Onboarding SOC gestito: le fasi e cosa preparare

L'onboarding di un SOC gestito è il progetto che porta dalla firma del contratto al servizio a regime. Passa da sei fasi: kickoff e perimetro, inventario di asset e fonti di log, collegamento al SIEM, tuning e baseline, playbook ed escalation, primo report. Dal cliente servono accessi, un referente con autorità e informazioni aggiornate sul proprio ambiente.

Questa guida segue l'onboarding fase per fase: cosa succede, cosa ti viene chiesto, cosa conviene verificare prima di dire che il servizio è partito. Cosa deve contenere il contratto è spiegato in servizio SOC gestito: cosa include; qui si guarda come quel contratto diventa operativo.

Perché l'onboarding decide la qualità del servizio

Un SOC vede solo quello che gli arriva e capisce solo quello che gli è stato spiegato. Se una fonte di log non è collegata, quel sistema non è sorvegliato. Se le regole di rilevamento non conoscono il tuo ambiente, producono rumore. Se nessuno ha deciso chi chiamare alle due di notte, l'incidente aspetta.

Sono tutte cose che si fissano nelle prime settimane. Dopo, correggerle costa di più, perché nel frattempo il servizio lavora su basi incomplete senza che nessuno se ne accorga.

Le sei fasi dell'onboarding

1. Kickoff e perimetro

Il primo incontro serve a mettere d'accordo le persone, non le macchine. Si fissano:

• i referenti dalle due parti: chi decide, chi fornisce gli accessi tecnici, chi va chiamato durante un incidente;
• il perimetro: quali sedi, ambienti, account cloud e sistemi critici entrano nel servizio, e cosa resta fuori in modo esplicito;
• le priorità: quali processi di business non possono fermarsi, quali dati sono più sensibili, quali obblighi normativi pesano (NIS2, DORA, ISO/IEC 27001);
• il piano: le fasi successive con responsabili e date, e i criteri con cui si dichiarerà chiuso l'onboarding.

Un kickoff che finisce senza un piano scritto è il primo segnale da non ignorare.

2. Inventario degli asset e delle fonti di log

Prima di collegare qualcosa bisogna sapere cosa c'è. L'inventario elenca endpoint, server, identità, servizi cloud, apparati di rete, posta e applicazioni, e per ognuno indica quali log produce e dove finiscono oggi.

Non è burocrazia. La guida NIST SP 800-61r3 sull'incident response (aprile 2025) osserva, alla voce ID.AM (Asset Management), che le informazioni sugli asset aiutano chi risponde a un incidente a capirne l'impatto, a individuare gli altri sistemi che potrebbero essere colpiti e a decidere le priorità di risposta e ripristino. Un SOC che non conosce il valore di un server non sa quanto in fretta muoversi quando quel server si comporta in modo strano.

Il risultato utile di questa fase è una mappa: le fonti da collegare subito, quelle da collegare dopo e quelle che mancano del tutto. Spesso l'inventario fa emergere sistemi che nessuno ricordava, ed è un risultato in sé.

3. Collegamento al SIEM

Qui le fonti iniziano a inviare dati alla piattaforma di analisi. Se ti serve un ripasso su cosa fa questa piattaforma, c'è la guida a cos'è un SIEM e come funziona. NIST SP 800-61r3 raccomanda, alla voce DE.AE-03 (correlazione delle informazioni da più fonti), di trasferire con continuità i log verso un numero ridotto di server di raccolta e di usare strumenti di correlazione come SIEM e SOAR per mettere insieme dati collegati che arrivano da fonti diverse.

Collegare una fonte non vuol dire solo farla arrivare. I log devono essere letti e tradotti in un formato comune, altrimenti le regole non li riconoscono. Su Google SecOps, per esempio, questo lavoro lo fanno i parser: la documentazione di Google descrive parser predefiniti che leggono i log grezzi e generano record strutturati nel formato UDM (Unified Data Model), e la possibilità di creare parser specifici per un cliente quando una fonte non è coperta da quelli standard.

Le verifiche di questa fase sono tre:

1. la fonte invia dati con continuità, non a strappi;
2. i campi importanti (utente, host, indirizzo, azione) vengono letti correttamente;
3. esiste un controllo che segnala quando una fonte smette di inviare. Una fonte silenziosa non genera allarmi, genera un punto cieco.

4. Tuning e baseline

Appena le fonti sono collegate, le regole di rilevamento iniziano a produrre segnalazioni, e all'inizio sono troppe. È normale: le regole non conoscono ancora il tuo ambiente. Il job di backup notturno sembra un'esfiltrazione, lo scanner di vulnerabilità sembra una ricognizione, l'amministratore che lavora da casa sembra un accesso anomalo.

Il tuning serve a insegnare al SOC cosa è normale da te. NIST SP 800-61r3 lo scrive in modo esplicito alla voce DE.CM (Continuous Monitoring): calibrare le tecnologie di monitoraggio per riportare falsi positivi e falsi negativi a livelli accettabili. Le due direzioni contano entrambe: alzare tutte le soglie per far tacere il rumore spegne anche detection che servivano.

In pratica si costruisce una baseline del comportamento atteso (orari, account di servizio, flussi di rete, strumenti amministrativi), si aggiungono eccezioni motivate e documentate, si adattano le regole ai sistemi critici. Se il rumore non scende, il problema diventa strutturale: la guida all'alert fatigue nel SOC spiega da dove nasce e come si riduce.

5. Playbook, escalation e autorizzazioni di risposta

Questa è la fase che decide cosa succede durante un incidente vero. NIST SP 800-61r3 descrive i playbook come procedure con passi concreti da seguire in scenari specifici, e suggerisce di documentare la risposta almeno per i tipi di incidente più comuni. Per un SOC gestito si traducono in tre decisioni da prendere insieme:

• la matrice di escalation: chi viene chiamato, in che ordine, con quale canale, per quale livello di gravità, anche di notte e nei festivi. NIST distingue tra escalation, che aumenta risorse o tempi dedicati, ed elevation, che coinvolge un livello più alto del management: conviene prevedere entrambe;
• le autorizzazioni di risposta: quali azioni il SOC può fare senza chiederti (isolare un endpoint, sospendere un account, bloccare un indirizzo) e quali richiedono il tuo via libera. Sui sistemi di produzione la risposta prudente è spesso diversa da quella sugli endpoint;
• il raccordo con la notifica: 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 con una valutazione iniziale e, ove disponibili, gli indicatori di compromissione. L'obbligo resta in capo al soggetto, ma le informazioni le produce in buona parte il SOC: il playbook deve dire cosa ti consegna e quando.

Le autorizzazioni di risposta meritano una riunione a sé. Sono la differenza tra un attacco contenuto alle tre di notte e un attacco descritto in un report la mattina dopo.

6. Primo report e chiusura dell'onboarding

L'onboarding si chiude con un documento, non con una sensazione. Il primo report dovrebbe dire:

• quali fonti sono collegate e quali mancano ancora, con il motivo;
• quali regole sono attive e quali eccezioni sono state introdotte durante il tuning;
• cosa è emerso nelle prime settimane: segnalazioni gestite, configurazioni deboli, sistemi non inventariati;
• i passi successivi, con responsabili e date.

Da quel momento il servizio passa a regime, con i report periodici e le revisioni previste dal contratto.

Cosa deve preparare il cliente

La parte del cliente pesa sui tempi quanto quella del fornitore. Conviene arrivare al kickoff con:

1. un referente tecnico e un referente decisionale, con tempo dedicato nelle prime settimane;
2. un inventario anche parziale di sistemi, account cloud, apparati di rete e applicazioni critiche;
3. gli accessi amministrativi necessari a configurare l'invio dei log, già approvati dalla sicurezza interna e dai fornitori che gestiscono i sistemi;
4. l'elenco dei fornitori terzi che hanno accesso ai tuoi sistemi, perché la loro attività va riconosciuta come normale o segnalata;
5. le finestre di manutenzione e i processi notturni, che altrimenti finiscono tra i falsi positivi;
6. i contatti reperibili per l'escalation, con numeri verificati e un sostituto per ogni ruolo;
7. le procedure interne già esistenti: piano di risposta agli incidenti, procedura di notifica, policy di backup.

Da cosa dipendono i tempi

Non esiste una durata standard di un onboarding: una stima affidabile si fa dopo aver visto il tuo ambiente. I fattori che la spostano sono pochi e riconoscibili:

• numero e varietà delle fonti: dieci sorgenti con connettori standard sono un altro progetto rispetto a cinquanta, con applicazioni sviluppate in casa;
• fonti senza parser pronto: ogni formato non coperto richiede lavoro di mappatura;
• disponibilità del cliente: accessi, approvazioni e risposte alle domande del tuning sono spesso il collo di bottiglia;
• stato dell'inventario: se va costruito da zero, l'onboarding include anche quel lavoro;
• ambienti particolari, come reti OT o sistemi che non si possono toccare in orario di produzione;
• eventuale migrazione da un SIEM o da un fornitore precedente, con storico da conservare e regole da riportare.

Un buon fornitore ti consegna un piano con queste variabili esplicite, non un numero di settimane uguale per tutti.

Segnali che l'onboarding è fatto bene

• Hai un piano scritto con fasi, responsabili, date e criteri di chiusura.
• Puoi vedere l'elenco delle fonti collegate e lo stato di ognuna, e vieni avvisato quando una smette di inviare.
• Il SOC ti ha fatto domande sul tuo ambiente durante il tuning: orari, account di servizio, eccezioni. Un tuning senza domande è un tuning fatto sui default.
• Il volume di segnalazioni scende nel tempo e le eccezioni introdotte sono documentate e motivate.
• La matrice di escalation è stata provata almeno una volta, con una chiamata vera fuori orario.
• Le autorizzazioni di risposta sono scritte e firmate da chi ha l'autorità per concederle.
• Il primo report dice anche cosa manca, non solo cosa funziona.

Al contrario, un onboarding dichiarato concluso con fonti mancanti non elencate, regole mai adattate o contatti di escalation non verificati è un servizio che parte con punti ciechi. Se stai ancora scegliendo il fornitore, queste domande valgono già in fase di gara: la guida su come scegliere un MSSP in Italia le mette in ordine. E se stai ancora decidendo se affidare il presidio all'esterno, il confronto tra SOC interno e gestito parte da qui.

Se vuoi vedere come impostiamo l'onboarding sul tuo ambiente, la pagina sulla cybersecurity gestita di AmagisTech descrive il SOC gestito 24/7 dall'Italia su Google SecOps, e da lì puoi chiedere una valutazione del tuo perimetro.