Documentar lo encontrado y convertirlo en regla

Una cacería que no queda escrita es una cacería que, para el SOC, no ocurrió. La ficha de la cacería tiene lo que cualquiera necesita para repetirla y juzgarla: la hipótesis, las fuentes, la ventana, las consultas exactas, el resultado (hallazgo, vacía o ciega), la evidencia y qué se hace a continuación. Y una parte que casi todos olvidan: lo que quedó sin mirar, porque es lo que impide que un resultado se lea de más. Un «no encontré nada» sin eso se interpreta como «no hay nada».

La tabla registro_caza es el borrador que dejó quien hizo la búsqueda; plantilla_registro es la plantilla de ocho campos que usa el equipo, cada uno con su para qué. Compáralos.

La evidencia de una cacería es una línea de tiempo. En la tabla hallazgos están las tres filas que sostienen el resultado, de tres fuentes distintas y sobre el mismo servidor. Lo que las une no es un identificador común sino el equipo y la hora, y el tiempo entre una y otra es parte de la evidencia: una sesión remota, una tarea nueva y un dominio nunca visto en una misma noche cuentan una historia distinta de la de los mismos tres eventos repartidos en un mes.

Para pasar de la búsqueda a la regla hay tres preguntas. ¿Qué parte describe una conducta y qué parte es de este caso? El nombre de la tarea, la ruta y la cuenta concreta las cambia quien las usa en un día; la conducta, no. ¿Cuántas alertas daría? Se mide corriendo la búsqueda sobre la historia, y lo harás en la tarea siguiente. ¿Qué excepciones necesita? Una regla sin excepciones acotadas entierra al turno.

Y una cuarta, la que más se olvida: no toda búsqueda se vuelve regla. Una regla suele mirar un evento o un conteo en una ventana; una búsqueda que necesita comparar contra una base («primera vez visto») pide una consulta programada con una lista de apoyo, o se queda como cacería periódica hecha a mano. Convertir sin pensar produce reglas que alertan de todo o de nada. Medirla, afinarla y mantenerla son los temas del módulo 6; el formato portable, los del módulo 10.

Antes de activar nada se corre la búsqueda sobre la historia y se cuenta lo que habría alertado. La conducta de la tarea anterior, escrita como inicios_win | where cuenta startswith "svc-", cubre los 45 días de la cacería. La tabla cuentas_de_servicio dice cuáles de esos inicios tienen un motivo documentado y cuáles no; un inicio documentado es ruido para la regla, no un riesgo.

El porcentaje de ruido es la primera cifra que mira quien decide si la regla se activa: una regla con casi todas sus alertas explicadas se apaga a los pocos días.

Casi todo el ruido viene de una cuenta, y la tentación es excluirla. El problema es lo que se pierde: una exclusión ancha deja sin vigilar justo lo que la regla debía vigilar, y esa misma cuenta usada en otro sitio ya no alerta. Una excepción acotada se escribe con lo que sí está documentado, la cuenta y el equipo, y nada más. Prueba las dos en la consola y compara qué deja pasar cada una.

inicios_win
| where cuenta startswith "svc-"
| where cuenta != "svc-balanzas"

inicios_win
| where cuenta startswith "svc-"
| where not (cuenta == "svc-balanzas" and equipo == "msi-srv-bal01")