Come gli attaccanti attraversano il confine IT-OT: tecniche e segnali di rilevamento

Perché il confine IT-OT è il punto critico

In quasi tutti gli incidenti di cybersecurity industriale documentati con sufficiente dettaglio tecnico, c'è un momento preciso che separa un attacco IT da un attacco con impatto operativo reale: il momento in cui l'attaccante attraversa il confine tra la rete aziendale e la rete OT.

Prima di quel momento, si tratta di un incidente IT come molti altri: violazione di credenziali, malware su un endpoint, accesso non autorizzato a un server. Dopo, il perimetro di rischio cambia completamente: l'attaccante ha accesso a sistemi che controllano processi fisici, macchinari, impianti. Il potenziale di danno sale in modo discontinuo.

Questo confine esiste nella maggior parte delle organizzazioni manifatturiere, ma raramente è impenetrabile. Esiste per ragioni storiche (le reti OT erano separate prima che diventassero connesse all'IT aziendale) e viene mantenuto con gradi variabili di rigore. Il problema è che la pressione operativa, ovvero la necessità di monitoraggio remoto, di trasferimento dati verso i sistemi ERP, di accesso vendor per la manutenzione, crea continuamente aperture in questo confine, molte delle quali sono legittime ma non adeguatamente monitorate.

Tecnica 1: abuso dei jump server e degli historian

Il percorso più comune verso la rete OT non passa attraverso una vulnerabilità nei firewall industriali: passa attraverso i sistemi che per design hanno un piede in entrambe le reti.

Gli historian sono database che raccolgono dati di processo dalla rete OT e li rendono disponibili per analisi e reportistica sul lato IT. Sistemi come OSIsoft PI, GE Historian e simili sono progettati per stare a cavallo del confine: hanno connessioni verso i server OPC-UA della rete di controllo e interfacce consultabili dalla rete IT. Un attaccante che compromette l'historian ottiene spesso la possibilità di interrogare direttamente i valori di processo, ma in alcuni casi anche di scrivere verso la rete OT, a seconda di come è configurata la comunicazione bidirezionale.

I jump server, o bastion host, sono sistemi da cui gli operatori e i tecnici accedono agli asset OT in modo controllato. Sono punti di aggregazione dell'accesso: chi compromette il jump server ottiene la stessa visibilità di tutti gli utenti che ci si connettono. In ambienti con scarsa segmentazione, un jump server può avere visibilità su decine o centinaia di asset OT senza ulteriori meccanismi di controllo interno.

Il pattern di attacco tipico: compromissione di un endpoint IT (phishing, vulnerabilità applicativa), escalation dei privilegi, ricerca di credenziali verso jump server o historian, accesso alla rete OT attraverso questi sistemi.

Tecnica 2: tunneling su canali di accesso remoto legittime

I canali di accesso remoto vendor sono un vettore critico e spesso sottovalutato. Quasi tutti i costruttori di macchinari industriali prevedono la possibilità di connettersi remotamente ai propri sistemi per la manutenzione e la diagnostica. Questi accessi avvengono tipicamente tramite VPN dedicate, client software proprietari, o connessioni RDP/SSH verso dispositivi di campo.

Il problema di sicurezza non è nell'esistenza di questi canali, dato che la manutenzione remota ha vantaggi operativi reali, ma in come vengono gestiti. Alcune configurazioni frequenti che creano rischio:

• Credenziali condivise tra più tecnici vendor: se il vendor A usa sempre le stesse credenziali per accedere all'impianto del cliente, e un tecnico le porta fuori dall'azienda, l'accesso è compromesso senza che nessuno lo sappia.
• Connessioni sempre attive: tunnel VPN verso reti OT che rimangono aperti anche quando non servono, invece di essere attivati su richiesta e monitorati.
• Accesso più ampio del necessario: il tecnico di un fornitore di PLC ottiene una connessione VPN che gli dà visibilità sull'intera rete di controllo, non solo sui suoi dispositivi.
• Nessun log delle sessioni: le attività del tecnico remoto non vengono registrate, quindi non è possibile ricostruire cosa ha fatto.

Un attaccante che compromette la workstation di un tecnico vendor, tipicamente un sistema con postura di sicurezza inferiore a quella aziendale, eredita tutti i canali di accesso remoto configurati su quel sistema.

Tecnica 3: credenziali condivise tra rete IT e rete OT

In molte organizzazioni manifatturiere, specialmente quelle cresciute senza una pianificazione della sicurezza OT, le credenziali usate in rete IT sono le stesse usate per accedere ai sistemi OT. Un operatore usa la stessa password Windows sia per il suo PC in ufficio sia per il terminale HMI in produzione. Un amministratore di sistema usa le stesse credenziali per i server IT e per il jump server OT.

Questa condivisione trasforma qualsiasi compromissione di credenziali IT in un problema OT automatico. Un attacco di credential stuffing che ottiene la password di un operatore potrebbe valere anche per il sistema SCADA, senza che l'attaccante debba fare niente di specifico per l'ambiente OT.

La separazione delle credenziali tra dominio IT e sistemi OT è uno dei miglioramenti di sicurezza con il miglior rapporto costo/beneficio disponibili per le organizzazioni industriali, e uno dei meno implementati.

Segnali di rilevamento nel traffico di rete

Il movimento laterale tra IT e OT, anche quando avviene attraverso canali tecnicamente legittimi, lascia tracce rilevabili nel traffico di rete se si sa cosa cercare.

Connessioni verso subnet OT da sistemi IT che non comunicano normalmente con l'OT: nella maggior parte degli ambienti produttivi, solo un sottoinsieme limitato e noto di sistemi IT (l'historian, specifici server di interfaccia, i jump server) comunica con la rete OT. Una connessione che parte da una workstation utente o da un server applicativo IT verso un indirizzo nella subnet OT è anomala e deve essere investigata.

Autenticazioni fuori orario o da posizioni insolite verso jump server: i jump server hanno pattern di accesso prevedibili: certi utenti, certi orari, certi IP sorgente. Un'autenticazione riuscita a un jump server OT alle 3 di notte da un IP non visto in precedenza è un segnale forte.

Scansioni interne dalla rete OT: se un dispositivo che normalmente comunica solo con il suo PLC di riferimento inizia a inviare richieste ARP verso indirizzi che non conosce, o tenta connessioni verso porte insolite di altri dispositivi, sta probabilmente eseguendo discovery, il che suggerisce che qualcosa di non autorizzato si sta muovendo nella rete.

Variazioni nel volume di traffico verso e da historian: un picco significativo nel volume di dati che l'historian trasferisce verso la rete IT, fuori dai pattern normali, può indicare esfiltrazione di dati di processo o uso improprio del sistema come relay.

Prime connessioni tra coppie di host precedentemente mute: negli ambienti OT maturi, la matrice di comunicazione è stabile. Ogni comunicazione tra una coppia di indirizzi che non ha mai comunicato prima merita attenzione.

Il ruolo del monitoraggio passivo nella rilevazione del pivot

Il vantaggio del monitoraggio passivo del traffico di rete per rilevare il movimento laterale IT-OT è che non richiede nessuna modifica agli endpoint: né agenti, né configurazioni aggiuntive sui dispositivi OT, né impatto sui processi in corso. Si posiziona un sensore di rete in un punto strategico, tipicamente in prossimità del firewall che separa IT e OT, e si osserva tutto il traffico che attraversa il confine.

Questo approccio ha limiti chiari: non vede cosa succede internamente a un singolo dispositivo, non cattura comunicazioni che avvengono interamente dentro una subnet senza attraversare il sensore, non può bloccare il traffico (è passivo per definizione). Ma per rilevare il pivot IT-OT, che per definizione attraversa il confine dove si posiziona il sensore, la copertura è diretta.

La chiave è avere una baseline accurata di cosa è normale su quel confine, ossia quali sistemi comunicano, su quali porte, con quale frequenza, in quali orari, per poter rilevare le deviazioni che caratterizzano il movimento laterale. Questo richiede un periodo di osservazione iniziale e un processo di calibrazione, ma una volta stabilita la baseline, le anomalie emergono in modo chiaro dalla cortina di traffico legittimo.

Cosa fare dopo il rilevamento

Rilevare il pivot IT-OT in corso pone un problema operativo immediato: l'ambiente OT è in produzione, non si può semplicemente bloccare tutto il traffico verso la rete di controllo senza verificare le conseguenze.

La risposta corretta non è quella IT, cioè isola tutto e poi investiga. Nell'OT la sequenza è diversa: raccogli più informazioni possibile prima di agire, coordina con il responsabile operations prima di toccare qualunque cosa che possa avere impatto sul processo, identifica la portata della compromissione e i sistemi coinvolti, costruisci una narrazione chiara di cosa è successo e cosa rischia di succedere.

Solo con questa visibilità, e con un consenso esplicito tra sicurezza e operations su quanto rischio si è disposti ad accettare durante la risposta, si può agire in modo efficace senza creare danni operativi nel tentativo di contenere un attacco.

L'angolo MON5

Rilevare il pivot IT-OT richiede esattamente ciò che questo articolo descrive: una baseline accurata del confine e un sensore che osserva il traffico senza toccarlo. La fase PROTECT di MON5 fa questo con NDR passivo fuori banda, che decodifica i protocolli OT nativi (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) e segnala con anomaly detection ML le prime connessioni tra host che non avevano mai comunicato, gli accessi anomali ai jump server, i picchi di traffico verso gli historian.

Prima di monitorare il confine, però, bisogna sapere dove passa davvero. Per mappare i punti di contatto tra IT e OT del vostro impianto, potete partire da un assessment OT.