O SyntheticSun foi desenvolvido em torno do uso da Plataforma de Compartilhamento de Informações de Malware
SyntheticSun
SyntheticSun é uma estrutura de monitoramento e automação de segurança de defesa em profundidade que utiliza inteligência contra ameaças, aprendizado de máquina, serviços de segurança gerenciados da AWS e tecnologias sem servidor para prevenir, detectar e responder continuamente às ameaças.
Você dorme em vidro fragmentado
Com reflexos de você,
Mas você está se sentindo vivo?
Sim, deixe-me perguntar:
Você está se sentindo vivo?
- Norma Jean, 2016
Sinopse
- Usa automação sem servidor baseada em evento e tempo (por exemplo, AWS CodeBuild, AWS Lambda) para coletar, normalizar, enriquecer e correlacionar a telemetria de segurança em Kibana
- Aproveita a inteligência de ameaças, dados de geolocalização, inteligência de código aberto, detecção de anomalias apoiadas por aprendizado de máquina (ML) e APIs da AWS para enriquecer ainda mais a telemetria de segurança e identificar ameaças potenciais
- Aproveita os algoritmos Random Cut Forests (RCF) e IP Insights de ML não supervisionados para identificar anomalias em séries temporais e dados de pares de entidades IP, respectivamente. Recursos orquestrados por contêineres sem servidor são fornecidos para treinar e implantar novos endpoints do IP Insights à vontade.
- Atualiza dinamicamente conjuntos de IPs AWS WAFv2 e conjuntos de informações de ameaças Amazon GuardDuty para reforçar a proteção de sua conta e infraestrutura contra ameaças conhecidas
Descrição
O SyntheticSun foi desenvolvido em torno do uso da Plataforma de Compartilhamento de Informações de Malware (MISP) e do LIMO da Anomali, que são plataformas de inteligência de ameaças (TIPs) conduzidas pela comunidade que fornecem vários tipos de indicadores de comprometimento (IoC). As informações de ameaças normalizadas e não duplicadas são pesquisadas 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 em potencial, os modelos de IP Insights são implantados para encontrar anames (e ameaças em potencial) entre o emparelhamento de endereços IP e entidades (como IDs principais IAM, usuários-agentes, etc.), detectores RCF nativos são também usado no Elasticsearch para encontrar anomalias na telemetria de segurança quase em tempo real à medida que é transmitido para Kibana. Para democratizar o uso e o ajuste fino dos modelos de ML nas equipes de segurança,
Para realizar a orquestração e automação, bem como extração, transformação e carregamento (ETL) de telemetria de segurança em Kibana, várias tecnologias sem servidor da AWS, como AWS Lambda, Amazon DynamoDB e AWS CodeBuild são usadas. Tecnologias sem servidor como essas são usadas por sua escalabilidade, facilidade de uso, custos relativamente baratos versus soluções baseadas em MapReduce ou Glue ETL pesadas. A maior parte da solução é implantada via CloudFormation com scripts auxiliares em Python e shell fornecidos em vários estágios para promover a adoção e a implantação potencial em pipelines de integração contínua.
Para fazer com que as "entranhas" da solução como magra como módulos possível Python básico, tal como boto3, requests, json, ipaddress, sockete reexecutar a maior parte da extracção, a transformação, e carga (ETL) em serviços a jusante. Como todas as informações de geolocalização são fornecidas pelo ip-api.com , ele não requer uma conta ou níveis pagos e tem uma ótima API que inclui informações de limitação em seus cabeçalhos de resposta. A maioria das dependências Elasticsearch e Kibana também são fornecidas em código (indicadores, mapeamentos, visualizações, etc.) para evitar configuração manual pesada.
Configurando
SyntheticSun é distribuído por três estágios devido ao tamanho da solução e às dependências necessárias. Todas as instruções de arquitetura e instalação (e FAQs quando apropriado) vivem em seu próprio Palco. Módulos de complementos (chamados de Apêndice) também são fornecidos para estender a funcionalidade, que têm sua própria arquitetura e instruções de instalação localizadas.
Antes de começar: Considerações para implantações de produção
SyntheticSun, por ser algo que você encontrou no GitHub, é uma prova de conceito e, portanto, não me esforcei muito para que o primeiro lançamento tornasse tudo mais rígido. Desde que você esteja lendo isso em um momento em que eu não tenha feito as alterações 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). Vou colocar esses itens em um roteiro e atualizá-los conforme apropriado.
- Treinar seus próprios modelos Insights IP usando os exemplos fornecidos no Apêndice A . Usar seus próprios dados e treinar continuamente o modelo ajudará a acertar as descobertas.
- Implante seus projetos CodeBuild, servidor MISP e domínio Elasticsearch Service em um VPC para se proteger contra ataques originados na Internet. Considere o uso de VPN cliente da AWS, VPN site a site AWS, DirectConnect, Amazon Workspaces e AppStream 2.0 ou (se for absolutamente necessário) um proxy reverso para acessar o console MISP e Kibana dentro de um VPC.
- Considere o uso do Cognito para AuthN no Kibana. Dê um passo adiante e associe seu Pool de usuários ao IdP corporativo.
- Considere preparar seu próprio AMI para MISP ou use o Fargate para hospedá-lo. Eu também consideraria pré-assar Suricata e o Agente Amazon CloudWatch em compilações futuras para ajudar a dimensionar implantações de agentes e HIDPS em sua propriedade.
- Modifique sua configuração Suricata para atender às necessidades de suas equipes SecOps olhando os logs, uma vez que tudo que esta solução faz é despejá-los. Você também pode considerar escrever suas próprias regras ou importar outras fontes para proteger seus hosts contra ataques.
Pré-requisitos
- Acesso de administrador a uma conta da AWS (se você estiver usando isso em uma implantação de várias contas, você deve estar na conta onde seus mestres ou administradores mestres delegados estão localizados)
- Balanceador de carga de aplicativo (ALB) com pelo menos uma instância de destino e logs de acesso habilitados
- Log do CloudTrail habilitado em sua conta
- Um VPC com pelo menos uma sub-rede privada (rota para NATGW), uma sub-rede pública (rota para IGW) e registros de fluxo de VPC habilitados, bem como publicados em CloudWatch Logs
Perguntas frequentes
1. Por que devo usar esta solução?
SyntheticSun é uma maneira fácil de começar a usar inteligência de ameaças cibernéticas e aprendizado de máquina para seus casos de uso de segurança de proteção de borda na nuvem AWS sem ter que investir em uma ou mais ferramentas comerciais ou contratar um cientista de dados para sua equipe de segurança (embora você deva idealmente faça o último). Esta solução, após a configuração inicial, é totalmente automatizada, permitindo identificar e responder às ameaças na velocidade da máquina. Finalmente, esta solução fornece visualizações básicas para sua equipe de resposta a incidentes usar para resposta a ameaças, como conexões de entrada ou saída permitidas ou consultas DNS de e para endereços IP ou domínios considerados maliciosos. O núcleo da solução depende de automação muito leve e pipelines de engenharia de dados, que teoricamente,
2. Quem deve usar esta solução?
Em primeiro lugar, se você estiver usando o Amazon GuardDuty e / ou AWS WAF, pode fazer sentido avaliar esta solução, mas também é um requisito. Pessoas óbvias que podem tirar vantagem são as equipes de produto responsáveis por proteger sua pilha completa e não têm capital ou experiência para modelar, treinar e implantar algoritmos de aprendizado de máquina ou operacionalizar feeds de inteligência de 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 de DevSecOps; no entanto, essa lista não é exaustiva e eles não precisam ser alinhados ao produto / aplicativo, pois as equipes centrais também podem usá-la. Outro uso são as 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,
3. Quais são as lacunas nesta solução?
SyntheticSun atualmente carece de cobertura total em todas as principais fontes de log - ou seja, S3 Access Logs e CloudFront Access Logs, que são essenciais para a forma como muitas pessoas fornecem serviços (especialmente para SPAs em baldes S3). A detecção de anomalia não se estende além de WAF, API Gateway Access Logs ou CloudTrail devido à minha obsessão com IP Insights e completa falta de qualquer treinamento em ciência de dados (sério, eu nem sei como usar pandasou numpy). Não há nenhuma análise aprofundada dos IoCs de inteligência de ameaças brutos, exceto a tentativa de combiná-los nos logs.
4. Fora dos mestres para os serviços de segurança da AWS, quais considerações existem para uma implantação organizacional?
A maneira mais fácil de implantar essa solução para uma organização é implantá-la em uma conta de serviços de segurança centralizada. Para a telemetria de nível inferior, como VPC Flow Logse registros WAF, você deve considerar o fornecimento de scripts auxiliares ou modelos do CloudFormation por meio do AWS Service Catalog para promover a ativação em ambientes inferiores. Você precisará avaliar o consumo de fragmentos e a rotação do índice do Elasticsearch Service, bem como as permissões, se deseja publicar fluxos de entrega do Kinesis Data Firehose entre contas em um local centralizado. Eu criei essa solução em minha conta de sandbox pessoal, portanto, por que não incorporei nenhuma das considerações acima na solução, ficarei feliz em trabalhar em um RP com isso em mente e posso fazer isso sozinho no futuro.
A partir de 31 de julho de 2020, as políticas do AWS Firewall Manager suportam a agregação de várias contas do WAF Logging, o que o deixa um passo mais perto de tornar isso muito menos doloroso ...
5. O que é o algoritmo do IP Insights? O seu uso é realmente o que foi planejado?
CAVEATS : Não sou um cientista de dados e essa vai ser uma resposta longa. Tl; dr: É um localizador de anomalias e eu acho?
Visto que não sou nem remotamente próximo de um cientista de dados ou tenho qualquer treinamento, é melhor ler os documentos 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, agente de usuário). Em seguida, o IP Insights tenta determinar a probabilidade de a entidade usar esse endereço IPv4. Por trás das cortinas do IP Insights está uma rede neural que aprende a representação vetorial latente dessas entidades e endereços IPv4. A distância entre essas representações vetorizadas é emblemática de quão anômalo (ou não) é para uma entidade estar associada (por exemplo, enviar uma solicitação de) um endereço IPv4.
As redes neurais são quase exatamente como parecem; eles formam um sistema de aprendizado de máquina projetado para se comportar de forma semelhante ao cérebro humano, completo com neurônios computadorizados e sinapses. No aprendizado de máquina não supervisionado, o algoritmo pode descobrir qual é a aparência de "bom" (ou seja, verdadeiro negativo) versus "ruim" (ou seja, verdadeiro positivo) observando a associação entre todos os endereços IPv4 e suas entidades emparelhadas. Esta associação é avaliada a fim de identificar quais vetores se assemelham aos demais pela sua "distância". No caso do IP Insights, é fornecido um codificador pré-construído que pesquisa endereços IPv4 e, em seguida, faz o hash de todas as entidades em clusters. Em seguida, itera sobre eles usando vetorização. A vetorização é uma forma de realizar cálculos como uma matriz em vez de fazer um loop sobre eles (pense em um "For"
Quando você está treinando um modelo de Insights de IP, ele na verdade cria falsos positivos ao emparelhar endereços IPv4 com entidades que têm uma distância distante (ou seja, altamente anômalas) e têm menos probabilidade 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 o tornasse melhor) e introduz outro termo, classificação binária. O IP Insights está essencialmente perguntando: "Qual é a chance de este endereço IP emparelhado com esta entidade ser 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, portanto, prever um valor de 0,01 para algo que é realmente 1 (conhecido como positivo verdadeiro) resultaria em uma perda de log muito alta. Portanto, com tudo o que foi dito, ao fazer propositalmente lixo de dados IP Insights ajuda a reduzir a perda de log (ou seja, previsões ruins) durante o treinamento.
Isso nos leva à saída do terminal. Quando você o consulta (por meio de lotes ou quase em tempo real, usando oInvokeEndpointAPI) a resposta é uma flutuação ilimitada que pode ser negativa ou positiva. Quanto mais alto for acima de 0, mais provável será anômalo, que é onde 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 True Positives para o ponto de extremidade e ver qual é a sua resposta. Com base nessas descobertas, você pode configurar uma abordagem em camadas em que seu aplicativo pode emitir um segundo desafio de fator, gerar um alerta ou bloqueá-lo imediatamente, dependendo da pontuação. A resposta para a segunda parte da pergunta é "Sim, eu acho que sim", treinar o modelo com agentes de usuário emparelhados com um IP é, na verdade, muito incompleto. Agora, para outras entidades menos voláteis (número da conta, nome do usuário, usuário IAM), parece o uso pretendido.
6. Quais feeds de inteligência de ameaças devo usar? O que acontece se houver duplicatas?
Na solução, apresento alguns feeds de exemplo que você deve usar, alguns são bastante óbvios, como o feed de domínio do crime cibernético, Ameaças emergentes e bandidos da CI. No meu trabalho real, trabalho com um dos mais talentosos especialistas em inteligência de ameaças cibernéticas do mundo (não é brincadeira, ela é incrível!), Que também influenciou as escolhas. Assim como os modelos de aprendizado de máquina e qualquer outra coisa que você construir, você deve adaptar seus feeds e agregação de inteligência de ameaças para corresponder ao seu ambiente de ameaças atual. As duplicatas são identificadas no MISP e apenas uma chave hash é especificada nas tabelas do DynamoDB para garantir a exclusividade, portanto, mesmo se houver 5 feeds relatando no mesmo endereço IPv4, apenas um chegará à mesa.
Você também pode trazer suas próprias plataformas e feeds intel de ameaças comerciais, como InfoBlox ou Recorded Future, para essa solução, apontando-os para as tabelas do DynamoDB com sintaxe semelhante.
7. Eu pesquisei as fontes de log brutas no S3 e não estou vendo as entradas no Elasticsearch; por que é isso?
A maior parte da entrega de log da AWS é "melhor esforço", portanto, não há um SLA oficial publicado; no entanto, eu presumiria que está em torno de 99,5 - 99,9%, onde qualquer coisa nos últimos 0,5 - 0,1% não será entregue. O tráfego de "produção" também é de primeira classe na AWS; se houver restrições de largura de banda de rede, o padrão será entregar 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 tudo a tempo; você vê muito isso quando está sendo hospedado por um DOS ou rastreador do mesmo IP de cliente. WAF e ALB agrupam arquivos de log pelo chamador (pelo que posso dizer), portanto, se você absorver centenas de solicitações, o arquivo de log pode ser muito grande.
8. Eu tenho um domínio existente do Elasticsearch Service em um VPC; essa solução funcionará?
Sim, no entanto, você precisará realizar um dos seguintes:
- Coloque as funções Lambda em um VPC e anexe Endpoints VPC para S3, DynamoDB e CloudWatch Logs.
- Como alternativa, modifique a solução para publicar os logs formatados finais no Kinesis Data Firehose e direcione-os para seu domínio ES em um VPC.
Existem custos adicionais para isso. Lambda em um VPC, especialmente para dezenas de invocações simultâneas, provavelmente levará a mais problemas de ENIs permanecendo e comendo seu espaço RFC1918. A menos que seja absolutamente necessário isolar todo o tráfego em seu VPC para atender aos requisitos de conformidade, eu não seguiria por esse caminho.
9. Em vez disso, posso publicar essas fontes de registro no Splunk?
Sim, isso é possível modificando a solução para publicar os logs formatados finais no Kinesis Data Firehose e direcioná-los para o Splunk.
10. Você oferecerá suporte a outras fontes de registro?
Espero ter suporte para Route 53 DNS Logs, S3 Access Logs, CloudFront Access Logs e registros de acesso de gateway de API e talvez alguns outros logs baseados em host no futuro.
11. Por que você usou o CloudWatch Agent em vez do Kinesis Data Agent?
Eu honestamente 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 o Ubuntu 18.04 LTS AMIs vem com o Java 11 pré-instalado, eu estava executando em problemas de compatibilidade com versões anteriores com o Agente, pois ele falha na construção, a menos que você tenha o OpenJDK 8 ou 9. Era muito mais fácil instalar o Agente CloudWatch, pois ele é atualizado frequentemente com novos recursos e há suporte de Documento do Gerenciador de Sistemas para configuração; tem até um assistente para instalação. Se a AWS levar o suporte do Kinesis Data Agent tão a sério quanto o CloudWatch Agent, posso mudar para ele, pois prefiro publicar no Kinesis Data Firehose diretamente para determinados logs baseados em host (Suricata, Squid, Nginx, Apache) em vez de usar CloudWatch Logs como um intermediário.
Contribuindo
Fico feliz em aceitar PRs para itens marcados como "Procura-se ajuda" no Issues ou no painel do projeto. Também analisarei quaisquer outros PRs propostos, se atenderem ao espírito do projeto.
Contribuintes iniciais
Agradecimentos especiais a David Dorsey e Ryan Nolette que forneceram feedback valioso, testes e contribuições para ajudar a ajustar o SyntheticSun.
Licença
Esta biblioteca está licenciada sob a licença GNU General Public License v3.0 (GPL-3.0). Veja o arquivo de LICENÇA.
Comentários
Postar um comentário