In una rete industriale, una vulnerabilità non è soltanto un problema software. Se interessa un PLC, un HMI, una engineering workstation o un componente che governa il processo, il suo sfruttamento può produrre conseguenze sulla disponibilità dell’impianto e, negli scenari più critici, sul comportamento del processo fisico.

Per questo la gestione delle vulnerabilità software in ambiente OT richiede un approccio diverso dal tradizionale patch management IT: bisogna conoscere l’esposizione, comprendere le conseguenze operative e decidere quando correggere, mitigare o isolare il sistema.

Cosa sono le vulnerabilità software e perché rappresentano un rischio per i sistemi OT

Una vulnerabilità software è una debolezza che può compromettere la sicurezza di un sistema o di un’applicazione quando viene sfruttata in determinate condizioni.

Può derivare da errori di programmazione, progettazione insicura, configurazioni errate, componenti di terze parti vulnerabili oppure da funzionalità che, pur previste dal prodotto, diventano pericolose nel contesto nel quale vengono utilizzate.

Nell’Operational Technology il problema assume caratteristiche particolari perché il software non gestisce soltanto informazioni: può contribuire al controllo di macchinari e processi fisici.

Definizione dei difetti informatici e differenza tra ambienti IT e Operational Technology

Dal punto di vista tecnico, molte vulnerabilità presenti nell’OT appartengono alle stesse categorie osservate nell’IT. Cambiano però contesto e conseguenze.

In un ambiente IT, la priorità è spesso proteggere confidenzialità, integrità e disponibilità dei dati e dei servizi. Nell’OT, disponibilità e integrità del processo assumono generalmente un peso particolarmente elevato, insieme ai requisiti di safety.

Anche le modalità di remediation sono differenti.

Un server può spesso essere aggiornato durante una finestra programmata e, se necessario, ripristinato attraverso procedure relativamente standardizzate. Fermare o riavviare un componente industriale può invece significare interrompere una linea, coordinare la manutenzione con la produzione o verificare nuovamente che il processo possa essere riavviato in condizioni sicure.

Per questo il livello di severità tecnica di una vulnerabilità non è sufficiente a determinarne la priorità in fabbrica.

Occorre sapere dove si trova il sistema vulnerabile, quanto è esposto, quale processo controlla e cosa accadrebbe se venisse compromesso.

Le principali tipologie di vulnerabilità nei software e nei firmware industriali

I sistemi industriali possono presentare vulnerabilità molto diverse.

Buffer overflow, gestione non sicura della memoria, command injection, autenticazione debole, credenziali hard-coded, gestione inadeguata delle sessioni e controlli insufficienti sulle autorizzazioni sono alcuni esempi di debolezze che possono interessare software e firmware.

A queste si aggiungono protocolli e servizi progettati in epoche nelle quali autenticazione e cifratura non rappresentavano requisiti prioritari.

Un ulteriore elemento riguarda le dipendenze software.

Applicazioni industriali moderne possono incorporare librerie, sistemi operativi e componenti open source o di terze parti. Una vulnerabilità in una dipendenza può quindi propagarsi all’interno di prodotti differenti senza essere immediatamente visibile all’utilizzatore finale.

La gestione del rischio richiede, perciò, di conoscere non soltanto il dispositivo fisico, ma anche versione del firmware, software installato, servizi attivi e dipendenze rilevanti.

Vettori di attacco e impatto delle vulnerabilità sulla produzione industriale

Una vulnerabilità diventa realmente pericolosa quando esistono condizioni che ne permettono lo sfruttamento.

Il fatto che un PLC presenti una CVE critica non significa automaticamente che sia facilmente attaccabile. Se il dispositivo è correttamente segmentato e non raggiungibile dal percorso utilizzato dall’attaccante, il rischio può essere sensibilmente diverso rispetto allo stesso PLC esposto attraverso una rete scarsamente controllata.

La valutazione deve quindi unire vulnerabilità, esposizione e criticità.

Come i cyber criminali sfruttano i difetti software per accedere alle reti di fabbrica

L’accesso iniziale a un ambiente industriale non avviene necessariamente attraverso un PLC.

Un attaccante può compromettere sistemi IT, credenziali, VPN, workstation utilizzate per la manutenzione o servizi esposti e utilizzare successivamente questa posizione per avvicinarsi alla rete OT.

Una vulnerabilità presente su un sistema raggiungibile può facilitare il movimento laterale, l’escalation dei privilegi o l’esecuzione di codice.

Particolarmente delicati sono i sistemi che collegano domini differenti: jump server, workstation di engineering, historian, gateway e piattaforme di accesso remoto possono diventare punti di passaggio verso l’ambiente industriale.

Anche la supply chain può contribuire al rischio. Software di gestione, aggiornamenti, strumenti utilizzati dai fornitori e componenti integrati nei prodotti ampliano infatti il numero di relazioni di fiducia che l’organizzazione deve governare.

La sicurezza della fabbrica dipende quindi anche dalla capacità di identificare quali percorsi possono trasformare una compromissione iniziale in accesso ai sistemi di controllo.

Conseguenze economiche dei fermi impianto e rischi per la sicurezza fisica

Lo sfruttamento di una vulnerabilità OT può produrre effetti molto differenti.

Un attacco può rendere indisponibile una workstation, interrompere le comunicazioni, compromettere la supervisione oppure interferire con le configurazioni dei sistemi di controllo.

Nei casi più gravi, una manipolazione può incidere sul processo fisico.

La presenza di sistemi di safety correttamente progettati rimane essenziale per proteggere persone e impianti, ma anche un arresto sicuro può generare conseguenze economiche importanti.

Ogni ora di fermo può significare produzione persa, ritardi, scarti, costi di ripristino e possibili penali contrattuali.

Per questo la valutazione di una vulnerabilità deve essere correlata alla stima degli asset industriali: comprendere il valore economico e operativo del sistema interessato permette di stabilire quanto una debolezza tecnica possa incidere sul rischio complessivo dell’impresa.

Gestione delle vulnerabilità software e sfide del patching nei contesti industriali

Il vulnerability management OT non può essere ridotto alla sequenza “scopri, patcha, chiudi”.

In molti impianti, tra l’identificazione della vulnerabilità e l’applicazione della correzione esiste un intervallo nel quale devono essere valutati compatibilità, impatto sul processo e disponibilità della finestra di manutenzione.

Durante questo periodo il rischio deve comunque essere gestito.

Il dilemma dell’aggiornamento dei sistemi senza interrompere la continuità operativa

Applicare rapidamente una patch riduce il tempo durante il quale una vulnerabilità rimane sfruttabile, ma un aggiornamento non verificato può introdurre a sua volta problemi operativi.

Il produttore potrebbe richiedere una determinata versione del firmware, l’applicazione industriale potrebbe non essere certificata con il nuovo aggiornamento oppure il riavvio potrebbe richiedere il fermo dell’impianto.

Ne deriva un equilibrio complesso.

Rinviare indefinitamente gli aggiornamenti aumenta l’esposizione cyber; applicarli senza verifiche può mettere a rischio disponibilità e affidabilità della produzione.

La soluzione passa attraverso procedure strutturate: verifica degli advisory del vendor, test quando possibile, pianificazione delle finestre di manutenzione, backup delle configurazioni e definizione di procedure di rollback.

Quando la patch non può essere installata immediatamente, devono essere introdotti controlli compensativi capaci di ridurre temporaneamente il rischio.

Strategie per la valutazione dei rischi e la prioritizzazione delle correzioni

Un elenco ordinato esclusivamente per punteggio CVSS difficilmente rappresenta le priorità reali di un impianto.

Il punteggio tecnico è un’informazione utile, ma deve essere integrato con il contesto.

Occorre considerare se esistano exploit conosciuti o evidenze di sfruttamento, se il sistema sia raggiungibile, quali privilegi siano necessari, quali controlli compensativi siano già presenti e quale processo dipenda dall’asset.

Un difetto con severità elevata su un dispositivo isolato può richiedere una risposta diversa rispetto a una vulnerabilità apparentemente meno grave su un sistema esposto e indispensabile alla produzione.

La priorità dovrebbe quindi derivare dall’incrocio tra severità, sfruttabilità, esposizione, criticità dell’asset e conseguenze sul processo.

In questo modo il vulnerability management smette di essere una corsa al numero di CVE chiuse e diventa un vero processo di riduzione del rischio.

Tecniche e strumenti per la mitigazione dei rischi software in ambiente OT

Non tutte le vulnerabilità possono essere eliminate immediatamente.

La sicurezza industriale deve quindi poter convivere, almeno temporaneamente, con sistemi vulnerabili senza accettarne passivamente il rischio.

Segmentazione, monitoraggio, restrizione degli accessi e altri controlli compensativi servono proprio a ridurre la probabilità e l’impatto di uno sfruttamento.

Monitoraggio continuo delle vulnerabilità note e scansioni di sicurezza non invasive

Il primo requisito è sapere quali asset esistono e quali versioni software utilizzano.

Senza un inventario attendibile, associare advisory e vulnerabilità ai sistemi realmente presenti nell’impianto diventa estremamente difficile.

La discovery deve però essere compatibile con le caratteristiche dell’OT.

Scansioni attive progettate per normali endpoint IT possono produrre comportamenti inattesi su alcuni dispositivi industriali, soprattutto quando si tratta di sistemi datati o particolarmente sensibili.

Per questo il monitoraggio passivo del traffico può rappresentare uno strumento importante per acquisire visibilità senza interrogare direttamente ogni dispositivo.

Quando vengono utilizzate scansioni attive, è opportuno valutarne preventivamente compatibilità e impatto, coordinandole con i responsabili OT e con le indicazioni dei produttori.

Le informazioni raccolte devono poi essere correlate con advisory dei vendor, database delle vulnerabilità e informazioni sull’effettivo sfruttamento delle falle.

La domanda utile non è soltanto quante vulnerabilità possediamo, ma quali di esse rappresentino oggi una minaccia concreta per la produzione.

Segmentazione della rete e controlli di compensazione per i sistemi non aggiornabili

Quando un sistema non può essere aggiornato, la segmentazione diventa uno dei principali strumenti di riduzione dell’esposizione.

Firewall e altri controlli di rete possono limitare le comunicazioni ai soli sistemi necessari, riducendo i percorsi attraverso i quali un attaccante potrebbe raggiungere l’asset.

La protezione può essere ulteriormente rafforzata limitando gli accessi amministrativi, controllando le connessioni remote, disabilitando servizi non necessari e aumentando il monitoraggio sulle comunicazioni.

Queste misure non eliminano la vulnerabilità.

Modificano però le condizioni necessarie per sfruttarla e possono ridurne significativamente il rischio.

Il controllo compensativo deve inoltre essere documentato e periodicamente rivalutato. Se il sistema rimane vulnerabile per anni, l’organizzazione deve verificare che l’architettura di protezione continui a essere efficace rispetto all’evoluzione delle minacce.

L’eccezione non deve trasformarsi in normalità: un sistema non aggiornabile deve avere una strategia di mitigazione e, quando necessario, un percorso di sostituzione.

Quadro normativo e responsabilità della governance per la sicurezza del software

La gestione delle vulnerabilità sta assumendo un ruolo sempre più esplicito nella regolamentazione europea della cyber security.

Per le imprese industriali questo significa considerare la sicurezza del software lungo due prospettive differenti: quella dell’organizzazione che utilizza e gestisce i sistemi e quella dei soggetti che sviluppano o immettono sul mercato prodotti con elementi digitali.

NIS2 e Cyber Resilience Act intervengono rispettivamente su questi piani, con perimetri e destinatari che non devono essere confusi.

Requisiti della direttiva NIS2 e del Cyber Resilience Act sulle vulnerabilità

Per i soggetti che rientrano nel proprio campo di applicazione, la direttiva NIS2 richiede misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi cyber.

L’articolo 21 comprende, tra gli ambiti da considerare, la sicurezza nell’acquisizione, sviluppo e manutenzione dei sistemi, inclusa la gestione e la divulgazione delle vulnerabilità, oltre alla gestione degli incidenti, alla business continuity, alla sicurezza della supply chain e al controllo degli accessi.

Per un’organizzazione industriale significa che il vulnerability management deve essere inserito in un processo strutturato di gestione del rischio.

Il Cyber Resilience Act (Regolamento UE 2024/2847) affronta, invece, il problema dal lato dei prodotti con elementi digitali che rientrano nel suo campo di applicazione.

Il CRA introduce requisiti essenziali di cyber security e obblighi relativi alla gestione delle vulnerabilità durante il periodo di supporto. Il regolamento punta così a evitare che la sicurezza del prodotto termini nel momento in cui questo viene immesso sul mercato.

Per l’OT è un passaggio significativo: disponibilità degli aggiornamenti, gestione delle vulnerabilità e trasparenza sul supporto diventano fattori sempre più importanti nella scelta delle tecnologie industriali.

NIS2 e CRA costruiscono quindi una responsabilità distribuita: chi utilizza la tecnologia deve governarne il rischio e chi realizza prodotti soggetti al CRA deve integrare requisiti di cybersecurity e gestione delle vulnerabilità lungo il ciclo di vita previsto dalla normativa.

Applicazione degli standard IEC 62443 per la gestione della sicurezza del software

La famiglia IEC 62443 permette di inserire la sicurezza del software all’interno di un modello specificamente progettato per i sistemi di automazione e controllo industriale.

Particolarmente rilevante è la distinzione tra responsabilità dell’asset owner, requisiti del sistema e sicurezza dei componenti.

IEC 62443-4-1 affronta il secure product development lifecycle, definendo requisiti per processi di sviluppo sicuro dei prodotti destinati agli ambienti industriali.

IEC 62443-4-2 riguarda invece i requisiti tecnici di sicurezza dei componenti IACS.

Per l’asset owner, la famiglia IEC 62443 offre inoltre principi attraverso i quali valutare il rischio dell’architettura, definire zone e conduits e stabilire requisiti coerenti con la criticità dei sistemi.

Questa separazione delle responsabilità è particolarmente importante per il vulnerability management.

L’utilizzatore industriale non può correggere autonomamente ogni vulnerabilità presente nel firmware di un dispositivo, così come il produttore non può conoscere tutte le condizioni nelle quali quel componente verrà installato.

La sicurezza nasce quindi dalla combinazione di secure development, gestione delle vulnerabilità da parte del vendor, architettura sicura e processi di risk management dell’utilizzatore.

È qui che cambia anche il significato delle vulnerabilità software in fabbrica.

Una CVE non rappresenta da sola il rischio. È un’informazione che deve essere inserita nel contesto del processo industriale.

Sapere che una falla esiste è il punto di partenza. Occorre poi capire se può essere raggiunta, se viene sfruttata attivamente, quale sistema interessa, quali conseguenze avrebbe una compromissione e quali misure siano disponibili per ridurre il rischio.

In alcuni casi la risposta sarà applicare immediatamente una patch. In altri sarà segmentare il sistema, limitarne gli accessi e monitorarlo in attesa della prima finestra di manutenzione disponibile. Nei casi in cui il supporto sia terminato, potrebbe diventare necessario pianificarne la sostituzione.

La maturità del vulnerability management OT non si misura quindi sul numero assoluto di aggiornamenti installati, ma sulla capacità di individuare per prime le vulnerabilità che possono realmente mettere a rischio la produzione e intervenire prima che diventino un incidente.