Come si costruisce un Piano di Risposta agli Incidenti che funziona?

La maggior parte delle organizzazioni non fallisce nella risposta agli incidenti perché mancano di strumenti. Falliscono perché nessuno ha concordato in anticipo chi fa cosa, e il primo incidente reale diventa una riunione invece che una risposta.

Inizia dalle fasi, non dal playbook

NIST SP 800-61 stabilisce quattro fasi: preparazione, rilevamento e analisi, contenimento/eradicazione/ripristino, e attività post-incidente. Quell'ordine conta. I team amano saltare direttamente al contenimento perché sembra produttivo, ma se non hai completato il lavoro di preparazione, non conosci la tua rete abbastanza bene per contenere nulla in modo pulito.

La preparazione significa inventari di asset realmente attuali, non il foglio di calcolo del 2022. Significa conoscere la finestra di conservazione dei log (se è 7 giorni e l'attaccante ha avuto 30 giorni di tempo di permanenza, hai già perso la cronologia). Significa strumenti forensici pre-allocati — Velociraptor, KAPE, o anche una procedura tar/dd documentata per le immagini disco — così nessuno scarica strumenti su un host compromesso durante un incidente attivo.

Definisci i livelli di gravità prima che ti servano

Un SEV1 (esfiltrazione attiva di dati, detonazione di ransomware, compromesso di domain admin) ha bisogno di una risposta diversa da un SEV3 (malware isolato su una singola workstation senza privilegi). Scrivi questo come una matrice: impatto vs. ambito vs. confidenza. Assegna a ogni gravità un tempo di risposta richiesto e un percorso di escalation. Se il tuo incident commander per un SEV1 è la stessa persona che deve approvare ogni ordine di acquisto da 500 dollari, hai costruito un collo di bottiglia nel tuo stesso processo di emergenza.

Il ruolo dell'incident commander non è opzionale

Una persona gestisce l'incidente. Non l'ingegnere più senior per impostazione predefinita — la persona più adatta a coordinare, delegare e prendere decisioni di contenimento sotto pressione. Questa persona non necessariamente tocca una tastiera durante la risposta; traccia la cronologia, gestisce la comunicazione con l'ufficio legale e la dirigenza, e decide quando attivare l'isolamento di un segmento o portare un sistema offline.

Senza questo ruolo, finisci con cinque persone in SSH sulla stessa macchina, nessuna di loro che parla con l'altra, e nessuno che cattura la memoria volatile prima che qualcuno riavvii la macchina per "vedere se lo risolve".

Decisioni di contenimento che contano davvero

La chiamata più difficile nella maggior parte degli incidenti è: isolare ora, o osservare un po' più a lungo per capire l'ambito? Tagliare l'accesso di rete troppo presto avverte un attaccante ancora in movimento laterale e distrugge la tua possibilità di vedere la sua prossima mossa. Aspettare troppo a lungo lascia che il ransomware finisca di cifrare le condivisioni.

Una via di mezzo ragionevole: usare la segmentazione di rete e l'isolamento EDR (CrowdStrike, Defender for Endpoint, SentinelOne supportano tutti questo) per tagliare un host dal movimento laterale mantenendolo acceso per la cattura della memoria. Lo spegnimento completo dovrebbe essere l'ultima risorsa — uccide la prova volatile e, per i casi di ransomware, può attivare comportamenti anti-forensici incorporati in alcuni payload.

Lacune di logging che rimpiancerai durante, non prima

I default di Windows Event Log non sono sufficienti. Se non hai Sysmon distribuito con una configurazione decente (le configurazioni baseline di SwiftOnSecurity o di Olaf Hartong sono un buon punto di partenza), dovrai ricostruire gli alberi di processo da frammenti. Dal lato della rete, i log NetFlow o Zeek contano più di quanto la maggior parte delle organizzazioni realizzi finché non hanno bisogno di rispondere