Contenere o investigare? La decisione più difficile per rispondere ad un incidente

C’è un momento, durante un incidente o un attacco hacker, in cui il SOC Manager si trova davanti a una scelta senza risposta ovvia: isolare subito e bloccare l’attacco — perdendo forse la possibilità di capire fino in fondo cosa è successo — oppure continuare a osservare per raccogliere più evidenze, sapendo che ogni minuto in più aumenta il rischio di danni. Questa decisione non si prende mai con certezza completa. Si prende con le informazioni disponibili, sotto pressione, con il business che aspetta.

Perché questa è la decisione più difficile

Il ciclo standard di risposta ad un problema — preparazione, identificazione, contenimento, eradicazione, recovery, apprendimento — sembra lineare sulla carta. Nella pratica, il confine tra identificazione e contenimento è il punto in cui la pressione è più alta e le informazioni sono più incomplete.

Contenere troppo presto significa rischiare di tagliare la visibilità sull’attacco prima di capire l’estensione reale della compromissione. Se l’attacco ha già stabilito più punti di accesso o si è mosso lateralmente, isolare un singolo endpoint senza capire l’intera catena di attacco non risolve il problema: dà solo la falsa impressione di averlo risolto.

Contenere troppo tardi significa accettare che l’attacco continui a operare nell’ambiente — espandendo la propria presenza, esfiltrando dati, cifrando sistemi — mentre il team raccoglie evidenze. Ogni minuto di "dwell time" ha un costo reale.

I fattori che guidano la decisione

Non esiste una formula universale, ma i fattori che un SOC Manager valuta in questa fase sono prevedibili.

Tipologia di minaccia. Un ransomware che ha iniziato la fase di cifratura richiede contenimento immediato senza eccezioni. Un attaccante che sembra ancora in fase di ricognizione o movimento laterale silenzioso può giustificare qualche minuto di osservazione aggiuntiva. La mappatura su MITRE ATT&CK aiuta: sapere in quale fase della kill chain si trova l’attaccante orienta la decisione su quanto tempo si ha prima che il danno diventi irreversibile.

Visibilità attuale. Quante informazioni ha già il team? Se gli analisti hanno già ricostruito il vettore di accesso iniziale, i movimenti laterali e i sistemi compromessi, il valore marginale di ulteriore osservazione è basso. Se l’estensione della compromissione è ancora poco chiara, l’isolamento prematuro può chiudere una finestra informativa preziosa.

Impatto sul business. Il sistema coinvolto è business-critical? C’è un SLA verso il cliente che si sta avvicinando alla soglia di violazione? La risposta a questa domanda viene da chi conosce l’architettura e il contesto operativo del cliente — non sempre il SOC Manager ha questa informazione immediatamente disponibile, e ottenerla fa parte della gestione dell’incidente.

Vincoli legali e regolatori. In alcuni settori e per alcune tipologie di dati, la notifica agli enti competenti deve avvenire entro finestre temporali precise. NIS2 e GDPR impongono obblighi specifici che il SOC Manager deve avere già mappato nei propri playbook.

Elaborazione su NIST SP 800-61r3, SANS Incident Response Framework, SentinelOne, 2025

Come il contenimento viene eseguito

Quando la decisione è contenere, le tecnologie del SOC permettono azioni precise: isolare un endpoint via EDR senza spegnerlo fisicamente, segmentare la rete per bloccare il movimento laterale, bloccare account compromessi, mettere in quarantena i sistemi sospetti. Il principio è contenere con il minimo impatto possibile sulle operazioni business mentre si impedisce l’espansione della minaccia (SANS, 2025).

Ogni azione di contenimento deve essere documentata e questa documentazione è la base del post-incident review e, in caso di obblighi di notifica, anche della reportistica regolamentare.

Il SANS framework raccomanda di completare il contenimento a breve termine prima di passare al contenimento a lungo termine: prima bloccare la propagazione immediata, poi lavorare alla bonifica completa. La distinzione è importante perché permette di ripristinare le operazioni business critiche prima che l’ambiente sia completamente pulito.

Decidere bene significa averlo già deciso

I SOC Manager più efficaci non improvvisano questa scelta nel momento dell’incidente. La definiscono prima, nei playbook: per ogni scenario di minaccia rilevante, la soglia di contenimento è già stabilita. Cosa costituisce un trigger di contenimento immediato? Chi ha l’autorità di prendere la decisione? Chi deve essere informato prima che venga eseguita?

Avere questa struttura definita non elimina il giudizio situazionale — ogni incidente ha le sue specificità — ma riduce il carico cognitivo nel momento in cui il tempo conta di più. Come indicato dal NIST SP 800-61r3 (aggiornato ad aprile 2025), i tradeoff tra contenimento immediato e continuità operativa devono essere risolti nei playbook prima che l’incidente forzi una decisione improvvisata.

FAQ

Quando va presa la decisione di contenimento durante un incidente?

Non esiste un momento fisso: dipende dalla tipologia di minaccia, dalla visibilità disponibile e dall’impatto sul business. Ransomware in fase di cifratura richiede contenimento immediato. Un attaccante in fase di ricognizione può giustificare qualche minuto di osservazione aggiuntiva per capire l’estensione della compromissione prima di agire.

Isolare un sistema significa perdere evidenze forensi?

Non necessariamente. I moderni strumenti EDR permettono di isolare un endpoint dalla rete mantenendolo acceso e analizzabile. La perdita di evidenze avviene principalmente se il sistema viene spento fisicamente o ripristinato senza acquisizione preliminare. La documentazione dell’azione di contenimento fa parte del processo di gestione dell’evidenza.

Chi decide il contenimento in un SOC erogato in logica managed?

La struttura decisionale deve essere definita contrattualmente e nei playbook di servizio. In genere il SOC Manager ha l’autorità operativa per le azioni di contenimento standard, ma per azioni ad alto impatto sul business — isolare sistemi critici, interrompere servizi — è necessaria l’autorizzazione del referente cliente. Questa catena deve essere stabilita prima dell’incidente.

Come si comunica la decisione di contenimento al cliente?

In modo rapido e diretto: cosa si sta per fare, perché, quale impatto operativo avrà e in quanto tempo si prevede il ripristino. Il cliente ha il diritto di conoscere le azioni che impattano i propri sistemi prima che vengano eseguite, salvo nei casi in cui il ritardo aumenterebbe in modo significativo il danno.

Cosa si fa dopo il contenimento?

Dopo il contenimento si passa all’eradicazione — rimozione della presenza dell’attaccante dall’ambiente — e poi alla recovery. Il post-incident review viene condotto successivamente per identificare le cause radice, le lacune nei processi e le azioni correttive per ridurre la probabilità di recidiva. Questo ciclo è definito dal NIST SP 800-61r3 come parte integrante del processo di incident response.

Potrebbe interessarti anche

• CYBERSECURITY DIRECTOR
• HEAD OF CYBERSECURITY
• SECURITY OPERATIONS CENTER MANAGER 
• SOC MANAGER 
• Come un Cyber Security Manager riesce a coordinare un team eterogeneo su più sedi
• Cybersecurity Director: ruolo, responsabilità e competenze
• Cybersecurity: quali aree un profilo Senior deve presidiare?
• Palo Alto, Fortinet, Cisco: come orientarsi in questo ambito
• Tecnica e commerciale: come un Cybersecurity Manager gestisce questi 2 domini
• Come il SOC Manager comunica un incidente al Chief Information Security Officer senza perdere credibilità