Achados com sinal detectável em log podem gerar uma regra Sigma inicial — um ponto de partida, não uma detecção em produção. Este guia cobre a origem das regras e como adaptá-las ao seu SIEM com responsabilidade.
O ciclo de vida é a disciplina: starter significa gerada, tuned significa adaptada e testada no seu ambiente, verified significa evidência registrada mostrando que ela dispara. Nunca pule uma etapa porque o YAML parece pronto.
De onde as regras vêm
- O gerador cria uma regra inicial quando o achado possui um sinal que pode aparecer nos registros. Nem todo achado é detectável dessa forma.
- Baixe o conjunto na página da execução ou use `GET /v1/demo/runs/{run_id}/sigma` no ambiente controlado e `GET /v1/runs/{run_id}/sigma` em uma execução da organização.
- A marca `starter` significa rascunho: ajuste nomes de campos, fonte dos registros e limites antes de implantar.
O gerador cria uma regra inicial só quando o achado tem um sinal que pode aparecer em logs — nem todo achado consegue. Baixe o pacote completo na página da execução ou pela API e trate o disclaimer de cada regra como parte do artefato.
Importar e calibrar
- No Splunk, converta o YAML com `sigma-cli convert -t splunk`, revise a consulta resultante e ajuste a janela ao atraso de ingestão dos registros.
- No Elastic, use `sigma-cli convert -t esql` ou a importação nativa e associe `sigma.logsource.service` ao índice correto.
- Mude o estado de `starter` para `tuned` somente após ajustar a regra. Use `verified` apenas quando houver evidência registrada de que ela detecta o caso esperado sem produzir uma taxa inaceitável de falsos alertas.
Converta com sigma-cli para a sua plataforma — SPL no Splunk ou ESQL no Elastic — e mapeie o log source para o seu índice real de logs de requisições LLM. Defina timeframes e limites a partir do seu tráfego e avance uma regra só depois de adaptá-la e testá-la.