Playbook SOC: cosa contiene, con 3 esempi pratici

La risposta breve: un playbook SOC è la procedura scritta che dice al team cosa fare davanti a un tipo preciso di incidente. Ha cinque parti: il trigger che lo attiva, il triage che conferma e dà una priorità, il contenimento, l'escalation con le notifiche e la chiusura con il rapporto finale. Si scrive prima per gli incidenti più frequenti: phishing, credenziali compromesse, ransomware.

Procedure e playbook: che differenza c'è

La guida di riferimento è la NIST SP 800-61 Rev. 3 (aprile 2025), che sostituisce la Rev. 2 del 2012. Nella sezione 2.3 distingue tre livelli. La policy stabilisce ruoli, autorità, criteri di priorità e misure di performance. Le procedure discendono dalla policy e dal piano, e spiegano come si eseguono i processi tecnici. I playbook sono un modo di scrivere le procedure, che secondo NIST può renderle più facili da usare. La definizione, nel testo originale: "Playbooks provide actionable steps or tasks for people to perform during various scenarios or situations."

In pratica: la policy dice chi può spegnere un server, il playbook dice in quale situazione lo si spegne, in che ordine e chi va avvisato subito dopo. Senza playbook il SOC dipende dalla memoria dell'analista di turno, e alle tre di notte è la risorsa meno affidabile che hai.

Sulle priorità NIST è pragmatico: una procedura per ogni situazione possibile non è realistica, quindi si documenta la risposta ai tipi di incidente e minaccia più comuni, più i processi critici che potrebbero servire in emergenza, come rimettere in piedi la piattaforma di autenticazione principale.

Cosa c'è in un playbook SOC: le cinque parti

Le cinque parti seguono le funzioni Detect, Respond e Recover del NIST Cybersecurity Framework 2.0, su cui la Rev. 3 organizza la risposta agli incidenti. Tra parentesi trovi la voce della guida, per ritrovarla nel documento.

1. Trigger: cosa attiva il playbook

È la condizione che fa partire la procedura: una regola di detection del SIEM, un alert dell'EDR, la segnalazione di un dipendente, una comunicazione esterna. Va scritto in modo che non ci siano dubbi su quale playbook si apre, e se due possono partire dallo stesso alert va detto quale ha la precedenza. Le segnalazioni esterne contano: NIST raccomanda canali con cui terze parti possano segnalare un possibile incidente, e di prenderle sul serio (RS.MA-02).

2. Triage: è un incidente, e quanto è grave?

Il triage risponde a tre domande: è successo davvero, quanto è grave, quanto è urgente. NIST chiede una prima revisione per verificare l'incidente e stimarne gravità e urgenza (RS.MA-02), poi una più approfondita per classificarlo per tipo (data breach, ransomware, account takeover, denial of service) e decidere la velocità di risposta in base a perimetro, impatto probabile, urgenza e risorse disponibili (RS.MA-03).

Il playbook scrive i criteri, non li lascia all'istinto. Con risorse limitate, osserva NIST, gli incidenti non si gestiscono in ordine di arrivo, e triage, priorità ed escalation vanno basati su fattori di rischio (RS.MA). In concreto: criticità dell'asset, privilegi dell'utente, dati coinvolti, segni di movimento laterale, e quale livello di gravità corrisponde a quale combinazione.

3. Contenimento: fermare l'espansione

Il contenimento impedisce all'incidente di allargarsi (RS.MI-01). Scegliere le azioni è più facile e veloce se criteri e procedure esistono già, e i criteri possono tenere conto del tipo di incidente e della durata della misura: un intervento d'emergenza da togliere in poche ore non è uno temporaneo da togliere in due settimane (RS.MI).

Il playbook scrive le azioni e chi le autorizza: isolare un endpoint, disabilitare un account, bloccare un dominio, mettere in quarantena un allegato. NIST suggerisce di far eseguire alcune azioni agli strumenti senza intervento umano, come la quarantena di un malware o lo spostamento di un endpoint compromesso su una rete isolata, lasciando sempre a chi gestisce l'incidente la possibilità di agire a mano (RS.MI-01).

Una cautela viene dai playbook federali della CISA (novembre 2021): alcuni attaccanti osservano le contromosse e cambiano metodo, quindi prima di agire conviene avere il quadro più completo possibile. Il dilemma è reale, perché ogni minuto speso a mappare l'attaccante è un minuto in cui resta dentro: il playbook dice chi decide quando fermarsi.

4. Escalation: a chi passa il caso, e quando

NIST distingue due movimenti (RS.MA-04): l'escalation aumenta risorse o tempi dedicati all'incidente, l'elevation porta la decisione a un livello più alto di management. Il playbook li scrive entrambi: quando il primo livello passa al secondo, quando entra il fornitore di incident response, quando si informa la direzione. NIST suggerisce anche di nominare un incident lead per ogni incidente (RS.MA-01): una persona, non un gruppo.

Qui il playbook incontra la legge. Per i soggetti NIS2, l'art. 25 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, una notifica entro 72 ore e una relazione finale entro un mese dalla notifica. Il playbook dice chi valuta se l'incidente è significativo e da quando corre l'orologio. Il dettaglio è nella guida alla notifica degli incidenti NIS2.

5. Chiusura: rapporto e lezioni apprese

Un incidente non è chiuso quando l'alert sparisce. NIST chiede di controllare che i sistemi ripristinati non abbiano indicatori di compromissione e che la causa sia rimossa prima di rimetterli in produzione (RC.RP-05), e di preparare un rapporto che documenti l'incidente, le azioni di risposta e ripristino e le lezioni apprese (RC.RP-06). I dati raccolti sono prove anche quando non si arriva in tribunale, e si conservano secondo le procedure dell'organizzazione (RS.AN-07). Le lezioni apprese tornano nella categoria Improvement (ID.IM): una regola da correggere, un passo del playbook da riscrivere.

Tre esempi concreti

Sono schemi di partenza, non procedure da copiare: i passi si adattano agli strumenti e alle autorizzazioni del tuo ambiente.

Playbook phishing

• Trigger: segnalazione di un dipendente dal pulsante della posta, o alert del filtro email su un messaggio già consegnato.
• Triage: mittente, intestazioni, link e allegati; ricerca dello stesso messaggio nelle altre caselle; chi ha cliccato, inserito credenziali o aperto l'allegato. Se qualcuno ha inserito la password, si apre il playbook credenziali compromesse.
• Contenimento: rimozione del messaggio da tutte le caselle, blocco di dominio e URL, quarantena dell'allegato sugli endpoint che l'hanno scaricato.
• Escalation: al secondo livello se c'è stata esecuzione di codice o furto di credenziali; alla direzione se il messaggio imitava un fornitore o chiedeva un pagamento.
• Chiusura: indicatori aggiunti alle regole, risposta a chi ha segnalato, numeri utili per la formazione.

Playbook credenziali compromesse

• Trigger: accesso da paese o dispositivo mai visti, accessi impossibili per distanza e tempo, raffica di richieste MFA, credenziali aziendali in un leak.
• Triage: chi è l'utente e che privilegi ha; cosa ha fatto la sessione sospetta (regole di inoltro, download, nuove app autorizzate, modifiche ai fattori MFA); se lo stesso IP compare su altri account.
• Contenimento: revoca di sessioni e token, reset della password, nuova registrazione MFA, rimozione delle regole di inoltro create dall'attaccante. NIST cita la disabilitazione degli account violati tra le azioni di eradicazione (RS.MI-02).
• Escalation: immediata se l'account è amministrativo o se ci sono accessi a dati personali, che aprono anche la valutazione GDPR.
• Chiusura: si corregge la via d'ingresso (phishing, password riusata, dispositivo infetto), non solo l'account.

Playbook ransomware

La base pubblica più usata è la checklist del #StopRansomware Guide (CISA, FBI, NSA e MS-ISAC, ottobre 2023), che chiede di eseguire i primi tre passi in sequenza.

• Trigger: cifratura di massa di file, cancellazione delle copie shadow, nota di riscatto, uso anomalo di strumenti come vssadmin o wbadmin.
• Contenimento, per primo: individuare i sistemi colpiti e isolarli subito; se sono molti, staccare la rete a livello di switch. Spegnere i dispositivi solo se non si riesce a scollegarli, perché si perdono le evidenze in memoria. Coordinarsi su canali fuori banda, come il telefono, per non avvisare l'attaccante.
• Triage per il ripristino: ordinare i sistemi secondo una lista di asset critici preparata prima, non durante.
• Analisi: cercare il malware di accesso iniziale che spesso precede il ransomware prima di ripristinare dai backup, e controllare i backup stessi per indicatori di compromissione (NIST, RC.RP-03).
• Escalation: direzione, legale, fornitore di incident response e, per i soggetti NIS2, l'orologio delle 24 ore. La guida sconsiglia di pagare: il pagamento non garantisce la decifratura né che i dati non vengano pubblicati.

Se l'incidente supera le forze del SOC quotidiano, il playbook dice come si attiva il supporto esterno, che è il ruolo di un incident response retainer.

Playbook su carta e playbook in una piattaforma SOAR

Un playbook può vivere in un documento o in una piattaforma SOAR che ne esegue una parte. Nella documentazione di Google Security Operations un playbook è costruito su tre elementi: un trigger obbligatorio che lo avvia, le azioni che esegue e un flusso con condizioni if-then-else che sceglie il passo successivo in base al risultato dei precedenti. È la struttura delle cinque parti, tradotta in passi eseguibili.

La scelta vera è quali passi lasciare alla macchina. Arricchire un alert, cercare lo stesso messaggio in tutte le caselle, aprire e assegnare il caso sono passi ripetitivi e a basso rischio. Isolare il server di produzione o disabilitare l'account del direttore finanziario conviene farli passare da un'approvazione. Togliere lavoro ripetitivo agli analisti è anche la leva principale contro l'alert fatigue.

Gli errori che rendono inutile un playbook

• Troppo generico. Un playbook unico per ogni incidente di sicurezza non aiuta nessuno: servono playbook per tipo.
• Mai provato. NIST ricorda che le procedure si possono testare o esercitare periodicamente, per verificarne l'accuratezza e formare chi arriva (sezione 2.3). Un playbook mai provato contiene quasi sempre un numero sbagliato o un'autorizzazione che nessuno ha.
• Senza responsabile. Ogni playbook ha un proprietario e una data di revisione, e cambia quando cambiano strumenti e persone.
• Non allineato al contratto. Se il SOC è esterno, NIST chiede di definire nel contratto le responsabilità del fornitore, la sua autorità di agire per conto dell'organizzazione e i limiti, per esempio sulle decisioni operative come disattivare subito un servizio per contenere un incidente (sezione 2.2). Cosa chiedere lo trovi in cosa include un servizio SOC gestito.
• Solo tecnico. Il playbook che si ferma al contenimento dimentica comunicazione, notifiche e rapporto finale, le parti da cui dipende la documentazione dell'incidente.

Da dove partire

Si parte da tre o quattro playbook scelti fra gli incidenti che il SOC vede più spesso nel vostro ambiente: phishing, credenziali compromesse, ransomware e malware su endpoint sono il punto di partenza abituale. Per ciascuno si scrivono le cinque parti, si prova con un'esercitazione a tavolino e si corregge quello che non ha funzionato. Se manca il quadro generale, il punto di ingresso è cos'è un SOC e cosa fa.

Nel nostro SOC gestito su Google SecOps i playbook di risposta si concordano con il cliente durante l'onboarding, insieme alle autorizzazioni per il contenimento. Se vuoi capire come si applicherebbero al tuo ambiente, i dettagli sono nella pagina SOC gestito e MDR.