🥇Monitoramento de segurança em nuvem

A migração de dados e aplicações para a nuvem representa um novo desafio para os SOCs corporativos, que nem sempre estão prontos para monitorar a infraestrutura de outras pessoas. De acordo com a Netoskope, uma empresa média (aparentemente nos EUA) utiliza 1246 serviços de nuvem diferentes, o que representa 22% a mais do que há um ano. 1246 serviços em nuvem!!! 175 deles estão relacionados com serviços de RH, 170 estão relacionados com marketing, 110 estão na área de comunicações e 76 estão em finanças e CRM. A Cisco usa “apenas” 700 serviços de nuvem externos. Então estou um pouco confuso com esses números. Mas em qualquer caso, o problema não está neles, mas no facto de a nuvem começar a ser utilizada de forma bastante activa por um número cada vez maior de empresas que gostariam de ter as mesmas capacidades de monitorização da infra-estrutura da nuvem que na sua própria rede. E esta tendência está a crescer - segundo de acordo com a Câmara Americana de Contas Até 2023, 1200 data centers serão fechados nos Estados Unidos (6250 já fecharam). Mas a transição para a nuvem não é apenas “vamos mover nossos servidores para um provedor externo”. Nova arquitetura de TI, novos softwares, novos processos, novas restrições... Tudo isso traz mudanças significativas não só no trabalho da TI, mas também na segurança da informação. E se os provedores aprenderam a lidar de alguma forma com a garantia da segurança da própria nuvem (felizmente, há muitas recomendações), então com o monitoramento da segurança da informação na nuvem, especialmente em plataformas SaaS, existem dificuldades significativas, das quais falaremos.

Digamos que sua empresa migrou parte de sua infraestrutura para a nuvem... Pare. Não desta forma. Se a infra-estrutura foi transferida e só agora você está pensando em como irá monitorá-la, então você já perdeu. A menos que seja Amazon, Google ou Microsoft (e com reservas), você provavelmente não terá muita capacidade de monitorar seus dados e aplicativos. É bom que você tenha a oportunidade de trabalhar com logs. Às vezes, os dados de eventos de segurança estarão disponíveis, mas você não terá acesso a eles. Por exemplo, Office 365. Se você tiver a licença E1 mais barata, os eventos de segurança não estarão disponíveis para você. Se você possui uma licença E3, seus dados são armazenados por apenas 90 dias, e somente se você possui uma licença E5, a duração dos logs fica disponível por um ano (no entanto, isso também tem suas próprias nuances relacionadas à necessidade de separadamente solicite uma série de funções para trabalhar com logs 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 de uma licença adicional de Conformidade Avançada, o que pode exigir dinheiro adicional que não foi levado em consideração em seu modelo financeiro para migrar para a infraestrutura em nuvem. E este é apenas um exemplo de subestimação de questões relacionadas ao monitoramento da segurança da informação na nuvem. Neste artigo, sem pretender ser completo, quero chamar a atenção para algumas nuances que devem ser levadas em consideração na hora de escolher um provedor de nuvem do ponto de vista da segurança. E ao final do artigo será fornecida uma lista de verificação que vale a pena completar antes de considerar que a questão do monitoramento da segurança da informação na nuvem foi resolvida.

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

Os logs de segurança não existem. Esta é uma situação bastante comum, principalmente entre players iniciantes no mercado de soluções em nuvem. Mas você não deve desistir deles imediatamente. Os pequenos players, especialmente os nacionais, são mais sensíveis às necessidades dos clientes e podem implementar rapidamente algumas funções necessárias, alterando o roteiro aprovado para os seus produtos. Sim, este não será um análogo do GuardDuty da Amazon ou do módulo “Proactive Protection” do Bitrix, mas pelo menos alguma coisa.
A segurança da informação 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 importante para ele. Mas, em geral, não é muito bom quando o acesso aos registos é fornecido “por decisão especial”.
Acontece também que o provedor de nuvem possui logs, mas eles fornecem monitoramento e registro de eventos limitados, que não são suficientes para detectar todos os incidentes. Por exemplo, você pode receber apenas logs de alterações em um site ou logs de tentativas de autenticação de usuários, mas não outros eventos, como tráfego de rede, que ocultarão de você toda uma camada de eventos que caracterizam tentativas de hackear sua infraestrutura em nuvem.
Existem logs, mas o acesso a eles é difícil de automatizar, o que obriga a serem monitorados não continuamente, mas de forma programada. E se você não puder baixar logs automaticamente, então baixá-los, por exemplo, no formato Excel (como acontece com vários provedores domésticos de soluções em nuvem), pode até levar a uma relutância por parte do serviço corporativo de segurança da informação em mexer neles.
Sem monitoramento de log. Esta é talvez a razão menos clara para a ocorrência de incidentes de segurança da informação em ambientes de nuvem. Parece que existem logs e é possível automatizar o acesso a eles, mas ninguém faz isso. Por que?

Conceito de segurança em nuvem compartilhada

A transição para a nuvem é sempre uma busca pelo equilíbrio entre o desejo de manter o controle sobre a infraestrutura e transferi-la para mãos mais profissionais de um 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 de entrega de serviços em nuvem utilizado (IaaS, PaaS, SaaS), esse equilíbrio será sempre diferente. De qualquer forma, devemos lembrar que todos os provedores de nuvem hoje seguem o chamado modelo de responsabilidade compartilhada e segurança da informação compartilhada. A nuvem é responsável por algumas coisas, e por outras o cliente é responsável, colocando seus dados, suas aplicações, suas máquinas virtuais e outros recursos na nuvem. Seria imprudente esperar que, ao migrarmos para a nuvem, transferiríamos toda a responsabilidade para o fornecedor. Mas também não é aconselhável criar você mesmo toda a segurança ao migrar para a nuvem. É necessário um equilíbrio, que dependerá de muitos fatores: - estratégia de gestão de risco, modelo de ameaça, mecanismos de segurança disponíveis para o fornecedor de nuvem, legislação, etc.

Por exemplo, a classificação dos dados hospedados na nuvem é sempre de responsabilidade do cliente. Um provedor de nuvem ou provedor de serviços externo só pode ajudá-lo com ferramentas que ajudarão 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 da responsabilidade do fornecedor da nuvem, que não pode partilhar com os clientes. Mas tudo o que está entre dados e infraestrutura física é justamente tema de discussão neste artigo. Por exemplo, a disponibilidade da nuvem é de responsabilidade do provedor, e a configuração de regras de firewall ou a ativação da criptografia é de responsabilidade do cliente. Neste artigo, tentaremos ver quais mecanismos de monitoramento de segurança da informação são fornecidos hoje por vários provedores de nuvem populares na Rússia, quais são os recursos de seu uso e quando vale a pena procurar soluções de sobreposição externas (por exemplo, Cisco E- mail Security) que expandem as capacidades da sua nuvem em termos de segurança cibernética. Em alguns casos, especialmente se você estiver seguindo uma estratégia multinuvem, não terá outra escolha senão usar soluções externas de monitoramento de segurança da informação em vários ambientes de nuvem ao mesmo tempo (por exemplo, Cisco CloudLock ou Cisco Stealthwatch Cloud). Bem, em alguns casos você perceberá que o provedor de nuvem que você escolheu (ou impôs a você) não oferece nenhum recurso de monitoramento de segurança da informação. Isto é desagradável, mas também não pouco, 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ê usa, você tem apenas três opções:

conte com as ferramentas fornecidas pelo seu provedor de nuvem,
usar soluções de terceiros que monitorarão as plataformas IaaS, PaaS ou SaaS que você usa,
construa sua própria infraestrutura de monitoramento em nuvem (somente para plataformas IaaS/PaaS).

Vamos ver quais recursos cada uma dessas opções possui. Mas primeiro, precisamos entender a estrutura geral que será usada ao monitorar plataformas em nuvem. Destaco 6 componentes principais do processo de monitoramento da segurança da informação na nuvem:

Preparação de infra-estruturas. Determinar os aplicativos e a infraestrutura necessários para coletar eventos importantes para a segurança da informação no armazenamento.
Coleção. Nesta fase, os eventos de segurança são agregados de diversas fontes para posterior transmissão para processamento, armazenamento e análise.
Tratamento. Nesta fase, os dados são transformados e enriquecidos para facilitar análises posteriores.
Armazenar. Este componente é responsável pelo armazenamento de curto e longo prazo dos dados brutos e processados coletados.
Análise. Nesta fase, você tem a capacidade de detectar incidentes e responder a eles de forma automática ou manual.
Comunicando. Esta etapa ajuda a formular indicadores-chave para as partes interessadas (gestão, auditores, fornecedor de nuvem, clientes, etc.) que nos ajudam a tomar certas decisões, por exemplo, mudar de fornecedor ou reforçar a segurança da informação.

A compreensão desses componentes permitirá que você decida rapidamente no futuro o que pode receber do seu provedor e o que terá que fazer sozinho ou com o envolvimento de consultores externos.

Serviços de nuvem integrados

Já escrevi acima que muitos serviços em nuvem hoje não oferecem nenhum recurso de monitoramento de segurança da informação. Em geral, eles não dão muita atenção ao tema segurança da informação. Por exemplo, um dos serviços russos mais populares para envio de relatórios a agências governamentais através da Internet (não mencionarei especificamente o seu nome). Toda a seção sobre a segurança deste serviço gira em torno da utilização de CIPF certificado. A seção de segurança da informação de outro serviço de nuvem nacional para gerenciamento eletrônico de documentos não é diferente. Fala sobre certificados de chave pública, criptografia certificada, eliminação de vulnerabilidades web, proteção contra ataques DDoS, uso de firewalls, backups e até auditorias regulares de segurança da informação. Mas não há uma palavra sobre monitoramento, nem sobre a possibilidade de acesso a eventos de segurança da informação que possam ser de interesse dos clientes deste prestador de serviços.

Em geral, pela maneira como o provedor de nuvem descreve as questões de segurança da informação em seu site e em sua documentação, você pode entender o quão seriamente ele leva essa questão. Por exemplo, se você ler os manuais dos produtos “My Office”, não há nenhuma palavra sobre segurança, mas na documentação do produto separado “My Office. KS3”, projetado para proteger contra acesso não autorizado, há uma listagem usual de pontos da 17ª ordem do FSTEC, que “My Office.KS3” implementa, mas não é descrito como ele o implementa e, o mais importante, como integrar esses mecanismos à segurança da informação corporativa. Talvez tal documentação exista, 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 secretas?

Para Bitrix, a situação é muito melhor. A documentação descreve os formatos dos logs de eventos e, curiosamente, do log de intrusão, que contém eventos relacionados a ameaças potenciais à plataforma em nuvem. A partir daí você pode extrair o IP, nome do usuário ou convidado, fonte do evento, hora, agente do usuário, tipo de evento, etc. É verdade que você pode trabalhar com esses eventos a partir do painel de controle da própria nuvem ou fazer upload de dados no formato MS Excel. Agora é difícil automatizar o trabalho com logs do Bitrix e você terá que fazer parte do trabalho manualmente (carregar o relatório e carregá-lo em seu SIEM). Mas se nos lembrarmos que até há relativamente pouco tempo tal oportunidade não existia, então este é um grande progresso. Ao mesmo tempo, gostaria de observar que muitos provedores de nuvem estrangeiros oferecem funcionalidade semelhante “para iniciantes” - observe os logs com os olhos através do painel de controle ou carregue os dados para você mesmo (no entanto, a maioria carrega os dados em . csv, não Excel).

Sem considerar a opção sem registros, os provedores de nuvem geralmente oferecem três opções para monitorar eventos de segurança: painéis, upload de dados e acesso à API. O primeiro parece resolver muitos problemas para você, mas isso não é inteiramente verdade - se você tiver várias revistas, terá que alternar entre as telas que as exibem, perdendo a imagem geral. Além disso, é improvável que o provedor de nuvem forneça a capacidade de correlacionar eventos de segurança e analisá-los de maneira geral do ponto de vista da segurança (geralmente você está lidando com dados brutos, que você mesmo precisa entender). Existem exceções e falaremos sobre elas mais adiante. Por fim, vale a pena perguntar quais eventos são registrados pelo seu provedor de nuvem, em que formato e como eles correspondem ao seu processo de monitoramento de segurança da informação? Por exemplo, identificação e autenticação de usuários e convidados. O mesmo Bitrix permite, com base nesses eventos, registrar a data e hora do evento, o nome do usuário ou convidado (caso possua o módulo “Web Analytics”), o objeto acessado e outros elementos típicos de um site . Mas os serviços corporativos de segurança da informação podem precisar de informações sobre se o usuário acessou a nuvem a partir de um dispositivo confiável (por exemplo, em uma rede corporativa esta tarefa é implementada pelo Cisco ISE). E quanto a uma tarefa tão simples como a função geo-IP, que ajudará a determinar se uma conta de usuário de serviço em nuvem foi roubada? E mesmo que o provedor de nuvem forneça isso a você, isso não é suficiente. O mesmo Cisco CloudLock não analisa apenas a geolocalização, mas utiliza machine learning para isso e analisa dados históricos de cada usuário e monitora diversas anomalias nas tentativas de identificação e autenticação. Apenas o MS Azure possui funcionalidade semelhante (se você tiver a assinatura apropriada).

Há outra dificuldade - como para muitos provedores de nuvem o monitoramento da segurança da informação é um tema novo com o qual eles estão apenas começando a lidar, eles estão constantemente mudando algo em suas soluções. Hoje eles têm uma versão da API, amanhã outra, depois de amanhã uma terceira. Você também precisa estar preparado para isso. O mesmo acontece com a funcionalidade, que pode sofrer alterações, o que deve ser levado em consideração no seu sistema de monitoramento de segurança da informação. Por exemplo, a Amazon inicialmente tinha serviços separados de monitoramento de eventos em nuvem – AWS CloudTrail e AWS CloudWatch. Em seguida, apareceu um serviço separado para monitorar eventos de segurança da informação - AWS GuardDuty. Depois de algum tempo, a Amazon lançou um novo sistema de gerenciamento, Amazon Security Hub, que inclui análise de dados recebidos do GuardDuty, Amazon Inspector, Amazon Macie e vários outros. Outro exemplo é a ferramenta de integração de logs do Azure com SIEM – AzLog. Foi usado ativamente por muitos fornecedores de SIEM, até que em 2018 a Microsoft anunciou a cessação de seu desenvolvimento e suporte, o que confrontou muitos clientes que usavam essa ferramenta com um problema (falaremos sobre como isso foi resolvido mais tarde).

Portanto, monitore cuidadosamente todos os recursos de monitoramento que seu provedor de nuvem oferece. Ou conte com provedores de soluções externos 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 de outra pessoa. Ou não tudo?.. Vamos lembrar o conceito de segurança compartilhada e entender que não podemos mudar nada - teremos que entender de forma independente como diferentes provedores de nuvem fornecem monitoramento da segurança da informação de seus dados, aplicativos, máquinas virtuais e outros recursos hospedado na nuvem. E começaremos com o que a Amazon oferece nesta parte.

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

Sim, sim, entendo que a Amazon não é o melhor exemplo porque se trata de um serviço americano e pode ser bloqueado no âmbito da luta contra o extremismo e da divulgação de informações proibidas na Rússia. Mas nesta publicação eu gostaria apenas de mostrar como as diferentes plataformas de nuvem diferem em suas capacidades de monitoramento de segurança da informação e no 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 aprenderem algo útil para si próprios, isso será ótimo.

A primeira coisa a dizer é que a Amazon não é uma fortaleza impenetrável. Vários incidentes acontecem regularmente com seus clientes. Por exemplo, os nomes, endereços, datas de nascimento e números de telefone de 198 milhões de eleitores foram roubados do Deep Root Analytics. A empresa israelense Nice Systems roubou 14 milhões de registros de assinantes da Verizon. No entanto, os recursos integrados da AWS permitem detectar uma ampla variedade de incidentes. Por exemplo:

impacto 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 inseguras.

Esta discrepância deve-se ao facto de, como vimos acima, o próprio cliente ser responsável pela segurança dos dados do cliente. E se ele não se preocupou em ativar mecanismos de proteção e não ativou ferramentas de monitoramento, só saberá do incidente pela mídia ou por seus clientes.

Para identificar incidentes, você pode usar uma ampla gama de diferentes serviços de monitoramento desenvolvidos pela Amazon (embora estes sejam frequentemente complementados por ferramentas externas, como o osquery). Assim, na AWS, todas as ações do usuário são monitoradas, independente de como são realizadas – por meio do console de gerenciamento, linha de comando, SDK ou outros serviços da AWS. Todos os registros da atividade de cada conta da AWS (incluindo nome de usuário, ação, serviço, parâmetros de atividade e resultado) e uso da API estão disponíveis por meio do AWS CloudTrail. Você pode visualizar esses eventos (como logins do console AWS IAM) no console do CloudTrail, analisá-los usando o Amazon Athena ou “terceirizá-los” para soluções externas, como Splunk, AlienVault, etc. Os próprios logs do AWS CloudTrail são colocados em seu bucket AWS S3.

Dois outros serviços da AWS fornecem vários outros recursos importantes de monitoramento. Primeiro, o Amazon CloudWatch é um serviço de monitoramento de recursos e aplicações AWS que, entre outras coisas, permite identificar diversas 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 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 a aplicativos e serviços personalizados, permitindo expandir o escopo da análise de eventos dentro de um contexto de segurança.

Em segundo lugar, o serviço VPC Flow Logs permite analisar o tráfego de rede enviado ou recebido pelos 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 VPC Flow Logs registra detalhes sobre o tráfego de rede, incluindo a interface de rede de origem e destino, bem como os endereços IP, portas, protocolo, número de bytes e número de pacotes que você serra. Aqueles com experiência em segurança de rede local reconhecerão isso como análogo a threads NetFlow, que pode ser criado por switches, roteadores e firewalls de nível empresarial. Esses logs são importantes para fins de monitoramento de segurança da informação porque, diferentemente dos eventos sobre as ações de usuários e aplicações, eles também permitem que você não perca as interações de rede no ambiente de nuvem privada virtual da AWS.

Em resumo, esses três serviços da AWS – AWS CloudTrail, Amazon CloudWatch e VPC Flow Logs – juntos fornecem insights bastante poderosos sobre o uso da sua conta, comportamento do usuário, gerenciamento de infraestrutura, atividade de aplicativos e serviços e atividade de rede. Por exemplo, eles podem ser usados para detectar as seguintes anomalias:

Tentativas de escanear o site, procurar backdoors, procurar vulnerabilidades por meio de rajadas de “erros 404”.
Ataques de injeção (por exemplo, injeção de SQL) por meio de rajadas de “500 erros”.
Ferramentas de ataque conhecidas são sqlmap, nikto, w3af, nmap, etc. através da análise do campo User Agent.

A Amazon Web Services também desenvolveu outros serviços para fins de segurança cibernética que permitem resolver muitos outros problemas. Por exemplo, a AWS possui um serviço integrado para auditoria de políticas e configurações - AWS Config. Este serviço fornece auditoria contínua de seus recursos da AWS e de suas configurações. Vejamos um exemplo simples: digamos que você deseja ter certeza de que as senhas dos usuários estão desabilitadas em todos os seus servidores e que o acesso só é possível com base em certificados. O AWS Config facilita a verificação disso em todos os seus servidores. Existem outras políticas que podem ser aplicadas aos seus servidores em nuvem: “Nenhum servidor pode usar a porta 22”, “Somente os administradores podem alterar as regras do firewall” ou “Somente o usuário Ivashko pode criar novas contas de usuário, e ele pode fazer isso apenas às terças-feiras. " No verão de 2016, o serviço AWS Config foi ampliado para automatizar a detecção de violações das políticas desenvolvidas. As regras do AWS Config são essencialmente solicitações de configuração contínuas para os serviços da Amazon que você usa, que geram eventos se as políticas correspondentes forem violadas. Por exemplo, em vez de executar periodicamente consultas do AWS Config para verificar se todos os discos em um servidor virtual estão criptografados, as regras do AWS Config podem ser usadas para verificar continuamente os discos do servidor para garantir que essa condição seja atendida. 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.

A AWS também possui seu equivalente à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ões - AWS GuardDuty
Controle de vazamento de informações - AWS Macie
EDR (embora fale um pouco estranhamente sobre endpoints na nuvem) - 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 - AWS Directory Service
Gerenciamento de contas - AWS IAM
SSO - AWS SSO
análise de segurança - AWS Inspector
gerenciamento de configuração - AWS Config
WAF -AWS WAF.

Não descreverei detalhadamente todos os serviços da Amazon que podem ser úteis no contexto da segurança da informação. O principal é entender que todos eles podem gerar eventos que podemos e devemos analisar no contexto da segurança da informação, utilizando para isso tanto as capacidades integradas da própria Amazon quanto soluções externas, por exemplo, SIEM, que podem leve eventos de segurança para sua central de monitoramento e analise-os junto com eventos de outros serviços em nuvem ou de infraestrutura interna, perímetro ou dispositivos móveis.

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

CloudTrail – Uso da API e ações do usuário
Trusted Advisor - verificação de segurança em relação às práticas recomendadas
Configuração - inventário e configuração de contas e configurações de serviço
Logs de fluxo de VPC: conexões com interfaces virtuais
IAM - serviço de identificação e autenticação
Logs de acesso ELB - balanceador de carga
Inspetor - vulnerabilidades de aplicativos
S3 - armazenamento de arquivos
CloudWatch – Atividade do aplicativo
SNS é um serviço de notificação.

A Amazon, embora ofereça uma gama tão grande de fontes de eventos e ferramentas 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 de forma independente os logs disponíveis, procurando neles indicadores relevantes de comprometimento. O AWS Security Hub, lançado recentemente pela Amazon, visa resolver esse problema tornando-se um SIEM em nuvem para AWS. Mas até o momento está apenas no início de sua jornada e está limitado tanto pela quantidade de fontes com as quais trabalha quanto por outras restrições estabelecidas pela arquitetura e assinaturas da própria Amazon.

Exemplo: Monitoramento de segurança da informação em IaaS baseado em 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 ainda tem suas especificidades e é adequado para resolver seus próprios problemas); Vamos nos concentrar nos recursos de monitoramento de segurança da informação que esses players oferecem. É preciso admitir que o Amazon AWS foi um dos primeiros neste segmento e, portanto, foi o que mais avançou em termos de suas funções de segurança da informação (embora muitos admitam que são difíceis de usar). Mas isso não significa que iremos ignorar as oportunidades que a Microsoft e o Google nos oferecem.

Os produtos Microsoft sempre se distinguiram pela sua “abertura” e no Azure a situação é semelhante. Por exemplo, se AWS e GCP sempre partem do conceito de “o que não é permitido é proibido”, então o Azure tem a abordagem exatamente oposta. Por exemplo, ao criar uma rede virtual na nuvem e uma máquina virtual nela, todas as portas e protocolos são abertos e permitidos por padrão. Portanto, você terá que despender 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 em termos de monitoramento de atividades na nuvem Azure.

A AWS tem uma peculiaridade associada ao fato de que ao monitorar seus recursos virtuais, caso estejam localizados em regiões diferentes, você tem dificuldades em combinar todos os eventos e sua análise unificada, para eliminar os quais é necessário recorrer a vários truques, como como Crie seu próprio código para AWS Lambda que transportará eventos entre regiões. O Azure não tem esse problema – seu mecanismo de Log de Atividades rastreia todas as atividades em toda a organização sem restrições. O mesmo se aplica ao AWS Security Hub, que foi recentemente desenvolvido pela Amazon para consolidar muitas funções de segurança dentro de um único centro de segurança, mas apenas dentro da sua região, o que, no entanto, não é relevante para a Rússia. O Azure possui uma Central de Segurança própria, que não está sujeita a restrições regionais, proporcionando acesso a todos os recursos de segurança da plataforma em nuvem. Além disso, para diferentes equipas locais pode fornecer o seu próprio conjunto de capacidades de proteção, incluindo eventos de segurança geridos por elas. O AWS Security Hub ainda está a caminho de se tornar semelhante ao Azure Security Center. Mas vale a pena adicionar uma mosca na sopa - você pode extrair do Azure muito do que foi descrito anteriormente na AWS, mas isso é feito de maneira mais conveniente apenas para Azure AD, Azure Monitor e Azure Security Center. Todos os outros mecanismos de segurança do Azure, incluindo a análise de eventos de segurança, ainda não são geridos da forma mais conveniente. O problema é parcialmente resolvido pela API, que permeia todos os serviços do Microsoft Azure, mas isso exigirá um esforço adicional de sua parte para integrar sua nuvem ao seu SOC e a presença de especialistas qualificados (na verdade, como acontece com qualquer outro SIEM que trabalhe com nuvem API). Alguns SIEMs, que serão discutidos mais adiante, já suportam o Azure e podem automatizar a tarefa de monitorá-lo, mas também têm suas próprias dificuldades - nem todos conseguem coletar todos os logs que o Azure possui.

A coleta e monitoramento de eventos no Azure são fornecidos por meio do serviço Azure Monitor, que é a principal ferramenta de coleta, armazenamento e análise de dados na nuvem da Microsoft e seus recursos - repositórios Git, contêineres, máquinas virtuais, aplicativos, etc. Todos os dados recolhidos pelo Azure Monitor estão divididos em duas categorias - métricas, recolhidas em tempo real e que descrevem os principais indicadores de desempenho da nuvem Azure, e registos, contendo dados organizados em registos que caracterizam determinados aspetos da atividade dos recursos e serviços do Azure. Além disso, utilizando a API do Coletor de Dados, o serviço Azure Monitor pode recolher dados de qualquer fonte REST para construir os seus próprios cenários de monitorização.

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

Logs de atividades – esse log responde às perguntas clássicas de “quem”, “o quê” e “quando” em relação a qualquer operação de gravação (PUT, POST, DELETE) em recursos de nuvem. Os eventos relacionados ao acesso de leitura (GET) não são incluídos neste log, como vários outros.
Logs de diagnóstico – contém dados sobre operações com um recurso específico incluído em sua assinatura.
Relatórios do Azure AD – contém atividades do usuário e atividades 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.
Métricas – contém telemetria sobre o desempenho e o status de integridade dos seus serviços e recursos em nuvem. Medido a cada minuto e armazenado. dentro de 30 dias.
Logs de fluxo do grupo de segurança de rede - contém dados sobre eventos de segurança de rede coletados usando o serviço Network Watcher e monitoramento de recursos no nível da rede.
Logs de armazenamento - contém eventos relacionados ao acesso a instalações de armazenamento.

Para monitorização, pode utilizar SIEMs externos ou o Azure Monitor incorporado e as suas extensões. Falaremos sobre sistemas de gerenciamento de eventos de segurança da informação mais tarde, mas por enquanto vamos ver o que o próprio Azure nos oferece para análise de dados no contexto de segurança. A tela principal para tudo relacionado à segurança no Azure Monitor é o Painel de Segurança e Auditoria do Log Analytics (a versão gratuita oferece suporte a uma quantidade limitada de armazenamento de eventos por apenas uma semana). Este painel está dividido em 5 áreas principais que visualizam estatísticas resumidas do que está acontecendo no ambiente de nuvem que você está usando:

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, 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 da informação
Detecções - exibe padrões de ataques usados 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 o ajudarão a monitorar melhor a segurança da sua informação.

As extensões do Azure Monitor incluem 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 em nuvem), etc. . Estas ferramentas, enriquecidas com determinadas regras de processamento de eventos, permitem visualizar vários aspectos da atividade dos serviços cloud, incluindo a segurança, e identificar determinados desvios de funcionamento. Mas, como costuma acontecer, qualquer funcionalidade adicional requer uma assinatura paga correspondente, o que exigirá de você os investimentos financeiros correspondentes, que você precisa planejar com antecedência.

O Azure tem uma série de capacidades de monitorização de ameaças incorporadas que estão integradas no Azure AD, no Azure Monitor e no Azure Security Center. Entre eles, por exemplo, detecção de interação de máquinas virtuais com IPs maliciosos conhecidos (devido à presença de integração com serviços de Threat Intelligence da Microsoft), detecção de malware na infraestrutura em nuvem por meio do recebimento de alarmes de máquinas virtuais hospedadas na nuvem, senha ataques de adivinhação” em máquinas virtuais, vulnerabilidades na configuração do sistema de identificação do usuário, login no sistema a partir de anonimizadores ou nós infectados, vazamentos de contas, login no sistema a partir de locais incomuns, etc. Atualmente, o Azure é um dos poucos provedores de nuvem que oferece recursos integrados de Threat Intelligence para enriquecer os eventos de segurança de informações coletados.

Conforme mencionado acima, a funcionalidade de segurança e, consequentemente, os eventos de segurança por ela gerados não estão disponíveis para todos os usuários igualmente, mas requerem uma determinada assinatura que inclua a funcionalidade que você precisa, que gera os eventos apropriados para o monitoramento da segurança da informação. Por exemplo, algumas das funções descritas no parágrafo anterior para monitorização de anomalias em contas estão disponíveis apenas na licença premium P2 do serviço Azure AD. Sem ele, você, como no caso da AWS, terá que analisar “manualmente” os eventos de segurança coletados. E, também, 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 consultas de pesquisa de logs de seu interesse e configurar painéis para visualizar os principais indicadores de segurança da informação. Além disso, você pode selecionar extensões do Azure Monitor, que permitem expandir a funcionalidade dos logs do Azure Monitor e obter uma análise mais profunda dos eventos do ponto de vista da segurança.

Se você precisa não apenas da capacidade de trabalhar com logs, mas de um centro de segurança abrangente para sua plataforma de nuvem Azure, incluindo gerenciamento de políticas de segurança da informação, então você pode falar sobre a necessidade de trabalhar com a Central de Segurança do Azure, cuja maioria das funções úteis estão disponíveis por algum dinheiro, 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 eliminação de problemas identificados). Ele consolida todos os problemas de segurança em um só lugar. Na verdade, podemos falar de um nível de segurança da informação superior ao que o Azure Monitor lhe proporciona, pois neste caso os dados recolhidos em toda a sua fábrica na nuvem são enriquecidos através de diversas 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), nos quais vários algoritmos sofisticados de aprendizado de máquina e análise comportamental são sobrepostos, o que deve, em última análise, melhorar a eficiência de detecção e resposta a ameaças .

O Azure também 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 ser integrado. soluções de segurança externa (por exemplo, NGFW ou WAF), cuja lista está em constante crescimento. Além disso, por meio da integração da API de segurança do Microsoft Graph, você tem a capacidade de conectar seus próprios feeds de Threat Intelligence ao Sentinel, o que enriquece os recursos de análise de incidentes na nuvem do Azure. Pode-se argumentar que o Azure Sentinel é o primeiro SIEM “nativo” que surgiu de provedores de nuvem (o mesmo Splunk ou ELK, que pode ser hospedado na nuvem, por exemplo, AWS, ainda não é desenvolvido por provedores de serviços de nuvem tradicionais). O Azure Sentinel e o Security Center poderiam ser chamados de SOC para a nuvem Azure e poderiam ser limitados a eles (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 a nuvem Microsoft Azure.

Mas como os recursos integrados do Azure (mesmo se você tiver uma assinatura do Sentinel) muitas vezes não são suficientes para monitorar a segurança da informação e integrar esse processo com outras fontes de eventos de segurança (na nuvem e internos), há um necessidade de exportar os dados recolhidos para sistemas externos, que podem incluir o SIEM. Isso é feito usando a API e extensões especiais, que atualmente estão oficialmente disponíveis apenas para os seguintes SIEMs - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight e ELK. Até recentemente, existiam mais SIEMs desse tipo, mas a partir de 1º de junho de 2019, a Microsoft parou de oferecer suporte à Azure Log Integration Tool (AzLog), que no início da existência do Azure e na ausência de padronização normal de trabalho com logs (Azure O Monitor ainda nem existia) facilitou a integração do SIEM externo com a nuvem da Microsoft. Agora a situação mudou e a Microsoft recomenda a plataforma Azure Event Hub como principal ferramenta de integração para outros SIEMs. Muitos já implementaram essa integração, mas tenha cuidado - eles podem não capturar todos os logs do Azure, mas apenas alguns (procure na documentação do seu SIEM).

Concluindo uma breve excursão ao Azure, gostaria de dar uma recomendação geral sobre este serviço em nuvem - antes de dizer qualquer coisa sobre as funções de monitoramento de segurança da informação no Azure, você deve configurá-las com muito cuidado e testar se funcionam conforme está escrito na documentação e como os consultores da Microsoft lhe disseram (e eles podem ter opiniões diferentes sobre a funcionalidade das funções do Azure). Se você tiver recursos financeiros, poderá extrair muitas informações úteis do Azure em termos de monitoramento de segurança da informação. Se seus recursos forem limitados, então, como no caso da AWS, você terá que confiar apenas em sua própria força e nos dados brutos que o Azure Monitor fornece. E lembre-se que muitas funções de monitoramento custam dinheiro e é melhor se familiarizar com a política de preços com antecedência. Por exemplo, gratuitamente você pode armazenar 31 dias de dados até um máximo de 5 GB por cliente - exceder esses valores exigirá que você desembolse dinheiro adicional (aproximadamente US$ 2+ para armazenar cada GB adicional do cliente e US$ 0,1 para armazenando 1 GB a cada mês adicional). Trabalhar com telemetria e métricas de aplicativos também pode exigir fundos adicionais, bem como trabalhar com alertas e notificações (um determinado limite está disponível gratuitamente, o que pode não ser suficiente para suas necessidades).

Exemplo: Monitoramento de segurança da informação em IaaS baseado no Google Cloud Platform

O Google Cloud Platform parece jovem em comparação com AWS e Azure, mas isso é parcialmente bom. Ao contrário da AWS, que aumentou suas capacidades, inclusive de segurança, gradativamente, tendo problemas de centralização; O GCP, assim como o Azure, é muito melhor gerenciado centralmente, o que reduz erros e tempo de implementação em toda a empresa. Do ponto de vista da segurança, o GCP está, curiosamente, entre AWS e Azure. Ele também possui uma inscrição de evento único para toda a organização, mas está incompleta. Algumas funções ainda estão em modo beta, mas aos poucos essa deficiência deverá 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 (semelhante ao Azure Monitor), que permite coletar eventos em toda a sua infraestrutura de nuvem (bem como na AWS). Do ponto de vista da segurança no GCP, cada organização, projeto ou pasta possui quatro registros:

Atividade Admin - 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 log é sempre gravado, independente da sua vontade, e armazena seus dados por 400 dias.
Acesso a dados - contém todos os eventos relacionados ao trabalho com dados pelos usuários da nuvem (criação, modificação, leitura, etc.). Por padrão, esse log não é gravado, pois seu volume aumenta muito rapidamente. Por esse motivo, seu prazo de validade é de apenas 30 dias. Além disso, nem tudo está escrito nesta revista. Por exemplo, eventos relacionados a recursos acessíveis publicamente a todos os usuários ou acessíveis sem login no GCP não são gravados nele.
Evento do Sistema - contém eventos do sistema não relacionados aos usuários ou ações de um administrador que altera a configuração dos recursos da nuvem. É sempre escrito e armazenado por 400 dias.
A transparência no acesso é um exemplo único de registro que captura todas as ações dos funcionários do Google (mas ainda não de todos os serviços do GCP) que acessam sua infraestrutura como parte de suas funções profissionais. Esse registro é armazenado por 400 dias e não está disponível para todos os clientes do GCP, mas somente se uma série de condições forem atendidas (suporte de nível Gold ou Platinum ou a presença de quatro funções de um determinado tipo como parte do suporte corporativo). Uma função semelhante também está disponível, por exemplo, no Office 4 - Lockbox.

Exemplo de registro: Transparência no 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 discutida anteriormente no Azure e na AWS): por meio da interface do Log Viewer, da API, do Google Cloud SDK ou da página de atividades do seu projeto para o qual você estão interessados em eventos. Da mesma forma, podem ser exportados para soluções externas para análises adicionais. O último é feito exportando registros 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 monitorar as principais métricas (desempenho, MTBF, integridade geral etc.) de serviços e aplicativos em nuvem. Os dados processados e visualizados podem facilitar a localização de problemas na sua infraestrutura em nuvem, inclusive no contexto de segurança. Mas deve-se destacar que esta funcionalidade não será muito rica no contexto de segurança da informação, já que hoje o GCP não possui um análogo do mesmo AWS GuardDuty e não consegue identificar eventos ruins entre todos os eventos registrados (o Google desenvolveu Event Threat Detection, mas ainda está em desenvolvimento na versão beta e é muito cedo para falar sobre sua utilidade). O Stackdriver Monitoring poderia ser usado como um sistema de detecção de anomalias, que seriam então investigadas para encontrar as causas de sua ocorrência. Mas dada a falta de pessoal qualificado na área de segurança da informação GCP no mercado, esta tarefa parece difícil atualmente.

Também vale a pena dar uma lista de alguns módulos de segurança da informação que podem ser usados dentro da sua nuvem GCP, e que são 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 – descoberta e edição automática (por exemplo, mascaramento) de dados hospedados na nuvem usando mais de 90 políticas de classificação predefinidas.
Cloud Scanner é um scanner para vulnerabilidades conhecidas (XSS, Flash Injection, bibliotecas não corrigidas, etc.) no App Engine, Compute Engine e Google Kubernetes.
Cloud IAM: controle o acesso a todos os recursos do GCP.
Cloud Identity: gerencie contas de usuários, dispositivos e aplicativos do GCP em um único console.
Cloud HSM - proteção de chaves criptográficas.
Cloud Key Management Service - gerenciamento de chaves criptográficas no GCP.
VPC Service Control: crie um perímetro seguro em torno dos recursos do GCP para protegê-los contra vazamentos.
Chave de segurança Titan - proteção contra phishing.

Muitos desses módulos geram eventos de segurança que podem ser enviados ao armazenamento do BigQuery para análise ou exportação para outros sistemas, incluindo SIEM. Conforme mencionado acima, o GCP é uma plataforma em desenvolvimento ativo e o Google está agora desenvolvendo uma série de novos módulos de segurança da informação para sua plataforma. Entre eles estão o Event Threat Detection (agora disponível em beta), que verifica os logs do Stackdriver em busca de vestígios de atividades não autorizadas (análogo ao GuardDuty na AWS), ou Policy Intelligence (disponível em alfa), que permitirá desenvolver políticas inteligentes para acesso aos recursos do GCP.

Fiz uma breve visão geral dos recursos de monitoramento integrados em plataformas de nuvem populares. Mas você tem especialistas capazes de trabalhar com logs “brutos” de provedores de IaaS (nem todo mundo está pronto para comprar os recursos avançados da AWS, do Azure ou do Google)? Além disso, muitos estão familiarizados com o ditado “confie, mas verifique”, que é mais verdadeiro do que nunca no campo da segurança. Quanto você confia nos recursos integrados do provedor de nuvem que enviam eventos de segurança da informação? Quanto eles se concentram na segurança da informação?

Às vezes vale a pena procurar soluções de sobreposição de monitoramento de infraestrutura em nuvem que possam complementar a segurança integrada na nuvem e, às vezes, essas soluções são a única opção para obter insights sobre a segurança de seus dados e aplicativos hospedados na nuvem. Além disso, são simplesmente mais convenientes, pois assumem todas as tarefas de análise dos logs necessários gerados por diferentes serviços em nuvem de diferentes provedores de nuvem. Um exemplo de tal solução de sobreposição é o Cisco Stealthwatch Cloud, que se concentra em uma única tarefa - monitorar 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 usando Stealthwatch Cloud

A AWS fornece uma plataforma de computação flexível, mas essa flexibilidade torna mais fácil para as empresas cometerem erros que levam a problemas de segurança. E o modelo compartilhado de segurança da informação só contribui para isso. Execução de software na nuvem com vulnerabilidades desconhecidas (as conhecidas podem ser combatidas, por exemplo, pelo AWS Inspector ou GCP Cloud Scanner), senhas fracas, configurações incorretas, insiders, etc. E tudo isso se reflete no comportamento dos recursos da nuvem, que podem ser monitorados pelo Cisco Stealthwatch Cloud, que é um sistema de monitoramento de segurança da informação e detecção de ataques. nuvens públicas e privadas.

Um dos principais recursos do Cisco Stealthwatch Cloud é a capacidade de modelar entidades. Com ele, você pode criar um modelo de software (ou seja, uma simulação quase em tempo real) de cada um dos seus recursos de nuvem (não importa se é AWS, Azure, GCP ou qualquer outro). Estes podem incluir servidores e utilizadores, bem como tipos de recursos específicos do seu ambiente de nuvem, tais como grupos de segurança e grupos de escala automática. Esses modelos usam fluxos de dados estruturados fornecidos por serviços em nuvem como entrada. Por exemplo, para AWS, seriam VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda e AWS IAM. A modelagem de entidades descobre 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 na nuvem). Essas funções incluem dispositivo móvel Android ou Apple, servidor Citrix PVS, servidor RDP, gateway de correio, cliente VoIP, servidor de terminal, controlador de domínio, etc. Em seguida, ele monitora continuamente seu comportamento para determinar quando ocorre um comportamento arriscado ou que ameaça a segurança. Você pode identificar adivinhação de senha, ataques DDoS, vazamento de dados, acesso remoto ilegal, atividade de código malicioso, verificação de vulnerabilidades e outras ameaças. Por exemplo, é assim que se parece a detecção de uma tentativa de acesso remoto de um país atípico para sua organização (Coréia do Sul) a um cluster Kubernetes via SSH:

E é assim que se parece o suposto vazamento de informações do banco de dados Postgress para um país com o qual não encontramos interação anteriormente:

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

Ou suponha que a instância do servidor na VPC nunca seja, por política, um destino de login remoto. Vamos supor ainda que este computador sofreu um logon remoto devido a uma alteração incorreta na política de regras de firewall. O recurso Modelagem de entidade detectará e relatará essa atividade (“Acesso remoto incomum”) quase em tempo real e apontará para 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 ).o que motivou a mudança na regra da UIT. E então essas informações podem ser enviadas ao SIEM para análise.

Recursos semelhantes são implementados para qualquer ambiente de nuvem compatível com Cisco Stealthwatch Cloud:

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

Alguém descobriu um backdoor no software que usamos?
Existe algum software ou dispositivo de terceiros em nossa nuvem?
O usuário autorizado está abusando de privilégios?
Houve um erro de configuração que permitiu acesso remoto ou outro uso não intencional de recursos?
Existe um vazamento de dados de nossos servidores?
Alguém estava tentando se conectar conosco de uma localização geográfica atípica?
Nossa nuvem está infectada com código malicioso?

Um evento de segurança da informação detectado pode ser enviado na forma de um ticket correspondente para o Slack, Cisco Spark, o sistema de gerenciamento de incidentes PagerDuty, e também enviado para vários SIEMs, incluindo Splunk ou ELK. Resumindo, podemos dizer que se sua empresa usa uma estratégia multinuvem e não está limitada a nenhum provedor de nuvem, os recursos de monitoramento de segurança da informação descritos acima, então usar o Cisco Stealthwatch Cloud é uma boa opção para obter um conjunto unificado de monitoramento. recursos para os principais players de nuvem – Amazon, Microsoft e Google. O mais interessante é que se você comparar os preços do Stealthwatch Cloud com licenças avançadas para monitoramento de segurança da informação em AWS, Azure ou GCP, pode acontecer que a solução Cisco seja ainda mais barata que os recursos integrados da Amazon, Microsoft e soluções do Google. É paradoxal, mas é verdade. 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 pode monitorar nuvens privadas implantadas em sua organização, por exemplo, com base em contêineres Kubernetes ou monitorando fluxos Netflow ou tráfego de rede recebido por meio de espelhamento em equipamentos de rede (mesmo produzidos internamente), dados AD ou servidores DNS e assim por diante. Todos esses dados serão enriquecidos com informações de Threat Intelligence coletadas pelo Cisco Talos, o maior grupo não governamental do mundo de pesquisadores de ameaças à segurança cibernética.

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

Com isso, completaremos a primeira parte do artigo, na qual revisei as ferramentas internas e externas de monitoramento da segurança da informação de plataformas IaaS/PaaS, que nos permitem detectar e responder rapidamente a incidentes ocorridos nos ambientes de nuvem que nossa empresa escolheu. Na segunda parte, continuaremos o tópico e veremos as opções de monitoramento de plataformas SaaS usando o exemplo de Salesforce e Dropbox, e também tentaremos resumir e juntar tudo criando um sistema unificado de monitoramento de segurança da informação para diferentes provedores de nuvem.

Fonte: habr.com

Monitoramento de segurança na nuvem