jonrau1/syntheticsunFramework de automação de segurança serverless da AWS que ingere inteligência de ameaças, aplica detecção de anomalias baseada em ML (RCF, IP Insights) e enriquece a telemetria de segurança no Kibana para prevenção, detecção e resposta automatizada de ameaças.
SyntheticSun é um framework de automação e monitoramento de segurança em profundidade que utiliza inteligência contra ameaças, aprendizado de máquina, serviços de segurança gerenciados da AWS e tecnologias serverless para prevenir, detectar e responder continuamente a ameaças.
Você dorme em vidro fragmentado
Com reflexos de você,
Mas você se sente vivo?
Sim, deixe-me perguntar,
Você se sente vivo?
- Norma Jean, 2016
O SyntheticSun é construído em torno do uso da Malware Information Sharing Platform (MISP) e do Anomali LIMO, que são plataformas de inteligência contra ameaças (TIPs) orientadas pela comunidade que fornecem vários tipos de indicadores de comprometimento (IoCs). A inteligência contra ameaças normalizada e deduplicada é consultada em tempo quase real para identificar rapidamente ameaças conhecidas em vários tipos de tráfego de rede. Para adicionar dinamismo à identificação de ameaças potenciais, modelos do IP Insights são implantados para encontrar anomalias (e ameaças potenciais nelas) entre o pareamento de endereços IP e entidades (como IDs de principal do IAM, user-agents, etc.). Detectores RCF nativos também são usados no Elasticsearch para encontrar anomalias na telemetria de segurança em tempo quase real à medida que é transmitida para o Kibana. Para democratizar o uso e ajuste fino de modelos de ML dentro das equipes de segurança, utilitários para treinar modelos do IP Insights são fornecidos como um complemento à solução principal.
Para realizar tanto a orquestração e automação quanto a extração, transformação e carregamento (ETL) da telemetria de segurança no Kibana, várias tecnologias serverless da AWS, como AWS Lambda, Amazon DynamoDB e AWS CodeBuild, são utilizadas. Tecnologias serverless como essas são usadas por sua escalabilidade, facilidade de uso, custos relativamente baixos em comparação com soluções pesadas baseadas em MapReduce ou Glue ETL. A maior parte da solução é implantada via CloudFormation com scripts auxiliares em Python e shell fornecidos ao longo dos vários Estágios para promover a adoção e a potencial implantação em pipelines de integração contínua.
Para tornar os "componentes internos" da solução o mais enxutos possível, módulos Python básicos como boto3, requests, json, ipaddress, socket e re realizam a maior parte da extração, transformação e carregamento (ETL) para serviços downstream. Como todas as informações de geolocalização são fornecidas pelo ip-api.com, ele não requer conta ou níveis pagos e possui uma ótima API que inclui informações de limitação (throttling) nos cabeçalhos de resposta. A maioria das dependências do Elasticsearch e Kibana também é fornecida em código (índices, mapeamentos, visualizações, etc.) para evitar configuração manual pesada.
O SyntheticSun está distribuído em três Estágios devido ao tamanho da solução e às dependências necessárias. Toda a arquitetura e instruções de instalação (e FAQs quando apropriado) estão dentro de seu próprio Estágio. Módulos adicionais (chamados de Apêndices) também são fornecidos para estender a funcionalidade, com sua própria arquitetura e instruções de instalação localizadas.
O SyntheticSun, por ser algo que você encontrou no GitHub, é uma prova de conceito e, portanto, não me esforcei ao máximo na primeira versão para endurecer absolutamente tudo. Desde que você esteja lendo isso em um ponto no tempo em que eu não fiz as mudanças necessárias, considere o seguinte antes de implantar esta solução em um ambiente de produção (ou qualquer ambiente com necessidades de segurança elevadas). Colocarei esses itens em um roteiro e os atualizarei conforme apropriado.
O SyntheticSun é uma maneira fácil de começar a usar inteligência contra ameaças cibernéticas e aprendizado de máquina para seus casos de uso de segurança de borda na Nuvem AWS sem precisar investir em uma ou mais ferramentas comerciais, ou contratar um cientista de dados para sua equipe de segurança (embora idealmente você deva fazer o último). Esta solução, após a configuração inicial, é totalmente automatizada, permitindo identificar e responder a ameaças na velocidade da máquina. Finalmente, esta solução fornece visualizações básicas para sua equipe de resposta a incidentes usar na resposta a ameaças, como conexões de entrada ou saída permitidas ou consultas DNS para e de endereços IP ou domínios considerados maliciosos. O núcleo da solução depende de pipelines de automação e engenharia de dados muito leves, que, teoricamente, podem ser reutilizados para outros fins onde seja necessária normalização e enriquecimento em vários estágios ou trabalhos em lote rápidos e agendados.
Em primeiro lugar, se você está usando Amazon GuardDuty e/ou AWS WAF, pode fazer sentido avaliar esta solução, mas também é um requisito. Personas óbvias que podem se beneficiar são equipes de produto responsáveis por proteger sua pilha completa e que não têm capital ou conhecimento para modelar, treinar e implantar algoritmos de aprendizado de máquina ou operacionalizar feeds de inteligência contra ameaças cibernéticas de forma significativa. Essas personas mencionadas são provavelmente engenheiros de segurança, analistas e engenheiros de SecOps/SOC, ou um engenheiro DevSecOps; no entanto, esta lista não é exaustiva, e eles não precisam estar alinhados a produtos/aplicações, pois equipes centrais também podem usar isso. Outro uso é para essas mesmas personas (SecOps, engenharia de segurança) que trabalham para uma equipe centralizada e desejam criar uma lista de bloqueio dinâmica para firewalls e sistemas de prevenção de intrusão; os projetos do CodeBuild podem ser reaproveitados para soltar arquivos CSV ou planos em quase qualquer local (por exemplo, firewalls Palo Alto, filtros de URL do proxy forward Squid, etc.).
O SyntheticSun atualmente não possui cobertura total em todas as principais fontes de log - principalmente, S3 Access Logs e CloudFront Access Logs, que são essenciais para a forma como muitas pessoas entregam serviços (especialmente para SPAs em buckets S3). A detecção de anomalias não se estende além de WAF, API Gateway Access Logs ou CloudTrail devido à minha obsessão por IP Insights e completa falta de qualquer treinamento em ciência de dados (sério, nem sei usar pandas ou numpy). Não há nenhuma análise aprofundada dos IoCs brutos de inteligência contra ameaças, além de tentar combiná-los nos logs.
A maneira mais fácil de implantar esta solução para uma organização é implantá-la em uma conta centralizada de serviços de segurança. Para a telemetria de nível inferior, como VPC Flow Logs e WAF Logs, você deve considerar fornecer scripts auxiliares ou modelos do CloudFormation via AWS Service Catalog para promover a ativação em ambientes inferiores. Você precisará avaliar seu consumo de shards e rotação de índices do Elasticsearch Service, bem como as permissões, se você tiver streams de entrega do Kinesis Data Firehose entre contas publicando em um local centralizado. Eu construí esta solução na minha conta sandbox pessoal, por isso não incorporei nenhuma das considerações acima na solução; ficarei feliz em trabalhar em um PR com isso em mente e posso fazê-lo eu mesmo no futuro.
A partir de 31 DE JULHO DE 2020, as Políticas do AWS Firewall Manager suportam a agregação multi-conta do Logging do WAF, o que te aproxima um passo de tornar isso muito menos doloroso...
RESSALVAS: Não sou um cientista de dados e esta será uma resposta longa. Resumo: É um localizador de anomalias, e acho que sim?
Dado que não estou nem remotamente perto de ser um cientista de dados ou ter qualquer treinamento, você é melhor servido lendo a documentação sobre isso. Dito isso, aqui está minha tentativa leiga: IP Insights é um algoritmo de aprendizado de máquina não supervisionado que aprende a relação entre um endereço IPv4 e uma entidade (por exemplo, número de conta, nome de usuário, user-agent). O IP Insights então tenta determinar qual a probabilidade de a entidade usar aquele endereço IPv4. Por trás das cortinas do IP Insights há uma rede neural que aprende a representação vetorial latente dessas entidades e endereços IPv4. A distância entre essas representações vetoriais é emblemática de quão anômalo (ou não) é para uma entidade estar associada a (por exemplo, enviar uma solicitação de) um endereço IPv4.
Redes neurais são quase exatamente como soam; elas formam um sistema de aprendizado de máquina projetado para se comportar de maneira semelhante ao cérebro humano, completo com neurônios e sinapses computadorizadas. No aprendizado de máquina não supervisionado, o algoritmo pode descobrir como é "bom" (ou seja, Verdadeiro Negativo) versus "ruim" (ou seja, Verdadeiro Positivo) observando a associação entre todos os endereços IPv4 e suas entidades pareadas. Essa associação é avaliada para identificar quais vetores são semelhantes aos outros por sua "distância". No caso do IP Insights, um codificador pré-construído é fornecido que procura endereços IPv4 e então agrupa todas as entidades em clusters. Ele então itera sobre eles usando vetorização. Vetorização é uma maneira de realizar computações como uma matriz em vez de iterar sobre eles (pense em um loop "For" para uma lista contendo dezenas de milhões de valores).
Quando você está treinando um modelo do IP Insights, ele realmente criará falsos positivos para si mesmo ao parear endereços IPv4 com entidades que têm uma distância grande (ou seja, altamente anômalas) e são menos prováveis de realmente ocorrer na realidade; o modelo agora pode discriminar entre Verdadeiros Positivos, Falsos Positivos e Verdadeiros Negativos. Isso é feito para evitar outro termo maluco chamado "entropia cruzada" (também conhecido como "perda de log", como se isso melhorasse), e introduz outro termo, classificação binária. O IP Insights está essencialmente perguntando: "Qual é a chance de que este endereço IP pareado com esta entidade seja anômalo?" Isso é o que o torna binário, eu acho, então "sim, é ruim" ou "não, não é". A probabilidade é representada como um valor entre 0 e 1, o objetivo de todos os modelos de aprendizado de máquina é tornar isso o mais próximo possível de 0, então prever um valor de 0,01 para algo que é realmente 1 (Verdadeiro Positivo conhecido) resultaria em uma perda de log muito alta. Então, com tudo isso dito, ao criar dados deliberadamente ruins, o IP Insights ajuda a reduzir essa perda de log (ou seja, previsões ruins) durante o treinamento.
Isso nos leva à saída do endpoint. Quando você o consulta (seja em lotes ou em tempo quase real usando a API InvokeEndpoint), a resposta é um float ilimitado que pode ser negativo ou positivo. Quanto mais acima de 0, mais provável é que seja anômalo, e é aí que seu trabalho começa. Para esta solução, escolhi qualquer coisa acima de 0,03, o que é amplamente nocional; para chegar mais perto da verdade, você deve fornecer Verdadeiros Positivos ao endpoint e ver qual é a sua resposta. Com base nesses achados, você pode configurar uma abordagem em camadas onde sua aplicação pode emitir um desafio de segundo fator, gerar um alerta ou bloquear diretamente, dependendo da pontuação. A resposta para a segunda parte da pergunta é "Sim, eu acho que sim"; treinar o modelo com user-agents pareados com um IP é realmente bastante arriscado. Agora, para outras entidades menos voláteis (número de conta, nome de usuário, usuário IAM), parece ser o uso pretendido.
Na solução, forneço alguns feeds de exemplo que você deve usar; alguns são bastante óbvios, como o feed de domínios de crimes cibernéticos, Emerging Threats e CI-badguys. No meu trabalho real, trabalho com uma das especialistas em inteligência contra ameaças cibernéticas mais talentosas do mundo (sem brincadeira, ela é incrível!), que também influenciou as escolhas. Como modelos de aprendizado de máquina e qualquer outra coisa que você construirá, você deve adaptar seus feeds de inteligência contra ameaças e agregação para corresponder ao seu ambiente de ameaças atual. Duplicatas são identificadas no MISP e apenas uma chave hash é especificada nas tabelas do DynamoDB para impor a exclusividade, então mesmo que haja 5 feeds relatando o mesmo endereço IPv4, apenas um chegará à tabela.
Você também pode trazer suas próprias plataformas e feeds de inteligência contra ameaças comerciais, como InfoBlox ou Recorded Future, para esta solução, apontando-os para as tabelas do DynamoDB com sintaxe semelhante.
A maioria da entrega de logs da AWS é "melhor esforço", então não há um SLA oficial publicado; no entanto, eu assumiria que é em torno de 99,5 - 99,9%, onde qualquer coisa nesses últimos 0,5 - 0,1% não será entregue. O tráfego de "produção" também é primeira classe na AWS; se houver restrições de largura de banda de rede, ele priorizará a entrega de conectividade de volta aos clientes em vez de enviar logs. O evento mais provável é que o arquivo de log bruto era muito grande para o Lambda processar a coisa toda a tempo; você vê isso muito quando está sendo atacado por um DOS ou crawler do mesmo IP de cliente. WAF e ALB agrupam arquivos de log por chamador (pelo que posso dizer), então se você absorver centenas de solicitações, o arquivo de log pode ser muito grande.
Sim, no entanto, você precisará realizar uma das seguintes ações:
Há custos adicionais para isso. Lambda em uma VPC, especialmente para dezenas de invocações concorrentes, provavelmente levará a mais problemas com ENIs que não são liberados e consomem seu espaço RFC1918. A menos que você absolutamente precise isolar todo o tráfego dentro da sua VPC para atender aos requisitos de conformidade, eu não seguiria esse caminho.
Sim, isso é alcançável modificando a solução para publicar os logs finais formatados no Kinesis Data Firehose e apontá-los para o Splunk.
Espero ter suporte para Route 53 DNS Logs, S3 Access Logs, CloudFront Access Logs e API Gateway Access Logs e talvez alguns outros logs baseados em host no futuro.
Honestamente, eu teria preferido usar o Kinesis Data Agent, mas encontrei muitos problemas com ele: Ele não está incluído por padrão no Amazon Linux 2 e agora que as AMIs do Ubuntu 18.04 LTS vêm com Java 11 pré-instalado, estava encontrando problemas de compatibilidade reversa com o Agent, pois ele falha no build a menos que você tenha OpenJDK 8 ou 9. Foi muito mais fácil instalar o CloudWatch Agent, pois é frequentemente atualizado com novos recursos e há suporte do Systems Manager Document para configuração; ele até tem um assistente para instalação. Se a AWS algum dia levar o suporte ao Kinesis Data Agent tão a sério quanto o CloudWatch Agent, posso mudar para ele, pois preferiria publicar diretamente no Kinesis Data Firehose para certos logs baseados em host (Suricata, Squid, Nginx, Apache) em vez de usar o CloudWatch Logs como intermediário.
Ficarei feliz em aceitar PRs para itens marcados como "Help Wanted" nas Issues ou no Quadro de Projetos. Também revisarei quaisquer outros PRs propostos, desde que estejam de acordo com o espírito do projeto.
Agradecimentos especiais a David Dorsey e Ryan Nolette que forneceram feedback valioso, testes e contribuições para ajudar a ajustar o SyntheticSun.
Esta biblioteca está licenciada sob a GNU General Public License v3.0 (GPL-3.0). Consulte o arquivo LICENSE.
