Ingeniería de detección en Azure Sentinel

Ingeniería de detección en un entorno Microsoft Sentinel y Defender XDR en producción que opero. Nueve reglas de análisis personalizadas se reparten entre tres planos, cada una mapeada a MITRE ATT&CK y probada de extremo a extremo: una acción controlada dispara la regla, la regla eleva un incidente, y el incidente se investiga y se documenta. Siete vigilan el plano de control de Azure (AzureActivity), incluida una correlación de múltiples etapas y una regla de contenido basada en ARG; una vigila el endpoint (Defender for Endpoint), con Defender Vulnerability Management alimentando una biblioteca de hunting; una vigila la identidad (registros SigninLogs de Entra ID). Todas se despliegan mediante el mismo pipeline controlado por PR.

Un entorno de un solo inquilino en producción que opero de extremo a extremo. Los identificadores de inquilino y suscripción y cualquier PII están redactados en todas las capturas de pantalla.

Las cifras son trazables: la cobertura, a la capa ATT&CK; la validación, a RESULTS.md. Deliberadamente no hay insignia de tasa de falsos positivos: un entorno de un solo inquilino no puede producir una tasa de FP significativa, así que el repositorio informa de falsos disparos medidos sobre un lote benigno real en lugar de un porcentaje inventado (metrics.yaml lo indica en su totalidad).

Inicio rápido

Ejecuta las pruebas unitarias de detección en un fork, sin necesidad de Azure. El KQL real de cada regla se ejecuta contra fixtures sintéticos en un emulador local de Kusto, de modo que la lógica de detección es verificable sin mi inquilino:

git clone https://github.com/ibondarenko1/azure-sentinel-detection-engineering
cd azure-sentinel-detection-engineering
docker run -d --rm -p 8080:8080 -e ACCEPT_EULA=Y mcr.microsoft.com/azuredataexplorer/kustainer-linux:latest
pip install pyyaml
python tests/run-detection-tests.py

Esta es exactamente la comprobación que CI ejecuta en cada pull request (detection-tests): verifica que cada regla se dispara con los fixtures maliciosos y permanece silenciosa con los benignos. El harness en vivo en validation/ va más allá, ejecutando un lote benigno y otro de ataque reales en un inquilino y midiendo los verdaderos positivos y los falsos disparos, pero ese requiere tu propia suscripción de Azure y az login (consulta validation/README), así que no es "local". Pipeline de despliegue: docs/03. Para contribuir una regla: CONTRIBUTING.

Por qué existe esto

Una detección solo es creíble cuando puedes demostrar que se dispara. Este repositorio cierra ese ciclo en tres planos, el plano de control de Azure, el endpoint y la identidad: lógica de la regla, activación controlada, incidente generado, investigación y mapeo MITRE. Va más allá de las reglas de evento único con una correlación de múltiples etapas (concesión y luego despliegue) y una regla basada en contenido que une la postura de Azure Resource Graph con el evento de cambio. Son reglas de análisis de Sentinel, KQL y respuesta a incidentes contra telemetría real, no contra muestras sintéticas.

Detección como código

Las reglas no se crean con clics en el portal. Son YAML versionado desplegado por un pipeline controlado por PR. Editar una detección significa abrir un pull request; CI la valida, un revisor la aprueba y el merge a main la despliega en Sentinel mediante OIDC (sin secretos almacenados), de forma idempotente por GUID de regla (API 2025-09-01).

flowchart LR
  D[Edit rule YAML] --> PR[Pull request] --> V[CI validate] -->|review| M[Merge main] --> CD[OIDC deploy] --> S[Sentinel sc200-ws]

• Fuente de la verdad: detections/rules/*.yaml · Pipeline: .github/workflows/deploy-detections.yml · Desplegador/validador: cicd/ · Detalles: docs/03-cicd.md

Un cambio real pasó por él: PR #1 ajustó el umbral de DET-001 (de 10 a 8); CI lo validó y el merge lo desplegó a la regla en vivo sc200-ws. Ese paso —reglas que se despliegan automáticamente desde git mediante un PR revisado— es lo que separa a un ingeniero de detección de un analista que terminó un curso.

Arquitectura

flowchart LR
  subgraph Sources
    A[Microsoft Defender XDR<br/>Email · Endpoint]
    B[Azure subscription<br/>Activity Log]
    C[Entra ID<br/>sign-ins]
  end
  A --> W[Log Analytics workspace<br/>sc200-ws]
  B --> W
  C --> W
  W --> R[9 scheduled<br/>analytics rules]
  R --> I[Incidents]
  I --> V[Investigation<br/>+ MITRE mapping]

Catálogo de detecciones

Resultados

Cada detección se activó con una acción administrativa controlada y autorrevertida, y produjo un incidente real:

Estado operativo actual del área de trabajo: 10 reglas de análisis habilitadas, 4 conectores de datos activos, una regla de automatización y datos en vivo fluyendo. Las 10 reglas habilitadas son las nueve reglas programadas personalizadas [DET] de este catálogo más la regla Fusion integrada de Microsoft (Advanced Multistage Attack Detection), que está activada por defecto y no está creada aquí; la cifra de nueve que se menciona en otras partes de este README cuenta solo las reglas personalizadas.

Cinco incidentes están redactados como investigaciones completas:

• INV-01, Eliminación masiva de recursos (Alta)
• INV-02, Escalada de privilegios RBAC
• INV-03, Acceso a credenciales LSASS (Alta), endpoint, Incidente #65
• INV-04, NSG abierto al tráfico entrante desde Any (Alta), correlación de contenido ARG (DET-009)
• INV-05, Concesión de privilegios y luego despliegue (Alta), correlación de múltiples etapas (DET-007)

Más allá de las activaciones puntuales, un harness de validación ejecuta un lote real benigno + ataque en el inquilino y corre el KQL de cada regla contra él, de modo que los falsos positivos se miden, no se asumen. Última ejecución (resultados): 5/5 escenarios de ataque se dispararon (DET-002/003/004/007/009) y 0 falsos disparos en el flujo benigno (despliegue de propietario en lista de permitidos, eliminaciones por debajo del umbral, despliegue sin concesión). No simula el volumen de producción; convierte un "0 % de FP con N=1" en un "0 falsos disparos sobre un lote benigno real" medido.

Cobertura ATT&CK

Un mapa de cobertura con brechas explícitas es más honesto que una lista de reglas. La capa del ATT&CK Navigator (cómo cargarla) muestra ambas:

Las brechas no son texto estático. Cada una es un issue detection-gap en vivo, de modo que la hoja de ruta es un backlog en el que se puede hacer clic.

Por qué estas reglas y no otras: docs/08, estrategia de detección y modelo de amenazas mapea el catálogo a una cloud kill chain y clasifica por riesgo las brechas. Cómo se ajusta una regla: docs/09, un ciclo de ajuste medido de DET-005 lleva una regla de "se dispara ante cualquier escritura" a unos falsos positivos medidos de cero en el harness de validación.

Respuesta automatizada (SOAR)

La detección de mayor gravedad cierra el ciclo de detectar a responder. Una regla de automatización de Sentinel ejecuta un playbook de Logic App en cada incidente DET-004 (eliminación masiva): publica un comentario de enriquecimiento con la contención recomendada (deshabilitar la cuenta que realizó la llamada, bloquear los grupos de recursos, restaurar, hacer hunting). El playbook se autentica con su propia identidad administrada directamente contra la API de ARM, sin secretos y sin conector externo.

Un segundo playbook amplía el ciclo a detectar → responder → investigar con IA mediante Microsoft Security Copilot: un promptbook + Logic App invoca un promptbook de Copilot sobre el mismo incidente DET-004 y publica, como comentario, un resumen de investigación de IA. Se compila y se despliega sin unidades de cómputo; la captura en vivo del resumen de IA se ejecuta en una única ventana de pago de coste acotado (~$4) y no se declara lograda hasta que se captura. Runbook de costes y desmontaje: docs/06.

Gestión de endpoints y vulnerabilidades

Las detecciones empiezan en el plano de control de Azure; esta fase añade el plano del endpoint. Un sensor de Defender for Endpoint en un host Windows alimenta la misma área de trabajo, de modo que el pipeline de detección como código despliega una regla de endpoint, DET-006 Acceso a credenciales LSASS, junto a las reglas del plano de control. DET-006 tiene múltiples fuentes y está probada: se ejecutaron tres técnicas de volcado de credenciales contra el sensor, el host endurecido (LSASS RunAsPPL, AMSI, protección de comportamiento) las bloqueó todas, y la regla se disparó con las alertas de Defender resultantes para elevar un incidente (INV-03). Defender Vulnerability Management añade una segunda entrada: una biblioteca de hunting que saca a la luz CVEs críticas por software expuesto, líneas base de configuración segura no cumplidas y activos vulnerables bajo alerta activa. Las tablas DeviceTvm* solo existen en la búsqueda avanzada de Defender, así que esas correlaciones son hunts, no reglas desplegadas, y el repositorio indica dónde se ejecuta realmente cada consulta. Arquitectura y flujo de datos: docs/07.

Remediación de la postura

Las detecciones vigilan los ataques; esta fase lee la puntuación de postura del propio inquilino y corrige lo que señala, y luego demuestra que el número se ha movido. La línea base de Secure Score de Defender for Cloud se obtiene como una instantánea legible por máquina mediante collect-posture.ps1, de modo que el antes/después es un diff de archivos, no una comparación de capturas. En la línea base la puntuación es 68.81 % (21.33 / 31), y el desglose por control sitúa la brecha completa de 9.67 puntos en cuatro controles (cifrado en reposo, acceso y permisos, acceso a la red, auditoría). La remediación se ordena por radio de explosión, primero las correcciones aditivas, y cada elemento se mapea a la regla del catálogo que detecta su regresión (exposición de almacenamiento a DET-002 / DET-009, proliferación de RBAC a DET-003 / DET-007, pérdida de registros al catálogo completo). En esta pasada se aplicaron tres correcciones, verificadas a nivel de recurso: el contacto de seguridad y las notificaciones de alertas, el registro de diagnóstico en ambos playbooks SOAR (+1 auditoría) y el cifrado en el host en la VM del sensor (+4 cifrado en reposo). Defender for Cloud reevalúa y recalcula la puntuación en las siguientes 24 a 72 horas, por lo que la puntuación posterior se documenta como seguimiento en lugar de afirmarse ahora. Método completo, plan ordenado y tabla de vinculación con las detecciones: docs/10, remediación de la postura.

Mapeo de controles SOC 2

Este trabajo respalda un marco de control reconocido, así que el repositorio indica dónde. Cada parte del catálogo se mapea a un Trust Services Criterion de SOC 2: el catálogo de nueve reglas y los incidentes, a la serie de supervisar y responder (CC7.2 a CC7.4); los playbooks SOAR, a la respuesta a incidentes (CC7.4); el pipeline de detección como código controlado por PR, a la gestión de cambios (CC8.1); y el harness de validación y el antes/después de la postura, a la eficacia operativa del control (CC4.1). Se plantea como un mapeo, no como una declaración de cumplimiento: este es un inquilino que yo opero, no una organización auditada, así que el documento mapea las actividades técnicas de control y es explícito sobre el envoltorio de gobernanza que un informe SOC 2 real necesita y que un repositorio de detecciones no aporta. Tabla completa criterio por criterio y la nota de cómo se leería en una auditoría: docs/11, mapeo de controles SOC 2.

Estructura del repositorio

detections/rules  rule source-of-truth (Sentinel YAML, deployed by CI)
detections/*.md   one card per rule: logic, MITRE, trigger, evidence
detections/metrics.yaml  per-detection metrics (volume, FP rate, TP, MTTD)
tests/            synthetic-log unit tests (Kusto emulator, fork-runnable)
validation/       live mixed-activity harness: benign + attack streams, measured TP/FP
cicd/ + .github   Detection-as-Code pipeline (deploy, validate, regression)
sigma/            vendor-neutral Sigma conversions (portable to any SIEM)
kql/              analytics-rule queries + hunting library
investigations/   end-to-end incident write-ups
simulations/      exact atomic-aligned trigger steps
navigator/        ATT&CK coverage layer (covered + gaps)
posture/          Secure Score baseline collector + JSON snapshots + remediation script
playbooks/        SOAR response (Logic App + automation rule)
docs/             architecture, methodology, cicd, validation, data-dictionary, endpoint+TVM, detection-strategy, tuning case study, posture remediation, SOC 2 control mapping
screenshots/      visual evidence

Habilidades demostradas

KQL · reglas de análisis programadas de Microsoft Sentinel · reglas de correlación de múltiples etapas · detección de identidad de Entra ID (SigninLogs) · watchlists de listas de permitidos (_GetWatchlist) · postura-como-contenido de Azure Resource Graph (scheduled Action) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · búsqueda avanzada (tablas Device / DeviceTvm) · Microsoft Secure Score · remediación de postura de Defender for Cloud (CSPM, MCSB) · mapeo de controles SOC 2 Common Criteria · detección como código (GitHub Actions, OIDC) · SOAR (reglas de automatización de Logic Apps) · Sigma (independiente de proveedor) · validación con Atomic Red Team · triaje e investigación de incidentes · mapeo MITRE ATT&CK · monitorización del plano de control de Azure (Activity Log).

Contribuciones

Este es un portafolio personal, pero está estructurado para que un cambio de detección sea un pull request revisable, no un clic en el portal. Si haces un fork o quieres proponer una regla, CONTRIBUTING.md cubre el flujo de trabajo: editar el YAML de la regla, regenerar el espejo KQL, ampliar el fixture de pruebas, ejecutar las pruebas unitarias en local y abrir un PR que verifican los mismos controles de CI.

Credenciales

Microsoft Certified: Security Operations Analyst Associate (SC-200).

Aviso legal

Un entorno que yo opero, no un inquilino de producción de ningún empleador ni de terceros. Las detecciones se validan con acciones administrativas controladas y autorrevertidas contra mis propios recursos; no intervienen sistemas de producción ni terceros. Los identificadores de inquilino y suscripción y la PII están redactados en todas las capturas de pantalla.

Licencia

MIT