Una regla genera cientos de alertas al día. ¿Cómo la ajustas sin crear un punto ciego?

Analiza el ruido antes de tocar la regla. Agrupa las alertas por host, usuario, proceso y línea de comandos para ver qué pocas fuentes producen la mayor parte del volumen, y luego escribe exclusiones estrechas ancladas a atributos duraderos, como la ruta de un binario firmado más un proceso padre concreto, no un comodín amplio. Mantén los eventos suprimidos consultables, fija una revisión con fecha de caducidad y documenta el riesgo residual que aceptaste.

Primero saco treinta días de esa regla y agrupo los aciertos. Normalmente el ochenta por ciento viene de tres fuentes. En un trabajo una regla de certutil nos estaba ahogando, y resultó ser un agente de despliegue de software que llamaba a certutil para comprobar una cadena de certificados en cada instalación. Mi exclusión no fue certutil. Fue ese proceso padre concreto, desde esa ruta de instalación, ejecutándose con la cuenta de servicio del despliegue. Cualquier otra cosa que llamara a certutil seguía alertando. Además mantuve los eventos entrando en el data lake con las alertas apagadas, para que si luego hacía falta cazar sobre ellos el histórico estuviera ahí. Después le puse una revisión a noventa días a la exclusión y escribí una línea en el registro de cambios diciendo qué necesitaría controlar un atacante para abusar de ella, que aquí era comprometer el servidor de despliegue, y ya teníamos monitorización aparte sobre esa máquina. El volumen pasó de unas cuatrocientas al día a menos de diez y no perdimos la técnica.