Il detection-evidence pack — come provare che la detection funziona

Questo playbook scatta nel momento in cui qualcuno ti chiede di provare che la tua detection funziona — un supervisore DORA che rivede un threat-led penetration test, un'autorità competente NIS2 che conduce un assessment di capacità, un underwriter di cyber-insurance che stringe un rinnovo, un revisore del blue team di un TLPT, o il tuo stesso board dopo la breccia di un peer. Il deliverable è un evidence pack permanente che puoi consegnare a richiesta, non una slide assemblata la sera prima.

Cosa non è in scope: comprare detection, tunare regole o scegliere un SIEM. Questo playbook assume che tu già gestisca tooling di detection; il suo compito è provare che le detection che hai scattano davvero, contro quali tecniche avversarie e quanto in fretta. Un inventario di tool — la lista dei prodotti che possiedi — non è esplicitamente ciò che produce, e non è esplicitamente ciò che nessuna di queste audience accetterà come evidenza.

L'istinto quando ti chiedono di provare la detection è rispondere con lo stack: il vendor EDR, il SIEM, il numero di regole abilitate, il conteggio alert dell'ultimo trimestre. Niente di tutto ciò risponde alla domanda. Una regola che esiste non è una regola che scatta; un conteggio alert misura volume, non copertura; e un logo di prodotto prova l'acquisto, non la detection.

L'evidenza ha la forma opposta. È costruita attorno all'avversario, non al tool, e ha esattamente tre colonne portanti:

• Cosa — la tecnica avversaria, nominata contro un framework condiviso così che il revisore la mappi sul proprio threat model. MITRE ATT&CK è la lingua franca che ogni regolatore, assicuratore e red team già parla.
• Se — una detection è davvero scattata quando quella tecnica è girata, verificato per test, non asserito da un nome di regola.
• Quanto in fretta — il mean time to detect (MTTD) dall'esecuzione della tecnica all'alert, perché una detection che scatta il mattino dopo è un post-mortem, non un controllo.

Un pack che porta queste tre colonne per le tecniche che contano per il tuo settore è evidenza. Qualsiasi cosa di meno è un inventario travestito da evidenza.

Obiettivo: una mappa tecnica-per-tecnica di ciò che dichiari di rilevare, prima di testarne alcunché. Checklist:

• Scegli il threat model, non l'intera matrice. Enumera le tecniche ATT&CK che gli avversari reali del tuo settore usano — affiliati ransomware, le tecniche di initial-access e lateral-movement nella tua storia di incidenti, le tattiche profilate dal threat-intelligence report del tuo TLPT. Voler bollire l'oceano su tutte le 600+ tecniche produce una mappa che nessuno mantiene.
• Mappa ogni tecnica alla/e detection attesa/e. Una riga per tecnica: la data source, la regola o il modello, e il layer (endpoint, rete, identity, cloud).
• Grada la copertura onestamente — coperta / parziale / nessuna — come dichiarazione, non ancora come fatto provato. Parziale significa che la regola esiste ma è non tunata o rumorosa; nessuna significa che non hai detection e ti affidi a un controllo compensativo.
• Segnala i punti ciechi per data source. Una tecnica che si vede solo sul filo (lateral movement, C2 beaconing, esfiltrazione) è invisibile a uno stack solo-endpoint per quante regole EDR tu conti.

La trappola comune qui è la copertura a conteggio-regole — riportare '80% di copertura' perché l'80% delle tecniche ha una regola. Una regola è un'ipotesi finché un test non la fa scattare. La Fase A produce l'ipotesi; la Fase B la trasforma in evidenza.

Questa è la fase portante, e quella che la maggior parte delle organizzazioni salta. Per ogni tecnica in scope, eseguila contro lo stack live e registra cosa è davvero successo.

• Esegui la tecnica, non modellarla. Atomic Red Team è la libreria standard di test piccoli e riproducibili mappati su ATT&CK; una sessione purple-team o un run red-team di un TLPT producono la stessa ground truth a fedeltà più alta. Il punto è che un alert o è scattato o no.
• Registra l'esito per tecnica: è scattato un alert, a quale layer, a che fedeltà (alto segnale vs sepolto nel rumore), e — cruciale — l'MTTD, il gap wall-clock tra esecuzione della tecnica e alert.
• Distingui testato da dichiarato. Una tecnica marcata 'coperta' in Fase A che sotto test non produce alcun alert passa a gap. Questa riconciliazione, fatta con date, è l'artefatto più persuasivo dell'intero pack.
• Metti timestamp su tutto. Ora di esecuzione e ora di alert sono la materia prima della colonna MTTD e la prova che il test è davvero girato nella data che dichiari.

Un MTTD sotto un'ora per una tecnica ad alta severità dice che la tua detection può contenere prima di danni seri; un MTTD sopra le 24 ore dice che non può. I revisori conoscono queste soglie — riportare il numero onestamente batte sempre il dichiarare una percentuale di copertura.

Trasforma i risultati dei test in un artefatto durevole, versionato e datato, non un export una tantum:

• La matrice di copertura: tecnica → detection → coperta/parziale/nessuna, riconciliata contro i test di Fase B.
• Risultati di validazione per tecnica: timestamp di esecuzione, timestamp di alert, layer, fedeltà.
• La distribuzione MTTD per le tecniche ad alta severità — una mediana e una coda, non una singola media che nasconde le detection lente.
• Un registro dei gap accettati: ogni tecnica che non rilevi, perché, e il controllo compensativo su cui ti appoggi.
• Un change log: cosa si è mosso dall'ultimo run, perché la copertura decade in silenzio ogni volta che una log source cade o una regola viene disabilitata.

Permanente è la parola operativa. Un pack assemblato una volta per un audit è stale al deployment successivo. Ri-esegui la validazione a cadenza — trimestrale come minimo, e a ogni cambiamento materiale dell'estate — così il pack che consegni a un supervisore riflette lo stack che gestisci oggi, non quello che gestivi all'assessment dell'anno scorso.

Ordinata per cosa un revisore apre per primo:

• La matrice di copertura, datata — la risposta di una pagina a 'cosa rilevi'.
• Risultati di validazione per tecnica con timestamp di esecuzione e di alert — la prova che la matrice è stata testata, non asserita.
• La distribuzione MTTD per le tecniche ad alta severità — il numero che assicuratori e blue-team report consumano direttamente.
• Il registro dei gap accettati — l'onestà che rende credibile il resto.
• La telemetria di detection grezza dietro la colonna 'quando' — gli eventi datati che provano che ogni alert è davvero scattato.
• Il change log dall'ultimo run — prova che il pack è permanente, non un'istantanea.

La colonna più difficile da produrre onestamente è il 'rilevata / quando' per le tecniche visibili in rete — lateral movement, C2 beaconing, esfiltrazione — perché spesso non lasciano un log endpoint pulito e sono esattamente dove una mappa a conteggio-regole sovrastima la copertura. È qui che l'AI Traffic Analysis di Zero Hunt contribuisce: un modello deep-learning on-appliance con quattro inference head paralleli (traffico sospetto, classificazione malware, identificazione tipo di attacco, application fingerprinting), addestrato su miliardi di sequenze PCAP e in esecuzione localmente sulla GPU dell'appliance, produce eventi di detection con timestamp per quelle tecniche visibili in rete come sottoprodotto dell'operazione normale — così la telemetria 'rilevata / quando' che alimenta la tua colonna MTTD esiste già ed è datata, invece di essere ricostruita per l'audit. È l'input di detection di rete al pack, non l'intero pack — le righe endpoint, identity e cloud restano tue da testare.

Anti-pattern che ritrasformano un detection-evidence pack in un inventario:

• Contare regole, non tecniche. '80% delle tecniche ha una regola' è un'ipotesi di Fase A riportata come risultato di Fase B.
• Dichiarare copertura mai testata. Il gap tra 'abbiamo una regola per quello' e 'l'alert è scattato sotto test' è dove vivono gli incidenti reali.
• Copertura senza tempi. Una matrice senza MTTD risponde a 'sa rilevare' ma non a 'in tempo perché conti' — e ogni audience che la consuma pone la seconda domanda.
• La dichiarazione di copertura al 100%. Un pack senza registro dei gap accettati si legge come disonesto o non testato; una lista di gap candida è ciò che rende credibili le righe coperte.
• Il pack stale. Testato una volta al momento dell'audit e mai ri-eseguito, così certifica uno stack che non esiste più dopo due trimestri di cambiamenti.
• La vista solo-endpoint. Assumere che l'EDR veda tutto, così le tecniche visibili in rete non vengono mai misurate e il pack sovrastima in silenzio la copertura proprio sulle tecniche che gli attaccanti usano per muoversi ed esfiltrare.

Costruisci il pack una volta ed esportalo per audience — l'evidenza sottostante è la stessa, cambia solo l'inquadramento.

• DORA. Il blue-team report del TLPT sotto l'RTS (UE) 2025/1190 cronometra ciò che i difensori hanno rilevato contro ciò che il red team ha davvero fatto — un detection-evidence pack è la baseline permanente che rende quel report un confronto invece di una sorpresa. Il pubblicato playbook di engagement TLPT DORA nomina 'nessuna baseline di detection misurata in ingresso' come failure mode di punta; questo pack è il rimedio.
• NIS2. L'Articolo 21(2) della Direttiva (UE) 2022/2555 richiede capacità di detection e incident-handling come dovere dell'organo di gestione, e gli assessment delle autorità competenti chiedono sempre più evidenza di ciò, non una descrizione.
• Cyber insurance. L'underwriting è passato dai checkbox del questionario all'evidenza, e l'MTTD è la metrica che traduce una matrice di copertura nel linguaggio che un carrier prezza — un pack testato è un asset di rinnovo.
• Metodologia. NIST SP 800-115 è il riferimento neutro per la metodologia di security-testing dietro la Fase B, e si accoppia naturalmente con un programma di continuous threat-exposure management che tiene il pack permanente invece che annuale.