Cloud

Segurança em Cloud, por onde começar ?

Vamos do principio ok ? Mente aberta !! Mesmo você que não é de Cloud e nem de segurança!! 🙂

Segurança é uma coisa complicada e significa coisas diferentes para pessoas diferentes. Está verdadeiramente nos olhos de quem vê. Existe o tipo de caixa de seleção, existe o tipo “real”, há o tipo de caixa de seleção que se mantém, e há o tipo “real” que é contornado, e assim por diante. Não se engane: o tipo “absoluto” não existe.

Eu quero falar sobre soluções de segurança baseadas em dados de log a principio. Esse é o tipo de segurança que ocorre depois que a segurança de perímetro (firewalls), a detecção de intrusão (IDS / IPS), os scanners de vulnerabilidades e dezenas de outras tecnologias de segurança fazem sua parte. Ele une todas essas tecnologias, correlaciona seus eventos, reduz os falsos positivos e permite a investigação forense. Às vezes, essa tecnologia é chamada de Gerenciamento de Log e / ou Informações de Segurança e Gerenciamento de Eventos (SIEM). Eu costumava construir essas tecnologias anos atrás, mas parece que há décadas atrás.

Se você acredita que a implantação de um SIEM com a sua segurança de perímetro é uma defesa eficaz contra as crescentes ameaças que a sua rede corporativa enfrenta, você realmente vai aprender a verdade da maneira mais difícil.

Vamos a um pouquinho de história: O SIEM nasceu do SIM (Security Information Management). O SIM foi o resultado de um período de má conduta corporativa maciça nos primeiros dias do século XXI. A Enron, a Worldcom e outras foram as principais motivadoras da Sarbanes-Oxley. Um novo regime regulatório que levou executivos de conformidade a implantar o SIM como meio de fornecer evidências de que suas políticas de controle financeiro estavam implementadas e cumpridas. Como na maioria das iniciativas focadas em contabilidade, ela estava voltada para a retaguarda. O modelo de conformidade que orienta o SIM é entregue com base em requisitos de relatórios semanais, mensais, trimestrais e anuais, que acabam capturando incidentes passados. Isso mesmo, já foi!

Como o SIM se tornou comum em empresas de capital aberto (pense no ArcSight), algumas pessoas acharam que havia um jogo de segurança para o SIM. E assim, o SIEM foi inventado como uma nova categoria de produtos de segurança. A necessidade de gerenciar registros de segurança não era algo novo. Nos primeiros dias do IDS, havia um pouco de empolgação. Os sistemas IDS foram rapidamente implantados. No início dos anos 2000, eles eram comuns. Mas os sistemas IDS criaram um novo problema: eles geraram enormes quantidades de dados na forma de logs / alertas. Infelizmente, no mundo real da detecção de anomalias baseada em assinaturas (o cérebro central da maioria dos sistemas IDS), há muitos falsos positivos. Os sistemas IDS tinham limitações reais em sua capacidade de produzir resultados em preto e branco. Eles produzem muito cinza. Cinza é um problema. Cinza é barulho. E barulho significa trabalho extra.

A resposta a esse ruído foi terceirizar logs do IDS para terceiros. As empresas não podem justificar que os recursos filtrem os enormes registros em busca de ameaças. Por esta altura, um mercado chamado Managed Security Service Providers (MSSP) já estava em voo. Este mercado foi criado porque o gerenciamento de firewall tornou-se bastante difícil.

Firewalls como os da Checkpoint eram poderosos, mas exigiam alguma habilidade para gerenciar de forma eficaz. Essas habilidades estavam em falta (assim como a habilidade de segurança permanece escassa até hoje). Por isso, os MSSPs se concentraram em concentrar o talento em torno de um modelo que apoiava muitas redes corporativas. Foi valioso e assim o mercado MSSP cresceu. O problema de ruído do IDS era algo que os MSSPs estavam prontos e dispostos a ajudar a resolver. No entanto, o gerenciamento de logs / alertas de IDS requer uma abordagem diferente de um serviço de diretivas de firewall de controle de alterações.

Movendo o ruído gerado pelos sistemas de IDS para “especialistas”, os MSSPs resolveram um problema (ou pelo menos deram a impressão de resolver um problema) – “Temos pessoas inteligentes procurando ameaças em nossos registros de IDS”. Mas a verdade honesta e muitas vezes não ouvida é que, em última análise, confiar nos registros deixa você incapaz de tomar a ação apropriada, porque o ruído não pode se tornar um sinal sem um contexto melhor.

Não importa quanto tempo você olhe para um evento de registro do IDS, ele não será mais informativo. O mesmo é verdadeiro para a grande maioria dos eventos de log de segurança. Mas vamos deixar de lado a falha primária na segurança baseada em log por um momento.

Ponto 1: SIEM não escala
É bastante difícil capturar um terabyte de logs diários (40.000 eventos por segundo, 3 bilhões de eventos por dia) e armazená-los. É um par de ordens de grandeza mais difícil executar a correlação em tempo real e alertar quando algo de ruim acontece. As ferramentas SIEM são extraordinariamente difíceis de executar em escalas acima de 100 GB de dados por dia. Isso ocorre porque eles são projetados para dimensionar adicionando mais CPU, memória e discos rápidos à mesma caixa. O crescimento exponencial dos dados nas duas décadas em que essas ferramentas SIEM foram projetadas ultrapassou a capacidade de adicionar CPU, memória e eixos rápidos à caixa. Ah, mas eu uso na Nuvem, posso escalar facilmente….am ram, vai nessa.

Ponto 2: A normalização do SIEM não consegue acompanhar o ritmo
As ferramentas SIEM dependem da normalização (todos os dados) de todos os dados em um esquema comum, para que você possa gravar consultas em todos os eventos. Isso funcionou quinze anos atrás, quando as fontes eram poucas. Atualmente, as fontes e os tipos de infraestrutura estão se expandindo como nunca antes. Uma empresa pode ter vários fornecedores e versões de equipamentos de rede, muitas versões de sistemas operacionais, tecnologias de software livre, cargas de trabalho em execução na infraestrutura como um serviço (IaaS) e muitos aplicativos escritos personalizados. Escrever normalizadores para acompanhar a mudança de formatos de log não é possível.

Hoje, temos poderosos dispositivos de segurança, como NGFW, IPS / IDS, endpoint e tudo o que há entre implantados com políticas diluídas que comprometem a eficácia do perímetro. E mesmo usando a palavra perímetro, é um pouco de brincadeira hoje com a mobilidade dos endpoints.

Eu acho que Amit Yoran, o CEO da RSA Security, declarou o problema de forma bonita em sua palestra RSA de 2015 intitulada “Escapando na Idade das Trevas da Segurança” quando ele disse:

“No entanto, muitos profissionais de segurança baseiam seus programas na agregação fútil de telemetria desses IDS virtualmente cegos, plataformas antivírus e logs de firewall, implementando o glorioso e cada vez mais inútil pit de dinheiro, conhecido como SIEM. Sei que não surpreendeu muitos de vocês quando o Relatório de Investigações de Violações de Dados da Verizon do ano passado afirmou que menos de um por cento dos ataques bem-sucedidos de ameaças avançadas foram detectados pelos sistemas SIEM. Menos de 1%. O terreno mudou, mas ainda nos apegamos aos nossos mapas antigos. É hora de perceber que as coisas são diferentes.

Confiar exclusivamente em um SIEM para identificar e gerenciar ameaças é imprudente, é uma perspectiva contábil de “espelho retrovisor” que pode informar apenas sobre ameaças conhecidas com base apenas nos insights obtidos das defesas do perímetro, que são essencialmente inúteis quando se trata de ataques novos e inovadores. E sem contexto adicional, você não pode identificar uma ameaça real de um falso positivo mundano.

Só vai ficar mais difícil proteger suas redes. Você precisa adotar a realidade de que seus produtos de segurança de perímetro são terminais, por mais poderosos que sejam, acabarão por falhar ao lidar com algo diferente dos ataques de ontem. O jogo de segurança mudou da prevenção para a detecção. O novo plano de jogo exige não apenas um perímetro eficaz para bloquear a radiação de fundo, mas também exige um monitoramento contínuo que não dependa de um SIEM para sua visibilidade das ameaças.

Segurança é difícil sim. Mas pode ser muito mais fácil se você se concentrar no gerenciamento de ameaças de maneira eficaz e parar de se preocupar com quem finge oferecer segurança olhando seus registros.

Uma pergunta simples:

Quando você compra um carro, você lê o manual ?

E quando você vai para a AWS, Azure, ou qualquer outro provedor, você lê as recomendações de arquitetura ? De segurança ?

Alias, vamos simplificar a pergunta: Você tem alguma topologia, diagrama, ou papel de pão atualizado da sua rede ou de seus sistemas, e como eles interagem ?

Vamos ser sinceros. As pessoas querem comprar, antes de estudar segurança. Te garanto que existem produtos Open que atendem isso e muito mais. Basta pensar, e deixar qualquer curioso trabalhar em paz =)