Automatizando os testes ATT&CK com SOAR e Atomic Red Team

 

MITRE ATT&CK é a estrutura padrão para as organizações avaliarem sua postura de defesa. O ATT&CK fornece categorias verticais na forma de táticas, que se alinham às metodologias comuns usadas pelos atacantes. Dentro dessas verticais, há um conjunto (e subconjuntos) de maneiras comuns pelas quais os atacantes executam uma tática (vertical). Essas são conhecidas como técnicas.

Algumas técnicas podem ser comuns a vários sistemas operacionais. Isso geralmente equivale a uma definição ampla de técnica. Como defensores, isso significa que devemos entender como uma única técnica pode ser implementada em múltiplas plataformas — o que pode ser difícil para muitos, inclusive para mim. Felizmente, organizações como a Red Canary forneceram à nossa comunidade uma estrutura robusta para auxiliar nos testes dessas técnicas.

A Red Canary tornou o código-fonte do Atomic Red Team aberto. Há alguns anos, desenvolvemos um projeto para auxiliar a comunidade de segurança, fornecendo um conjunto de Atomics (testes) mapeados para o framework MITRE ATT&CK. Cada Atomic está associado a uma técnica específica dentro do ATT&CK e oferece um ou mais testes que podem ser executados em um sistema. Esses Atomics têm como objetivo simular ou emular como um atacante utiliza uma técnica contra o seu ambiente.

Além de fornecer um conjunto de testes que podem ser executados, o Red Canary também oferece várias estruturas de execução que nos permitem executar esses testes. Essas estruturas são escritas em Python, PowerShell (Core) e Ruby, mas de longe a mais atualizada (e mais ativa) é a estrutura PowerShell (Core). Como observação adicional, Reescrevi a estrutura do PowerShell em setembro de 2018., Mas sofreu muitas mudanças desde então.

A ideia é usar uma das estruturas de execução para executar um ou mais testes atômicos em um sistema. Em contrapartida, seu EDR, SIEM etc. disparariam alertas/detecções e começariam a medir sua eficácia em relação a técnicas específicas dentro do seu ambiente. No entanto, fazer isso manualmente tem se mostrado um processo difícil, tedioso e demorado.

Como fã de longa data da Red Canary e do seu projeto Atomic Red Team, estabeleci dois objetivos principais:

1. Para executar testes remotamente em vários tipos de sistemas operacionais usando uma única estrutura.
2. Associar detecções/alertas a testes atômicos em um ambiente.

Recentemente, fiz uma apresentação sobre como consegui atingir esses objetivos usando o Swimlane SOAR.. Além disso, eu queria contribuir com a comunidade de segurança disponibilizando como código aberto um componente desse caso de uso.

Caso de uso

O principal caso de uso consiste em várias aplicações dentro de um único espaço de trabalho. Consegui analisar os Atomics da Equipe Vermelha Atômica e transformá-los em um único registro dentro de um Atômicos aplicativo. Como mencionei anteriormente, cada Atomic pode ter vários testes associados a ele, e esses testes podem não ser para um único tipo de sistema operacional. Portanto, criei um aplicativo secundário chamado Testes atômicos, que contém os detalhes sobre cada teste e está associado ao registro principal do Atomics.

O principal ponto de entrada que um analista utilizaria é o Hospedar aplicação. A aplicação host contém informações sobre um host no qual você deseja executar um teste. Um analista criará um registro e fornecerá (no mínimo) um nome, endereço (IP ou DNS) e o tipo de sistema operacional. Assim que este novo Hospedar Após o registro ser salvo, o analista precisa escolher quais testes deseja executar. Isso é feito utilizando um registro de referência. Testes atômicos aplicação. Depois de adicionarem testes, eles podem optar por executar um ou mais testes associados ao registro.

leme

Você pode estar se perguntando: "Como eles vão executar esses testes remotamente?" Bem, eu gostaria de apresentar uma nova ferramenta de código aberto chamada leme. leme É um pacote Python que executa comandos remotamente no Windows, macOS ou *nix, e é multiplataforma.

Para usar leme, Você deve fornecer um conjunto de credenciais que possam utilizar o PowerShell Remoting/WinRM (Windows Remote Management) ou SSH no host desejado.

Depois de fornecer um conjunto de credenciais em nosso sistema... Loja de chaves, Com o Swimlane, você pode executar testes em vários hosts e sistemas operacionais. Para cada execução de teste em um host, criamos um registro histórico em outro aplicativo chamado Histórico de testes. Este aplicativo contém registros de todos os testes realizados em um host, juntamente com a resposta do sistema. Cada um desses testes é então associado ao host em que foi executado, fornecendo informações contextuais históricas.

Após a execução de um único teste em um host, iniciamos imediatamente a busca por alertas/detecções semelhantes ao nosso teste. Fazemos isso analisando os aplicativos fornecidos e os campos específicos a serem monitorados. Também levamos em consideração os seguintes pontos de dados ao tomar uma decisão (todos eles podem ser facilmente modificados ou personalizados de acordo com as necessidades da sua organização):

1. Comparação de carimbos de data/hora
   1. A busca pelos horários de início é baseada no carimbo de data/hora em que o teste foi invocado no host.
   2. A duração final é configurável, mas por padrão a definimos em 3 horas após a execução do teste.
2. Comparação de endereços
   1. Analisamos os campos fornecidos e verificamos se o nome/endereço do host de alerta é o mesmo endereço em que o teste foi executado.
3. Comparação de execução
   1. Normalização dos detalhes de teste e alerta atômico
      1. minúsculas
      2. Remover caracteres (ex: |, \\, etc.)
   2. Comparar duas listas de comandos para encontrar a diferença percentual entre strings e valores semelhantes.
   3. Opcional:
      1. Disponibilizamos a capacidade de usar cálculos de distância de Levenshtein e comparações de hash SSDeep, mas esses métodos são dispendiosos e são mais adequados para valores de origem e destino semelhantes.

Após realizar uma comparação e determinar que um alerta/detecção é semelhante ao nosso teste, associamos esse registro de alerta ao nosso registro de histórico de testes. Nesse ponto, criamos um registro ou associamos nosso registro de histórico de testes a outro aplicativo chamado Registros de mapas de calor.

A Registro de mapa de calor É utilizado para rastrear, relatar e exibir dados sobre nossa capacidade de detectar (ou não) técnicas específicas nas quais realizamos testes. Se um teste foi executado e nenhum alerta foi identificado, ainda assim rastreamos esse evento, mas nosso relatório será um pouco diferente de quando conseguimos detectar com precisão uma técnica em todos os testes anteriores.

Uma vez criados esses registros ou associado um histórico de testes a uma técnica, podemos então entender visualmente onde conseguimos detectar atividades maliciosas e onde estamos falhando.

Acima está uma imagem do widget do painel MITRE ATT&CK da Swimlane. Este painel está extraindo dados de nossa plataforma. Registros de mapas de calor e exibindo-o dinamicamente. Se uma caixa da grade não tiver cor, significa que não realizamos testes para essa técnica específica. O azul mais escuro significa que realizamos pelo menos um teste e conseguimos detectá-la. À medida que mais testes e detecções são identificados, a cor clareia para o azul-turquesa ao redor. No Windows. Se um teste foi realizado e nenhuma detecção foi identificada, essa técnica será exibida em vermelho.

Ao usar Equipe Vermelha Atômica da Canário Vermelho Com o Swimlane SOAR, você pode automatizar seus testes ATT&CK e, ao mesmo tempo, obter visibilidade das suas capacidades de detecção e das lacunas existentes. Chega de testes, revisões e correlações manuais. Com esse recurso, você pode identificar lacunas rapidamente e iniciar novos testes em poucos minutos.