🥇Monitoramento de segurança em nuvem

A transferência de dados e aplicativos para a nuvem representa um novo desafio para os SOCs corporativos, que nem sempre estão prontos para monitorar a infraestrutura de terceiros. De acordo com a Netskope, a empresa média nos EUA utiliza 1246 serviços de nuvem diferentes, o que representa um aumento de 22% em relação ao ano passado. 1246 serviços de nuvem!!! 175 deles se referem a serviços de RH, 170 estão relacionados ao marketing, 110 na área de comunicações e 76 em finanças e CRM. Na Cisco, utilizam 'apenas' 700 serviços de nuvem externos. Portanto, fico um pouco confuso com esses números. Mas, de qualquer forma, o problema não são eles, mas sim que as nuvens estão sendo cada vez mais adotadas por um número crescente de empresas que desejam ter as mesmas capacidades de monitoramento da infraestrutura de nuvem que possuem em sua própria rede. E essa tendência está crescendo — segundo dados do Tribunal de Contas dos Estados Unidos em 2023, planejam fechar 1200 data centers (6250 já foram fechados). Mas a transição para a nuvem não é apenas "vamos mover nossos servidores para um provedor externo". É uma nova arquitetura de TI, novo software, novos processos, novas restrições... Tudo isso traz mudanças significativas não apenas para a TI, mas também para a segurança da informação. E enquanto os provedores aprenderam a lidar de algum modo com a segurança da própria nuvem (felizmente, há muitas recomendações disponíveis), monitorar a segurança na nuvem, especialmente nas plataformas SaaS, apresenta desafios significativos, sobre os quais vamos conversar.

Suponha que sua empresa tenha migrado parte de sua infraestrutura para a nuvem... Espera. Não é bem assim. Se a infraestrutura já foi migrada e você está apenas agora pensando em como vai monitorá-la, você já perdeu. Se não for Amazon, Google ou Microsoft (e mesmo assim com ressalvas), provavelmente você não terá muitas opções para monitorar seus dados e aplicativos. É bom se você tiver acesso aos logs. Às vezes, os dados sobre eventos de segurança estarão disponíveis, mas você não terá acesso a eles. Por exemplo, no Office 365. Se você tiver a licença E1 mais barata, os eventos de segurança não estarão disponíveis para você. Com a licença E3, os dados são mantidos por apenas 90 dias e somente com a E5 a duração dos logs é estendida por um ano (embora existam nuances relacionadas à necessidade de solicitar separadamente algumas funcionalidades de log ao suporte da Microsoft). A propósito, a licença E3 é muito mais limitada em termos de funcionalidades de monitoramento do que o Exchange corporativo. Para alcançar o mesmo nível, você precisaria da licença E5 ou de uma licença adicional de Conformidade Avançada, que podem exigir dinheiro extra que não foi considerado no seu modelo financeiro de migração para infraestrutura na nuvem. E esse é apenas um exemplo da subestimação das questões relacionadas ao monitoramento da segurança na nuvem. Neste artigo, sem pretender ser exaustivo, 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. No final do artigo, haverá uma lista de verificação que deve ser cumprida antes de considerar que a questão do monitoramento da segurança na nuvem está resolvida.

Podemos destacar alguns problemas típicos que levam a incidentes em ambientes de nuvem, nos quais os serviços de segurança não conseguem reagir ou mesmo não os percebem:

Logs de segurança não existem. Esta é uma situação bastante comum, especialmente entre os novos entrantes no mercado de soluções em nuvem. Mas também não devemos descartar esses novos jogadores imediatamente. Pequenos fornecedores, especialmente os nacionais, estão mais atentos às demandas dos clientes e podem rapidamente implementar algumas funcionalidades solicitadas, alterando o roadmap aprovado para seus produtos. Sim, isso não será um equivalente ao GuardDuty da Amazon ou ao módulo de 'Proteção Proativa' da Bitrix, mas é algo.
A segurança da informação não sabe onde estão os logs ou não tem acesso a eles. Aqui é necessário iniciar negociações com o fornecedor de serviços em nuvem — talvez ele forneça essas informações se considerar o cliente significativo para si. Mas, no geral, não é muito bom quando o acesso aos logs é concedido "por decisão especial".
Às vezes, acontece que os logs estão disponíveis com o provedor de nuvem, mas eles oferecem monitoramento e registro de eventos limitados, insuficientes para detectar todos os incidentes. Por exemplo, você pode receber apenas os logs de alterações no site ou os logs de tentativas de autenticação de usuários, mas outros eventos, como tráfego de rede, podem não ser fornecidos, o que oculta uma série de eventos que caracterizam tentativas de violação de sua infraestrutura em nuvem.
Os logs existem, mas o acesso a eles é difícil de automatizar, o que obriga o monitoramento a ser feito não continuamente, mas em horários programados. E se ainda não for possível carregar os logs de forma automática, a exportação dos logs, por exemplo, em formato Excel (como fazem alguns fornecedores locais de soluções em nuvem), pode levar a uma aversão por parte do serviço corporativo de segurança da informação em lidar com eles.
Não há monitoramento dos logs. Esta talvez seja a razão mais incompreensível para a ocorrência de incidentes de segurança da informação em ambientes em nuvem. Parece que os logs existem, e o acesso a eles pode ser automatizado, mas ninguém faz isso. Por quê?

Conceito de segurança compartilhada na nuvem

A transição para a nuvem é sempre uma busca pelo equilíbrio entre o desejo de manter o controle sobre a infraestrutura e a entrega dela para as mãos mais profissionais de um provedor de nuvem, que se especializa em sua manutenção. E na área de segurança de ambientes de nuvem, esse equilíbrio também deve ser buscado. Especialmente considerando que, dependendo do modelo de serviços de nuvem utilizado (IaaS, PaaS, SaaS), esse equilíbrio estará sempre mudando. Em qualquer cenário, é importante lembrar que todos os provedores de nuvem hoje seguem o chamado modelo de responsabilidade compartilhada e segurança compartilhada. O provedor é responsável por alguns aspectos, enquanto o cliente, que armazena seus dados, aplicativos, máquinas virtuais e outros recursos na nuvem, se responsabiliza por outros. Seria imprudente supor que, ao migrarmos para a nuvem, transferiremos toda a responsabilidade para o provedor. Contudo, também não é sensato construir toda a segurança de forma independente durante essa migração para a nuvem. É necessário encontrar um equilíbrio que dependerá de vários fatores: a estratégia de gestão de riscos, o modelo de ameaças, os mecanismos de proteção disponíveis pelo provedor de nuvem, a legislação e outros.

Por exemplo, a classificação dos dados armazenados na nuvem é sempre responsabilidade do cliente. O provedor de nuvem ou o fornecedor externo pode apenas ajudar com as ferramentas que ajudarão a rotular os dados na nuvem, identificar violações, remover dados que infringem a legislação ou mascará-los de alguma forma. Por outro lado, a segurança física é sempre responsabilidade do provedor de nuvem, do qual ele não pode compartilhar com os clientes. O que está entre os dados e a infraestrutura física é precisamente o tema em discussão neste artigo. Por exemplo, a disponibilidade da nuvem é responsabilidade do provedor, enquanto a configuração de regras de segurança ou a ativação da criptografia são responsabilidade do cliente. Neste artigo, tentaremos explorar quais mecanismos de monitoramento de segurança da informação são oferecidos hoje por vários provedores de nuvem populares na Rússia, as características de sua aplicação e quando é necessário considerar soluções externas (como Cisco E-mail Security) que ampliam as capacidades da sua nuvem em termos de cibersegurança. Em vários casos, especialmente ao seguir uma estratégia de nuvem múltipla, você não terá escolha a não ser usar soluções externas de monitoramento de segurança da informação em várias plataformas de nuvem (como Cisco CloudLock ou Cisco Stealthwatch Cloud). Em alguns casos, você perceberá que o provedor de nuvem escolhido (ou imposto) não oferece nenhuma capacidade de monitoramento de segurança da informação. Isso é desagradável, mas também importante, pois permite avaliar adequadamente o nível de risco associado ao trabalho com esta nuvem.

Ciclo de Vida do Monitoramento de Segurança na Nuvem

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

confiar nas ferramentas fornecidas pelo seu provedor de nuvem,
usar soluções de terceiros que irão monitorar as plataformas IaaS, PaaS ou SaaS que você utiliza,
construir sua própria infraestrutura de monitoramento de ambientes de nuvem (somente para plataformas IaaS/PaaS).

Vamos analisar quais são as características de cada uma dessas opções. Mas primeiro, precisamos entender o esquema geral que será usado para monitorar plataformas em nuvem. Eu destacaria 6 componentes principais do processo de monitoramento de segurança em nuvem:

Preparação da infraestrutura. Definição das aplicações e infraestrutura necessárias para coletar eventos relevantes para a segurança, armazenando-os.
Coleta. Nesta fase, eventos de segurança são agregados a partir de várias fontes para posterior transmissão para processamento, armazenamento e análise.
Processamento. Neste estágio, os dados são transformados e enriquecidos para facilitar a análise subsequente.
Armazenamento. Este componente é responsável pelo armazenamento a curto e longo prazo dos dados processados e 'brutos' coletados.
Análise. Neste ponto, você tem a oportunidade de detectar incidentes e responder a eles de forma automática ou manual.
Relatórios. Esta etapa ajuda a formar indicadores-chave para as partes interessadas (gestores, auditores, provedores de nuvem, clientes, etc.), que nos ajudam a tomar certas decisões, como mudar de provedor ou reforçar a segurança.

Compreender esses componentes permitirá que você determine rapidamente o que pode obter do seu provedor e o que precisará fazer por conta própria ou com a ajuda de consultores externos.

Recursos integrados dos serviços em nuvem

Já mencionei anteriormente que muitos serviços em nuvem hoje não oferecem qualquer possibilidade de monitoramento de segurança da informação (SI). Na verdade, eles não dão muita atenção ao tema da SI. Por exemplo, um dos populares serviços russos para o envio de relatórios a órgãos governamentais pela Internet (não mencionarei o nome). Toda a seção sobre segurança deste serviço gira em torno do uso de Sistemas de Criptografia com Hardware Certificado (SKZI). A seção sobre SI de outro serviço doméstico de nuvem para troca eletrônica de documentos é muito mais abrangente. Nela, fala-se sobre certificados de chave pública, criptografia certificada, eliminação de vulnerabilidades web, proteção contra ataques DDoS, uso de MCE, backups e até a realização regular de auditorias de SI. Mas não há uma palavra sobre monitoramento, nem sobre a possibilidade de acesso a eventos de SI que possam ser de interesse para os clientes deste prestador de serviços.

De fato, pela maneira como o provedor de nuvem descreve em seu site e na documentação as questões de SI, pode-se entender o quanto ele realmente leva a sério essa questão. Por exemplo, se você ler os manuais dos produtos "Meu Escritório", verá que não há uma palavra sobre segurança, e na documentação de um produto específico "Meu Escritório. KS3", destinado à proteção contra acesso não autorizado, há apenas uma enumeração dos pontos do 17º decreto do FSTEK que o "Meu Escritório.KS3" cumpre, mas não é descrito como o faz e, o mais importante, como integrar esses mecanismos com a SI corporativa. Talvez essa documentação exista, mas não a encontrei publicamente no site "Meu Escritório". Embora talvez eu apenas não tenha acesso a essas informações secretas?

A situação na mesma plataforma Bitrix é muito melhor. A documentação descreve os formatos dos logs de eventos e, curiosamente, o log de intrusões, que contém eventos associados a potenciais ameaças para a plataforma em nuvem. E a partir daí, você pode extrair o IP, o nome do usuário ou visitante, a fonte do evento, o horário, o User Agent, o tipo de evento, etc. Na verdade, você pode trabalhar com esses eventos ou através do painel de controle da própria nuvem, ou exportar os dados em formato MS Excel. Automatizar o trabalho com os logs do Bitrix atualmente é complicado e você terá que realizar uma parte do trabalho manualmente (exportando o relatório e carregando-o no seu SIEM). Mas se lembrarmos que não faz muito tempo não havia essa possibilidade, isso é um grande progresso. Além disso, gostaria de ressaltar que muitos provedores de nuvem estrangeiros também oferecem funcionalidades semelhantes "para iniciantes" — ou você vê os logs visualmente através do painel de controle, ou exporta os dados para si (embora a maioria exporte os dados em formato .csv, e não Excel).

Se não considerarmos o caso da ausência de logs, os provedores de nuvem geralmente oferecem três opções para monitorar eventos de segurança — painéis de controle, exportação de dados e acesso via API. A primeira solução parece resolver muitos problemas, mas não é bem assim: quando há vários logs, é necessário alternar entre as telas que os exibem, perdendo a visão geral. Além disso, é improvável que o provedor de nuvem ofereça a você a capacidade de correlacionar eventos de segurança e de analisá-los sob a ótica da segurança (geralmente você está lidando com dados brutos, que você precisa entender por conta própria). Existem exceções e falaremos sobre elas a seguir. Por fim, é importante indagar quais eventos seu provedor de nuvem registra, em qual formato e quão adequados eles são ao seu processo de monitoramento de segurança da informação? Por exemplo, a identificação e autenticação de usuários e visitantes. O mesmo Bitrix permite que você registre, a partir desses dados de eventos, a data e hora do evento, o nome do usuário ou visitante (caso o módulo “Web Analytics” esteja disponível), o objeto ao qual foi feito o acesso e outros elementos típicos de um site. Contudo, serviços corporativos de segurança da informação podem necessitar de informações sobre se o acesso foi feito a partir de um dispositivo confiável (por exemplo, em uma rede corporativa, essa tarefa é realizada pelo Cisco ISE). E uma tarefa tão simples quanto a função de geo-IP, que ajuda a determinar se a conta de um usuário do serviço em nuvem foi comprometida? E mesmo que o provedor de nuvem a forneça, isso pode não ser suficiente. O mesmo Cisco CloudLock não apenas analisa a geolocalização, mas usa aprendizado de máquina para analisar dados históricos de cada usuário e rastrear várias anomalias em tentativas de identificação e autenticação. Um funcionalidade semelhante existe apenas no MS Azure (com a assinatura correspondente).

Há uma dificuldade adicional — como para muitos provedores de nuvem, a monitoração de segurança da informação é um tema novo com o qual eles estão apenas começando a lidar, eles estão constantemente mudando suas soluções. Hoje eles têm uma versão da API, amanhã outra, e depois de amanhã uma terceira. É preciso estar preparado para isso. O mesmo se aplica à funcionalidade, que pode variar e deve ser considerada no seu sistema de monitoramento de segurança da informação. Por exemplo, a Amazon inicialmente tinha serviços separados para a monitoração de eventos na nuvem — AWS CloudTrail e AWS CloudWatch. Depois, surgiu um serviço separado especificamente para a monitoração de eventos de segurança da informação — AWS GuardDuty. Algum tempo depois, a Amazon lançou um novo sistema de gestão, o Amazon Security Hub, que inclui a análise de dados obtidos a partir do GuardDuty, Amazon Inspector, Amazon Macie e outros. Outro exemplo — a ferramenta de integração de logs do Azure com SIEM — AzLog. Muitos fornecedores de SIEM o utilizavam ativamente, até que em 2018 a Microsoft anunciou a interrupção do seu desenvolvimento e suporte, o que deixou muitos clientes que utilizavam essa ferramenta diante de um problema (como isso foi resolvido, falaremos a seguir).

Por isso, acompanhe atentamente todas as funções de monitoramento que seu provedor de nuvem oferece. 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, isso custará mais (embora nem sempre), mas assim você delega toda a responsabilidade a terceiros. Ou será que não?... Vamos lembrar do conceito de segurança compartilhada e entender que não conseguimos transferir tudo — teremos que nos aprofundar em como diferentes provedores de nuvem garantem a monitoração de segurança da informação de seus dados, aplicativos, máquinas virtuais e outros recursos hospedados na nuvem. E começaremos com o que a Amazon oferece nessa parte.

Exemplo: Monitoramento de segurança da informação em IaaS baseado em AWS

Sim, eu entendo que a Amazon não é o melhor exemplo, uma vez que é um serviço americano e pode ser bloqueado na luta contra o extremismo e a disseminação de informações proibidas na Rússia. No entanto, nesta publicação, gostaria de mostrar como as diferentes plataformas de nuvem diferem em suas capacidades de monitoramento de segurança da informação e o que deve ser considerado ao transferir seus processos críticos para a nuvem em termos de segurança. E se alguns desenvolvedores de soluções em nuvem russas puderem extrair algo útil disso, isso será ótimo.

Primeiro, é importante dizer que a Amazon não é uma fortaleza impenetrável. Seus clientes frequentemente enfrentam diversos incidentes. Por exemplo, a Deep Root Analytics teve os nomes, endereços, datas de nascimento e telefones de 198 milhões de eleitores roubados. A empresa israelense Nice Systems teve 14 milhões de registros de assinantes da Verizon comprometidos. Nesse contexto, as capacidades embutidas da AWS permitem que você detecte uma ampla variedade de incidentes. Por exemplo:

ataques à infraestrutura (DDoS)
comprometimento de nós (injeção de comandos)
comprometimento de contas e acesso não autorizado
configuração incorreta e vulnerabilidades
interfaces e APIs não protegidos.

Essa discrepância se deve ao fato de que a segurança dos dados do cliente, como descobrimos acima, é responsabilidade do próprio cliente. E se ele não se preocupou em ativar mecanismos de proteção e não habilitou ferramentas de monitoramento, ele só tomará conhecimento do incidente pelos meios de comunicação ou por seus clientes.

Para identificar incidentes, pode-se usar uma ampla gama de serviços de monitoramento desenvolvidos pela Amazon (embora muitas vezes eles sejam complementados por ferramentas externas, como o osquery). Assim, na AWS, todas as ações dos usuários 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 de atividades de cada conta AWS (incluindo nome de usuário, ação, serviço, parâmetros de atividade e seu resultado) e o uso da API estão disponíveis através do serviço AWS CloudTrail. Você pode visualizar esses eventos (por exemplo, login no console AWS IAM) a partir do console CloudTrail, analisá-los com o Amazon Athena ou encaminhá-los para soluções externas, como Splunk, AlienVault, etc. Os próprios logs do AWS CloudTrail são armazenados no seu bucket AWS S3.

Dois outros serviços da AWS oferecem um conjunto adicional de funcionalidades importantes para monitoramento. Primeiro, o Amazon CloudWatch — é um serviço de monitoramento de recursos e aplicações da AWS, que permite, entre outras coisas, identificar várias anomalias em sua nuvem. Todos os serviços integrados da AWS, como Amazon Elastic Compute Cloud (servidores), Amazon Relational Database Service (bancos de dados), Amazon Elastic MapReduce (análise de dados) e mais 30 outros serviços da Amazon, utilizam o Amazon CloudWatch para armazenar seus logs. Os desenvolvedores podem usar a API aberta do Amazon CloudWatch para adicionar a funcionalidade de monitoramento de logs a aplicações e serviços personalizados, ampliando assim o espectro 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 por seus servidores AWS (externamente ou internamente), bem como entre microsserviços. Quando qualquer um dos seus recursos da AWS VPC interage com a rede, o serviço VPC Flow Logs registra informações sobre o tráfego de rede, incluindo a interface de rede de origem e destino, assim como endereços IP, portas, protocolo, número de bytes e quantidade de pacotes que você viu. Aqueles que têm experiência em segurança de rede local reconhecerão isso como o equivalente aos fluxos. NetFlow, que podem ser gerados por switches, roteadores e firewalls corporativos. Esses logs são importantes para fins de monitoramento de segurança da informação, pois, ao contrário dos eventos relacionados a ações de usuários e aplicações, também permitem capturar a interação de rede em um ambiente de nuvem privada virtual AWS.

Assim, esses três serviços da AWS — AWS CloudTrail, Amazon CloudWatch e VPC Flow Logs — juntos oferecem uma visão bastante eficaz sobre o uso da sua conta, o comportamento dos usuários, a gestão da infraestrutura, a atividade de aplicações e serviços, e também a atividade de rede. Por exemplo, com eles é possível detectar as seguintes anomalias:

Tentativas de escaneamento do site, busca por backdoors, procura de vulnerabilidades através de picos de “erros 404”.
Ataques de injeção (por exemplo, injeção SQL) através de picos de “erros 500”.
Ferramentas conhecidas para ataques como sqlmap, nikto, w3af, nmap, etc., através da análise do campo User Agent.

A Amazon Web Services para fins de cibersegurança também desenvolveu outros serviços que permitem resolver muitas outras tarefas. Por exemplo, na AWS, existe um serviço embutido para auditoria de políticas e configurações — AWS Config. Este serviço proporciona uma auditoria contínua dos seus recursos AWS e suas configurações. Vejamos um exemplo simples: suponha que você deseja garantir que as senhas dos usuários estejam desativadas em todos os seus servidores e que o acesso seja possível apenas com base em certificados. O AWS Config permite verificar isso facilmente para todos os seus servidores. Existem outras políticas que podem ser aplicadas aos seus servidores em nuvem: "Nenhum servidor pode usar a porta 22", "Apenas administradores podem alterar as regras do firewall" ou "Apenas o usuário Ivashko pode criar novas contas de usuário, e ele só pode fazer isso às terças-feiras". No verão de 2016, o serviço AWS Config foi expandido para automatizar a detecção de violações das políticas estabelecidas. As AWS Config Rules são, essencialmente, consultas de configuração contínuas dos serviços Amazon que você utiliza, que geram eventos caso haja uma violação das políticas correspondentes. Por exemplo, em vez de realizar consultas periódicas no AWS Config para verificar se todos os discos do servidor virtual estão criptografados, é possível usar as AWS Config Rules para verificar continuamente os discos do servidor quanto ao cumprimento dessa condição. E, o mais importante, no contexto desta publicação, quaisquer violações geram eventos que podem ser analisados pelo seu serviço de segurança da informação.

Na AWS, também existem equivalentes tradicionais para soluções corporativas em segurança da informação, que geram eventos de segurança que você pode e deve analisar:

detecção de intrusões — AWS GuardDuty
controle de vazamento de informações — AWS Macie
EDR (embora falar sobre dispositivos finais na nuvem seja um pouco estranho) — AWS Cloudwatch + soluções open source osquery ou GRR
análise de Netflow — AWS Cloudwatch + AWS VPC Flow
análise de DNS — AWS Cloudwatch + AWS Route53
AD — AWS Directory Service
gestão de contas — AWS IAM
SSO — AWS SSO
análise de segurança — AWS Inspector
gestão de configurações — AWS Config
WAF — AWS WAF.

Não vou detalhar todos os serviços da Amazon que podem ser úteis no contexto da 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, utilizando tanto as capacidades internas da própria Amazon quanto soluções externas, como SIEM, que podem coletar eventos de segurança no seu centro de monitoramento e analisá-los junto com eventos de outros serviços em nuvem ou da infraestrutura interna, do perímetro ou de dispositivos móveis.

De qualquer forma, tudo começa com as fontes de dados que fornecem os eventos de Segurança da Informação. Entre essas fontes, podemos incluir:

CloudTrail — uso de API e ações dos usuários
Trusted Advisor — verificação de segurança em conformidade com as melhores práticas
Config — inventário e configuração de contas e configurações de serviços
VPC Flow Logs — conexões com interfaces virtuais
IAM — serviço de identificação e autenticação
ELB Access Logs — logs do balanceador de carga
Inspector — vulnerabilidades em aplicativos
S3 — armazenamento de arquivos
CloudWatch — atividade dos aplicativos
SNS — serviço de notificações.

A Amazon, oferecendo essa gama de fontes de eventos e ferramentas para sua geração, está bastante limitada nas possibilidades de análise dos dados coletados no contexto da Segurança da Informação. Você terá que estudar os logs disponíveis, buscando os indicadores de comprometimento relevantes. O AWS Security Hub, que a Amazon lançou recentemente, pretende resolver esse problema, funcionando como uma espécie de SIEM em nuvem para a AWS. Mas, por enquanto, ele ainda está em seus estágios iniciais e é limitado tanto no número de fontes com as quais trabalha quanto nas outras restrições impostas pela arquitetura e pelos planos da própria Amazon.

Exemplo: Monitoramento de Segurança da Informação em IaaS baseado em Azure

Não quero entrar em uma longa polêmica sobre qual dos três provedores de nuvem (Amazon, Microsoft ou Google) é o melhor (especialmente porque cada um deles tem suas peculiaridades e se adapta a diferentes necessidades); vamos nos concentrar nas capacidades de monitoramento de segurança da informação que esses players oferecem. É preciso reconhecer que a Amazon AWS foi uma das pioneiras nesse segmento e, por isso, avançou mais em termos de funcionalidades de segurança da informação (embora muitos reconheçam que utilizá-las pode ser complicado). Mas isso não significa que vamos ignorar as oportunidades que a Microsoft e o Google nos proporcionam.

A linha de produtos da Microsoft sempre se destacou por sua 'abertura', e no Azure a situação é semelhante. Por exemplo, enquanto a AWS e o GCP sempre partem do conceito de 'tudo o que não é permitido, é proibido', o Azure tem uma abordagem totalmente oposta. Ao criar uma rede virtual na nuvem e uma máquina virtual nela, todas as portas e protocolos estão abertos e permitidos por padrão. Portanto, você terá que dedicar um pouco mais de esforço para a configuração inicial do sistema de controle de acesso na nuvem da Microsoft. Isso também impõe требования mais rígidas em relação ao monitoramento da atividade na nuvem Azure.

O AWS tem uma característica relacionada ao monitoramento de seus recursos virtuais: se eles estão em diferentes regiões, surgem dificuldades em agrupar todos os eventos e analisá-los de forma unificada. Para resolver isso, é necessário recorrer a diversas artimanhas, como a criação de um código próprio para o AWS Lambda que transfira eventos entre regiões. No Azure, esse problema não existe — seu mecanismo de Activity Log monitora toda a atividade em toda a organização sem restrições. O mesmo se aplica ao AWS Security Hub, que foi recentemente desenvolvido pela Amazon para consolidar várias funções de segurança em um único centro de segurança, mas apenas dentro de sua própria região, o que, na verdade, não é relevante para a Rússia. O Azure possui seu próprio Security Center, que não tem restrições regionais, oferecendo acesso a todas as funções de segurança da plataforma de nuvem. Além disso, para diferentes equipes locais, ele pode fornecer seu próprio conjunto de recursos de proteção, incluindo eventos de segurança gerenciados. O AWS Security Hub ainda está em busca de se tornar semelhante ao Azure Security Center. Porém, é importante mencionar uma desvantagem: você pode extrair muito do Azure a partir do que foi descrito anteriormente no AWS, mas isso é feito de forma mais conveniente apenas para Azure AD, Azure Monitor e Azure Security Center. Todos os outros mecanismos de proteção do Azure, incluindo a análise de eventos de segurança, ainda são geridos de uma maneira nem tão conveniente. Parte do problema é abordado por meio de um API que permeia todos os serviços do Microsoft Azure, mas isso demandará esforços adicionais para integrar sua nuvem com seu SOC e a presença de profissionais qualificados (como ocorre com qualquer outro SIEM que trabalhe com APIs de nuvem). Alguns SIEM, dos quais falaremos a seguir, já suportam o Azure e podem automatizar a tarefa de monitoramento, mas também apresentam suas próprias complexidades — nem todos conseguem coletar todos os logs disponíveis no Azure.

A coleta e monitoramento de eventos no Azure são fornecidos pelo serviço Azure Monitor, que é a principal ferramenta de coleta, armazenamento e análise de dados na nuvem da Microsoft e em 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, coletadas em tempo real e que descrevem os principais indicadores de desempenho da nuvem Azure, e logs, que contêm dados organizados em entradas refletindo determinados aspectos do funcionamento dos recursos e serviços do Azure. Além disso, por meio da API Data Collector, o serviço Azure Monitor 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 e que podem ser acessadas através do Azure Portal, CLI, PowerShell ou REST API (algumas apenas através da Azure Monitor / Insight API):

Logs de Atividade - este log responde a perguntas clássicas de “quem”, “o que” e “quando” em relação a qualquer operação de gravação (PUT, POST, DELETE) sobre recursos em nuvem. Eventos relacionados ao acesso de leitura (GET) não são registrados neste log, assim como uma série de outros.
Logs de Diagnóstico - contém dados sobre operações com determinados recursos que fazem parte da sua assinatura.
Relatórios do Azure AD - contém tanto a atividade do usuário quanto a atividade do sistema relacionada à gestão de grupos e usuários.
Log de Eventos do Windows e Syslog do Linux - contém eventos de máquinas virtuais hospedadas na nuvem.
Métricas - contém telemetria sobre o desempenho e a “saúde” dos seus serviços e recursos em nuvem. Medido a cada minuto e armazenado por 30 dias.
Logs de Fluxo do Grupo de Segurança de Rede - contém dados sobre eventos de segurança da rede, coletados com o serviço Network Watcher e monitoramento de recursos no nível da rede.
Logs de Armazenamento - contém eventos relacionados ao acesso a repositórios.

Para monitoramento, você pode usar SIEM externos ou o Azure Monitor integrado e suas extensões. Vamos falar mais sobre sistemas de gerenciamento de eventos de segurança, mas, por enquanto, vamos ver o que o Azure oferece para a análise de dados no contexto de segurança. A tela principal para tudo relacionado à segurança no Azure Monitor é o Log Analytics Security and Audit Dashboard (a versão gratuita suporta armazenamento de um volume limitado de eventos por apenas uma semana). Este painel é dividido em 5 áreas principais, visualizando estatísticas resumidas sobre o que está acontecendo no seu ambiente em nuvem:

Domínios de Segurança — indicadores quantitativos chave relacionados à segurança, como o número de incidentes, número de nós comprometidos, nós não corrigidos, eventos de segurança de rede, etc.
Problemas Notáveis — exibe o número e a importância dos problemas ativos de segurança
Detecções — mostra os padrões de ataques utilizados contra você
Inteligência de Ameaças — exibe informações geográficas sobre nós externos que estão atacando você
Consultas de segurança comuns — consultas típicas que ajudarão você a monitorar melhor sua segurança.

Como extensões do Azure Monitor, podemos citar o Azure Key Vault (proteção de chaves criptográficas na nuvem), Malware Assessment (análise da proteção contra malware em máquinas virtuais), Azure Application Gateway Analytics (análise, entre outras, dos logs de firewall de nuvem) e assim por diante. Esses instrumentos, enriquecidos com regras específicas de processamento de eventos, permitem visualizar vários aspectos da atividade dos serviços em nuvem, incluindo segurança, e identificar desvios em seu funcionamento. Entretanto, como muitas vezes acontece, qualquer funcionalidade adicional requer uma assinatura paga correspondente, o que exigirá de você investimentos financeiros que precisam ser planejados com antecedência.

A Azure possui uma série de recursos integrados de monitoramento de ameaças, que estão integrados ao Azure AD, ao Azure Monitor e ao Azure Security Center. Esses recursos incluem, por exemplo, a detecção de interações de máquinas virtuais com endereços IP maliciosos conhecidos (graças à integração com os serviços de Threat Intelligence da Microsoft), a detecção de malware na infraestrutura de nuvem através da recepção de alertas de máquinas virtuais hospedadas na nuvem, ataques de força bruta em máquinas virtuais, vulnerabilidades na configuração do sistema de identificação de usuários, acessos a partir de anonimizadores ou nós comprometidos, vazamentos de contas, acessos de locais incomuns etc. Atualmente, a Azure é um dos poucos provedores de nuvem que oferece recursos de Threat Intelligence integrados para enriquecer os eventos de segurança coletados.

Como já mencionado anteriormente, a funcionalidade de proteção e, como consequência, os eventos de segurança gerados, não estão disponíveis igualmente para todos os usuários, exigindo uma assinatura específica que inclua os recursos necessários, os quais geram os eventos correspondentes para o monitoramento de segurança. Por exemplo, parte das funcionalidades descritas no parágrafo anterior para monitoramento de anomalias em contas está disponível apenas na licença premium P2 para o serviço Azure AD. Sem ela, assim como no caso da AWS, você 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 estarão disponíveis para análise.

No portal do Azure, você pode gerenciar tanto as consultas para os logs de registro de seu interesse quanto configurar painéis para visualizar os principais indicadores de segurança. Além disso, lá você pode escolher extensões do Azure Monitor que permitem expandir a funcionalidade dos logs do Azure Monitor e obter uma análise mais detalhada dos eventos sob a perspectiva de segurança.

Se você precisa não apenas da capacidade de trabalhar com logs, mas de um centro de segurança abrangente para a sua plataforma de nuvem Azure, incluindo a gestão de políticas de segurança da informação, é necessário considerar a utilização do Azure Security Center, cujas funcionalidades mais úteis estão disponíveis por um custo adicional, como detecção de ameaças, monitoramento fora do Azure, avaliação de conformidade, entre outros (na versão gratuita, você tem acesso apenas à avaliação de segurança e recomendações para resolver problemas identificados). Ele consolida todas as questões de segurança em um só lugar. De fato, pode-se falar de um nível de segurança da informação superior ao que o Azure Monitor oferece, pois, nesse caso, os dados coletados em toda a sua infraestrutura de nuvem são enriquecidos com várias 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), aplicando-se diversos algoritmos avançados de aprendizado de máquina e análise comportamental, o que, em última instância, deve aumentar a eficácia na detecção e resposta a ameaças.

A Azure também possui seu próprio SIEM — que foi lançado no início de 2019. É o Azure Sentinel, que se baseia em dados do Azure Monitor e também pode se integrar a soluções externas de segurança (como NGFW ou WAF), cuja lista está em constante crescimento. Além disso, por meio da integração do Microsoft Graph Security API, você pode conectar seus próprios feeds de Threat Intelligence ao Sentinel, enriquecendo as capacidades de análise de incidentes em sua nuvem Azure. Pode-se afirmar que o Azure Sentinel é o primeiro SIEM ‘nativo’ a surgir entre os provedores de nuvem (o mesmo Splunk ou ELK, que podem ser hospedados na nuvem, por exemplo, AWS, foram, de fato, desenvolvidos por fornecedores de serviços de nuvem tradicionais). O Azure Sentinel e o Security Center poderiam ser considerados SOCs para a nuvem Azure, e poderiam ser usados como tal (com algumas ressalvas) se você não tivesse mais nenhuma infraestrutura e tivesse movido todos os seus recursos computacionais para a nuvem Microsoft Azure.

No entanto, como as capacidades integradas do Azure (mesmo com uma assinatura do Sentinel) muitas vezes são insuficientes para fins de monitoramento de segurança da informação e integração desse processo com outras fontes de eventos de segurança (tanto na nuvem quanto internas), surge a necessidade de exportar os dados coletados para sistemas externos, que podem incluir SIEM. Isso é feito tanto por meio de APIs quanto por meio de extensões específicas, que atualmente estão disponíveis apenas para os seguintes SIEM: Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight e ELK. Não faz muito tempo, havia mais SIEM, mas desde 1º de junho de 2019, a Microsoft descontinuou o suporte para o Azure Log Integration Tool (AzLog), que, no início da existência do Azure e na ausência de uma padronização adequada para o trabalho com logs (o Azure Monitor ainda nem existia), permitia integrar facilmente SIEM externos com a nuvem da Microsoft. A situação mudou agora, e a Microsoft recomenda a plataforma Azure Event Hub como a principal ferramenta de integração para outros SIEM. Muitos já realizaram essa integração, mas fiquem atentos — eles podem não capturar todos os logs do Azure, mas apenas alguns (consulte a documentação do seu SIEM).

Ao concluir uma breve introdução ao Azure, gostaria de dar uma recomendação geral sobre este serviço em nuvem: antes de afirmar qualquer coisa sobre as funções de monitoramento de segurança da informação (IB) no Azure, é essencial configurá-las cuidadosamente e testar se funcionam conforme descrito na documentação e conforme lhe foi explicado pelos consultores da Microsoft (pois eles podem ter diferentes visões sobre a funcionalidade dos recursos do Azure). Com recursos financeiros adequados, é possível extrair muito valor do Azure em termos de monitoramento de IB. No entanto, se seus recursos forem limitados, assim como no caso da AWS, você terá que contar apenas com suas próprias forças e com os dados brutos fornecidos pelo Azure Monitor. E lembre-se de que muitas funções de monitoramento têm custos associados, sendo melhor se familiarizar com a política de preços com antecedência. Por exemplo, você pode armazenar dados gratuitamente por até 31 dias com um volume máximo de 5 GB por cliente — exceder esses limites fará com que você precise desembolsar um valor adicional (cerca de 2 dólares ou mais por cada GB adicional por cliente e 0,1 dólar por 1 GB a cada mês adicional). Trabalhar com telemetria de aplicativos e métricas também pode exigir recursos financeiros adicionais, assim como o gerenciamento de alertas e notificações (um limite inicial gratuito está disponível, que pode não ser suficiente para suas necessidades).

Exemplo: Monitoramento de IB em IaaS na Google Cloud Platform

A Google Cloud Platform, em comparação com a AWS e o Azure, parece ser relativamente nova, mas isso é, em parte, positivo. Ao contrário da AWS, que expandiu suas capacidades, incluindo as de segurança, de maneira gradual, enfrentando problemas de centralização; a GCP, assim como o Azure, é muito mais bem gerenciada de forma centralizada, o que reduz o número de erros e o tempo de implantação nas empresas. Em termos de segurança, a GCP está, curiosamente, posicionada entre a AWS e o Azure. Ela também possui um sistema unificado de registro de eventos para toda a organização, mas é incompleto. Algumas funções ainda estão em modo beta, mas esse problema deve ser resolvido gradualmente, tornando a GCP uma plataforma mais madura em termos de monitoramento de IB.

A principal ferramenta para registro de eventos no GCP é o Stackdriver Logging (equivalente ao Azure Monitor), que permite coletar eventos em toda a sua infraestrutura de nuvem (inclusive da AWS). Do ponto de vista de segurança, no GCP, cada organização, projeto ou pasta possui quatro registros de log:

Admin Activity — contém todos os eventos relacionados ao acesso administrativo, como criação de máquinas virtuais, alteração de permissões etc. Este log é sempre gravado, independentemente da sua vontade, e armazena os dados por 400 dias.
Data Access — contém todos os eventos relacionados ao trabalho com dados por usuários da nuvem (criação, modificação, leitura etc.). Por padrão, este log não é gravado, pois seu volume aumenta rapidamente. Por essa razão, seu período de retenção é de apenas 30 dias. Além disso, nem todos os eventos são registrados. Por exemplo, eventos relacionados a recursos publicamente acessíveis a todos os usuários ou que estão disponíveis sem login no GCP não são registrados.
System Event — contém eventos do sistema que não estão relacionados a usuários, ou ações de um administrador que altera a configuração dos recursos da nuvem. Este log é sempre gravado e armazenado por 400 dias.
Access Transparency — é um exemplo único de log que registra todas as ações dos funcionários do Google (mas ainda não para todos os serviços do GCP), que acessam sua infraestrutura no âmbito de suas responsabilidades de trabalho. Este log é retido por 400 dias e não está disponível para todos os clientes do GCP, mas apenas sob certas condições (ou suporte de nível Gold ou Platinum, ou a presença de quatro funções de um determinado tipo no âmbito do suporte corporativo). Uma função semelhante também está disponível, por exemplo, no Office 365 — Lockbox.

Exemplo de log: Access Transparency

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

O acesso aos logs especificados pode ser feito de várias maneiras (de forma semelhante ao que foi anteriormente discutido sobre Azure e AWS) — através da interface Log Viewer, via API, através do Google Cloud SDK ou pela página de Atividades do seu projeto relacionado aos eventos de interesse. Da mesma forma, eles também podem ser exportados para soluções externas para análise adicional. Isso é feito através da exportação de logs para o BigQuery ou Cloud Pub/Sub.

Além do Stackdriver Logging, a plataforma GCP oferece a funcionalidade Stackdriver Monitoring, que permite monitorar métricas-chave (desempenho, tempo até falha, estado geral etc.) de serviços e aplicativos em nuvem. Dados processados de forma especial e visualizados podem facilitar a identificação de problemas em sua infraestrutura em nuvem, inclusive no contexto de segurança. Mas vale destacar que essa funcionalidade não é muito rica no que diz respeito à segurança da informação, já que atualmente a GCP não possui uma alternativa ao AWS GuardDuty e não consegue destacar entre todos os eventos registrados os de natureza negativa (o Google desenvolveu o Event Threat Detection, mas ainda está em versão beta e é cedo para falar sobre sua utilidade). O Stackdriver Monitoring poderia ser utilizado como um sistema de detecção de anomalias, que seriam investigadas para determinar suas causas. Porém, diante da escassez de profissionais qualificados em segurança da informação no mercado, essa tarefa atualmente parece difícil.

Também é importante mencionar alguns módulos relacionados à segurança da informação que podem ser aplicados em sua nuvem GCP, semelhantes ao que a AWS oferece:

O Cloud Security Command Center é o equivalente ao AWS Security Hub e ao Azure Security Center.
Cloud DLP — detecção e edição automáticas (por exemplo, mascaramento) de dados armazenados na nuvem, com base em mais de 90 políticas de classificação pré-configuradas.
Cloud Scanner — scanner de vulnerabilidades conhecidas (XSS, Flash Injection, bibliotecas não corrigidas, etc.) no App Engine, Compute Engine e Google Kubernetes.
Cloud IAM — gerenciamento de acesso a todos os recursos do GCP.
Cloud Identity — gerenciamento de contas de usuários, dispositivos e aplicativos do GCP a partir de uma única console.
Cloud HSM — proteção de chaves criptográficas.
Cloud Key Management Service — gerenciamento de chaves criptográficas no GCP.
VPC Service Control — criação de um perímetro seguro em torno dos seus recursos do GCP para protegê-los contra vazamentos.
Titan Security Key — proteção contra phishing.

Módulos como esses geram muitos eventos de segurança que podem ser enviados para o armazenamento BigQuery para análise ou exportação para outros sistemas, incluindo SIEM. Como mencionado anteriormente, o GCP é uma plataforma em constante desenvolvimento e o Google está atualmente trabalhando em uma série de novos módulos de segurança para sua plataforma. Dentre eles, o Event Threat Detection (atualmente disponível em beta), que escaneia os logs do Stackdriver em busca de sinais de atividade não autorizada (semelhante ao GuardDuty na AWS), e o Policy Intelligence (disponível em alfa), que permitirá a criação de políticas de acesso inteligente aos recursos do GCP.

Eu fiz uma pequena análise das capacidades integradas de monitoramento nas plataformas de nuvem populares. Mas você tem especialistas que consigam trabalhar com os logs 'brutos' do provedor IaaS (nem todos estão dispostos a comprar recursos avançados da AWS, Azure ou Google)? Além disso, muitos conhecem o ditado 'confie, mas verifique', que se aplica à segurança como nunca antes. Até que ponto você confia nas capacidades integradas do provedor de nuvem que lhe envia eventos de segurança? Até que ponto eles realmente focam em segurança?

Às vezes, vale a pena considerar soluções sobrepostas para monitoramento de infraestruturas em nuvem, que podem complementar a segurança interna da nuvem, e em certos casos, essas soluções são a única forma de obter informações sobre a segurança de seus dados e aplicativos hospedados na nuvem. Além disso, são mais convenientes, pois assumem todas as tarefas de análise dos logs necessários, gerados por diferentes serviços em nuvem de diversos provedores de nuvem. Um exemplo de tal solução sobreposta é o Cisco Stealthwatch Cloud, que se concentra em uma única tarefa — monitoramento de anomalias de segurança da informação em ambientes de nuvem, incluindo não apenas Amazon AWS, Microsoft Azure e Google Cloud Platform, mas também nuvens privadas.

Exemplo: Monitoramento de Segurança da Informação com Stealthwatch Cloud

A AWS oferece uma plataforma flexível para computação, mas essa flexibilidade leva a um maior risco de as empresas cometerem erros que resultam em problemas de segurança. E o modelo compartilhado de segurança da informação apenas contribui para isso. Executar na nuvem softwares com vulnerabilidades desconhecidas (com as conhecidas, pode-se usar, por exemplo, AWS Inspector ou GCP Cloud Scanner), senhas fracas, configurações incorretas, insiders, etc. E tudo isso reflete-se no comportamento dos recursos em nuvem, que podem ser monitorados pelo Cisco Stealthwatch Cloud, um sistema de monitoramento de segurança da informação e detecção de ataques em nuvens públicas e privadas.

Uma das principais características do Cisco Stealthwatch Cloud é a capacidade de modelar entidades. Com ele, você pode criar um modelo de software (ou seja, uma simulação praticamente em tempo real) de cada um dos seus recursos em nuvem (não importa se é AWS, Azure, GCP ou outro). Isso pode incluir servidores e usuários, bem como tipos de recursos específicos do seu ambiente em nuvem, como grupos de segurança e grupos de autoescalonamento de serviços (auto-scale). Esses modelos usam como entrada fluxos de dados estruturados fornecidos pelos serviços em nuvem. Por exemplo, para AWS, isso incluirá VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda e AWS IAM. A modelagem de entidades detecta automaticamente o papel e o comportamento de qualquer um dos seus recursos (podendo-se falar sobre o perfilamento de toda a atividade em nuvem). Entre esses papéis estão um dispositivo móvel Android ou Apple, um servidor Citrix PVS, um servidor RDP, um gateway de e-mail, um cliente VoIP, um servidor terminal, um controlador de domínio, e assim por diante. Ele então monitora continuamente seu comportamento para determinar quando ocorre um comportamento arriscado ou que ameaça a segurança. Você pode identificar tentativas de força bruta, ataques DDoS, vazamento de dados, acesso remoto não autorizado, atividades de malware, varredura de vulnerabilidades e outras ameaças. Por exemplo, aqui está como aparece a detecção de uma tentativa de acesso remoto de um país atípico para sua organização (Coreia do Sul) a um cluster Kubernetes via SSH:

E aqui está como aparece um suposto vazamento de informações de um banco de dados Postgress para um país com o qual não houve interação anterior:

Finalmente, aqui está como aparece um número excessivo de tentativas de acesso malsucedidas via SSH da China e da Indonésia a partir de um dispositivo remoto externo:

Ou, suponha que uma instância de servidor em uma VPC, de acordo com a política, nunca deve ser um ponto de destino para acesso remoto ao sistema. Suponha ainda que esse computador sofreu um acesso remoto devido a uma alteração indevida na política de regras do firewall. A função de modelagem de entidades irá detectar e relatar essa atividade ('Acesso remoto incomum') em quase tempo real e indicará a chamada específica da API AWS CloudTrail, Azure Monitor ou GCP Stackdriver Logging (incluindo nome de usuário, data e hora, entre outros detalhes), que provocou a alteração na regra do firewall. E, em seguida, essa informação pode ser enviada para o SIEM para análise.

Capacidades semelhantes são implementadas para qualquer ambiente de nuvem suportado pelo Cisco Stealthwatch Cloud:

A modelagem de entidades é uma forma única de automação de segurança que pode detectar problemas anteriormente desconhecidos em suas pessoas, processos ou tecnologias. Por exemplo, ela permite identificar, entre outras, as seguintes questões de segurança:

Alguém descobriu um backdoor no software que usamos?
Há algum software ou dispositivo de terceiros em nossa nuvem?
Um usuário autorizado está abusando de privilégios?
Houve uma falha de configuração que permite acesso remoto ou outro uso não intencional dos recursos?
Há vazamentos de dados de nossos servidores?
Alguém tentou se conectar a nós de um local geográfico incomum?
Nossa nuvem está infectada com código malicioso?

Um evento de segurança cibernética detectado pode ser enviado como um ticket correspondente para o Slack, Cisco Spark, o sistema de gerenciamento de incidentes PagerDuty, e também pode ser encaminhado para diferentes SIEMs, como Splunk ou ELK. Resumindo, se sua empresa utiliza uma estratégia multicloud e não se limita a um único provedor de nuvem, as capacidades de monitoramento de segurança cibernética descritas acima tornam o uso do Cisco Stealthwatch Cloud uma boa opção para obter um conjunto unificado de capacidades de monitoramento dos principais players de nuvem — Amazon, Microsoft e Google. O mais interessante é que, ao comparar os preços do Stealthwatch Cloud com as licenças avançadas de monitoramento de segurança cibernética na AWS, Azure ou GCP, pode acontecer de a solução Cisco ser até mais barata do que as funcionalidades integradas das soluções da Amazon, Microsoft e Google. Paradoxal, mas é verdade. E quanto mais nuvens e suas capacidades você utilizar, mais evidente será a vantagem de uma solução consolidada.

Além disso, o Stealthwatch Cloud pode monitorar também nuvens privadas implantadas em sua organização, por exemplo, baseadas em contêineres Kubernetes ou através do monitoramento de fluxos Netflow ou do tráfego de rede obtido por espelhamento em equipamentos de rede (mesmo de fabricação nacional), dados de AD ou servidores DNS, e assim por diante. Todas essas informações serão enriquecidas com dados de Threat Intelligence, coletados pela divisão Cisco Talos, que é o maior grupo de pesquisadores de ameaças cibernéticas não governamental do mundo.

Isso permite que você implemente um sistema unificado de monitoramento tanto para nuvens públicas quanto híbridas que sua empresa pode utilizar. As informações coletadas podem então ser analisadas usando as capacidades integradas do Stealthwatch Cloud ou enviadas para o seu SIEM (com suporte padrão para Splunk, ELK, SumoLogic e vários outros).

Com isso, encerramos a primeira parte do artigo, na qual eu analisei as ferramentas internas e externas para monitoramento de segurança em plataformas IaaS/PaaS, que nos permitem detectar e responder rapidamente a incidentes que ocorrem nos ambientes em nuvem escolhidos pela nossa empresa. Na segunda parte, vamos continuar o assunto e explorar as opções de monitoramento de plataformas SaaS, usando como exemplos o Salesforce e o Dropbox, e também tentaremos sintetizar e reunir tudo, criando um sistema unificado de monitoramento de segurança para diferentes provedores de nuvem.

Fonte: habr.com