Ingegneria delle Rilevazioni di Azure Sentinel

Ingegneria delle rilevazioni su un ambiente live Microsoft Sentinel e Defender XDR che gestisco. Nove regole di analisi personalizzate coprono tre piani, ciascuna mappata a MITRE ATT&CK e verificata end-to-end: un'azione controllata attiva la regola, la regola genera un incidente, e l'incidente viene analizzato e documentato. Sette monitorano il piano di controllo di Azure (AzureActivity), inclusa una correlazione multi-stadio e una regola con contenuti basata su ARG; una monitora l'endpoint (Defender for Endpoint), con Defender Vulnerability Management che alimenta una libreria di caccia; una monitora l'identità (Entra ID SigninLogs). Tutte distribuite tramite la stessa pipeline con gated PR.

Un ambiente live single-tenant che gestisco end-to-end. Identificatori di tenant e sottoscrizione e qualsiasi dato personale sono oscurati in tutti gli screenshot.

I dati sono tracciabili: copertura al layer ATT&CK, validazione a RESULTS.md. Non c'è deliberatamente nessun badge di tasso di falsi positivi: un ambiente single-tenant non può produrre un tasso FP significativo, quindi il repository segnala falsi allarmi misurati su un batch reale benigno invece di una percentuale inventata (metrics.yaml lo afferma per intero).

---

Avvio rapido

Esegui i test unitari delle rilevazioni su un fork, senza bisogno di Azure. Ogni regola esegue il suo KQL reale contro fixture sintetiche in un emulatore Kusto locale, quindi la logica di rilevazione è verificabile senza il mio tenant:

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

Questo è esattamente il controllo che la CI esegue su ogni pull request (detection-tests): asserisce che ogni regola si attivi su fixture dannose e rimanga silenziosa su quelle benigne. Il test harness live in validation/ va oltre, eseguendo un batch reale benigno e di attacco in un tenant e misurando veri positivi e falsi allarmi, ma richiede una propria sottoscrizione Azure e az login (vedi validation/README), quindi non è "locale". Pipeline di distribuzione: docs/03. Contribuire con una regola: CONTRIBUTING.

Perché esiste

Una rilevazione è credibile solo quando puoi dimostrare che si attiva. Questo repository chiude quel ciclo su tre piani: il piano di controllo Azure, l'endpoint e l'identità: logica della regola, trigger controllato, incidente generato, analisi e mappatura MITRE. Va oltre le regole a evento singolo con una correlazione multi-stadio (grant poi deploy) e una regola sensibile al contenuto che unisce la postura di Azure Resource Graph all'evento di modifica. Sono regole di analisi di Sentinel, KQL e risposta agli incidenti su telemetria reale, non su campioni sintetici.

Detection-as-Code

Le regole non vengono create tramite click nel portale. Sono YAML versionato distribuito da una pipeline con gated PR. Modificare una rilevazione significa aprire una pull request; la CI la valida, un revisore la approva e il merge su main la distribuisce a Sentinel tramite OIDC (nessun segreto memorizzato), idempotentemente per GUID della regola (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]

• Fonte di verità: detections/rules/*.yaml · Pipeline: .github/workflows/deploy-detections.yml · Deployer/validatore: cicd/ · Dettagli: docs/03-cicd.md

Una modifica reale è passata attraverso: PR #1 ha stretto la soglia DET-001 (da 10 a 8); la CI l'ha validata e il merge l'ha distribuita alla regola live sc200-ws. Questo passaggio, regole che si distribuiscono automaticamente da git tramite PR revisionata, è ciò che distingue un ingegnere delle rilevazioni da un analista che ha completato un corso.

Architettura

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]

Catalogo delle rilevazioni