Protezione delle piattaforme tecno-industriali. Compliance NIS e oltre

Introduzione e considerazioni generali

La normativa NIS (che comprende la Direttiva UE 2016/1148 e il relativo decreto di recepimento 18 maggio 2018 n.65) stabilisce una serie di adempimenti relativi agli OSE (Operatori di Servizi Essenziali) nei settori energia, trasporti, banche, mercati finanziari, sanità, fornitura e distribuzione di acqua potabile e infrastrutture digitali; nonché motori di ricerca, servizi cloud e piattaforme di commercio elettronico.

Vale la pena osservare che la normativa in questione tende specificamente a garantire la continuità del servizio erogato dalle OSE interessate, mentre sono altre – GDPR in testa – le norme che promuovono la protezione delle informazioni (dati) di carattere gestionale e personale in particolare.

Si noti che non tutti gli enti che rientrano nelle numerose tipologie sopra indicate sono obbligati alla normativa in questione: solo quelli (si suppone di maggior valenza sociale, si veda al riguardo l’art. 5 del sopracitato decreto attuativo) indicati in un’apposita lista governativa rimasta, fino ad oggi, secretata, per motivi che a chi scrive rimangono oscuri (forse retaggio della vecchia filosofia ormai da tempo superata che predicava la security by obscurity).

Il citato decreto di recepimento, forte di complessivi ventidue articoli e tre allegati e di cui si raccomanda caldamente la lettura, è in massima parte dedicato alla citazione di norme connesse, di attori in gioco, degli enti governativi proposti al tema (cinque ministeri), dei rapporti con l’Europa, dei centri cui indirizzare le segnalazioni di eventi indesiderati. Solo negli articoli 12 e 14 si indica l’obbligo di progettare e attuare misure di protezione delle piattaforme digitali in essere. L’avverbio solo non deve tuttavia trarre in inganno: in effetti gli adempimenti e la relativa roadmap necessaria per onorare gli adempimenti previsti negli articoli citati sono ben descritti nel documento Framework Nazionale per la Cybersecurity e la Data Protection reperibile sul sito https://www.cybersecurityframework.it/.

La figura che segue, realizzata da chi scrive, sintetizza graficamente quanto previsto nel citato documento.

È nell’area della funzione Identify che si inserisce utilmente la metodologia IPSEM (Industrial Platform Security Evaluation Methodology). Anzitutto rispondiamo a una domanda più che giustificabile: perché, con varie metodologie disponibili (l’ENISA ne mantiene un elenco, circa una quindicina), proporne una nuova?

La risposta è articolata e la domanda fornisce lo spunto per chiarire aspetti importanti e far giustizia di alcune approssimazioni che compaiono frequentemente in articoli e convegni specializzati. Anzitutto è ormai chiaro che esistono due diversi tipi di piattaforme che utilizzano ampiamente tecnologie digitali. La prima, ormai più che matura e pesantemente normata, sia sul piano degli standard che su quello legislativo, riguarda il trattamento di informazioni (vale a dire dati, nel momento in cui vengono trattati dai computer) di natura amministrativa e gestionale aziendale. È il dominio della contabilità generale, della stipendiazione, degli ordinativi commerciali, dei contratti, della posta elettronica, delle cartelle cliniche, dell’e-commerce e così via. La stragrande maggioranza di questi dati hanno, direttamente o indirettamente, a che fare con persone e, di conseguenza, con i loro diritti. In questo dominio si concorda generalmente che la protezione dei dati debba essere articolata secondo tre parametri – riservatezza, integrità e disponibilità – e tenendo conto di ciò si effettua, allorché ci si accinge a redigere un piano di protezione, l’importante e prescritta fase di analisi dei rischi. Al riguardo, alcuni decenni fa chi scrive coniò il termine di terna RID. Indicheremo nel seguito questo dominio con il termine, semanticamente equivoco ma utile sul piano pratico, gestionale. Giova notare che in questo ambito, spesso mediato da strumentazione tecnica e qualche tipo di automatismo, l’immissione delle informazioni è effettuata da una persona o da qualche suo comportamento. Il risultato del trattamento nella maggior parte dei casi è destinato, direttamente o tramite un evento che lo riguarda, a una persona (fisica o giuridica) (l’accredito in banca di uno stipendio, l’invio di una email, la spedizione di un bene acquistato, l’aggiornamento di una cartella medica e così via).

Di contro, da qualche tempo, la società ha preso coscienza della necessità di proteggere piattaforme digitali di altro tipo: quelle che chiameremo, anche in questo caso con una certa approssimazione semantica, piattaforme tecnoindustriali. In questo ambito rientrano scenari vari: automotive, building automation, industria 4.0 e oltre, smart cities, produzione e distribuzione di energia e servizi e molto altro. In questo tipo di piattaforme l’immissione dei dati per l’elaborazione è a carico di sensori, l’elaborazione (come si può notare non parliamo più di trattamento) è a cura di molteplici piccole unità di calcolo dotate spesso di sistemi operativi sui generis, i dati viaggiano grazie a protocolli proprietari e i risultati sono a beneficio, piuttosto che di esseri umani, di attuatori che regolano le funzioni tecniche più disparate.

Di conseguenza a quanto sopra, essendo la maggior parte dei dati elaborati da questo tipo di piattaforme non relazionato a esseri umani, ma dovendosi soprattutto, quanto a protezione (preferiamo usare questo termine in luogo del troppo metafisico sicurezza), garantire la continuità funzionale della piattaforma stessa, appaiono giustificate alcune riflessioni che effettueremo di seguito. Prima di fare questo riportiamo di seguito una tabella che riassume significativamente, anche se probabilmente non in modo esaustivo, la differenza tra i due mondi.

Aspetto distintivo	Piattaforme gestionali	Piattaforme tecnoindustriali
Generatori dei dati	Persone	Sensori
Destinatari della elaborazione	Persone	Attuatori, sale operative
CPU utilizzate	Server, di potenza medio-grande	CPU di piccole dimensioni
Sistemi operativi in uso	Noti, standardizzati, pochi	Molteplici, proprietari, poco noti
Protocolli in uso	Molteplici, specifiche note	Molteplici, proprietari, specifiche poco note
Scopo del sistema di protezione	Riservatezza, integrità, disponibilità del dato	Continuità della funzione

Premesso tutto questo torniamo al titolo dell’articolo per proporre un percorso per conseguire l’obiettivo della compliance di un’azienda alla normativa NIS. Teniamo sott’occhio lo schema in alto (Fig. 1).

La metodologia IPSEM è pensata per coprire l’intero processo indicato nello schema in questione. Allo stadio di sviluppo attuale essa “copre” la Funzione “Identify” e, più specificamente sei Categorie delle sette in cui detta funzione risulta articolata. Non viene infatti trattata l’ultima Categoria, Data Management, che riguarda la componente privacy; vale a dire la gestione, ai sensi della normativa GDPR , di eventuali informazioni a carattere personale gestiti dalla piattaforma industriale. Questo aspetto, in effetti, richiede un modus operandi proprio, focalizzato, piuttosto che sui componenti, sul censimento preventivo dei macrodati, intesi come insiemi di informazioni omogenei ai fini di un processo aziendale e come esigenza di protezione in termini di terna RID (Riservatezza, integrità e disponibilità).

La procedura

Per quanto riguarda la funzione Identify, il procedimento si articola nei seguenti passi:

1. descrizione e articolazione del perimetro d’intervento (perimetro, sotto-perimetri, componenti);
2. individuazione delle vulnerabilità;
3. definizione dei parametri di criticità e loro applicazione ai componenti;
4. calcolo dell’Indice di Criticità e sua rappresentazione grafica.

Quanto sopra è sintetizzato nel grafico che segue e descritto in dettaglio di seguito.

Descrizione e articolazione del perimetro d’intervento

Il primo passo della procedura consiste nella definizione del perimetro d’intervento. Il livello di componente è, quanto a livello di astrazione, il più basso e si riferisce ad apparati normalmente fisicamente individuabili in grado di fornire una funzionalità parziale ma compiuta a beneficio della funzionalità complessiva della piattaforma che eroga e gestisce il servizio.

Esempi di componenti sono desktop e laptop, cellulari, modem, canali trasmissivi (tratte peer-to-peer), sensori, attuatori, server etc. I componenti, come indicato, sono suscettibili di vulnerabilità a determinati attacchi che sfruttano le loro eventuali debolezze funzionali (anche gli utenti possono essere considerati componenti).

I componenti tra di loro complementari, che contribuiscono sinergicamente a fornire una funzionalità ancora parziale se la si riferisce al complesso del servizio fornito dalla piattaforma ma tuttavia chiaramente identificabile e definibile e nei suoi limiti compiuta, affidata a uno specifico ente aziendale, concorrono a formare un sottoperimetro.

L’insieme di sottoperimetri costituisce il perimetro d’intervento, vale a dire la piattaforma digitale di cui ci stiamo occupando.

Di seguito a titolo di esempio si indica la rappresentazione in forma grafica, articolata come sopra indicato, di una piattaforma di Telecontrollo nel settore dell’energia.

Ai fini delle elaborazioni successive i componenti vengono distinti in varie categorie, in funzione della propria capacità computazionale e di altri parametri. La definizione delle categorie può variare, in funzione della tipicità del contesto industriale. Un esempio di categorizzazione sempre nel settore dell’energia è il seguente:

• utenti;
• componenti di interfaccia e di accesso (dispositivi fissi e mobili);
• componenti trasmissivi (connessioni);
• server e relative applicazioni;
• componenti industriali dotati di capacità computazionale completa;
• componenti industriali dotati di capacità computazionale cablata e limitata;
• sensori e attuatori;
• strutture e contenitori;
• entità esterne funzionali al processo considerato.

Individuazione delle vulnerabilità

Una volta che sia disponibile un elenco di tutti i componenti della piattaforma in considerazione, si procede all’assegnazione delle vulnerabilità note a ciascun componente. Le vulnerabilità sono di tipo informatico-digitale per i componenti dotati di capacità computazionale. Tale tipo di vulnerabilità sono potenzialmente tanto più numerose quanto maggiore è la capacità computazionale del componente.

Una fonte, ma non l’unica, di vulnerabilità note è costituito dal database CVE (https://www.cvedetails.com/). Segue un esempio di videata che riguarda, in modo soltanto esemplificativo, le vulnerabilità di un modello del firewall “Watchguard”.

Su componenti di particolare interesse possono essere svolti test complementari o verifiche) in laboratorio (per esempio riguardanti l’installazione di patch rilasciate dal fornitore).

Per componenti con capacità computazionale bassa o nulla, le vulnerabilità sono normalmente legate a carenza di misure antintrusione, antieffrazione ovvero organizzative che possono aprire la strada all’accesso fisico a componenti dotati di capacità computazionale e quindi allo sfruttamento di vulnerabilità di tipo informatico.

Definizione dei parametri di criticità e loro applicazione ai componenti

Considerazioni preliminari

Con riferimento ad un primo cenno al riguardo effettuato all’inizio dell’articolo la valutazione dei componenti al fine della messa in sicurezza dei perimetri e sotto-perimetri di riferimento viene normalmente effettuata mirando, a conclusione del procedimento, alla definizione di un livello di rischio dei singoli componenti o, per meglio dire, del rischio che corrono, in caso di attacco con successo, i dati dal componente gestito, in termini di compromissione delle loro qualità RID (Riservatezza, Integrità, Disponibilità).

Com’è noto, il rischio è considerato in modo consistente in letteratura e negli standard come funzione del danno e della probabilità di accadimento. Tali entità dovrebbero essere definite in modo credibile facendo riferimento a serie storiche e a valori economici documentabili.

Essendo ambedue gli elementi citati difficilmente reperibili o definibili nell’ambito della distribuzione dell’energia, si è preferito basare la metodologia di seguito descritta sull’obbiettivo di definire, per ciascun componente, un indice di criticità.

Per onestà intellettuale osserviamo che rischio e criticità non sono la stessa cosa, ma si assomigliano molto. Rinunciamo a derivare il rischio da due parametri (danno e probabilità) di cui non disponiamo con sufficiente approssimazione e ci accontentiamo di derivare, per ciascun componente, un indice di criticità che risulta dalla valutazione del componente, qualificato dalle vulnerabilità note o risultanti da prove di laboratorio, rispetto a una serie di parametri modulati con una metrica di tipo qualitativo, strizzando l’occhio, in tal modo, ai dettami della logica sfumata.

Si potrà osservare che la scarsa consistenza denunciata e temuta a proposito dei parametri rischio e probabilità, evitata rinunciando a utilizzare gli stessi, rientra dalla finestra con l’utilizzo di parametri sostitutivi concepiti ad hoc, più credibili.

Si apre poi la strada alla possibilità di definire parametri, a giudizio dell’analista, personalizzati e riferibili a dati e informazioni, sempre a suo giudizio, sufficientemente attendibili. Secondo, poi, il grado di approssimazione del modello suggerito dovrebbe risultare più omogeneo, contaminando i vari componenti più o meno nello stesso modo, conferendo pertanto un elevato grado di consistenza alla classifica finale relativa e consentendo, in tal modo, di individuare una priorità d’intervento credibile in materia di attuazione delle contromisure, che è poi lo scopo pratico concreto del procedimento.

Il procedimento di seguito descritto si ripropone di determinare, per ciascun componente, il rispettivo Indice di criticità (Icc). La somma degli Icc estesa a tutto il sottoperimetro definisce l’Indice di criticità del sottoperimetro (Ics). Analogamente la somma degli Ics estesa al perimetro costituisce l’indice di criticità del perimetro (o piattaforma) Icp.

Il risultato ottenuto può essere rappresentato semplicemente con un elenco, in ordine di criticità decrescente in una tabella, ovvero in forma grafica. Ad esempio, è pensabile un grafico in cui i componenti siano posti in uno spazio cartesiano in cui l’asse delle ascisse rappresenti Ic e quello delle ordinate la numerosità dei componenti nel territorio.

Il procedimento

Ai fini di attribuire un Icc ai componenti occorre disporre di un catalogo dei parametri di valutazione preventivamente definito. Il catalogo prevede un set di parametri specifico per ciascuna categoria di componenti (nove in tutto nell’esempio in precedenza indicato). In tal modo è possibile personalizzare meglio il set di parametri alla singola categoria, essendo altrimenti possibile, in caso di definizione di un set unico per tutte le categorie, che alcuni parametri non siano significativi per certi componenti. È consigliabile, all’atto pratico, che il numero di parametri per ciascuna categoria di componenti sia compreso tra tre otto.

L’anatomia di un parametro è costituita da:

1. una frase che indica una conseguenza dannosa derivabile da un attacco, o una circostanza, una proprietà riguardante il componente considerato;
2. una scala metrica, di tipo qualitativo, costituita da cinque valori crescenti in termini di severità.

Tali valori (o forse meglio valutazioni) di tipo qualitativo sono comunque associati a valori numerici per necessità computazionali successive.

Quanto sopra è meglio chiarito da un esempio:

Parametro = numero di utenze potenzialmente oscurate in caso di attacco.

Scala metrica associata (in parentesi il valore numerico corrispondente):

Una utenza (0)

Da 2 a 100 utenze (1)

Da 101 a 1.000 utenze (2)

Da 1001 a 10.000 utenze (3)

Oltre 10.000 utenze (4)

Si osserva che i valori numerici associati a ciascuno scalino della scala metrica non devono necessariamente corrispondere allo spazio da 0 a 4, ma possono essere diversi (ovviamente sempre rispecchiando valori crescenti). Ciò può consentire all’analista, in fase di definizione del catalogo dei parametri, di attribuire un peso maggiore di un particolare parametro che si rispecchierà nella somma finale dei vari valori numerici scelti. Tale somma, infatti, definirà l’indice di criticità (Ic) di ciascun componente.

Il Catalogo dei parametri

Segue un elenco dei parametri utilizzati per valutare i diversi componenti, riferiti alle nove categorie in cui i medesimi sono raggruppati. La metrica che caratterizza l’applicazione di ciascun parametro ai singoli componenti è indicata nella tabella successiva. Tale metrica chiarisce ulteriormente, oltre a quanto indicato in parentesi nella tabella che immediatamente segue, il significato dei parametri. Per motivo di sintesi il Catalogo non viene riportato per esteso, ma vengono solo indicati i primi elementi della gerarchia logica Categoria di componente > Parametro > Metrica.

Categoria di Componente	Parametro
1 – Utenti (Gli utenti a tutti gli effetti possono essere considerati componenti di un perimetro. Essi infatti son portatori di vulnerabilità che possono essere sfruttate con tecniche di social engineering).	1 – Esistenza di una norma di comportamento (Una procedura aziendale che indichi le norme di comportamento sia legate all’utilizzo dei dispositivi di accesso utilizzati che alla segretezza di informazioni correlate è importante). 2 – Modalità di comunicazione delle credenziali di accesso (Può accadere che, in determinate circostanze, le credenziali di accesso o altre informazioni sensibili siano comunicate tramite canali insicuri). 3 – Tipo di utente (L’utente generalmente è un dipendente, ma può accadere che sia un consulente o altra persona esterna).
2 – Componenti di interfaccia e di accesso (Dispositivi fissi e mobili utilizzati e autorizzati ad accedere a un certo sottoperimetro. Questa categoria è un sottoassieme particolare della categoria 4).	1 – Natura del dispositivo (Cellulari, tablet, laptop hanno intrinsecamente una criticità maggiore di desktop fissi). 2 – Sistema operativo (Sistemi operativi obsoleti, non più mantenuti dal fornitore, ovvero proprietari hanno una criticità maggiore). 3 – Robustezza delle credenziali di accesso (Autenticazione debole di tipo one token, autenticazione forte two tokens, altro).
Segue per tutte le categorie di componenti…

Ciascun componente, in funzione della categoria di appartenenza, viene valutato in base al set di parametri sopra indicato. La valutazione avviene utilizzando la metrica associata a ciascun parametro e descritta nella tabella che segue. Per ciascun parametro è scelto un valore corrispondente allo scalino della metrica che, a giudizio del valutatore, è più vero.

Nella tabella i parametri sono riportati contraddistinti da un codice x.y in cui x corrisponde alla categoria e y al codice del parametro nell’ambito di detta categoria.

Parametro	Metrica
1.1 – Esistenza di una norma di comportamento	Norma inesistente = 4 Norma esistente ma incompleta = 2 Norma esistente e completa = 0
1.2 – Modalità di comunicazione delle credenziali di accesso	Le credenziali sono create inizialmente dall’amministratore di sistema e comunicate all’utente in modo sicuro. Questi provvede a gestirle in autonomia. Le credenziali non sono mai comunicate a terzi = 0 Le credenziali sono create inizialmente dall’amministratore di sistema e comunicate all’utente in modo sicuro. Questi provvede a gestirle in autonomia. Le credenziali sono talvolta comunicate a terzi con canale sicuro = 2 Le credenziali sono create inizialmente dall’amministratore di sistema e comunicate all’utente in modo sicuro. Questi provvede a gestirle in autonomia. Le credenziali sono talvolta comunicate a terzi con canale non sicuro. = 4
Segue per tutti i parametri….

Rispondenza della metodologia proposta a quanto previsto dal Framework Nazionale per la Cybersecurity e la Data Protection

La metodologia proposta, come si è detto, si ripropone di essere di ausilio alla realizzazione di quanto previsto dal citato documento Framework Nazionale per la Cybersecurity e la Data Protection. Lo schema che segue indica la corrispondenza tra le Categorie previste dal documento e i segmenti della metodologia applicabili.

Si ricorda che il tutto riguarda la funzione Identify.

 

Categoria	Riferimenti alla metodologia
Asset management	2.1 Descrizione e articolazione del perimetro d’intervento
Business environment
Governance
Risk assesment	2.2 Individuazione delle vulnerabilità. 2.3 Definizione dei parametri di criticità e loro applicazione ai componenti.
Risk Management Strategy
Supply Chain Risk Management	2.1 Descrizione e articolazione del perimetro d’intervento
Data Management	Non considerato, essendo dominio della normativa Privacy (GDPR – Regolamento Ue 2016/679

Conclusioni

La metodologia esposta rappresenta, a giudizio dell’autore, una metodologia operativa concretamente utile all’attuazione di quanto previsto dalla normativa vigente in materia di OSE. Essa, evidentemente, è applicabile, con opportune personalizzazioni del Catalogo dei Parametri, a una serie di contesti tecno-industriali che vanno dal semplice sistema di accensione a distanza della caldaia domestica fino a scenari complessi quali piattaforme di distribuzione di energia, impianti industriali produttivi 4.0, smart cities e così via.

La metodologia è in corso di essere estesa, con riferimento alla Fig. 1, alle funzioni “Protect” e all’intero dominio della gestione degli incidenti: chiunque fosse interessato a collaborare può mettersi in contatto con l’autore.

Infine, la metodologia apre a ulteriori iniziative e progetti, quali la costituzione di database di vulnerabilità note per componenti di ciascun particolare settore industriale.

Ringraziamenti

L’autore si assume tutte le responsabilità relative a quanto contenuto nel presente articolo. Egli, tuttavia, desidera ringraziare, a vario titolo, alcune persone che hanno contribuito al consolidamento e alla attuabilità concreta della metodologia esposta.
Anzitutto il pluridecennale compagno di progetti professionali Alberto Berretti dell’Università di Tor Vergata, quindi Maurizio Pesce e Federico Tiberi di SCS s.r.l. per il loro contributo alla realizzazione dei progetti di consulenza realizzati. Ancora desidero ringraziare Massimo Cresta con Marco Paulucci di TDE Terni e Carlo Paris con Andrea Veronesi di Deval S.p.A che hanno costruttivamente collaborato nell’applicazione della metodologia a scenari reali di rilevante portata geografica e sociale.

 

Articolo a cura di Giulio Carducci