Hipóteses no campo da detecção de ameaças cibernéticas

A detecção de ameaças é a principal etapa das defesas cibernéticas de uma organização, é como alimentamos claramente nossos sistemas de proteção e resposta. É somente encontrando essa ameaça ativa que podemos agir, isolar, eliminar, enganar ou melhorar os modelos de ameaças cibernéticas.

Explorando alguns exemplos da afirmação acima, percebemos que há muitos casos em que é possível agir a nosso favor sem a necessidade de ter feito qualquer tipo de detecção, por exemplo, ativando um firewall, implantando uma solução antimalware ou usando uma senha complexa. Isso não é totalmente verdade, pois todas as ações de proteção que aplicamos (sejam preventivas ou reativas) baseiam-se em um entendimento das ameaças que foram modeladas anteriormente, como no caso de estratégias mais abrangentes, como o Princípio do Menor Privilégio (PoLP), a boa e velha defesa em profundidade ou o modelo Zero Trust.

É com isso em mente que agora nos concentraremos no comportamento dos atacantes cibernéticos e em como é possível destilar regras de detecção utilizáveis a partir de um conjunto de hipóteses. Nesta postagem, analisaremos a lógica por trás da detecção comportamental, algumas linguagens para a geração de regras exportáveis e um modelo de detecção dinâmica conhecido como “Detecção como código”.

Da técnica à detecção

Tomaremos algumas técnicas comumente usadas numa cadeia de ataques cibernéticos para analisá-las. Nesse caso, usaremos como referência a matriz MITRE ATT&CK no contexto da caça a ameaças (você pode ler sobre ela em nosso post anterior).

T1087.004 - Account Discovery: Cloud Account

Vamos começar adiantando um pouco os estágios de um ataque cibernético e tomar como referência a técnica de enumeração "Account Discovery" em sua variante "Cloud Accounts". Essa técnica, como a maioria das técnicas de enumeraçãobaseia-se na premissa de que o invasor cibernético pode tentar coletar uma lista de itens adicionais que lhe permitam expandir seu ataque,Para essa técnica específica, os dados descobertos podem ser usuários e funções em um serviço de nuvem (Azure AD, Google Workspace, IaaS, Office 365, SaaS).

Reconhecendo esse comportamento, analisamos a maneira específica pela qual um atacante cibernético poderia realizá-lo na prática. Para sermos específicos em nosso exemplo, vamos nos concentrar na interface de comando do Azure (AZ CLI). A MITRE ATT&CK propõe o comando "az ad user list" como exemplo. Uma possível saída desse comando com alguns parâmetros forneceria dados específicos do usuário.

Exemplo de saída de "az ad user list".

Uma hipótese, então, para começar com "nosso destilado por detecção" poderia ser:

"Se o comando 'AZ AD USER LIST' for executado, um adversário estará realizando uma DESCOBERTA".

Do ponto de vista da "detecção", podemos ver que o grau de precisão dessa afirmação é baixo, pois podemos encontrar vários casos em que encontramos esse comportamento e não se trata de um invasor. Por exemplo, na implementação de algum tipo de solução por um administrador de nuvem, até mesmo algum software de gerenciamento de identidade que realiza consultas por meio da mesma API. Precisamos refinar nossa hipótese aqui para melhorar a precisão, por exemplo:

"Se o comando 'AZ AD USER LIST' for executado de um terminal desconhecido, um adversário estará realizando uma DESCOBERTA".

Essa nova definição aumenta o grau de precisão, , embora, por outro lado, limite o escopo, pois só podemos detectar esse comportamento se o terminal de origem for desconhecido (o que nem sempre é o caso).

A detecção precisa nos aproximar da base da pirâmide. A detecção exaustiva nos aproxima do topo. Não há respostas certas, combinamos constantemente as duas estratégias (Assinaturas + Heurística).

O tamanho certo dependerá de nossos objetivos de detecção e dos riscos associados ao ativo que queremos proteger.

Por outro lado, avançando com a implementação prática desta detecção e a partir da perspectiva dos 'requisitos' para realizá-la, o elemento disparador poderia ser um monitoramento contínuo dos comandos executados através da interface 'Azure CLI'. Esta fonte de detecção não é trivial, como um registro de auditoria pré-configurado, por isso precisamos moldar a detecção a partir de outros elementos observáveis de acordo com as tecnologias que temos. É necessário encontrar alternativas, como focar nos terminais que poderiam executar comandos no Azure CLI e monitorar o histórico de execução no PowerShell, ou outros tipos de estratégias para cobrir também as execuções a partir do Azure Cloud Shell, por exemplo.

T0878 - Alarm Suppression

Vamos agora para um ambiente diferente e analisar as táticas que estão mais relacionadas a algum tipo de impacto em ambientes industriais. A "supressão de alarme" é uma técnica que se enquadra na tática "Inibição da função de resposta" específica da matriz MITRE para ICS ou sistemas de controle industrial (você pode se aprofundar em ICS ou OT nesta publicação ou ficar do lado do invasor nesta publicação).

Essa técnica envolve a inibição de uma função de alarme que visa a alertar um operador sobre uma situação crítica no sistema. Esse tipo de técnica, ao contrário da anterior, concentra-se em dispositivos específicos de redes industriais (por exemplo, sistemas PLC / Scada).

Essa técnica geralmente é aplicada, por exemplo, modificando ou suprimindo um sistema de avisos e mensagens de relatório, ou mesmo alterando os dados exibidos em uma interface do tipo HMI. Há várias maneiras de abordar essa técnica, dependendo dos tipos de alarmes e dos dispositivos envolvidos na operação, mas podemos dar alguns exemplos hipotéticos:

Se uma comunicação ASSOCIADA AOS PROTOCOLOS DE UM SISTEMA DE ALERTA for perdida, um adversário está realizando uma INIBIÇÃO DE FUNÇÕES DE RESPOSTA".

Essa hipótese exigirá como "fontes de dados", algum tipo de monitoramento de tráfego de rede ou monitoramento de integridade dos programas envolvidos nos dispositivos, por exemplo.

MITRE ATT&CK - Possíveis fontes de dados para a detecção de T0878

A tradução dessas hipóteses em uma linguagem operável na forma de regras lógicas será nossa próxima etapa para, em seguida, implementar diferentes casos de uso em nossa infraestrutura. Sempre considerando os fatores acima, poderemos ajustar a precisão de cada um deles.

Sobre regras de detecção

A detecção em larga escalade atividades mal-intencionadas na infraestrutura se torna complexa se quisermos usar as técnicas uma a uma e defini-las para cada uma de suas variantes específicas. Consumir regras de detecção da comunidade, de um fornecedor ou de outras organizações traz a dificuldade de que cada uma delas têm diferentes soluções de detecção, tipos de registro e estratégias para definir sua proteção. Cada SIEM tem até mesmo suas próprias linguagens de consulta.

O que são as regras SIGMA?

As regras SIGMA são um formato de assinatura de código aberto que permite escrever regras de detecção considerando qualquer registro de entrada e em um formato padronizado. Elas têm uma sintaxe yaml e podem ser convertidas (ou traduzidas, como eu gosto de dizer) para a sintaxe do nosso SIEM preferido ou de qualquer plataforma usada na organização.

Tomamos como exemplo uma regra sigma de um repositório da comunidade encontrado em uma biblioteca de projetos SigmaHQ (aqui), Nessa regra, o comportamento a ser detectado é a conexão de um possível invasor de um sistema afetado a um serviço externo de "Comando e Controle”(C&C TA0011) por meio da rede onion (Multi-hop Proxy T1090.003). A técnica específica faz uso do navegador TOR para cumprir sua missão; essa é a regra de detecção:

Podemos interpretar, neste exemplo, que a detecção é, em princípio, baseada nos nomes e locais dos binários executados, especificamente para ambientes Windows. O leitor atento saberá que essas regras precisam ser refinadas para melhorar sua precisão..

Um guia para entender a sintaxe desse tipo de regra para a criação de novas regras pode ser encontrado aqui aqui.

Em seguida, para usar essa regra sigma, podemos convertê-la em um formato compreensível pela nossa solução de detecção preferida, um SIEM como o QRADAR da IBM, o que nos deixa com uma consulta no seguinte formato:

Essa conversão pode ser feita manualmente, compreendendo a sintaxe de ambas as pseudo-linguagens, ou podemos usar as ferramentas disponíveis, como o tradutor undercoder.io.

As regras Sigma são apenas um exemplo de um formato para executar decisões de triagem, que também podem ser encontradas em diferentes aplicativos e escopos:

• Regras Yara (voltadas para a detecção de arquivos maliciosos)
• OpenIOC (Orientado para a gestão de Indicadores de comprometimento)
• Regras do Snort (orientadas para a detecção de intrusão de rede)
• Regrs Suricata (também orientadas para a detecção de intrusão de rede)

Detecção como um código

No final das contas, os analistas de segurança já têm uma regra de detecção, concreta, aplicável aos seus sistemas de segurança e baseada em um comportamentobem conhecido em um ataque cibernético. No entanto, engenharia de detecção exige muito mais do que a criação de uma boa regra, ela exige a condução de um conjunto de regras que serão constantemente modificadas, refinadas, adicionadas e desativadas.

E se realizarmos essa operação usando algum framework conhecido conhecido que tenha esse dinamismo de integração e entrega contínuas? É assim que o conceito de Detecções como Código está sendo aprimorado como um meio de sustentar uma detecção dinâmica e eficiente usando DevOps.

Essa abordagem nos permite ter, por exemplo, algumas dessas características:

• Controle de versão das regras de detecção
• Processode teste/QA para avaliação de regras
• Modularização das regras para reutilização
• Métricas e melhorias em toda a operação.

Aqui está um excelente diagrama de todo o fluxo de criação e distribuição de regras de detecção, preparado por Matt Bromiley em seu artigo "Detecting Malicious Activity in Large Enterprises":

Algumas conclusões

No processo de destilar o comportamento em uma forma de detectar atividades mal-intencionadas, podemos ser tentados a pensar que um controle lógico pode fechar uma porta para o invasor. Uma regra de firewall muito restritiva que limite o acesso à Internet é uma excelente medida, mas não substituirá a necessidade de detectar o tráfego de C&C dentro da rede.

"A prevenção pode falhar, mas a detecção não tem esse luxo".
Felipe Alves - Pesquisador da BASE4 Security

A detecção "genérica" que podemos encontrar pelo simples fato de implantar uma solução de proteção, como um EDR, um WAF ou um IPS, tem muito valor; a proteção como boa prática deve começar pelas medidas mais abrangentes até as medidas mais específicas. Não faz sentido confiar em hipóteses para detectar comportamentos "avançados" se, por outro lado, não pudermos ver quais privilégios são atribuídos aos usuários, por exemplo.

O campo da IA está nos fornecendo uma série de ferramentas que estão cada vez mais ao nosso alcance, e incorporar o aprendizado de máquina à "detecção como código" é uma prática que aumentará ainda mais a capacidade das equipes de SOC de operar com mais eficiência e eficácia.