Playbook e gestione dei ticket

Un playbook (o runbook) è una procedura documentata e articolata in passaggi per gestire un tipo specifico di alert o incidente. I playbook rendono la risposta coerente, rapida e verificabile tramite audit.

Senza playbook, due analisti potrebbero gestire lo stesso alert di phishing in modi completamente diversi. Con i playbook, la qualità della risposta non dipende da chi è di turno.

Un buon playbook ha una struttura prevedibile, così che gli analisti possano seguirla anche sotto pressione:

• Trigger — quale alert o condizione attiva questo playbook
• Ambito — che cosa comprende e che cosa esclude
• Passaggi — azioni ordinate di analisi e risposta
• Punti decisionali — logica di diramazione per risultati diversi
• Criteri di escalation — quando trasferire la gestione
• Condizioni di chiusura — quando il caso è concluso

Consideri un'e-mail di phishing segnalata. Un playbook tipico definisce passaggi chiari:

Gli incidenti reali non seguono un percorso lineare. I playbook includono punti decisionali che creano diramazioni in base a ciò che si rileva.

Ad esempio, nel playbook per il phishing:

• Qualcuno ha fatto clic sul link? Se no, contenga l'incidente e lo chiuda. Se sì, passi alla gestione della compromissione delle credenziali.
• Sono state inserite credenziali? Se sì, imponga la reimpostazione della password e verifichi la presenza di accessi sospetti.

Le diramazioni mantengono il playbook proporzionato: poco lavoro per le segnalazioni innocue, una risposta completa in caso di compromissione reale.

Un sistema di ticketing (gestione dei casi) è il sistema di riferimento per ogni alert e incidente. Ogni caso è un ticket che documenta l'intera indagine.

Tra le piattaforme più comuni vi sono il case manager SOAR, ServiceNow, Jira o uno strumento IR dedicato. Nel ticket vengono registrate evidenze, cronologia e decisioni, così nulla dipende dalla memoria o dai messaggi in chat.

Un ticket utile raccoglie tutte le informazioni necessarie per comprendere e sottoporre a verifica un caso:

• Titolo — conciso e specifico
• Gravità e stato
• Asset e utenti interessati
• Cronologia delle fasi dell'indagine con indicazione degli orari
• Evidenze e IOC
• Esito e azioni intraprese

Scriva il ticket come se dovesse leggerlo uno sconosciuto durante un audit tra un anno, perché potrebbe accadere.

Campi coerenti di stato e gravità rendono gestibili le code e danno significato alle metriche.

Quando un incidente può portare a un'azione legale o al coinvolgimento delle risorse umane, la gestione delle evidenze è importante. La catena di custodia documenta chi ha raccolto ogni elemento di prova, quando lo ha fatto e come è stato conservato.

I ticket la supportano registrando:

• L'ora e la fonte esatte di ogni artefatto
• L'analista che lo ha raccolto
• Gli hash che dimostrano che l'evidenza non è stata alterata

Una gestione negligente delle evidenze può rendere i risultati non ammissibili o contestabili.

I ticket applicano gli accordi sul livello di servizio (SLA), che definiscono in base alla gravità entro quanto tempo gli alert devono essere presi in carico e risolti.

Esempi di obiettivi SLA:

• SEV1: presa in carico entro 15 minuti
• SEV2: presa in carico entro 1 ora
• SEV3: risposta entro 4 ore

Le indicazioni temporali nel ticket alimentano le metriche che mostrano se il SOC sta rispettando questi impegni.

I playbook diventano obsoleti se non vengono mantenuti. Gli strumenti cambiano, gli attaccanti si evolvono e le procedure diventano obsolete. Consideri i playbook documenti in continua evoluzione.

Li aggiorni quando:

• Viene aggiunto un nuovo strumento o una nuova fonte di dati
• Una revisione post-incidente rivela una lacuna
• Compare una nuova tecnica di attacco
• Un analista individua un passaggio poco chiaro o errato

Gestisca i playbook con il controllo versione e li riveda secondo una pianificazione.

Molti passaggi dei playbook sono meccanici e si prestano perfettamente all'automazione SOAR. Automatizzarli lascia agli analisti più tempo per le attività che richiedono valutazione.

Passaggi comunemente automatizzati:

• Recupero dell'email originale ed estrazione degli IOC
• Esecuzione di verifiche della reputazione
• Eliminazione delle email malevole da tutte le caselle di posta
• Aggiornamento del ticket con i risultati

L'analista continua a prendere le decisioni fondamentali; l'automazione esegue semplicemente le parti di routine in modo più rapido e coerente.

Ha imparato come i playbook e il ticketing strutturano il lavoro del SOC:

• I playbook forniscono passaggi coerenti e ripetibili, con punti decisionali e criteri di escalation
• Il sistema di ticketing è il sistema di riferimento per ogni caso
• I buoni ticket raccolgono cronologia, evidenze, IOC ed esito e supportano la catena di custodia
• Gli SLA stabiliscono obiettivi sui tempi di risposta, tracciati dagli orari dei ticket
• Mantenga aggiornati i playbook e automatizzi con SOAR i loro passaggi meccanici

Ora misurerà le prestazioni del SOC usando MTTD e MTTR.