Asistentes para redactar reglas y sus errores

Un asistente produce una regla que se parece a las que vio: tiene la estructura correcta, nombres de campo verosímiles y comentarios seguros de sí mismos. Eso no garantiza que los campos existan en tu esquema, que los operadores hagan lo que parece, que la fuente llegue al SIEM ni que el resultado no sea demasiado amplio. Cada una de esas cosas se comprueba con datos propios, y la regla entra al ciclo normal: pruebas con casos positivos y negativos, revisión de un par y despliegue por etapas.

Compara las columnas campo de regla_del_asistente con los campos de esquema_real. Una condición sobre un campo que no existe no falla con ruido: en muchos motores simplemente no coincide nunca, y la regla queda muda sin que nadie lo note. Cuenta cuántas de las seis condiciones usan un campo que el esquema real no tiene.

Una condición puede usar un campo real y aun así ser mala. muestra_de_50000_eventos dice cuántos eventos de una muestra cumplen cada condición válida por separado. Una condición que coincide con una gran parte del tráfico no discrimina: unida a otras con Y quizá se salve, pero si alguna de ellas falla por el campo inexistente, el resto queda solo.

Una regla de proceso solo ve a los equipos que envían eventos de proceso. El asistente no podía saberlo: lo dice cobertura_de_fuentes. Una regla impecable sobre una fuente que cubre solo una parte del parque deja a los demás equipos sin protección, y conviene decirlo en la ficha de la regla.

El borrador tiene campos inexistentes, una condición válida demasiado amplia y una fuente que no cubre todo el parque. Hay cosas que se corrigen en la regla y otras que se documentan fuera de ella.