2026-07-15 · Team Fenrir

MDR vs EDR: le differenze reali, spiegate da chi le opera

EDR e MDR non sono concorrenti: uno è uno strumento, l’altro è un servizio. L’EDR è l’agente che registra e blocca sull’endpoint; l’MDR è chi quell’agente lo guarda, lo interroga e risponde, anche alle 2 di notte. Comprare un EDR ti dà telemetria e pulsanti. Comprare un MDR significa che qualcuno quei pulsanti li preme. Vediamo cosa fa davvero ciascuno dei due, e dove passa il confine.

Cos’è un EDR, in pratica?

La categoria ha una data di nascita precisa: il 26 luglio 2013, quando l’analista Gartner Anton Chuvakin battezzò “Endpoint Threat Detection & Response” gli strumenti «focalizzati sul rilevare e investigare attività sospette (e le loro tracce) sugli host/endpoint». La “T” è caduta per strada, il mestiere è rimasto quello. Un EDR moderno fa quattro cose:

1. Registra — processi avviati, connessioni di rete, modifiche a file e registro, comandi eseguiti. In continuo, su ogni endpoint.
2. Rileva — regole e analisi comportamentale sulla telemetria: il PowerShell nascosto, il processo che tocca centinaia di file in un minuto.
3. Permette di investigare — la timeline di cosa è successo prima e dopo l’alert, su quale macchina, con quale utente.
4. Espone azioni di risposta — isolare l’host dalla rete, terminare un processo, mettere un file in quarantena.

Nota il verbo: espone. L’EDR consegna una coda di alert e una pulsantiera. Non decide chi guarda la coda, con che priorità, entro quanto tempo — e non preme i pulsanti da solo, se non per i casi più netti.

Cos’è un MDR, in pratica?

Managed Detection & Response è l’altra metà del lavoro, erogata come servizio: qualcuno — fuori dalla tua azienda — monta la detection sopra i tuoi endpoint e la opera. Monitoraggio continuo, triage degli alert, investigazione, contenimento, caccia proattiva alle minacce, tuning delle regole. Di solito l’MDR è costruito proprio sopra un EDR (tuo o del fornitore): stesso sensore, ma con un turno di lavoro attaccato.

Che il punto critico siano le persone e non la tecnologia lo dice anche chi i servizi li valuta: quando nel 2021 MITRE Engenuity ha lanciato le ATT&CK Evaluations per i servizi gestiti, citava un sondaggio preliminare in cui il 58% delle organizzazioni si affidava a servizi gestiti per il proprio SOC — e circa la metà non era fiduciosa nelle persone o nella tecnologia del proprio fornitore. Da lì il formato “closed book”: il fornitore non sa quale avversario verrà emulato, esattamente come nella realtà.

La differenza di fondo sta nel deliverable. L’EDR ti consegna software e telemetria. L’MDR ti consegna un esito: l’incidente triagato, contenuto, spiegato.

Se ho già un EDR, cosa mi manca?

Tre cose, e nessuna è un modulo che si compra col checkout.

Chi guarda la coda. Un EDR su qualche decina di endpoint produce alert ogni giorno: veri, falsi, e quel grigio in mezzo che costa tempo. Senza un responsabile del triage — con tempi definiti — la coda diventa rumore di fondo, e l’alert vero annega tra i falsi positivi.

Chi c’è fuori orario. Gli attaccanti scelgono il momento: nei casi di ransomware analizzati da Mandiant tra il 2017 e il 2019, il 76% delle esecuzioni è avvenuto fuori dall’orario lavorativo — weekend, prima delle 8, dopo le 18. Non è un caso: è il momento in cui la coda dell’EDR non la guarda nessuno.

Chi spegne l’incendio, e come. La risposta non è un pulsante ma un processo: il NIST le ha dedicato la SP 800-61r3 (2025), che tratta l’incident response come un ciclo continuo — preparazione, rilevamento, risposta, recupero — dentro la gestione del rischio, non come un gesto isolato. Isolare l’host giusto al momento giusto, decidere se un reimage serve, ricostruire il vettore d’ingresso: servono playbook e mani allenate.

E c’è un quarto punto, il più antipatico: l’EDR è un bersaglio. MITRE ATT&CK cataloga come T1685 (Disable or Modify Tools, l’ex T1562.001) la pratica degli attaccanti di disabilitare, degradare o manomettere proprio gli strumenti di sicurezza — EDR incluso — per accecare la difesa. Un sensore che smette di parlare non manda alert: è un silenzio, e il silenzio lo nota solo chi sta ascoltando.

Quanto conta il tempo, numeri alla mano?

Il dwell time — quanto un attaccante resta nella rete prima di essere scoperto — è la metrica che separa un fastidio da un disastro. M-Trends 2025 (dati 2024, oltre 450.000 ore di investigazioni Mandiant) fotografa così la situazione:

• dwell time mediano globale: 11 giorni;
• quando l’organizzazione se ne accorge da sola: 10 giorni;
• quando lo scopre perché qualcuno da fuori glielo notifica: 26 giorni;
• quando è l’attaccante stesso ad annunciarsi (tipicamente la nota di riscatto): 5 giorni.

Leggi l’ultima riga per quello che è: nei casi peggiori la “detection” è il ransomware che si presenta. La differenza tra 10 e 26 giorni è la differenza tra avere una detection operata — da un team interno o da un MDR — e aspettare che se ne accorga qualcun altro.

MDR, SOC, XDR: come si incastrano le sigle?

Glossario operativo, senza marketing:

• EDR — strumento. Sensore e attuatore sull’endpoint.
• XDR — strumento. Come l’EDR, ma estende raccolta e correlazione a rete, identità, cloud, email.
• SOC — funzione. Le persone, i processi e la tecnologia che monitorano e rispondono, in casa.
• MDR — servizio. Le funzioni operative di un SOC comprate dall’esterno, di norma su uno stack predefinito del fornitore.

La domanda “EDR o XDR?” riguarda cosa raccogli. La domanda “SOC interno o MDR?” riguarda chi risponde. Sono due assi diversi, e confonderli è il modo più rapido per comprare la cosa sbagliata.

Come scelgo tra EDR da solo e MDR?

Tre domande oneste, da farti prima di guardare qualunque listino:

1. Chi fa triage di un alert critico entro 30 minuti, oggi? Un nome e un cognome, non “il reparto IT”.
2. Chi lo fa sabato alle 3 di notte? (Rileggi il 76% di cui sopra.)
3. Chi fa tuning delle regole e caccia alle minacce ogni settimana? Un EDR mai accordato urla, e chi urla sempre non viene ascoltato.

Se una risposta è “nessuno”, il tuo EDR è una scatola nera: registrerà benissimo l’incidente che nessuno ha fermato. A quel punto le opzioni sono due — costruire il presidio (persone, turni, playbook) o comprarlo come servizio.

E se valuti un MDR, rovescia il tavolo con domande da operatore: quali azioni di risposta è autorizzato a compiere da solo (isolamento? kill di processo?) e quali richiedono la tua approvazione? Che tempi di contenimento dichiara, misurati come? La telemetria resta tua se il contratto finisce? E come dimostra la qualità della detection — ha mai accettato una valutazione indipendente a scenario cieco, come le ATT&CK Evaluations di MITRE Engenuity?

E l’AI, in tutto questo?

È il terzo modo di coprire il turno di notte. Il collo di bottiglia dell’MDR classico sono le persone — trovarle, formarle, tenerle sveglie — e per questo il nostro approccio in Fenrir MDR inverte lo schema: l’AI fa detection, triage e contenimento in autonomia graduata (sopra soglia di confidenza agisce da sola, con azioni reversibili; sotto, chiede), e l’umano supervisiona le decisioni ad alto impatto. Gli endpoint e i server finiscono nella stessa console del SOC, correlati. Il principio però non cambia ed è il punto di tutto questo articolo: lo strumento senza qualcuno — o qualcosa — che lo opera è solo telemetria ben archiviata.