Ingenieria de deteccion en SIEM con reglas Sigma: una guia practica para blue teams

La ingenieria de deteccion es la disciplina de convertir el conocimiento sobre el comportamiento del adversario en alertas fiables y mantenibles que se disparan ante amenazas reales y permanecen en silencio ante todo lo demas. Sigma es el formato de reglas abierto y neutral respecto al proveedor que se ha convertido en la lingua franca de este trabajo: escribes una deteccion una vez en YAML y la conviertes al lenguaje de consulta del SIEM que ejecutes. Esta guia es un recorrido defensivo, orientado a la forense, de como construir detecciones con Sigma y tu SIEM: como funciona el formato, como obtener buenas ideas de deteccion, como ajustar para senal sobre ruido, como probar que una regla realmente se dispara y como operar todo como codigo para que tus detecciones queden versionadas, revisadas y reproducibles.

Que es la ingenieria de deteccion

Una plataforma SIEM (Gestion de Informacion y Eventos de Seguridad) agrega registros de todo tu entorno —endpoints, servidores, dispositivos de red, servicios en la nube, proveedores de identidad— y te permite consultarlos y correlacionarlos. La ingenieria de deteccion es lo que hace utiles esos datos: es el proceso deliberado de hipotetizar una tecnica del adversario, identificar la telemetria que la revelaria, codificar esa logica como una regla, validar la regla contra datos reales y simulados y mantenerla en el tiempo. Bien hecha, produce una biblioteca curada de detecciones de alta fidelidad mapeadas a un marco como MITRE ATT&CK. Mal hecha, produce una avalancha de alertas de bajo valor que los analistas aprenden a ignorar, lo cual es peor que no tener alerta.

Por que Sigma y como funciona el formato

Antes de Sigma, cada deteccion estaba atada a la sintaxis de consulta de un proveedor, asi que compartir detecciones entre equipos o migrar de SIEM significaba reescribir todo. Sigma resuelve esto describiendo detecciones en un formato YAML estructurado que un convertidor traduce a la consulta nativa de tu backend. Una regla Sigma tiene algunas secciones nucleo. logsource declara a que telemetria aplica la regla, por ejemplo eventos de creacion de procesos en Windows. El bloque detection contiene selecciones con nombre —conjuntos de condiciones campo-valor— y una condition que las combina con logica booleana, incluida la negacion para recortar actividad conocida como buena. Las reglas tambien llevan metadatos: un title, un id estable, un level (severidad), una description, tags que mapean a tecnicas de ATT&CK y falsepositives que documentan disparos benignos esperados. Como la logica es declarativa y portable, una regla Sigma bien escrita es a la vez deteccion y documentacion.

Obtener buenas ideas de deteccion

Las detecciones fuertes parten de entender el comportamiento del adversario, no de campos de registro al azar. Ancla tu trabajo a MITRE ATT&CK para que cada regla mapee a una tecnica con nombre y puedas ver tu cobertura como una matriz. Extrae ideas de informes de inteligencia de amenazas, repositorios publicos de detecciones, post-mortems de incidentes y ejercicios de red team o purple team. Prefiere detecciones basadas en comportamiento sobre indicadores fragiles: los hashes y las direcciones IP cambian con cada campana, pero la tecnica —por ejemplo un servicio creado para establecer persistencia, o una herramienta que genera un proceso hijo inesperado— es mucho mas duradera. Un modelo mental util es la piramide del dolor: las detecciones que fuerzan al adversario a cambiar sus herramientas y su oficio le cuestan mucho mas que las que puede evadir intercambiando un indicador.

Fuentes de deteccion y telemetria requerida

Una regla es tan buena como el registro que consulta, asi que la ingenieria de deteccion es inseparable de la estrategia de registro. En Windows, la telemetria rica de procesos (incluidos los argumentos de linea de comandos y las relaciones padre-hijo), el registro de bloques de script de PowerShell y los eventos de autenticacion son fundamentales; un agente de endpoint bien configurado o Sysmon mejora dramaticamente la visibilidad. En Linux, los registros de auditoria y la telemetria de endpoint cumplen el mismo papel. Las fuentes de nube e identidad —registros de auditoria del plano de control, registros de inicio de sesion y actividad de API— son esenciales para las detecciones modernas. La implicacion practica es que antes de escribir una regla debes confirmar que los campos requeridos se recopilan y normalizan de verdad; una deteccion hermosa sobre telemetria que no ingieres es una deteccion que nunca se dispara. Construye un inventario de fuentes de registro y trata sus vacios como deuda de deteccion.

Ajuste: senal sobre ruido

La parte mas dificil de la ingenieria de deteccion no es escribir una regla que atrape la amenaza, sino una que no ahogue a los analistas en falsos positivos. Cada regla debe ajustarse contra tu entorno real. Empieza amplio para confirmar que el comportamiento es detectable, luego anade exclusiones para fuentes legitimas —las cuentas de servicio, herramientas administrativas o tareas programadas especificas que generan el mismo patron de forma benigna— usando la negacion de Sigma en la condicion. Documenta cada exclusion en el campo falsepositives para que el siguiente ingeniero entienda por que existe. Fija el level con honestidad: reserva la severidad alta para detecciones que ameriten respuesta inmediata, y enruta las reglas mas ruidosas y de menor confianza a enriquecimiento o correlacion en lugar de a un buscapersonas. Rastrea el volumen de alertas y la tasa de verdaderos positivos de cada regla en el tiempo; una regla que solo dispara falsos positivos es candidata a ajuste o retiro, y una regla que nunca se dispara puede estar rota.

Probar que una deteccion realmente funciona

Una regla que nunca has visto dispararse es una esperanza, no una deteccion. Valida las reglas como validas el codigo. Usa muestras de registro grabadas o sinteticas que contengan el comportamiento objetivo y confirma que la regla las empareja, y usa muestras benignas para confirmar que no lo hace. Los marcos de emulacion de adversarios te permiten generar de forma segura la telemetria que produce una tecnica en un laboratorio controlado para que verifiques de extremo a extremo que el evento se registra, se ingiere y se alerta: esa es la esencia del purple teaming. De forma crucial, incluye una prueba negativa y una muestra deliberada de bueno-conocido: una deteccion que empareja todo es tan inutil como una que no empareja nada. Vuelve a ejecutar tu suite de pruebas siempre que cambien los formatos de registro, los mapeos de campos o la propia regla, porque una deriva silenciosa de esquema puede desactivar una deteccion sin ningun error.

Operaciones de deteccion como codigo

Trata las detecciones como software. Manten tus reglas Sigma en control de versiones para que cada cambio sea revisado, atribuido y reversible. Ejecuta un pipeline de CI que revise la sintaxis de las reglas, valide el esquema, compruebe que cada regla se convierte limpiamente al lenguaje de consulta de tu SIEM y ejecute la regla contra datos de prueba. Exige revision por pares antes de que una deteccion llegue a produccion, igual que con el codigo de aplicacion. Despliega mediante automatizacion en lugar de editar reglas a mano en la consola del SIEM, para que la produccion siempre coincida con el repositorio y no haya deriva no documentada. Rastrea la cobertura contra ATT&CK como metrica viva, registra el historial de ajuste de cada regla y programa revisiones periodicas para retirar reglas muertas y revisitar las ruidosas. Este enfoque de deteccion como codigo convierte una fragil pila de reglas de consola en una biblioteca de detecciones mantenible, auditable y portable.

Errores comunes

Los programas de deteccion tropiezan de formas predecibles. Escriben reglas contra telemetria que en realidad no recopilan, produciendo detecciones que nunca pueden dispararse. Persiguen indicadores fragiles —hashes e IPs especificos— y se preguntan por que la cobertura se evapora con cada nueva campana. Despliegan reglas sin ajustar, sepultan a los analistas en falsos positivos y luego desactivan el ruido en lugar de refinarlo. Nunca prueban, asi que un cambio de mapeo de campos ciega en silencio una deteccion critica. Optimizan por el numero de reglas en lugar del valor de las alertas, confundiendo un gran conteo de reglas con buena cobertura. Y dejan pudrir las reglas sin revision, acumulando detecciones muertas que crean falsa confianza. El antidoto a todo esto son reglas basadas en comportamiento, telemetria verificada, ajuste honesto, pruebas reales y disciplina de deteccion como codigo.

Lista de verificacion de ingenieria de deteccion

Usa esto como flujo de trabajo recurrente. Mapea cada deteccion a una tecnica de ATT&CK y rastrea la cobertura como matriz. Confirma que la telemetria requerida se recopila y normaliza antes de escribir la regla. Escribe Sigma portable con selecciones claras, severidad honesta, etiquetas ATT&CK y falsos positivos documentados. Ajusta contra tu entorno real y anade exclusiones con justificacion. Prueba cada regla con muestras positivas y negativas, y valida de extremo a extremo con emulacion de adversarios en un laboratorio. Almacena las reglas en control de versiones con revision por pares y validacion de CI. Despliega mediante automatizacion para que la produccion coincida con el repo. Monitorea el volumen y la tasa de verdaderos positivos de cada regla. Programa revisiones periodicas para retirar reglas muertas y refinar las ruidosas. Repite continuamente conforme cambian tu entorno y el panorama de amenazas.

FAQ: Sigma reemplaza las reglas nativas de mi SIEM?

No: Sigma es un formato de origen portable que compila a las consultas nativas de tu SIEM; no reemplaza la plataforma, hace tu logica de deteccion neutral respecto al proveedor y compartible. Autoras y gestionas detecciones como Sigma en control de versiones, y luego las conviertes al lenguaje de consulta que tu SIEM use para desplegar. El beneficio es que tu biblioteca de detecciones sobrevive a una migracion de SIEM, puede compartirse con la comunidad y consumirse de repositorios publicos, y se revisa y prueba como codigo en vez de armarse a clics en una consola. Algunas detecciones que necesitan correlacion especifica de la plataforma aun pueden autorarse de forma nativa, pero el nucleo portable pertenece a Sigma.

FAQ: Cuantas reglas de deteccion deberiamos tener?

La pregunta correcta no es cuantas reglas sino cuanta cobertura de alta fidelidad de las tecnicas relevantes para tu modelo de amenazas. Unos cientos de reglas bien ajustadas, probadas, mapeadas a ATT&CK y que generan alertas accionables valen mucho mas que miles ruidosas y sin probar que los analistas ignoran. Mide el exito por la cobertura de las tecnicas que los adversarios usan de verdad contra organizaciones como la tuya, por la tasa de verdaderos positivos y por el tiempo medio de deteccion, no por el conteo bruto de reglas. Poda con agresividad: una regla muerta o perpetuamente de falsos positivos es un pasivo, no un activo.

Conclusion

La ingenieria de deteccion con Sigma convierte el conocimiento del adversario en defensas duraderas, portables y comprobables. Al anclar las reglas a ATT&CK, confirmar que recopilas la telemetria que necesitan, ajustar con honestidad para senal sobre ruido, probar que cada deteccion realmente se dispara y operar toda la biblioteca como codigo, construyes una capacidad de deteccion que mejora en el tiempo en lugar de decaer en fatiga de alertas. El formato es abierto y las practicas estan bien establecidas; lo que separa un programa fuerte de uno debil es la disciplina: comportamiento sobre indicadores, telemetria verificada sobre suposiciones y pruebas continuas sobre esperanza. Construye detecciones que has visto dispararse, mantenlas en control de versiones, y tu SIEM se vuelve un instrumento que encuentra amenazas reales en vez de una manguera que tus analistas han aprendido a ignorar.