Em suma, direi que emulou uma cidade bem desenvolvida e bastante grande, na qual havia praticamente tudo - do aeroporto às instituições financeiras e um parque de diversões! Isso deu aos invasores a oportunidade de mostrar suas habilidades de hacker e aos defensores suas habilidades de detecção e repelimento de ameaças.
Então, surgiu a pergunta: como podemos “observar” essa batalha do ponto de vista da segurança da informação? Na verdade, este artigo trata dos detalhes da construção desse processo de observação e dos resultados que obtivemos.
Entendemos que não devemos interferir no funcionamento do polígono, e que o formato do evento não nos permite realizar ajustes detalhados de perfis de detecção de ataques, por isso foram escolhidas soluções de classe NTA (NTA - Network Traffic Analytics) - são soluções que identificam ameaças por meio da análise de telemetria de rede , ou, simplesmente, o perfil de tráfego de rede. A implementação de tais sistemas é muito mais simples e contínua do que, por exemplo, a implementação de sistemas clássicos de detecção e prevenção de intrusão. Isso se deve ao fato de que não há necessidade de fazer alterações na topologia da rede, bem como ao fato de que o núcleo de tais sistemas é o aprendizado de máquina combinado com dados de inteligência de ameaças. Esta abordagem permite que o sistema não apenas identifique rapidamente ameaças típicas, mas também "aprenda" ao longo de um determinado período de tempo,e então usar o conhecimento adquirido para detectar comportamento anormal do usuário, sistema e aplicativo. Além disso, esses sistemas, simplesmente por sua abordagem, são significativamente menos "barulhentos" em termos de alerta sobre todos os tipos de ameaças e muito mais precisos em termos de identificação de incidentes reais. Sobre isso, vou encerrar uma pequena excursão neste tema, quem quiser ler mais sobre isso, aconselho a atenção
neste material .
Inicialmente, decidi usar o conhecido produto Cisco Stealthwatch Enterprise, que é usado com sucesso por muitos de meus colegas em diferentes organizações. E eu estava prestes a ligar para meus colegas da Positive para dizer quantos processadores, espaço em disco, máquinas virtuais, etc. eu preciso. Naquele momento, um pensamento estranho me ocorreu - eu me lembrei de quantos recursos, tanto humanos quanto técnicos, foram empregados para criar este polígono cibernético, e pensei que ninguém esperava que eu pedisse alguns desses recursos. Por outro lado, não queria desistir da ideia e, no quadro das tendências modernas em segurança da informação, decidi mudar para uma solução em nuvem chamada Stealthwatch Cloud. Devo dizer que esta solução se chama nuvem por uma razão, já que é capaz de coletar e analisar telemetria de nuvens privadas,criado dentro de nuvens públicas por meio de interfaces de programação de aplicativos (API). Ou seja, com a ajuda desta solução, posso analisar, do ponto de vista da segurança da informação, o que está acontecendo dentro do Amazon AWS, Microsoft Azure, Google GCP, além dos containers Kubernetes. Mas agora eu precisava de outro aplicativo para este produto - ou seja, monitoramento de redes privadas. Nesse caso, um sensor (sensor) é simplesmente instalado em tal grade, que envia telemetria para o console de monitoramento e controle baseado em nuvem. Na frase anterior usei a palavra "simples" e agora tentarei expandi-la com mais detalhes.bem como contêineres Kubernetes. Mas agora eu precisava de outro aplicativo para este produto - ou seja, monitoramento de redes privadas. Nesse caso, um sensor (sensor) é simplesmente instalado em tal grade, que envia telemetria para o console de monitoramento e controle baseado em nuvem. Na frase anterior usei a palavra "simples" e agora tentarei expandi-la com mais detalhes.bem como contêineres Kubernetes. Mas agora eu precisava de outro aplicativo para este produto - ou seja, monitoramento de redes privadas. Nesse caso, um sensor (sensor) é simplesmente instalado em tal grade, que envia telemetria para o console de monitoramento e controle baseado em nuvem. Na frase anterior usei a palavra "simples" e agora tentarei expandi-la com mais detalhes.
Então, como é o processo?
Você precisa solicitar um teste, que leva alguns minutos.
Link aqui .
Então, em alguns dias, várias cartas úteis começam a chegar e no final surge uma carta informando que o portal é ativado!
Depois disso, você obtém um portal pessoal, cujo link se parece com este:
cisco-YOUR_CISCO_USERNAME.obsrvbl.com , por exemplo: cisco-mkader.obsrvbl.com .
Entrando lá, vemos a tela principal, de onde você pode baixar uma máquina virtual de sensores para monitorar redes privadas. Os requisitos para esta máquina virtual não são grandes - 2 vCPUs, 2 gigabytes de memória e 32 gigabytes de espaço em disco. Em geral, o processo de instalação é extremamente simples e é descrito em um manual extraordinariamente simples e conveniente, feito na forma de um e-book rolável .
Devo dizer desde já que o sensor possui duas interfaces - uma serve para comunicação com o console de controle e também coleta sobre si mesma telemetria, por exemplo, o NetFlow, e ao mesmo tempo monitora todo o tráfego que chega até ele. O segundo pode trabalhar no modo de captura de pacotes (modo promíscuo) e gerar telemetria para o tráfego capturado. Em nosso caso particular, usamos apenas a primeira interface.
Após a instalação, o sensor é executado na nuvem onde o console está localizado - na verdade, é AWS e produz uma bela mensagem:
{"error":"unknown identity","identity":"185.190.117.34"}
Este é o mesmo endereço IP sob o qual o sensor pensa que se vê no mundo exterior, rompendo um firewall corporativo, tradução de endereço, etc. Só para garantir, direi imediatamente que o sensor precisa de HTTP e HTTPs, além de configurar DNS uma. Depois de receber a mensagem acima, você só precisa pegar este endereço e adicioná-lo à lista de seus sensores no console:
E depois de um tempo o sensor fica verde - isso significa que o sensor estabeleceu uma conexão com o console.
E, em geral, o lançamento do sistema é concluído nisso. O próximo passo é adicionar fontes de telemetria, além da própria escuta do sensor. Se quisermos receber telemetria usando o protocolo NetFlow, o site é extremamente útil .
Nele podemos selecionar o dispositivo de rede de que precisamos, inserir alguns parâmetros e obter uma configuração pronta:
E copiar as informações recebidas para nossos dispositivos de rede. É isso - o sistema está pronto para funcionar! Em vez disso, até começou a funcionar.
A propósito, exemplos de configurações de Netflow deste site podem ser usados não apenas para Steathwatch, mas para qualquer outro produto que possa usar tal telemetria - por exemplo, Cisco Tetration, IBM QRadar, etc.
Agora você pode fazer o ajuste fino do sistema. Quero dizer imediatamente que realmente gosto de observar como vários produtos de segurança da informação da Cisco me informam sobre tudo o que acontece em um único console de monitoramento e resposta Cisco SecureX. Na verdade, SecureX é algo extremamente interessante e merece uma descrição separada. Em suma, é um sistema de monitoramento de segurança da informação (SIEM) baseado em nuvem, investigação (Threat Hunting), investigação e resposta a incidentes e, ao mesmo tempo, automação de processos (SOAR). Eu recomendo fortemente que você se familiarize com este sistema em mais detalhes, e ele é "anexado" por padrão a qualquer produto de segurança de informações da Cisco. Bem, um pouco de marketing neste tópico aqui .
Então, em primeiro lugar, configurei esta integração:
ao mesmo tempo, configurei a integração com nossa plataforma em nuvem para fornecer serviços de segurança Cisco Umbrella: https://habr.com/ru/company/jetinfosystems/blog/529174/ .
Não coloquei nenhuma esperança em particular nisso, acreditando que todas as coisas mais interessantes aconteceriam dentro do aterro, e não era minha tarefa protegê-lo.
Depois disso, criei um novo console de monitoramento no SecureX. Tudo isso levou um total de 5 minutos, talvez até menos. Algumas fotos do meu SecureX abaixo:
Depois disso, decidi desligar as notificações que não eram interessantes para mim e ativar as interessantes. Para fazer isso, voltei ao console SWC e fui configurar essas mesmas notificações:
direi imediatamente que, para cada uma das notificações, você pode ver o que é, quantos dias de coleta de informações telemétricas são necessários para detectar a ameaça correspondente e como funcionará se cair, para MITER ATT & CK.
O número de ameaças detectadas e notificações relacionadas está crescendo constantemente à medida que a própria solução evolui. Mas eu realmente não preciso pensar sobre isso - a nuvem, conforme eles adicionam algo novo, está imediatamente à minha disposição.
Desativei a maioria das notificações relacionadas a ataques nas nuvens AWS, Azure, GCP, uma vez que não eram usadas neste polígono, e ativei todas as notificações relacionadas a ataques em redes privadas.
Além disso, posso gerenciar políticas de monitoramento para diferentes sub-redes que desejo controlar. Você pode habilitar o monitoramento separadamente para os países de particular interesse para nós:
Neste ponto eu li meu texto acima e percebi que demorou muito mais para escrevê-lo do que para configurar o sistema, incluindo todas as integrações.
Agora o que vimos?
Nos primeiros dias do Standoff, a telemetria me foi fornecida por alguns de nossos firewalls ASAv virtuais, mas então o número de fontes aumentou ligeiramente - mais firewalls foram adicionados, bem como Netflow de um corretor de tráfego central.
As primeiras notificações chegaram muito rapidamente e, como era de se esperar, foram associadas a várias verificações. Bem, então ficou mais interessante observar o processo a cada hora. Não vou descrever todo o processo de observação aqui, mas apenas falar sobre alguns fatos. Em primeiro lugar, conseguimos coletar boas informações sobre o que é o quê no local de teste:
Em segundo lugar, para avaliar a escala do evento - com quais países houve a troca de tráfego mais ativa:
Na verdade, existe um formato mais conveniente para apresentar esses dados, mas aqui decidi mostrar mais detalhes.
Assim, os principais "externos", além da Rússia, os usuários do aterro foram os EUA, Alemanha, Holanda, Irlanda, Inglaterra, França, Finlândia, Canadá, embora tenha havido alguma interação com quase todos os países, inclusive os países da América do Sul, África e Austrália:
Claro, nós pode ver quem é o proprietário dos endereços que viram:
E, se desejar, pergunte sobre eles de outras fontes analíticas úteis:
O que nos permitiu ver, por exemplo, interação ativa com recursos da Microsoft em muitos países.
Além disso, a tabela das interações mais ativas também poderia ser vista na forma de um quadro dinâmico de conexões com a possibilidade de sua análise mais detalhada:
Mas o que coletamos exatamente do ponto de vista dos ataques?
A lista de notificações nos fala sobre isso, algumas das quais você verá abaixo:
No total, 117 ataques foram identificados, confirmados por muitas observações (Observáveis). Vemos aqui varreduras de rede, sessões longas suspeitas, problemas com SMB, uso incorreto de portas e serviços de rede, comportamento estranho nós de rede, mudanças inesperadas em seu comportamento e outras estranhezas que devem alertar um especialista em segurança da informação.
Para cada evento de interesse para nós, podemos obter informações detalhadas, incluindo o que é, o que é ruim e recomendações de prevenção. Alguns desses eventos interessantes podem ser vistos abaixo - um lançamento inesperado de um servidor SSH em uma estação de trabalho Windows e o uso de um intervalo de portas não padrão. Você também pode prestar atenção ao fato de que, com a integração configurada, você pode ir diretamente da descrição do evento para o console de investigação SecureX Treat Response para uma análise detalhada deste incidente:
Portanto, algumas pequenas conclusões baseadas nos resultados deste pequeno e divertido piloto.
Em primeiro lugar, a Positive Technologies conduziu excelentes exercícios cibernéticos e foi muito interessante observá-los um pouco "de dentro", e foi conveniente, fácil e simples.
O segundo, que devo dizer, as soluções de segurança em nuvem são rápidas, simples e convenientes. E se ainda houver muitos deles e você puder configurar a integração entre eles, também é muito eficaz.
Terceiro, os participantes do site de teste também usaram ativamente serviços em nuvem, por exemplo, serviços da Microsoft.
Quarto, a análise automatizada da máquina de vários telemetria de rede facilita a identificação de incidentes de segurança da informação, incluindo as atividades planejadas de intrusos. E aconselho você a prestar atenção ao fato de que já existem muitos cenários bem desenvolvidos para o uso eficaz da solução Cisco Stealthwatch para as necessidades de segurança da informação. Cada um dos leitores pode encontrar um script ao seu gosto aqui .
Bem, e um pequeno comentário final - neste artigo eu deliberadamente não listei as listas recebidas de endereços IP, domínios, detalhes de interação, etc. em detalhes, percebendo quanto esforço foi necessário para a Positive Technologies montar este polígono e esperando que ele seja útil para eles repetidamente e nós no futuro. E não tornaremos a vida mais fácil para futuros invasores.