"XDR" è una delle sigle più abusate del marketing della sicurezza: ogni vendor la appiccica a qualunque cosa venda. Sta per Extended Detection and Response, un termine attribuito a Nir Zuk di Palo Alto Networks e adottato da Gartner intorno al 2018. Tolto l'hype, però, XDR è una promessa precisa: unificare la telemetria di tutto l'ambiente - endpoint, rete, identità, cloud, log - rilevare le minacce correlando tra questi silos, e rispondere, possibilmente in automatico. La parte difficile non è nessuno dei singoli pezzi: è farli diventare uno. Lo so perché ne ho costruito uno, Presidio, e questa è l'anatomia vista da dentro.
Da dove viene: SIEM, EDR e il problema dei silos
Per capire l'XDR serve la storia che lo precede. Il SIEM (Security Information and Event Management) è la vecchia spina dorsale del SOC: raccoglie i log da mezza azienda e cerca pattern sospetti tramite regole di correlazione. L'EDR (Endpoint Detection and Response) è arrivato dopo, portando telemetria profonda dall'endpoint - processi, comandi, connessioni - e la capacità di reagire direttamente sulla macchina. Il limite di entrambi è lo stesso: ognuno vede una sola fetta. E un attacco serio attraversa le fette - una credenziale rubata sull'endpoint, un movimento laterale in rete, un accesso anomalo all'identità - dove ogni singolo evento sembra innocuo, ma la sequenza è ovvia se la metti insieme. XDR è il tentativo di mettere insieme quelle fette. Gartner lo descrive con la "triade di visibilità del SOC": log (SIEM), endpoint (EDR) e rete (NDR, Network Detection and Response), che insieme coprono quasi ogni traccia che un attaccante lascia.
I cinque strati di un XDR
Sotto il marketing, una piattaforma XDR è una pipeline a cinque strati. Capirli è il modo migliore per valutarne una - o per costruirla.
1. Telemetria, le fonti. Agenti sull'endpoint, sensori di rete, log di autenticazione e identità, audit log del cloud, log applicativi. Vale la regola spietata del "garbage in, garbage out": puoi rilevare solo ciò che raccogli, e una fonte mancante è un punto cieco permanente.
2. Ingestione e normalizzazione. Lo strato che prende dati eterogenei e li traduce in uno schema comune, così che un evento di Windows e uno di un firewall diventino confrontabili. È la parte meno appariscente, ed è dove vive gran parte dell'ingegneria. Esistono standard nati apposta: l'OCSF (Open Cybersecurity Schema Framework, avviato nel 2022 da AWS, Splunk e altri) e l'ECS di Elastic.
3. Detection. Qui si decide cos'è sospetto, e tre approcci convivono: regole (firme di comportamenti noti), analisi comportamentale (anomalie rispetto a una baseline) e matching con la threat intelligence. Il linguaggio comune è MITRE ATT&CK, la knowledge base delle tecniche reali usate dagli attaccanti; le regole portabili si scrivono in formato Sigma. E c'è un principio che guida le priorità, la "Pyramid of Pain" di David Bianco (2013): rilevare un hash o un IP infastidisce poco l'attaccante - li cambia in un minuto - mentre rilevare le sue tecniche lo costringe a rifare tutto da capo.
4. Correlazione e arricchimento. È la "X" di XDR: trasformare tanti eventi a basso segnale in un incidente ad alto segnale, unendo i puntini tra domini diversi e aggiungendo contesto - threat intel (una piattaforma come MISP), inventario degli asset, identità coinvolte. Senza questo strato hai una collezione di allarmi; con questo strato hai un caso.
5. Risposta. Due metà. L'automazione - il SOAR (Security Orchestration, Automation and Response): playbook che isolano una macchina, bloccano un IP, disabilitano un account in pochi secondi. E il lavoro umano: gestione del caso, indagine, decisione. La regola pratica è una sola: automatizza l'ovvio, lascia all'umano il giudizio.
Il linguaggio comune: MITRE ATT&CK
Se c'è una cosa da portarsi a casa per valutare qualsiasi XDR, è ATT&CK: una matrice pubblica, mantenuta da MITRE, che cataloga le tattiche e le tecniche reali degli attaccanti - non vulnerabilità teoriche, ma "cosa fa davvero un avversario", passo per passo. Il suo valore è duplice. Dà alla detection un linguaggio condiviso: una regola non rileva "questo IP è cattivo", rileva "esecuzione tramite PowerShell offuscato", una tecnica precisa. E permette di misurare la copertura. La domanda giusta da fare a qualunque piattaforma - comprata o costruita - non è "quanti alert generi?", ma "quali tecniche ATT&CK rilevi, e come lo misuri?".
La detection è ingegneria, non un prodotto
L'errore più comune è pensare che la detection si compri una volta e funzioni per sempre. Non è così: gli attaccanti si adattano, le regole invecchiano, e i falsi positivi seppelliscono il segnale vero - la alert fatigue di cui ho parlato nel pezzo su come tagliare il rumore nella threat intelligence. Per questo è nata la disciplina della detection engineering: detection scritte come codice - versionate, testate e riviste come si fa col software - regole Sigma portabili, e validazione tramite esercizi di purple teaming, cioè l'attacco simulato per verificare che la detection scatti davvero. Il valore vero di un XDR non è la dashboard: è il contenuto di detection e la sua manutenzione continua.
Le due metriche che contano: MTTD e MTTR
Una piattaforma di sicurezza si misura con due numeri. Il MTTD (Mean Time To Detect), quanto tempo passa prima che un attacco venga visto, e il MTTR (Mean Time To Respond), quanto tempo passa prima che venga fermato. Il dwell time - i giorni in cui un attaccante resta dentro indisturbato - è sceso negli anni, come documentano gli M-Trends di Mandiant, ma il ransomware ha compresso la finestra utile a poche ore. È qui che l'automazione cambia tutto: un playbook SOAR risponde in secondi dove un essere umano impiegherebbe ore. Una piattaforma che rileva in giorni è teatro; l'obiettivo sono i minuti.
Comprato, costruito o assemblato
Esistono XDR commerciali "tutto in uno": veloci da attivare, un solo fornitore a cui chiedere conto - ma con lock-in, costi che crescono e detection a scatola nera. L'alternativa è assemblarne uno con componenti open source maturi, che oggi coprono ogni strato. È esattamente come ho costruito Presidio.
Il punto, di nuovo, non sono i componenti - sono provati e documentati ovunque. Il lavoro di ingegneria, e il valore, è nell'integrazione: i bridge che fanno parlare il SIEM con il SOAR, il SOAR con il case manager, la threat intel con tutto, così che un singolo evento faccia scattare una risposta correlata, automatica e documentata in pochi secondi. Il playbook di Presidio per un brute force SSH, ad esempio, correla l'evento con la threat intel, apre un caso e può bloccare l'IP sull'intera infrastruttura - in un colpo solo. Possedere quell'integrazione è possedere la piattaforma.
Piattaforma o dashboard? Il test
La domanda che separa un XDR vero da un cruscotto colorato è semplice: il sistema fa il lavoro, o lo fai tu guardando dei grafici? Un XDR vero correla tra domini (non si limita a raccogliere), ha una copertura ATT&CK misurabile, automatizza la risposta (non solo allerta), tiene un caso e un audit trail, ed è messo a punto fino ad avere pochi falsi positivi. Una dashboard ti mostra i dati e ti lascia trovare la violazione da solo.
Una checklist per valutare (o costruire) un XDR
- Fonti: copri davvero endpoint, rete, identità e cloud, o solo una fetta?
- Detection: è mappata a MITRE ATT&CK, e la copertura è misurata?
- Correlazione: è cross-dominio o solo per-silo?
- Risposta: c'è automazione (SOAR), non solo allarmi?
- Workflow: esiste case management e un audit trail di ciò che è stato fatto?
- Metriche: MTTD e MTTR sono misurati e migliorano nel tempo?
- Proprietà: le detection le puoi vedere, versionare e modificare, o sono una scatola nera?
La conclusione
XDR non è un prodotto da comprare a scatola chiusa: è una capacità - vedere ovunque, correlare, rispondere in fretta, e migliorare nel tempo. La sigla la mette ogni vendor; la sostanza sta in cinque strati che devono funzionare come uno. Che tu lo compri, lo assembli o lo costruisca - io l'ho costruito - il metro non cambia: quanto in fretta vedi un attacco, quanto in fretta lo fermi, e quanto del processo non dipende da un essere umano sveglio alle tre di notte.
Se vuoi approfondire questo argomento o ti serve una consulenza specializzata, parliamone.
Parliamone →Analisi su cybersecurity, vulnerability research e difesa concreta per le imprese. Niente spam: solo quando ho qualcosa che vale. Disiscrizione in un clic.