ibondarenko1/azure-sentinel-detection-engineering9 detecciones KQL mapeadas a MITRE ATT&CK en un entorno Microsoft Sentinel + Defender XDR en vivo (plano de control, endpoint, identidad), con un pipeline de Detection-as-Code con compuerta de PR (GitHub Actions, OIDC), playbooks SOAR y un mapeo de controles SOC 2.
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).
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.
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.
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]
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.
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]
