Iniciaremos a produção de uma série de artigos voltados para a área de Engenharia de Detecção, contribuindo para a comunidade de cybersecurity no aprofundamento de temas que impactam diretamente o dia a dia de times que trabalham com: SIEM, criação de regras, concepção de cenários de ameaça, gestão de casos de uso, entre outros. Neste artigo vamos começar trazendo um escopo introdutório sobre o tema Sigma Rules, abordando os seguintes tópicos:
- Contexto histórico;
- Importância de Sigma Rules em Casos de Uso;
- Sigma além da sintaxe;
- Sobre o Sigma Rules propriamente dito;
- Os principais benefícios e desafios do Sigma Rules;
- Um exemplo prático e real que desenvolvemos.
Ao final do artigo esperamos que o profissional de segurança possa estar convencido destes benefícios do uso de Sigma Rules e seguir adotando este formato para compor sua biblioteca de casos de uso de detecção.
Contexto Histórico
Antes de falarmos do Sigma Rules é importante deixarmos claro em que contexto ele pode e, mais ainda, precisa ser usado dentro do mundo de detecção de ameaças.
Para colocarmos um ponto de início nessa história, o Projeto Sigma surgiu no final do ano de 2016, criado por Florian Roth (Twitter: @cyb3rops) e Thomas Patzke (Twitter: @blubbfiction), oferecendo um formato padronizado para a troca de arquivos que designam detecções, similar à proposta das YARA Rules, contudo, se utilizando de fontes de logs como matéria-prima.
Um pouco sobre Casos de Uso de Detecção
Também em 2016, o assunto “Casos de Uso de Detecção” já se encontrava presente em conferências internacionais de Cyber Defense, sendo apontado como um tópico, ainda que de certa forma, em fase embrionária. Esse assunto abordaremos com mais profundidade no próximo artigo da série,mas, por hora, é importante definirmos pontualmente o que é um caso de uso e qual a relação dele com o Sigma Rule.
Um cenário de ataque pressupõe vários estágios pelos quais o ataque deve passar para comprometer um sistema e, por conseguinte, vários casos de uso podem ser implementados para detectar e impedir o ataque nos diferentes estágios.
E o que o Sigma Rule tem a ver com isso? Muito simples. O caso de uso está num nível de abstração que não consegue ser colocado ou escrito em uma regra no SIEM.
O Sigma Rule vai ser exatamente a ponte entre esses dois mundos (ou momentos). Será a tradução da concepção (caso de uso) numa linguagem estruturada (YAML) que possa, no passo seguinte, ser materializada em uma ou mais regras para um ou mais SIEMs alvo.
Sigma além da sintaxe
É importante observarmos que, ao utilizar o padrão Sigma, não se trata somente de uma questão de adotarmosuma solução de mercado ou fazermos uso de uma notação estruturada para fins de documentação que fará parte de uma base de conhecimento knowledge base.
Sua estrutura e, por conseguinte, sua sintaxe, é apenas o meio pelo qual o processo de engenharia de detecção está ancorado. Materializar um caso de uso, mediante a utilização do Sigma Rules, deve ser uma proposta simples, objetiva e genérica, para documentar um cenário de detecção de ameaça e dar suporte à padronização do processo de Incident Handling (tratamento dado à um evento adverso, confirmado ou mesmo sob suspeita, relacionado à segurança).
Sabe quando você descobre e aprende uma linguagem nova de programação? Pois bem, a rigor, saber codificar é meramente parte do processo e, arriscamos dizer, é a de menor importância frente ao problema que você vai resolver e como você espera resolver com aquela nova habilidade e sintaxe.
Sigma Rule, portanto, é utilizado (neste caso) para documentar o caso de uso de detecção.
Enfim, Sigma Rules
Sendo um formato de assinatura genérico, o Sigma Rule é aberto e permite descrever eventos de log relevantes de maneira direta, sendo muito flexível, fácil de escrever e aplicável à qualquer tipo de arquivo de log. Esse projeto atualmente está disponível através do github chamado SigmaHQ, que pode ser acessado aqui.
O objetivo principal, nesse caso, é fornecer uma forma estruturada na qual pesquisadores ou analistas possam descrever seus métodos de detecção desenvolvidos e torná-los compartilháveis com outros. A estrutura sob a qual o Sigma Rule é construído, bem como seu funcionamento, serão descritos nos tópicos a seguir:
- Propósito caso de uso / cenário de ameaça;
- Referências;
- Falsos Positivos;
- Fields;
- Lógica da detecção;
- Metadados.
Ao final das descrições de cada item listado anteriormente vamos mostrar como funciona e estruturar o sigma em sua versão final com todas essas partes contidas no YAML.
Propósito caso de uso / cenário de ameaça: Para a criação de um Sigma, a primeira etapa é entender o cenário de ameaça que estamos observando para se comprometer a fazer um caso de uso. No quadro abaixo começamos a montar e descrever, portanto, o sigma com dois atributos (title e description). Nesse exemplo estamos considerando um cenário de ameaça que possibilite a detecção de deleção de arquivos do sistema operacional utilizando SDelete, ainda nesse trecho é descrito no campo title o título da detecção e no campo description é incluído uma breve descrição do escopo da detecção.
title: Sysinternals SDelete Delete File description: Use of SDelete to erase a file not the free space
Referências: São referências externas utilizadas para entendimento da ameaça à qual a regra de detecção se destina.
references: - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1485/T1485.md
Falsos Positivos: Descreve possíveis comportamentos que não são propriamente uma ameaça, mas a regra pode detectar, erroneamente, por motivos diversos, tais como: pentest, ações administrativas, diversas automatizadas, etc.
falsepositives: - System administrator Usage
Fields: Item com lista de campos do evento. Tais campos são parte da notificação (alerta) que é enviada pela ação disparada pela regra no SIEM.
fields: - ComputerName - User - CommandLine - ParentCommandLine
Lógica da detecção: Nessa parte é descrita, de forma estruturada, qual seleção de campo/valor corresponde ao padrão de ameaça que se quer detectar. Para o exemplo em questão consideramos na definição de fonte de dados o uso do campo logsource. Sendo assim, conseguimos discriminar o datasource necessário para prover os eventos e campos usados na seção detection que, por sua vez, é composto por uma lista que relaciona campos dos eventos com seus respectivos valores. Neste caso particular, ilustrado abaixo, para reconhecer parte do comportamento malicioso, especifica-se o valor sdelete.exe para o campo OriginalFileName (campo que podemos encontrar no log de criação de processo do Windows). No campo condition podemos utilizar operadores booleanos para relacionar os filtros e seleções especificados e, assim, definir a condição final da qual o match da regra depende.
logsource: category: process_creation product: windows detection: selection: OriginalFileName: sdelete.exe filter: CommandLine|contains: - ' -h' - ' -c' - ' -z' - ' /?' condition: selection and not filter
Metadados: Aqui se faz necessária a inclusão de pontos de controle que definem autor, data de criação, versão da detecção e aspectos de mitigação e erradicação.
id: a4824fca-976f-4964-b334-0621379e84c4 status: experimental author: frack113 date: 2021/06/03
Com todos esses elementos mostrados individualmente, chegou o momento de mostrar como fica tudo isso junto em um só arquivo, em uma só estrutura de forma integral com todos os campos:
title: Sysinternals SDelete Delete File id: a4824fca-976f-4964-b334-0621379e84c4 status: experimental author: frack113 date: 2021/06/03 description: Use of SDelete to erase a file not the free space references: - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1485/T1485.md tags: - attack.impact - attack.t1485 logsource: category: process_creation product: windows detection: selection: OriginalFileName: sdelete.exe filter: CommandLine|contains: - ' -h' - ' -c' - ' -z' - ' /?' condition: selection and not filter fields: - ComputerName - User - CommandLine - ParentCommandLine falsepositives: - System administrator Usage level: medium
Tradução do Sigma para SIEM
Seguindo o processo, agora é horade fazer a tradução do Sigma para a search query do SIEM alvo. Na figura que mostramos anteriormente, seria seguir do passo 3 para o 4. Para construir esse fluxo utilizamos o Sigmac, programa responsável por essa conversão e tradução de um arquivo YAML na sintaxe de um SIEM alvo que deve ser baixado aqui.
Para efeito prático vamos utilizar um exemplo que está disponível no repositório do projeto Sigma Rules, no github, no seguinte caminho: rules/windows/process_creation/process_creation_SDelete.yml.
A base do comando para essa conversão considera dois importantes parâmetros: o target (plataforma que se pretende obter a regra a partir do Sigma) e configuration file (parâmetro utilizado para definir a configuração através de um arquivo que contém o mapeamento de campos no Sigma); que são usados passando -t e -c, respectivamente.
Vamos utilizar, portanto, como target o Splunk como SIEM alvo e, no configuration file, usaremos o sysmon, considerando hipoteticamente que é o log source disponível no nosso SIEM. O comando, em sua versão completa, ficará assim:
$ ./tools/sigmac -t splunk -c sysmon rules/windows/process_creation/process_creation_SDelete.yml
Após executar o comando sigmac com sucesso no processo de compilação do YAML, a saída esperada pode ser vista no quadro abaixo.
(EventID="1" OriginalFileName="sdelete.exe" NOT ((CommandLine="* -h*" OR CommandLine="* -c*" OR CommandLine="* -z*" OR CommandLine="* /?*"))) | table ComputerName,User,CommandLine,ParentCommandLine
Caso você não saiba, ou queira, descobrir os configuration files existentes para uso no Sigmac use o comando -l, que listará todas as possíveis opções de configuração conforme:
$ ./tools/sigmac -l ala : Converts Sigma rule into Azure Log Analytics Queries. ala-rule : Converts Sigma rule into Azure Log Analytics Rule. arcsight : Converts Sigma rule into ArcSight saved search. Contributed by SOC Prime. https://socprime.com arcsight-esm : Converts Sigma rule into ArcSight ESM saved search. Contributed by SOC Prime. https://socprime.com carbonblack : Converts Sigma rule into CarbonBlack query string. Only searches, no aggregations. Contributed by SOC Prime. https://socprime.com chronicle : Converts Sigma rule into Google Chronicle YARA-L. Contributed by SOC Prime. https://socprime.com crowdstrike : Converts Sigma rule into CrowdStrike Search Processing Language (SPL). csharp : Converts Sigma rule into CSharp Regex in LINQ query. devo : Converts Sigma rule into Devo query. ...
Esse output proveniente da conversão do Sigma Rules para uma regra SPL já pode ser implementada no seu SIEM Splunk.
Benefícios e desafios
“Com Sigma, você pode potencializar sua solução de gerenciamento de logs e aplicar métodos de detecção fornecidos pela comunidade sem custos extras.” — Florian Roth
Podemos relacionar os seguintes benefícios ao utilizar Sigma Rules:
- Portável: formato de assinatura agnóstica que habilita a migração facilitada para outras tecnologias de SIEM;
- Gestão em multi-deploy: gestão de regras em ambientes nos quais o uso de dois ou mais SIEMs é mandatório;
- Sem Vendor lock-in: Liberdade para mudar de solução de SIEM, sem perda de sua base de inteligência;
- Comunicação: Formato agnóstico para expressar ideias de detecção, portanto, habilitando a possibilidade de troca de detecções sem ambiguidade entre profissionais de cyber defense;
- Comunidade: Usufruto da produção contingente de novas detecções produzidas pela comunidade de cyber defense.
Talvez você não encontre uma característica que você usou no seu SIEM corporativo, mas, não se engane, esse pormenor não impedirá de produzir as detecções que você necessita. Reconhecemos que certos desafios são uma realidade, pois o sigma não te proporcionará alguns elementos que você deveria considerar, tais como:
- Gerenciamento de regras;
- Teste de regra e garantia de qualidade;
- Documentação automática;
- Ambientes e dados para teste.
Conclusão
Se você trabalha construindo barreiras e elementos de detecção no ambiente do seu cliente ou da sua empresa, Sigma Rules poderá ser uma ferramenta de grande valia para se usar no seu dia a dia. Esta missão passa por construir uma visão baseada em táticas, técnicas e procedimentos que possibilitam desenvolver uma lógica de detecção de manifestação de uma ameaça.
A estruturação dos dados de maneira humanamente legível permitirá que você obtenha uma detecção mais assertiva. Além disso, a possibilidade da portabilidade para outras tecnologias de SIEM também proporciona um ganho de eficiência no processo de gestão de casos de uso.
E, vale salientar, que muitas das explicações desse artigo já fizemos na Tempest, mediante o uso de frameworks de segurança como: Cyber Kill Chain®, MITRE ATT&CK, MaGMa, CORAS, entre outros. Constantemente desenvolvemos casos de uso com foco em ameaças presentes no mercado e no negócio de nossos clientes.
O uso do framework Sigma Rules, portanto, passa a ser uma ferramenta indispensável para alcançarmos nossos objetivos em diferentes ambientes, detectando novas ameaças com menor índice de falsos-positivos e aumentando a assertividade do SOC da Tempest.
