Cibersegurança e segurança da informação

Regras Sigma: Escrever, Testar e Converter para SIEM

6 min de leituraPublicado: 5 de agosto de 2026
Ilustração visual profissional sobre a escrita de Regras Sigma na área de Threat Hunting e deteção
Resposta rápida

Escrever Regras Sigma começa com uma pergunta ou comportamento a detetar, continua com a definição de Telemetria e lógica, e termina com testes, afinação, documentação e implantação controlada. A qualidade é medida pela cobertura e capacidade de investigação.

Threat Hunting e Detection Engineering transformam o conhecimento do comportamento do adversário em perguntas mensuráveis, fontes de dados e regras de deteção. O objetivo não é gerar mais alertas, mas melhorar a cobertura e a qualidade da decisão. Este artigo foca-se na escrita de Regras Sigma e destina-se a analistas SOC e profissionais de Deteção iniciantes. O objetivo é fornecer um método de trabalho que pode ser aplicado em treino, numa entrevista profissional e num ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. title/id/status, logsource, detection selections podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos o teste em torno de uma pergunta de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: escrever uma Regra para Criação de Processos anormais num laboratório. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de parar o teste.

Estrutura Sigma

Os campos importantes não são necessariamente aqueles exibidos no topo do ecrã. Ao escrever Regras Sigma, deve-se identificar identificadores estáveis, tempo, origem, destino, resultado e contexto. Exemplos úteis são title/id/status, logsource, detection selections, condition, falsepositives, tags. O objetivo é permitir a Correlação entre registos e não apenas a leitura de um único Evento.

É recomendável criar um pequeno dicionário de dados: nome do campo, significado, formato, origem, valores Null esperados e se é confiável para ligação. Assim, é possível distinguir entre um campo de exibição e um identificador investigativo, e identificar quando um Conector ou versão alterou o Schema.

Logsource e Campos

Os campos importantes não são necessariamente aqueles exibidos no topo do ecrã. Ao escrever Regras Sigma, deve-se identificar identificadores estáveis, tempo, origem, destino, resultado e contexto. Exemplos úteis são title/id/status, logsource, detection selections, condition, falsepositives, tags. O objetivo é permitir a Correlação entre registos e não apenas a leitura de um único Evento.

É recomendável criar um pequeno dicionário de dados: nome do campo, significado, formato, origem, valores Null esperados e se é confiável para ligação. Assim, é possível distinguir entre um campo de exibição e um identificador investigativo, e identificar quando um Conector ou versão alterou o Schema.

Seleção e Condição

O tópico 'Seleção e Condição' é uma parte central do trabalho na escrita de Regras Sigma. É recomendável dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe title/id/status, logsource, detection selections, condition, falsepositives, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Falsos Positivos e Nível

A melhoria na escrita de Regras Sigma deve começar com um Baseline. Mede-se volume, taxa de casos úteis, tempo de investigação, fontes ausentes e motivo de encerramento. Uma mudança que reduz Alertas, mas oculta atividade real, não é um sucesso.

As opções de Afinação incluem limite, janela de tempo, Allowlist direcionada, Contexto de ativo, Supressão e exceção baseada em processo aprovado. Cada exceção deve ter um proprietário, validade e condições de cancelamento. Após a alteração, executa-se um Test corpus e compara-se antes/depois.

Conversão e Teste em SIEM

Um teste profissional para a escrita de Regras Sigma começa com condições de sucesso e condições de falha. Define-se um Caso positivo, Caso negativo, Caso limite e atividade legítima semelhante. Assim, é possível identificar tanto False Negative quanto False Positive.

Num ambiente autorizado, usa-se uma operação mínima que prova a alegação sem causar danos. Guarda-se Input, Output, tempo e versão, e após a correção, realiza-se um Retest no mesmo cenário e verifica-se também a Regressão em funções próximas.

Focos de Teste Únicos

Neste tópico, é recomendável construir um mapa de evidências focado de antemão. Os principais focos de teste são: title/id/status, logsource, detection selections, condition, falsepositives, tags. A lista não é um Checklist automático; cada item é selecionado porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

  • title/id/status: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional confirmará a descoberta.
  • logsource: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional confirmará a descoberta.
  • detection selections: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional confirmará a descoberta.
  • condition: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional confirmará a descoberta.
  • falsepositives: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional confirmará a descoberta.
  • tags: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional confirmará a descoberta.

Quando um dos focos não está disponível, deve-se documentar a lacuna e escolher uma alternativa. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for encriptado, usa-se Metadata, volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

  1. Defina o Scope e uma única pergunta de trabalho sobre a escrita de Regras Sigma.
  2. Registe as fontes de dados e evidências necessárias: title/id/status, logsource, detection selections, condition.
  3. Crie um Baseline curto de comportamento normal ou resultado esperado.
  4. Realize o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
  5. Crie uma Linha de Tempo ou tabela de comparação e separe facto de interpretação.
  6. Faça um Pivot para uma fonte adicional para verificar ou refutar a explicação inicial.
  7. Resuma a decisão, limitações, ação recomendada e critério de Reteste.

Cenário Prático

O cenário escolhido é a escrita de uma Regra para Criação de Processos anormais num laboratório. O objetivo do exercício não é provar a capacidade de ataque, mas praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, janela de tempo e resultado esperado.

No final do exercício, deve-se apresentar um produto que outro analista ou testador possa rever: uma imagem ou Export da evidência, uma curta Linha de Tempo, uma hipótese inicial, evidência de confirmação, limitação e recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

EtapaO que se fazProduto
PreparaçãoDefina Scope, tempo e objetivo. Registe quais campos ou evidências de title/id/status, logsource, detection selections são esperados.Plano de teste curto
Geração de dadosExecute uma ação segura e simulada relacionada com a escrita de Regras Sigma, sem informações reais ou impacto num sistema de produção.Evento/Pedido/Fluxo controlado
RecolhaRecolha a evidência bruta e o contexto de uma fonte adicional. Verifique Time zone, identificadores e integridade.Duas evidências ligadas
AnáliseEscreva o que cada evidência prova, o que não prova e qual é a possível explicação legítima.Conclusão intermédia
ConclusãoEscolha fecho, escalada, Finding ou Tuning; adicione recomendação e Retest.Produto documentado

Checklist Prático

  • Verifique e documente: Hypothesis.
  • Verifique e documente: Técnica ATT&CK.
  • Verifique e documente: Data sources.
  • Verifique e documente: Detection logic.
  • Verifique e documente: Expected benign behavior.
  • Verifique e documente: Test cases e coverage.
  • Indique Time zone, versão da ferramenta e hora de recolha.
  • Guarde os dados brutos antes da filtragem ou alteração.
  • Escreva o que a descoberta prova e o que ainda é desconhecido.
  • Defina proprietário e ação de acompanhamento com prazo.

Erros Comuns

  • Começar com um IOC aleatório sem Hypothesis.
  • Mapear ATT&CK apenas pelo nome.
  • Escrever uma Rule sem Test cases.
  • Ignorar comportamento legítimo.
  • Medir Rules em vez de Coverage.
  • Não gerir versões.

Resumo e CTA

Regras Sigma: Escrever, Testar e Converter para SIEM é um tópico que conecta conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No percurso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. O passo seguinte natural é consultar os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portefólio profissional.

Perguntas frequentes

Escrever Regras Sigma por si só prova um ataque ou vulnerabilidade?

Não. Ele fornece um sinal ou descoberta que requer contexto, verificação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na conformidade com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não preencha campos por suposição nem apresente Desconhecido como válido.

Por quanto tempo as evidências devem ser guardadas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente Retention, Legal hold e a capacidade de exportar evidências num formato que possa ser verificado.

Como praticar sem colocar em risco um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina Scope, Stop conditions e backup antes de iniciar o trabalho.

Quer verificar se este percurso é para si?

Deixe os seus dados e um consultor da HPI ligará para uma breve conversa de adequação, sem compromisso.

Os seus dados são armazenados em segurança.

Para estudos de SOC e cibersegurança no programa Cybersecurity & AI

Quer os detalhes do programa? Deixe os seus dados e entraremos em contacto.

Artigos relacionados