SOC ibrido (co-gestito): come si dividono i compiti

Un SOC ibrido, o co-gestito, è un SOC in cui team interno e fornitore esterno lavorano sugli stessi dati con compiti divisi per iscritto. Di solito il fornitore copre il monitoraggio 24/7 e il primo triage, mentre il team interno tiene il contesto, le decisioni di risposta sui sistemi critici e la responsabilità verso le autorità.

Funziona quando la divisione è decisa prima del primo incidente: chi possiede la piattaforma, chi scrive le regole, chi può isolare un server alle tre di notte, chi notifica. Se stai ancora decidendo tra costruire il SOC in casa e affidarlo fuori, il confronto è in SOC interno vs gestito.

Cosa vuol dire co-gestito, e cosa non vuol dire

Nel SOC pienamente gestito il fornitore fa il lavoro e tu ricevi alert e report; nel co-gestito le due squadre lavorano sullo stesso flusso di eventi e si passano gli incidenti secondo regole concordate.

La guida NIST SP 800-61r3 sulla risposta agli incidenti (aprile 2025), nella sezione 2.2 sui ruoli, prevede che chi gestisce gli incidenti possa essere interno, a contratto (cita l'esternalizzazione del SOC a un MSSP) o chiamato al bisogno, e osserva che molte organizzazioni combinano più approcci. Lo chiama modello a responsabilità condivisa: le responsabilità trasferite al fornitore vanno definite nel contratto, compresi flussi di informazione, coordinamento e autorità di agire per conto dell'organizzazione.

Un SOC ibrido senza una divisione scritta è un SOC in cui ciascuna squadra pensa che l'altra se ne stia occupando.

Tre modi di dividere il lavoro

Nella pratica i compiti si dividono lungo tre assi. Spesso si combinano.

Per orario

Il team interno presidia in orario d'ufficio, il fornitore copre notti, weekend e festivi. Risolve il problema più costoso, la rotazione dei turni notturni. Il punto debole è il passaggio di consegne: due volte al giorno un incidente aperto cambia mano, e lì si perdono informazioni se non c'è un registro unico.

Per livello

Il fornitore fa il primo livello 24/7: riceve gli alert, scarta i falsi positivi, arricchisce quelli veri e li passa. Il team interno fa l'indagine approfondita e decide la risposta. Cosa fa ogni livello è spiegato in cosa fa un SOC analyst.

Per piattaforma

Qui la domanda è chi possiede il SIEM. In un caso l'azienda ha già la sua piattaforma, con licenza e regole proprie, e il fornitore entra a operarla. Nell'altro il fornitore porta la piattaforma come parte del servizio e il team interno ci lavora con accessi concordati. La differenza si vede il giorno in cui il contratto finisce.

Chi possiede cosa: SIEM, dati, regole, playbook

È la parte che nei contratti resta più vaga. Conviene scriverla voce per voce.

• La piattaforma e la licenza. Di chi è l'istanza del SIEM, chi paga la licenza, a chi resta se il rapporto si chiude.
• I dati. Dove sono conservati i log, per quanto tempo, in che formato ti vengono restituiti. Per le entità finanziarie DORA lo rende un obbligo contrattuale: l'art. 30, paragrafo 2, lettera d), del Regolamento (UE) 2022/2554 chiede nei contratti ICT garanzie di accesso, ripristino e restituzione dei dati in un formato facilmente accessibile, anche in caso di risoluzione.
• Le regole di rilevamento. Chi le scrive, chi le approva, chi può disattivarle o aggiungere un'eccezione, e di chi sono alla fine del contratto.
• I playbook e le autorizzazioni di risposta. Quali azioni il fornitore può fare da solo e quali richiedono il via libera di una persona tua. Cosa contiene un playbook, con esempi, è in playbook SOC: cosa contiene.

Gli accessi seguono da queste scelte. Su Google SecOps, la piattaforma su cui lavoriamo, la documentazione prevede ruoli predefiniti (amministrazione, modifica, sola lettura, e una sola lettura limitata che esclude le regole di rilevamento) e ruoli personalizzati: si può decidere chi modifica le regole e chi le propone, senza dare a tutti gli stessi poteri.

Serve anche un registro delle modifiche: una regola cambiata da una squadra senza avvisare l'altra può spegnere un rilevamento senza che nessuno se ne accorga.

La matrice RACI di un SOC co-gestito

La RACI scrive la divisione attività per attività: indica chi la esegue (R, Responsible), chi ne risponde e decide (A, Accountable, una sola persona o funzione), chi va consultato prima (C, Consulted) e chi va informato dopo (I, Informed). NIST SP 800-61r3, alla voce GV.RR-02, raccomanda di documentare nelle policy tutti i ruoli legati alla risposta agli incidenti e di dare a ciascuna parte l'autorità necessaria per svolgerli, terze parti comprese.

Un punto di partenza per il caso con fornitore sul primo livello 24/7 e team interno su decisioni e contesto. Non è uno standard: va adattato al tuo perimetro.

1. Collegamento e salute delle fonti di log: R fornitore, A responsabile IT interno, C proprietari dei sistemi.
2. Scrittura e manutenzione delle regole di rilevamento: R fornitore, A responsabile sicurezza interno, C team interno per il contesto.
3. Tuning ed eccezioni: R fornitore, A responsabile sicurezza interno. Ogni eccezione documentata e motivata.
4. Triage degli alert 24/7: R e A fornitore, I team interno secondo la gravità.
5. Indagine su un incidente confermato: R fornitore e team interno insieme, A responsabile sicurezza interno.
6. Contenimento su endpoint e account: R fornitore entro le autorizzazioni concordate, A responsabile sicurezza interno, I proprietari dei sistemi.
7. Azioni su sistemi di produzione critici: R team interno o fornitore su richiesta, A direzione o responsabile del servizio colpito, C fornitore.
8. Notifica al CSIRT Italia per i soggetti NIS2: R e A l'azienda, C fornitore per le informazioni tecniche.
9. Report e revisione periodica: R fornitore, A responsabile sicurezza interno, I direzione.

Due controlli sulla matrice finita: ogni riga ha una sola A, e ogni R del fornitore che tocca i tuoi sistemi ha scritto accanto cosa può fare senza chiedere.

Escalation e passaggi di consegne

Nel SOC ibrido l'escalation deve attraversare il confine tra due organizzazioni, spesso di notte. Le regole da fissare sono poche.

• Un solo registro degli incidenti, visibile a entrambe le squadre. Due sistemi di ticket paralleli producono incidenti visti da tutti e gestiti da nessuno.
• Un proprietario per ogni incidente aperto, che cambia solo con un passaggio esplicito, scritto nel registro.
• Una matrice di escalation per gravità: chi viene chiamato, con quale canale, entro quanto tempo, con un sostituto per ogni nome. Come si costruisce, e come si prova prima di averne bisogno, è spiegato in onboarding di un SOC gestito.
• I limiti del fornitore scritti. NIST SP 800-61r3 indica tra gli elementi da definire anche le restrizioni su ciò che il fornitore può fare, come prendere decisioni operative tipo disattivare subito un servizio per contenere un incidente. Se non è scritto, alle tre di notte qualcuno decide da solo, o nessuno decide.

C'è poi il tempo delle notifiche. Per i soggetti NIS2 l'art. 25, comma 5, del D.Lgs. 138/2024 chiede una pre-notifica al CSIRT Italia entro 24 ore da quando si è venuti a conoscenza di un incidente significativo e una notifica entro 72 ore. In un modello ibrido un incidente rilevato dal fornitore di sabato notte non può restare in coda fino al lunedì: la matrice deve portarlo in tempo a chi in azienda decide sulla notifica.

La responsabilità non si co-gestisce

Dividere il lavoro non divide la responsabilità. Nel D.Lgs. 138/2024 l'art. 23 assegna agli organi di amministrazione e direttivi dei soggetti essenziali e importanti l'approvazione delle modalità di attuazione delle misure di gestione dei rischi, la sovrintendenza sulla loro attuazione e la responsabilità delle violazioni. L'art. 24, comma 2, mette tra gli elementi minimi delle misure sia la gestione degli incidenti (lettera b) sia la sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori di servizi (lettera d).

La Direttiva (UE) 2022/2555, al considerando 86, spiega perché il fornitore di sicurezza gestita conta in modo particolare: aiuta i soggetti a prevenire e rilevare gli incidenti, a rispondere e a riprendersi, ma è stato a sua volta bersaglio di attacchi e, per la sua stretta integrazione nelle attività del cliente, presenta un rischio particolare. Per questo va scelto con maggiore diligenza. NIST SP 800-61r3 aggiunge che i fornitori hanno spesso accessi privilegiati a sistemi e dati, e il rischio che vengano compromessi va considerato.

Per banche, assicurazioni e altre entità finanziarie vale DORA: l'art. 28, paragrafo 1, lettera a), stabilisce che restano sempre pienamente responsabili degli obblighi anche quando usano servizi ICT di terzi, e l'art. 30, paragrafo 1, chiede che diritti e obblighi di entità e fornitore siano attribuiti chiaramente e definiti per iscritto. Nel SOC co-gestito la RACI è il modo naturale di farlo.

Quando conviene il modello ibrido, e quando no

Il co-gestito ha senso quando c'è davvero qualcosa da tenere in casa. I segnali più comuni:

• hai una o più persone di sicurezza che conoscono bene l'ambiente, ma non abbastanza per coprire notti e weekend;
• hai già un SIEM con regole scritte negli anni e vuoi farlo presidiare, non ricominciare da capo;
• sei in un settore regolato e vuoi tenere in casa le decisioni di risposta sui sistemi critici;
• stai costruendo un team interno e ti serve copertura continua mentre cresce.

Ci sono anche casi in cui il co-gestito è la scelta sbagliata:

• nessuno internamente ha tempo per la sua parte. Le righe con A interno restano scoperte, e il modello diventa un gestito con un decisore in meno;
• non c'è reperibilità interna. Se di notte l'escalation non trova nessuno, il fornitore deve avere autorizzazioni più ampie: a quel punto è più onesto scegliere un servizio pienamente gestito;
• cerchi solo copertura notturna senza integrazione. Due squadre che non condividono registro, regole e playbook raddoppiano il lavoro senza raddoppiare la visibilità.

Sul piano economico l'ibrido non elimina il costo del personale interno: lascia al servizio la parte più cara da costruire, la rotazione 24/7. Le voci del canone sono in quanto costa un SOC gestito.

Le domande da fare prima di partire

Oltre alle verifiche valide per qualunque fornitore, che trovi in come scegliere un MSSP in Italia e in cosa include un servizio SOC gestito, un modello co-gestito chiede risposte su punti suoi:

1. Su quale piattaforma lavoreremo entrambi, e di chi è l'istanza?
2. Con quali ruoli accede il mio team, e può modificare le regole di rilevamento?
3. Le regole scritte sul mio ambiente restano a me se il contratto finisce?
4. Usiamo un solo registro degli incidenti, e come si passano le consegne a fine turno?
5. Quali azioni di contenimento fate senza chiedere, e quali richiedono una persona mia?
6. Chi mi chiama di notte per un incidente che potrebbe richiedere la pre-notifica, ed entro quanto?

Se le risposte arrivano come documento e non come rassicurazione, la divisione dei compiti esiste già prima di firmare.

Se stai valutando un modello ibrido per il tuo team, la pagina sulla cybersecurity gestita di AmagisTech descrive il SOC 24/7 che operiamo dall'Italia su Google SecOps, e da lì puoi chiedere un assessment del tuo perimetro e di come dividere i compiti con le persone che hai già.