Ciberseguridad y seguridad de la información

Detection as Code: Gestión de reglas de detección en Git

6 min de lecturaPublicado: 5 de agosto de 2026
Ilustración visual profesional sobre Detection as Code en el ámbito de Threat Hunting y detección
Respuesta rápida

Detection as Code comienza con una pregunta o comportamiento que se desea detectar, continúa con la definición de telemetría y lógica, y finaliza con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.

Threat Hunting y Detection Engineering transforman el conocimiento del comportamiento del adversario en preguntas medibles, fuentes de datos y reglas de detección. El objetivo no es generar más alertas, sino mejorar la cobertura y la calidad de la decisión. Este artículo se centra en Detection as Code y está dirigido a equipos de Detección y SOC avanzados. El objetivo es proporcionar una metodología de trabajo que pueda aplicarse en la práctica, en una entrevista profesional y en un entorno de trabajo, sin limitarse a una definición de diccionario.

El desafío principal es que los datos son casi siempre incompletos. Un repositorio, pull request, lint pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la prueba en torno a una pregunta de investigación, la evidencia requerida y un criterio claro de finalización.

El escenario práctico en el artículo es: estructura de repositorio de ejemplo sin código malicioso. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, solo se debe trabajar con autorización explícita, un alcance definido y la capacidad de detener la prueba.

¿Por qué gestionar las Detecciones como Código?

El tema 'Por qué gestionar las Detecciones como Código' es una parte central del trabajo en Detection as Code. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender su propósito.

En la práctica, registre el repositorio, pull request, lint, tests, release, compárelo con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos a seguir.

Repository structure

El tema 'Repository structure' es una parte central del trabajo en Detection as Code. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender su propósito.

En la práctica, registre el repositorio, pull request, lint, tests, release, compárelo con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos a seguir.

Review y Approval

El tema 'Review y Approval' es una parte central del trabajo en Detection as Code. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender su propósito.

En la práctica, registre el repositorio, pull request, lint, tests, release, compárelo con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos a seguir.

Testing y CI

Una prueba profesional para Detection as Code comienza con condiciones de éxito y condiciones de falla. Se definen un caso positivo, un caso negativo, un caso límite y una actividad legítima similar. Así se pueden identificar tanto falsos negativos como falsos positivos.

En un entorno autorizado, se utiliza una acción mínima que demuestre la afirmación sin causar daño. Se guardan Input, Output, tiempo y versión, y después de la corrección se realiza un Retest en el mismo escenario y también se verifica la regresión en funciones adyacentes.

Deployment y Rollback

El tema 'Deployment y Rollback' es una parte central del trabajo en Detection as Code. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender su propósito.

En la práctica, registre el repositorio, pull request, lint, tests, release, compárelo con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos a seguir.

Puntos de prueba únicos

En este tema se recomienda construir previamente un mapa de evidencias enfocado. Los puntos de prueba centrales son: repository, pull request, lint, tests, release, rollback. La lista no es un Checklist automático; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo o explicar un comportamiento legítimo.

  • repository: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
  • pull request: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
  • lint: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
  • tests: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
  • release: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
  • rollback: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si un Process identifier no es estable, se puede usar tiempo, Host, User y Parent; si la carga útil está cifrada, se usan Metadatos, volumen, frecuencia y contexto TLS/DNS.

Proceso de trabajo recomendado

  1. Defina el Alcance y una pregunta de trabajo sobre Detection as Code.
  2. Anote las fuentes de datos y las evidencias necesarias: repository, pull request, lint, tests.
  3. Cree una línea base corta de comportamiento normal o resultado esperado.
  4. Realice la prueba mínima en un entorno de laboratorio y guarde tiempo, entrada y salida.
  5. Construya una línea de tiempo o tabla de comparación y separe los hechos de la interpretación.
  6. Realice un Pivot a una fuente adicional para confirmar o refutar la explicación inicial.
  7. Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es una estructura de Repositorio de ejemplo sin código malicioso. El propósito del ejercicio no es demostrar una capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, un período de tiempo y un resultado esperado.

Al final del ejercicio, se debe entregar un producto que otro analista o evaluador pueda revisar: una captura de pantalla o exportación de la evidencia, una línea de tiempo corta, una suposición inicial, evidencia de verificación, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

EtapaQué se realizaProducto
PreparaciónDefina el alcance, el tiempo y el objetivo. Anote qué campos o evidencias de repository, pull request, lint se espera que aparezcan.Plan de prueba breve
Creación de datosRealice una acción segura y simulada relacionada con Detection as Code, sin información real ni impacto en el sistema de producción.Evento/Solicitud/Flujo controlado
RecopilaciónRecopile la evidencia bruta y el contexto de una fuente adicional. Verifique la zona horaria, los identificadores y la integridad.Dos evidencias vinculadas
AnálisisEscriba lo que cada evidencia demuestra, lo que no demuestra y cuál es la posible explicación legítima.Conclusión provisional
FinalizaciónElija un cierre, escalada, hallazgo o ajuste; añada una recomendación y Retest.Producto documentado

Checklist práctico

  • Comprobar y documentar: Hypothesis.
  • Comprobar y documentar: técnica ATT&CK.
  • Comprobar y documentar: Data sources.
  • Comprobar y documentar: Detection logic.
  • Comprobar y documentar: Expected benign behavior.
  • Comprobar y documentar: Test cases y coverage.
  • Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
  • Guarde el dato bruto antes de filtrar o modificar.
  • Escriba lo que el hallazgo demuestra y lo que aún se desconoce.
  • Defina al propietario y la acción de seguimiento con fecha.

Errores comunes

  • Comenzar con un IOC aleatorio sin Hypothesis.
  • Mapear ATT&CK solo por nombre.
  • Escribir una Rule sin Test cases.
  • Ignorar el comportamiento legítimo.
  • Medir Rules en lugar de Coverage.
  • No gestionar versiones.

Resumen y CTA

Detection as Code: la gestión de reglas de detección en Git es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo evidencia relevante, mantenga el contexto y el tiempo, y elija una acción que pueda justificarse y volverse a probar.

En el programa Cybersecurity & AI de HPI, estos principios se practican utilizando sistemas, registros y laboratorios. Un paso natural es pasar a los artículos vinculados, completar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes

¿Detection as Code por sí solo prueba un ataque o una vulnerabilidad?

No. Proporciona una señal o un hallazgo que necesita contexto, verificación y una fuente adicional. Una conclusión profesional se basa en una secuencia de evidencias y en la conformidad con el comportamiento esperado.

¿Qué se hace cuando faltan algunos datos?

Se documenta lo que falta, se verifica una fuente alternativa y se reduce el nivel de confianza. No se deben completar campos por suposición ni presentar 'Unknown' como correcto.

¿Cuánto tiempo se deben guardar las evidencias?

El tiempo depende de la política, la regulación, el coste y el tipo de incidente. Es importante definir de antemano el Retention, Legal hold y la capacidad de exportar evidencia en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Se utilizan máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En las pruebas autorizadas, se definen Scope, Stop conditions y una copia de seguridad antes de comenzar el trabajo.

¿Quieres comprobar si este itinerario es para ti?

Deja tus datos y un asesor de HPI te llamará para una breve charla de orientación, sin compromiso.

Tus datos se guardan de forma segura.

Para estudios de SOC y ciberseguridad dentro del programa Cybersecurity & AI

¿Quieres los detalles del programa? Déjanos tus datos y te contactaremos.

Artículos relacionados