Valutazione della sicurezza informatica delle infrastrutture critiche

Igor Nai Fovino
Global Cyber Security Center
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE,
DEFINIZIONI E METODOLOGIA
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS
METHODOLOGY)
Sommario
Le minacce alla sicurezza sono uno dei principali problemi dell’era dei calcolatori. Tutti i sistemi che fanno uso delle
tecnologie dell’informazione e della comunicazione (ICT) sono
esposti a malfunzionamenti e vulnerabilità che possono essere
sfruttati da codice e agenti maligni. Considerando l’uso imponente delle tecnologie ICT nelle cosiddette “infrastrutture critiche”, diventa doveroso eseguire adeguate valutazioni dei rischi
sulla sicurezza, mettendo in evidenza le principali minacce a
cui un sistema è esposto e, alla fine, l’efficacia delle possibili
contromisure. Sfortunatamente, le caratteristiche delle infrastrutture critiche industriali rendono difficile l’uso delle tecniche tradizionali di valutazione del rischio. In questo contributo presentiamo una metodologia innovativa per la valutazione
del rischio sulla sicurezza adattata alle esigenze di questi particolari sistemi e basata sul paradigma dei sistemi-di-sistemi e
sul concetto di “modellazione orientata al servizio”. Dopo
aver fornito una panoramica dello Stato dell’Arte nella disciplina della valutazione del rischio per le Infrastrutture
Critiche, forniamo alcune definizioni base sulla sicurezza e
infrastrutture critiche. Successivamente descriviamo la metodologia proposta, presentando i risultati della sua applicazione
in un caso di studio concreto.
1. Introduzione
Le minacce informatiche sono uno dei principali
problemi dell’era digitale.
Tutti i sistemi che fanno uso di tecnologie informatiche sono potenzialmente soggetti a vulnerabilità
che potrebbero essere sfruttate da software malevoli
(virus, worms ecc.) e da criminali.
La situazione è ancora più delicata se consideriamo il caso delle infrastrutture critiche, ossia quelle
infrastrutture il cui danneggiamento può impattare
seriamente la vita del comune cittadino. Esempi di
Speciale Sicurezza ICT
A bstract
Security threats are one of the main problems of this computer-based era. All systems making use of information and
communication technologies (ICT) are prone to failures and
vulnerabilities that can be exploited by malicious software and
agents. Considering the massive use of ICT technologies in the
so called “critical infrastructures”, it become imperative to perform adequate security risk assessments, putting in evidence the
main threats a system is exposed to and eventually the effectiveness of the possible countermeasures. Unfortunately, the
peculiarities of industrial critical infrastructures make hard
the use of traditional security assessment techniques. In this
paper we present an innovative security assessment methodology tailored for these particular systems, and based on the
system-of-system paradigm and on the concept of “service
oriented modelling”. After giving an overview of the State of
the Art in the field of security assessment for Critical
Infrastructures, we provide some basic definitions on security
and critical infrastructures. Then we describe the proposed
methodology, presenting the results of its application on a real
case study.
infrastrutture critiche possono essere centrali elettriche, impianti per l’acqua potabile, ma anche sistemi
di controllo del traffico ferroviario, aereo e così via.
Se una di queste infrastrutture venisse attaccata o
danneggiata, gli effetti potrebbero essere estremamente dannosi.
Per questo motivo tali infrastrutture dovrebbero
essere ciclicamente sottoposte a processi di security
assessment (i.e. valutazione della loro sicurezza), al
fine di individuare eventuali falle e porvi rimedio.
In questo articolo poniamo l’attenzione su quelle
infrastrutture critiche che, per definizione, vengono
101
Igor Nai Fovino
definite industriali (centrali elettriche, nucleari, sistemi di controllo ferroviari, reti gas, acquedotti ecc.).
Tali infrastrutture presentano peculiarità che, per
motivi storici e tecnici, le differenziano nettamente
da quelle informatiche tradizionali.
Le infrastrutture industriali combinano assieme
tipici sistemi informatici (basi di dati, protocolli
TCP/IP, sistemi operativi ed applicazioni da ufficio),
con software ed elementi aventi caratteristiche di
tempo reale che implementano le funzioni di controllo dei dispositivi di basso livello (ad esempio
sistemi per il controllo e la misura della pressione di
condutture, della velocità di turbine, del grado di
apertura di valvole idrauliche, ecc.).
Negli ultimi anni, questi già complessi sistemi
ibridi, hanno iniziato ad essere connessi a reti interne
ed esterne al perimetro aziendale. Se da una parte tale
innovazione tecnologica ha reso possibili molti nuovi
servizi, 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 infrastrutture critiche era più che altro un fatto di “sicurezza
fisica e controllo degli accessi”, nei moderni sistemi,
non più isolati dal resto del mondo, le vulnerabilità
informatiche sono diventate oggetto di massima
attenzione.
Mentre per le infrastrutture informatiche tradizionali esistono in letteratura (come verrà presentato
nella sezione relativa) metodologie per la valutazione
della sicurezza informatica ben collaudate, il campo
della valutazione della sicurezza informatica delle
infrastrutture critiche industriali è relativamente giovane. La maggior parte dell’attenzione, in questo
contesto, è spesso concentrato sulla valutazione dei
classici sistemi informatici della rete aziendale, tralasciando completamente tutto ciò che avviene nel lato
industriale degli impianti.
Purtroppo i maggiori rischi, come il caso Stuxnet
[1] insegna, sono nella parte bassa di queste infrastrutture, ossia in quelli più vicini ai meccanismi di
controllo. Le metodologie tradizionali di valutazione
della sicurezza informatica non sono adeguate ad
analizzare questa parte dei sistemi industriali: la
coesistenza di ambienti molto eterogenei (sistemi
real-time, sistemi elettromeccanici, software sviluppati appositamente per applicazioni particolari, sistemi desktop), i vincoli che derivano dai fenomeni fisici controllati da questi sistemi (ad esempio la stabilità elettrica) e gli obiettivi di business nettamente
diversi rispetto al mondo informatico tradizionale
costituiscono elementi di difficile valutazione e com-
102
prensione.
Per rendere chiara questa diversità, consideriamo
questo esempio: è prassi normale avere delle politiche di software patch nei sistemi informatici, spesso
configurate per installare automaticamente nuovi
aggiornamenti quando questi sono disponibili.
Mentre tale pratica è da considerare altamente consigliata in sistemi informatici tradizionali, nel caso dei
sistemi industriali potrebbe non essere la migliore:
spesso l’installazione di una patch richiede il riavvio
della macchina, ma se questa macchina controlla un
processo industriale, il suo riavvio implica automaticamente l’alt dell’intera catena di produzione, fatto
questo che causa notevoli costi economici e che
potrebbe non essere possibile se non mettendo a
rischio servizi ritenuti vitali per la società (si pensi
allo stop di una centrale elettrica).
Questi vincoli influenzano pesantemente il modo
e le procedure che devono essere intraprese quando
si tratta di intervenire sulla sicurezza di infrastrutture
industriali, e di conseguenza l’analisi di sicurezza
deve essere in grado di tenerne conto.
Inoltre tali considerazioni mettono in evidenza
come esista la necessità di includere nei processi di
analisi la comprensione del funzionamento di elementi che con l’informatica hanno in linea di principio ben poco a che fare.
Ciò pone l’attenzione sulla necessità di tenere in
considerazione dell’eterogeneità di informazioni che
un processo di analisi della sicurezza deve essere in
grado di processare nel caso di infrastrutture industriali:
• Caratteristiche dei sistemi coinvolti (hardware,
procedure, processi, politiche di sicurezza,
politiche di operatività in condizioni normali e
di emergenza, ecc.).
• Vulnerabilità.
• Minacce (agenti di minaccia, risorse di attacco
stimate, ecc.).
• Attacchi.
• Contromisure.
Oltre a tutto questo è necessario tenere conto
anche delle interazioni tra azioni malevole, fallimenti
accidentali di sistemi di controllo ed errori umani.
Negli ultimi anni le cose poi si sono ulteriormente complicate: l’utilizzo della rete pubblica per interconnettere diverse parti di queste infrastrutture critiche, ha fatto evolvere questi sistemi da “isolati” a
complessi sistemi-di-sistemi. Così, la comprensione
degli effetti collaterali o dei fallimenti locali, deve
Speciale Sicurezza ICT
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE, DEFINIZIONI E METODOLOGIA.
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS METHODOLOGY)
essere oggi estesa ben oltre i confini del singolo
impianto, aggiungendo strati di complessità.
I tradizionali processi di valutazione della sicurezza mal si sposano con il paradigma di sistema-disistema, date le intrinseche difficoltà nell’identificare
le interdipendenze e gli effetti della propagazione di
errori e guasti.
Alcuni approcci all’analisi delle proprietà di sicurezza sono stati, ad onor del vero, proposti (si veda
la prossima sezione). In generale tali metodologie
mirano a collegare a descrizioni strutturali e funzionali degli obiettivi di sicurezza.
In questo articolo viene presentata una nuova
metodologia per la valutazione del livello di sicurezza delle infrastrutture industriali basata sul concetto
di modellizzazione e mappatura dei servizi. Tale
mappatura, consente di effettuare un’analisi basata
sulla correlazione sistematica, passando quindi da
una più tradizionale visione basata su eventi di sicurezza ad una più complessa e completa che consenta
di catturare anche gli effetti di tali eventi sull’intera
infrastruttura.
In questo articolo, dopo aver presentato una
panoramica dello stato dell’arte nell’ambito delle
metodologie di valutazione della sicurezza dei sistemi IT, viene analizzata la relazione esistente tra i differenti insiemi di “informazioni” che possono essere
usati per descrivere il sistema sotto analisi dal punto
di vista della sicurezza informatica.
Infine viene presentata la metodologia che consente di sfruttare tali informazioni al fine di analizzare il livello di sicurezza del sistema.
2. Stato dell’arte
Nella letteratura scientifica non esiste una metodologia ritagliata su misura per analizzare la sicurezza informatica dei sistemi industriali; in ogni caso nel
campo dell’informatica e nel campo della safety esistono alcuni approcci che vale la pena menzionare.
La valutazione dei sistemi industriali è campo tradizionale della “Safety Analysis”. Solo di recente le
problematiche di sicurezza sono entrate prepotentemente in questo mondo. Keeney [2] nel 2005 presentò uno studio sugli effetti del sabotaggio di sistemi informatici nelle infrastrutture critiche.
Stoneburner, Goguen e Feringa [3], nel loro studio
sull’analisi del rischio nei sistemi informatici descrivono una procedura basata su nove passi per la valutazione dei rischi derivanti dalle vulnerabilità dei
Speciale Sicurezza ICT
sistemi informatici tradizionali. Swiderski e Snyder
[4] introducono il concetto di “Threat Modeling”
(modellizzazione delle minacce), e presentano un
approccio strutturato per identificare, valutare e
mitigare rischi associati alla sicurezza dei sistemi.
Tale lavoro, presentando per primo il concetto di
modellizzazione delle minacce rappresenta sicuramente un passo avanti in questo ambito. Una applicazione di tale approccio nel mondo reale viene presentata in [5]. Esistono inoltre alcuni strumenti
appositamente sviluppati per la valutazione di sistemi generici, come ad esempio “Microsoft Security
Assessment tool” [6] e “Citicus” [7]. Il primo implementa in sostanza un tradizionale processo di “check
list”; in altre parole, l’intero processo di valutazione
passa attraverso una serie di sessioni di “domanderisposte” che guidano l’analista nell’esecuzione della
valutazione, e che producono come output una serie
di raccomandazioni. Ovviamente, vista la sua genericità, tale oggetto è lungi dall’essere in grado di fornire un’analisi esaustiva e precisa, specialmente nel
campo dei sistemi industriali, per l’analisi dei quali,
ovviamente, non è stato concepito. Il secondo strumento, Citicus, è basato sul concetto di rischio percepito, categorizzando di fatto tali rischi in accordo
con una serie di criteri preconfezionati.
L’approccio OCTAVE [8], introdotto dal
“Software Engineering Institute” del MIT verso la
fine degli anni ’90, rappresenta al momento la più
esaustiva metodologia per l’analisi del rischio nel
campo dei sistemi informatici. Non è stata però concepita per analizzare i sistemi industriali e per questo
risulta poco precisa nell’analizzare l’impatto e le
ripercussioni di vulnerabilità informatiche in questi
sistemi.
Il progetto CORAS (2001-2003) [9], sviluppò una
metodologia di analisi basata sulla modellizzazione di
sistemi informatici. Sfortunatamente, anche in questo caso, in fase di progetto, non vennero prese in
considerazione le problematiche dei sistemi industriali.
Dalla presentazione di tutti questi metodi, è possibile ricavare una importante osservazione: la valutazione della sicurezza richiede una descrizione adeguata del sistema da analizzare, prendendo in considerazione tutte le rilevanti prospettive: politiche,
operazioni, strutture e funzioni, collegamenti fisici,
fenomeni fisici, flussi informativi ecc.
Il problema della modellizzazione di infrastrutture complesse è stato affrontato principalmente per
scopi di progettazione o di definizione operazionale.
103
Igor Nai Fovino
Differenti approcci sono stati suggeriti per modellare i sistemi alla luce di requisiti di sicurezza. Il lavoro
presentato in [8] da Alberts & Dorefee è un buon
esempio di metodologia di analisi del rischio basata
sulla descrizione del sistema. Purtroppo tale descrizione: (a) non è formale e (b) non è in grado di essere applicata proficuamente nel caso di sistemi-disistemi. Folker Den Braber [9] adotta un approccio
parzialmente descrittivo, che cattura il concetto di
“ambiente avverso” introducendo, attraverso modelli UML, il concetto di “scenario di minaccia”. Questo
è ovviamente un notevole passo avanti nella rappresentazione di sistemi, che potrebbe essere adattata
anche al caso di quelli complessi ed interattivi.
Nai Fovino, in tre lavori correlati [10-11-12] presenta un approccio basato sul concetto di sistema-disistema, che preserva l’indipendenza operazionale e
manageriale dei componenti, catturando allo stesso
tempo il concetto di relazione tra componenti, servizi e sottosistemi.
In questo articolo viene adottato come punto di
partenza tale approccio (descritto in dettaglio nelle
prossime sezioni).
Per fornire risultati di una certa qualità nell’ambito della valutazione della sicurezza informatica, è
necessario prendere in considerazione quelli che vengono comunemente definiti “scenari di attacco”.
Esistono diversi metodi in letteratura per descrivere
le informazioni relative ad azioni malevole (i.e. come
vengono condotte, i passi eseguiti, le vulnerabilità
sfruttate ecc.). Storicamente il primo tentativo di fornire struttura a questo processo descrittivo, viene
fatto risalire alla creazione di basi di dati di vulnerabilità (tra i quali Bugtraq [13] è un esempio). Tali
database, ad ogni modo, sono focalizzati solo sulla
descrizione di vulnerabilità, tralasciando completamente la descrizione dei processi che portano al loro
sfruttamento durante un attacco.
Uno dei più promettenti paradigmi descrittivi in
grado di catturare quest’ultimo aspetto è il “Graph
Based Attack Models” [14]. In questa categoria
descrittiva due sono i principali metodi di modellizzazione: modelli basati sulle reti di Petri e modelli
basati sugli alberi di attacco. Un buon esempio del
primo metodo è l’ “Attack Net Model” introdotto da
McDermott [15], nel quale i posti di una rete di Petri
rappresentano i passi di un attacco e le transizioni
sono usate per catturare in modo accurato le azioni
fatte dall’attaccante.
Il capostipite del secondo metodo di modellizzazione è sicuramente Bruce Schneier [16], che propo-
104
se l’utilizzo di “alberi d’espansione” per mostrare le
differenti linee di attacco che possono essere utilizzate contro un sistema, descrivendone i passi e le
relazioni. Questo approccio è stato esteso da Nai e
Masera [17] introducendo il concetto di “proiezione
di attacco”. Nel presente lavoro viene adottata quest’ultima tecnica come punto di riferimento.
3. Definizione Preliminare dell’Ambiente
La valutazione del rischio di infrastrutture ICT
richiede la caratterizzazione (o descrizione) di due
classi di informazioni: informazioni relative alla
struttura del sistema sotto analisi e informazioni relative alla sicurezza stessa.
Nel seguito di questa sezione verranno presentate alcune definizioni relative a queste due classi di
informazioni.
3.1. Sicurezza
Per quanto riguarda le informazioni concernenti
la sicurezza, molto importanti sono i concetti di
Minaccia, Vulnerabilità, Attacco e Rischio.
Più in dettaglio, una minaccia, come indicato in
[18] e nell’ “Internet RFC Glossary of Terms” viene
definita come un potenziale per la violazione della
sicurezza, che esiste quanto c’è circostanza, capacità,
azione o evento che potrebbe fare una breccia nelle
misure di sicurezza e causare danno.
Una vulnerabilità, per definizione [19][20] è una
debolezza del sistema sotto analisi, sia essa infrastrutturale, legata a processi, politiche, controlli ecc.
Come diretta conseguenza, un attacco può essere
definito come l’intero processo messo in atto da un
agente di minaccia per attaccare un sistema con successo, sfruttando una o più vulnerabilità dello stesso.
Infine, come definito nell’ISO/IEC 17799:2000
[21], il rischio è definito come la probabilità che un
attacco/incidente accada (quando una minaccia
viene attualizzata dalla combinazione di vulnerabilità
ed attacchi) moltiplicato per il danno potenziale causato.
3.2. Sistema
In questa seconda classe cadono tutti i concetti
relativi alla modellizzazione del sistema sotto analisi.
Ogni sistema può essere descritto come una collezione di entità che collaborano per realizzare un
Speciale Sicurezza ICT
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE, DEFINIZIONI E METODOLOGIA.
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS METHODOLOGY)
insieme di obiettivi [22]. Per il principio di ereditarietà, tale definizione risulta vera anche per il concetto
di sottosistema.
Masera e Nai [10][11][12] definiscono come
Componente un oggetto atomico (i.e. non ulteriormente scomponibile) in grado di realizzare in modo attivo o passivo una serie di compiti di basso livello. Gli
stessi autori definiscono il concetto di Servizio come
una serie di compiti realizzati da componenti o sottosistemi.
Infine, sempre Masera e Nai definiscono il concetto di Dipendenza tra componenti e sotto-sistemi
(e.g. un oggetto A dipende da un oggetto B se B (o
un servizio fornito da B) è necessario perché A soddisfi la sua missione).
In [11] è messo in fine in evidenza il concetto di
Flusso Informativo, come insieme di relazioni punto a
punto descriventi l’intero ciclo di vita delle informazioni del sistema sotto analisi.
L’ultimo concetto necessario per descrivere un
sistema ai fini di un’analisi della sicurezza, è il concetto di Asset, che viene definito in [23] come un
qualsiasi elemento (nel senso più generale del termine), che abbia un valore per i proprietari del sistema
o per chi ne usufruisce.
Dato che la perdita o il danneggiamento di un
asset impatta negativamente sul valore del sistema
stesso, l’obiettivo della sicurezza è quello di proteggerlo in modo appropriato.
Va da se quindi che gli asset siano per definizione
gli oggetti più rilevanti dal punto di vista della sicurezza per un sistema, in quanto:
1. La loro distruzione o inabilità ad eseguire le
funzioni per cui sono stati progettati può causare 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 sistema, di minore importanza.
Un asset può avere due forme principali: (a) un
insieme di componenti/servizi interni al sistema la
cui perdita può danneggiare il sistema stesso. (b) un
insieme di servizi esterni, necessari al sistema sotto
analisi per espletare le sue stesse funzioni.
Riassumendo quindi, l’approccio presentato in
questo lavoro per condurre un’analisi della sicurezza
di un sistema, richiede la descrizione puntuale di
questi elementi:
• Minacce che affliggono il sistema.
Speciale Sicurezza ICT
•
•
•
•
•
•
•
Vulnerabilità.
Insieme di alberi di attacco.
Componenti.
Servizi.
Sotto-sistemi.
Flussi informativi.
Assets.
Una valutazione della sicurezza, muoverà i suoi
passi a partire dalla raccolta ed organizzazione di
queste informazioni.
Nella prossima sezione viene descritto come questa mole di informazioni può essere rappresentata
formalmente ed utilizzata per analizzare l’esposizione di un sistema a rischi di sicurezza.
4. Analisi basata sulla modellizzazione dei
Servizi
In questa sezione verrà fornita una panoramica di
una metodologia di analisi della sicurezza concepita
appositamente per i sistemi complessi. Per ulteriori
dettagli si rimanda a [10][11][12][17].
Una volta definiti i concetti di base che consentono di descrivere nella sua interezza un sistema
complesso, è necessario definire un paradigma che
consenta di interconnettere i differenti aspetti sotto
analisi. Per fare un esempio, come mettere insieme
tutte queste informazioni al fine di comprendere
quali potrebbero essere gli effetti di una certa vulnerabilità di un componente di un sistema industriale,
sugli assets di business dello stesso sistema?
Dato che gli elementi da considerare per retropropagare gli effetti di una vulnerabilità di una infrastruttura che è per definizione un sistema-di-sistemi
sono molti, una delle sfide chiave è quella di individuare un paradigma che consenta di “potare” l’informazione in eccesso senza offuscare la qualità dei
risultati ottenuti dall’analisi.
Per risolvere tale problema, come illustrato in
[10][11], viene introdotto il concetto di Servizio. Se
consideriamo gli oggetti che compongono un sistema come “produttori e consumatori di servizi”, è
possibile sviluppare una dettagliata descrizione delle
relazioni che legano questi oggetti e catturare quindi
il concetto di dipendenza che è di fatto alla base di
un’analisi di sicurezza che voglia comprendere gli
effetti diretti ed indiretti delle vulnerabilità informatiche su di un sistema complesso.
Più in dettaglio:
105
Igor Nai Fovino
Definizione: definiamo un servizio come una
tupla s = <nome, descrizione, ID, sdr>, dove: nome identifica il servizio, descrizione dà una breve descrizione
funzionale del servizio, ID è l’identificatore del “produttore del servizio” e sdr, come definito nel seguito,
rappresenta l’informazione relativa alle dipendenze
del servizio stesso (e.g. “per completare la sua missione, il servizio x necessita il diretto contributo dei
servizi k, z, m”). Ovviamente è possibile ribaltare il
concetto di servizio, parlando quindi di Disservizio
come l’inaspettato deterioramento o completa mancanza del servizio stesso. L’importanza del concetto
di disservizio, è noto nella letteratura scientifica relativa per esempio alle tecniche di analisi del guasto
(Fault Tree Analysis). Ad ogni modo la sua rilevanza
non è stata, sino ad ora, mai sottolineata nel campo
dell’analisi di sicurezza informatica.
Nella metodologia di analisi proposta in quest’articolo, abbiamo adottato una descrizione del sistema
basata sul paradigma dell’analisi dei servizi. Inoltre è
stato introdotto il concetto di disservizio. In tal modo,
il sistema descritto assume un aspetto simile a quello
di un grafo orientato. Ogni componente e sottosistema è direttamente o indirettamente interconnesso
attraverso quella che può essere definita una “catena
di servizi” che esprime il legame intercorrente tra
tutti quei componenti, sottosistemi e servizi necessari per portare a termine una certa missione.
A riguardo degli Assets, a causa della loro natura
eterogenea (un asset può essere un componente, un
sottosistema, un servizio od un insieme comprendente tutte queste cose), non è semplice legarli alle
potenziali minacce. Essendo però, per loro stessa
natura degli oggetti compositi, è possibile far ereditare agli assets stessi tutte le relazioni, vulnerabilità ecc.
che sono proprie dei componenti, dei servizi e dei
sottosistemi che li compongono.
In tal modo, anche gli Assets rientreranno nelle
catene di servizio e di disservizio del grafo che rappresenta il sistema sotto analisi.
Per chiarire il concetto, si prenda in considerazione il seguente esempio: un sistema X fornisce ad un
agente esterno un Servizio Informativo IS (e.g. una centrale elettrica che fornisce informazione in merito
all’energia prodotta ad una entità esterna). Questo
servizio è realizzato tramite l’utilizzo di una applicazione web (WAS) al livello di sottosistema. I dati
inviati all’agente esterno sono memorizzati in un
database, che fornisce un servizio di memorizzazione
(SS). Questi dati sono il risultato di una computazione basata sulle informazioni recuperate da sensori
106
remoti, che forniscono un servizio di Monitoring sul
campo (FMS). Il servizio di alto livello IS, è collegato
a WAS in modo funzionale. Inoltre esiste un flusso
informativo tra WAS, SS e FMS. In altre parole esiste un collegamento indiretto tra WAS ed SS e tra SS
e FMS. Questo insieme di collegamenti, che evidenziano come il fallimento di FMS possa avere un effetto 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 un
insieme Sn ={s1, ..., sn, desc} dove s1, ..., sn sono i servizi forniti da Sn e desc è la descrizione generale del
sistema stesso. Senza perdere generalità possiamo
descrivere un sottosistema ed un componente allo
stesso modo.
Definizione: Sia SoS={Sa, Sb, …, Sn} l’insieme
dei sistemi/sottosistemi/componenti in SoS, tali che
Serv sia l’insieme di tutti i servizi di SoS, allora una
dipendenza di servizio è una tupla sdr=<s, sid, inset,
outset, lf>, dove s è un servizio, sid è l’identificatore di
un sistema/sottosistema/componente Sa in SoS (che
produce il servizio), Inset dove Inset={<d, w> | d ∈
Serv, w ∈ ℵ} rappresenta la collezione dei servizi che
contribuiscono direttamente alla realizzazione del
servizio in questione, con associata una serie di pesi
(indicanti la loro rilevanza) w. lf rappresenta una
espressione logica del secondo ordine che consente
di mettere in evidenza, combinata con i pesi w
dell’Inset come e con quale rilevanza i suddetti servizi sono logicamente correlati con quello sotto analisi. In questo modo per esempio, è possibile rappresentare il fatto che un certo servizio A, per essere
fornito, necessita la combinazione dei servizi
(B∧C)∨D e che ognuno di questi servizi deve essere considerato come “fornito” ad A sino a quando le
sue performances non sono al di sotto il peso associato w (un po’ come nel caso della minima QoS
richiesta in certe applicazioni). Infine, Outset è la lista
di tutti i servizi ai quali il servizio in esame fornisce
direttamente un contributo.
Utilizzando queste definizioni, siamo quindi in
grado di costruire, partendo da un certo punto di inizio, (componente, sottosistema, ecc.) del sistema
sotto analisi, una catena di servizi.
Tale catena risulta quindi essere un grafo orientato che descrive le connessioni dirette ed indirette tra
i servizi di un componente/sottosistema e tutti gli
Speciale Sicurezza ICT
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE, DEFINIZIONI E METODOLOGIA.
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS METHODOLOGY)
altri servizi forniti da altri oggetti.
Da un punto di vista di analisi della sicurezza,
queste connessioni possono essere utilizzate per
identificare l’insieme delle “dipendenze dei servizi”.
Come definito da Masera, una “dipendenza di
sicurezza” esiste quando esiste una relazione tra due
sistemi(o sottosistemi o componenti) A e B, tale per
cui un errore interno in B, possa essere propagato
attraverso una catena di guasti, errori e fallimenti, al
sistema A. In tal caso, prendendo ispirazione da
Avizienis et al. [25], possiamo parlare di catene patologiche, ossia di catene che rappresentano il possibile
decorso patologico di una malattia (nel nostro caso,
il fallimento di parte del sistema sotto analisi).
Ragionando in termini di sicurezza informatica, possiamo dire che una catena patologica è causata da (a)
eventi accidentali dovuti a fallimenti interni o ad
errori umani o (b) attacchi intenzionali. Dato che
ogni componente della nostra descrizione di sistema
si porta, come corredo informativo, una lista delle
possibili vulnerabilità intrinseche e conosciute (ossia
la lista di vulnerabilità che, a priori, è possibile associare a tale componente con un certo livello di confidenza), è possibile espandere il concetto di catene
patologiche aggiungendo le informazioni relative a
tali vulnerabilità. In questo modo, le catene così
arricchite diventano quello che possiamo definire
Catene di V ulnerabilità (Figura 1).
Figura 1: Esempio di catene di vulnerabilità
Speciale Sicurezza ICT
L’introduzione di queste catene ha tre vantaggi:
1. Consente di identificare quali vulnerabilità di
basso livello (associate a qualche componente
di basso livello) possono avere un effetto su
servizi di alto livello (tipicamente servizi forniti dal sistema verso l’esterno) e sugli assets
del sistema stesso.
2. Consente di catturare tutto l’insieme non trascurabile di potenziali effetti collaterali delle
vulnerabilità identificate.
3. Costituisce la colla che unisce la descrizione
del sistema con le informazioni legate alla
sicurezza (vulnerabilità, minacce ed attacchi).
5. Analisi delle vulnerabilità
Attraverso l’adozione del paradigma di descrizione appena presentato, siamo ora in grado di mostrare come sia possibile identificare quali vulnerabilità
di basso livello possano avere un ruolo non trascurabile sulla sicurezza degli Assets del sistema sotto analisi.
Sostanzialmente l’approccio proposto è il seguente:
1. Per ogni asset vengono individuate tutte le
dipendenze (ricordiamo qui che un asset può
essere composto da componenti, sottosistemi
fisici e da servizi).
2. Per ogni elemento
appartenente all’asset,
vengono recuperati ed
enumerati i servizi che
esso fornisce.
3. Tramite l’esplorazione
delle relazioni che legano
i servizi dell’elemento
dell’asset sotto analisi,
vengono identificati tutti
i componenti di basso
livello che in qualche
modo contribuiscono a
rendere possibile il servizio di alto livello dell’asset.
4. Vengono quindi associate le vulnerabilità che
potenzialmente potrebbero affliggere il componente di basso livello, che
quindi vengono retro-
107
Igor Nai Fovino
propagate all’asset stesso.
quali asset, vulnerabili a causa di un insieme di debolezze identificate nella fase precedente, sono esposti
Applicando questa procedura siamo quindi in
a differenti tipi di minacce e quali sono le caratterigrado di identificare quali vulnerabilità, associate a
stiche che tali minacce dovrebbero esibire per essere
quali componenti, possono avere un impatto su un
considerate una sorgente potenziale di rischio.
asset. Questo tipo di conoscenza consentirà di deciNormalmente quando questo tipo di analisi è
dere, in fasi successive del processo di valutazione
applicata a sistemi relativamente piccoli, essa si esaudella sicurezza, se le politiche di sicurezza applicate
risce con l’assegnazione di minacce note a possibili
sono efficaci, di valutare possibili contromisure e di
assets, sulla base alcune, non ben definite, ipotesi
identificare scenari di attacco e di mitigazione.
fatte dall’analista.
Le vulnerabilità possono essere classificate, ovviaPurtroppo, questo approccio è ovviamente limitamente, a seconda della loro stimata rilevanza. Tale
to se si considerano grandi sistemi come ad esempio
classificazione viene utilizzata anche per identificare
impianti industriali.
un ordine di urgenza nell’applicazione delle controUtilizzando le informazioni derivate dalla fase
misure più idonee. In Figura 2 è mostrato l’algoritmo
precedente (analisi delle vulnerabilità), è possibile
di alto livello che implementa questa parte dell’analimigliorare questo processo.
si.
Una minaccia infatti è da considerarsi rilevante se
e solo se esiste una reale possibilità di realizzarla.
Input: the set of System Assets (SA)
Output: the set SA enriched with information related to the
Per dirla in parole povere, noi
vulnerabilities associated
possiamo ipotizzare una minaccia “Tsunami” per un ospedale,
Main
{
ma tale minaccia diventa realistiSelect Asset from SA
ca
se e solo se l’ospedale si trova
For each element i in Asset do
J=i
in prossimità del mare e non
If i is a service then J=service.ID
sulle
Alpi.
Inspect (J)
Allo
stesso modo, non ha
}
Function Inspect (J)
senso collegare minacce infor{
matiche
ad assets che, dall’analisi
If check_cycle(J)=false
precedente, risultano non impatthen
if J.vulnset ? ø then Asset.vulnset=Asset.vulnset+J.vulnset
tati da questo tipo di minacce.
for each service provided by J
In modo del tutto simile
{
sdr=retrieve s.sdr
all’approccio presentato nella
for each service in s.sdr.inset Inspect(s.sdr.inset.ID)
sezione precedente, un’analisi
}
delle minacce basata sul concetto
}
di servizio, si sviluppa nel
Figura 2: algoritmo di analisi delle vulnerabilità
seguente modo:
1.
Dall’insieme di tutti i possibili assets, solo il sottoinsieme di quelli affetti
6. Valutazione delle Minacce
da vulnerabilità (dirette o indirette) viene
preso in considerazione.
La determinazione di quali vulnerabilità possano
2. Per ogni elemento degli assets vulnerabili, il
impattare gli assets di un sistema non è ovviamente
sottoinsieme dei servizi coinvolti viene identisufficiente per considerare conclusa un’analisi di
ficato.
sicurezza.
3. Le minacce ipotizzate (ipotesi basate sull’idenA questo punto è infatti necessario analizzare
tificazione di minacce specifiche per scomparquali minacce possono utilizzare le vulnerabilità
ti industriali o sulla base di informazioni punidentificate per danneggiare il sistema. Questo è un
tuali relative alla compagnia proprietaria delpasso importante, che consente di identificare gli
l’impianto), vengono associate ai servizi di
obiettivi di attacco più probabili.
sottosistema individuati.
L’obiettivo di questa fase è quello di identificare
4. Tramite l’esplorazione delle dipendenze di ser-
108
Speciale Sicurezza ICT
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE, DEFINIZIONI E METODOLOGIA.
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS METHODOLOGY)
vizio e delle relazioni esistenti, viene verificato se le minacce possono propagare i loro
effetti sugli assets definiti vulnerabili.
In tal modo, non solo è possibile ottenere un
insieme più preciso, documentato e focalizzato di
servizi di sottosistema minacciabili, ma viene analiticamente dimostrato come queste minacce possono
affliggere questi servizi e quindi indirettamente i
relativi assets.
7. Analisi degli Scenari di attacco
Il processo di analisi degli attacchi consiste nell’identificazione dei potenziali attacchi che possono
essere realizzati con successo per portare a termine
le minacce in precedenza identificate. Questa parte
dell’analisi è estremamente importante, in quanto
consente di fornire indicazioni sulla reale robustezza
del sistema, sulla sua esposizione, e sulle possibili
contromisure 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 la
sua realizzazione. Purtroppo un albero d’attacco è
generalmente troppo astratto, nel senso che esprime
concetti come il seguente: “per realizzare l’attacco è
necessario avere la vulnerabilità x sul componente y
e la vulnerabilità z sul componente K”.
Tali informazioni sono di scarso aiuto nel processo di validazione perché il fatto che tali componenti esistano nel sistema non implica che essi siano
interconnessi o che siano dipendenti in un modo che
consenta la realizzazione dell’attacco stesso.
Un processo di validazione condotto senza questo tipo di informazioni aggiuntive produrrà certamente risultati poco utili e ricchi di falsi positivi.
Le informazioni ottenute dalla modellazione
orientata ai servizi, consentono di mitigare il rischio
di falsi positivi nel processo di validazione degli
attacchi.
Infatti, è possibile mappare gli alberi di attacco
sul sistema sotto analisi utilizzando come guida le
catene di dipendenza e di disservizio. Le relazioni tra
servizi contengono in modo intrinseco ciò che nel
gergo sistemistico è noto come “conoscenza locale”
e “diametro della rete”. In altre parole, utilizzando
questi tipi di conoscenza è possibile identificare se
esista qualche dipendenza e connessione tra componenti vulnerabili che sia di interesse a causa di qualSpeciale Sicurezza ICT
che minaccia sottesa. La validazione degli attacchi, da
una prospettiva orientata ai servizi, avviene quindi
come segue:
1. Gli attacchi che possono essere associati a
minacce precedentemente validate sono identificati e presentati come ipotesi da verificare.
2. Per ogni minaccia validata, i sottosistemi associati e le relative relazioni sono identificate.
3. Gli alberi di attacco associati alle minacce
selezionate sono validati tenendo in considerazione le informazioni derivate dalle catene
di disservizio, dalle relazioni di dipendenza e
da possibili asserzioni condizionali (i.e. asserzioni aggiuntive che esprimano ulteriori condizioni da soddisfare).
4. Gli attacchi validati sono utilizzati per stimare
l’impatto sugli assets, tenendo in considerazione gli effetti diretti ed indiretti (ricavabili,
ancora una volta, dall’analisi delle catene di
dipendenza e disservizio).
In questo modo è possibile ridurre lo spazio degli
attacchi da analizzare ai soli aventi effettivamente
possibilità di impattare sul sistema, diminuendo
notevolmente il numero di falsi positivi.
L’output dei passi precedentemente presentati
consente di mettere quindi in evidenza:
1. Le dipendenze che legano il sistema industriale sotto analisi.
2. Le vulnerabilità di basso livello che possono
impattare sul sistema e la loro catalogazione a
seconda della severità di impatto e della probabilità di occorrenza.
3. Gli asset che possono essere minacciati.
4. L’insieme degli attacchi che possono essere
con buona probabilità di successo realizzati
contro un certo insieme di assets.
Tali informazioni consentono di computare agilmente un calcolo del rischio al quale l’impianto è sottoposto, e di individuare agilmente le contromisure
più opportune.
8. Risultati Sperimentali
La metodologia presentata nelle sezioni precedenti è stata implementata all’interno di uno strumento software (InSAW-Industrial Security
Assessment Workbench) che ne consente l’utilizzo
immediato [26].
109
Igor Nai Fovino
Il cuore di tale software è un’articolata base di dati
relazionale in grado di contenere informazioni relative a tutti gli oggetti necessari per l’analisi, compreso
un set di librerie di vulnerabilità, alberi di attacco e
minacce collezionate nel corso di anni di test ed esperimenti.
Tale strumento è dotato di una mappatura ad
oggetti che consente di rappresentare graficamente
l’intera architettura dell’infrastruttura industriale analizzata, associandovi componenti e vulnerabilità in
modo automatico.
Una suite di algoritmi appositamente sviluppati
consente di retro-propagare le vulnerabilità sugli
assets, di mappare gli attacchi e di validarne la fattibilità. Tale strumento è stato sviluppato presso il
Centro di Ricerca della Commissione Europea di
Ispra [26].
La metodologia presentata nelle sezioni precedenti, è stata applicata con successo in diversi contesti. In particolare è stata utilizzata per valutare la sicurezza di sistemi di controllo industriale e di centrali
elettriche[27][28]. In questa sezione vengono presentati brevemente i risultati della sua applicazione nella
valutazione della sicurezza informatica di una centrale elettrica. I risultati sono volutamente descritti ad
alto livello, in quanto coperti da non-disclosureagreement.
Un impianto di generazione è un ambiente estremamente complesso, che coinvolge molti sistemi
diversi, sia da un punto di vista tecnico, che di requisiti che di politiche e gestione. In accordo con la
metodologia presentata l’impianto è stato analizzato
per identificare:
Assets, flussi informativi, componenti, sottosistemi, servizi
e dipendenze tra i differenti servizi.
I sottosistemi individuati sono stati i seguenti:
- Sottosistema di Campo: ospita i PLC/RTU di
controllo, gli attuatori ed i sensori della centrale elettrica.
- Sottosistema di controllo di processo e acquisizione
dati: è quello che in gergo tecnico viene chiamato sistema SCADA, e che ha in carico il
controllo dei processi di centrale.
- Rete di controllo: che interconnette tutti i sottosistemi di centrale.
- Rete Dati: che interconnette centrali diverse.
- Business network: che contiene tutti i sistemi utilizzati dagli operatori e tutte le funzioni così
dette “corporate”.
- Firewall: sistema che in realtà raggruppa tutti i
firewall e gli elementi di controllo sparsi all’in-
110
terno delle diverse reti, e che per comodità
sono stati raggruppati all’interno di un unico
sistema.
Il numero di componenti analizzati ed enumerati
durante l’analisi è stato nell’ordine delle tremila entità. Ad ognuno di questi componenti sono stati automaticamente associati gli insiemi di vulnerabilità che
potrebbero in ipotesi, affliggerli (tale operazione è
stata resa possibile grazie all’utilizzo di un database
appositamente realizzato per le vulnerabilità dei sistemi industriali).
A seguito di questa fase esplorativa, sono state
identificate le politiche operazionali e di sicurezza
applicate ad ogni componente e sistema identificato.
Sono stati inoltre identificati i requisiti operazionali
di processo e di funzionamento. Tali informazioni
sono state poi utilizzate in fase di analisi per identificare se e come certi profili di attacco potessero avere
senso, e per valutare l’impatto di eventuali contromisure.
Agli asset risultanti esposti a vulnerabilità di basso
livello (informazione derivata dall’analisi delle catene
di vulnerabilità e disservizio), sono state in seguito
associate ipotesi di minaccia basate sulla classificazione fornita dall’U.S. GAO [29].
In questo caso particolare sono stati considerati 5
particolari agenti di minaccia:
- Insiders: ossia dipendenti della stessa azienda
proprietaria dell’impianto.
- Crackers.
- Malware Interni.
- Malware Esterni.
- Gruppi organizzati: hacktivisti (ossia hacker che
sposano cause tipiche dei moderni attivisti),
crimine organizzato, ecc.
Seguendo tale approccio, sono state individuate
circa 1000 differenti vulnerabilità di un certo rilievo,
e tra queste, 156 aventi un impatto critico sul sistema
sotto analisi.
Tali vulnerabilità sono state classificate in accordo
con la loro probabilità di occorrenza e con la severità del loro impatto sull’infrastruttura.
Sulla base delle conoscenze accumulate, sono stati
identificati sette potenziali scenari di attacco complesso in grado di impattare sulla centrale in esame.
Come detto all’inizio di questa sezione, non è possibile riportare in questo lavoro i dettagli di tali scenari. Ciò che ha rilevanza è in ogni caso il fatto che
molti di questi scenari di attacco sfruttano una serie
Speciale Sicurezza ICT
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE, DEFINIZIONI E METODOLOGIA.
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS METHODOLOGY)
di effetti collaterali che, senza l’applicazione di una
metodologia di analisi basata sulla modellizzazione
dei servizi, sarebbe stato estremamente difficile scoprire.
9. Conclusioni
Centrali Elettriche, sistemi di controllo dei trasporti, reti elettriche, gasdotti, sono tutte infrastrutture necessarie per la vita di tutti i giorni, che, per le
loro peculiarità storiche sono sempre state viste
come modi completamente isolati, a se stanti, e per
questo avulse dai fenomeni di criminalità informatica che le cronache ci hanno abituato ad osservare in
altri campi.
Il senso di sicurezza derivato da questa supposta
estraneità di tali infrastrutture nei confronti delle
minacce informatiche, non ha motivo di esistere.
L’imperante diffusione delle tecnologie informatiche
nel mondo del controllo di processo industriale, la
diffusione dell’utilizzo delle classiche reti informatiche basate su TCP/IP per scambiare flussi di controllo, se da una parte ha reso possibili incredibili
passi avanti nella gestione coordinata di tali installazioni, dall’altra ha aperto le porte a nuovi, inimmaginabili scenari di fallimento, dovuti proprio alle vulnerabilità del mondo informatico.
La valutazione del livello di sicurezza informatica
delle infrastrutture critiche industriali è diventato,
alla luce di tutto ciò, di grande importanza.
La letteratura scientifica moderna, è ricca di
esempi di metodologie di valutazione della sicurezza
applicate a sistemi informatici tradizionali. Tali
metodologie purtroppo si sono rivelate poco adatte
ad analizzare realtà estremamente complesse, eterogenee e peculiari come quelle dei sistemi industriali.
In questo lavoro è stata fornita una panoramica di
una metodologia per la valutazione di sicurezza di
tali sistemi, sviluppata nei laboratori del Centro di
Ricerca della Commissione Europea e poi applicata
in diversi casi di studio.
Tale metodologia, si basa sul concetto di modellizzazione delle relazioni esistenti tra i vari componenti del sistema sotto analisi e nell’utilizzo della
conoscenza derivante da tale modellizzazione, al fine
di identificare e comprendere a pieno gli effetti collaterali di eventuali vulnerabilità identificate ed il loro
impatto su quelli che vengono comunemente definiti gli asset dell’infrastruttura.
L’adozione di tale metodologia non è ovviamente indolore, in quanto la quantità di informazioni da
gestire ed analizzare è ingente, ma, test sul campo
hanno dimostrato come la sua applicazione sia in
realtà fattibile e come i risultati ottenuti valgano il
costo dello sforzo intrapreso.
BIBLIOGRAFIA
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Stuxnet: http://www.symantec.com/connect/blogs/w32stuxnet-dossier
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.
G. Stoneburner, A. Goguen, A. Feringa. “Risk Management Guide for Information Technology
Systems”. Special publication 800-3, National institute of Standards and Technology.
Frank Swiderski and Window Snyder. “Threat Modeling”, Microsoft Press 2004
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.
“Microsoft Security Assessment Tool” https://www.securityguidance.com/
“Citicus ONE”. http://www.citicus.com
C. Alberts A. Dorofee “Managing Information Security Risks: The OCTAVE (SM) Approach”, July
2002, Addison Wesley Professional.
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.
Speciale Sicurezza ICT
111
Igor Nai Fovino
[10] Masera, M. & Nai Fovino, I., Models for security assessment and management. In proceeding of the
International Workshop on Complex Network and Infrastructure Protection, 2006.
[11] Masera, M. & Nai Fovino, I. (2006). Modelling Information Assets for Security Risk Assessment in
Industrial settings. 15th EICAR Annual Conference
[12] Nai Fovino, I. & Masera, M. (2006). “Emergent Disservices in Interdependent Systems and System-ofSystems”. 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-attacktrees-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-29
September 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 Quantitative
Perspective”. Lecture Notes in Computer Science, Volume 3654/2005. (2005) Publisher: Springer-Verlag
GmbH.
[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 applications 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 the
International 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 threats
to power substation control systems. International Journal of Critical Infrastructure, 2007
[29] Critical Infrastructure Protection, Challenges and Efforts to Secure Control Systems. United States
Government Accountability Office, 2004. GAO-04-628T.
112
Speciale Sicurezza ICT