azure-sentinel-detection-engineering

9 rilevamenti KQL mappati su MITRE ATT&CK su un ambiente live Microsoft Sentinel + Defender XDR (control-plane, endpoint, identity), con una pipeline Detection-as-Code con gate PR (GitHub Actions, OIDC), playbook SOAR e una mappatura dei controlli SOC 2.

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:

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).

• 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

Catalogo delle rilevazioni

Risultati

Ogni rilevazione è stata attivata con un'azione amministrativa controllata e auto-revocata e ha prodotto un incidente reale:

Stato operativo corrente dell'area di lavoro: 10 regole di analisi abilitate, 4 connettori dati attivi, una regola di automazione e dati live in flusso. Le 10 regole abilitate sono le nove regole pianificate personalizzate [DET] in questo catalogo più la regola Fusion integrata di Microsoft (Rilevamento avanzato di attacchi multistadio), che è attiva per impostazione predefinita e non è creata qui; il numero nove altrove in questo README conta solo le regole personalizzate.

Cinque incidenti sono documentati come indagini complete:

• INV-01, Eliminazione massiva di risorse (Alta)
• INV-02, Escalation dei privilegi RBAC
• INV-03, Accesso alle credenziali LSASS (Alta), endpoint, Incidente #65
• INV-04, NSG ha esposto traffico in entrata da Any (Alta), correlazione contenuto ARG (DET-009)
• INV-05, Concessione di privilegi seguita da distribuzione (Alta), correlazione multi-stadio (DET-007)

Oltre ai trigger singoli, un validation harness esegue un batch reale benigno + attacco nel tenant e applica il KQL di ogni regola, quindi i falsi positivi sono misurati, non presunti. Ultima esecuzione (risultati): 5/5 scenari di attacco attivati (DET-002/003/004/007/009) e 0 falsi allarmi sul flusso benigno (deploy del proprietario nella whitelist, cancellazioni sotto soglia, deploy senza grant). Non falsifica il volume di produzione; converte "0% FP a N=1" in un misurato "0 falsi allarmi su un batch reale benigno".

Copertura ATT&CK

Una mappa di copertura con lacune esplicite è più onesta di un elenco di regole. Il layer ATT&CK Navigator (come caricarlo) mostra entrambi:

Le lacune non sono testo statico. Ognuna è una detection-gap issue live, quindi la roadmap è un backlog cliccabile.

Perché queste regole e non altre: docs/08, strategia di rilevazione e modello di minaccia mappa il catalogo a una kill chain cloud e classifica le lacune per rischio. Come una regola viene sintonizzata: docs/09, un ciclo di sintonizzazione misurato per DET-005 porta una regola da "si attiva su ogni scrittura" a zero falsi positivi misurati sul validation harness.

Risposta automatizzata (SOAR)

La rilevazione a gravità più alta chiude il ciclo dalla rilevazione alla risposta. Una regola di automazione di Sentinel esegue un playbook di App per la logica su ogni incidente DET-004 (eliminazione massiva): pubblica un commento di arricchimento con il contenimento consigliato (disabilitare il chiamante, bloccare i gruppi di risorse, ripristinare, cacciare). Il playbook si autentica con la propria identità gestita direttamente all'API ARM, senza segreti e senza connettore esterno.

Un secondo playbook estende il ciclo in rileva → rispondi → indaga con AI con Microsoft Security Copilot: un promptbook + App per la logica invoca un promptbook di Copilot sullo stesso incidente DET-004 e pubblica un riepilogo dell'indagine AI come commento. Viene creato e distribuito senza unità di calcolo; la cattura live del riepilogo AI viene eseguita in una singola finestra a pagamento con costo limitato (~$4) e non viene rivendicata fino alla cattura. Costo e runbook di smantellamento: docs/06.

Gestione degli endpoint e delle vulnerabilità

Le rilevazioni iniziano sul piano di controllo di Azure; questa fase aggiunge il piano endpoint. Un sensore di Defender for Endpoint su un host Windows alimenta la stessa area di lavoro, quindi la pipeline Detection-as-Code distribuisce una regola endpoint, DET-006 Accesso alle credenziali LSASS, accanto alle regole del piano di controllo. DET-006 è multi-fonte e testimoniato: tre tecniche di dump delle credenziali sono state eseguite contro il sensore, l'host indurito (LSASS RunAsPPL, AMSI, protezione comportamentale) ha prevenuto ognuna, e la regola si è attivata sugli avvisi Defender risultanti per generare un incidente (INV-03). Defender Vulnerability Management aggiunge un secondo input: una libreria di caccia che evidenzia CVE critici per software esposto, baseline di configurazione sicura fallite e asset vulnerabili sotto avviso attivo. Le tabelle DeviceTvm* vivono solo nella caccia avanzata di Defender, quindi quelle correlazioni sono cacce, non regole distribuite, e il repository dice dove ogni query viene effettivamente eseguita. Architettura e flusso di dati: docs/07.

Rimediazione della postura

Le rilevazioni monitorano gli attacchi; questa fase legge il punteggio di postura del tenant e corregge ciò che segnala, poi dimostra che il numero è cambiato. Il Secure Score di Defender for Cloud viene estratto come snapshot leggibile da macchina da collect-posture.ps1, quindi il prima/dopo è un diff di file, non un confronto di screenshot. Al baseline il punteggio è 68.81% (21.33 / 31), e la suddivisione per controllo colloca l'intero divario di 9.67 punti in quattro controlli (crittografia a riposo, accesso e permessi, accesso alla rete, auditing). La rimediazione è ordinata per raggio d'esplosione, correzioni additive prima, e ogni elemento è mappato alla regola del catalogo che ne coglie la regressione (esposizione dello storage a DET-002 / DET-009, proliferazione RBAC a DET-003 / DET-007, logging perso all'intero catalogo). Tre correzioni sono state applicate in questo passaggio e verificate a livello di risorsa: il contatto di sicurezza e le notifiche di avviso, la registrazione diagnostica su entrambi i playbook SOAR (+1 auditing) e la crittografia sull'host sulla VM sensore (+4 crittografia a riposo). Defender for Cloud rivaluta e ricalcola il punteggio nelle successive 24-72 ore, quindi il punteggio post-rimediazione è documentato come follow-up piuttosto che affermato ora. Metodo completo, piano ordinato e tabella di collegamento alle rilevazioni: docs/10, rimediazione della postura.

Mappatura dei controlli SOC 2

Questo lavoro supporta un framework di controllo riconosciuto, quindi il repository dice dove. Ogni parte del catalogo si mappa a un Criterio dei Servizi Fiduciari SOC 2: il catalogo di nove regole e gli incidenti alla serie monitora-e-rispondi (CC7.2 a CC7.4), i playbook SOAR alla risposta agli incidenti (CC7.4), la pipeline Detection-as-Code con gated PR alla gestione delle modifiche (CC8.1) e il validation harness e la postura prima/dopo all'efficacia operativa del controllo (CC4.1). È inquadrato come una mappatura, non come una dichiarazione di conformità: questo è un tenant che gestisco, non un'organizzazione sottoposta a audit, quindi il documento mappa le attività di controllo tecnico ed è esplicito riguardo all'involucro di governance di cui un vero report SOC 2 ha bisogno che un repository di rilevazione non porta. Tabella completa criterio per criterio e nota su come viene letto in un audit: docs/11, mappatura dei controlli SOC 2.

Struttura del repository

Competenze dimostrate

KQL · Regole di analisi pianificate di Microsoft Sentinel · Regole di correlazione multi-stadio · Rilevazione dell'identità Entra ID (SigninLogs) · Watchlist di allow-list (_GetWatchlist) · Azure Resource Graph postura-come-contenuto (Azione pianificata) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · Caccia avanzata (tabelle Device / DeviceTvm) · Microsoft Secure Score · Rimediazione della postura di Defender for Cloud (CSPM, MCSB) · Mappatura dei controlli SOC 2 Common Criteria · Detection-as-Code (GitHub Actions, OIDC) · SOAR (Regole di automazione di App per la logica) · Sigma (neutrale rispetto al fornitore) · Validazione Atomic Red Team · Triage e indagine degli incidenti · Mappatura MITRE ATT&CK · Monitoraggio del piano di controllo Azure (Log attività).

Contribuire

Questo è un portfolio personale, ma è strutturato in modo che una modifica a una rilevazione sia una pull request revisionabile, non un clic nel portale. Se lo fork o vuoi proporre una regola, CONTRIBUTING.md copre il flusso di lavoro: modifica il YAML della regola, rigenera lo specchio KQL, estendi il fixture di test, esegui i test unitari localmente e apri una PR che gli stessi gate CI controllano.

Credenziali

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

Dichiarazione di non responsabilità

Un ambiente che gestisco, non un tenant di produzione di alcun datore di lavoro o terza parte. Le rilevazioni sono validate con azioni amministrative controllate e auto-revocate contro le mie risorse; non sono coinvolti sistemi di produzione né terze parti. Identificatori di tenant e sottoscrizione e dati personali sono oscurati in tutti gli screenshot.

Licenza

MIT