Monitoramento de segurança na nuvem

Transferir dados e aplicativos para as nuvens é um novo problema para os SOCs corporativos que nem sempre estão prontos para monitorar a infraestrutura de outras pessoas. Segundo a Netoskope, uma empresa de médio porte (aparentemente ainda nos EUA) usa 1246 serviços em nuvem diferentes, 22% a mais do que um ano atrás. 1246 serviços em nuvem !!! 175 deles referem-se a serviços de RH, 170 são relacionados a marketing, 110 - no campo das comunicações e 76 em finanças e CRM. A Cisco usa "total" 700 serviços em nuvem externos. Portanto, estou um pouco confuso com esses números. Mas, em qualquer caso, o problema não está neles, mas no fato de que as nuvens estão sendo usadas ativamente por um número crescente de empresas que gostariam de ter os mesmos recursos para monitorar a infraestrutura de nuvem que em sua própria rede. E essa tendência está crescendo - de acordo com o American Audit Office, em 2023, 1.200 data centers serão fechados nos EUA (6.250 já fecharam). Mas a transição para a nuvem não é apenas "mas vamos transferir nossos servidores para um provedor externo". Nova arquitetura de TI, novo software, novos processos, novas restrições ... Tudo isso faz alterações significativas no trabalho não apenas da TI, mas também da segurança da informação. E se os provedores aprenderem a lidar com a segurança da própria nuvem (o benefício das recomendações é bastante), haverá dificuldades significativas com o monitoramento da segurança da informação na nuvem, especialmente nas plataformas SaaS, sobre as quais falaremos.



Digamos que sua empresa mudou parte de sua infraestrutura para a nuvem ... Pare. Não é assim. Se a infraestrutura for transferida e você só agora estiver pensando em como irá monitorá-la, você já terá perdido. Se não for Amazon, Google ou Microsoft (e com reservas), provavelmente você não terá muitas oportunidades para monitorar seus dados e aplicativos. Bem, se você tiver a oportunidade de trabalhar com logs. Às vezes, os dados sobre eventos de segurança estarão disponíveis, mas você não terá acesso a eles. Por exemplo, Office 365. Se você possui a licença E1 mais barata, os eventos de segurança não estão disponíveis para você. Se você possui uma licença E3, você só precisa armazenar dados por 90 dias e somente se tiver E5 - a duração dos logs estará disponível por um ano (embora existam algumas nuances associadas à necessidade de solicitar separadamente várias funções de log do suporte da Microsoft). A propósito, a licença E3 é muito mais fraca em termos de funções de monitoramento do que o Exchange corporativo. Para atingir o mesmo nível, você precisa de uma licença E5 ou uma licença adicional de conformidade avançada, que pode exigir dinheiro adicional que não foi incluído no seu modelo financeiro para a transição para a infraestrutura de nuvem. E este é apenas um exemplo de subestimação de problemas relacionados ao monitoramento da nuvem IS. Neste artigo, sem pretender concluir, quero chamar a atenção para algumas nuances que devem ser consideradas ao escolher um provedor de nuvem do ponto de vista da segurança. E no final do artigo, será fornecida uma lista de verificação, que deve ser concluída antes que você considere que o problema de monitoramento da segurança das informações na nuvem foi resolvido.

Existem vários problemas típicos que levam a incidentes em ambientes em nuvem, aos quais os serviços de IB não têm tempo para responder ou não veem:

• Os logs de segurança não existem. Essa é uma situação bastante comum, especialmente para iniciantes no mercado de nuvem. Mas acabar com eles imediatamente não vale a pena. Os pequenos players, especialmente os domésticos, são mais sensíveis aos requisitos dos clientes e podem implementar rapidamente algumas funções solicitadas, alterando o roteiro aprovado para seus produtos. Sim, não será um análogo do GuardDuty da Amazon ou do módulo Proactive Defense da Bitrix, mas pelo menos alguma coisa.
• O IB não sabe onde os logs estão armazenados ou não há acesso a eles. Aqui é necessário entrar em negociações com o provedor de serviços em nuvem - talvez ele forneça essas informações se considerar o cliente significativo para si mesmo. Mas, em geral, isso não é muito bom quando o acesso aos logs é fornecido "por uma decisão especial".
• Também acontece que o provedor de nuvem possui logs, mas eles fornecem monitoramento e log de eventos limitados, insuficientes para detectar todos os incidentes. Por exemplo, você pode receber apenas os registros de alterações no site ou os registros de tentativas de autenticação de usuários, mas eles não podem fornecer outros eventos, por exemplo, sobre tráfego de rede, que ocultará uma camada inteira de eventos que caracterizam tentativas de invasão da infraestrutura da nuvem.
• Existem logs, mas o acesso a eles é difícil de automatizar, o que os faz monitorar não continuamente, mas de acordo com uma programação. E se você ainda não pode baixar os logs no modo automático, o upload de logs, por exemplo, no formato Excel (como em alguns fornecedores de soluções em nuvem domésticas), pode levar à falta de vontade de mexer com eles no serviço de SI corporativo.
• Sem monitoramento de log. Esse talvez seja o motivo mais incompreensível para a ocorrência de incidentes de segurança da informação em ambientes em nuvem. Parece que existem logs, e você pode automatizar o acesso a eles, mas ninguém faz isso. Porque

Conceito de segurança compartilhada em nuvem

Mudar para as nuvens é sempre a busca de um equilíbrio entre o desejo de manter o controle sobre a infraestrutura e transferi-la para as mãos mais profissionais do provedor de nuvem, especializado em mantê-la. E no campo da segurança na nuvem, esse equilíbrio também deve ser buscado. Além disso, dependendo do modelo usado de prestação de serviços em nuvem (IaaS, PaaS, SaaS), esse equilíbrio será sempre diferente. Em qualquer situação, devemos lembrar que hoje todos os provedores de nuvem seguem o chamado modelo de responsabilidade compartilhada e segurança de informações compartilhadas. A nuvem é responsável por alguma coisa, o cliente é responsável por alguma coisa, tendo colocado seus dados, aplicativos, máquinas virtuais e outros recursos na nuvem. Seria tolice esperar que, tendo entrado na nuvem, transferiremos toda a responsabilidade para o provedor. Mas construir toda a segurança por conta própria ao migrar para a nuvem também é irracional. É necessário um equilíbrio, que dependerá de muitos fatores: - estratégias de gerenciamento de riscos, modelos de ameaças disponíveis para o provedor de mecanismos de defesa, legislação, etc.



Por exemplo, a classificação dos dados hospedados na nuvem é sempre de responsabilidade do cliente. Um provedor de nuvem ou um provedor de serviços externo pode ajudá-lo apenas com um kit de ferramentas que ajudará a marcar dados na nuvem, identificar violações, excluir dados que violam a lei ou mascará-los usando um método ou outro. Por outro lado, a segurança física é sempre de responsabilidade do provedor de nuvem, que não pode compartilhar com os clientes. Mas tudo o que há entre os dados e a infraestrutura física é precisamente o assunto da discussão neste artigo. Por exemplo, a disponibilidade da nuvem é de responsabilidade do provedor e a definição de regras da ITU ou a ativação da criptografia é de responsabilidade do cliente. Neste artigo, tentaremos ver que tipo de mecanismos de segurança da informação são fornecidos por vários provedores de nuvem populares na Rússia atualmente, quais são os recursos de seus aplicativos e quando procurar soluções de sobreposição externa (por exemplo, Cisco E-mail Security) que expandem os recursos de sua nuvem em parte cibersegurança. Em alguns casos, especialmente ao seguir uma estratégia de várias nuvens, você não terá escolha a não ser usar soluções de monitoramento de segurança externas em vários ambientes de nuvem ao mesmo tempo (por exemplo, Cisco CloudLock ou Cisco Stealthwatch Cloud). Bem, em alguns casos, você entenderá que o provedor de nuvem que você escolheu (ou lhe impôs) não oferece nenhuma opção para monitorar a segurança das informações. Isso é desagradável, mas também muito, pois permite avaliar adequadamente o nível de risco associado ao trabalho com essa nuvem.

Ciclo de vida do monitoramento de segurança na nuvem

Para monitorar a segurança das nuvens que você usa, você tem apenas três opções:

• confie nas ferramentas fornecidas pelo seu provedor de nuvem,
• aproveite as soluções de terceiros que monitorarão as plataformas IaaS, PaaS ou SaaS usadas,
• Crie sua própria infraestrutura de monitoramento de nuvem (apenas plataformas IaaS / PaaS).

Vamos ver quais recursos cada uma dessas opções possui. Mas primeiro, precisamos entender o esquema geral que será usado no monitoramento de plataformas em nuvem. Eu destacaria seis componentes principais do processo de monitoramento de segurança da informação na nuvem:

• Preparação de infraestrutura. Identificação dos aplicativos e infraestrutura necessários para a coleta de eventos importantes para a segurança da informação no repositório.
• Coleção. Nesse estágio, os eventos de segurança são agregados de várias fontes para posterior transmissão ao processamento, armazenamento e análise.
• Processando. Nesse ponto, os dados são transformados e enriquecidos para facilitar sua análise subsequente.
• Armazenamento. Esse componente é responsável pelo armazenamento de curto e longo prazo dos dados processados ​​e brutos coletados.
• Análise. Nesta fase, você tem a capacidade de detectar incidentes e responder a eles automaticamente ou manualmente.
• Relatórios Esse estágio ajuda a formar indicadores-chave para as partes interessadas (gerenciamento, auditores, provedores de nuvem, clientes etc.) que nos ajudam a tomar certas decisões, por exemplo, alterar o provedor ou fortalecer o SI.

A compreensão desses componentes permitirá determinar rapidamente o que você pode obter do seu provedor e o que você terá que fazer sozinho ou com a ajuda de consultores externos.

Serviços em nuvem integrados

Eu já escrevi acima que muitos serviços em nuvem hoje não oferecem nenhuma possibilidade de monitorar a segurança das informações. Em geral, eles não prestam muita atenção ao tópico de segurança da informação. Por exemplo, um dos serviços russos populares para enviar relatórios a agências governamentais pela Internet (não mencionarei especificamente o nome). Toda a seção de segurança deste serviço gira em torno do uso de ferramentas certificadas de proteção de informações criptográficas. A seção de segurança da informação de outro serviço de nuvem doméstica para gerenciamento de documentos eletrônicos não é mais um exemplo. Ele fala sobre certificados de chave pública, criptografia certificada, eliminação de vulnerabilidades da Web, proteção contra ataques DDoS, aplicação de ITU, backup e até mesmo auditorias regulares de IS. Mas nem uma palavra sobre monitoramento, nem sobre a possibilidade de obter acesso a eventos de segurança da informação que possam ser do interesse dos clientes desse provedor de serviços.

Em geral, pela maneira como o provedor de nuvem descreve os problemas de segurança da informação em seu site e na documentação, pode-se entender com que seriedade ele geralmente leva esse problema. Por exemplo, se você ler os manuais dos produtos My Office, não haverá uma palavra sobre segurança e a documentação do produto My Office separado. O KS3 ”, projetado para proteger contra acesso não autorizado, é a enumeração usual de cláusulas da 17ª ordem do FSTEC, que executa“ My office.KS3 ”, mas não está descrito como ele funciona e, o mais importante, como integrar esses mecanismos à segurança das informações corporativas. Talvez essa documentação esteja lá, mas não a encontrei em domínio público no site My Office. Embora talvez eu simplesmente não tenha acesso a essas informações classificadas?



A mesma situação do Bitrix é muito melhor. A documentação descreve os formatos dos logs de eventos e, curiosamente, o log de intrusão, que contém eventos relacionados a ameaças potenciais à plataforma em nuvem. A partir daí, você pode obter IP, nome de usuário ou nome do convidado, fonte do evento, hora, agente do usuário, tipo de evento etc. É verdade que você pode trabalhar com esses eventos no painel de controle da própria nuvem ou fazer upload de dados no formato MS Excel. Agora é difícil automatizar o trabalho com os registros do Bitrix e você terá que fazer parte do trabalho manualmente (faça o upload do relatório e carregue-o no SIEM). Mas se você se lembrar disso até recentemente, e isso não era possível, esse é um grande progresso. Ao mesmo tempo, quero observar que muitos provedores de nuvem estrangeiros oferecem funcionalidades semelhantes “para iniciantes” - olhe os logs com seus olhos através do painel de controle ou faça o upload de dados para si mesmo (embora a maioria faça upload de dados no formato .csv, não no Excel).



Se você não considera a opção sem logs, os provedores de nuvem geralmente oferecem três opções para monitorar eventos de segurança - painéis, upload de dados e acesso a eles via API. O primeiro parece resolver muitos problemas para você, mas isso não é totalmente verdade - se houver várias revistas, você precisará alternar entre as telas que as exibem, perdendo o quadro geral. Além disso, é improvável que o provedor de nuvem ofereça a você a oportunidade de correlacionar eventos de segurança e geralmente analisá-los do ponto de vista da segurança (geralmente você está lidando com dados brutos que precisa entender). Existem exceções e falaremos mais sobre elas. Por fim, vale a pena perguntar: quais eventos seu provedor de nuvem registra, em qual formato e quanto eles correspondem ao seu processo de monitoramento de IS? Por exemplo, a identificação e autenticação de usuários e convidados. O mesmo Bitrix permite registrar a data e hora do evento, o nome do usuário ou convidado (na presença do módulo Web Analytics), o objeto ao qual o acesso é feito e outros elementos típicos do site. Mas os serviços de IS corporativos podem precisar de informações sobre se um usuário efetuou login na nuvem a partir de um dispositivo confiável (por exemplo, em uma rede corporativa, o Cisco ISE implementa esta tarefa). E uma tarefa tão simples como a função de IP geográfico, que ajudará a determinar se a conta de usuário do serviço em nuvem é roubada? E mesmo que o provedor de nuvem o forneça, isso não é suficiente. O mesmo Cisco CloudLock não apenas analisa a localização geográfica, mas usa o aprendizado de máquina para isso e analisa dados históricos de cada usuário e rastreia várias anomalias na tentativa de identificar e autenticar. Somente o MS Azure possui funcionalidade semelhante (se houver uma assinatura correspondente).



Há mais uma dificuldade - já que para muitos provedores de nuvem o monitoramento de IS é um novo tópico com o qual eles estão apenas começando a lidar, eles estão constantemente mudando algo em suas decisões. Hoje eles têm uma versão da API, amanhã outra, o terceiro dia depois de amanhã. É preciso também estar preparado para isso. A mesma coisa com a funcionalidade que pode mudar, que deve ser levada em consideração no seu sistema de monitoramento de segurança da informação. Por exemplo, a Amazon tinha inicialmente serviços de monitoramento de eventos em nuvem separados - AWS CloudTrail e AWS CloudWatch. Em seguida, veio um serviço de monitoramento de eventos de IS separado - AWS GuardDuty. Depois de algum tempo, a Amazon lançou o novo sistema de gerenciamento Amazon Security Hub, que inclui uma análise dos dados recebidos do GuardDuty, Amazon Inspector, Amazon Macie e vários outros. Outro exemplo é a ferramenta de integração de log do Azure com o SIEM - AzLog. Muitos fornecedores de SIEM o utilizaram ativamente, até 2018 a Microsoft anunciou o término de seu desenvolvimento e suporte, o que colocou muitos clientes que usavam essa ferramenta antes do problema (como foi resolvido, falaremos mais adiante).

Portanto, monitore cuidadosamente todas as funções de monitoramento que seu provedor de nuvem oferece a você. Ou confie em fornecedores externos de soluções que atuarão como intermediários entre seu SOC e a nuvem que você deseja monitorar. Sim, será mais caro (embora nem sempre), mas você transferirá toda a responsabilidade para os ombros dos outros. Ou não todos? .. Lembre-se do conceito de segurança compartilhada e entenda que não podemos mudar nada - você precisará descobrir como diferentes provedores de nuvem fornecem monitoramento de segurança das informações de seus dados, aplicativos, máquinas virtuais e outros recursos localizados na nuvem. E começaremos com o que a Amazon oferece nesta parte.

Exemplo: monitoramento de segurança em IaaS baseado na AWS

Sim, entendo que a Amazon não é o melhor exemplo, pois é um serviço americano e pode ser bloqueada como parte da luta contra o extremismo e a disseminação de informações proibidas na Rússia. Mas nesta publicação, gostaria apenas de mostrar como as diferentes plataformas de nuvem diferem nos recursos de segurança da informação e em que você deve prestar atenção ao transferir seus principais processos para as nuvens do ponto de vista da segurança. Bem, se alguns dos desenvolvedores russos de soluções em nuvem obtiverem algo útil para si mesmos, será ótimo.



Primeiro, devo dizer que a Amazônia não é uma fortaleza inexpugnável. Vários incidentes acontecem regularmente com seus clientes. Por exemplo, os nomes, endereços, datas de nascimento e telefones de 198 milhões de eleitores foram roubados do Deep Root Analytics. 14 milhões de registros de assinatura da Verizon roubados da Nice Systems, Israel Ao mesmo tempo, os recursos internos da AWS permitem detectar uma ampla variedade de incidentes. Por exemplo:

• Influência na infraestrutura (DDoS)
• comprometimento do nó (injeção de comando)
• comprometimento da conta e acesso não autorizado
• configuração incorreta e vulnerabilidades
• interfaces e APIs desprotegidas.

Essa discrepância se deve ao fato de o próprio cliente ser responsável pela segurança dos dados do cliente, conforme descobrimos acima. E se ele não se preocupou com a inclusão de mecanismos de proteção e não incluiu ferramentas de monitoramento, ele aprenderá sobre o incidente apenas na mídia ou em seus clientes.

Para detectar incidentes, você pode usar uma ampla variedade de vários serviços de monitoramento desenvolvidos pela Amazon (embora sejam frequentemente complementados por ferramentas externas, como a osquery). Portanto, na AWS, todas as ações do usuário são rastreadas, independentemente de como são realizadas - por meio do console de gerenciamento, linha de comando, SDK ou outros serviços da AWS. Todos os registros das ações de cada conta da AWS (incluindo nome de usuário, ação, serviço, parâmetros de atividade e seu resultado) e uso da API estão disponíveis no AWS CloudTrail. Você pode visualizar esses eventos (por exemplo, fazer login no console do AWS IAM) no console do CloudTrail, analisá-los usando o Amazon Athena ou "fornecê-los" para soluções externas, como Splunk, AlienVault etc. Os próprios logs do AWS CloudTrail são colocados no seu bucket do AWS S3.



Os outros dois serviços da AWS fornecem alguns recursos de monitoramento mais importantes. Em primeiro lugar, o Amazon CloudWatch é um serviço de monitoramento de recursos e aplicativos da AWS que, entre outras coisas, pode detectar várias anomalias em sua nuvem. Todos os serviços internos da AWS, como Amazon Elastic Compute Cloud (servidores), Amazon Relational Database Service (bancos de dados), Amazon Elastic MapReduce (análise de dados) e 30 outros serviços da Amazon, usam o Amazon CloudWatch para armazenar seus logs. Os desenvolvedores podem usar a API aberta do Amazon CloudWatch para adicionar funcionalidade de monitoramento de log aos aplicativos e serviços do usuário, o que permite expandir a gama de eventos analisados ​​no contexto da segurança da informação.



Em segundo lugar, o serviço VPC Flow Logs permite analisar o tráfego de rede enviado ou recebido pelos servidores da AWS (externa ou internamente), bem como entre microsserviços. Quando qualquer um dos seus recursos do AWS VPC interage com a rede, o serviço VPC Flow Logs registra as informações de tráfego da rede, incluindo as interfaces de rede de origem e de destino, bem como endereços IP, portas, protocolo, número de bytes e número de pacotes que você viu. Aqueles com experiência em segurança de rede local reconhecem isso como um análogo dos fluxos NetFlow .que podem ser criados por switches, roteadores e firewalls de nível corporativo. Esses logs são importantes para o monitoramento da segurança das informações, porque, diferentemente dos eventos de atividades de usuários e aplicativos, eles também permitem que você não perca a comunicação de rede no ambiente de nuvem privada virtual da AWS.



Portanto, esses três serviços da AWS - AWS CloudTrail, Amazon CloudWatch e VPC Flow Logs - juntos fornecem uma visão bastante eficaz do uso da sua conta, comportamento do usuário, gerenciamento da infraestrutura, atividade de aplicativos e serviços e atividade de rede. Por exemplo, eles podem ser usados ​​para detectar as seguintes anomalias:

• Tentativas de varrer o site, procurar backdoors, procurar vulnerabilidades através de explosões de "erros 404".
• Injection- (, SQL injection) “ 500”.
• sqlmap, nikto, w3af, nmap .. User Agent.

A Amazon Web Services também desenvolveu outros serviços de segurança cibernética que abordam muitos outros desafios. Por exemplo, a AWS possui um serviço interno para auditoria de políticas e configurações - AWS Config. Esse serviço fornece auditoria contínua dos recursos da AWS e de suas configurações. Considere um exemplo simples: suponha que você queira ter certeza de que as senhas dos usuários estejam desabilitadas em todos os seus servidores e que o acesso seja possível apenas com base em certificados. O AWS Config facilita a verificação disso para todos os seus servidores. Existem outras políticas que podem ser aplicadas aos servidores em nuvem: “Nenhum servidor pode usar a porta 22”, “Somente administradores podem alterar as regras de firewall” ou “Somente o usuário Ivashko pode criar novas contas de usuário e ele pode fazer é apenas às terças-feiras ".No verão de 2016, o AWS Config foi expandido para automatizar a detecção de violações das políticas desenvolvidas. As regras de configuração da AWS são, em essência, solicitações de configuração contínua para os serviços Amazon que você usa, que geram eventos em caso de violação das políticas relevantes. Por exemplo, em vez de executar periodicamente solicitações do AWS Config para verificar se todas as unidades de servidor virtual estão criptografadas, as Regras de configuração da AWS podem ser usadas para verificar constantemente essas unidades do servidor quanto a essa condição. E, mais importante, no contexto desta publicação, quaisquer violações geram eventos que podem ser analisados ​​pelo seu serviço de SI.Solicitações de configuração contínua para os serviços Amazon que você usa que geram eventos quando políticas são violadas. Por exemplo, em vez de executar periodicamente solicitações do AWS Config para verificar se todas as unidades de servidor virtual estão criptografadas, as Regras de configuração da AWS podem ser usadas para verificar constantemente essas unidades do servidor quanto a essa condição. E, mais importante, no contexto desta publicação, quaisquer violações geram eventos que podem ser analisados ​​pelo seu serviço de SI.Solicitações de configuração contínua para os serviços Amazon que você usa que geram eventos quando políticas são violadas. Por exemplo, em vez de executar periodicamente solicitações do AWS Config para verificar se todas as unidades de servidor virtual estão criptografadas, as Regras de configuração da AWS podem ser usadas para verificar constantemente essas unidades do servidor quanto a essa condição. E, mais importante, no contexto desta publicação, quaisquer violações geram eventos que podem ser analisados ​​pelo seu serviço de SI.As Regras de configuração da AWS podem ser usadas para verificar constantemente os discos do servidor quanto a essa condição. E, mais importante, no contexto desta publicação, quaisquer violações geram eventos que podem ser analisados ​​pelo seu serviço de SI.As Regras de configuração da AWS podem ser usadas para verificar constantemente os discos do servidor quanto a essa condição. E, mais importante, no contexto desta publicação, quaisquer violações geram eventos que podem ser analisados ​​pelo seu serviço de SI.



A AWS também tem seus equivalentes às soluções tradicionais de segurança da informação corporativa, que também geram eventos de segurança que você pode e deve analisar:

• Detecção de intrusão - AWS GuardDuty
• controle de vazamento - AWS Macie
• EDR (embora falar sobre pontos de extremidade na nuvem seja um pouco estranho) - AWS Cloudwatch + osquery de código aberto ou soluções GRR
• Análise de fluxo de rede - AWS Cloudwatch + AWS VPC Flow
• Análise de DNS - AWS Cloudwatch + AWS Route53
• AD - Serviço de Diretório da AWS
• Gerenciamento de contas - AWS IAM
• SSO - SSO da AWS
• análise de segurança - AWS Inspector
• gerenciamento de configuração - AWS Config
• WAF - AWS WAF.

Não detalharei todos os serviços da Amazon que possam ser úteis no contexto de segurança da informação. O principal a entender é que todos eles podem gerar eventos que podemos e devemos analisar no contexto da segurança da informação, envolvendo tanto os recursos internos da Amazon quanto as soluções externas, por exemplo, SIEM, que pode levar eventos de segurança ao seu centro de monitoramento e analisá-los, juntamente com eventos de outros serviços em nuvem ou de infraestrutura interna, perímetro ou dispositivos móveis.



De qualquer forma, tudo começa com fontes de dados que fornecem eventos de IB. Essas fontes incluem, mas não estão limitadas a:

• CloudTrail - Uso da API e ações do usuário
• Consultor Confiável - Verificação de Segurança para Melhores Práticas
• Config —
• VPC Flow Logs —
• IAM —
• ELB Access Logs —
• Inspector —
• S3 —
• CloudWatch —
• SNS — .

A Amazon, oferecendo uma variedade de fontes e ferramentas de eventos para sua geração, é muito limitada em sua capacidade de analisar os dados coletados no contexto da segurança da informação. Você terá que estudar independentemente os logs disponíveis, procurando os indicadores correspondentes de comprometimento neles. O AWS Security Hub, lançado recentemente pela Amazon, tem como objetivo resolver esse problema, tornando-se uma espécie de SIEM para a AWS baseado em nuvem. Porém, embora esteja apenas no início de sua jornada e seja limitado tanto pelo número de fontes com as quais trabalha, quanto por outras restrições estabelecidas pela arquitetura e assinaturas da própria Amazon.

Exemplo: Monitorando o IS no IaaS baseado no Azure

Não quero entrar em um longo debate sobre qual dos três provedores de nuvem (Amazon, Microsoft ou Google) é melhor (especialmente porque cada um deles tem suas próprias características específicas e é adequado para resolver seus problemas); concentre-se nos recursos de monitoramento de segurança que esses players fornecem. É certo que o Amazon AWS foi um dos primeiros nesse segmento e, portanto, avançou mais em termos de funções de segurança da informação (embora muitos admitam que é difícil usá-los). Mas isso não significa que ignoraremos as oportunidades que a Microsoft nos oferece ao Google.

Os produtos da Microsoft sempre se destacaram por sua "abertura" e no Azure a situação é semelhante. Por exemplo, se AWS e GCP sempre vêm do conceito de "tudo o que não é permitido é proibido", o Azure tem a abordagem exatamente oposta. Por exemplo, criando uma rede virtual na nuvem e uma máquina virtual nela, todas as portas e protocolos são abertos e ativados por padrão. Portanto, você precisará gastar um pouco mais de esforço na configuração inicial do sistema de controle de acesso na nuvem da Microsoft. E isso também impõe requisitos mais rigorosos para você em termos de atividade de monitoramento na nuvem do Azure.



A AWS tem uma peculiaridade relacionada ao fato de que, quando você monitora seus recursos virtuais, se eles estiverem em regiões diferentes, você tem dificuldades em combinar todos os eventos e sua análise única, para eliminar os quais você precisa recorrer a vários truques, como Crie um código personalizado para o AWS Lambda que carregará eventos entre regiões. Não existe esse problema no Azure - seu mecanismo de log de atividades monitora todas as atividades da organização sem restrições. O mesmo vale para o AWS Security Hub, desenvolvido recentemente pela Amazon para consolidar muitas funções de segurança em um único centro de segurança, mas apenas em sua região, que, no entanto, não é relevante para a Rússia. O Azure possui sua própria Central de Segurança, que não está vinculada a restrições regionais,fornecendo acesso a todos os recursos de segurança da plataforma em nuvem. Além disso, para várias equipes locais, ele pode fornecer seu próprio conjunto de recursos defensivos, incluindo eventos de segurança gerenciados por elas. O AWS Security Hub ainda está se esforçando para se tornar como a Central de Segurança do Azure. Mas vale a pena adicionar uma mosca na pomada - você pode extrair muito do que foi descrito anteriormente na AWS no Azure, mas isso é feito de maneira mais conveniente apenas para o Azure AD, o Azure Monitor e o Centro de Segurança do Azure. Todos os outros mecanismos de defesa do Azure, incluindo a análise de eventos de segurança, ainda não são gerenciados da maneira mais conveniente. Parte do problema é resolvida pela API que permeia todos os serviços do Microsoft Azure, mas isso exigirá esforços adicionais para integrar sua nuvem ao seu SOC e à disponibilidade de especialistas qualificados (na verdade,como com qualquer outro. SIEM trabalhando com APIs de nuvem). Alguns SIEMs, que serão discutidos posteriormente, já oferecem suporte ao Azure e podem automatizar a tarefa de monitorá-lo, mas existem algumas dificuldades com ele - nem todos eles podem receber todos os logs que o Azure possui.



A coleta e o monitoramento de eventos no Azure são fornecidos usando o serviço Azure Monitor, que é a principal ferramenta para coletar, armazenar e analisar dados na nuvem da Microsoft e seus recursos - repositórios Git, contêineres, máquinas virtuais, aplicativos etc. Todos os dados coletados pelo Azure Monitor são divididos em duas categorias: métricas em tempo real que descrevem os principais indicadores de desempenho da nuvem do Azure e logs de registro contendo dados organizados em registros, caracterizando certos aspectos das atividades dos recursos e serviços do Azure. Além disso, usando a API do coletor de dados, o serviço Monitor do Azure pode coletar dados de qualquer fonte REST para criar seus próprios cenários de monitoramento.



Aqui estão algumas fontes de eventos de segurança que o Azure oferece a você que você pode acessar por meio da API do Portal, CLI, PowerShell ou REST do Azure (e algumas apenas pela API do Azure Monitor / Insight):

• Logs de atividades - este diário responde às perguntas clássicas “quem”, “o quê” e “quando” em relação a qualquer operação de gravação (PUT, POST, DELETE) sobre recursos da nuvem. Eventos relacionados ao acesso de leitura (GET) não se enquadram nesse log, nem em vários outros.
• Logs de diagnóstico - contém dados sobre operações com um recurso específico incluído na sua assinatura.
• Relatório do Azure AD - contém as atividades do usuário e do sistema relacionadas ao gerenciamento de grupos e usuários.
• Log de Eventos do Windows e Syslog do Linux - contém eventos de máquinas virtuais hospedadas na nuvem.
• Metrics — “” . . 30 .
• Network Security Group Flow Logs — , Network Watcher .
• Storage Logs — , .

Para o monitoramento, você pode usar o SIEM externo ou o Azure Monitor interno e suas extensões. Falaremos mais sobre os sistemas de gerenciamento de eventos de SI, mas, por enquanto, veremos o que o próprio Azure nos oferece para analisar dados no contexto de segurança. A tela principal de tudo relacionado à segurança no Azure Monitor é o Painel de Auditoria e Segurança do Log Analytics (a versão gratuita suporta o armazenamento de uma quantidade limitada de eventos por apenas uma semana). Este painel é dividido em 5 áreas principais que visualizam estatísticas resumidas do que está acontecendo no seu ambiente de nuvem:

• Domínios de segurança - principais indicadores quantitativos relacionados à segurança da informação - o número de incidentes, o número de nós comprometidos, os nós sem patches, os eventos de segurança de rede etc.
• Problemas notáveis ​​- Exibe o número e a importância dos problemas de IB ativos
• Detections — ,
• Threat Intelligence — ,
• Common security queries — , .

As extensões do Monitor do Azure incluem o Azure Key Vault (proteção de chaves criptográficas na nuvem), Avaliação de Malware (análise de proteção contra código malicioso em máquinas virtuais), Azure Application Gateway Analytics (análise de, entre outras coisas, logs de firewall na nuvem), etc. . Essas ferramentas, enriquecidas por certas regras de processamento de eventos, permitem visualizar vários aspectos da atividade dos serviços em nuvem, incluindo segurança, e identificar certos desvios do trabalho. Porém, como costuma acontecer, qualquer funcionalidade adicional requer uma assinatura paga apropriada, o que exigirá investimentos financeiros apropriados, que você deve planejar com antecedência.



O Azure possui vários recursos internos de monitoramento de ameaças integrados ao Azure AD, Azure Monitor e Centro de Segurança do Azure. Entre eles, por exemplo, detectar a interação de máquinas virtuais com IPs maliciosos conhecidos (devido à integração com os serviços Microsoft Threat Intelligence), detectar malware na infraestrutura da nuvem ao receber alarmes de máquinas virtuais localizadas na nuvem, ataques como "adivinhação de senha" ”Para máquinas virtuais, vulnerabilidades na configuração do sistema de identificação do usuário, logon de anonimizadores ou nós infectados, vazamento de conta, logon de locais incomuns, etc. O Azure hoje é um dos poucos provedores de nuvem que oferece recursos internos de Threat Intelligence para enriquecer os eventos de segurança das informações coletadas.



Como mencionado acima, a funcionalidade de proteção e, como conseqüência, os eventos de segurança gerados por ela não são acessíveis a todos os usuários igualmente, mas requer uma certa assinatura que inclua a funcionalidade necessária, que gera os eventos correspondentes para monitorar a segurança das informações. Por exemplo, algumas das funções para monitorar anomalias nas contas descritas no parágrafo anterior estão disponíveis apenas na licença premium P2 do Azure AD. Sem ele, você, como no caso da AWS, terá que analisar os eventos de segurança coletados "manualmente". Além disso, dependendo do tipo de licença do Azure AD, nem todos os eventos para análise estarão disponíveis para você.

No portal do Azure, você pode gerenciar as consultas de pesquisa nos logs de seu interesse e configurar os painéis para visualizar os principais indicadores de segurança das informações. Além disso, você pode escolher as extensões do Azure Monitor, que permitem expandir a funcionalidade dos logs do Azure Monitor e obter uma análise mais aprofundada dos eventos do ponto de vista da segurança.



Se você precisar não apenas da capacidade de trabalhar com logs, mas também do abrangente centro de segurança da sua plataforma em nuvem do Azure, incluindo o gerenciamento de políticas de IS, poderá falar sobre a necessidade de trabalhar com a Central de Segurança do Azure, a maioria útil por uma taxa, por exemplo, detecção de ameaças, monitoramento fora do Azure, avaliação de conformidade etc. (Na versão gratuita, você só tem acesso a uma avaliação de segurança e recomendações para resolver problemas identificados). Consolida todos os problemas de segurança em um só lugar. De fato, podemos falar sobre um nível mais alto de segurança das informações do que o Azure Monitor fornece, pois, nesse caso, os dados coletados em toda a sua fábrica em nuvem são enriquecidos usando uma variedade de fontes, como Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, Outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) e Microsoft Security Response Center (MSRC), sobrepostos a vários algoritmos sofisticados de aprendizado de máquina e de análise comportamental, que devem aumentar a eficiência da detecção e resposta a ameaças.

O Azure possui seu próprio SIEM - ele apareceu no início de 2019. Este é o Azure Sentinel, que depende de dados do Azure Monitor e também pode se integrar. soluções de segurança externa (por exemplo, NGFW ou WAF), cuja lista é atualizada constantemente. Além disso, com a integração da API do Microsoft Graph Security, você pode conectar seus próprios feeds do Threat Intelligence ao Sentinel, o que enriquece a capacidade de analisar incidentes na nuvem do Azure. Pode-se argumentar que o Azure Sentinel é o primeiro SIEM "nativo" que apareceu nos provedores de nuvem (o mesmo Splunk ou ELK, que pode ser colocado na nuvem, por exemplo, AWS, ainda não foi desenvolvido pelos provedores de serviços em nuvem tradicionais). O Sentinel e a Central de Segurança do Azure poderiam ser chamados de SOC para a nuvem do Azure e poderiam ser limitados (com certas reservas) se você não tivesse mais nenhuma infraestrutura e transferisse todos os seus recursos de computação para a nuvem e seria uma nuvem da Microsoft Azure



Porém, como os recursos internos do Azure (mesmo com uma assinatura do Sentinel) muitas vezes não são suficientes para o monitoramento e integração de IS desse processo com outras fontes de eventos de segurança (na nuvem e internos), torna-se necessário exportar os dados coletados para sistemas externos, que pode incluir SIEM. Isso é feito com a ajuda da API e com extensões especiais que estão oficialmente disponíveis no momento apenas para os seguintes SIEMs - Splunk (complemento do Azure Monitor para Splunk), IBM QRadar (DSM do Microsoft Azure), SumoLogic, ArcSight e ELK. Mais recentemente, havia mais SIEMs, mas a partir de 1 de junho de 2019, a Microsoft parou de oferecer suporte à Ferramenta de Integração de Log do Azure (AzLog), que no início do Azure e na ausência de padronização normal do trabalho com logs (o Monitor do Azure nem sequer existia) tornou mais fácil Integre SIEMs externos ao Microsoft Cloud. Agora a situação mudou e a Microsoft recomenda a plataforma Azure Event Hub como a principal ferramenta de integração para o restante do SIEM. Muitos já implementaram essa integração, mas tenha cuidado - eles podem não capturar todos os logs do Azure, mas apenas alguns (consulte a documentação do seu SIEM).

Concluindo uma breve excursão ao Azure, desejo dar uma recomendação geral sobre este serviço em nuvem - antes de falar sobre as funções de monitoramento de segurança no Azure, você deve configurá-las com muito cuidado e testar se elas funcionam conforme escrito na documentação e conforme os consultores informaram Microsoft (e eles podem ter visões diferentes sobre o desempenho dos recursos do Azure). Se você tiver os recursos financeiros do Azure, poderá extrair muitas informações úteis sobre o monitoramento de segurança das informações. Se seus recursos forem limitados, como no caso da AWS, você precisará confiar apenas em seus próprios recursos e dados brutos fornecidos pelo Azure Monitor. E lembre-se de que muitas funções de monitoramento custam dinheiro e é melhor se familiarizar com os preços com antecedência. Por exemplo, você pode armazenar dados por 31 dias, no máximo, 5 GB para um cliente de graça - exceder esses valores exigirá que você pague adicionalmente (aproximadamente US $ 2 ou mais para armazenar cada GB adicional do cliente e US $ 0,1 para armazenar 1 GB por mês adicional ) Trabalhar com telemetria e métricas de aplicativos também pode exigir recursos financeiros adicionais, além de trabalhar com alertas e notificações (um certo limite está disponível gratuitamente, o que pode não ser suficiente para suas necessidades).

Exemplo: monitoramento de IS na IaaS com base no Google Cloud Platform

O Google Cloud Platform no cenário da AWS e do Azure parece bastante jovem, mas isso é parcialmente bom. Diferentemente da AWS, que estava desenvolvendo seus recursos, inclusive os defensivos, gradualmente, tendo problemas com a centralização; O GCP, como o Azure, é muito melhor gerenciado centralmente, o que reduz o número de erros e o tempo de implementação na empresa. Do ponto de vista da segurança, o GCP está, curiosamente, localizado entre a AWS e o Azure. Ele também tem um registro de evento único para toda a organização, mas está incompleto. Algumas funções ainda estão no modo beta, mas gradualmente essa deficiência deve ser eliminada e o GCP se tornará uma plataforma mais madura em termos de monitoramento de segurança da informação.



A principal ferramenta para registrar eventos no GCP é o Stackdriver Logging (um análogo do Azure Monitor), que permite coletar eventos em toda a infraestrutura da nuvem (assim como na AWS). De uma perspectiva de segurança no GCP, toda organização, projeto ou pasta possui quatro logs:

• Atividade administrativa - contém todos os eventos relacionados ao acesso administrativo, por exemplo, criação de uma máquina virtual, alteração de direitos de acesso etc. Este diário é sempre escrito, independentemente do seu desejo, e armazena seus dados por 400 dias.
• Acesso a dados - contém todos os eventos relacionados ao trabalho com dados de usuários da nuvem (criar, modificar, ler etc.). Por padrão, este diário não está escrito, porque seu volume aumenta muito rapidamente. Por esse motivo, seu prazo de validade é de apenas 30 dias. Além disso, longe de tudo, está escrito neste diário. Por exemplo, eventos relacionados a recursos que estão disponíveis publicamente a todos os usuários ou acessíveis sem acesso ao GCP não são gravados nele.
• Evento do sistema - contém eventos do sistema que não estão relacionados aos usuários ou as ações de um administrador que altera a configuração dos recursos da nuvem. É sempre escrito e armazenado por 400 dias.
• A Transparência de acesso é um exemplo único de um diário de bordo que registra todas as ações dos funcionários do Google (mas ainda não para todos os serviços GCP) que obtêm acesso à sua infraestrutura como parte de suas responsabilidades profissionais. Esse diário é armazenado por 400 dias e não está disponível para todos os clientes GCP, mas apenas sujeito a várias condições (suporte Gold ou Platinum, ou a presença de 4 funções de um determinado tipo como parte do suporte corporativo). Um recurso semelhante também está disponível, por exemplo, no Office 365 - Lockbox.

Exemplo de log: Transparência de acesso

{  insertId:  "abcdefg12345"  jsonPayload: {  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"  location: {   principalOfficeCountry:  "US"   principalEmployingEntity:  "Google LLC"   principalPhysicalLocationCountry:  "CA"  }  product: [   0:  "Cloud Storage"  ]  reason: [   detail:  "Case number: bar123"   type:  "CUSTOMER_INITIATED_SUPPORT"  ]  accesses: [   0: {   methodName: "GoogleInternal.Read"   resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"   }  ]  }  logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"  operation: {  id:  "12345xyz"  }  receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"  resource: {  labels: {   project_id:  "1234567890"  }  type:  "project"  }  severity:  "NOTICE"  timestamp:  "2017-12-18T16:06:24.660001Z" } 

O acesso a esses logs é possível de várias maneiras (da mesma maneira que anteriormente considerada pelo Azure e AWS) - por meio da interface do Log Viewer, da API, do Google Cloud SDK ou da página Activity do seu projeto, de acordo com o qual você está interessado em eventos. Da mesma forma, eles também podem ser exportados para soluções externas para análises adicionais. O último é feito exportando logs para o armazenamento do BigQuery ou Cloud Pub / Sub.

Além do Stackdriver Logging, a plataforma GCP também oferece a funcionalidade Stackdriver Monitoring, que permite rastrear as principais métricas (desempenho, MTBF, status geral etc.) dos serviços e aplicativos em nuvem. Os dados processados ​​e visualizados podem facilitar a localização de problemas em sua infraestrutura de nuvem, inclusive no contexto de segurança. Mas deve-se observar que essa funcionalidade não será muito rica precisamente no contexto da segurança das informações, já que hoje o GCP não tem análogo do mesmo AWS GuardDuty e não pode distinguir os ruins de todos os eventos registrados (o Google desenvolveu a detecção de ameaças de eventos, mas até agora é na versão beta e fale sobre sua utilidade mais cedo). O Stackdriver Monitoring pode ser usado como um sistema para detectar anomalias, que serão investigadas para encontrar as causas de sua ocorrência. Mas, nas condições de escassez de pessoal qualificado no campo de segurança da informação GCP no mercado, essa tarefa no momento parece difícil.



Também vale a pena listar alguns dos módulos de segurança da informação que podem ser usados ​​na sua nuvem GCP e semelhantes ao que a AWS oferece:

• O Cloud Security Command Center é um análogo do AWS Security Hub e do Azure Security Center.
• Cloud DLP - detecção e edição automáticas (por exemplo, mascaramento) de dados localizados na nuvem, de acordo com mais de 90 políticas de classificação predefinidas.
• O Cloud Scanner é um scanner de vulnerabilidades conhecidas (XSS, Flash Injection, bibliotecas sem patch etc.) no App Engine, Compute Engine e Google Kubernetes.
• Cloud IAM - controle de acesso a todos os recursos do GCP.
• Identidade na nuvem - gerencie contas de usuário, dispositivos e aplicativos GCP a partir de um único console.
• Cloud HSM - proteção de chave criptográfica.
• Serviço de gerenciamento de chaves na nuvem - gerenciamento de chaves criptográficas no GCP.
• Controle de serviço da VPC - Crie um perímetro seguro em torno dos recursos do GCP para protegê-los contra vazamentos.
• Titan Security Key - proteção contra phishing.

Muitos desses módulos geram eventos de segurança que podem ser enviados ao BigQuery para análise ou exportação para outros sistemas, incluindo SIEM. Como já mencionado acima, o GCP é uma plataforma desenvolvida ativamente e agora o Google está desenvolvendo vários novos módulos de segurança da informação para sua plataforma. Entre eles estão a detecção de ameaças a eventos (agora disponível na versão beta), que verifica os logs do Stackdriver em busca de vestígios de atividade não autorizada (semelhante ao GuardDuty na AWS) ou a Policy Intelligence (disponível em alfa), que permitirá o desenvolvimento de políticas de acesso inteligente aos recursos do GCP.

Fiz uma breve revisão dos recursos internos de monitoramento em plataformas populares de nuvem. Mas você tem especialistas capazes de trabalhar com os logs brutos do provedor de IaaS (nem todos estão prontos para comprar recursos avançados da AWS, Azure ou Google)? Além disso, muitas pessoas conhecem o provérbio "confie, mas verifique", o que no campo da segurança é mais verdadeiro do que nunca. Quanto você confia nos recursos internos do provedor de nuvem que lhe enviam eventos de IB? Quanto eles se concentram na segurança da informação?

Às vezes, vale a pena procurar soluções de sobreposição para monitorar infraestruturas de nuvem que podem complementar a segurança interna da nuvem, e às vezes essas soluções são a única maneira de obter dados sobre a segurança de seus dados e aplicativos localizados na nuvem. Além disso, eles são simplesmente mais convenientes, pois assumem todas as tarefas de analisar os logs necessários gerados por diferentes serviços de nuvem de diferentes provedores de nuvem. Um exemplo dessa solução imposta é o Cisco Stealthwatch Cloud, que se concentra na única tarefa - monitorar anomalias de SI em ambientes em nuvem, incluindo não apenas Amazon AWS, Microsoft Azure e Google Cloud Platform, mas também nuvens privadas.

Exemplo: Monitorando a Segurança com a Nuvem Stealthwatch

A AWS fornece uma plataforma de computação flexível, mas essa flexibilidade facilita para as empresas cometer erros que levam a problemas de segurança. E o modelo de IS compartilhado apenas contribui para isso. A execução de software na nuvem com vulnerabilidades desconhecidas (por exemplo, o AWS Inspector ou o GCP Cloud Scanner pode combater vulnerabilidades conhecidas), senhas fracas, configurações incorretas, informações privilegiadas etc. E tudo isso afeta o comportamento dos recursos da nuvem, o que pode ser observado pelo Cisco Stealthwatch Cloud, que é um sistema para monitorar a segurança das informações e a detecção de ataques. nuvens públicas e privadas.



Um dos principais recursos do Cisco Stealthwatch Cloud é a capacidade de modelar entidades. Com sua ajuda, você pode criar um modelo de programa (isto é, uma simulação quase em tempo real) de cada um dos seus recursos de nuvem (não importa se é AWS, Azure, GCP ou outra coisa). Isso pode incluir servidores e usuários, além de tipos de recursos específicos para o seu ambiente de nuvem, como grupos de segurança e grupos de dimensionamento automático. Esses modelos usam fluxos de dados estruturados fornecidos pelos serviços em nuvem como entrada. Por exemplo, para a AWS, esses serão Logs de fluxo da VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda e AWS IAM. A modelagem de entidades detecta automaticamente a função e o comportamento de qualquer um dos seus recursos (você pode falar sobre a criação de perfil de todas as atividades da nuvem). Entre essas funções estão um dispositivo móvel Android ou Apple, servidor Citrix PVS, servidor RDP, gateway de correio, cliente VoIP, servidor de terminal, controlador de domínio, etc. Ele então monitora continuamente seu comportamento para determinar quando ocorre um comportamento arriscado ou ameaçador à segurança. Você pode identificar a adivinhação de senha, ataques DDoS, vazamentos de dados, acesso remoto ilegal, código malicioso, verificação de vulnerabilidades e outras ameaças. Por exemplo, veja como é detectar uma tentativa de acesso remoto de um país atípico de sua organização (Coréia do Sul) ao cluster Kubernetes via SSH:



E é com isso que parece o suposto vazamento de informações do banco de dados do Postgress em um país que não foi previamente interagido:



Finalmente, é assim que muitas tentativas de acesso SSH com falha da China e da Indonésia a partir de um dispositivo remoto externo se parecem:



Ou, suponha que uma instância de servidor em uma VPC, de acordo com a política, nunca deva ser um destino para logon remoto. Além disso, suponha que um logon remoto tenha ocorrido neste computador devido a uma alteração incorreta na diretiva de regra do firewall. O recurso de modelagem de entidade detectará e reportará essa atividade ("Acesso remoto incomum") quase em tempo real e apontará para uma chamada específica da API do AWS CloudTrail, Azure Monitor ou GCP Stackdriver Logging API (incluindo nome do usuário, data e hora, entre outros detalhes), o que causou a alteração na regra da ITU. E então essa informação pode ser fornecida ao SIEM para análise.



Recursos semelhantes estão disponíveis para qualquer ambiente em nuvem suportado pelo Cisco Stealthwatch Cloud:



A modelagem de entidades é uma forma exclusiva de automação de segurança que pode detectar um problema anteriormente desconhecido com seu pessoal, processos ou tecnologias. Por exemplo, ele permite detectar, entre outras coisas, problemas de segurança como:

• Alguém encontrou um backdoor no software que usamos?
• Existe algum software ou dispositivo de terceiros em nossa nuvem?
• Um usuário autorizado abuse de privilégios?
• Houve um erro de configuração que permitiu acesso remoto ou outro uso inadvertido de recursos?
• Existem vazamentos de dados de nossos servidores?
• Alguém tentou se conectar conosco a partir de uma localização geográfica atípica?
• Nossa nuvem está infectada com código malicioso?

O evento IB detectado pode ser transmitido na forma de um ticket correspondente ao sistema de gerenciamento de incidentes Slack, Cisco Spark, PagerDuty e também enviado a vários SIEMs, incluindo Splunk ou ELK. Resumindo, podemos dizer que, se sua empresa usa uma estratégia de várias nuvens e não se limita a um provedor de nuvem, os recursos de monitoramento de segurança das informações descritos acima, o uso do Cisco Stealthwatch Cloud é uma boa opção para obter um conjunto unificado de recursos de monitoramento para os principais players de nuvem - Amazon , Microsoft e Google. O mais interessante é que, se você comparar os preços da Stealthwatch Cloud com licenças avançadas de monitoramento de segurança na AWS, Azure ou GCP, pode ser que a solução da Cisco seja ainda mais barata que os recursos internos das soluções Amazon, Microsoft e Google. Paradoxalmente, é. E quanto mais nuvens e seus recursos você usar, mais óbvia será a vantagem de uma solução consolidada.



Além disso, o Stealthwatch Cloud também pode monitorar nuvens privadas implantadas em sua organização, por exemplo, com base em contêineres Kubernetes ou monitorando fluxos do Netflow ou tráfego de rede recebido através do espelhamento de equipamentos de rede (mesmo produção doméstica), dados AD ou servidores DNS etc. Todos esses dados serão enriquecidos com informações de Inteligência de Ameaças coletadas pela Cisco Talos, o maior grupo não governamental de pesquisadores de ameaças de SI do mundo.



Isso permite implementar um sistema de monitoramento unificado para nuvens públicas e híbridas que sua empresa pode usar. As informações coletadas podem ser analisadas usando os recursos internos do Stealthwatch Cloud ou enviadas para o SIEM (Splunk, ELK, SumoLogic e vários outros são suportados por padrão).

Isso conclui a primeira parte do artigo em que examinei as ferramentas internas e externas para monitorar plataformas IaaS / PaaS que nos permitem detectar e responder rapidamente a incidentes nos ambientes em nuvem que nossa empresa escolheu. Na segunda parte, continuaremos o tópico e consideraremos as opções de monitoramento para plataformas SaaS usando o Salesforce e o Dropbox como exemplo, além de tentar resumir e reunir tudo, criando um sistema unificado de monitoramento de segurança das informações para diferentes provedores de nuvem.