Uma regra está gerando centenas de alertas por dia. Como você faz o tuning sem criar um ponto cego?

Analise o ruído antes de tocar na regra. Agrupe os alertas por host, usuário, processo e linha de comando para achar quais poucas fontes produzem a maior parte do volume, e depois escreva exclusões estreitas ancoradas em atributos duráveis, como um caminho de binário assinado mais um processo pai específico, e não um curinga amplo. Mantenha os eventos suprimidos pesquisáveis, defina uma revisão com prazo, e documente o risco residual que você aceitou.

Primeiro eu puxo trinta dias daquela regra e agrupo os disparos. Normalmente oitenta por cento vem de três fontes. Em um trabalho, uma regra de certutil estava nos afogando, e acabou sendo um agente de distribuição de software chamando certutil para checar uma cadeia de certificados em toda instalação. A minha exclusão não foi certutil. Foi aquele processo pai específico, daquele caminho de instalação, rodando com a conta de serviço da distribuição. Qualquer outra coisa chamando certutil continuava alertando. Eu também mantive os eventos fluindo para o data lake com o alerta desligado, para que, se a gente precisasse caçar entre eles depois, o histórico estivesse lá. Depois coloquei uma revisão de noventa dias na exclusão e escrevi uma linha no registro de mudança dizendo o que um atacante precisaria controlar para abusar dela, o que aqui significava comprometer o servidor de distribuição, e a gente já tinha monitoramento separado naquela máquina. O volume foi de cerca de quatrocentos por dia para menos de dez e a gente não perdeu a técnica.