OT incident response è la risposta agli incidenti nei sistemi industriali, ed è uno dei pochi ambiti in cui le competenze della sicurezza informatica, applicate senza adattamento, possono fare più male dell’attacco che vorrebbero fermare. In informatica il riflesso, di fronte a una compromissione, è quasi automatico: isolare il sistema, staccarlo dalla rete, terminare il processo, e nei casi peggiori reinstallare tutto da zero. Sono mosse rapide e quasi sempre prive di conseguenze fisiche. Nel mondo della tecnologia operativa quelle stesse mosse possono provocare un arresto di emergenza, una perdita di produzione, il danneggiamento di un macchinario, o mettere a rischio l’incolumità di chi lavora nell’impianto.

Il punto di partenza, quindi, è un’inversione dell’obiettivo. In informatica il fine della risposta è fermare l’attaccante, e si accetta che farlo costi un disservizio temporaneo. Nell’OT il fine è mantenere il processo fisico in uno stato sicuro mentre si gestisce l’incidente, e fermare l’attaccante diventa un obiettivo secondario, da perseguire solo con azioni che non compromettano la sicurezza e la continuità dell’impianto. Chi affronta un incidente industriale con la testa dell’informatico, e stacca la spina come farebbe con un server, rischia di trasformare un problema di sicurezza in un problema di sicurezza fisica.

Contenere non vuol dire spegnere

La distinzione più importante riguarda proprio il contenimento. In informatica contenere significa spesso isolare brutalmente: scollegare, spegnere, mettere in quarantena. Nell’OT questa equivalenza salta, perché ogni decisione di isolamento ha una ricaduta sul processo che governa. Scollegare un controllore può togliere la visibilità o il controllo su una parte di impianto nel momento meno opportuno, e la disconnessione fisica improvvisa è raramente la scelta giusta. La regola, qui, è privilegiare la segmentazione logica e graduale rispetto allo strappo, e soprattutto valutare ogni mossa di contenimento contro le sue conseguenze materiali prima di eseguirla.

È quello che gli specialisti definiscono spesso il ciclo delle conseguenze: per ogni azione di risposta, la domanda non è solo se ferma l’attaccante, ma cosa succede al processo se la si compie. Spegnere quel sistema interrompe una catena di sicurezza? Isolare quella zona lascia un impianto senza supervisione? La risposta a queste domande non la conosce chi viene dalla sicurezza informatica: la conosce l’ingegnere di processo, ed è per questo che nell’incident response industriale la decisione non può restare nelle mani dei soli esperti di sicurezza.

Sicuro non è la stessa cosa di protetto

Dietro tutto questo c’è una differenza concettuale che vale la pena rendere esplicita, perché in italiano due parole diverse si confondono in una. Esiste uno stato sicuro, lo safe state, che è la condizione in cui il processo fisico resta sotto controllo e non può produrre danni; ed esiste uno stato protetto, il secure state, che è la condizione in cui l’attaccante è stato escluso e il sistema informatico è messo in sicurezza. Nell’informatica i due tendono a coincidere: rendere sicuro un sistema vuol dire proteggerlo. Nell’OT possono entrare in conflitto diretto, perché l’azione che mette in sicurezza informatica un impianto, isolandolo o spegnendolo, può portarlo fuori dal suo stato fisico sicuro.

Quando i due obiettivi confliggono, l’OT sceglie il primo: la sicurezza fisica viene prima della pulizia informatica. È anche per questo che il recupero, in ambito industriale, è lento e si misura spesso in giorni o settimane, non in ore. Non si reinstalla un controllore come si reimmagina un portatile, non si manda offline un processo produttivo per ricostruirlo con calma, e ogni ripristino va validato per essere certi che il processo torni davvero nel suo stato corretto, e non solo apparentemente.

OT incident response si pianifica al contrario

Da questa realtà discende un’indicazione pratica controintuitiva, al centro dei cinque controlli critici per la sicurezza ICS proposti dagli istruttori SANS Tim Conway e Robert M. Lee a partire dall’analisi degli attacchi industriali realmente avvenuti. Il primo di quei controlli è proprio il piano di risposta agli incidenti specifico per l’OT, e l’osservazione più interessante, come ha notato Lee, è che conviene partire da lì, dal piano di incident response industriale, e ricavare a ritroso il resto della strategia di sicurezza. Un piano OT non è la versione adattata di un piano informatico: nasce con priorità diverse, ordina le azioni in base all’impatto operativo e punta a tenere il sistema in funzione durante l’attacco, riducendo insieme l’effetto dell’aggressione e il colpo al processo controllato.

Un piano del genere coinvolge figure che la risposta informatica raramente include: i responsabili dell’impianto, gli ingegneri di processo, i team della sicurezza fisica. Sono loro a poter dire quale azione è praticabile senza fermare la produzione e quale invece scatenerebbe un arresto pericoloso. Per questo i cinque controlli SANS, che oltre al piano comprendono un’architettura difendibile, la visibilità e il monitoraggio della rete industriale, l’accesso remoto sicuro e una gestione delle vulnerabilità basata sul rischio, sono pensati per essere mappati sugli standard esistenti come IEC 62443: non un metodo alternativo, ma un ordine di priorità derivato da come gli attacchi industriali accadono davvero.

Vedere senza toccare: l’OT SOC

C’è infine la condizione che rende possibile tutto il resto, ed è la visibilità. Sui sistemi industriali, in larga parte legacy, non si possono installare agenti di rilevamento come sugli endpoint informatici, e una scansione attiva troppo aggressiva può destabilizzare dispositivi fragili. Per questo il monitoraggio dell’OT è prevalentemente passivo: una piattaforma che osserva il traffico, comprende i protocolli industriali e alimenta con allarmi normalizzati un centro operativo capace di correlare gli eventi tra le diverse zone. È un centro operativo declinato per l’industria, e la guida NIST SP 800-82, nella revisione del 2023 e ora in aggiornamento, ne descrive l’architettura in coerenza con i requisiti di monitoraggio dello stesso IEC 62443. Vedere senza toccare è la regola: l’osservazione non deve mai diventare essa stessa una fonte di disturbo per il processo.

Perché conta adesso

Due forze rendono il tema urgente. La prima è la convergenza tra informatica e tecnologia operativa, che ha portato nei sistemi industriali sia le opportunità sia le minacce del mondo connesso, e con esse attacchi che si muovono usando strumenti legittimi e credenziali valide, senza lasciare il codice malevolo che un tempo si cercava. In questo scenario la difesa diventa per forza guidata dall’ingegneria, perché riconoscere un’anomalia richiede di sapere come il processo dovrebbe comportarsi. La seconda è la spinta normativa: con l’estensione degli obblighi alle infrastrutture critiche, la capacità di rispondere a un incidente industriale non è più una buona pratica per pochi settori, ma un requisito, e la continuità operativa dell’impianto diventa una responsabilità documentabile.

In fondo, l’OT incident response è il luogo in cui la differenza tra sicurezza informatica e sicurezza industriale smette di essere teorica e diventa una scelta con conseguenze fisiche. La prima domanda di chi risponde non è come fermare l’attaccante, ma cosa accade al processo se lo fermo in questo modo. Rispondere richiede gli ingegneri al tavolo, un piano scritto per la fabbrica e non preso in prestito dall’ufficio, e l’umiltà di accettare che a volte la reazione più sicura non è la più aggressiva. È un cambio di mentalità prima che di strumenti, e per chi gestisce un impianto è ciò che separa un incidente gestito da un incidente che diventa un disastro.

https://www.ictsecuritymagazine.com/industrial-cyber-security/ot-incident-response/