Validar contra registros de prueba

Validar una regla es comprobar dos cosas. Con casos positivos (eventos que representan la conducta que se quiere ver) se mide si la regla la detecta; con casos negativos (eventos legítimos parecidos) se mide si calla cuando debe. Los positivos de un boletín valen oro, porque son la conducta tal como se vio en otros; los negativos solo los puede poner la propia casa.

Y una tercera comprobación que se olvida: repetir la regla sobre registros reales recientes y mirar no solo cuántas alertas da, sino cuántos eventos leyó. Cero alertas sobre cero eventos no dice nada.

Abre la consola. casos_de_prueba trae nueve casos con su resultado esperado y resultado_prueba_lru_s04 lo que dio la versión 1.0 de la regla local, con el bloque que decidió cada uno.

Un positivo que no da alerta es un falso negativo: la regla tiene un hueco por donde la conducta pasa sin ruido. Hay que encontrarlo y entender por qué no coincidió.

Para la nota de validación hace falta la cifra de detección de la versión 1.0: de los casos positivos, cuántos dieron alerta.

Un negativo que da alerta es un falso positivo que todavía no está documentado. Aquí no es un misterio: corresponde a una actividad legítima que en la sala anterior ya se vio en la prueba de catorce días y para la que no había filtro propuesto.

repeticion_30_dias muestra la versión 1.0 repetida sobre los últimos treinta días, por grupo: qué fuente leyó, cuántos eventos de creación de proceso había y cuántas alertas dio. Casi todos los grupos dan cero alertas, pero no todos los ceros valen lo mismo.