La matrice ATT&CK come strumento di misura

MITRE ATT&CK descrive il comportamento degli attaccanti su due livelli: le tattiche (l’obiettivo — Initial Access, Execution, Persistence, Credential Access, Lateral Movement, Exfiltration) e le tecniche (il modo concreto con cui quell’obiettivo viene raggiunto). Microsoft Sentinel usa questa tassonomia come griglia di misura: la vista a matrice mostra, tecnica per tecnica, quante detection sono davvero attive nel workspace e quante esistono soltanto come contenuto non ancora distribuito.

La distinzione è quella che l’esame verifica. La copertura attiva nasce dalle analytics rule abilitate; rule template non deployate e hunting query contribuiscono solo alla copertura potenziale. Una matrice illuminata dai template non protegge nessuno.

Come si alimenta la copertura

Il mapping non viene dedotto dalla query. Su una regola Scheduled o NRT scritta in casa, tattiche e tecniche sono metadati che l’autore dichiara nella regola: se li ometti, la detection funziona ma la cella resta vuota e il report di copertura mente. Le regole Microsoft Security (che promuovono a incident gli alert dei workload Defender) e quelle Fusion, Anomaly e Threat Intelligence portano invece un mapping proprio, gestito da Microsoft.

Da qui parte il detection engineering: si guardano le tattiche dove il rischio per l’organizzazione è alto e la copertura è zero, e si stabilisce se il buco è di contenuto (nessuna regola) o di dati (la sorgente che servirebbe non è ingerita — inutile scrivere una regola su SecurityEvent se i domain controller non inviano nulla, cosa che si verifica con Heartbeat e con lo stato delle data collection rule). Le raccomandazioni di SOC optimization ragionano sullo stesso asse: per uno scenario di minaccia indicano quali detection e quali sorgenti mancano, ed è il complemento naturale della lettura della matrice.

Copertura non significa efficacia: una tecnica presidiata da una sola regola rumorosa, chiusa ogni volta come falso positivo, sulla matrice è verde e nella realtà è un buco.

Le anomalie: segnale per l’hunting, non per l’alert

Le regole di tipo Anomaly sono modelli di machine learning preconfezionati che imparano un baseline (per utente, host, applicazione) e marcano gli scostamenti: un volume di download fuori scala, un logon da una provenienza mai vista, un orario incoerente con lo storico. Nascono per l’hunting e per l’arricchimento del contesto durante un’indagine, non per svegliare l’analista: da sole non producono alert né incident. Il loro output resta nel workspace come dato interrogabile, da correlare ad altri eventi o da usare per dare peso a un’entità già sospetta.

Se il requisito è “voglio essere avvisato”, serve un passo in più: una Scheduled analytics rule costruita sopra l’output dell’anomalia, filtrata (una sola tipologia, un punteggio minimo, un perimetro di utenti privilegiati) per non riversare in coda tutto il rumore statistico. Un’anomalia si può anche tarare senza perdere il segnale: si lavora su una copia in modalità di test mentre l’originale resta in produzione, e si promuove solo quando la soglia regge.

Diverso il caso di Fusion, che pure consuma segnali a bassa fedeltà: correla eventi di workload differenti in una kill chain multi-stage e genera incident ad alta fedeltà, senza che tu scriva query.

Trappole tipiche d’esame

  • Una scheduled rule custom rileva la tecnica ma la matrice mostra il buco → dichiarare tattica e tecnica nella regola: il mapping ATT&CK è un metadato della regola, non viene inferito dal KQL.
  • La matrice sembra ben coperta ma il SOC non riceve nulla → distinguere regole attive e template: solo le analytics rule abilitate producono alert, la galleria è copertura potenziale.
  • Serve un alert su un comportamento anomalo e la Anomaly rule è già attiva → aggiungere una Scheduled rule sopra il suo output: l’anomalia arricchisce e alimenta l’hunting, non chiama l’analista.
  • Troppi falsi positivi da un’anomalia ma il segnale serve → tarare una copia in test lasciando l’originale in produzione: disabilitarla è la risposta sbagliata.
  • Una hunting query si è dimostrata affidabile e va operativizzata → promuoverla ad analytics rule in Sentinel, o a custom detection rule in Defender XDR: nel secondo caso la query deve restituire le colonne richieste, fra cui Timestamp, ReportId e una colonna di entità.
  • Correlare endpoint, identità e cloud app in un attacco multi-stage senza scrivere query → Fusion: una scheduled rule su una singola tabella non copre lo scenario, e la copertura ATT&CK di Fusion la gestisce Microsoft.