Una regla que se activa en una prueba controlada todavía no está lista para producción. Necesita encontrar el comportamiento relevante, operar sobre datos confiables y generar alertas que un equipo pueda investigar.
Este artículo trata de lo que hay entre «la regla funcionó en mi prueba» y «la regla mejora la capacidad de detección de la organización», dos cosas muy diferentes.
Define la hipótesis detectable
Describe el comportamiento que pretende observar la regla, el entorno en el que ocurre y los campos de telemetría necesarios.
Diferencia la técnica del indicador utilizado en la prueba. Esta distinción define la vida útil de la regla:
| Nivel | Ejemplo | Costo de evasión |
|---|---|---|
| Valor específico | Un hash de archivo | Recompilar: segundos |
| Herramienta | Un nombre de ejecutable | Renombrar: segundos |
| Patrón de comportamiento | Proceso de oficina que crea un proceso hijo de shell | Cambiar la técnica: alto |
Las reglas del primer nivel tienen valor, pero envejecen en días. Si la detección depende de un único nombre de proceso o dirección, su cobertura es limitada y el informe de cobertura que produce es demasiado optimista.
Especifica también los límites conocidos: fuentes sin recopilar, eventos perdidos, retraso de ingesta y sistemas fuera de alcance. Estos límites forman parte de la capacidad real de la regla. Una detección que cubre el 40 % del parque de equipos y se reporta como cobertura total es peor que ninguna, porque genera una confianza injustificada.
Prepara casos positivos y negativos
Prepara ejemplos autorizados que deban activarla y ejemplos legítimos parecidos que no deberían generar un incidente.
Los casos negativos son donde realmente ocurre el trabajo y la lista debe ser específica de tu entorno:
- la herramienta de administración que hace exactamente lo que busca la regla;
- el software de copias de seguridad que lee volúmenes completos;
- el escáner de vulnerabilidades autorizado;
- la ventana de despliegue en la que se ejecutan scripts masivamente;
- el entorno de desarrollo, donde casi todo es atípico.
Ejecuta los casos en un entorno controlado y registra los eventos sin procesar, además del resultado de la regla. Comprueba si utiliza los campos que imaginaste y si las diferencias entre sistemas cambian el resultado: los nombres de campos, el formato horario y los niveles de detalle de los registros varían entre plataformas y versiones.
Una prueba positiva responde «¿puede detectar este caso?». Los casos negativos responden «¿con qué frecuencia interrumpirá al equipo sin necesidad?». Ninguna de las dos preguntas basta por sí sola.
Mide el costo operativo antes de publicar
Un dato que evita la mayor parte de los problemas: ejecuta la lógica retroactivamente sobre datos históricos antes de publicarla. Treinta días de historial responden, sin costo operativo, cuántas alertas habría generado la regla y cuántas corresponderían a actividad legítima.
El cálculo que decide la publicación:
alertas al día × tiempo medio de triaje = horas de equipo al díaUna regla que genera 40 alertas diarias de 10 minutos cada una consume casi 7 horas de analista al día. Si la tasa de acierto esperada es baja, esa regla no mejora la detección: consume la capacidad que otras detecciones necesitarían.
Observa también el volumen, las duplicaciones y el retraso hasta la alerta. Una regla muy sensible puede producir tantas alertas que señales importantes queden sin analizar: el modo de falla más común y menos discutido en las operaciones de detección. Antes de crear excepciones amplias, entiende qué patrones legítimos generan ruido: una excepción mal diseñada es un agujero permanente en la cobertura.
Prefiere reducir el ruido mediante la lógica antes que mediante excepciones. Exigir dos condiciones correlacionadas suele reducir los falsos positivos sin abrir una excepción que un adversario pueda aprovechar.
Escribe la alerta para quien la recibirá a las 3 de la madrugada
Prioriza el enriquecimiento útil: identificación del activo, función de la cuenta, acciones relacionadas y acceso a los eventos originales. Una alerta debe facilitar la primera decisión del analista.
Qué contiene una alerta sobre la que se puede actuar:
- Qué ocurrió, en una frase sin jerga interna.
- Por qué importa: la hipótesis que motivó la regla.
- Contexto del activo y de la cuenta: criticidad, propietario, privilegio.
- Los tres primeros pasos de verificación sugeridos.
- Enlace a los eventos sin procesar, sin exigir que el analista reconstruya la consulta.
- Qué no es: el falso positivo conocido y cómo descartarlo.
El punto 6 es el más descuidado y el que más tiempo ahorra. Si el equipo ya sabe que la regla se activa durante una ventana de mantenimiento, escribirlo en la alerta evita repetir la misma investigación decenas de veces.
Una alerta que solo dice «actividad sospechosa detectada en el host X» traslada todo el trabajo de contexto a quien está de guardia, precisamente quien dispone de menos tiempo e información para reconstruirlo.
Trata la regla como un producto
Cada regla necesita propietario, propósito, fuente de datos, casos de prueba y una revisión prevista. Versiona la lógica y registra la justificación de los cambios: la pregunta «¿por qué existe esta condición?» aparece meses después y, sin respuesta, nadie se atreve a tocarla.
Situaciones que exigen reevaluación:
- campo renombrado o formato modificado por el proveedor;
- nueva fuente de telemetría que cambia la cobertura;
- cambio del proceso operativo que crea un falso positivo nuevo;
- actualización del sistema que modifica el comportamiento observado;
- la técnica que cubría la regla cayó en desuso.
Una detección también debe poder retirarse. Las reglas mantenidas solo porque ya existen consumen triaje y crean la ilusión de cobertura.
Mide la salud del conjunto, además de la de cada regla:
| Métrica | Qué revela |
|---|---|
| Proporción de alertas que se convierten en investigación | Calidad de la señal |
| Alertas cerradas como falsos positivos | Candidatas a ajuste |
| Reglas que no se activaron en 90 días | Telemetría ausente o lógica rota |
| Tiempo desde el evento hasta la alerta | Retraso de ingesta |
| Cobertura por táctica de ATT&CK | Carencias estructurales |
La tercera fila merece atención. Una regla que nunca se activa puede significar que el comportamiento no ocurre o que la fuente de datos dejó de llegar hace dos meses y nadie lo advirtió. El silencio no es evidencia de seguridad: monitorear la llegada de telemetría es tan importante como monitorear su contenido.
Cuidado con lo que no dice la cobertura del mapa
Mapear las detecciones frente a las tácticas de ATT&CK es útil y se convirtió en una práctica común. También es la fuente más eficiente de falsa confianza en una operación de detección.
Tres trampas al leer un mapa de cobertura:
La técnica marcada como cubierta por una regla frágil. Si la regla utiliza un nombre de ejecutable, la columna queda verde y la evasión cuesta un mv. El mapa no distingue detección de comportamiento de coincidencia de cadenas.
La técnica con muchos procedimientos y una sola regla. Una técnica de ATT&CK puede ejecutarse de decenas de formas diferentes. Cubrir una colorea la celda completa y la celda coloreada es lo que ve la dirección.
La cobertura que existe donde hay telemetría fácil. Los equipos tienden a escribir reglas para las fuentes que ya recopilan. El mapa refleja entonces la distribución de la telemetría disponible, no la del riesgo real del entorno.
Una lectura más sincera anota tres cosas por técnica: la fuente de datos necesaria, si se recopila en todo el parque de equipos y en qué nivel opera la regla: valor específico, herramienta o comportamiento. El resultado tiene menos colores y es mucho más útil para decidir la próxima inversión.
Cuando la carencia es de telemetría, escribir más reglas no lo resuelve. Ninguna lógica compensa un evento que nunca se recopiló, y ese es el motivo más común de que una detección «lista» no se active en producción.
Registra la regla de forma que sobreviva a tu paso por el equipo
La documentación mínima de una detección cabe en una página y responde a lo que necesitará una persona de guardia o un sucesor:
| Campo | Contenido |
|---|---|
| Hipótesis | El comportamiento que pretende encontrar la regla |
| Técnica relacionada | Referencia a ATT&CK cuando corresponda |
| Fuentes de datos | Qué eventos y de qué sistemas |
| Cobertura | En qué parte del parque de equipos existe realmente la fuente |
| Casos positivos | Ejemplos autorizados que deben activarla |
| Falsos positivos conocidos | Qué se ha observado y cómo descartarlo |
| Excepciones activas | Cada una con motivo y fecha de revisión |
| Propietario y revisión | Quién responde y cuándo reevaluar |
El campo de excepciones es el que peor envejece. Las excepciones entran para resolver un ruido puntual, nadie las retira y al cabo de un año la regla tiene más exclusiones que lógica. Registrar el motivo y la fecha de revisión de cada una convierte una decisión temporal en algo que alguien volverá a evaluar de verdad.
Revisa después de publicar
Sigue el resultado en producción. Después de cada investigación, pregunta si la alerta aportó suficiente contexto para la primera decisión. Si no fue así, prefiere enriquecer el evento, aclarar la hipótesis o ajustar la documentación antes de ampliar las excepciones.
El objetivo no es maximizar el número de alertas. Es aumentar la probabilidad de reconocer una actividad relevante a tiempo para actuar. Una detección útil reduce la incertidumbre de quien está de guardia.
Siguiente paso
Elige una regla que ya esté en producción y responde a tres preguntas: cuántas alertas generó en el último mes, cuántas se convirtieron en una investigación real y cuándo se verificó por última vez su fuente de datos. Si alguna respuesta no está disponible, esa es la carencia que debes resolver antes de escribir la siguiente regla.
Valida detecciones únicamente en entornos propios, de laboratorio o con autorización explícita para la prueba.
