Progettazione di applicazioni HMI/SCADA orientata alla sicurezza informatica: principi che riducono il rischio già in fase di progettazione

La sicurezza delle applicazioni HMI/SCADA si gioca molto prima della scelta dei meccanismi di protezione. La capacità del sistema di resistere a errori, abusi e variazioni incontrollate dello stato del processo dipende anzitutto dalle ipotesi adottate in fase di progettazione: distribuzione dei ruoli, confini di fiducia, perimetro delle funzioni accessibili dall’interfaccia e modalità di organizzazione dell’assistenza e dell’accesso remoto. Se questi aspetti vengono considerati secondari, l’applicazione finisce per cristallizzare il rischio invece di ridurlo. Per questo la progettazione di HMI/SCADA in ottica di cybersicurezza va trattata come un compito ingegneristico: prima bisogna definire quali operazioni sono critiche, quali effetti possono produrre e chi debba realmente poterle eseguire; solo dopo si possono sviluppare schermate, allarmi e facilità d’uso.

La cybersicurezza inizia dal progetto

Nei sistemi HMI/SCADA la cybersicurezza non è un’aggiunta a una visualizzazione già pronta. Nasce da decisioni prese in precedenza: dall’architettura dell’applicazione, dal modello di autorizzazioni, dal modo in cui comunica con il controllo e dalle ipotesi previste per l’assistenza. Questo aspetto è particolarmente importante, perché l’applicazione HMI/SCADA è al tempo stesso il punto di contatto tra persona, processo e infrastruttura. Un errore di progettazione, quindi, non si limita a generare un rischio informatico. Può incidere contemporaneamente sulla risposta dell’operatore, sulla sicurezza funzionale, sul rischio operativo e sulla continuità della produzione.

Dal punto di vista del progetto, la domanda fondamentale non è quindi quale protezione aggiungere alla fine, ma quali decisioni adottare fin dall’inizio per ridurre la superficie di attacco. I problemi più gravi, di norma, non derivano dall’assenza di un singolo meccanismo, ma da un eccesso di fiducia incorporato nell’applicazione. In pratica, questo significa account utente condivisi, accesso di assistenza ampio e permanente, assenza di separazione dei ruoli tra operatore, manutenzione e integratore, nonché una comunicazione troppo libera tra il livello operatore e il controllo. Nella fase di avviamento, soluzioni di questo tipo sembrano comode, perché accelerano le attività e facilitano la diagnostica. In seguito, però, diventano una caratteristica stabile dell’ambiente e aumentano il rischio di abuso, errore o modifica incontrollata dello stato del processo.

Per questo, prima di progettare le schermate, conviene definire non solo che cosa l’utente debba vedere, ma soprattutto dove si collocano i confini di fiducia, quali operazioni sono critiche e in quali punti l’interfaccia può trasformarsi in uno strumento di errore o di aggiramento della procedura. Questo ordine aiuta a impostare le decisioni successive: se l’HMI debba essere esclusivamente un livello di visualizzazione oppure anche un punto di configurazione, diagnostica e modifica delle ricette; se le funzioni di assistenza debbano essere sempre attive oppure disponibili solo dopo un’attivazione consapevole; se l’operatore debba avere accesso soltanto alla conduzione del processo oppure anche a operazioni che modificano parametri e storico dei dati.

Il costo concreto delle carenze emerge di solito solo quando l’applicazione è già collegata a ricette, allarmi, reportistica, archiviazione e procedure di manutenzione. A quel punto anche una correzione apparentemente semplice, come separare gli account, modificare il percorso di approvazione di un’operazione critica o limitare l’accesso remoto a un uso occasionale, smette di essere una semplice modifica delle schermate. Richiede una revisione della logica, nuovi test della gestione degli allarmi, la definizione delle responsabilità e spesso anche cambiamenti organizzativi nello stabilimento.

In pratica, il punto di partenza più ragionevole è una mappa operativa dei ruoli utente e delle relative autorizzazioni sulle operazioni critiche, un elenco delle funzioni che comportano una modifica dello stato del processo, della configurazione o delle ricette, nonché un quadro dei collegamenti esterni che comprenda assistenza, reportistica, sistemi di livello superiore e accesso remoto. Solo su questa base è possibile progettare in modo sensato l’architettura delle zone e delle connessioni nell’automazione industriale e preparare la successiva analisi del rischio. Un approccio di questo tipo è coerente sia con la pratica ingegneristica sia con l’esigenza di definire con chiarezza le responsabilità, separare le funzioni e controllare le comunicazioni negli ambienti industriali.

Dove crescono davvero costi e rischi

I costi e i rischi maggiori in un’applicazione HMI/SCADA non derivano esclusivamente dal semplice fatto che i sistemi siano collegati, ma dagli effetti di processo e organizzativi generati dalle singole funzioni dell’applicazione. I punti più sensibili sono quelli che consentono di modificare rapidamente i setpoint, introdurre un bypass, silenziare un allarme, cambiare una ricetta oppure eseguire un comando manuale senza il pieno contesto tecnologico. Se il progetto consente tali operazioni dalla schermata di produzione in modalità ordinaria, il rischio aumenta perché una sola decisione dell’utente o una singola sessione compromessa può modificare direttamente lo stato del processo, con impatto anche sulle linee di produzione e tecnologiche.

Questo significa che il catalogo delle operazioni critiche va considerato come un elemento dell’architettura di sicurezza, e non soltanto come una questione di ergonomia dell’interfaccia. Lo stesso principio vale per la tracciabilità delle azioni. Login condivisi, account usati dall’intero turno, assenza di separazione tra permessi di lettura, comando, configurazione e amministrazione, nonché una registrazione degli eventi insufficiente, fanno sì che dopo un incidente sia difficile stabilire con attendibilità se si sia trattato di un errore, di un aggiramento della procedura, di un abuso dell’accesso di servizio o di un’azione non autorizzata. Il problema non riguarda solo l’accertamento delle cause. Senza una traccia affidabile delle attività dell’utente non è possibile nemmeno valutare l’efficacia delle procedure, gestire in modo sensato i permessi o giustificare le decisioni operative davanti a un audit interno, alle richieste del cliente o alle politiche di sicurezza adottate. In pratica, qui si parla di responsabilità delle azioni e tracciabilità, non del solo salvataggio degli eventi.

Un errore di progettazione molto costoso consiste anche nel trasferire nell’ambiente produttivo schermate di servizio e diagnostica complesse, inizialmente predisposte per la messa in servizio o per il supporto dell’integratore. Queste viste spesso offrono un ampio accesso a variabili interne, forzature di stato, azzeramento di blocchi e modifica di parametri, pur essendo necessarie nell’esercizio normale solo in casi sporadici. Se non vengono sottoposte a ulteriori limitazioni, diventano la via più rapida per intervenire sul processo al di fuori del normale percorso operativo. Una soluzione ragionevole consiste nel separare la diagnostica necessaria alla manutenzione dalle funzioni che consentono di intervenire sulla logica di funzionamento, e nel decidere separatamente se la diagnostica del costruttore della macchina debba essere disponibile in locale, da remoto oppure solo in modo condizionato, dopo un’attivazione consapevole e con registrazione completa della sessione.

Allo stesso modo va trattata l’integrazione con basi di dati, sistemi di reportistica, supporto remoto e sistemi d’ufficio. Ogni collegamento di questo tipo migliora la comodità operativa, ma allo stesso tempo aumenta il numero di dipendenze che possono diventare una via di accesso, una fonte di disturbi o una causa di perdita di chiarezza nelle responsabilità. Il guasto di un servizio intermedio, una sincronizzazione errata dell’ora, uno scambio di dati non controllato con il sistema di livello superiore o un canale di servizio lasciato aperto possono influire non solo sulla disponibilità dei report, ma anche sulle decisioni prese dall’operatore.

Per questo motivo, già in fase di progetto conviene misurare non solo la disponibilità delle schermate, ma anche indicatori più semplici e più utili: il numero di operazioni critiche eseguibili dal livello HMI di produzione, il numero di connessioni esterne attive, il numero di account privilegiati e l’estensione degli eventi coperti dalla traccia di audit. Una verifica di questo tipo mette poi ordine nella registrazione degli eventi, nel controllo delle modifiche dei parametri e nelle regole di accesso remoto.

Un trattamento a parte merita la gestione degli allarmi. In quest’area, una completezza solo apparente spesso nasconde una reale mancanza di controllo. Allarmi progettati male e una cronologia eventi poco efficace non solo sovraccaricano l’operatore, ma gli tolgono anche la capacità di distinguere i segnali critici dal rumore tecnico. Se un allarme può essere facilmente silenziato senza giustificazione, confermato senza alcun riferimento alla causa oppure perso in mezzo a una massa di messaggi diagnostici, l’applicazione smette di supportare la sicurezza del processo. Perciò le priorità degli allarmi dovrebbero derivare dall’effetto reale su persone, macchina e qualità della produzione, e restare collegate alle regole di registrazione delle conferme, degli aggiramenti e delle modifiche dei setpoint. È proprio questo il momento in cui l’analisi del rischio smette di essere un documento formale e comincia a plasmare l’interfaccia.

Come progettare per limitare gli effetti dell’errore e dell’abuso

Il punto di partenza è semplice: un’applicazione HMI/SCADA non può presumere che ogni utente operi sempre correttamente e nel giusto contesto di processo. La progettazione va avviata partendo dalla separazione delle funzioni, non dal disegno delle schermate. Il team dovrebbe prima stabilire che cosa l’operatore debba soltanto vedere, che cosa possa confermare, che cosa gli sia consentito modificare nel normale flusso di lavoro e quali azioni, invece, debbano essere spostate in modalità di servizio, sottoposte a un’autorizzazione aggiuntiva oppure completamente separate in uno strumento o in una postazione dedicata.

Questa decisione mette ordine nell’intera architettura degli accessi: ruoli, ambito dei permessi, modalità di registrazione delle attività e condizioni del supporto remoto. Nella pratica funziona bene una matrice dei ruoli basata sulle responsabilità reali, che distingua operatore, capoturno, manutenzione, tecnologo, integratore e amministratore. Non è una formalità. Se le funzioni di servizio restano sulla stessa schermata e sotto lo stesso account usato per la conduzione del processo, l’applicazione crea da sola una via verso l’errore, l’aggiramento della procedura o l’abuso dei privilegi.

Un buon HMI/SCADA limita la possibilità di eseguire per errore un’operazione pericolosa, ma non rallenta inutilmente le attività di routine. Questo richiede un contesto operativo chiaro: l’utente deve vedere su quale impianto sta lavorando, in quale stato si trova il processo, se sta operando in locale o da remoto e se il sistema è in modalità automatica, manuale o di servizio. Le conferme devono essere proporzionate al rischio, non uguali per tutte le azioni. Dove l’effetto dell’errore è reversibile e limitato, di norma è sufficiente una singola autorizzazione. Le operazioni critiche richiedono un controllo aggiuntivo: una seconda conferma, una nuova autenticazione, una dipendenza dallo stato del processo oppure il passaggio fisico a un’interfaccia separata.

Sono importanti anche i blocchi condizionati. Se l’applicazione consente di modificare un setpoint, forzare un segnale o passare in modalità manuale indipendentemente dallo stato dell’impianto, il rischio viene trasferito dal progetto all’operatore. È proprio qui che si vede come una corretta progettazione dell’interfaccia non riguardi soltanto la comodità d’uso, ma anche la limitazione degli effetti dell’errore tramite barriere integrate. In molti casi, questo modo di ragionare è vicino a quello con cui opera il Poka-Yoke nelle linee di produzione.

La progettazione dell’accesso su più livelli dovrebbe comprendere anche le modalità di utilizzo delle autorizzazioni nel tempo. Gli account individuali sono necessari ovunque sia richiesta la tracciabilità delle azioni. Un account condiviso elimina la possibilità di stabilire chi abbia effettivamente preso una decisione. Il principio del privilegio minimo significa che l’utente dispone solo delle funzioni necessarie per il lavoro corrente, mentre l’elevazione dei privilegi avviene in modo temporaneo e in condizioni controllate. Questo vale in particolare per la manutenzione, per l’integratore e per il supporto remoto del produttore. Un canale di assistenza sempre aperto è comodo solo in apparenza, perché annulla il naturale confine di fiducia tra esercizio e assistenza. Un modello più sicuro è quello dell’accesso attivato su richiesta, limitato nel tempo, assegnato a una persona specifica e registrato nella cronologia degli eventi. Questo approccio si inserisce bene nel principio del privilegio minimo e nella segmentazione degli accessi.

Nello stesso spirito occorre decidere se le funzioni di assistenza debbano essere disponibili dall’HMI operativo oppure esclusivamente da una postazione separata, e se consentire supporti rimovibili e l’importazione o l’esportazione locale dei dati dal pannello operatore. Queste decisioni non sono secondarie. Da esse dipende se la manutenibilità del sistema sarà gestita in modo controllato oppure tramite soluzioni estemporanee.

Dal punto di vista di un incidente o di una contestazione in esercizio, la sola interfaccia non basta. L’applicazione deve lasciare elementi che consentano di ricostruire il processo decisionale. La cronologia degli eventi, i log di sistema e la registrazione delle modifiche dovrebbero rispondere insieme non solo alla domanda su che cosa sia accaduto, ma anche su chi abbia eseguito l’operazione, quando, da quale postazione e in quale stato del processo. L’insieme minimo degli eventi che in genere vale la pena registrare comprende l’accesso al sistema, la modifica dei privilegi, la modifica dei parametri, il passaggio in modalità manuale, la conferma di un allarme e l’importazione della configurazione. È fondamentale collegare la registrazione al contesto tecnologico, perché la sola informazione sulla modifica, senza lo stato dell’impianto, può risultare inutile.

Un buon esempio, tipico di molte implementazioni, è il seguente: la modifica della soglia di allarme da parte del tecnologo può essere ammessa, ma solo dopo l’ingresso nella modalità prevista, con registrazione dell’utente, della postazione, dell’ora, del valore precedente e di quello nuovo, oltre alla conferma che l’impianto non si trovasse in uno stato critico. Una traccia di questo tipo è importante sia per la sicurezza sia per la gestione delle modifiche nelle applicazioni industriali.

L’ultimo livello è la manutenibilità senza aggirare le protezioni. Se un aggiornamento, il ripristino della configurazione o la diagnostica richiedono la disattivazione del controllo degli accessi, l’uso di una password condivisa o attività prive di traccia di audit, il problema sta nel progetto e non nella disciplina del personale. L’applicazione dovrebbe prevedere un iter di modifica definito: richiesta, valutazione dell’impatto, test, implementazione, conferma e piano di rollback. Dovrebbe inoltre separare l’ambiente operativo da quello di assistenza almeno sul piano logico e, dove giustificato, anche su quello organizzativo e tecnico. Le copie della configurazione devono poter essere eseguite e ripristinate in modo controllato, senza esportazioni estemporanee “per sicurezza” dal pannello. Questo approccio è coerente con il principio del privilegio minimo in OT e con i requisiti relativi al controllo degli accessi, alla tracciabilità delle azioni e alla gestione delle modifiche, fermo restando che il loro ambito va sempre riferito all’architettura del sistema e alla ripartizione delle responsabilità adottata.

Pratica di implementazione e riferimento ai requisiti

Il risultato migliore non si ottiene aggiungendo ulteriori meccanismi di protezione alla fine del progetto, ma attraverso una revisione strutturata dell’applicazione prima del collaudo o dell’ammodernamento. È il momento in cui si può ancora correggere, con costi relativamente contenuti, il modo in cui il sistema opera, invece di dover poi compensare presupposti errati con procedure aggiuntive. Una revisione di questo tipo dovrebbe essere condotta da un gruppo misto: progettazione, manutenzione, esercizio, specialista dell’automazione e figure responsabili della sicurezza.

L’oggetto della valutazione non è soltanto la configurazione tecnica, ma anche il fatto che l’applicazione separi realmente i ruoli, protegga le operazioni critiche, limiti l’accesso remoto ai casi giustificati, garantisca una gestione chiara degli allarmi, conservi la cronologia delle modifiche e consenta di eseguire copie e procedure di emergenza senza aggirare le protezioni. È proprio da una revisione di questo tipo che dovrebbero derivare l’elenco per il FAT/SAT e i requisiti da inserire nel collaudo, nel piano di assistenza e nella documentazione as-built.

Questo approccio sposta il baricentro dalla discussione sulle sole misure di protezione alle scelte progettuali che, in seguito, determinano il comportamento delle persone e dei dispositivi. Se già in fase di progetto non si stabilisce chi può modificare i parametri delle ricette, chi autorizza la modalità di servizio, come viene registrato l’intervento dell’integratore e a quali condizioni è consentito l’accesso dall’esterno dello stabilimento, dopo la messa in servizio il sistema finirà per basarsi su eccezioni e accordi verbali. In questo senso, includere la cybersicurezza nella gestione del progetto fin dall’inizio aiuta a evitare soluzioni improvvisate in fase operativa.

Per lo stesso motivo, conviene decidere se valutare l’applicazione nell’ambito dell’ammodernamento della macchina o della linea, oppure come verifica OT separata. Il primo approccio collega meglio la sicurezza alla funzione del processo, il secondo facilita l’individuazione delle dipendenze tra sistemi e la ripartizione delle responsabilità per account, autorizzazioni e registrazione delle attività. Questo è anche il contesto naturale per una prima analisi del rischio: identificazione delle operazioni critiche, dei confini di fiducia e delle conseguenze di un errore dell’operatore o di un uso improprio. In pratica, può essere utile anche un’analisi del rischio nel progetto di ammodernamento della macchina.

• ruoli e modalità di accesso degli utenti,
• operazioni critiche e regole per la loro conferma,
• accesso remoto e funzioni di servizio,
• allarmi, registrazione delle modifiche e tracciabilità delle azioni,
• copie di backup, ripristino e procedure di emergenza.

In stabilimento, un buon risultato raramente deriva dall’introduzione simultanea di molti strumenti. Di norma conta di più eliminare alcuni rischi sistemici che per anni sono stati considerati pratici. L’ammodernamento dell’applicazione HMI/SCADA può iniziare dall’eliminazione degli account condivisi, dalla separazione delle funzioni di servizio da quelle operative, dalla limitazione delle connessioni esterne a percorsi controllati e dall’attivazione della tracciabilità delle modifiche dei parametri con attribuzione a una persona o a un ruolo specifico. Un cambiamento di questo tipo non deve necessariamente peggiorare il lavoro della manutenzione né quello dell’integratore, purché fin dall’inizio siano stati previsti la modalità di servizio, le regole di autorizzazione e un iter delle modifiche riproducibile.

Durante l’esercizio conviene poi misurare non un livello astratto di sicurezza, ma indicatori utili dal punto di vista operativo: il numero di account condivisi ancora presenti nel sistema, l’estensione dell’accesso remoto attivo, la completezza dei registri delle modifiche, il tempo di ripristino della configurazione e il numero di interventi eseguiti al di fuori della procedura formale. Indicatori di questo tipo permettono di valutare se il progetto ha realmente ridotto il rischio oppure se lo ha soltanto trasferito nella pratica quotidiana.

Nel contesto polacco e dell’Unione europea è sempre più difficile sostenere un approccio in cui la cybersicurezza HMI/SCADA sia una questione esclusiva del reparto IT. La responsabilità è distribuita tra progettazione, esercizio, manutenzione, fornitori e integratori, e i requisiti di settore e contrattuali assumono valore solo quando l’organizzazione è in grado di mostrare elementi concreti: quali decisioni progettuali sono state prese, come vengono assegnate le autorizzazioni, quale tracciabilità delle attività esiste e chi controlla le modifiche. I soli richiami a norme, politiche o clausole contrattuali non sostituiscono la prova che l’applicazione sia stata progettata e accettata in modo da consentire un esercizio sicuro.

La conclusione più importante è di natura pratica. Il momento meno costoso e più efficace per ridurre il rischio resta la progettazione e l’accettazione dell’applicazione. È in questa fase che, con il minimo costo, si definiscono i confini di fiducia, i ruoli, le condizioni di accesso, la tracciabilità delle attività e le modalità di gestione delle modifiche. Se questi requisiti vengono tradotti in criteri verificabili nei confronti del fornitore e dell’integratore, HMI/SCADA smette di essere un’interfaccia comoda ma eccessivamente fiduciosa e diventa uno strumento per l’esercizio sicuro del processo.