Credenziali di default nei sistemi OT: un problema più diffuso di quanto si pensi

Quanto è diffuso il problema

Quando si parla di credenziali di default nei sistemi OT, la reazione comune è di scetticismo: "sicuramente nei nostri impianti le password sono state cambiate al momento dell'installazione." In molti casi questa convinzione è errata.

I dati che emergono dai penetration test e dagli audit di sicurezza OT descrivono una realtà diversa. Credenziali di default, o password banalmente semplici impostate al momento del deploy e mai cambiate, si trovano con frequenza negli impianti industriali, anche in aziende che hanno investito in altri aspetti della sicurezza informatica.

Il problema non nasce da negligenza grossolana. Nasce dalla convergenza di diversi fattori strutturali che rendono il cambio delle credenziali nei sistemi OT molto più complicato di quanto sembri.

Perché le credenziali rimangono di default

Capire le cause aiuta a identificare le soluzioni reali invece di limitarsi a prescrivere "cambiate le password."

Il cambio password rompe funzionalità collegate: molti sistemi OT hanno integrazioni tra componenti che usano credenziali hardcoded o memorizzate in file di configurazione. Cambiare la password dell'account di amministrazione del server SCADA può interrompere la comunicazione con il database storico, con il sistema di reportistica, con le notifiche automatiche. Prima di cambiare la password occorre capire dove è usata: un'analisi che richiede tempo e conoscenza approfondita del sistema.

La dipendenza dal vendor: per molti sistemi OT, qualsiasi modifica alla configurazione, incluso il cambio delle credenziali di accesso, deve essere eseguita dal vendor o con la sua supervisione, per non invalidare la garanzia o il contratto di manutenzione. Il vendor ha i propri processi e tempi. L'account di accesso del vendor, con la sua password di servizio standard, è spesso lo stesso su ogni installazione dello stesso prodotto in tutto il mondo.

Assenza di un processo di hardening al deploy: i sistemi OT vengono spesso installati da system integrator che si concentrano sulla funzionalità operativa, far funzionare la linea di produzione, e non sulla sicurezza. Le checklist di commissioning raramente includono il cambio delle credenziali di default. E una volta che il sistema è in produzione e tutto funziona, intervenire per fare hardening richiede un motivo forte.

La sindrome del "se funziona non toccare": una HMI con password "admin" che gira da sei anni senza problemi è percepita come meno rischiosa di una procedura di cambio password che potrebbe causare un fermo non pianificato. La valutazione del rischio implicita è distorta, ma è comprensibile in un contesto operativo dove la continuità produttiva è la priorità assoluta.

Proliferazione di account di servizio: i sistemi SCADA e i software applicativi OT hanno spesso account di servizio multipli: account per l'esecuzione del servizio Windows, account per la connessione al database, account per la comunicazione con i dispositivi di campo. Ognuno ha una password. Spesso sono le stesse password di default impostate dall'installatore, dimenticate, e mai aggiornate.

Come un attaccante trova le credenziali

La disponibilità di informazioni sulle credenziali di default dei sistemi OT è sorprendente per chi non l'ha mai cercata attivamente.

Documentazione pubblica dei vendor: i manuali di installazione e le guide rapide di moltissimi prodotti OT sono disponibili liberamente sul sito del vendor o su siti di documentazione tecnica. Questi manuali includono tipicamente le credenziali di default, le procedure di primo accesso, e a volte anche le credenziali degli account di servizio. Una ricerca mirata permette di trovare le credenziali di default di gran parte dei prodotti OT diffusi in pochi minuti.

Motori di ricerca specializzati: Shodan e strumenti simili indicizzano dispositivi esposti su internet, inclusi i pannelli di accesso remoto di sistemi OT. Combinare un prodotto specifico (identificato tramite il banner di risposta) con le sue credenziali di default dalla documentazione del vendor è un vettore di attacco documentato e usato attivamente.

Bruteforce su protocolli senza lockout: molti protocolli OT e le interfacce di gestione dei dispositivi di campo non implementano meccanismi di lockout dopo tentativi falliti multipli. Un attaccante con accesso alla rete OT può provare dizionari di password comuni, e le credenziali di default di tutti i prodotti noti, senza rischio di bloccare l'account.

Condivisione nei forum underground: le credenziali di default dei prodotti OT più diffusi circolano nei forum underground insieme alle tecniche di exploit specifiche per protocolli industriali. Non è un segreto custodito: è informazione largamente disponibile nell'ecosistema dei threat actor che si interessano agli ambienti industriali.

Cosa rivela il monitoraggio del traffico

Il monitoraggio passivo del traffico OT può rilevare sia i tentativi di compromissione tramite credenziali di default sia gli accessi effettivamente avvenuti.

Tentativi di autenticazione falliti multipli: un bruteforce, anche lento e distribuito per evitare rilevamento, produce un pattern riconoscibile nel traffico. Tentativi di accesso ripetuti verso la stessa destinazione, specialmente se provenienti da sorgenti non usuali, sono un segnale da investigare.

Sessioni di gestione non autorizzate: anche se un attaccante usa credenziali valide (perché erano di default), una sessione di management aperta in un orario insolito, da un indirizzo IP non previsto, o con un pattern di comandi diverso dalla baseline è rilevabile. Il traffico legittimo di un operatore ha caratteristiche diverse dal traffico di un attaccante che esplora il sistema.

Accessi fuori dalle finestre di manutenzione: nelle reti OT ben gestite, le sessioni di configurazione e management avvengono in finestre temporali definite. Un accesso di amministrazione in orario di produzione normale, quando non c'è nessun intervento pianificato, è un'anomalia che merita attenzione.

Traffico verso indirizzi di gestione da zone non autorizzate: un dispositivo di campo o un PLC raggiunto da un sistema che normalmente non comunica con lui (un server IT, un laptop connesso in un punto non abituale) è un indicatore di possibile uso anomalo di credenziali.

Hardening pratico senza fermare la produzione

Cambiare le credenziali di default in un ambiente OT attivo richiede un approccio metodico, non un intervento massivo e improvvisato.

Prima fase: inventario degli account

Il punto di partenza è capire quanti account esistono, su quali sistemi, e quali sono le dipendenze. Questo richiede di esaminare sistemi SCADA, server OPC, database storici, HMI, switch di rete, e tutti i componenti che hanno un'interfaccia di autenticazione. Per i sistemi più critici, l'analisi deve essere coordinata con i vendor per non fare ipotesi errate sulle dipendenze.

Seconda fase: classificazione per priorità

Non tutti gli account hanno lo stesso profilo di rischio. Gli account più critici da affrontare prima sono quelli su sistemi con interfacce di accesso remoto attive o raggiungibili da reti non completamente fidate. Un account con password di default su un sistema completamente isolato dalla rete ha profilo di rischio molto diverso rispetto allo stesso account su un sistema raggiungibile dalla rete IT o da internet.

Terza fase: intervento pianificato per sistema

Per ogni sistema, il cambio delle credenziali va eseguito in una finestra di manutenzione pianificata, con:

• Backup della configurazione corrente
• Mappa delle dipendenze (quali altri sistemi usano queste credenziali)
• Piano di rollback in caso di problemi
• Test di funzionalità dopo il cambio

Le nuove password devono seguire una politica definita (lunghezza minima, complessità, unicità per sistema) e vanno gestite con uno strumento di password management, non in fogli Excel condivisi.

Quarta fase: monitoraggio post-hardening

Dopo il cambio delle credenziali, il monitoraggio del traffico permette di verificare che non ci siano sistemi che continuano a usare le vecchie credenziali (fallimenti di autenticazione ripetuti da host interni sono un segnale che qualche integrazione è stata dimenticata) e che non ci siano tentativi di accesso con le vecchie password di default (che indicherebbero qualcuno che ha già in mano le credenziali precedenti).

Il vendor account: il caso speciale

Un caso che merita attenzione separata è l'account di accesso del vendor. Quasi tutti i prodotti OT hanno un account di supporto o di servizio, spesso con privilegi elevati, che il vendor usa per manutenzione e troubleshooting remoto.

Questi account hanno caratteristiche problematiche: tendono ad avere credenziali standard identiche su tutte le installazioni del prodotto, a essere condivisi tra tutti i tecnici del vendor, e a rimanere attivi anche quando non ci sono interventi in corso.

La gestione corretta degli account vendor nell'OT prevede:

• Credenziali diverse per ogni installazione, generate e comunicate al vendor solo per la durata dell'intervento
• Disabilitazione dell'account vendor al termine di ogni intervento di manutenzione
• Monitoraggio di tutte le sessioni aperte con l'account vendor (quando, da dove, quali operazioni)
• Revisione periodica degli account vendor attivi e rimozione di quelli non più necessari

Questa gestione richiede coordinamento con il vendor e può incontrare resistenza ("ma così ci complicate il lavoro di supporto"). È una resistenza comprensibile operativamente, ma inaccettabile dal punto di vista della sicurezza: un account vendor condiviso con credenziali standard è una porta aperta che chiunque abbia accesso alla documentazione del prodotto può usare.

Il tema delle credenziali di default negli ambienti OT è uno di quelli dove la distanza tra la percezione del rischio e il rischio reale è più grande. La buona notizia è che il hardening, fatto con metodo, è tecnicamente realizzabile senza impatti significativi sulla produzione, e il monitoraggio continuo del traffico permette di rilevare rapidamente sia i tentativi di sfruttamento sia le configurazioni che non sono ancora state corrette.

L'angolo MON5

Rilevare l'uso di credenziali di default senza scansioni attive è esattamente il tipo di problema che richiede un approccio passivo. Il monitoraggio della fase PROTECT di MON5 decodifica i protocolli OT nativi e individua sessioni di autenticazione anonima, accessi di gestione fuori orario e tentativi ripetuti che indicano bruteforce, senza mai interrogare i dispositivi.

L'inventario degli account parte però da quello dei sistemi: la fase DISCOVER mappa dispositivi e interfacce di gestione presenti in rete, comprese quelle che nessuno aveva censito. Per sapere quante interfacce di accesso esistono davvero nel tuo impianto, prenota un assessment OT.