Valutazione della sicurezza informatica delle infrastrutture critiche ... · 102 Speciale Sicurezza ICT Igor Nai Fovino definite industriali (centrali elettriche, nucleari, siste-mi

101Speciale Sicurezza ICT

SommarioLe minacce alla sicurezza sono uno dei principali proble-

mi dell’era dei calcolatori. Tutti i sistemi che fanno uso delletecnologie dell’informazione e della comunicazione (ICT) sonoesposti a malfunzionamenti e vulnerabilità che possono esseresfruttati da codice e agenti maligni. Considerando l’uso impo-nente delle tecnologie ICT nelle cosiddette “infrastrutture criti-che”, diventa doveroso eseguire adeguate valutazioni dei rischisulla sicurezza, mettendo in evidenza le principali minacce acui un sistema è esposto e, alla fine, l’efficacia delle possibilicontromisure. Sfortunatamente, le caratteristiche delle infra-strutture critiche industriali rendono difficile l’uso delle tecni-che tradizionali di valutazione del rischio. In questo contribu-to presentiamo una metodologia innovativa per la valutazionedel rischio sulla sicurezza adattata alle esigenze di questi par-ticolari sistemi e basata sul paradigma dei sistemi-di-sistemi esul concetto di “modellazione orientata al servizio”. Dopoaver fornito una panoramica dello Stato dell’Arte nella disci-plina della valutazione del rischio per le InfrastruttureCritiche, forniamo alcune definizioni base sulla sicurezza einfrastrutture critiche. Successivamente descriviamo la metodo-logia proposta, presentando i risultati della sua applicazionein un caso di studio concreto.

AbstractSecurity threats are one of the main problems of this com-

puter-based era. All systems making use of information andcommunication technologies (ICT) are prone to failures andvulnerabilities that can be exploited by malicious software andagents. Considering the massive use of ICT technologies in theso called “critical infrastructures”, it become imperative to per-form adequate security risk assessments, putting in evidence themain threats a system is exposed to and eventually the effecti-veness of the possible countermeasures. Unfortunately, thepeculiarities of industrial critical infrastructures make hardthe use of traditional security assessment techniques. In thispaper we present an innovative security assessment methodo-logy tailored for these particular systems, and based on thesystem-of-system paradigm and on the concept of “serviceoriented modelling”. After giving an overview of the State ofthe Art in the field of security assessment for CriticalInfrastructures, we provide some basic definitions on securityand critical infrastructures. Then we describe the proposedmethodology, presenting the results of its application on a realcase study.

Igor Nai FovinoGlobal Cyber Security Center

VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE,DEFINIZIONI E METODOLOGIA(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONSMETHODOLOGY)

1. Introduzione

Le minacce informatiche sono uno dei principaliproblemi dell’era digitale.Tutti i sistemi che fanno uso di tecnologie infor-

matiche sono potenzialmente soggetti a vulnerabilitàche potrebbero essere sfruttate da software malevoli(virus, worms ecc.) e da criminali. La situazione è ancora più delicata se consideria-

mo il caso delle infrastrutture critiche, ossia quelleinfrastrutture il cui danneggiamento può impattareseriamente la vita del comune cittadino. Esempi di

infrastrutture critiche possono essere centrali elettri-che, impianti per l’acqua potabile, ma anche sistemidi controllo del traffico ferroviario, aereo e così via.Se una di queste infrastrutture venisse attaccata odanneggiata, gli effetti potrebbero essere estrema-mente dannosi. Per questo motivo tali infrastrutture dovrebbero

essere ciclicamente sottoposte a processi di securityassessment (i.e. valutazione della loro sicurezza), alfine di individuare eventuali falle e porvi rimedio.In questo articolo poniamo l’attenzione su quelle

infrastrutture critiche che, per definizione, vengono

102 Speciale Sicurezza ICT

Igor Nai Fovino

definite industriali (centrali elettriche, nucleari, siste-mi di controllo ferroviari, reti gas, acquedotti ecc.).Tali infrastrutture presentano peculiarità che, per

motivi storici e tecnici, le differenziano nettamenteda quelle informatiche tradizionali.Le infrastrutture industriali combinano assieme

tipici sistemi informatici (basi di dati, protocolliTCP/IP, sistemi operativi ed applicazioni da ufficio),con software ed elementi aventi caratteristiche ditempo reale che implementano le funzioni di con-trollo dei dispositivi di basso livello (ad esempiosistemi per il controllo e la misura della pressione dicondutture, della velocità di turbine, del grado diapertura di valvole idrauliche, ecc.). Negli ultimi anni, questi già complessi sistemi

ibridi, hanno iniziato ad essere connessi a reti interneed esterne al perimetro aziendale. Se da una parte taleinnovazione tecnologica ha reso possibili molti nuoviservizi, d’altro canto essa ha aperto le porte a nuovi,più inquietanti scenari e possibilità di attacco. Così,mentre sino agli anni ’90 la sicurezza delle infrastrut-ture critiche era più che altro un fatto di “sicurezzafisica e controllo degli accessi”, nei moderni sistemi,non più isolati dal resto del mondo, le vulnerabilitàinformatiche sono diventate oggetto di massimaattenzione.Mentre per le infrastrutture informatiche tradi-

zionali esistono in letteratura (come verrà presentatonella sezione relativa) metodologie per la valutazionedella sicurezza informatica ben collaudate, il campodella valutazione della sicurezza informatica delleinfrastrutture critiche industriali è relativamente gio-vane. La maggior parte dell’attenzione, in questocontesto, è spesso concentrato sulla valutazione deiclassici sistemi informatici della rete aziendale, trala-sciando completamente tutto ciò che avviene nel latoindustriale degli impianti.Purtroppo i maggiori rischi, come il caso Stuxnet

[1] insegna, sono nella parte bassa di queste infra-strutture, ossia in quelli più vicini ai meccanismi dicontrollo. Le metodologie tradizionali di valutazionedella sicurezza informatica non sono adeguate adanalizzare questa parte dei sistemi industriali: lacoesistenza di ambienti molto eterogenei (sistemireal-time, sistemi elettromeccanici, software svilup-pati appositamente per applicazioni particolari, siste-mi desktop), i vincoli che derivano dai fenomeni fisi-ci controllati da questi sistemi (ad esempio la stabili-tà elettrica) e gli obiettivi di business nettamentediversi rispetto al mondo informatico tradizionalecostituiscono elementi di difficile valutazione e com-

prensione. Per rendere chiara questa diversità, consideriamo

questo esempio: è prassi normale avere delle politi-che di software patch nei sistemi informatici, spessoconfigurate per installare automaticamente nuoviaggiornamenti quando questi sono disponibili.Mentre tale pratica è da considerare altamente consi-gliata in sistemi informatici tradizionali, nel caso deisistemi industriali potrebbe non essere la migliore:spesso l’installazione di una patch richiede il riavviodella macchina, ma se questa macchina controlla unprocesso industriale, il suo riavvio implica automati-camente l’alt dell’intera catena di produzione, fattoquesto che causa notevoli costi economici e chepotrebbe non essere possibile se non mettendo arischio servizi ritenuti vitali per la società (si pensiallo stop di una centrale elettrica).Questi vincoli influenzano pesantemente il modo

e le procedure che devono essere intraprese quandosi tratta di intervenire sulla sicurezza di infrastruttureindustriali, e di conseguenza l’analisi di sicurezzadeve essere in grado di tenerne conto.Inoltre tali considerazioni mettono in evidenza

come esista la necessità di includere nei processi dianalisi la comprensione del funzionamento di ele-menti che con l’informatica hanno in linea di princi-pio ben poco a che fare.Ciò pone l’attenzione sulla necessità di tenere in

considerazione dell’eterogeneità di informazioni cheun processo di analisi della sicurezza deve essere ingrado di processare nel caso di infrastrutture indu-striali:• Caratteristiche dei sistemi coinvolti (hardware,procedure, processi, politiche di sicurezza,politiche di operatività in condizioni normali edi emergenza, ecc.).

• Vulnerabilità.• Minacce (agenti di minaccia, risorse di attaccostimate, ecc.).

• Attacchi.• Contromisure.

Oltre a tutto questo è necessario tenere contoanche delle interazioni tra azioni malevole, fallimentiaccidentali di sistemi di controllo ed errori umani.Negli ultimi anni le cose poi si sono ulteriormen-

te complicate: l’utilizzo della rete pubblica per inter-connettere diverse parti di queste infrastrutture criti-che, ha fatto evolvere questi sistemi da “isolati” acomplessi sistemi-di-sistemi. Così, la comprensionedegli effetti collaterali o dei fallimenti locali, deve


VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE, DEFINIZIONI E METODOLOGIA.(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS METHODOLOGY)

essere oggi estesa ben oltre i confini del singoloimpianto, aggiungendo strati di complessità.I tradizionali processi di valutazione della sicu-

rezza mal si sposano con il paradigma di sistema-di-sistema, date le intrinseche difficoltà nell’identificarele interdipendenze e gli effetti della propagazione dierrori e guasti.Alcuni approcci all’analisi delle proprietà di sicu-

rezza sono stati, ad onor del vero, proposti (si vedala prossima sezione). In generale tali metodologiemirano a collegare a descrizioni strutturali e funzio-nali degli obiettivi di sicurezza. In questo articolo viene presentata una nuova

metodologia per la valutazione del livello di sicurez-za delle infrastrutture industriali basata sul concettodi modellizzazione e mappatura dei servizi. Talemappatura, consente di effettuare un’analisi basatasulla correlazione sistematica, passando quindi dauna più tradizionale visione basata su eventi di sicu-rezza ad una più complessa e completa che consentadi catturare anche gli effetti di tali eventi sull’interainfrastruttura.In questo articolo, dopo aver presentato una

panoramica dello stato dell’arte nell’ambito dellemetodologie di valutazione della sicurezza dei siste-mi IT, viene analizzata la relazione esistente tra i dif-ferenti insiemi di “informazioni” che possono essereusati per descrivere il sistema sotto analisi dal puntodi vista della sicurezza informatica.Infine viene presentata la metodologia che con-

sente di sfruttare tali informazioni al fine di analizza-re il livello di sicurezza del sistema.

2. Stato dell’arte

Nella letteratura scientifica non esiste una meto-dologia ritagliata su misura per analizzare la sicurez-za informatica dei sistemi industriali; in ogni caso nelcampo dell’informatica e nel campo della safety esi-stono alcuni approcci che vale la pena menzionare. La valutazione dei sistemi industriali è campo tra-

dizionale della “Safety Analysis”. Solo di recente leproblematiche di sicurezza sono entrate prepotente-mente in questo mondo. Keeney [2] nel 2005 pre-sentò uno studio sugli effetti del sabotaggio di siste-mi informatici nelle infrastrutture critiche.Stoneburner, Goguen e Feringa [3], nel loro studiosull’analisi del rischio nei sistemi informatici descri-vono una procedura basata su nove passi per la valu-tazione dei rischi derivanti dalle vulnerabilità dei

sistemi informatici tradizionali. Swiderski e Snyder[4] introducono il concetto di “Threat Modeling”(modellizzazione delle minacce), e presentano unapproccio strutturato per identificare, valutare emitigare rischi associati alla sicurezza dei sistemi.Tale lavoro, presentando per primo il concetto dimodellizzazione delle minacce rappresenta sicura-mente un passo avanti in questo ambito. Una appli-cazione di tale approccio nel mondo reale viene pre-sentata in [5]. Esistono inoltre alcuni strumentiappositamente sviluppati per la valutazione di siste-mi generici, come ad esempio “Microsoft SecurityAssessment tool” [6] e “Citicus” [7]. Il primo imple-menta in sostanza un tradizionale processo di “checklist”; in altre parole, l’intero processo di valutazionepassa attraverso una serie di sessioni di “domande-risposte” che guidano l’analista nell’esecuzione dellavalutazione, e che producono come output una seriedi raccomandazioni. Ovviamente, vista la sua generi-cità, tale oggetto è lungi dall’essere in grado di forni-re un’analisi esaustiva e precisa, specialmente nelcampo dei sistemi industriali, per l’analisi dei quali,ovviamente, non è stato concepito. Il secondo stru-mento, Citicus, è basato sul concetto di rischio per-cepito, categorizzando di fatto tali rischi in accordocon una serie di criteri preconfezionati.L’approccio OCTAVE [8], introdotto dal

“Software Engineering Institute” del MIT verso lafine degli anni ’90, rappresenta al momento la piùesaustiva metodologia per l’analisi del rischio nelcampo dei sistemi informatici. Non è stata però con-cepita per analizzare i sistemi industriali e per questorisulta poco precisa nell’analizzare l’impatto e leripercussioni di vulnerabilità informatiche in questisistemi. Il progetto CORAS (2001-2003) [9], sviluppò una

metodologia di analisi basata sulla modellizzazione disistemi informatici. Sfortunatamente, anche in que-sto caso, in fase di progetto, non vennero prese inconsiderazione le problematiche dei sistemi indu-striali.Dalla presentazione di tutti questi metodi, è pos-

sibile ricavare una importante osservazione: la valu-tazione della sicurezza richiede una descrizione ade-guata del sistema da analizzare, prendendo in consi-derazione tutte le rilevanti prospettive: politiche,operazioni, strutture e funzioni, collegamenti fisici,fenomeni fisici, flussi informativi ecc.Il problema della modellizzazione di infrastruttu-

re complesse è stato affrontato principalmente perscopi di progettazione o di definizione operazionale.


Igor Nai Fovino

Differenti approcci sono stati suggeriti per modella-re i sistemi alla luce di requisiti di sicurezza. Il lavoropresentato in [8] da Alberts & Dorefee è un buonesempio di metodologia di analisi del rischio basatasulla descrizione del sistema. Purtroppo tale descri-zione: (a) non è formale e (b) non è in grado di esse-re applicata proficuamente nel caso di sistemi-di-sistemi. Folker Den Braber [9] adotta un approccioparzialmente descrittivo, che cattura il concetto di“ambiente avverso” introducendo, attraverso model-li UML, il concetto di “scenario di minaccia”. Questoè ovviamente un notevole passo avanti nella rappre-sentazione di sistemi, che potrebbe essere adattataanche al caso di quelli complessi ed interattivi. Nai Fovino, in tre lavori correlati [10-11-12] pre-

senta un approccio basato sul concetto di sistema-di-sistema, che preserva l’indipendenza operazionale emanageriale dei componenti, catturando allo stessotempo il concetto di relazione tra componenti, servi-zi e sottosistemi. In questo articolo viene adottato come punto di

partenza tale approccio (descritto in dettaglio nelleprossime sezioni).Per fornire risultati di una certa qualità nell’ambi-

to della valutazione della sicurezza informatica, ènecessario prendere in considerazione quelli che ven-gono comunemente definiti “scenari di attacco”.Esistono diversi metodi in letteratura per descriverele informazioni relative ad azioni malevole (i.e. comevengono condotte, i passi eseguiti, le vulnerabilitàsfruttate ecc.). Storicamente il primo tentativo di for-nire struttura a questo processo descrittivo, vienefatto risalire alla creazione di basi di dati di vulnera-bilità (tra i quali Bugtraq [13] è un esempio). Talidatabase, ad ogni modo, sono focalizzati solo sulladescrizione di vulnerabilità, tralasciando completa-mente la descrizione dei processi che portano al lorosfruttamento durante un attacco. Uno dei più promettenti paradigmi descrittivi in

grado di catturare quest’ultimo aspetto è il “GraphBased Attack Models” [14]. In questa categoriadescrittiva due sono i principali metodi di modelliz-zazione: modelli basati sulle reti di Petri e modellibasati sugli alberi di attacco. Un buon esempio delprimo metodo è l’ “Attack Net Model” introdotto daMcDermott [15], nel quale i posti di una rete di Petrirappresentano i passi di un attacco e le transizionisono usate per catturare in modo accurato le azionifatte dall’attaccante.Il capostipite del secondo metodo di modellizza-

zione è sicuramente Bruce Schneier [16], che propo-

se l’utilizzo di “alberi d’espansione” per mostrare ledifferenti linee di attacco che possono essere utiliz-zate contro un sistema, descrivendone i passi e lerelazioni. Questo approccio è stato esteso da Nai eMasera [17] introducendo il concetto di “proiezionedi attacco”. Nel presente lavoro viene adottata que-st’ultima tecnica come punto di riferimento.

3. Definizione Preliminare dell’Ambiente

La valutazione del rischio di infrastrutture ICTrichiede la caratterizzazione (o descrizione) di dueclassi di informazioni: informazioni relative allastruttura del sistema sotto analisi e informazioni rela-tive alla sicurezza stessa.Nel seguito di questa sezione verranno presenta-

te alcune definizioni relative a queste due classi diinformazioni.

3.1. Sicurezza

Per quanto riguarda le informazioni concernentila sicurezza, molto importanti sono i concetti diMinaccia, Vulnerabilità, Attacco e Rischio.Più in dettaglio, una minaccia, come indicato in

[18] e nell’ “Internet RFC Glossary of Terms” vienedefinita come un potenziale per la violazione dellasicurezza, che esiste quanto c’è circostanza, capacità,azione o evento che potrebbe fare una breccia nellemisure di sicurezza e causare danno.Una vulnerabilità, per definizione [19][20] è una

debolezza del sistema sotto analisi, sia essa infra-strutturale, legata a processi, politiche, controlli ecc.Come diretta conseguenza, un attacco può esseredefinito come l’intero processo messo in atto da unagente di minaccia per attaccare un sistema con suc-cesso, sfruttando una o più vulnerabilità dello stesso.Infine, come definito nell’ISO/IEC 17799:2000

[21], il rischio è definito come la probabilità che unattacco/incidente accada (quando una minacciaviene attualizzata dalla combinazione di vulnerabilitàed attacchi) moltiplicato per il danno potenziale cau-sato.

3.2. Sistema

In questa seconda classe cadono tutti i concettirelativi alla modellizzazione del sistema sotto analisi.Ogni sistema può essere descritto come una col-

lezione di entità che collaborano per realizzare un



insieme di obiettivi [22]. Per il principio di ereditarie-tà, tale definizione risulta vera anche per il concettodi sottosistema.Masera e Nai [10][11][12] definiscono come

Componente un oggetto atomico (i.e. non ulteriormen-te scomponibile) in grado di realizzare in modo atti-vo o passivo una serie di compiti di basso livello. Glistessi autori definiscono il concetto di Servizio comeuna serie di compiti realizzati da componenti o sot-tosistemi. Infine, sempre Masera e Nai definiscono il con-

cetto di Dipendenza tra componenti e sotto-sistemi(e.g. un oggetto A dipende da un oggetto B se B (oun servizio fornito da B) è necessario perché A sod-disfi la sua missione). In [11] è messo in fine in evidenza il concetto di

Flusso Informativo, come insieme di relazioni punto apunto descriventi l’intero ciclo di vita delle informa-zioni del sistema sotto analisi.L’ultimo concetto necessario per descrivere un

sistema ai fini di un’analisi della sicurezza, è il con-cetto di Asset, che viene definito in [23] come unqualsiasi elemento (nel senso più generale del termi-ne), che abbia un valore per i proprietari del sistemao per chi ne usufruisce.Dato che la perdita o il danneggiamento di un

asset impatta negativamente sul valore del sistemastesso, l’obiettivo della sicurezza è quello di proteg-gerlo in modo appropriato. Va da se quindi che gli asset siano per definizione

gli oggetti più rilevanti dal punto di vista della sicu-rezza per un sistema, in quanto:1. La loro distruzione o inabilità ad eseguire lefunzioni per cui sono stati progettati può cau-sare danno all’intero sistema.

2. Sono l’obiettivo principale della quasi totalitàdegli attacchi.

3. Essi possono essere esposti a vulnerabilitàindirette, causate da altri componenti del siste-ma, di minore importanza.

Un asset può avere due forme principali: (a) uninsieme di componenti/servizi interni al sistema lacui perdita può danneggiare il sistema stesso. (b) uninsieme di servizi esterni, necessari al sistema sottoanalisi per espletare le sue stesse funzioni. Riassumendo quindi, l’approccio presentato in

questo lavoro per condurre un’analisi della sicurezzadi un sistema, richiede la descrizione puntuale diquesti elementi:• Minacce che affliggono il sistema.

• Vulnerabilità.• Insieme di alberi di attacco.• Componenti.• Servizi.• Sotto-sistemi.• Flussi informativi.• Assets.

Una valutazione della sicurezza, muoverà i suoipassi a partire dalla raccolta ed organizzazione diqueste informazioni.Nella prossima sezione viene descritto come que-

sta mole di informazioni può essere rappresentataformalmente ed utilizzata per analizzare l’esposizio-ne di un sistema a rischi di sicurezza.

4. Analisi basata sulla modellizzazione deiServizi

In questa sezione verrà fornita una panoramica diuna metodologia di analisi della sicurezza concepitaappositamente per i sistemi complessi. Per ulterioridettagli si rimanda a [10][11][12][17].Una volta definiti i concetti di base che consen-

tono di descrivere nella sua interezza un sistemacomplesso, è necessario definire un paradigma checonsenta di interconnettere i differenti aspetti sottoanalisi. Per fare un esempio, come mettere insiemetutte queste informazioni al fine di comprenderequali potrebbero essere gli effetti di una certa vulne-rabilità di un componente di un sistema industriale,sugli assets di business dello stesso sistema? Dato che gli elementi da considerare per retro-

propagare gli effetti di una vulnerabilità di una infra-struttura che è per definizione un sistema-di-sistemisono molti, una delle sfide chiave è quella di indivi-duare un paradigma che consenta di “potare” l’in-formazione in eccesso senza offuscare la qualità deirisultati ottenuti dall’analisi.Per risolvere tale problema, come illustrato in

[10][11], viene introdotto il concetto di Servizio. Seconsideriamo gli oggetti che compongono un siste-ma come “produttori e consumatori di servizi”, èpossibile sviluppare una dettagliata descrizione dellerelazioni che legano questi oggetti e catturare quindiil concetto di dipendenza che è di fatto alla base diun’analisi di sicurezza che voglia comprendere glieffetti diretti ed indiretti delle vulnerabilità informa-tiche su di un sistema complesso. Più in dettaglio:


Igor Nai Fovino

Definizione: definiamo un servizio come unatupla s=<nome, descrizione, ID, sdr>, dove: nome iden-tifica il servizio, descrizione dà una breve descrizionefunzionale del servizio, ID è l’identificatore del “pro-duttore del servizio” e sdr, come definito nel seguito,rappresenta l’informazione relativa alle dipendenzedel servizio stesso (e.g. “per completare la sua mis-sione, il servizio x necessita il diretto contributo deiservizi k, z, m”). Ovviamente è possibile ribaltare ilconcetto di servizio, parlando quindi di Disserviziocome l’inaspettato deterioramento o completa man-canza del servizio stesso. L’importanza del concettodi disservizio, è noto nella letteratura scientifica relati-va per esempio alle tecniche di analisi del guasto(Fault Tree Analysis). Ad ogni modo la sua rilevanzanon è stata, sino ad ora, mai sottolineata nel campodell’analisi di sicurezza informatica.Nella metodologia di analisi proposta in quest’ar-

ticolo, abbiamo adottato una descrizione del sistemabasata sul paradigma dell’analisi dei servizi. Inoltre èstato introdotto il concetto di disservizio. In tal modo,il sistema descritto assume un aspetto simile a quellodi un grafo orientato. Ogni componente e sottosiste-ma è direttamente o indirettamente interconnessoattraverso quella che può essere definita una “catenadi servizi” che esprime il legame intercorrente tratutti quei componenti, sottosistemi e servizi necessa-ri per portare a termine una certa missione.A riguardo degli Assets, a causa della loro natura

eterogenea (un asset può essere un componente, unsottosistema, un servizio od un insieme compren-dente tutte queste cose), non è semplice legarli allepotenziali minacce. Essendo però, per loro stessanatura degli oggetti compositi, è possibile far eredita-re agli assets stessi tutte le relazioni, vulnerabilità ecc.che sono proprie dei componenti, dei servizi e deisottosistemi che li compongono.In tal modo, anche gli Assets rientreranno nelle

catene di servizio e di disservizio del grafo che rap-presenta il sistema sotto analisi.Per chiarire il concetto, si prenda in considerazio-

ne il seguente esempio: un sistema X fornisce ad unagente esterno un Servizio Informativo IS (e.g. una cen-trale elettrica che fornisce informazione in meritoall’energia prodotta ad una entità esterna). Questoservizio è realizzato tramite l’utilizzo di una applica-zione web (WAS) al livello di sottosistema. I datiinviati all’agente esterno sono memorizzati in undatabase, che fornisce un servizio di memorizzazione(SS). Questi dati sono il risultato di una computazio-ne basata sulle informazioni recuperate da sensori

remoti, che forniscono un servizio di Monitoring sulcampo (FMS). Il servizio di alto livello IS, è collegatoa WAS in modo funzionale. Inoltre esiste un flussoinformativo tra WAS, SS e FMS. In altre parole esi-ste un collegamento indiretto tra WAS ed SS e tra SSe FMS. Questo insieme di collegamenti, che eviden-ziano come il fallimento di FMS possa avere un effet-to su IS, sono un chiaro esempio di catena di servizi.Come in [12] definiamo la relazione di servizio

come segue:

Definizione: un sistema Sn è definito come uninsieme Sn={s1, ..., sn, desc} dove s1, ..., sn sono i ser-vizi forniti da Sn e desc è la descrizione generale delsistema stesso. Senza perdere generalità possiamodescrivere un sottosistema ed un componente allostesso modo.

Definizione: Sia SoS={Sa, Sb, …, Sn} l’insiemedei sistemi/sottosistemi/componenti in SoS, tali cheServ sia l’insieme di tutti i servizi di SoS, allora unadipendenza di servizio è una tupla sdr=<s, sid, inset,outset, lf>, dove s è un servizio, sid è l’identificatore diun sistema/sottosistema/componente Sa in SoS (cheproduce il servizio), Inset dove Inset={<d, w> | d ∈Serv, w ∈ ℵ} rappresenta la collezione dei servizi checontribuiscono direttamente alla realizzazione delservizio in questione, con associata una serie di pesi(indicanti la loro rilevanza) w. lf rappresenta unaespressione logica del secondo ordine che consentedi mettere in evidenza, combinata con i pesi wdell’Inset come e con quale rilevanza i suddetti servi-zi sono logicamente correlati con quello sotto anali-si. In questo modo per esempio, è possibile rappre-sentare il fatto che un certo servizio A, per esserefornito, necessita la combinazione dei servizi(B∧C)∨D e che ognuno di questi servizi deve esse-re considerato come “fornito” ad A sino a quando lesue performances non sono al di sotto il peso asso-ciato w (un po’ come nel caso della minima QoSrichiesta in certe applicazioni). Infine, Outset è la listadi tutti i servizi ai quali il servizio in esame forniscedirettamente un contributo. Utilizzando queste definizioni, siamo quindi in

grado di costruire, partendo da un certo punto di ini-zio, (componente, sottosistema, ecc.) del sistemasotto analisi, una catena di servizi. Tale catena risulta quindi essere un grafo orienta-

to che descrive le connessioni dirette ed indirette trai servizi di un componente/sottosistema e tutti gli



altri servizi forniti da altri oggetti.Da un punto di vista di analisi della sicurezza,

queste connessioni possono essere utilizzate peridentificare l’insieme delle “dipendenze dei servizi”. Come definito da Masera, una “dipendenza di

sicurezza” esiste quando esiste una relazione tra duesistemi(o sottosistemi o componenti) A e B, tale percui un errore interno in B, possa essere propagatoattraverso una catena di guasti, errori e fallimenti, alsistema A. In tal caso, prendendo ispirazione daAvizienis et al. [25], possiamo parlare di catene patolo-giche, ossia di catene che rappresentano il possibiledecorso patologico di una malattia (nel nostro caso,il fallimento di parte del sistema sotto analisi).Ragionando in termini di sicurezza informatica, pos-siamo dire che una catena patologica è causata da (a)eventi accidentali dovuti a fallimenti interni o aderrori umani o (b) attacchi intenzionali. Dato cheogni componente della nostra descrizione di sistemasi porta, come corredo informativo, una lista dellepossibili vulnerabilità intrinseche e conosciute (ossiala lista di vulnerabilità che, a priori, è possibile asso-ciare a tale componente con un certo livello di con-fidenza), è possibile espandere il concetto di catenepatologiche aggiungendo le informazioni relative atali vulnerabilità. In questo modo, le catene cosìarricchite diventano quello che possiamo definireCatene di V ulnerabilità (Figura 1).

L’introduzione di queste catene ha tre vantaggi:1. Consente di identificare quali vulnerabilità dibasso livello (associate a qualche componentedi basso livello) possono avere un effetto suservizi di alto livello (tipicamente servizi for-niti dal sistema verso l’esterno) e sugli assetsdel sistema stesso.

2. Consente di catturare tutto l’insieme non tra-scurabile di potenziali effetti collaterali dellevulnerabilità identificate.

3. Costituisce la colla che unisce la descrizionedel sistema con le informazioni legate allasicurezza (vulnerabilità, minacce ed attacchi).

5. Analisi delle vulnerabilità

Attraverso l’adozione del paradigma di descrizio-ne appena presentato, siamo ora in grado di mostra-re come sia possibile identificare quali vulnerabilitàdi basso livello possano avere un ruolo non trascura-bile sulla sicurezza degli Assets del sistema sotto ana-lisi.Sostanzialmente l’approccio proposto è il seguen-

te:1. Per ogni asset vengono individuate tutte ledipendenze (ricordiamo qui che un asset puòessere composto da componenti, sottosistemi

fisici e da servizi).2. Per ogni elementoappartenente all’asset,vengono recuperati edenumerati i servizi cheesso fornisce.3. Tramite l’esplorazionedelle relazioni che leganoi servizi dell’elementodell’asset sotto analisi,vengono identificati tuttii componenti di bassolivello che in qualchemodo contribuiscono arendere possibile il servi-zio di alto livello dell’as-set.4. Vengono quindi asso-ciate le vulnerabilità chepotenzialmente potreb-bero affliggere il compo-nente di basso livello, chequindi vengono retro-Figura 1: Esempio di catene di vulnerabilità


Igor Nai Fovino

propagate all’asset stesso.

Applicando questa procedura siamo quindi ingrado di identificare quali vulnerabilità, associate aquali componenti, possono avere un impatto su unasset. Questo tipo di conoscenza consentirà di deci-dere, in fasi successive del processo di valutazionedella sicurezza, se le politiche di sicurezza applicatesono efficaci, di valutare possibili contromisure e diidentificare scenari di attacco e di mitigazione. Le vulnerabilità possono essere classificate, ovvia-

mente, a seconda della loro stimata rilevanza. Taleclassificazione viene utilizzata anche per identificareun ordine di urgenza nell’applicazione delle contro-misure più idonee. In Figura 2 è mostrato l’algoritmodi alto livello che implementa questa parte dell’anali-si.

6. Valutazione delle Minacce

La determinazione di quali vulnerabilità possanoimpattare gli assets di un sistema non è ovviamentesufficiente per considerare conclusa un’analisi disicurezza. A questo punto è infatti necessario analizzare

quali minacce possono utilizzare le vulnerabilitàidentificate per danneggiare il sistema. Questo è unpasso importante, che consente di identificare gliobiettivi di attacco più probabili.L’obiettivo di questa fase è quello di identificare

quali asset, vulnerabili a causa di un insieme di debo-lezze identificate nella fase precedente, sono espostia differenti tipi di minacce e quali sono le caratteri-stiche che tali minacce dovrebbero esibire per essereconsiderate una sorgente potenziale di rischio.Normalmente quando questo tipo di analisi è

applicata a sistemi relativamente piccoli, essa si esau-risce con l’assegnazione di minacce note a possibiliassets, sulla base alcune, non ben definite, ipotesifatte dall’analista.Purtroppo, questo approccio è ovviamente limita-

to se si considerano grandi sistemi come ad esempioimpianti industriali.Utilizzando le informazioni derivate dalla fase

precedente (analisi delle vulnerabilità), è possibilemigliorare questo processo.Una minaccia infatti è da considerarsi rilevante se

e solo se esiste una reale possibi-lità di realizzarla.Per dirla in parole povere, noi

possiamo ipotizzare una minac-cia “Tsunami” per un ospedale,ma tale minaccia diventa realisti-ca se e solo se l’ospedale si trovain prossimità del mare e nonsulle Alpi. Allo stesso modo, non ha

senso collegare minacce infor-matiche ad assets che, dall’analisiprecedente, risultano non impat-tati da questo tipo di minacce. In modo del tutto simile

all’approccio presentato nellasezione precedente, un’analisidelle minacce basata sul concettodi servizio, si sviluppa nelseguente modo:1. Dall’insieme di tutti i possi-

bili assets, solo il sottoinsieme di quelli affettida vulnerabilità (dirette o indirette) vienepreso in considerazione.

2. Per ogni elemento degli assets vulnerabili, ilsottoinsieme dei servizi coinvolti viene identi-ficato.

3. Le minacce ipotizzate (ipotesi basate sull’iden-tificazione di minacce specifiche per scompar-ti industriali o sulla base di informazioni pun-tuali relative alla compagnia proprietaria del-l’impianto), vengono associate ai servizi disottosistema individuati.

4. Tramite l’esplorazione delle dipendenze di ser-

Input: the set of System Assets (SA)Output: the set SA enriched with information related to the vulnerabilities associated

Main{Select Asset from SAFor each element i in Asset do

J=iIf i is a service then J=service.ID Inspect (J)

}Function Inspect (J){If check_cycle(J)=falsethen

if J.vulnset ? ø then Asset.vulnset=Asset.vulnset+J.vulnsetfor each service provided by J{sdr=retrieve s.sdrfor each service in s.sdr.inset Inspect(s.sdr.inset.ID)

}}

Figura 2: algoritmo di analisi delle vulnerabilità



vizio e delle relazioni esistenti, viene verifica-to se le minacce possono propagare i loroeffetti sugli assets definiti vulnerabili.

In tal modo, non solo è possibile ottenere uninsieme più preciso, documentato e focalizzato diservizi di sottosistema minacciabili, ma viene analiti-camente dimostrato come queste minacce possonoaffliggere questi servizi e quindi indirettamente irelativi assets.

7. Analisi degli Scenari di attacco

Il processo di analisi degli attacchi consiste nell’i-dentificazione dei potenziali attacchi che possonoessere realizzati con successo per portare a terminele minacce in precedenza identificate. Questa partedell’analisi è estremamente importante, in quantoconsente di fornire indicazioni sulla reale robustezzadel sistema, sulla sua esposizione, e sulle possibilicontromisure da intraprendere.Come descritto precedentemente, un attacco può

essere rappresentato per mezzo di alberi di attacco,che specificano i passi e le condizioni richieste per lasua realizzazione. Purtroppo un albero d’attacco ègeneralmente troppo astratto, nel senso che esprimeconcetti come il seguente: “per realizzare l’attacco ènecessario avere la vulnerabilità x sul componente ye la vulnerabilità z sul componente K”. Tali informazioni sono di scarso aiuto nel pro-

cesso di validazione perché il fatto che tali compo-nenti esistano nel sistema non implica che essi sianointerconnessi o che siano dipendenti in un modo checonsenta la realizzazione dell’attacco stesso.Un processo di validazione condotto senza que-

sto tipo di informazioni aggiuntive produrrà certa-mente risultati poco utili e ricchi di falsi positivi. Le informazioni ottenute dalla modellazione

orientata ai servizi, consentono di mitigare il rischiodi falsi positivi nel processo di validazione degliattacchi. Infatti, è possibile mappare gli alberi di attacco

sul sistema sotto analisi utilizzando come guida lecatene di dipendenza e di disservizio. Le relazioni traservizi contengono in modo intrinseco ciò che nelgergo sistemistico è noto come “conoscenza locale”e “diametro della rete”. In altre parole, utilizzandoquesti tipi di conoscenza è possibile identificare seesista qualche dipendenza e connessione tra compo-nenti vulnerabili che sia di interesse a causa di qual-

che minaccia sottesa. La validazione degli attacchi, dauna prospettiva orientata ai servizi, avviene quindicome segue:1. Gli attacchi che possono essere associati aminacce precedentemente validate sono iden-tificati e presentati come ipotesi da verificare.

2. Per ogni minaccia validata, i sottosistemi asso-ciati e le relative relazioni sono identificate.

3. Gli alberi di attacco associati alle minacceselezionate sono validati tenendo in conside-razione le informazioni derivate dalle catenedi disservizio, dalle relazioni di dipendenza eda possibili asserzioni condizionali (i.e. asser-zioni aggiuntive che esprimano ulteriori con-dizioni da soddisfare).

4. Gli attacchi validati sono utilizzati per stimarel’impatto sugli assets, tenendo in considera-zione gli effetti diretti ed indiretti (ricavabili,ancora una volta, dall’analisi delle catene didipendenza e disservizio).

In questo modo è possibile ridurre lo spazio degliattacchi da analizzare ai soli aventi effettivamentepossibilità di impattare sul sistema, diminuendonotevolmente il numero di falsi positivi.L’output dei passi precedentemente presentati

consente di mettere quindi in evidenza:1. Le dipendenze che legano il sistema industria-le sotto analisi.

2. Le vulnerabilità di basso livello che possonoimpattare sul sistema e la loro catalogazione aseconda della severità di impatto e della pro-babilità di occorrenza.

3. Gli asset che possono essere minacciati.4. L’insieme degli attacchi che possono esserecon buona probabilità di successo realizzaticontro un certo insieme di assets.

Tali informazioni consentono di computare agil-mente un calcolo del rischio al quale l’impianto è sot-toposto, e di individuare agilmente le contromisurepiù opportune.

8. Risultati Sperimentali

La metodologia presentata nelle sezioni prece-denti è stata implementata all’interno di uno stru-mento software (InSAW-Industrial SecurityAssessment Workbench) che ne consente l’utilizzoimmediato [26].


Igor Nai Fovino

Il cuore di tale software è un’articolata base di datirelazionale in grado di contenere informazioni relati-ve a tutti gli oggetti necessari per l’analisi, compresoun set di librerie di vulnerabilità, alberi di attacco eminacce collezionate nel corso di anni di test ed espe-rimenti.Tale strumento è dotato di una mappatura ad

oggetti che consente di rappresentare graficamentel’intera architettura dell’infrastruttura industriale ana-lizzata, associandovi componenti e vulnerabilità inmodo automatico.Una suite di algoritmi appositamente sviluppati

consente di retro-propagare le vulnerabilità sugliassets, di mappare gli attacchi e di validarne la fattibi-lità. Tale strumento è stato sviluppato presso ilCentro di Ricerca della Commissione Europea diIspra [26].La metodologia presentata nelle sezioni prece-

denti, è stata applicata con successo in diversi conte-sti. In particolare è stata utilizzata per valutare la sicu-rezza di sistemi di controllo industriale e di centralielettriche[27][28]. In questa sezione vengono presen-tati brevemente i risultati della sua applicazione nellavalutazione della sicurezza informatica di una centra-le elettrica. I risultati sono volutamente descritti adalto livello, in quanto coperti da non-disclosure-agreement. Un impianto di generazione è un ambiente estre-

mamente complesso, che coinvolge molti sistemidiversi, sia da un punto di vista tecnico, che di requi-siti che di politiche e gestione. In accordo con lametodologia presentata l’impianto è stato analizzatoper identificare:

Assets, flussi informativi, componenti, sottosistemi, servizie dipendenze tra i differenti servizi.I sottosistemi individuati sono stati i seguenti:- Sottosistema di Campo: ospita i PLC/RTU dicontrollo, gli attuatori ed i sensori della cen-trale elettrica.

- Sottosistema di controllo di processo e acquisizionedati: è quello che in gergo tecnico viene chia-mato sistema SCADA, e che ha in carico ilcontrollo dei processi di centrale.

- Rete di controllo: che interconnette tutti i sotto-sistemi di centrale.

- Rete Dati: che interconnette centrali diverse.- Business network: che contiene tutti i sistemi uti-lizzati dagli operatori e tutte le funzioni cosìdette “corporate”.

- Firewall: sistema che in realtà raggruppa tutti ifirewall e gli elementi di controllo sparsi all’in-

terno delle diverse reti, e che per comoditàsono stati raggruppati all’interno di un unicosistema.

Il numero di componenti analizzati ed enumeratidurante l’analisi è stato nell’ordine delle tremila enti-tà. Ad ognuno di questi componenti sono stati auto-maticamente associati gli insiemi di vulnerabilità chepotrebbero in ipotesi, affliggerli (tale operazione èstata resa possibile grazie all’utilizzo di un databaseappositamente realizzato per le vulnerabilità dei siste-mi industriali). A seguito di questa fase esplorativa, sono state

identificate le politiche operazionali e di sicurezzaapplicate ad ogni componente e sistema identificato.Sono stati inoltre identificati i requisiti operazionalidi processo e di funzionamento. Tali informazionisono state poi utilizzate in fase di analisi per identifi-care se e come certi profili di attacco potessero averesenso, e per valutare l’impatto di eventuali contromi-sure.Agli asset risultanti esposti a vulnerabilità di basso

livello (informazione derivata dall’analisi delle catenedi vulnerabilità e disservizio), sono state in seguitoassociate ipotesi di minaccia basate sulla classificazio-ne fornita dall’U.S. GAO [29].In questo caso particolare sono stati considerati 5

particolari agenti di minaccia:- Insiders: ossia dipendenti della stessa aziendaproprietaria dell’impianto.

- Crackers.- Malware Interni.- Malware Esterni.- Gruppi organizzati: hacktivisti (ossia hacker chesposano cause tipiche dei moderni attivisti),crimine organizzato, ecc.

Seguendo tale approccio, sono state individuatecirca 1000 differenti vulnerabilità di un certo rilievo,e tra queste, 156 aventi un impatto critico sul sistemasotto analisi.Tali vulnerabilità sono state classificate in accordo

con la loro probabilità di occorrenza e con la severi-tà del loro impatto sull’infrastruttura.Sulla base delle conoscenze accumulate, sono stati

identificati sette potenziali scenari di attacco com-plesso in grado di impattare sulla centrale in esame.Come detto all’inizio di questa sezione, non è possi-bile riportare in questo lavoro i dettagli di tali scena-ri. Ciò che ha rilevanza è in ogni caso il fatto chemolti di questi scenari di attacco sfruttano una serie



di effetti collaterali che, senza l’applicazione di unametodologia di analisi basata sulla modellizzazionedei servizi, sarebbe stato estremamente difficile sco-prire.

9. Conclusioni

Centrali Elettriche, sistemi di controllo dei tra-sporti, reti elettriche, gasdotti, sono tutte infrastrut-ture necessarie per la vita di tutti i giorni, che, per leloro peculiarità storiche sono sempre state vistecome modi completamente isolati, a se stanti, e perquesto avulse dai fenomeni di criminalità informati-ca che le cronache ci hanno abituato ad osservare inaltri campi.Il senso di sicurezza derivato da questa supposta

estraneità di tali infrastrutture nei confronti delleminacce informatiche, non ha motivo di esistere.L’imperante diffusione delle tecnologie informatichenel mondo del controllo di processo industriale, ladiffusione dell’utilizzo delle classiche reti informati-che basate su TCP/IP per scambiare flussi di con-trollo, se da una parte ha reso possibili incredibilipassi avanti nella gestione coordinata di tali installa-zioni, dall’altra ha aperto le porte a nuovi, inimmagi-nabili scenari di fallimento, dovuti proprio alle vul-nerabilità del mondo informatico.

La valutazione del livello di sicurezza informaticadelle infrastrutture critiche industriali è diventato,alla luce di tutto ciò, di grande importanza.La letteratura scientifica moderna, è ricca di

esempi di metodologie di valutazione della sicurezzaapplicate a sistemi informatici tradizionali. Talimetodologie purtroppo si sono rivelate poco adattead analizzare realtà estremamente complesse, etero-genee e peculiari come quelle dei sistemi industriali.In questo lavoro è stata fornita una panoramica di

una metodologia per la valutazione di sicurezza ditali sistemi, sviluppata nei laboratori del Centro diRicerca della Commissione Europea e poi applicatain diversi casi di studio. Tale metodologia, si basa sul concetto di model-

lizzazione delle relazioni esistenti tra i vari compo-nenti del sistema sotto analisi e nell’utilizzo dellaconoscenza derivante da tale modellizzazione, al finedi identificare e comprendere a pieno gli effetti col-laterali di eventuali vulnerabilità identificate ed il loroimpatto su quelli che vengono comunemente defini-ti gli asset dell’infrastruttura.L’adozione di tale metodologia non è ovviamen-

te indolore, in quanto la quantità di informazioni dagestire ed analizzare è ingente, ma, test sul campohanno dimostrato come la sua applicazione sia inrealtà fattibile e come i risultati ottenuti valgano ilcosto dello sforzo intrapreso.

BIBLIOGRAFIA

[1] Stuxnet: http://www.symantec.com/connect/blogs/w32stuxnet-dossier[2] M. Keeney, E. Kowalski, D. Cappelli, A. Moore, T. Shimeall, S. Rogers. “Insider Threat Study: Computer

System Sabotage in Critical Infrastructure Sectors”. CMU, May 2005. [3] G. Stoneburner, A. Goguen, A. Feringa. “Risk Management Guide for Information Technology

Systems”. Special publication 800-3, National institute of Standards and Technology. [4] Frank Swiderski and Window Snyder. “Threat Modeling”, Microsoft Press 2004 [5] E. Bertino, D. Bruschi, S. Franzoni, I. Nai-Fovino, and S. Valtolina. “Threat modelling for SQL Servers”.

Eighth IFIP TC-6 TC-11 Conference on Communications and Multimedia Security (CMS 2004),September 2004, UK, pp189-201.

[6] “Microsoft Security Assessment Tool” https://www.securityguidance.com/ [7] “Citicus ONE”. http://www.citicus.com [8] C. Alberts A. Dorofee “Managing Information Security Risks: The OCTAVE (SM) Approach”, July

2002, Addison Wesley Professional.[9] Folker den Braber, Theo Dimitrakos, Bjørn Axel Gran, Ketil Stølen, Jan Øyvind Aagedal, “The CORAS

methodology: Model-based risk management using UML and UP”, in UML and the Unified Process.IRM Press, 2003.


Igor Nai Fovino

[10] Masera, M. & Nai Fovino, I., Models for security assessment and management. In proceeding of theInternational Workshop on Complex Network and Infrastructure Protection, 2006.

[11] Masera, M. & Nai Fovino, I. (2006). Modelling Information Assets for Security Risk Assessment inIndustrial settings. 15th EICAR Annual Conference

[12] Nai Fovino, I. & Masera, M. (2006). “Emergent Disservices in Interdependent Systems and System-of-Systems”. In proceeding of the IEEE Conference on Systems, Man and Cybernetics, October 8-11 2006,Taipei.

[13] Bugtraq vulnerability database. http://securityfocus.com[14] Steffan, J., Schumacher, M.: Collaborative attack modeling. In proceeding of the Symposium on Applied

Computing, Madrid, Spain (2002) pp. 253 – 259[15] McDermott, J. (2000). “Attack Net Penetration Testing”. In The 2000 New Security Paradigms Workshop

(Ballycotton, County Cork, Ireland, Sept. 2000), ACM SIGSAC, ACM Press, pp. 15-22.[16] Schneier, B.: Modeling Security Threats, Dr. Dobb's Journal. https://www.schneier.com/paper-attack-

trees-ddj-ft.html (2001).[17] Nai Fovino, I. & Masera.M (2006). "Through the Description of Attacks: a multidimensional View". In

proceeding of the 25th International Conference on Computer Safety, Reliability and Security 26-29September 2006 Gdansk, Poland

[18] Jones, A., Ashenden, D.(2005). “Risk Management for Computer Security : Protecting Your Network &Information Assets”. Elsevier (March 2005).

[19] Alhazmi, O., Malaiya, Y., & Ray, I. (2005). “Security Vulnerabilities in Software Systems: A QuantitativePerspective”. Lecture Notes in Computer Science, Volume 3654/2005. (2005) Publisher: Springer-VerlagGmbH.

[20] Bishop, M. (2004). “Computer Security Art and Science” (November 2004) AddisonWesley.[21] Code of Practice for Information Security Management. International Standard (ISO/IEC) 17799:2000.[22] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology[23] Masera, M. & Nai Fovino, I. (2005). “A framework for the security assessment of remote control appli-

cations of critical infrastructures”, ESREDA 2005.[24] Masera, M. (2006). “Interdependencies and Security Assessment: a Dependability view”. In proceeding

of the IEEE Conference on Systems, Man and Cybernetics, October 8-11 2006, Taipei. [25] Avizienis, A., Laprie, J.C., Randell, B. and Landwehr, C. (2004). “Basic Concepts and Taxonomy of

Dependable and Secure Computing”. IEEE Tr. On Dependable and Secure Computing, Jan–March 2004(Vol 1, No. 1), pp 11–33.

[26] I. Nai Fovino, M. Masera “InSAW-Industrial Security Assessment Workbench”. In proceeding of theInternational Conference on Infrastructure Systems, Rotterdam, November 10-12, 2008

[27] I. Nai Fovino, M. Masera, L. Guidi, A. Stefanini. "Cyber Security Assessment of a Power Plant".International Journal of Electric Power System Research, Elsevier, 81 (2), pp. 518-526

[28] Dondossola, G., Szanto, J., Masera, M. and Nai Fovino, I., Evaluation of the effects of intentional threatsto power substation control systems. International Journal of Critical Infrastructure, 2007

[29] Critical Infrastructure Protection, Challenges and Efforts to Secure Control Systems. United StatesGovernment Accountability Office, 2004. GAO-04-628T.

Documents

Valutazione della sicurezza informatica delle infrastrutture critiche ... · 102 Speciale Sicurezza ICT Igor Nai Fovino definite industriali (centrali elettriche, nucleari, siste-mi