MDR: cos'è e quando serve davvero

La risposta breve: l'MDR, Managed Detection and Response, è un servizio, non uno strumento. Compri un team esterno che monitora i tuoi sistemi 24 ore su 24, filtra gli allarmi, indaga su quelli veri e interviene quando qualcosa succede davvero. Serve quando non hai un team di sicurezza interno e non ha senso costruirlo. Non serve ancora se mancano le fondamenta: prima MFA, backup e inventario, poi il presidio.

Il mercato però lo racconta male: "MDR" compare su brochure di prodotti, licenze e piattaforme, e chi compra fatica a capire cosa sta comprando. Qui mettiamo ordine: cosa include davvero un MDR, in cosa è diverso dall'antivirus gestito e dal SOC, quando ha senso, quando è presto e come si valuta un fornitore in Italia.

Che cos'è il Managed Detection and Response?

La parola che pesa nell'acronimo è "managed". Detection significa accorgersi che qualcosa non va, response significa fare qualcosa al riguardo, e managed significa che non le fai tu: le eroga un fornitore, come servizio continuativo. Non ricevi una console con degli allarmi da interpretare, ricevi un esito: qualcuno si accorge, verifica, ti chiama e contiene.

Sotto il cofano gli ingredienti sono sempre tre:

• tecnologia: EDR o XDR sugli endpoint e, nei servizi più completi, un SIEM che correla anche i log di rete, identità e cloud;
• persone: analisti veri, su turni che coprono notte, weekend e festivi, che guardano gli allarmi e indagano;
• processi: criteri di escalation, runbook, canali di comunicazione decisi prima dell'incidente, non durante.

Se gli acronimi intorno ti si mischiano in testa, abbiamo scritto il dizionario in MDR vs SIEM vs SOC. La sintesi: il SIEM è uno strumento, il SOC è chi presidia, l'MDR è il pacchetto completo consegnato funzionante.

Cosa include davvero un servizio MDR?

Il perimetro cambia da fornitore a fornitore, ma un MDR degno del nome copre queste attività:

• Monitoraggio continuo, 24/7. Non in orario ufficio. Gli attacchi partono di notte, nei weekend e nei ponti, quando chi li conduce sa che nessuno guarda.
• Triage degli allarmi. La tecnologia genera segnali a valanga, in gran parte falsi positivi. Il triage li filtra: a te arriva solo quello che conta, già verificato da un analista.
• Investigation. Quando un segnale è vero, va ricostruito: da dove è entrato l'attaccante, dove si è mosso, cosa ha toccato. Senza questa parte non sai mai quanto è grave.
• Response. Il contenimento: isolare un endpoint, bloccare un account, terminare una sessione. A seconda del contratto lo esegue il fornitore in autonomia oppure ti guida passo passo.
• Threat hunting. La ricerca proattiva di segnali che le regole automatiche non hanno colto: si va a cercare l'attaccante, invece di aspettare l'allarme.
• Reporting. Cosa è successo nel periodo, cosa è stato gestito, dove si sta spostando il rischio. Utile anche per dimostrare le misure a chi le chiede: auditor, clienti, capogruppo.

E cosa di solito non include: gestione di firewall e infrastruttura, patching, vulnerability management continuativo. Sono servizi contigui, a volte dello stesso fornitore, ma sono un'altra riga di contratto. Chiedilo esplicitamente, è una delle sorprese più frequenti.

Che differenza c'è con l'antivirus gestito e con il SOC?

Due confusioni frequenti, due risposte secche.

Antivirus gestito. L'antivirus, anche moderno, blocca sull'endpoint il malware che riconosce, e "gestito" spesso significa che qualcuno controlla la console ogni tanto. L'MDR lavora su un piano diverso: cerca comportamenti, non solo file cattivi. Un attaccante entrato con credenziali rubate non fa scattare nessun antivirus, perché si muove come un utente legittimo: lo trovi solo se qualcuno mette in relazione accessi, orari e movimenti anomali. Quel qualcuno è l'MDR.

SOC classico. Il SOC è il team che presidia la sicurezza, e puoi costruirlo in casa: analisti da assumere, turni da coprire, strumenti da comprare e mantenere. Il problema è la scala: garantire un presidio 24/7 richiede parecchie persone con competenze rare, difficili da trovare e ancora più difficili da trattenere. Abbiamo smontato il modello, voce per voce, in quanto costa un SOC gestito. L'MDR, in pratica, è il modo di avere l'esito di un SOC senza costruirne uno.

Quando serve davvero un MDR?

I casi in cui il servizio ha senso, visti nel mid-market italiano:

• Non hai un team di sicurezza. C'è l'IT, magari bravo, ma fa anche help desk, server e gestionale. La sicurezza è il compito "quando c'è tempo", e quel tempo non arriva mai. È la situazione più comune nelle aziende italiane sotto i mille dipendenti.
• Hai obblighi NIS2, o clienti che li hanno. La direttiva chiede capacità concrete di gestione degli incidenti e notifiche in tempi stretti. Difficile rispettare le scadenze di notifica se non c'è nessuno in grado di accorgersi dell'incidente: la detection continua è il prerequisito di tutto il resto.
• Il tuo dwell time è un'incognita. Il tempo tra l'intrusione e la scoperta si misura in settimane o mesi, non in ore, e spesso a segnalare il problema è qualcuno da fuori. I numeri veri sono in cos'è il dwell time: leggili prima di decidere che "tanto a noi non succede".
• L'ambiente è cresciuto più del controllo. Cloud, SaaS, lavoro remoto, fornitori collegati: la superficie esposta è esplosa, la visibilità è rimasta quella di prima.

Il filo comune dei quattro casi è lo stesso: la domanda giusta non è "compro o non compro uno strumento", è "costruisco o compro la capacità di accorgermi e reagire". Se costruirla in casa non è realistico nei prossimi dodici mesi, l'MDR è la risposta pragmatica.

Quando NON serve ancora?

La risposta onesta che sentirai raramente da chi vende: se mancano le fondamenta, l'MDR non è il primo contratto da firmare. Prima vengono, in quest'ordine:

1. l'inventario: sapere cosa hai, quali macchine, quali identità, cosa è esposto su internet;
2. l'MFA, almeno su posta, VPN e accessi amministrativi;
3. i backup testati, separati dalla rete, con un ripristino provato almeno una volta;
4. il patching con un metodo, a partire dai sistemi esposti;
5. un EDR installato e acceso su tutti gli endpoint, perché è la sorgente che l'MDR userà per vedere.

Un MDR sopra un ambiente senza queste basi è un buon servizio che sorveglia una casa senza porte: vedrà tantissimo, e tu passerai i mesi a rincorrere segnalazioni evitabili. La notizia buona: le fondamenta si costruiscono in fretta se qualcuno le guida, e sono le stesse misure che NIS2 chiede comunque. È il lavoro da cui partiamo nei nostri servizi di cybersecurity, prima ancora di parlare di detection.

Come si valuta un fornitore MDR in Italia?

Cinque criteri che separano il servizio vero dalla brochure.

1. SLA scritti e misurabili. Tempo di presa in carico, tempo di prima analisi, tempo di contenimento. E soprattutto cosa fa il fornitore: notifica soltanto o contiene attivamente? "Vi avvisiamo il prima possibile" non è uno SLA.
2. Lingua e contesto. Alle tre di notte, con un incidente in corso, l'escalation deve essere comprensibile: analisti che parlano italiano e conoscono il quadro normativo, NIS2 e GDPR in testa, tolgono attrito proprio quando conta di più.
3. Piattaforma aperta e dati tuoi. Chiedi dove vivono i log, se puoi interrogarli tu e cosa succede a fine contratto. Un servizio costruito su piattaforme di mercato, come il nostro SOC sopra Google SecOps nei servizi di observability e SecOps, significa dati leggibili e detection che non evaporano se un giorno cambi fornitore.
4. Perimetro esplicito. Endpoint, identità, cloud, rete, posta: cosa è coperto e cosa no, scritto nero su bianco. È qui che nascono i malintesi, molto più che sugli SLA.
5. Prova sul campo. Un onboarding pilota dice più di venti slide: quanto ci mette il fornitore a integrare le tue sorgenti, com'è fatto un report vero, chi ti risponde quando chiami.

In sintesi: l'MDR è il servizio che ti consegna detection e response senza costruire un SOC: monitoraggio 24/7, triage, indagine e contenimento, con persone vere dietro. Serve a chi non ha un team e a chi deve reggere gli obblighi NIS2. Non è il primo passo se mancano MFA, backup e inventario: prima le fondamenta, poi il presidio. E il fornitore si sceglie su SLA, lingua e apertura della piattaforma, non sulla copertina della brochure.