Seguir 
Resumidamente
- SIGMA é um formato de regra de detecção agnóstico de plataforma que permite que as equipes compartilhem detecções de SIEM entre fornecedores.
- Para escrever uma regra, comece com uma ideia de detecção, escolha uma fonte de log comum e mapeie-a no SIGMA (mínimo:
logsource+detection). logsourceespecifica a quais logs a regra se aplica para que os tradutores possam direcionar o tipo de backend/dados correto.detectionsão seleções (correspondências de campo/valor + modificadores) mais uma condição (lógica booleana), opcionalmente com correlação/intervalo de tempo.- Use convenções de campo SIGMA (sensíveis a maiúsculas), traduza/teste a regra, depois compartilhe e itere com base no feedback.
Este post no blog defende o SIGMA como uma linguagem de detecção, cobre os componentes mais críticos das regras SIGMA (logsource & detecção), taxonomia SIGMA, teste de Regras SIGMA e geralmente prepara os analistas que são novos no SIGMA para escrever suas primeiras regras. Uma breve discussão sobre engenharia de detecção com SIGMA também é fornecida, abordando ruído, ideias, fontes de log, etc.
O Caso para Regras SIGMA
No passado, as detecções de SIEM existiam em silos específicos de fornecedores/plataformas. Parceiros que desejavam compartilhar conteúdo de detecção muitas vezes tinham que traduzir uma consulta de um fornecedor para outro. Isso não é sustentável, a comunidade de cibersegurança defensiva deve melhorar a forma como compartilhamos detecções para acompanhar nossos adversários em constante evolução.
Muito parecido com YARA, ou Regras Snort, SIGMA é outra ferramenta para o compartilhamento aberto de detecções, exceto que foca em SIEM em vez de arquivos ou tráfego de rede. SIGMA permite que os defensores compartilhem detecções (alertas, casos de uso) em uma linguagem comum.
Lançado pela primeira vez em 2017 por Florian Roth e Thomas Patzke, SIGMA está abrindo caminho para uma pesquisa agnóstica de plataforma. Com SIGMA, os defensores estão livres da linguagem de detecção e repositórios específicos de fornecedor/plataforma e podem aproveitar o poder da comunidade para responder rapidamente a ameaças críticas e novas técnicas adversárias.
Existem muitas razões para usar SIGMA:
- Pesquisadores e equipes de inteligência que identificam novos comportamentos adversários e desejam uma maneira agnóstica de compartilhar detecções
- MSSP / MDR responsáveis por múltiplas soluções SIEM / EDR / Análise de Logs & taxonomias/esquemas de dados (ECS, CEF, CIM, etc)
- Evite dependência de fornecedor, definindo regras em um SIGMA podemos nos mover mais facilmente entre plataformas.
- Pesquisadores no espaço de segurança ofensiva que desejam criar detecções com base em sua pesquisa
Nota: Neste blog, SIEM é usado para descrever qualquer plataforma usada para coletar e pesquisar logs. Eu aceito que muitas das plataformas listadas podem não se encaixar em sua definição de “SIEM”. No entanto, usar os termos “plataforma” ou “plataforma de log” é muito ambíguo.
SeguirCriando Regras SIGMA
Escrever regras SIGMA requer conhecimento básico sobre o esquema e taxonomia SIGMA, ter uma ideia, adaptar essa ideia ao SIGMA, testar, compartilhar e potencialmente manter a regra.
Contexto e Antecedentes Recomendados
Apesar do comprimento deste blog, graças ao YAML e ao pensamento avançado dos criadores, SIGMA é fácil de entender e escrever. Na SOC Prime, gostamos de dizer “qualquer um pode aprender SIGMA”. A arte da engenharia de detecção é onde as coisas podem se tornar mais complicadas.
Existem muitos outros recursos, como o wiki oficial e alguns guias escritos por especialistas em SIGMA (listados abaixo). Existem certas armadilhas, como manejo adequado de curingas or nomes de campos incorretos que podem causar regras quebradas e muitos desses são abordados nesses recursos.
Se você é um pesquisador interessado em se aprofundar no SIGMA, o Programa de Recompensa por Ameaças da SOC Prime é uma ótima oportunidade para começar e ganhar algum dinheiro. Regras enviadas passam por um processo de revisão detalhado onde podemos orientá-lo e ajudar a compreender erros e crescer como analista.
Leituras Recomendadas:
- Como Escrever Regras SIGMA, Florian Roth 2018
- Um Guia para Fontes de Log Genéricas, Thomas Patzke 2019
Assista Recomendado:
Tipos de Detecções que Regras SIGMA Podem Expressar
Hoje existem atualmente dois tipos básicos de regras:
- Regras SIGMA baseadas em correspondência, amplamente suportadas, mais fáceis de escrever
- Regras SIGMA baseadas em correspondência e correlações simples, suporte limitado, menos fáceis de escrever
Nota: Também existem regras SIGMA multi-yaml, no entanto, estas geralmente caíram em desuso para regras específicas de fontes de log. A equipe SOC Prime geralmente não cria regras multi-yaml porque elas adicionam complexidade desnecessária à manutenção e implantação da regra. Alguém pode criar uma regra SIGMA multi-yaml se puder criar duas regras SIGMA.
Vamos Criar uma Regra SIGMA Simples!
Uma ideia (e algumas considerações sobre engenharia de detecção com SIGMA)
Usuários e administradores geralmente mantêm senhas sensíveis em documentos de texto simples, como arquivos de texto, excel, word, etc. Estou preocupado que os adversários possam identificar esses arquivos antes de eu em um ambiente. Queremos instruir nossos usuários sobre como armazenar senhas corretamente antes que elas sejam descobertas por um hacker criminoso.
Para muitas regras SIGMA, é benéfico ao autor abstrair a ideia e ampliar o alvo ‘razoavelmente’. Para ideias como esta, podemos fazer suposições fundamentadas sobre como o comportamento may aparece, não apenas o que observamos. Por exemplo, podemos fazer suposições fundamentadas sobre termos e extensões adicionais que os usuários podem usar para armazenar senhas em texto simples.
A ideia de ‘ampliar’ uma regra é contra-intuitiva aos instintos de muitos analistas. Eliminar todos os ‘falsos positivos’ não é necessariamente o objetivo do autor original quando uma regra será consumida em ambientes desconhecidos e não familiares. Podemos deixar os fornecedores de EDR e Anti-Vírus preocupados em criar detecções que não possam ter falsos positivos. Com SIGMA, as regras podem ser testadas em ambientes e ajustadas facilmente.
SIGMA é fácil de entender, testável e ajustável. Se um termo como ‘detalhes’ é muito barulhento para um ambiente, a pessoa que implementa a regra deve se sentir capacitada para ajustar a regra. Implantar todas as regras de uma vez sem testar é uma receita para o desastre. Desativar regras em vez de digerir e ajustar suas intenções para um ambiente fará com que um local perca um bom conteúdo de detecção.
Eu gosto de dar o exemplo do psexec. Em alguns ambientes, psexec é completamente normal e o status quo para administradores gerenciarem hosts remotamente. Em outros ambientes, psexec é (provavelmente com razão) não aprovado, bloqueado, e uma infração acionável para administradores usarem. Então, uma regra SIGMA para detectar qualquer uso de psexec é ‘barulhenta’ ou apenas melhor para alguns ambientes do que outros? Se você implantar conteúdo sem testar, ajustar o barulho será sempre um problema. Apenas aquelas regras identificadas como “críticas” são destinadas a serem seguras para uso sem teste.
Voltando à criação de nossa regra SIGMA de exposição de senhas… podemos expandir a ideia para incluir nomes de arquivos adicionais, como:
- pw
- psw
- pass
- senha
- senhas
- contas
- conta
- informações
Criado com software como:
- Bloco de Notas
- Notepad++
- Wordpad
- Aplicações de Escritório
Uma fonte de dados / Uma fonte de log
Uma vez que temos uma ideia, precisaremos de uma fonte de log. SIGMA suporta any fonte de log teoricamente, no entanto, devemos identificar uma fonte de log que a maioria das pessoas possui. Por exemplo, podemos ser capazes de escrever uma regra para uma fonte de log de Prevenção de Perda de Dados, mas a Prevenção de Perda de Dados raramente é analisada e ingerida em SIEMs, e a indústria não possui um favorito claro. Portanto, podemos criar uma regra válida, mas ela não será facilmente adotada.
Para regras de endpoints do Windows, Sysmon é um ótimo lugar para começar. Sysmon é comumente implantado em ambientes e muitas fontes de log fornecem dados sinônimos (EDRs, etc). Com Sysmon, existem duas opções principais, criação de processo (process_creation no SIGMA) e criação de arquivo (file_event no SIGMA).
Construiremos nossa detecção a partir da criação de processo, pois é mais amplamente adotada, garantindo assim que nossa regra seja o mais útil possível. A criação de processo é uma ótima fonte de logs para aprender e é uma das fontes de logs mais úteis / populares usadas em detecções de endpoint.
Nota: Frequentemente, ideias vêm diretamente das próprias fontes de dados. Ao revisar os tipos de dados disponíveis para você em seu SIEM / Laboratório, você pode facilmente identificar regras SIGMA que valem a pena escrever. Também podemos usar outras fontes, como documentação de fornecedores.
Com eventos de criação de processo do sysmon (ID do Evento 1), um usuário acessando um arquivo contendo senhas pode conter esses campos interessantes:
Image: C:\Windows\System32\notepad.exe
CommandLine: “C:\Windows\System32\NOTEPAD.EXE” C:\Users\John\Desktop\password.txt
Ajustando a ideia de detecção ao SIGMA
Agora que temos uma ideia e uma fonte de dados para trabalhar, podemos começar a construir nossa regra.
Isso não é documentado, mas os verdadeiros componentes necessários para traduzir uma regra são apenas logsource & detecção (para algumas plataformas como Splunk, apenas a detecção é suficiente). Todo o resto é apenas ‘metadados’ para ajudar o consumidor da regra SIGMA. Quando você começa, é do seu interesse começar com esses campos mínimos, confirmar que sua lógica está funcionando e então adicionar campos e dados SIGMA adicionais. Se você quiser publicar sua regra no repositório público SIGMA, vale a pena verificar envios anteriores e emular seu formato.
Uma regra SIGMA básica com componentes mínimos para possível exposição de senha:
title: Potential Password Exposure (via cmdline)
author: Adam Swan
tags:
- attack.t1552.001
- attack.credential_access
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith:
- '\notepad.exe'
- '\word.exe'
- '\excel.exe'
- '\wordpad.exe'
- '\notepad++.exe'
CommandLine|contains:
- 'pass' #pass will match on password, including password is redundant
- 'pwd'
- 'pw.' #pw.txt, etc.
- 'account' #accounts,
- 'secret'
- 'details' #I included plural details based on experience
condition: selection
Componente logsource
The logsource o componente ajuda o tradutor de backend SIGMA (SIGMAC) a saber que tipo de dados a regra deve ser aplicada. Ele capacita o criador da regra a criar regras mais genéricas. Por exemplo, com logsource sendo “produto: windows, categoria: process_creation”, não precisamos especificar EventIDs (Sysmon 1, Windows 4688, ProcessRollup, etc). O consumidor da regra pode especificar quais IDs de eventos, índices, etc, eles querem associar com fontes de log no Config SIGMA. Sem especificar índices, IDs de eventos, etc, as regras provavelmente serão desnecessariamente caras (em termos de desempenho) para o consumidor.
Além disso, frequentemente, a telemetria pode conter campos semelhantes, mas implicar comportamentos completamente diferentes. Por exemplo, eventos de conexão de rede Sysmon (ID do Evento 3) e criação de processo (ID do Evento 1) compartilham o campo Imagem . A existência de explorer.exe no campo da conexão de rede Sysmon é completamente diferente da existência de explorer.exe em um evento de criação de processo. Ao fornecer o componente logsource adequado, fornecemos um contexto inestimável para a detecção. Imagem field of a Sysmon network connection event is completely different from the existence of explorer.exe in a process creation event. By providing the proper logsource component we provide invaluable context to the detection.
Componente de Detecção
O componente de detecção é onde o autor define seus critérios de detecção. Inclui pelo menos um componente de seleção e um componente de condição. Há um componente de intervalo de tempo opcional que é necessário para regras baseadas em correlação.
Subcomponente de Seleção:
- Geralmente, isso toma a forma Campo A contém/inicia_com/termina_com/é_igual Valor B. É claro que, como observado na regra de exemplo acima, se um autor precisar, ele pode expandir e incluir lógica como Campo A contém/inicia_com/termina_com/é_igual Valores X, Y ou Z. Essa lógica é sempre insensível a maiúsculas e minúsculas.
- Existem modificadores mais avançados que aumentam a complexidade da regra ou permitem que os autores sejam mais precisos. Por exemplo, expressões regulares são manuseadas através do operador re e permitem que os autores façam coisas como escrever consultas sensíveis a maiúsculas e minúsculas. Para fins de compatibilidade, é melhor se restringir a usar apenas os operadores regulares básicos . ? + * | { } [ ] () ” .
- As seleções são nomeadas (por exemplo, seleção, seleção2, seleção3, filtro). As seleções podem ser nomeadas (quase) como quiser. Muitas vezes, uma variação de seleção é usada, mas você pode nomear sua seleção de banana e a regra ainda funcionaria. Geralmente, o termo filtro é usado para seleções que serão excluídas (por exemplo, seleção E NÃO filtro).
Subcomponente de Condição:
- O componente de condição contém lógica booleana (E, OU, NÃO) definindo como cada seleção deve ser incluída na consulta final.
- Ex.: (seleção_a OU seleção_b) E NÃO filtroComponente de Condição com Correlação
Existem dois tipos de correlações suportadas por backends hoje. Existem outras correlações suportadas pelo esquema SIGMA, mas ainda não pelos backends disponíveis.:
Contar() por Y:
Contar as instâncias únicas do valor do campo Y e comparar (maior que, menor que) com um número estático.
Exemplo:
Contar() por src_ip > 2 Contar(X) por Y:
Contar as instâncias únicas do valor do campo X por valor Y e comparar (maior que, menor que) a contagem de X com um número estático.
Contar(EventID) por src_ip > 2
Contar() por src_ip > 2 Casos de Uso Comuns de Correlação:
Subcomponente de Intervalo de Tempo:
Count() by src_ip > 10 | Count unique matching events by the source IP. |
Count() by dst_ip > 10 | Count unique matching events by the destination IP |
Count(EventID) by ComputerName | This will let you search for unique instances of eventid. For instance, if you want to chain sysmon event ids 1 (process creation) AND event id 5. e.g. a process is created and terminated in less than 1 min. |
O componente
- The de intervalo de tempo é usado em conjunto com condições que incluem uma correlação. Muitos backends ignoram o intervalo de tempo, no entanto, ele geralmente é sempre incluído e exigido para ser incluído na maioria dos repositórios, incluindo o da SOC Prime. Exemplos Completos Usando Splunk:
Aqui estão alguns exemplos de SIGMA e suas traduções para Splunk. Se você não está familiarizado com Splunk, asteriscos são curingas, então um termo cercado por asteriscos (por ex., *termo*) é ‘contém’, um termo com asterisco à frente (por ex., *termo) é termina_com, um termo com asterisco no final é ‘termina_com’ (por ex., termo*).
- Questões de Taxonomia (por exemplo, quais nomes de campos usar)
SIGMA detection component | Splunk Translation (Asterisk is a wildcard) |
detection: selection: fieldX: 'suspicious' condition: selection | fieldX="suspicious" |
detection: selection: fieldY|contains: - 'suspicious' - 'malicious' - 'pernicious' condition: selection | (fieldY="*suspicious*" OR fieldY="*malicious*" OR fieldY="*pernicious*") |
detection: selection: - fieldX: 'icious' - fieldX: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern")) |
detection: selection: - FieldX|endswith: 'icious' - FieldX|startswith: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="*icious" AND (FieldX="susp*" OR FieldX="mal*" OR FieldX="pern*")) |
detection: selection: FieldX|endswith: 'icious' filter: FieldX|startswith: - 'del' - 'ausp' condition: selection AND NOT filter | (FieldX="*icious" AND NOT ((FieldX="del*" OR FieldX="ausp*"))) |
detection: selection: FieldX: 'suspicious' timeframe: 1m condition: selection | count by src_ip > 3 | FieldX="suspicious" | eventstats count as val by src_ip| search val > 3 #notice splunk ignores the timeframe value, the value must be set at search by the user |
detection: selection: FieldX: 'suspicious' condition: selection | count(ComputerName) by src_ip > 3 | FieldX="suspicious" | eventstats dc(ComputerName) as val by src_ip | search val > 3 |
Teoricamente, você pode usar os nomes de campos que desejar, desde que alguém esteja disposto a investir tempo para escrever um Config SIGMA para traduzir de seus campos para os deles.
Os nomes dos campos são sensíveis a maiúsculas e minúsculas!
Nota: Field names are case sensitive! Linha de Comando and linha de comando são dois valores diferentes. Linha de Comando faz parte da taxonomia existente, linha de comando não.
Dito isso, é melhor usar nomes de campos que são documentados pelo SIGMA. Existem três locais onde o repositório público SIGMA documenta a taxonomia.
Como regra geral, usamos os nomes de campos SIGMA especificados no wiki para categorias
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- O wiki revelará aos leitores que SIGMA usa
— campos SYSMON para regras de endpoint
— Formato de Arquivo de Log Estendido W3C para regras de servidor web e proxy
— Os campos para firewall, antivírus
Seguido pelos nomes de campos SIGMA especificados em regras existentes e arquivos de configuração SIGMA
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Realmente a documentação oficial para campos. Os usuários podem criar/modificar isso conforme necessário ao traduzir regras.
- https://github.com/SigmaHQ/sigma/tree/master/rules
Então, finalmente, se não existir configuração ou regras, usamos os nomes de campos originais da fonte de log original. Se os nomes dos campos vierem de valores aninhados (por ex. identidadeDoUsuário aninhado sob ID de conta no aws cloudtrail) usamos um ponto para indicar que o campo está aninhado, pois isso é relativamente consistente entre diferentes SIEMs (por ex. identidadeDoUsuário -> ID de conta torna-se identidadeDoUsuário.ID de conta).
Testando Regras SIGMA
Testar regras SIGMA é simples. Muitas vezes, as pessoas podem até enviar conteúdo sem testar diretamente. A maioria dos pesquisadores públicos não tem acesso a ambientes diversificados para testar regras contra “o conjunto de todos os SIEMs”. Em vez disso, uma pessoa pode confiar em feedback público, feedback de partes confiáveis, etc. Até mesmo Florian Roth, um co-criador do SIGMA, regularmente publica regras para o público em busca de feedback através de seu Twitter. Também vi pessoas publicarem diretamente em seus blogs pessoais e LinkedIn, etc. Se você acha que tem uma boa regra para compartilhar, publique, confie em mim, se estiver errada (ou não), as amáveis pessoas na internet vão te avisar! Não se leve tão a sério e esteja preparado para fazer alterações e aprender algo.
Existem alguns passos básicos que você pode seguir:
- Certifique-se de que a regra traduz (uncoder ou usando SIGMAC)
- Verificação de sanidade (por exemplo, garantir que a regra atenda à sua expectativa original, siga a taxonomia correta, etc) – veja armadilhas: https://github.com/SigmaHQ/sigma/wiki/Creation-Guide
- Verificando a regra em um ambiente de laboratório
- Compartilhando a regra amplamente para testes/compartilhando a regra com a Equipe SOC Prime via o Programa de Recompensa por Ameaças
Nota: Do ponto de vista do autor da regra, geralmente você não deve se preocupar com as implementações de backends das regras. Cabe aos autores de backends SIGMA, e pessoas como a SOC Prime, garantir que as traduções atendam à intenção original de uma regra válida. Se um bug for identificado, sempre vale a pena enviar uma questão para o GitHub.
Sobre a SOC Prime
- Fundaram a indústria de Detecção-como-Código em 2015
- Parceiros com Fortune 100 + MDRs globais
- Cobrindo todo o pipeline da detecção à simulação
- Pesquisa de ameaças mágica em vez de filtros
- 650.000+ regras de detecção
- Novas ameaças diárias
- Detecção ETL em Velocidade de Linha
- Detecção Shift-Left, Feita do Jeito Certo
FAQ
O que é uma regra SIGMA?
Uma regra SIGMA é uma detecção neutra de fornecedor escrita em YAML que descreve atividade suspeita em logs. Você pode traduzi-la em consultas para muitos SIEMs e ferramentas de log.
Quais são as duas partes essenciais de uma regra SIGMA?
Inclua logsource e detecção. logsource define o tipo de logs (como criação de processo do Windows), e detecção contém a lógica de correspondência e condição.
Como você escreve uma condição de detecção SIGMA?
Crie uma ou mais “seleções” que correspondam campos e valores, depois combine-as na condição usando AND/OU/NOT. Isso permite que você expresse correspondências simples e lógica mais complexa.
Como escolher uma boa fonte de log para sua primeira regra SIGMA?
Escolha algo amplamente implantado para que outros possam usá-lo. Para detecções de endpoints do Windows, o Sysmon é uma escolha comum e a criação de processo (process_creation) é um ponto de partida prático.
Como testar uma regra SIGMA antes de usá-la em produção?
Traduza-a para sua plataforma alvo (por exemplo, com um conversor SIGMA), execute-a contra dados reais ou de laboratório, e ajuste-a para reduzir falsos positivos antes de implementá-la amplamente.
