De un script a una regla que lo vea la próxima vez

De un script salen tres clases de datos. Los valores concretos —un dominio, el nombre de una carpeta, el nombre de un valor de registro— son útiles pero frágiles: el autor los cambia en la siguiente versión. El comportamiento —un PowerShell oculto que recibe un archivo del perfil del usuario— cambia menos, y se detecta con reglas sobre procesos. Y hay ruido: nombres fijos de la plataforma, como los eventos de apertura de Excel, que cualquier documento legítimo con macros también lleva.

La disciplina es no confundir las tres clases. Un indicador que también aparece en actividad normal alerta de más; uno que solo describe el valor de hoy deja de servir mañana.

Abre candidatos.txt en la estación: son ocho valores sacados de los tres casos. Antes de ponerlos en una regla o en una lista, cada uno pasa por la misma pregunta: «¿esto lo eligió quien escribió el archivo, o es parte de la plataforma?». Un nombre que pertenece al sistema que lo ejecuta aparecerá en actividad legítima, y ponerlo en una lista de bloqueo o en una alerta genera ruido y falsas alarmas.

Un solo candidato de la lista es un nombre fijo de la propia aplicación de oficina y no un valor elegido por el autor.

Sigma es un formato abierto para escribir reglas de detección que luego se traducen al lenguaje de cada SIEM. Una regla declara en qué registro mira (logsource), qué condiciones debe cumplir el evento (detection) y con qué nivel avisa. Cuando hay varias condiciones unidas por and, el evento debe cumplir todas. Los modificadores como endswith y contains comparan texto sin distinguir mayúsculas de minúsculas.

Abre regla-borrador.yml y eventos-de-prueba.txt. Aplica la regla a cada evento, a mano, y cuenta cuántos darían alerta. Es el mismo ejercicio que hace una prueba antes de activarla, solo que con papel.

Una regla que alerta sobre actividad normal cansa al turno. Para saber si un evento que alertó es un falso positivo, se mira su origen y se compara con lo que se sabe de la empresa: quién lo lanza, desde qué ruta y por qué. La salida no es apagar la regla, sino anotar una excepción acotada, con dueño y caducidad, que no tape el comportamiento real.

Entre los eventos que dan alerta, uno es actividad legítima de un agente de la empresa.

El error opuesto es peor: un falso negativo, una conducta real que la regla no ve. Se encuentra al revés, tomando los eventos que sí son la conducta que se busca y comprobando que cada uno dispara la regla. Si uno no dispara, se mira qué condición lo deja fuera y se ajusta la regla, no el evento.

El borrador escribe la opción de PowerShell completa. PowerShell acepta abreviaturas de sus opciones, y quien las usa se escapa de una condición literal.