SOC e MDR come servizio: quando ha senso

SOC e MDR come servizio hanno senso quando l'organizzazione ha bisogno di detection e response 24x7 ma non ha la scala per mantenere un team interno maturo. Il fornitore eroga monitoraggio continuo, triage e contenimento; l'azienda mantiene il contesto di business e la decisione finale. La scelta dipende da maturità, volume e costo totale.

Pochi temi di security operation generano tanta confusione quanto la differenza tra costruire un SOC interno, adottare un SOC gestito o sottoscrivere un servizio di MDR. Le tre risposte risolvono lo stesso problema — vedere e contenere un attacco prima che diventi incidente — ma partono da premesse di costo, scala e maturità molto diverse. Questo testo separa i concetti e mostra come decidere senza restare intrappolati nelle etichette dei fornitori.

Cosa sono SOC e MDR come servizio?

Un SOC (Security Operations Center) è la funzione di monitorare, rilevare e rispondere alle minacce in modo continuo; MDR (Managed Detection and Response) è un servizio che eroga quella funzione dall'esterno, combinando tecnologia, telemetria e analisti reperibili. In pratica, un SOC può essere interno, esternalizzato o ibrido — l'MDR è uno dei modi per esternalizzarlo, focalizzato sulla detection e response attiva, non solo sulla raccolta di alert.

La distinzione che conta di più non è il nome, ma cosa copre ciascuna soluzione:

• SOC interno — l'organizzazione costruisce il team, opera gli strumenti (SIEM, EDR, analisi dei log) e risponde agli incidenti con personale proprio.
• SOC gestito (MSSP classico) — un terzo monitora gli strumenti e inoltra gli alert, ma la response resta di solito dal lato del cliente. Diventa una fabbrica di ticket se il triage è debole.
• MDR — il fornitore non solo rileva ma conduce la response: isola un endpoint, blocca un account, contiene la minaccia e poi consegna il contesto. È l'evoluzione del modello gestito orientata a ridurre il tempo tra l'alert e il contenimento.

Il punto cieco più comune è adottare un servizio che genera solo alert e aspettarsi da esso la maturità di uno che risponde anche. Detection senza response restituisce il lavoro difficile a chi non aveva il team per farlo.

Quando ha senso adottare invece di costruire internamente?

Adottare SOC o MDR come servizio ha senso quando il costo e il tempo di costruire la capacità internamente superano il valore di tenerla sotto controllo diretto. Un SOC proprio maturo richiede turni 24x7, il che in pratica significa assumere da sei a otto analisti solo per coprire la scala senza fatica, più detection engineering, gestione della piattaforma e retention dei talenti — una superficie di costo che poche aziende fuori dal settore finanziario sostengono da sole.

I segnali che il modello come servizio tende a convenire:

1. L'operazione ha bisogno di copertura 24x7 e il volume non giustifica un team interno completo. L'attacco non rispetta l'orario di ufficio; un team che copre solo il giorno lascia scoperta la finestra più sfruttata.
2. Manca detection engineering matura. Comprare un SIEM è facile; scrivere, calibrare e mantenere regole di detection utili è il lavoro vero, ed è dove la maggior parte dei SOC interni si blocca.
3. Il turnover degli analisti erode la capacità. La security operation soffre di turnover elevato; un fornitore diluisce quel rischio tra più clienti.
4. L'azienda deve attivare la capacità in fretta, per un requisito normativo o contrattuale o per un incidente recente, senza aspettare i mesi che la costruzione interna richiede.
5. Il costo totale dell'interno non torna. Sommando persone, piattaforme, formazione e costo opportunità, il modello come servizio spesso eroga più maturità per unità investita nelle fasi iniziali.

D'altra parte, costruire (o mantenere) il SOC interno ha senso quando il contesto di business è altamente specifico, quando c'è un vincolo normativo su dove la telemetria può essere elaborata, o quando l'organizzazione ha già raggiunto una scala sufficiente perché il team proprio risulti più economico del servizio. Nella maggior parte dei casi il disegno vincente è ibrido: il fornitore sostiene il continuo e la reperibilità, e un team interno snello mantiene il contesto, decide sulle azioni a maggiore impatto e governa il fornitore.

SOC/MDR esternalizzato o team interno: come confrontare?

Il confronto onesto guarda costo totale, tempo di maturazione, copertura e controllo — non solo il prezzo dell'abbonamento. La tabella riassume le differenze strutturali tra i due estremi; il modello ibrido, in pratica il più adottato, combina le colonne in base al rischio.

Nessuna colonna è vincente in assoluto. L'errore è confrontare solo il canone mensile del servizio con lo stipendio di un analista — il conto reale include i turni che garantiscono la scala, la piattaforma, la formazione continua e il tempo finché l'operazione rileva davvero qualcosa di rilevante.

Cosa esigere da un fornitore di SOC/MDR?

Esiga trasparenza operativa, response contrattualizzata e proprietà dei suoi dati — senza questi tre pilastri, il servizio diventa una scatola nera che non può né auditare né portare via. La qualità di un fornitore sta meno nel marketing e più in ciò che accetta di mettere per iscritto. La checklist minima prima di firmare:

• SLA di detection e di response, non solo di disponibilità. Chieda il tempo medio fino al triage e fino al contenimento, e cosa accade quando viene superato. L'"uptime della piattaforma" non protegge nessuno.
• Copertura delle tecniche mappata in MITRE ATT&CK. Un fornitore serio mostra quali tattiche e tecniche rileva e dove sono le lacune, invece di promettere di rilevare "tutto".
• Response attiva definita. Chiarisca cosa il fornitore può fare da solo (isolare un endpoint, bloccare un account) e cosa richiede approvazione. L'ambiguità qui costa minuti preziosi durante un incidente.
• Threat intelligence azionabile e regionalizzata. L'intelligence generica genera rumore; quella che conta è contestualizzata per il suo settore e per lo scenario di minacce che colpisce davvero le operazioni in Brasile e America Latina.
• Modello co-gestito e senza lock-in. Deve mantenere l'accesso ai dati grezzi, alle regole di detection e allo storico. Se uscire dal contratto significa perdere tutto, il costo di cambio diventa una gabbia.
• Proprietà e residenza dei dati. Definisca per contratto dove la telemetria è archiviata ed elaborata e chi può accedervi — punto critico per la protezione dei dati e per i dati soggetti a regolazione settoriale.
• Report che sostengono le decisioni, non la vanità. Metriche di tempo di response, incidenti contenuti ed evoluzione della copertura valgono più di un conteggio di alert.
• Integrazione con il suo processo di response. Il fornitore deve inserirsi nel suo piano di incident response e nei suoi canali, non imporre un flusso isolato che nessuno internamente segue.

Come si collega il SOC/MDR a compliance e regolazione?

Detection e response continue sono, sempre più, un requisito normativo — non solo buona pratica. Le istituzioni sotto supervisione del settore finanziario devono dimostrare la capacità di monitorare e rispondere agli incidenti cyber; le risoluzioni del BACEN/CMN sulla sicurezza cibernetica, inclusa la 4.893, stabiliscono requisiti di policy, detection e comunicazione degli incidenti che un SOC/MDR aiuta a sostenere. Lo stesso vale per le operazioni di pagamento e per chi tratta dati sotto la regolazione sulla protezione dei dati, dove il tempo di detection influisce direttamente sulla capacità di contenere la fuga e di comunicare entro i termini.

Un servizio di detection ben progettato alimenta il resto del programma di sicurezza. Fornisce evidenza di monitoraggio per gli audit di adeguamento alla ISO 27001, sostiene i requisiti di incident response richiesti da PCI DSS, e rafforza la governance dei dati personali nel lavoro di adeguamento alla LGPD. Per le organizzazioni con esposizione europea, gli stessi controlli dialogano con gli obblighi di segnalazione degli incidenti della direttiva NIS2. Il SOC non è un'isola operativa — è lo strato che genera l'evidenza viva che i controlli delle norme funzionano davvero nel quotidiano.

Come lavora Berghem

Berghem tratta la detection e response come una capacità che deve essere intelligente, non solo continua. Il punto di partenza del nostro servizio di threat intelligence e detection non è il volume di alert, ma il modello di minaccia di ciascun cliente: quali avversari hanno un motivo per attaccare quell'operazione, quali tecniche usano e dove un guasto avrebbe il maggiore impatto sul business. Da lì, la detection engineering è calibrata su ciò che conta — perché una dashboard che urla a ogni evento è una dashboard che il team impara a ignorare.

Il lavoro poggia su tre principi. Il primo è l'intelligence regionalizzata: mappiamo le tecniche in MITRE ATT&CK e diamo priorità alle minacce che colpiscono davvero le operazioni in Brasile e America Latina, invece di importare scenari generici. Il secondo è l'integrazione con il resto del programma di sicurezza — la detection dialoga con gli esercizi di Red Team che validano se i controlli scattano davvero, con il pentest di rete e il pentest di cloud che riducono la superficie monitorata, e con la pipeline di compliance quando c'è una norma in gioco. Il terzo è la trasparenza: mantiene l'accesso al contesto, alle regole e alle evidenze, senza scatola nera.

Siamo un'azienda di sicurezza informatica a São Paulo, e il servizio si collega al portfolio secondo quanto il rischio giustifica, dal pentest di API alla sicurezza in Open Finance. Ogni consegna dà priorità all'impatto sul business rispetto al conteggio degli alert, con una metodologia riconosciuta a sostegno di ogni fase.

Domande frequenti

Qual è la differenza tra SOC gestito e MDR?

Un SOC gestito classico monitora i suoi strumenti e inoltra gli alert, lasciando a lei la response; l'MDR va oltre e conduce il contenimento — isola un endpoint, blocca un account, contiene la minaccia — prima di consegnare il contesto. La differenza pratica sta nel tempo tra l'alert e l'azione: l'MDR chiude quell'intervallo.

Il SOC come servizio sostituisce il team interno di sicurezza?

Non lo sostituisce, lo completa. Il fornitore sostiene la reperibilità 24x7 e la detection engineering che richiedono scala, ma il contesto di business, la decisione sulle azioni a maggiore impatto e la governance del fornitore stesso devono restare dal lato dell'organizzazione. Il disegno più efficace tende a essere ibrido.

Come evitare il lock-in a un fornitore di MDR?

Definisca nel contratto, prima di firmare, che mantiene l'accesso ai dati grezzi, alle regole di detection e allo storico degli incidenti, oltre a una residenza dei dati compatibile con la normativa. Esiga che la telemetria e le detection siano esportabili. Se terminare il contratto significa perdere tutto, il costo di cambio diventa una gabbia.

Per progettare detection e response calibrate sul suo modello di minaccia, scopra il servizio di threat intelligence e detection di Berghem.