O Que São Regras SIGMA: Guia para Iniciantes
Índice:
Este post de 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 analistas que são novos para SIGMA a escrever suas primeiras regras. Também é fornecida uma breve discussão sobre engenharia de detecção com SIGMA em relação a ruído, ideias, fontes de logs, etc.
O Caso para Regras SIGMA
No passado, as detecções SIEM existiam em silos específicos de fornecedores/plataformas. Parceiros que desejavam compartilhar conteúdo de detecção costumavam ter que traduzir uma consulta de um fornecedor para outro. Isso não é sustentável, a comunidade de cibersegurança defensiva deve melhorar a maneira como compartilhamos detecções para acompanhar nossos adversários sempre em evolução.
Muito parecido com YARA, ou Regras Snort, SIGMA é outra ferramenta para o compartilhamento aberto de detecções, exceto que se concentra no SIEM em vez de arquivos ou tráfego de rede. SIGMA permite que 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, o SIGMA está abrindo caminho para uma busca agnóstica de plataformas. Com o SIGMA, os defensores são liberados da linguagem de detecção específica de fornecedores & plataformas e repositórios e podem aproveitar o poder da comunidade para responder oportunamente a ameaças críticas e novas técnicas de adversários.
Há muitas razões para usar SIGMA:
- Pesquisadores e equipes de inteligência que identificam novos comportamentos de adversários e querem uma maneira agnóstica de compartilhar detecções
- MSSP / MDR responsáveis por múltiplas soluções SIEM / EDR / Log Analytics & taxonomias/esquemas de dados (ECS, CEF, CIM, etc)
- Evitar dependência do fornecedor, definindo regras em SIGMA podemos nos mover mais facilmente entre plataformas.
- Pesquisadores no espaço de segurança ofensiva querendo criar detecções baseadas em suas pesquisas
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 na sua definição de “SIEM”. No entanto, usar os termos “plataforma” ou “plataforma de logs” é muito ambíguo.
Criando Regras SIGMA
Escrever regras SIGMA requer ter conhecimento básico sobre o esquema e a taxonomia SIGMA, ter uma ideia, ajustá-la ao SIGMA, testar, compartilhar e potencialmente manter a regra.
Plano de Fundo & Contexto Recomendados
Apesar do comprimento deste blog, graças ao YAML e ao pensamento avançado pelos criadores, SIGMA é fácil de entender e escrever. Na SOC Prime, costumamos dizer que “qualquer um pode aprender SIGMA”. A arte da engenharia de detecção é onde as coisas podem ficar 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 buscando entrar no SIGMA, o Programa de Ameaças da SOC Prime é uma grande oportunidade para começar e ganhar um pouco de dinheiro. As regras submetidas passam por um processo de revisão completo onde podemos orientá-lo e ajudá-lo a entender 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
Assistir 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 da SOC Prime geralmente não cria regras multi-yaml porque adicionam complexidade desnecessária à manutenção e implantação das regras. Alguém pode criar uma regra SIGMA multi-yaml se puder criar duas regras SIGMA.
Vamos Criar uma Regra SIGMA Simples!
Uma ideia (e alguns pensamentos sobre engenharia de detecção com SIGMA)
Usuários e administradores frequentemente mantêm senhas sensíveis em documentos de texto simples, como arquivos de texto, excel, word, etc. Estou preocupado que adversários possam identificar esses arquivos antes de mim em um ambiente. Queremos instruir nossos usuários sobre como armazenar senhas corretamente antes que sejam descobertas por um hacker criminoso.
Para muitas regras SIGMA é do interesse do autor abstrair a ideia e ampliar o alvo ‘razoavelmente’. Para ideias como esta podemos fazer suposições informadas sobre como o comportamento may parece, não apenas o que observamos. Por exemplo, podemos fazer suposições informadas sobre termos e extensões adicionais que os usuários podem usar para armazenar senhas em texto simples.
A ideia de ‘ampliar’ uma regra é contraintuitiva para muitos instintos de 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 que os fornecedores de EDR e Anti-Vírus se preocupem em criar detecções que não possam ter falsos positivos. Com regras SIGMA podem ser testadas em ambientes e ajustadas facilmente.
SIGMA é facilmente entendida, testável e ajustável. Se um termo como ‘detalhes’ é muito ruidoso 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 uma loja perca conteúdo sólido de detecção.
Gosto de dar o exemplo do psexec. Em alguns ambientes, o psexec é completamente normal e o status-quo para administradores acessarem remotamente hosts. Em outros ambientes, o psexec é (provavelmente com razão) não aprovado, bloqueado, e uma ofensa acionável para administradores usarem. Então, é uma regra SIGMA para detectar qualquer uso do psexec ‘ruidosa’ ou apenas melhor para alguns ambientes do que para outros. Se você implantar conteúdo sem testar, ajustar o ruído sempre será um problema. Somente as regras identificadas como “críticas” são destinadas a serem seguras para uso sem teste.
Voltando a criar nossa regra SIGMA de exposição de senha… podemos expandir a ideia para incluir nomes de arquivos adicionais, como:
- pw
- psw
- pass
- senha
- senhas
- contas
- conta
- info
Criado com software como:
- Notepad
- Notepad++
- Wordpad
- Aplicativos do Office
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 possui. Por exemplo, talvez possamos escrever uma regra para uma fonte de log de Prevenção de Perda de Dados, mas Prevenção de Perda de Dados raramente é analisada e ingerida em SIEMs, e a indústria não tem um claro favorito. Portanto, podemos criar uma regra válida, mas ela não será tão facilmente adotada.
Para regras de endpoint no Windows, Sysmon é um ótimo lugar para começar. Sysmon é comumente implementado em ambientes, e muitas fontes de log fornecem dados sinônimos (EDRs, etc). Com Sysmon há duas opções principais, criação de processo (process_creation no SIGMA) e criar arquivo (file_event no SIGMA).
Construiremos nossa detecção com base na 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 log para aprender e é uma das mais úteis / populares fontes de log usadas em detecções de endpoint.
Nota: Muitas vezes, ideias vêm diretamente das próprias fontes de dados. Revisando os tipos de dados disponíveis no seu SIEM / Lab, pode-se facilmente identificar regras SIGMA que valem a pena escrever. Podemos também 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:
Imagem: C:WindowsSystem32notepad.exe
Linha de Comando: “C:WindowsSystem32NOTEPAD.EXE” C:UsersJohnDesktoppassword.txt
Ajustando a ideia de detecção para SIGMA
Agora que temos uma ideia e uma fonte de dados para trabalhar, podemos começar a construir nossa regra.
Isso não está documentado, mas os verdadeiros componentes necessários para traduzir uma regra são apenas logsource & detecção (para alguns backends como Splunk, apenas 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 quiser publicar sua regra no repositório público SIGMA, vale a pena verificar submissões anteriores e emular seu formato.
Uma regra SIGMA básica com componentes mínimos para potencial exposição de senha:
título: Exposição Potencial de Senha (via cmdline)
autor: Adam Swan
tags:
- attack.t1552.001
- attack.credential_access
logsource:
product: windows
category: process_creation
detecção:
seleção:
Image|endswith:
- 'notepad.exe'
- 'word.exe'
- 'excel.exe'
- 'wordpad.exe'
- 'notepad++.exe'
CommandLine|contains:
- 'pass' #pass coincide com password, incluindo password é redundante
- 'pwd'
- 'pw.' #pw.txt, etc.
- 'conta' #accounts,
- 'segredo'
- 'detalhes' #Eu incluí plural detalhes baseado na experiência
condição: seleção
Componente de origem de log
The logsource componente ajuda o tradutor de backend do SIGMA (SIGMAC) a saber contra qual tipo de dados a regra deve ser aplicada. Ela 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 IDs de eventos (Sysmon 1, Windows 4688, ProcessRollup, etc). O consumidor da regra pode especificar quais IDs de eventos, índices, etc., eles querem associar a fontes de logs na Configuração SIGMA. Sem especificar índices, IDs de eventos, etc, as regras provavelmente serão desnecessariamente caras (desempenho) para o consumidor.
Além disso, muitas vezes a telemetria pode conter campos semelhantes, mas implicar comportamentos inteiramente diferentes. Por exemplo, eventos de conexão de rede do Sysmon (Id do Evento 3) e criação de processos (ID do Evento 1) compartilham o Imagem campo. A existência de explorer.exe no Imagem campo de um evento de 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 de origem de log adequado, oferecemos um contexto inestimável para a detecção.
Componente de Detecção
O componente de detecção é onde o autor define seus critérios de detecção. Isso 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.
Subcomponentes de Seleção:
Geralmente, isso tomará a forma Campo A contém/começa com/termina com/equals Valor B. Claro, como observado na regra de exemplo acima, se um autor precisar, pode expandir e incluir lógica como Campo A contém/começa com/termina com/equals Valores X, Y ou Z. Essa lógica é sempre insensível a maiú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 tratadas através do operador re e permitem que autores façam coisas como escrever consultas sensíveis a maiúsculas. Para fins de compatibilidade, é melhor ficar apenas com os operadores de expressão regular 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 você quiser. Muitas vezes uma variação de seleção é usada, mas você pode simplesmente nomear sua seleção banana e a regra ainda funcionará. Geralmente, o termo filtro é usado para seleções que serão excluídas (por exemplo, seleção E NÃO filtro).
Componente 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 filtro
Componente 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 para um número estático.
Exemplo: Contar(EventID) por src_ip > 2
Casos de Uso Comuns de Correlação:
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. |
Subcomponente de Intervalo de Tempo:
The componente de tempo é usado em conjunto com condições que incluem uma correlação. Muitos backends ignoram o intervalo de tempo, no entanto, geralmente é sempre incluído e é necessário ser incluído na maioria dos repositórios, incluindo o da SOC Prime. component is used in conjunction with conditions that include a correlation. Many backends ignore the timeframe, however, it is generally always included and required to be included in most repositories including SOC Prime’s.
Exemplos Completos Usando o Splunk:
Aqui estão alguns exemplos de SIGMA e suas traduções para Splunk. Se você não está familiarizado com o Splunk, asteriscos são um curinga, então um termo cercado por asteriscos (por exemplo, *termo*) é ‘contém’, um termo com um asterisco à frente (por exemplo, *termo) é termina com, um termo com um asterisco no final é ‘termina com’ (por exemplo, termo*).
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 |
Questões de Taxonomia (por exemplo, quais nomes de campos usar)
Teoricamente, você pode usar quaisquer nomes de campos que desejar, desde que alguém esteja disposto a investir tempo para escrever uma Configuração SIGMA para traduzir dos seus campos.. para os deles.
Nota: Nomes de campos são sensíveis a maiúsculas! CommandLine and commandline são dois valores diferentes. CommandLine faz parte da taxonomia existente, commandline não faz.
Dito isso, é melhor usar nomes de campos que sejam documentados pela SIGMA. Existem três lugares onde o repositório público SIGMA documenta a taxonomia.
- Como regra geral, usamos os nomes dos 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 servidores web & proxy
- Os campos para firewall, antivírus
- Seguido por nomes de campos SIGMA especificados em regras existentes & 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
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
Então, finalmente, se não existir configuração ou regras, usamos os nomes de campo originais da fonte de log original. Se nomes de campos vêm de valores aninhados (por exemplo, userIdentity aninhado sob accountId em aws cloudtrail) usamos um ponto para indicar que o campo é aninhado, pois isso é relativamente consistente entre diferentes SIEMs (por exemplo, userIdentity -> accountId se torna userIdentity.accountId).
Testando Regras SIGMA
Testar regras SIGMA é simples. Muitas vezes as pessoas conseguem até enviar conteúdo sem testá-lo diretamente. A maioria dos pesquisadores públicos não tem acesso a ambientes diversos para testar regras contra ‘o conjunto de todos os SIEMs’. Em vez disso, pode-se confiar no feedback público, feedback de partes confiáveis, etc. Até mesmo Florian Roth, um co-criador do SIGMA, regularmente envia regras ao público para feedback via seu Twitter. Já vi pessoas publicando direto em seus blogs pessoais e LinkedIn, etc. Se você acha que tem uma boa regra para compartilhar, coloque-a lá fora, confie em mim, se estiver errada (ou não) as adoráveis pessoas na internet te avisarão! Não se leve muito a sério e esteja preparado para fazer mudanças 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, garantindo que a regra atenda às suas expectativas originais, siga a taxonomia correta, etc) – ver armadilhas: https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
- Verificando a regra em um ambiente de laboratório
- Compartilhando a regra amplamente para testes/compartilhando a regra com a Equipe da SOC Prime via o Programa de Recompensa por Ameaça
Nota: Do ponto de vista do autor da regra, geralmente você não deve se preocupar com as implementações de backend das regras. Cabe aos autores de backend do 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 um problema para o GitHub.
Chamada para Ação & Trabalho Futuro
Se você chegou até aqui, está mais do que preparado para escrever e compartilhar sua primeira regra! Se você gostou deste blog, pode gostar de outro que está por vir sobre como usar o SIGMAC para personalizar conteúdo.
