Incident response negli ambienti OT: le differenze critiche rispetto all'IT

Perché l'IR dell'IT non funziona nell'OT

Il primo istinto di un team di incident response IT di fronte a un sistema compromesso è isolare: staccare il sistema dalla rete, raccogliere le evidenze, analizzare. In un ambiente IT questa procedura è consolidata e generalmente sicura.

In un ambiente OT, lo stesso istinto può causare danni gravi.

Un PLC che controlla una linea di dosaggio chimica non può essere "isolato dalla rete" senza capire prima esattamente cosa sta controllando e quali sono le conseguenze operative dell'isolamento. Un sistema SCADA che gestisce la pressione in una rete di distribuzione del gas non si spegne come si spegne un server di posta.

Le differenze fondamentali tra IR IT e IR OT:

Priorità diverse: nell'IT, la priorità è proteggere i dati e ripristinare i servizi. Nell'OT, la priorità è la safety delle persone, poi la continuità operativa, poi l'integrità dei dati. Un'azione che protegge i dati causando un rischio di safety non è accettabile.

Sistemi non isolabili: molti sistemi OT non possono essere spenti o isolati senza conseguenze operative immediate. La risposta deve avvenire con il sistema in funzione.

Finestre temporali diverse: un incident response IT lavora in ore o giorni. Un impianto industriale potrebbe avere finestre di manutenzione disponibili solo ogni settimana o ogni mese. Alcune azioni di remediation possono essere eseguite solo durante questi periodi.

Competenze diverse: le tecniche forensics standard (acquisizione di immagini disco, analisi della memoria RAM) si applicano male ai PLC e ai dispositivi embedded OT, che hanno architetture e sistemi di storage completamente diversi dai server IT.

Triage in un ambiente operativo: sicurezza vs. risposta

La fase di triage in un incidente OT richiede la partecipazione congiunta di due funzioni che raramente collaborano: il team di sicurezza informatica e il team di operations.

Il team di sicurezza può identificare cosa è stato compromesso, ma spesso non sa quali sono le conseguenze operative di ciascuna azione di risposta. Il team di operations conosce l'impianto ma non ha le competenze di incident response cyber.

La decisione critica nel triage è: agire subito (con rischio di impatto operativo) o contenere l'espansione dell'incidente mentre si mantiene l'operatività (con rischio di ulteriore compromissione)?

Non c'è una risposta universale. Dipende da:

• Quale sistema è compromesso e cosa controlla
• Se l'attaccante è ancora attivo e sta compiendo azioni malevole
• Se ci sono indicazioni di un obiettivo imminente (es. sabotaggio pianificato)
• Se l'impianto può operare in modalità manuale nel frattempo

Queste decisioni devono essere prese velocemente, sotto pressione, con informazioni incomplete. La preparazione preventiva, avere già discusso questi scenari e avere un framework decisionale condiviso, è ciò che fa la differenza.

Il playbook OT: fasi e decisioni chiave

Un playbook OT efficace deve adattare la struttura IR standard alle peculiarità dell'ambiente industriale:

Fase 1, Rilevamento e notifica: chi deve essere notificato immediatamente? Non solo il CISO e il team IT: anche il responsabile di produzione, il responsabile safety, la direzione. In molti casi, le normative (NIS2, DORA) richiedono notifiche esterne entro 24 ore.

Fase 2, Valutazione iniziale del rischio OT: prima di qualsiasi azione tecnica, rispondere a: ci sono rischi di safety immediati? Il sistema compromesso può essere isolato senza impatto critico? Qual è la peggiore azione che l'attaccante potrebbe compiere?

Fase 3, Contenimento sicuro: definire le azioni di contenimento possibili che non aumentano il rischio operativo. Bloccare specifiche connessioni di rete invece di isolare completamente; aumentare il monitoraggio invece di spegnere; passare in modalità manuale sulle funzioni critiche come precauzione.

Fase 4, Raccolta delle evidenze: adattare le tecniche di acquisizione alle capacità dei sistemi OT. Log degli HMI, traffico di rete registrato, configurazioni dei PLC, eventi del sistema SCADA. Documentare l'ora e le condizioni di ogni raccolta.

Fase 5, Remediation pianificata: definire le azioni di remediation con il team di operations, pianificarle nelle finestre di manutenzione disponibili, testare ogni azione in un ambiente di test prima di applicarla all'impianto live quando possibile.

Forensics in ambienti industriali: vincoli e tecniche

L'acquisizione di evidenze forensi in ambienti OT presenta sfide specifiche:

PLC e dispositivi embedded: non hanno filesystem accessibili con strumenti forensi standard. La "memoria" di un PLC è la sua logica di controllo e lo stato dei suoi registri. L'acquisizione richiede strumenti specifici per la piattaforma (Siemens Step 7, Rockwell Studio 5000, ecc.) e competenza nel formato dei dati.

Sistemi non spegnibili: l'acquisizione forense di un sistema live (senza spegnerlo) è sempre meno accurata dell'acquisizione offline. In molti casi OT, è l'unica opzione disponibile.

Log con retention limitata: molti sistemi OT hanno log in memoria volatile con retention di poche ore. La raccolta dei log deve avvenire rapidamente per non perdere evidenze.

Chain of custody in ambienti industriali: mantenere la chain of custody forense in un impianto dove il personale operativo deve continuare a lavorare richiede procedure specifiche che bilanciamo integrità delle evidenze e continuità operativa.

Esercitazioni tabletop: come prepararsi prima dell'incidente

La preparazione all'incident response OT non può essere solo teorica. Le esercitazioni tabletop, scenari simulati discussi in gruppo senza interventi tecnici reali, sono il modo più efficace per costruire la prontezza operativa senza rischi per l'impianto.

Un'esercitazione tabletop OT efficace:

Scenario realistico: non "un attacker entra nella rete" ma "alle 14:30 di martedì il sistema SCADA della linea 3 mostra comportamenti anomali: i setpoint di temperatura vengono modificati senza che nessuno li abbia cambiati". Specifico, con dettagli operativi reali.

Partecipanti misti: CISO, responsabile IT, responsabile di produzione, ingegnere di processo, responsabile safety. L'esercitazione serve a far emergere i gap nella comunicazione tra funzioni.

Decisioni difficili: inserire volutamente scenari dove non c'è una risposta ovvia. "Isoliamo il sistema e fermiamo la linea, o monitoriamo e rischiamo che l'attacker agisca?": questa discussione, fatta in anticipo in un contesto non emergenziale, costruisce la capacità di prendere decisioni rapide quando serve davvero.

Debriefing strutturato: al termine, documentare i gap identificati e le azioni di miglioramento decise. L'esercitazione senza follow-up ha valore limitato.

Le organizzazioni che conducono esercitazioni regolari rispondono meglio agli incidenti reali. Non perché abbiano visto esattamente lo stesso scenario, ma perché hanno già attraversato il processo decisionale e sanno come collaborare sotto pressione.

L'angolo MON5

Quando l'incidente OT arriva, la differenza la fa ciò che è stato preparato prima: inventario aggiornato, baseline di comportamento, traffico di rete registrato. MON5 fornisce esattamente questo contesto: l'inventario asset continuo dice subito cosa controlla il sistema compromesso, mentre l'NDR passivo fuori banda conserva le evidenze di rete senza toccare i dispositivi, un vantaggio decisivo dove la forensics tradizionale non si applica.

L'anomaly detection ML accorcia inoltre il tempo di rilevamento, dando al team più margine per decisioni di contenimento coordinate con Operations. Costruisci la tua prontezza alla risposta partendo da un assessment OT.