Il problema maggiore nella gestione della sicurezza nell’automazione industriale, con il digitale, è che l’oggetto stesso della protezione è cambiato. Qui c’è il nodo da comprendere, per fare una svolta verso una migliore cyber security.
Notiamo innanzitutto la parola: preferiamo utilizzare la parola “protezione” piuttosto che “sicurezza”, perché “sicurezza” è un concetto che si riferisce ad uno stato (l’essere più o meno al sicuro) mentre “protezione” fa riferimento ad una esplicita attività da parte di attori che operano consapevolmente.
La mancata comprensione di quest’aspetto fondamentale del nuovo scenario ci porta a fare degli errori di valutazione, ed un esempio di questo problema può essere il peraltro ottimo articolo della professoressa Paola Severino pubblicato su Agendadigitale.eu. L’articolo sottolinea, molto giustamente, come quello che viene chiamato “rischio cyber nell’industria 4.0” (assumo si intenda il rischio dovuto all’utilizzo di Internet e delle tecnologie digitali nell’automazione industriale) sia un problema centrale per il Paese che va affrontato mediante la cooperazione di conoscenze e discipline anche molto diverse.
Fondamentale l’enfasi nella condivisione delle esperienze e delle conoscenze sull’argomento. Pienamente d’accordo anche sul ribadire l’importanza di norme come il GDPR per quanto riguarda la protezione della riservatezza dei dati personali. Il problema però è che non si tratta di dati personali, nel contesto a cui facciamo riferimento. Anzi spesso neppure di dati.
Occorre infatti distinguere due ambiti di utilizzo degli strumenti digitali, due ambiti distinti, non disgiunti, in cui gli obiettivi della protezione sono specifici.
Il mondo dell’informatica gestionale
Da una parte abbiamo il mondo dell’informatica che chiamiamo gestionale: qui lo strumento digitale serve a trattare informazione, rappresentata in forma digitale come dato, che costituisce pertanto il bene supremo da proteggere. La protezione del dato avviene, come è ben noto, lungo tre assi:
- la riservatezza (il dato deve essere accessibile solo da chi ha diritto ad accedervi),
- l’integrità (il dato non deve essere modificato in modo non autorizzato),
- la disponibilità (il dato deve essere a disposizione quando serve).
La quantità di tecnologie che sono state create per proteggere i dati lungo queste tre dimensioni è immensa. Le tecnologie crittografiche giocano un ruolo importantissimo, come è evidente: ad esempio se il dato deve essere riservato, va cifrato, e la gestione delle chiavi necessarie per decifrarlo è essenziale per definire chi lo potrà leggere; le tecnologie di firma digitale sono essenziali per la protezione dell’integrità dei dati. Per quanto riguarda la disponibilità, si può pensare a metodologie di backup e a tutta la tematica dell’incident handling e della disaster recovery.
Il mondo dell’informatica funzionale
Quando utilizziamo tecnologie digitali nel mondo industriale, però, il discorso cambia. Entriamo in quel mondo che chiamiamo dell’informatica funzionale. Qui il problema centrale non è proteggere un dato, ma delle funzioni, dei processi fisici.
In questo caso, buona parte delle nozioni che si studiano quando si studia la sicurezza informatica vanno reinventate. Ad esempio, i tre assi lungo i quali valutare la sicurezza dei dati non sono più rilevanti se il bene da proteggere non è il dato ma la funzione. Altri strumenti utilizzati per valutare la sicurezza dei componenti di un sistema (ad es., il parametro numerico noto come CVSS, il Common Vulnerability Scoring System) sono incompleti. Purtroppo, non è facile trovare semplici sostituti per questi concetti.
Il mondo dell’informatica funzionale è non solo vasto, ma anche multiforme: mentre nel mondo gestionale abbiamo una scarsa variabilità sia di hardware (a grande maggioranza computer o oggetti computer-like basati su processori Intel o ARM) che software (Windows, Windows Server e Linux la fanno da padroni) nel mondo dell’informatica funzionale la varietà è molto più grande, e a complicare la situazione è che settori industriali diversi possono avere apparati diversi e componenti diversi: mentre negli uffici di una fabbrica di scarpe o di una fabbrica di televisori troveremo i soliti PC con Windows, dentro un’automobile troveremo delle ECU (Electronic Control Unit), piccolissimi computer che gestiscono il funzionamento dell’auto, connessi con un bus CAN (Controller Area Network) che parlano tra di loro usando certi protocolli, mentre in una cabina di distribuzione dell’energia elettrica troveremo RTU (Remote Terminal Unit), RGD (Rilevatori di Guasto Direzionali), protezioni elettriche, strumenti di misura, etc., che utilizzano una quantità di protocolli per comunicare tra loro e con l’esterno (protocolli perlopiù definiti da un organismo specifico, l’IEC, International Electrotechnical Commission) su una quantità di supporti fisici: Ethernet, USB, seriale, GSM, GPRS, addirittura collegamenti satellitari in certi casi.
Protezione dei dati e protezione delle funzioni
Ma cerchiamo di spiegare meglio la differenza che c’è tra la protezione dei dati e la protezione delle funzioni.
L’RTU situata in una cabina di distribuzione dell’energia elettrica comunica con i sistemi SCADA (System Control And Data Acquisition, i sistemi nella sala di controllo centrale) utilizzando una rete dati, che tipicamente oggi come oggi è basata sui protocolli di Internet: tale rete tipicamente è chiusa ed isolata, ma isolata può semplicemente voler dire che è separata dalla rete Internet pubblica da un paio di firewall, che come tutte le cose umane possono essere configurati male o possono avere dei bug. Se in qualche modo un attore malevolo riesce ad “arrivare” all’RTU, può intervenire sugli interruttori e sulle protezioni elettriche (che sono a loro volta dispositivi intelligenti, dotati di una CPU e di un sistema operativo) e fare cose come spegnere un intero quartiere. Si tratta di uno scenario reale e non di fantascienza, come l’esperienza ucraina ci insegna. E c’è stato il predecessore importante di Stuxnet, che risale ad un decennio fa.
Nella figura seguente possiamo vedere lo schema generale dell’infrastruttura di un’OSE (Operatore di Servizi Essenziali), come tipico esempio di un sistema in cui funzioni, piuttosto che dati, devono essere oggetti di protezione, e nel quale il bene principale da tutelare è la continuità del servizio di erogazione di un bene fisico (nell’esempio seguente, l’energia elettrica).
Come si vede facilmente, siamo molto distanti dall’architettura di un tipico ufficio, o anche di un data center. Gli oggetti assimilabili a computer (oggetti dotati di una CPU e di una memoria che eseguono del codice) sono tanti e molto variabili, spesso prodotti in piccola serie per mercati ridotti (ad es. le RTU utilizzate in Italia sono in genere costruite secondo specifiche ENEL e dedicate al mercato italiano). Non solo, ma se l’integrità e la riservatezza dei dati scambiati ad es. tra un sistema SCADA ed una cabina di distribuzione tramite un canale di comunicazione sono importanti, lo sono principalmente allo scopo di garantire la continuità del servizio di erogazione dell’energia.
In questo contesto, l’oggetto della protezione deve dunque essere la funzione, non il dato. Ovviamente dei dati possono essere attaccati strumentalmente, come precondizione per poter accedere alla funzione, ma non sono centrali: nel caso ucraino ad esempio, sono state utilizzate delle e-mail di phishing ed un malware (un “virus”) per poter avere alcune password, grazie alle quali l’attore malevolo si è potuto muovere nella rete del fornitore di servizio ed è riuscito ad arrivare ai sistemi informatici in cabina di distribuzione. Tutte le tecnologie che sono pertinenti alla protezione dei dati devono essere utilizzate, quando necessario, ma come l’obiettivo dell’attacco è la funzione fisica, tale deve essere l’obiettivo della protezione. Ad esempio, l’utilizzo della crittografia può assolutamente giocare un ruolo, ma non è centrale nella difesa delle funzioni di un impianto.
Non che i requirement normativi non esistano o siano insufficienti. Nella figura sotto (realizzata da SCS S.r.l. per sintetizzare quanto proposto nel documento Framework nazionale di Cybersecurity v. 2.0 a cura del Cyber Intelligence and Information Center (CIS) dell’Università La Sapienza e del Laboratorio Nazionale di Cybersecurity del CINI) abbiamo lo schema sinottico degli adempimenti di un OSE: si tratta, a leggere bene, di una quantità di lavoro semplicemente spaventosa, e già il quadratino rosso in alto a sinistra (e cioè il semplice asset management, cioè l’inventario dei beni rilevanti per la protezione delle funzioni, con la semplice enumerazione delle vulnerabilità note dei componenti e dei canali di comunicazione) può essere un lavoro impegnativo. L’intero stack è un lavoro immenso.
Purtroppo, ancora non esistono metodologie standard e nemmeno un quadro concettuale coerente ed unificato per trattare questa problematica: ad esempio qualcosa che rimpiazzi i tre parametri lungo i quali si misura la sicurezza di un sistema gestionale sopra menzionato. Si tratterebbe di un quadro concettuale unificato che potrebbe essere anche molto difficile da definire, considerata la estrema diversità dei settori interessati. Ma certamente almeno nel settore delle reti di distribuzione e degli OSE si sente il bisogno di raggiungere una standardizzazione terminologica che permetta di affrontare il problema della protezione delle funzioni in un modo vicino all’approccio formale utilizzabile nel settore gestionale.
