Per molto tempo, nelle aziende industriali la cybersicurezza è stata considerata parte dell’informatica d’ufficio. Firewall, antivirus, password, backup — mentre il sistema produttivo o energetico funzionava separatamente, secondo una propria logica tecnica.

Con la convergenza di IT e OT questa linea di demarcazione è scomparsa. PLC, inverter, automazione degli edifici, SCADA, gateway e connessioni di assistenza remota possono oggi far parte dello stesso spazio di rischio digitale. Le conseguenze, però, restano fisiche: produzione ferma, regolazione errata, interruzione dell’approvvigionamento energetico o servizi non disponibili.

Per questo la NIS2 porta la gestione del rischio cyber a livello dirigenziale e organizzativo. La IEC 62443, a sua volta, offre un approccio alla sicurezza industriale e un sistema di requisiti con cui mettere ordine nell’ambiente OT anche dal punto di vista tecnico.

La NIS2 non è una lista della spesa tecnologica

La direttiva NIS2 dell’Unione europea ha creato un quadro di cybersicurezza più uniforme per 18 settori critici. Le medie e grandi imprese che rientrano nel suo ambito di applicazione devono adottare misure adeguate di gestione del rischio e processi di notifica degli incidenti. La direttiva sottolinea inoltre in modo esplicito la responsabilità dei vertici aziendali.

È un cambiamento importante: la cybersicurezza non può essere delegata senza limiti a un amministratore di sistema o a un fornitore esterno. La direzione deve comprendere e gestire quali dipendenze digitali mettono a rischio l’operatività essenziale.

La NIS2 non stabilisce quale firewall di quale produttore acquistare. Richiede un modo di operare basato sul rischio, che comprende tra l’altro:

  • gestione degli incidenti;
  • continuità operativa e ripristino;
  • sicurezza della catena di approvvigionamento;
  • gestione delle vulnerabilità;
  • controllo degli accessi;
  • crittografia e sicurezza delle comunicazioni;
  • consapevolezza in materia di sicurezza;
  • valutazione dell’efficacia delle misure.

Se una determinata organizzazione rientri effettivamente nell’ambito di applicazione e quali requisiti nazionali le si applichino (in Ungheria la NIS2 è recepita dalla legge XXIII del 2023) deve essere stabilito caso per caso, in base al settore, alle dimensioni, al servizio e al diritto nazionale applicabile. La gestione dei rischi tecnici resta comunque nell’interesse dell’impresa, anche se alla fine questa non risulta soggetta agli obblighi.

Perché il rischio OT è particolare?

I sistemi OT hanno cicli di vita lunghi. Non sono rari impianti di dieci o vent’anni, sistemi operativi non più supportati o controllori difficili da aggiornare senza fermare la produzione.

Inoltre, nell’OT:

  • la disponibilità e la sicurezza fisica hanno la priorità;
  • le modifiche vanno testate a causa del rischio di processo;
  • molti dispositivi non sono mai stati progettati per un ambiente di rete ostile;
  • l’accesso remoto da parte del produttore o del manutentore è frequente;
  • l’inventario degli asset è spesso incompleto;
  • la responsabilità è suddivisa tra IT, automazione, esercizio e fornitori.

Per questo non basta ricopiare una policy di sicurezza IT tradizionale.

Il ruolo della IEC 62443

La serie di norme ISA/IEC 62443 affronta la cybersicurezza dei sistemi di automazione e controllo industriale lungo l’intero ciclo di vita. Non si rivolge soltanto al gestore: definisce requisiti e ruoli anche per il produttore dei dispositivi, l’integratore di sistema e il proprietario dell’asset (asset owner).

Uno dei cardini dell’approccio è la definizione di zone basate sul rischio e di collegamenti di comunicazione regolamentati (conduit) tra di esse.

In una zona possono rientrare dispositivi con rischi ed esigenze di sicurezza simili. Il flusso di dati tra le zone può avvenire solo attraverso percorsi e protocolli definiti e secondo regole stabilite.

Questo modo di ragionare è molto più preciso di “abbiamo un firewall verso internet”. L’attacco o il guasto, infatti, può partire anche dall’interno: da una connessione di manutenzione remota, dal portatile di un fornitore o da un sistema IT compromesso.

Il primo compito scomodo: l’inventario dei dispositivi e delle connessioni dati

Non si può proteggere ciò che non si sa di avere.

Il primo passo concreto della sicurezza OT, quindi, di solito non è installare un nuovo prodotto, ma mappare l’ambiente reale:

  • quali PLC, HMI, contatori, inverter e gateway sono in funzione;
  • con quale versione di firmware e software;
  • su quale rete sono raggiungibili;
  • con chi comunicano e con quale protocollo;
  • chi può accedervi in locale e da remoto;
  • quale processo aziendale o fisico dipende da essi;
  • che cosa succede in caso di guasto o compromissione.

L’inventario non deve restare un file Excel statico. Conviene collegare a un sistema tracciabile anche le modifiche, le responsabilità, gli eventi e i documenti.

L’accesso remoto è un tipico punto debole

I sistemi industriali richiedono spesso il supporto del produttore o dell’integratore. Il problema non è l’accesso remoto in sé, ma l’accesso incontrollato, permanente e diretto.

Una soluzione difendibile deve stabilire:

  • chi può avviare la connessione;
  • se è necessaria l’autenticazione a più fattori;
  • quale sistema specifico è raggiungibile;
  • in quale finestra temporale;
  • se è necessaria un’approvazione locale o della direzione;
  • se la sessione può essere registrata;
  • come si può revocare l’autorizzazione;
  • che cosa accade alla cessazione del contratto con il fornitore.

Una soluzione del tipo “AnyDesk è installato sulla macchina, se serve” è comoda, ma non è un’architettura di sicurezza.

La catena di fornitura fa parte dell’OT

In un sistema industriale la sicurezza non dipende soltanto dal proprio team. Il produttore dell’hardware, il fornitore del firmware, l’integratore, l’operatore di telecomunicazioni e la piattaforma cloud possono tutti far parte della catena del rischio.

Per questo, nelle specifiche tecniche e nei contratti dovrebbero figurare, ad esempio:

  • il periodo di supporto e di aggiornamento;
  • le modalità di segnalazione delle vulnerabilità;
  • i requisiti di accesso e di registrazione;
  • le informazioni su componenti e versioni;
  • la collaborazione durante un incidente;
  • la restituzione di dati e configurazioni.

È qui che la visione della NIS2 sulla catena di approvvigionamento incontra l’approccio della IEC 62443 basato sul ciclo di vita e sui ruoli.

Sicurezza che funziona, non solo conformità

Spuntare una checklist di audit non ferma, di per sé, un attacco. Il vero obiettivo è che l’organizzazione conosca i propri processi critici, riduca la superficie di attacco, rilevi le anomalie, ne limiti la propagazione e sia in grado di ripristinare l’operatività in modo dimostrabile.

In questo contesto OrigSmart non va intesa come una semplice piattaforma di visualizzazione dei dati. La gestione congiunta di dispositivi di campo, gateway, connessioni di rete, identità, eventi e processi eseguibili aiuta a trasformare i requisiti di sicurezza in funzionamento tecnico.

Nei progetti gestiti da OrigSmart la sicurezza va progettata come parte dell’architettura: connessioni segmentate, privilegio minimo necessario, eventi registrati, accesso remoto controllato, funzionamento locale di fallback e azioni tracciabili.

La NIS2 chiarisce che il rischio cyber va preso sul serio a livello organizzativo. La IEC 62443 aiuta a tradurlo nella realtà tecnica dei sistemi OT.

Parliamo del vostro progetto

Fonti

Nota: l’articolo ha carattere informativo generale e non costituisce consulenza legale o in materia di conformità.