Introduzione

La situazione attuale ha come tendenza quello di integrare ed interconnettere sempre più la parte di IT (Information Technology) e la parte di OT (Operational Technology). Lo scopo è quello di rendere le comunicazioni sempre più efficaci, automatiche e veloci tra le diverse funzioni aziendali, usando, pertanto, i dati ottenuti direttamente dalla produzione verso i sistemi informativi aziendali che necessitano di avere i dati di produzione per poter consuntivare, progettare, manutenere e diagnosticare la produzione ed il processo.

Questo apre il fianco a possibili punti deboli nel mondo dell’OT ad aspetti legati alla cyber security, perché fino a quando l’infrastruttura di comunicazione del mondo IT e del mondo automazione OT erano separate il sistema di automazione era reso sicuro dalla separazione fisica dei due ambienti che non potevano fisicamente comunicare l’uno con l’altro, mentre oggi condividendo l’infrastruttura di comunicazione ed implementando uno scambio bidirezionale il sistema di automazione risulta esposto a nuove minacce e vulnerabilità che possono essere sfruttate per violare la sicurezza dei dati (la cyber security del sistema); inoltre era in vigore il paradigma security through obscurity, che si basa sul concetto cui se non si conosce il funzionamento del sistema non si conoscono le falle di sicurezza, anche questo abbandonato per la fallace che non si sa se il sistema non è conosciuto, soprattutto se il sistema è datato, è sicuramente possibile che una retroingegnerizzazione sia stata eseguita nel tentativo di conoscere il sistema.

Venuti meno i principi sopra, la tendenza odierna è quella di garantire una security by design implementano ed utilizzando algoritmi che siano verificati matematicamente essere troppo complessi da risolvere, per riuscire ad ottenere informazioni sensibili quando queste sono in corso di validità ed utilizzo, ovvero prima che risultino inutili, tenendo conto della potenza computazionale disponibile nel periodo in valutazione.

Con il termine di cyber security si intende la protezione dei dati che viene raggiunta quando sono soddisfatti i seguenti requisiti:

  • Autenticazione: abilità di dimostrare la propria identità
  • Autorizzazione: un utente autenticato deve svolgere solo le azioni di sua competenza
  • Confidenzialità: garanzia che i dati non siano accessibili a utenti non autorizzati
  • Disponibilità: garanzia che il sistema sia disponibile per un periodo di tempo definito a priori
  • Integrità: garanzia che i dati non siano modificati da utenti non autorizzati
  • Non-ripudio: abilità di dimostrare che un’azione è stata compiuta da un determinato utente

Questo implica che i sistemi di automazione e di comunicazione siano adeguatamente protetti per garantire la protezione dei dati. In questo scenario viene ad inserirsi la famiglia delle norme IEC 62433 il cui titolo è “Reti di comunicazione industriale – Security di rete e di sistema” e che offre un approccio sistematico per poter raggiungere i desiderata per la protezione dei dati.

Questo articolo ha lo scopo di fornire una panoramica sulla struttura della norma, i ruoli coinvolti nella security e le implementazioni di sicurezza da implementare a seconda del livello di sicurezza che si vuole raggiungere.

La norma IEC 62443

La norma IEC 62443 è composta da diverse pubblicazioni e le pubblicazioni sono a loro volta organizzate in diversi livelli, ognuno specifico per la propria funzione, come rappresentato in Figura 1.

Figura 1: La struttura della IEC 62443

Le IEC 62443 sono organizzate in quattro diverse famiglie:

  • IEC 62443-1: definisce la terminologia, i concetti e i modelli per la sicurezza di un sistema di automazione
  • IEC 62443-2: definisce gli elementi necessari a stabilire un sistema di gestione della sicurezza informatica per i sistemi di automazione
  • IEC 62443 – 3: definisce le attività da svolgersi per poter garantire ed ottenere un determinato livello di security, partendo dalla definizione di quali siano le tecnologie di security implementabili arrivando alla definizione delle misure da adottare su un sistema passando attraverso la valutazione del rischio
  • IEC 62443-4: definisce le attività da svolgersi per la gestione sicura di tutto il ciclo di vita di un dispositivo (sia hardware sia software) per un sistema di automazione oltre a definire quali siano le misure di sicurezza da implementare a bordo di un device per poter aggiungere determinate condizioni di security.

La security è definita come un processo che coinvolge diverse cose: risorse umane, processi, procedure e soluzioni tecnologiche. Per questo la normativa definisce due indicatori che consentano di quantificare sia la parte documentale sia la parte di implementazione tecnologica su sistemi e device.

Per la valutazione della documentazione del sistema di gestione di un’azienda la normativa definisce un indicatore chiamato Maturity Level (ML) che rappresenta il livello di maturità raggiunto dall’azienda nella preparazione, implementazione e rispetto delle policy e delle procedure relative alla security:

  • ML1: i processi correlati alla security sono sviluppati ad hoc e non sono ancora documentati
  • ML2: i processi correlati alla security sono documentati ma non sono necessariamente ripetibili.
  • ML3: i processi correlati alla security sono documentati, sono ripetibili e vengono seguiti e rispettati dal personale
  • ML4: i processi correlati alla security sono documentati, sono ripetibili e vengono seguiti e rispettati dal personale. Inoltre, le performance associate ai processi sono costantemente monitorate e sono misurate oltre che costantemente

L’indicatore per la valutazione delle performance di sistemi e di dispositivi è il Security Level (SL) che rappresenta anche un’indicazione di quali siano le minacce a cui è esposto il target:

  • SL0: non è richiesta protezione
  • SL1: protezione contro i danni accidentali o il malfunzionamento
  • SL2: protezione contro i datti intenzionali realizzati da persone con poche risorse, competenze nella media e motivazione non particolarmente forte
  • SL3: protezione contro i datti intenzionali realizzati da persone con risorse medie, competenze buone e motivazione media
  • SL4: protezione contro i datti intenzionali realizzati da persone con risorse elevate, competenze eccellente e motivazione elevatissima

I ruoli coinvolti nella security

La normativa IEC 62443 oltre a definire dei requisiti per i sistemi di gestione (con i Maturity Level) e per i sistemi/dispositivi (con i Security Level) prevede che siano coinvolte anche le figure che concorrono ad ottenere la security. Infatti, la security può essere definita come un processo e come tale vi sono dei requisiti tecnici e tecnologici ma devono essere coinvolte anche le persone.

In quest’ottica, la normativa prevede la definizione di tre ruoli:

  • Il fornitore dei dispositivi
  • L’assett owner che rappresenta il proprietario del sistema o dell’impianto
  • Il service provider, che è il personale dell’azienda che fornisce servizi all’azienda presso cui il sistema è installato, quindi sia le aziende di system integration sia le aziende che offrono servizi di manutenzione e di monitoraggio

Figura 2: I ruoli e le norme di riferimento

Questo implica che per ognuno dei ruoli indentificati vi sia, almeno, da parte dell’azienda la stesura di un sistema di gestione e la sua implementazione al fine di poter gestire e garantire il rischio in modo consapevole.

A questo punto diventa, poi, importante avere figure professionali che siano formate ed informate sulla gestione dei rischi relativi alla security e su come devono essere svolte le attività.

Come valutare la security di un sistema e di un device

Essendo i vari requisiti spesso di tipo funzionale, e i dispositivi e sistemi presi in considerazione spesso eterogenei nella forma e nel software, purtroppo non esiste un software che in autonomia possa verificare tutti i requisiti proposti dalla norma. Inoltre, vari requisiti pretendono esplicitamente un corredo documentale.

Partendo dai requisiti di sicurezza proposti dalla norma vengono testate le funzionalità del sistema, e si giudica se queste sono svolte in “modo sicuro”, e con quale livello di sicurezza sono accomunabili le procedure in uso. Per fare questo vengono identificate tutte le interfacce di comunicazione rese disponibili dal dispositivo o sistema ed una ad una vengono analizzate le dinamiche di comunicazione per verificare se effettivamente vengono svolte in modo sicuro o meno.

Sempre grazie allo standard il produttore di un prodotto o sistema è spinto a comunicare e dettagliare tutte le interfacce di comunicazione ed i protocolli implementati. Questo inventario sarà molto utile per giudicare eventuali protocolli obsoleti o punti non protetti del SUC (dispositivo o sistema preso in considerazione). E tenere una traccia dei problemi e delle mitigazioni o cambi di design attuati nel tempo.

Le best practice per la security secondo la IEC 62443

Le buone norme di security previste dallo standard si rifanno alle buone norme di security presenti nel mondo IT, limitando la garanzia di confidenzialità ove impraticabile, ma difendendo i dati tramite separazione di reti, ad esempio, e con un occhio speciale per quello che è la resilienza e il failsafe, poiché la safety, sicurezza delle persone e luoghi, potrebbe venire meno nel momento in cui la security viene meno. Inoltre, viene richiesto esplicitamente anche la capacità di audit, ovvero la possibilità di ricostruire la causa di un evento partendo dalle stracce registrate durante il percorso. Spesso questa abilità si basa sulla bontà dei log di sistema, trovati spesso incompleti o non adatti all’uso per una verifica agevole.

Volendo esplicitare in modo coinciso quello che lo standard IEC 62443 condivide con gli standard IT sicuramente possiamo citare, tenendo come soggetto la trasmissione dei dati e software la conservazione degli stessi: la confidenzialità quindi evitare di trasmettere e salvare i dati in chiaro (non criptati), l’integrità che prevede di dare la possibilità di verificare che i dati non abbiano subito modifiche nel tempo, l’autorizzazione che permette l’accesso ai dati solo al personale autorizzato previa identificazione, identificazione che va sincerata in modo sicuro, ovvero, senza lasciare possibilità di carpire informazioni sensibili durante il processo di autenticazione, ne appartenenti al soggetto che si vuole autenticare (nel quotidiano username e password) ne dei dati costituente il sistema (lasciar trapelare che un username è esistente o meno nel database, quale tra le due credenziali è errata) nemmeno in caso di errore del sistema stesso. Infatti, uno dei punti salienti è l’autenticazione che può avere vari livelli di sicurezza che vanno dalla password semplice costruita con criterio, e quindi ritenuta sicura dallo stato dell’arte, fino a autenticazione a doppio fattore e con autorizzazione da terzi. per quanto riguarda la disponibilità, questo è un aspetto fondamentale per un sistema OT poiché la riuscita di un processo di produzione dipende strettamente dall’osservazione e controllo del processo stesso, quindi dalla cooperazione sinergica di tutti i dispositivi atti a rilevare e misurare, e tutti i dispositivi “attuatori” che sono capaci di influenzare il processo. Qual ora uno di questi dispositivi venisse meno, ovvero non fosse disponibile, il dispositivo o il dato generato, il processo rischia di non essere controllabile o se venisse meno l’integrità dei dati, lo stato del processo verrebbe percepito differente dallo stato effettivo evocando correzioni non necessarie o addirittura nocive. Da questo si evince che la disponibilità è uno dei fattori cruciali per un processo di produzione, e qual ora venisse meno è necessario avere sistemi capaci di operare in modo safe fino alla ricostituzione della operatività. Lo standard suggerisce infatti funzionalità quali la sicurezza di poter lavorare in modalità degradata ma fornendo servizi essenziali. L’abilità di resistere ad attacchi di tipo DOS, e di amministrazione delle risorse in modo che la sicurezza sia garantita a discapito di funzionalità non essenziali. In fine la possibilità di creazione di backup e la possibilità di restore avendo individuato uno stato del dispositivo, firmware, software, impostazioni e dati, ritenuto sicuro e gestito da personale dedicato e qualificato.

Hai bisogno di maggiori informazioni? Contattaci!

GFCC (Genoa Fieldbus Competence Centre) Srl

Sede Legale:

Via Cesarea 2 - 16, 16121 GENOVA (GE)


Sede Tecnica:

Supporto Tecnico, R & D, Laboratorio, Aule Corsi

Via Greto di Cornigliano 6R 16152 GENOVA (GE)


Telefono (Supporto Tecnico):

010 860 2580

Telefono (Sales & Marketing):

010 860 2590

Fax: 010 656 3233

Email: info@gfcc.it