A cura di Andrew Tsonchev, Director of Technology, Darktrace Industrial
L’attacco recente del malware TRITON contro un'organizzazione di infrastruttura critica ha cercato di modificare e manipolare i sistemi di sicurezza industriale con l'intenzione di causare un danno fisico potenzialmente disastroso. I sistemi di controllo industriali (ICS) creano un'interfaccia tra ambienti fisici e digitali, il che significa che le ripercussioni di un guasto non gestito possono essere catastrofiche.
La campagna TRITON può essere divisa in due fasi concettuali; in primo luogo, gli attaccanti sono riusciti a guadagnare l’accesso remoto a una postazione di ingegneria collegata al network SIS (Safety Instrumented System), dopodiché hanno implementato un programma in grado di mascherarsi da applicazione legittima ideata da un fornitore legato al controllo critico e alla sicurezza del sistema. Il framework per imitare questa applicazione legittima non è facilmente disponibile, il che porta a credere che TRITON sia la creazione di attori ben finanziati e altamente capaci, con intenzioni che probabilmente vanno oltre al semplice guadagno economico.
Gli aggressori hanno sovvertito le tradizionali difese di rete; una volta stabilito questo punto d'appoggio, hanno optato per scavare più a fondo nella rete ed effettuare ricognizioni dettagliate – la seconda fase dell'attacco. Fortunatamente, durante questa fase hanno innescato accidentalmente un errore parziale di sistema, che il team di sicurezza interno ha esaminato e risolto.
Avendo fallito nel raggiungere l’obiettivo finale, gli attaccanti si troveranno probabilmente ad analizzare dove hanno sbagliato, in modo da evitare la prossima volta di essere scoperti in una fase così avanzata. Potrebbero anche decidere che la fase di ricognizione non sia più conveniente, poiché, chiaramente, sarebbero stati in grado di effettuare un sabotaggio significativo anche da quella prima posizione senza ulteriori rischi di essere scoperti. Il loro successo nel penetrare la rete con i loro strumenti e metodi attuali, fino a quando non sono stati scoperti, significa che li useranno quasi sicuramente di nuovo contro altre organizzazioni.
TRITON dovrebbe essere considerato un importante precedente per la sicurezza ICS. Questo incidente, infatti, dimostra che le tradizionali zone demilitarizzate, la segregazione intensa della rete e i firewall multipli non sono in definitiva sufficienti a proteggere le macchine, sostanzialmente indifese, che costituiscono le reti ICS. Come possono quindi i fornitori delle infrastrutture adottare un approccio di sicurezza valido alla luce dell’attacco TRITON?
Per quanto riguarda la seconda fase, il rilevamento delle anomalie è una soluzione evidente che permette di individuare attività insolite all'interno del sistema di controllo, evidenziando una riprogrammazione o ricognizione imprevista all'attenzione del team di sicurezza. Le comunicazioni tipicamente prevedibili che avvengono tra dispositivi ICS come HMI e PLC sono intuitivamente un terreno fertile per questo tipo di approccio. Le autorità di regolamentazione ne hanno preso atto e, ad esempio, nel Regno Unito la legislazione in arrivo sulla direttiva NIS impone che i fornitori di infrastrutture critiche abbiano adottato il rilevamento delle anomalie per le loro reti principali.
Tuttavia, i difensori non vogliono che la loro prima occasione di catturare gli attaccanti si presenti solo quando hanno già raggiunto il sistema di controllo e stanno facendo uso dei protocolli di automazione e sfruttando i dispositivi intrinsecamente vulnerabili. Vogliono essere avvisati nelle prime fasi della catena di attacco, quando gli aggressori si fanno strada attraverso le reti, ed essere in grado di ripristinarle proprio in quel momento; un risultato ottenibile solo estendendo il rilevamento delle anomalie e delle minacce informatiche oltre il sistema di controllo verso le altre reti (zone demilitarizzate, reti corporate) che possono formare un buffer difensivo attorno ad esso.
Questo è il motivo per cui l'Industrial Immune System di Darktrace è progettato per monitorare simultaneamente tutte queste reti, includendo l'intera gamma dei dispositivi, dai PLC ai sistemi IT standard delle sale di controllo OT, fino ai limiti estremi della possibile visibilità dell'organizzazione – anche nel cloud, se necessario. Tutto questo perché non è sufficiente per chi ha il compito di proteggere il sistema di controllo di monitorare solo i protocolli di automazione o le reti che li contengono.