Triton/TRISIS: quando gli attaccanti puntano ai sistemi di sicurezza industriali

L'incidente e il suo contesto

Nel 2017, un impianto petrolchimico in Arabia Saudita si fermò inaspettatamente. I safety instrumented system, i sistemi che monitorano le condizioni di processo e innescano gli shutdown di sicurezza in caso di emergenza, entrarono in fail-safe e bloccarono l'impianto. L'analisi successiva rivelò che non si era trattato di un malfunzionamento: era stato un attacco.

Il malware, denominato Triton dai ricercatori di Mandiant e TRISIS da quelli di Dragos, era stato impiantato nella workstation di engineering che comunicava con i Safety Instrumented System Triconex di Schneider Electric. Il suo obiettivo era riprogrammare i controller safety in modo da disabilitare la loro funzione di protezione: impedire che i SIS rilevassero una condizione pericolosa e attivassero lo shutdown, con l'intenzione presumibile di permettere che una condizione di pericolo fisico raggiungesse l'impianto senza che i sistemi di sicurezza intervenissero.

Il fatto che l'attacco sia stato scoperto, e non abbia causato l'incidente fisico che aveva come obiettivo, è dovuto a un errore nel malware stesso che ha causato il fail-safe spontaneo dei controller, attirando l'attenzione. Senza quell'errore, l'obiettivo dell'attacco potrebbe essere rimasto invisibile fino al momento in cui un'emergenza avrebbe trovato i SIS disabilitati.

Perché Triton è diverso da tutti gli altri malware OT

Prima di Triton, il panorama dei malware specificamente progettati per l'OT includeva Stuxnet (che ha sabotato le centrifughe per l'arricchimento dell'uranio a Natanz), INDUSTROYER/Crashoverride (che ha causato blackout nella rete elettrica ucraina), e BlackEnergy (usato in attacchi alla rete elettrica). Tutti questi malware avevano come obiettivo il processo di controllo industriale: i PLC, i sistemi SCADA, le reti di distribuzione dell'energia.

Triton è fondamentalmente diverso perché non attacca il sistema di controllo: attacca il sistema di sicurezza. Questa distinzione non è tecnica: è concettuale e ha implicazioni profonde.

I Safety Instrumented System esistono come ultimo livello di difesa contro gli incidenti industriali gravi. La filosofia tradizionale della sicurezza industriale distingue rigidamente tra "safety" (protezione da incidenti fisici) e "security" (protezione da attacchi informatici), trattandoli come domini separati con tecnologie, standard e responsabilità diverse. I SIS vengono progettati per resistere ai guasti dei sistemi di controllo, per essere indipendenti dal resto dell'automazione, per garantire uno shutdown sicuro anche quando tutto il resto fallisce.

Un attacco che rende inaffidabile il SIS non viola solo la "security" dell'impianto: viola il presupposto fondamentale su cui si basa la "safety". Se i sistemi di sicurezza possono essere compromessi, il modello di protezione su cui si basano le valutazioni di rischio degli impianti petrolchimici, delle centrali, degli impianti chimici, deve essere ripensato.

La catena tecnica: come si è arrivati al SIS

L'analisi tecnica dell'incidente ha ricostruito una catena di compromissione che parte dalla rete IT aziendale e arriva fino ai controller Triconex.

Il punto di ingresso è stato probabilmente la rete IT: le ricostruzioni disponibili indicano che l'accesso iniziale è avvenuto mesi prima dell'attivazione del malware, con un lungo periodo di reconnaissance e movimento laterale. Dalla rete IT, gli attaccanti hanno raggiunto la rete OT seguendo il percorso tipico: attraverso sistemi con accesso a entrambe le reti. Una volta nella rete OT, hanno identificato e compromesso la workstation di engineering che aveva accesso diretto ai controller Triconex attraverso il protocollo proprietario TriStation.

Il malware Triton aveva una struttura modulare sofisticata. Un implant permanente sulla workstation di engineering fungeva da framework di controllo. I payload specifici, scritti per interagire con il protocollo TriStation, permettevano di leggere e modificare la logica dei controller Triconex, incluse le funzioni di safety che determinano le soglie di allarme e le condizioni di shutdown.

La complessità tecnica del malware, ossia la necessità di implementare il protocollo proprietario TriStation, non documentato pubblicamente, indica risorse significative investite nello sviluppo. Non è il prodotto di un gruppo opportunista: è il prodotto di un'organizzazione con accesso a risorse considerevoli e tempo per lo sviluppo mirato.

Implicazioni per l'architettura di sicurezza industriale

Triton ha reso evidente un gap nel modo in cui la sicurezza industriale era concepita fino al 2017.

La separazione tradizionale tra safety e security si basava sull'assunzione implicita che i sistemi safety fossero al sicuro dagli attacchi informatici perché fisicamente segregati, perché usavano protocolli proprietari, perché avevano connettività limitata. Triton ha dimostrato che questa segregazione, nelle implementazioni reali, non è così ermetica come si immaginava: una workstation di engineering con connettività alla rete OT e accesso fisico al SIS è un percorso praticabile per un attaccante sufficientemente motivato.

Le implicazioni pratiche per la progettazione della sicurezza sono significative:

I SIS non possono essere esclusi dal perimetro di monitoring. Se un sistema safety è raggiungibile, anche attraverso catene di accesso complesse, deve essere visibile al programma di cybersecurity. Non necessariamente con strumenti invasivi che potrebbero interferire con le funzioni di safety, ma almeno con il monitoring del traffico di rete che transita verso di esso.

Le workstation di engineering sono asset critici. Il percorso verso i SIS passa attraverso la workstation che li programma. Queste workstation, spesso trascurate perché non parte del processo critico in senso stretto, diventano obiettivi di valore primario. Il loro stato di sicurezza, gli accessi che ricevono, le connessioni che stabiliscono, devono essere monitorati.

La segmentazione deve includere i sistemi safety. Se i SIS sono su una rete separata dalla rete di controllo principale, il traffico che attraversa questo confine deve essere monitorato tanto rigorosamente quanto il traffico tra IT e OT.

Cosa si può rilevare a livello di rete senza endpoint visibility sui SIS

I SIS sono sistemi per cui l'installazione di agenti endpoint o strumenti di monitoring invasivi è quasi sempre fuori discussione: il rischio di interferire con le funzioni di safety supera qualsiasi beneficio di visibilità. Ma il monitoring passivo del traffico di rete offre comunque una superficie di rilevamento significativa.

Traffico verso indirizzi dei controller SIS da sorgenti non autorizzate: la workstation di engineering è tipicamente l'unico sistema autorizzato a comunicare con i controller Triconex (o equivalenti). Una connessione verso gli indirizzi dei SIS da qualsiasi altro host è anomala e deve generare un alert immediato.

Traffico TriStation o equivalenti fuori dalla baseline: il protocollo TriStation ha caratteristiche riconoscibili nel traffico di rete. Una sessione TriStation che avviene fuori dalle normali finestre di manutenzione, o con volume insolito, o a orari atipici, è un segnale.

Comportamento anomalo della workstation di engineering: anche senza vedere il traffico verso i SIS, il comportamento della workstation stessa è rilevabile. Connessioni verso indirizzi esterni non abituali, scaricamento di file insoliti, comunicazioni verso altri host della rete OT che normalmente non coinvolgono la workstation di engineering: tutti segnali che possono indicare una compromissione in corso.

Variazioni nel timing delle comunicazioni di manutenzione: le sessioni di accesso ai SIS per manutenzione hanno pattern temporali riconoscibili: avvengono durante fermi pianificati, durano un tempo consistente con le operazioni di manutenzione, vengono eseguite da utenti identificabili. Una sessione fuori da questi parametri merita investigazione.

La lezione per le organizzazioni manifatturiere

Triton ha colpito un impianto petrolchimico, un settore con una superficie di rischio e una criticità delle conseguenze fisiche che la maggior parte delle aziende manifatturiere non condivide. Ma la lezione che porta non è specifica del settore petrolifero.

La lezione è che i sistemi concepiti come l'ultimo baluardo contro gli incidenti fisici possono essere obiettivo di attacchi informatici, e che la separazione concettuale tra safety e security non si traduce automaticamente in separazione tecnica sufficiente a proteggere i sistemi safety dagli attaccanti.

Per le PMI manifatturiere che dispongono di sistemi safety (anche meno sofisticati dei Triconex petrolchimici, anche sistemi semplici come PLC con funzioni di safety integrate, contatori di sicurezza, sistemi di interblocco) la domanda pertinente è: questi sistemi sono inclusi nell'inventario degli asset da monitorare? Il traffico verso di essi è visibile? Le workstation che li programmano sono trattate come asset critici?

La risposta onesta, nella maggior parte delle organizzazioni, è no. Triton non ha cambiato la probabilità che una PMI manifatturiera italiana venga attaccata con malware di questa sofisticazione. Ha cambiato la comprensione di quali sistemi devono essere considerati parte della superficie d'attacco, e questo cambiamento non ha soglie di fatturato o dimensione aziendale.

L'angolo MON5

La lezione di Triton è precisa: i sistemi safety e le workstation che li programmano vanno monitorati, ma senza installarci nulla sopra. È il terreno della fase PROTECT di MON5: NDR passivo fuori banda che osserva il traffico verso i controller critici e segnala connessioni da sorgenti non autorizzate o sessioni di engineering fuori dalle finestre di manutenzione.

Prima ancora serve sapere quali sistemi safety esistono e chi può raggiungerli: la fase DISCOVER li porta nell'inventario con asset discovery passiva, senza fermare la produzione. Un buon punto di partenza è un assessment OT che includa anche questi asset spesso dimenticati.