Principios de Detection-as-Code

Detection-as-Code (DaC) aplica la disciplina de la ingeniería de software a las detecciones de seguridad. En lugar de que los analistas editen manualmente las reglas dentro de la consola de un SIEM, las detecciones se almacenan como archivos de texto en un sistema de control de versiones y se entregan mediante un pipeline.

Los beneficios son concretos:

• Cambios revisables mediante pull requests
• Despliegues reproducibles entre entornos
• Lógica verificable antes de llegar a producción
• Historial auditable de quién cambió qué y por qué

Una detección se convierte en un artefacto que puede comparar, revertir y analizar como cualquier otro código.

Cada detección se almacena como un archivo independiente, normalmente en YAML o en el lenguaje de consulta del proveedor, y se confirma en un repositorio de Git. La estructura del repositorio refleja cómo organiza su cobertura.

Una estructura habitual separa las reglas por plataforma y táctica:

Cada detección nueva o modificada pasa por una pull request. Un segundo ingeniero revisa la lógica, el riesgo de falsos positivos y la asignación de ATT&CK antes de fusionarla.

Los revisores preguntan:

• ¿La lógica coincide con la amenaza descrita?
• ¿Qué actividad legítima podría activarla?
• ¿Son correctas la gravedad y la referencia de ATT&CK?
• ¿Hay pruebas que cubran los positivos verdaderos y los falsos positivos?

Esto detecta errores que un analista trabajando solo en el SIEM a las 2 de la madrugada pasaría por alto.

Un pipeline de integración continua se ejecuta automáticamente en cada push. Impone controles de calidad antes de que una regla pueda fusionarse.

Etapas habituales de CI para un repositorio basado en Sigma:

Una vez fusionadas las reglas, un trabajo de despliegue convierte las reglas portables al lenguaje de consulta de destino y las envía al SIEM o EDR mediante la API.

Para Sigma, normalmente se ejecuta un convertidor como sigma convert con un backend que coincida con su plataforma (Splunk, Elastic, Microsoft Sentinel). Después, el pipeline carga las búsquedas guardadas o las reglas analíticas generadas.

Ninguna persona pega consultas en una consola. El estado desplegado siempre coincide con lo que hay en main.

Una detección sin pruebas es una suposición. DaC empareja cada regla con datos de prueba: muestras de registros que deberían activarla (positivos verdaderos) y muestras benignas que no deberían activarla (falsos positivos).

Las pruebas se ejecutan en CI, por lo que un cambio que rompa la cobertura o vuelva a introducir ruido hace fallar la compilación antes de la fusión. Esta es la mayor fuente de confianza al refactorizar reglas a gran escala.

Trate los metadatos como un elemento fundamental. Cada detección registra su estado a medida que avanza por el ciclo de vida:

• experimental — recién escrita, se supervisa de cerca
• test — en ejecución, pero todavía no es de confianza para generar alertas
• stable — probada, con una tasa baja de falsos positivos
• deprecated — sustituida o retirada

Registrar el estado en el archivo permite promover, degradar y retirar reglas de forma deliberada, en lugar de dejar que la lógica obsoleta permanezca en producción.

Una de las principales ventajas de DaC es escribir la lógica de detección una sola vez en un formato independiente del proveedor y después compilarla para varios backends. Sigma es el estándar de facto para las detecciones basadas en registros.

El mismo archivo de reglas puede dirigirse a Splunk SPL, Elastic Lucene/EQL, Microsoft Sentinel KQL y otros sistemas mediante asignaciones de campos específicas del pipeline. Evita reescribir la misma idea cinco veces y evita la dependencia de un proveedor.

Distintas fuentes de registros pueden asignar nombres diferentes a los mismos datos. Un evento de creación de procesos de Sysmon utiliza Image; un registro de seguridad de Windows puede utilizar NewProcessName. Los pipelines de procesamiento conectan ambas representaciones.

Los pipelines transforman los nombres de campo genéricos de Sigma en los campos exactos que utilizan sus datos, de modo que una regla lógica se asigne correctamente a cualquier esquema que ingiera su SIEM. Mantener los pipelines de forma centralizada significa que un cambio de esquema se corrige una sola vez, no en cada regla.

Al igual que el código de una aplicación, las detecciones pasan por varios entornos antes de llegar a producción. Un flujo habitual es de desarrollo a staging y después a producción.

• Desarrollo — crear las reglas y ejecutar pruebas unitarias en CI
• Staging — desplegarlas con una copia de la telemetría real en modo de auditoría
• Producción — promoverlas cuando la tasa de falsos positivos sea aceptable

La promoción es un paso deliberado y revisado, vinculado al estado del ciclo de vida de la regla, no un accidente producido por una fusión. Este despliegue gradual refleja la disciplina de alertar y después bloquear que se utiliza con las detecciones en línea.

Como las detecciones son código, puede medir la cobertura mediante programación. Asocie cada regla con técnicas de MITRE ATT&CK y genere un mapa de calor de lo que cubre y lo que no cubre.

Métricas útiles que conviene seguir a lo largo del tiempo:

• Técnicas cubiertas frente al total de técnicas del modelo de amenazas
• Tasa de falsos positivos por regla
• Tiempo medio desde la idea de una regla hasta su puesta en producción
• Número de reglas en cada estado del ciclo de vida

Estas cifras convierten la ingeniería de detección, que antes se basaba en anécdotas, en un programa gestionado.

Compruebe su comprensión de los fundamentos de Detection-as-Code.

Detection-as-Code aporta rigor de ingeniería de software a las detecciones:

• Las reglas se almacenan como archivos versionados en Git
• Los cambios pasan por la revisión mediante pull requests
• CI ejecuta linters, valida y ejecuta pruebas automáticamente
• Las reglas fusionadas se despliegan mediante un pipeline, manteniendo prod sincronizado con main
• Las pruebas protegen contra falsos positivos y regresiones
• La portabilidad (Sigma + pipelines) permite dirigir una regla a muchos backends
• Los metadatos, el ciclo de vida y las métricas convierten la detección en un programa gestionado

A continuación, escribirá las propias reglas portátiles con Sigma.