Risk Assessment di ambienti applicativi: Servizi Web

Transcript

UNIVERSITÀ DI PISA
Facoltà di scienze matematiche fisiche e naturali
Dipartimento di Informatica
Risk Assessment di ambienti applicativi:
Servizi Web
Laurea Magistrale in Informatica
Lorenzo Isoni
Relatore Esterno: Lucio Machetti
Relatore Interno: Fabrizio Baiardi
Anno Accademico 2013/14
Sommario
Applicazioni e servizi web sono diventati lo strumento più popolare attraverso cui un
numero sempre crescente di organizzazioni decide di interfacciarsi con il mondo
esterno. La complessità delle applicazioni web più moderne, che integrano un numero
sempre più vasto di tecnologie a livelli di astrazione differenti, genera un insieme di
problemi relativi alla sicurezza che non può essere trascurato. I più recenti attacchi
informatici non si limitano alla ricerca di una singola vulnerabilità ed all’utilizzo della
stessa, ma cercano di concatenare delle sequenze più o meno complesse di attacchi che
permettano ad un attaccante di raggiungere un obbiettivo di suo interesse.
Questa tesi propone una soluzione per integrare le vulnerabilità di servizi web
nell’analisi del rischio di un sistema ICT. Dopo una analisi teorica del problema,
viene sviluppato un approccio che integra tali vulnerabilità con quelle dei livelli inferiori
e viene condotto uno studio di un sistema per la gestione di smart meters della
distribuzione di gas.
Ringraziamenti
Ai miei genitori,
Per il supporto e la fiducia che mi hanno dato in tutti questi anni.
A Roberta,
Per il sostegno e l’incoraggiamento, per avermi dato la forza di andare sempre avanti.
Al Prof. Baiardi,
A Federico, Alessandro e Roberto,
Per la pazienza, la disponibilità e l’aiuto durante la preparazione e la stesura della tesi.
Indice
1
Introduzione ....................................................................................... 8
1.1 Stato dell’arte ......................................................................................................... 9
1.2 Analisi del Rischio ................................................................................................. 12
1.2.1 Identificazione delle minacce e delle vulnerabilità ....................................... 13
1.2.2 Determinazione delle probabilità, dell’impatto e del rischio........................ 14
2
Strumenti per l’analisi di vulnerabilità ............................................... 15
2.1 Standard vulnerability scanner ............................................................................. 15
2.1.1 Nessus ............................................................................................................ 15
2.1.2 Classificazione di vulnerabilità standard: CVE ............................................... 19
2.2 Web vulnerability scanner .................................................................................... 21
2.2.1 Security AppScan ........................................................................................... 21
2.2.2 Owasp ZAP ..................................................................................................... 25
2.2.3 Classificazione di vulnerabilità non standard ................................................ 28
3
Haruspex ........................................................................................... 30
3.1 Definizioni base .................................................................................................... 30
3.2 Descrizione dello scenario .................................................................................... 32
3.3 Descrizione delle minacce .................................................................................... 34
3.4 Simulazioni ............................................................................................................ 36
3.5 Risultati ................................................................................................................. 37
3.6 Stato dell’arte ....................................................................................................... 39
4
Ambienti applicativi ........................................................................... 41
4.1 Modello ad ambienti ............................................................................................ 42
1
4.1.1 Classificazione di ambienti applicativi ........................................................... 43
4.2 Modello ad ambienti: servizi web ........................................................................ 44
4.2.1 Classe Web..................................................................................................... 44
4.2.2 Classe Database ............................................................................................. 46
4.3 Implementazione del modello web ...................................................................... 47
4.3.1 Web Builder ................................................................................................... 47
4.3.2 Ulteriori estensioni ad Haruspex ................................................................... 52
5
Caso di studio .................................................................................... 53
5.1 Generalità ............................................................................................................. 54
5.2 Architettura del Sistema ....................................................................................... 55
5.2.1 RepartoB ........................................................................................................ 56
5.2.2 RepartoA ........................................................................................................ 56
5.2.3 Rete SSM ........................................................................................................ 57
5.3 Assessment del sistema ........................................................................................ 59
5.3.1 Output dello standard assessment................................................................ 60
5.3.2 Assessment Haruspex .................................................................................... 62
5.4 Considerazioni finali ............................................................................................. 73
Bibliografia ............................................................................................... 75
2
Elenco delle figure
Figura 1.1 Vulnerabilità più diffuse secondo l’OSVDB ...................................................... 8
Figura 1.2 Confronto fra vulnerabilità web e vulnerabilità standard ............................... 9
Figura 1.3 Esempio di sequenza di attacchi ................................................................... 11
Figura 1.4 Metodologia OCTAVE .................................................................................... 12
Figura 2.1 Metriche CVSS ............................................................................................... 20
Figura 2.2 Schermata principale di AppScan .................................................................. 22
Figura 2.3 Flusso di esecuzione di una scansione AppScan ........................................... 24
Figura 2.4 Schermata principale di ZAP .......................................................................... 25
Figura 3.1 Esempio di curva di stress ............................................................................. 37
Figura 3.2 Curva di stress che confronta 3 sistemi differenti ......................................... 38
Figura 3.3 Descrizione modulare di Haruspex ................................................................ 39
Figura 4.1 Esempio di tipologie di relazione................................................................... 41
Figura 4.2 Esempio di modellazione ad ambienti .......................................................... 42
Figura 4.3 Modellazione di servizi web .......................................................................... 44
Figura 4.4 Modellazione Escape to OS ........................................................................... 45
Figura 4.5 Modellazione SQL Injection ........................................................................... 46
Figura 4.6 Web Builder ................................................................................................... 47
Figura 4.7 Esempio di alert generato da Owasp ZAP ..................................................... 48
Figura 4.8 Esempio di descrizione WASC ....................................................................... 49
Figura 4.9 Scope CAPEC .................................................................................................. 50
Figura 4.10 Valori d'impatto CAPEC ............................................................................... 51
Figura 5.1 Panoramica delle reti RepartoA e RepartoB ................................................. 55
Figura 5.2 Rete SSM, su Cloud Provider ......................................................................... 57
3
Figura 5.3 Resoconto vulnerabilità Nessus..................................................................... 60
Figura 5.4 Impatto vulnerabilità Nessus ......................................................................... 60
Figura 5.5 Resoconto vulnerabilità Owasp ZAP .............................................................. 61
Figura 5.6 Impatto vulnerabilità Owasp Zap .................................................................. 61
Figura 5.7 Curva di stress della Minaccia 1 .................................................................... 65
Figura 5.8 Curve di stress della Minaccia 2 .................................................................... 66
Figura 5.9 Curve di stress della Minaccia 3 .................................................................... 68
Figura 5.10 Curve di stress della Minaccia 4 .................................................................. 69
Figura 5.13 Confronto fra le strategie migliori ............................................................... 72
4
Elenco delle tabelle
Tabella 3.1 Acronimi Haruspex ....................................................................................... 32
Tabella 5.1 Reti analizzate con Nessus ........................................................................... 59
Tabella 5.2 Riepilogo delle minacce simulate ................................................................ 63
Tabella 5.3 Report Minaccia 1 ........................................................................................ 65
Tabella 5.4 Report minaccia 3 ........................................................................................ 66
Tabella 5.9 Risultati con integrazione Web .................................................................... 73
Tabella 5.10 Riepilogo simulazioni web totale ............................................................... 74
5
Organizzazione della tesi
Capitolo 1: Introduzione
Questo capitolo introduce la problematica affrontata nella tesi, ovvero la necessità di
integrare le vulnerabilità web nella valutazione del rischio di un sistema ICT.
Il capitolo presenta inoltre alcuni richiami e definizioni base relative all’analisi del rischio.
Capitolo 2: Strumenti per l’analisi di vulnerabilità
Questo capitolo presenta alcuni vulnerability scanner, strumenti automatizzati per
l’analisi di vulnerabilità standard e non. Vengono inoltre presentati gli standard di
riferimento adottati dagli strumenti per la classificazione delle vulnerabilità.
Capitolo 3: Haruspex
Questo capitolo presenta Haruspex, un insieme di strumenti software il cui scopo è
quello di valutare e gestire il rischio di un sistema ICT. A partire dalla descrizione di uno
scenario, Haruspex simula il comportamento di un attaccante che cerca di raggiungere i
suoi obiettivi mediante la composizione di una sequenza di attacchi.
Capitolo 4: Ambienti applicativi
Questo capitolo presenta l’estensione apportata ad Haruspex per modellare gli ambienti
applicativi. Nella prima parte si descrive il modello teorico, nella seconda parte si
descrive come questo sia stato istanziato per modellare gli ambienti web.
Capitolo 5: Caso di studio
Questo capitolo descrive il caso di studio svolto in collaborazione con Terranova
Software. Nella prima parte viene descritto il sistema target dell’assessment. Nella
seconda parte viene descritta la modellazione realizzata con Haruspex, e vengono
presentati i risultati ottenuti tenendo conto dell’estensione web introdotta nel 4°
capitolo.
6
7
1 INTRODUZIONE
A partire dagli anni ‘90 applicazioni e servizi web sono diventati lo strumento più
popolare attraverso cui un numero sempre crescente di aziende ed organizzazioni ha
deciso di interfacciarsi con il mondo esterno. Dai più semplici servizi di e-commerce, che
consentono di effettuare comodamente acquisti online, alle università che offrono ai
propri studenti la possibilità di iscriversi agli esami, o alle aziende che offrono servizi di
consulenza e supporto, i servizi web rappresentano oggigiorno una delle tecnologie
maggiormente affermate ed impiegate nella rete Internet.
La complessità delle applicazioni web più moderne, che integrano un numero sempre
più vasto di tecnologie a livelli di astrazione differenti, genera un insieme di problemi
relativi alla sicurezza che non può essere trascurato.
A testimoniare un sempre crescente interesse verso i servizi web anche da parte degli
attaccanti vi sono un importante numero di studi recenti, ad esempio [1], che mostrano
come la maggior parte delle vulnerabilità che affliggono i sistemi informatici siano
oggigiorno relative alle tecnologie web.
Figura 1.1 Vulnerabilità più diffuse secondo l’OSVDB
Il grafico della figura 1.1, estratto dal Cyber Risk Report [1], mostra come ben 4 sulle 6
più diffuse vulnerabilità (cross-site scripting, cross-site request forgery, remote file
inclusion, SQL injection) riguardino esclusivamente i servizi web.
8
In accordo con l’Open Source Vulnerability DataBase (OSVDB) le sole vulnerabilità lato
web rappresentano ad esempio il 40% di tutte le vulnerabilità scoperte e riportate nel
2012.
Figura 1.2 Confronto fra vulnerabilità web e vulnerabilità standard
1.1 Stato dell’arte
Nel corso degli anni sono nate diverse organizzazioni quali Open Web Application
Security Project (OWASP) e Web Application Security Consortium (WASC), per offrire un
punto di riferimento per la comprensione dei problemi di sicurezza inerenti ai servizi
web.
I siti gestiti da queste organizzazioni permettono di accedere ad una notevole quantità
di informazioni sulle più diffuse vulnerabilità, i principali attacchi che consentono di
sfruttarle e quali sono le contromisure che dovrebbero essere adottate per limitarli.
Esistono inoltre guide alla prevenzione dei problemi di sicurezza, con l’ambizioso
obiettivo di istruire i programmatori ad acquisire uno stile di programmazione più sicuro.
Alcune di queste organizzazioni, in particolare WASC, cercano di definire anche uno
standard di riferimento per la classificazione delle vulnerabilità.
9
Informazioni come le precedenti rappresentano un essenziale punto di partenza per la
gestione della sicurezza lato web. E’ tuttavia importante essere consapevoli della
necessità di una ulteriore elaborazione di questi dati nel momento in cui si desidera
considerare il web come una componente integrante di un sistema informatico.
Cerchiamo di comprenderne al meglio le ragioni attraverso un esempio.
1.1.1 Esempio
Consideriamo un’azienda che fornisca un certo servizio e che abbia integrato nella
propria rete aziendale un servizio web, accessibile attraverso internet, a cui i clienti
possono collegarsi per monitorare i costi loro addebitati.
Se il sito è affetto da una vulnerabilità che consente di bypassare l’autenticazione (1°
attacco), un exploit ad essa associato garantirebbe ad un agente esterno l’accesso a dei
contenuti altrimenti irraggiungibili. Consideriamo come esempio un caso relativamente
semplice di una form HTML, che permette all’utente di inserire una data relativa al
periodo dei consumi di suo interesse. Le informazioni inserite in questo campo vengono
utilizzate dal Web Server per generare un’istruzione SQL.
L’assenza di opportuni controlli sui valori trasmessi in ingresso può consentire
all’attaccante di trasmettere dati inattesi e realizzare una SQL Injection (2° attacco), che
gli può permettere di accedere a tutte le informazioni memorizzate sul Database.
Consideriamo un ulteriore passo da parte dell’attaccante, che dopo aver guadagnato
l’accesso alla base di dati può scoprire e sfruttare una vulnerabilità che gli consente di
eseguire del codice a livello del sistema operativo (3° attacco).
Considerando che il database potrebbe trovarsi anche su una macchina fisicamente
differente dal servizio web, in questo modo l’attaccante è stato in grado di
compromettere più nodi del sistema guadagnandone il totale controllo.
L’esempio discusso mostra come sfruttando una sequenza di due vulnerabilità relative
al servizio web, in composizione con una terza dipendente dall’ambiente applicativo, un
attaccante esterno possa realizzare una escalation dei propri privilegi tale da consentire
l’accesso nell’infrastruttura ICT. I privilegi ottenuti possono inoltre essere visti non solo
10
come punti di arrivo ma anche come un nuovo punto di partenza che permette di
eseguire nuove sequenze di attacchi.
1° attacco
3° attacco
2° attacco
Figura 1.3 Esempio di sequenza di attacchi
L’esempio illustrato descrive uno scenario estremamente realistico: i più recenti attacchi
informatici non si limitano alla ricerca di una singola vulnerabilità ed all’utilizzo della
stessa, ma cercano di concatenare delle sequenze più o meno complesse di attacchi che
permettano ad un attaccante di raggiungere un obbiettivo di suo interesse.
Questo esempio evidenzia la necessità di integrare la classificazione delle vulnerabilità
di un servizio web con le vulnerabilità di un’intera infrastruttura informatica. E’ solo
attraverso una loro correlazione, infatti, che diventa possibile descrivere con
un’adeguata accuratezza uno scenario che modelli la realtà di un attuale sistema ICT.
In particolar modo diventa essenziale la capacità di modellare attaccanti intelligenti, in
grado di spostarsi da un ambiente applicativo ad un altro in base agli obiettivi che
vogliono raggiungere.
11
1.2 Analisi del Rischio
L’analisi e la gestione del rischio sono parte integrante dell’attività umana;
l’intraprendere un’attività commerciale, guidare una macchina, attraversare la strada
nel bel mezzo di una via trafficata, sono tutte attività che comprendono l’analisi e la
valutazione del rischio, ovvero l’eventualità di subire un danno a causa di circostanze più
o meno prevedibili. Il processo di analisi del rischio per un sistema ICT ha il compito di
individuare le vulnerabilità presenti e di proporre delle contromisure per limitarne gli
effetti.
Il termine sistema comprende un insieme eterogeneo di elementi: può riguardare un
impianto, un processo produttivo, un servizio; da questa definizione risulta chiaro come
l’analisi del rischio non sia legata al solo settore informatico, bensì costituisca un’attività
trasversale a tutti i settori.
Figura 1.4 Metodologia OCTAVE
La figura 1.4 descrive graficamente il processo ciclico che caratterizza la gestione del
rischio, così come è definito secondo la metodologia OCTAVE (Operationally Critical
Threat, Asset, and Vulnerability Evaluation) [2]: dopo una fase preliminare di analisi, si
passa ad una fase di implementazione ed in seguito al controllo delle misure di sicurezza.
Il processo di analisi del rischio può essere suddiviso in una sequenza di passi:
12
1. Identificazione degli asset
2. Identificazione delle minacce
3. Identificazione delle vulnerabilità
4. Determinazione delle probabilità degli eventi associati alle minacce
5. Analisi degli impatti
6. Determinazione del rischio.
Nei paragrafi successivi saranno discusse in maggiore dettaglio le singole fasi.
1.2.1 Identificazione delle minacce e delle vulnerabilità
Nella fase preliminare è fondamentale analizzare l'intera infrastruttura: l’hardware, il
software, la topologia della rete, i dati trattati, fino ad arrivare alla sicurezza fisica ed alle
persone che gestiscono e s’interfacciano con il sistema. Tutte le informazioni ricavate
sono fondamentali per:

Identificazione degli asset: con asset si definisce tutto ciò che ha valore o
rappresenta utilità per l’azienda, e deve essere dunque protetto. Descrive quelle
componenti che, se attaccate con successo, generano una perdita. Si può parlare
sia di risorse fisiche (ad esempio la potenza di computazione o la banda di rete)
che logiche (ad esempio servizi o applicazioni). Stabilire il valore di una risorsa è
un’attività non banale; un possibile approccio potrebbe essere quello di
considerare il costo di ricostruzione qualora una risorsa venga compromessa.

Identificazione delle minacce: deve individuare un insieme di eventi in grado di
causare un danno all’azienda. Esempi possibili sono la perdita di dati sensibili,
l’alterazione od il blocco dei servizi. Per ogni minaccia è importante identificare
il punto di origine, i prerequisiti di cui ha bisogno in termini di diritti e risorse, le
azioni che deve eseguire per raggiungere i propri obiettivi e le conseguenze in
caso di successo;

Identificazione delle vulnerabilità: una vulnerabilità rappresenta un difetto nella
progettazione, nell’ implementazione di un componente o nei controlli di
sicurezza del sistema che può essere sfruttata, intenzionalmente o meno, da una
minaccia per violare il sistema. L'output di questa fase è l’elenco delle
13
vulnerabilità dei componenti del sistema, delle minacce che potrebbero
utilizzarle e delle azioni necessarie per sfruttare la vulnerabilità.
1.2.2 Determinazione delle probabilità, dell’impatto e del rischio
La determinazione del rischio considera due parametri fondamentali:

L’impatto generato da un evento negativo;

La probabilità che l’evento occorra.
Una stima dell’impatto può essere ottenuta mediante una valutazione della perdita in
termini di integrità (la risorsa colpita è stata alterata o distrutta), di confidenzialità (la
risorsa diventa nota all’attaccante) e di disponibilità (l’accesso alla risorsa viene negato).
Lo standard ISO27001 ad esempio associa una scala di valori low, medium ed high a
ciascuno dei parametri; la somma di questi parametri fornisce il valore dell’asset.
La valutazione della probabilità deve tener conto di diversi fattori, quali ad esempio le
capacità e le motivazioni dell’attaccante, la natura della vulnerabilità e le contromisure
adottate per proteggere il sistema. Il valore della probabilità può essere stabilito
secondo una scala di riferimento: il modello NIST [3] stabilisce ad esempio i valori low,
medium e high.
14
2 STRUMENTI PER L’ANALISI DI
VULNERABILITA
Questo capitolo presenta alcuni dei più noti vulnerability scanner, ovvero strumenti per
automatizzare la scoperta delle vulnerabilità di un sistema.
2.1 Standard vulnerability scanner
2.1.1 Nessus
Nessus è un security scanner nato nel 1998 e sviluppato da Teenable Network Security.
In origine era distribuito come software libero attraverso la licenza GNU (General Public
License), ma a partire dal 2005 è diventato software proprietario e viene distribuito
attraverso due licenze:

Gratuita, limitata al solo utilizzo privato e senza alcun supporto tecnico. E’
possibile scansionare un numero limitato di host servendosi di un numero
limitato di plugin;

A pagamento, attraverso sottoscrizione annuale, priva di limitazioni di sorta.
2.1.1.1 Come funziona
Nessus effettua l’analisi di un sistema da remoto grazie all’utilizzo dei plugin, programmi
di dimensione ridotta il cui compito è quello di rilevare un insieme noto di vulnerabilità.
I plugin sono scritti in NASL (Nessus Attack Scripting Language), un linguaggio di scripting
specializzato per le comunicazioni su una rete TCP/IP ed in grado di compiere attacchi a
diversi livelli della pila ISO/OSI.
L’analisi effettuata da Nessus è formata da una sequenza di passi:
15
1. Verifica degli host attivi sulla rete, nel caso in cui non venga fornita una lista di
indirizzi IP da analizzare;
2. Esecuzione di un port scanning completo per ogni host attivo;
3. Esecuzione dei plugin selezionati nella fase di configurazione dall’utente;
4. Generazione di un report, esportabile, che descrive nel dettaglio ogni
vulnerabilità rilevata.
2.1.1.2 Architettura
Nessus adotta un’architettura client-server. Il client si presenta come un’interfaccia
web, utilizzabile dall’utente per configurare la scansione e visualizzare i risultati. Il server
è composto invece da:

Un interprete NASL, che traduce i plugin in istruzioni per l’engine;

L’engine, che riceve le istruzioni dall’interprete ed esegue la scansione vera e
propria;

Un knowledge base, un componente che memorizza e condivide le informazioni
rilevate dai vari plugin. Memorizza indicazioni quali il tipo di servizio identificato,
la porta su cui è in ascolto, lo stato di funzionamento etc.
2.1.1.3 Configurazione della scansione
Nessus consente all’utente di configurare la politica di scansione specificando un
insieme di parametri. La configurazione è ottenuta in base ad un insieme di scelte per
raggiungere un compromesso tra rischi e benefici. Poiché Nessus esegue una serie di
operazioni indistinguibili da un attacco reale, i rischi da considerare sono, ad esempio, il
blocco dei servizi di rete o degli host, l’alterazione dei percorsi di rete o la stampa
incontrollata di dati casuali.
Queste motivazioni possono portare ad escludere una tipologia di servizi o un gruppo di
host dalla scansione. La scelta di escludere parte del sistema può essere influenzata
anche dalla necessità di ridurre il tempo per realizzare la scansione.
Questo compromesso non riguarda solo la scelta degli host da includere nella scansione,
ma anche quella dei plugin da eseguire e la loro modalità di esecuzione. Infatti, tale
16
modalità può essere prudente, safe mode, o aggressiva. La modalità di esecuzione
determina quali istruzioni possono essere eseguite in un plugin.
Un attacco aggressivo invia una o più richieste all’host, anche malformate, per analizzare
le risposte ricevute e capire se è vulnerabile. Un attacco safe mode, invece, si limita ad
una semplice interpretazione delle informazioni recuperate dai messaggi di
presentazione ottenuti durante una connessione ad un servizio di rete.
Altri parametri interessanti consentono la memorizzazione di credenziali di accesso a
diversi servizi quali Samba, o i database. E’ possibile inoltre bilanciare l’utilizzo delle
risorse, definendo ad esempio il numero di thread da istanziare od il numero di richieste
da inviare in caso di fallimento.
2.1.1.4 I plugin
Nessus mette a disposizione più di 60000 plugin diversi, che l’utente seleziona nella fase
di configurazione della scansione a seconda delle esigenze. Poiché i plugin possono
condividere informazioni attraverso il knowledge base, la loro esecuzione viene regolata
da 2 vincoli:

Per garantire la consistenza occorre che i plugin siano eseguiti nell’ordine in cui
accedono al knowledge base. Deve essere rispettata la regola per cui ogni plugin
che fa uso di un’informazione condivisa deve essere eseguito dopo il plugin che
fornisce tale informazione;

Non si deve verificare un’interferenza tra i vari plugin. Questo vincolo è
soddisfatto quando, per ogni host e per ogni servizio, vengono eseguiti
inizialmente quei plugin che implementano attacchi che non causano
malfunzionamenti e, solo successivamente, tutti gli altri in ordine di aggressività
crescente. Questo comportamento cerca di evitare interferenze tra diversi
attacchi, ad esempio un plugin che potrebbe causare il riavvio di un host non
deve essere eseguito prima di tutti quegli attacchi che, pur interagendo con
l’host, non ne alterano lo stato.
L’esecuzione di ogni plugin prevede i seguenti passi:
17
1. Controlla che tutti i plugin da cui dipende siano già stati eseguiti;
2. Controlla se i servizi che deve analizzare sono attivi sull’host;
3. Se non vengono trovati servizi attivi, il plugin può procedere con l’esecuzione
utilizzando impostazioni di default o può terminare la propria esecuzione;
4. Analisi delle risposte raccolte da un precedente port scan e del loro contenuto
per determinare se vi siano vulnerabilità riconoscibili. Questa fase può utilizzare,
ad esempio, il nome e la versione del software che fornisce il servizio;
5. Se consentito dalla configurazione safe mode, verifica dell’esistenza della
vulnerabilità. Tipicamente vengono inviate delle richieste appositamente
generate ed analizzate le risposte ricevute. In base alle risposte si determina se
la vulnerabilità esiste;
6. Assegna all’eventuale vulnerabilità scoperta un valore che ne determina il livello
di rischio. Tale valore è deciso dall’autore del plugin.
E’ possibile che un plugin generi informazioni parzialmente corrette o incomplete.
Questo può trarre in inganno l’utente generando falsi positivi o anche falsi negativi.
Alcuni esempi:

Backporting: si verifica quando un servizio non modifica la propria risposta in
seguito all’applicazione di un aggiornamento che corregge una vulnerabilità. In
questo caso il knowledge base contiene un’informazione non aggiornata e
favorisce il verificarsi di falsi positivi, soprattutto in caso di scansione non
invasiva;

Ricerca di malware: l’analisi condotta per rilevare un cavallo di troia potrebbe
segnalare l’apertura della porta ad esso associata anche se il servizio in ascolto
sulla porta è legittimo. In questo caso il plugin potrebbe segnalare la presenza di
un software sospetto in ascolto che in realtà non esiste. Ancora un volta è una
situazione che potrebbe verificarsi in caso di scansione non invasiva.
18
2.1.1.5 Risultati della scansione
Al termine della scansione è possibile visualizzare i risultati attraverso l’interfaccia del
client, oppure esportando dei report.
Per comprendere correttamente l’output è necessario conoscere le definizioni di
vulnerabilità, di rischio e capire la logica adottata da Nessus nel valutare la loro presenza.
Una vulnerabilità in una rete TCP/IP può essere dovuta ad un errore di programmazione,
configurazione o amministrazione che abilita attacchi contro il sistema. Le proprietà
critiche per la sicurezza di un sistema sono la confidenzialità, l’integrità e la disponibilità.
Un report di Nessus contiene una lista delle vulnerabilità, ma uno strumento
automatizzato come Nessus non è in grado di valutare correttamente se una
vulnerabilità che è presente su un host possa mettere a rischio anche gli altri host
presenti nella rete. In altre parole, non è in grado di valutare quali attacchi complessi
sono abilitati da vulnerabilità nei singoli nodi.
2.1.2 Classificazione di vulnerabilità standard: CVE
Il CVE (Common Vulnerabilities and Exposures) [4] è un database pubblico di
vulnerabilità note. Si tratta di uno standard emergente utilizzato da diverse
organizzazioni nell’ambito della sicurezza informatica.
Ogni vulnerabilità CVE è associata ad uno score CVSS (Common Vulnerability Scoring
System) [5], descritto da 3 tipi di metriche:

Base: rappresenta le caratteristiche di una vulnerabilità che sono costanti nel
tempo ed indipendenti dal contesto in cui si trovano. Informazioni di questo tipo
sono ad esempio l’impatto generato dalla vulnerabilità in termini di
confidenzialità, integrità e disponibilità.

Temporal: rappresenta le caratteristiche di una vulnerabilità che cambiano nel
tempo, come ad esempio la possibilità di sfruttare la vulnerabilità mediante un
exploit pubblico, oppure la presenza di una patch in grado di risolvere la
vulnerabilità.
19

Environmental: rappresenta le caratteristiche di una vulnerabilità che sono
rilevanti rispetto al contesto utente in cui vengono considerate. Informazioni di
questo tipo comprendono l’impatto collaterale che la vulnerabilità genera se
sfruttata da un attaccante, come ad esempio una perdita finanziaria.
Figura 2.1 Metriche CVSS
I vulnerability scanner standard quali Nessus associano a ciascuna vulnerabilità scoperta,
se disponibile, un identificativo CVE di riferimento al database pubblico.
20
2.2 Web vulnerability scanner
I web vulnerability scanner sono software specializzati nell’analisi di siti ed applicazioni
web. Esiste un numero molto elevato di scanner web, sia gratuiti che open source. Nel
seguito saranno presentati due di essi: AppScan e ZAP.
2.2.1 Security AppScan
AppScan è uno strumento proprietario sviluppato da IBM che automatizza la ricerca di
vulnerabilità note, quali Cross-site Scripting e SQL Injection, di siti ed applicazioni web.
Attualmente vengono commercializzate diverse versioni del software, ognuna delle
quali richiede una licenza a pagamento:

AppScan Standard Edition: rappresenta la versione base del prodotto. Consente
di effettuare un’analisi di tipo glass box, che combina l’analisi dinamica del black
box con l’analisi statica del white box. Per effettuare quest’ultima è necessario
installare un agente lato server;

AppScan Enterprise Edition: versione client-server del prodotto, per favorire la
scalabilità dei test e delle scansioni;

AppScan Source Edition: versione specializzata nell’analisi white box, assiste
durante le fasi di sviluppo degli applicativi web, intervenendo prima della loro
pubblicazione.
Esistono inoltre ulteriori versioni del prodotto, relative ad esempio ad applicativi di tipo
mobile. E’ possibile ottenere una versione di prova illimitata della versione standard,
con la quale è tuttavia possibile scansionare un solo sito web predefinito e non
modificabile.
La scansione effettuata da AppScan è divisa in due passi principali, chiamati stage:

Explore stage: AppScan esplora il sito web simulando il comportamento di un
utente, cliccando sui link presenti nelle pagine, completando i campi delle form.
21
Per ogni richiesta inviata nel corso della navigazione analizza la risposta ottenuta,
generando automaticamente dei test qualora rilevi la possibile presenza di una
vulnerabilità. In questa fase vengono inviate numerose richieste sia malformate
che legittime. Il risultato prodotto da questa fase è un albero che descrive
l’organizzazione di file e cartelle del sito web, associato all’insieme di test da
eseguire.

Test stage: tutti i test generati nella fase di esplorazione vengono eseguiti. Ad
ogni vulnerabilità rilevata vengono associate delle informazioni, quale il livello
del rischio, una descrizione ed i riferimenti alle componenti affette.
La fase di esplorazione e testing definiscono insieme una fase. Poiché l’esecuzione di un
test può permettere di scoprire componenti da analizzare, AppScan esegue un numero
prefissato di 4 fasi, in cui ripete ogni volta sia la fase di esplorazione che la fase di testing.
Se al termine di una singola fase lo scanner non ha potuto scoprire nuove componenti
da analizzare, la scansione viene arrestata. Nella configurazione dello scanning è
possibile modificare il numero massimo di fasi che devono essere eseguite.
Figura 2.2 Schermata principale di AppScan
22
La fase di esplorazione del sito web può essere effettuata anche manualmente,
attraverso l’utilizzo di un browser opportunamente configurato.
AppScan mette a disposizione dell’utente dei template, ovvero configurazioni
predefinite che possono essere selezionate per le scansioni. E’ possibile creare dei
template nuovi o personalizzare quelli già esistenti.
Alcune informazioni che è possibile inserire o manipolare sono le seguenti:

Explore stage
o URL del sito web da analizzare, o file WSDL nel caso di servizio web;
o Credenziali per l’accesso, metodo di autenticazione;
o Eventuali domini esterni da considerare;
o Url e percorsi da ignorare;
o Definizione dell’ambiente, come ad esempio il tipo di server web
(apache, asp.net) o di database (MYSQL, SQL Server);

Test Stage
o Severità dei test (livello basso, medio o alto), a seconda che si voglia
adottare un approccio più o meno aggressivo;
o Numero di test da effettuare, priorità di esecuzione;
o Tipologia di test da effettuare;

Numero massimo di fasi per la scansione.
Al termine della configurazione AppScan esegue un’utility nominata “Scan Expert”, che
valuta la configurazione generata e suggerisce eventuali modifiche per migliorare le
performance di esecuzione della scansione.
Al termine della scansione AppScan visualizza un elenco delle vulnerabilità web
riscontrate. Per ciascuna di essa riporta informazioni quali la tipologia, una descrizione
23
della problematica, l’impatto da essa generato, il componente che ne è affetto ed
eventuali riferimenti a classificazioni quali WASC[6] o CWE[7].
Per ciascuna vulnerabilità vengono inoltre proposte contromisure ed eventuali rimedi.
I risultati possono essere esportati in diversi formati quali pdf, xml o html. E’ inoltre
possibile generare report che rispettano determinati standard di settore, come ad
esempio l’ISO 27002 [8] o NIST 800-53 [9].
Figura 2.3 Flusso di esecuzione di una scansione AppScan
24
2.2.2 Owasp ZAP
Zed Attack Proxy (ZAP) è un web vulnerability scanner open source rilasciato nel 2010
da OWASP. Il software è sviluppato principalmente nel linguaggio Java, è gratuito e
multipiattaforma. E’ disponibile per sistemi operativi Windows, Linux e Mac OS. Viene
presentato anche come strumento per il penetration testing di siti ed applicazioni web.
La distribuzione open source del software rende ZAP uno scanner estendibile: è
integrato infatti nell’applicazione un marketplace dove è possibile scaricare degli addon, ovvero componenti applicativi pubblicati da sviluppatori per aggiungere funzionalità
allo scanner. E’ possibile ad esempio arricchire i dizionari utilizzati per effettuare attacchi
di brute force, oppure facilitare l’interazione dello scanner con programmi sviluppati da
terzi, rendendo esportabili i parametri od i risultati prodotti dallo scanner.
Figura 2.4 Schermata principale di ZAP
25
La scansione condotta da ZAP è composta da due passi principali:

Spidering, dove lo scanner esplora l’intero sito web a partire da un url di
riferimento. La fase di spidering può essere eseguita manualmente dall’utente
attraverso un browser oppure automatizzata. Nel secondo caso lo scanner segue
tutti i link presenti nelle pagine web che riesce a raggiungere. I risultati prodotti
dalla fase di spidering possono essere arricchiti avviando uno spider AJAX,
presente di default nell’applicazione: si tratta di un add-on che consente di
effettuare il crawling di pagine dinamiche che fanno utilizzo di AJAX
(Asynchronous JavaScript And Xml) per la generazione delle richieste.

Active Scanning, dove ZAP sfrutta le informazioni raccolte nella fase di spidering
per attaccare il sito web alla ricerca di vulnerabilità note come ad esempio Path
Traversal o Code Injection. La rilevazione avviene attraverso l’esecuzione di
attacchi veri e propri.
E’ possibile configurare ZAP in modo che esegua uno scanning di tipo passivo,
privo cioè di attacchi diretti verso il sito web. Questo scanning deduce la
presenza di vulnerabilità analizzando lo scambio di messaggi che avviene fra il
browser ed il sito web.
E’ possibile inoltre specificare dei breakpoints, ovvero punti di arresto nella
comunicazione tra lo scanner ed il sito web, per dar modo all’utente di analizzare
e modificare manualmente il contenuto dei messaggi inviati da ZAP prima che
questi vengano inoltrati.
Ad ogni scansione ZAP associa la definizione di contesto, che definisce l’insieme
delle URL che fanno parte dell’applicazione web che si intende analizzare.
E’ possibile associare una configurazione differente ad ogni contesto, ed è
possibile associare più di un contesto allo stesso applicativo web.
26
In ZAP è possibile definire due configurazioni diverse: una relativa allo scanner ed una
relativa al contesto.
La configurazione del contesto consente di specificare:

Le credenziali di accesso degli utenti (username e password);

Il tipo di autenticazione da implementare (HTTP authentication, form based
authentication);

Eventuali domini esterni da considerare o ignorare nella fase di spidering.
La possibilità di associare delle credenziali ad un contesto consente di effettuare
scansioni del sito web secondo la prospettiva di utenti differenti.
E’ possibile ad esempio specificare per lo stesso contesto credenziali appartenenti ad un
utente di tipo amministratore e ad un utente di tipo “guest”. Ciò permette di indicare
allo scanner di analizzare il sito web in accordo con quelle che sono le risorse accessibili
dall’utente specificato.
La configurazione dello scanner comprende invece informazioni di carattere più
generale, quali ad esempio:

Il tipo di elementi su cui condurre attacchi che prevedono iniezione di codice
(parametri presenti nell’URL, header HTTP, attributi xml etc);

Selezione degli add-on da utilizzare;

Numero massimo di link da seguire nella fase di spidering;

Numero di thread massimo da utilizzare nell’esecuzione della scansione;

Livello di aggressività da considerare per gli attacchi condotti durante fase di
active scan.
Al termine dalla scansione ZAP genera degli alert, ovvero degli avvisi che associano ad
ogni vulnerabilità scoperta delle informazioni in grado di classificarla.
Per ciascuna vulnerabilità vengono riportati il tipo di attacco che è stato identificato, in
che modo è stato testato, la URL di riferimento, la gravità della vulnerabilità, una
27
descrizione del problema, una possibile soluzione e gli identificativi di riferimento per la
classificazione WASC e CWE.
E’ possibile esportare i risultati della scansione in un report, sotto forma di file HTML o
XML.
2.2.3 Classificazione di vulnerabilità non standard
Le vulnerabilità scoperte da uno scanner web appartengono alla categoria delle
vulnerabilità non standard, ovvero vulnerabilità per le quali non esiste un database di
riferimento, come il CVE, a cui potersi ricondurre per una loro classificazione.
In rete esistono tuttavia diversi progetti indipendenti, quali WASC e CAPEC, che hanno
come obiettivo la definizione di uno standard di riferimento per la classificazione delle
vulnerabilità e degli attacchi web.
2.2.3.1 WASC Threat Classification
Il WASC Threat Classification [6] è un progetto sviluppato dal gruppo WASC (Web
Application Security Consortium) per promuovere una terminologia standard con cui
classificare le vulnerabilità e gli attacchi web.
Il progetto definisce un totale di 49 classi mediante cui vengono descritte le vulnerabilità
e gli attacchi web. Per ciascuna classe, WASC fornisce le seguenti informazioni:

Una descrizione testuale della vulnerabilità e degli attacchi da essa abilitati;

Una lista di esempi, che mostrano il funzionamento di un attacco che sfrutta la
vulnerabilità associata;

Eventuali referenze a siti esterni, ovvero indirizzi di siti web in cui è possibile
trovare ulteriori approfondimenti ed integrazioni.
2.2.3.2 CAPEC
CAPEC (Common Attack Pattern Enumeration and Classification) [10] è progetto
realizzato dall’organizzazione MITRE, con l’obiettivo di stabilire una classificazione di
riferimento per la descrizione di attacchi web noti.
28
Per ciascuno degli attacchi classificati, CAPEC definisce le seguenti informazioni:

Una descrizione testuale dell’attacco;

Una possibile sequenza di passi che deve essere implementata dall’attaccante
per realizzare l’attacco;

I prerequisiti che l’attaccante deve possedere per effettuare l’attacco;

La probabilità di successo dell’attacco;

Le abilità richieste dell’attaccante per realizzare l’attacco;

Le risorse richieste per realizzare l’attacco;

Un elenco di soluzioni che è possibile implementare per risolvere le vulnerabilità
che abilitano l’attacco;

L’impatto generato da un attacco che termina con successo nei confronti
dell’integrità, della confidenzialità e della disponibilità del componente
attaccato.
29
3 HARUSPEX
Haruspex è una suite sviluppata dal gruppo di sicurezza del Dipartimento di Informatica
dell’Università di Pisa. L’obiettivo degli strumenti della suite è quello di valutare e gestire
il rischio di un sistema ICT complesso utilizzando un metodo probabilistico, quantitativo
e formale [11] [12] [13] [14] [15] [16].
Haruspex applica il metodo Monte Carlo ad uno scenario dove una minaccia intelligente,
a partire da un insieme di diritti iniziali, compone una sequenza di attacchi per
raggiungere i suoi obiettivi. La suite opera sulla definizione di uno scenario, che descrive
il sistema target dell’assessment, le sue vulnerabilità e gli attacchi che possono essere
effettuati. A partire da tale descrizione il metodo Monte Carlo simula passo per passo il
comportamento di un attaccante.
3.1 Definizioni base
Di seguito verranno introdotte alcune definizioni utili per comprendere il funzionamento
di Haruspex.

Componente: rappresenta un modulo hardware o software del sistema
analizzato. Il livello di astrazione scelto nella descrizione determina il numero di
componenti che possono essere presenti e le operazioni da loro svolte.

Agente: rappresenta una minaccia, un attaccante che ha l’interesse e la capacità
di violare la sicurezza di un sistema ICT.

Obiettivi: ogni obiettivo, o goal, comprende i diritti che l’attaccante desidera
acquisire nel sistema attaccato. Ogni diritto permette di invocare un’operazione
di un qualche componente.

Vulnerabilità: ogni componente può essere affetto da vulnerabilità, difetti od
errori in grado di abilitare attacchi elementari.
30

Attacco elementare: definisce un’azione indivisibile che può essere effettuata
dall’attaccante e che sfrutta una o più vulnerabilità per ottenere illegalmente dei
diritti. Un attacco elementare è associato ad un insieme di attributi:
o Probabilità di successo: rappresenta la probabilità che l’attacco abbia
successo. Un attacco può fallire a causa di fattori fuori dal suo controllo.
Ad esempio, un azione potrebbe avere successo solo se eseguita in un
preciso istante temporale che l’attaccante non controlla.
o Pre-condizioni: rappresentano i diritti che l’attaccante deve possedere
per potere eseguire l’azione. Ad esempio, l’attaccante può inviare un
parametro corrotto ad un metodo vulnerabile solo se possiede il diritto
di invocare l’operazione coinvolta.
o Post-condizioni: rappresentano i diritti che l’attaccante acquisisce se
l’attacco ha successo.
o Tempo di esecuzione: rappresenta il tempo necessario all’attaccante per
eseguire le azioni dell’attacco.

Attacco complesso: rappresenta la composizione sequenziale di attacchi
elementari. Consente di modellare una privilege escalation, in cui un attaccante
esegue l’attacco elementare i per acquisire i diritti necessari per l’esecuzione di
dell’attacco i+1.
31
3.2 Descrizione dello scenario
Il primo passo di Haruspex costruisce il modello che descrive il sistema. Le informazioni
che descrivono un sistema S possono appartenere ad uno dei due sottoinsiemi seguenti:

Componenti del sistema, vulnerabilità ed attacchi;

Topologia di rete ed interconnessioni.
S
c
op
ag
res(ag)
g
at
v
v(at)
pre(at)
res(at)
post(a)
succ(at)
AttGr(S,ag)
n
r(n)
λ(ag,
na(ag)
il sistema target dell’assessment
un component di S
un’operazione definita da un componente
un agente
le risorse che ag ha a disposizione
l’obiettivo di un agente
un attacco elementare
una vulnerabilità
le vulnerabilità che abilitano at
i diritti per eseguire at
le risorse per eseguire at
i diritti acquisiti se at ha successo
la probabilità di successo di at
l’attack graph con il piano di ag contro S
un nodo di AttGr(S,ag)
i diritti associati al nodo n
il look-ahead di ag
il numero di attacchi che ag esegue prima di cambiare attacco
Tabella 3.1 Acronimi Haruspex
Haruspex utilizza un approccio modulare che decompone il sistema in componenti
(hardware e software) fra loro interconnessi. Ogni componente è descritto da un
insieme di attributi, fra cui:

Un elenco di porte di rete aperte;

Un insieme di vulnerabilità;

Gli attacchi abilitati dalle vulnerabilità;

Le interfacce di rete;

Il tipo di componente.
32
La scoperta dei componenti e la definizione delle sue caratteristiche avviene attraverso
il vulnerability scanning, o scansione del sistema, che in una prima fase rileva tutti i
componenti presenti, ed in seguito associa ad ognuno le informazioni che lo definiscono.
Il campo “tipo” specifica se il componente è un host, un firewall, uno switch o un
hypervisor. La definizione del tipo consente di modellare i diritti acquisiti con un attacco
rivolto verso tale componente. Ad esempio, un attaccante che controlla un componente
di tipo firewall può alterare la tabella di routing o la topologia logica della rete.
Il modello definito da Haruspex considera due tipi di vulnerabilità:

Effettive: si tratta di vulnerabilità già scoperte attraverso una scansione. La loro
classificazione e descrizione può essere ricavata mediante un database di
vulnerabilità note, come ad esempio il CVE.

Potenziali: si tratta di vulnerabilità sospette, e vengono associate alla probabilità
di venir scoperte in un certo istante temporale.
La scoperta delle componenti e delle vulnerabilità presenti in un sistema viene realizzata
da Haruspex utilizzando Nessus. Questo scanner produce una lista di CVE associati ad un
insieme di host presenti all’interno di una sottorete. Ad ogni attacco at abilitato da una
vulnerabilità, Haruspex associa gli attributi descritti nella tabella 3.1 classificando gli
attacchi in un insieme di finito di classi. Per associare un attacco ad una classe, Haruspex
confronta la descrizione del CVE con un insieme predefinito di pattern.
Per descrivere completamente un sistema S è importante considerare la topologia logica
che definisce le connessioni fra gli host del sistema. Per questo motivo il modello di S
costruito da Haruspex include il numero di sottoreti presenti, i componenti presenti in
ciascuna sottorete, le tabelle di routing, la presenza di switch, router, firewall e le regole
di filtraggio del traffico di rete.
33
3.3 Descrizione delle minacce
La descrizione di uno scenario Haruspex prevede la modellazione di minacce intelligenti.
Si tratta di attaccanti in grado di penetrare all’interno di un sistema sfruttando percorsi
a più passi, ognuno dei quali realizzato mediante un attacco elementare che sfrutta
difetti nelle singole componenti.
Alla descrizione di una minaccia sono associate informazioni quali:

Le risorse che l’attaccante ha a disposizione per effettuare gli attacchi;

L’insieme dei diritti iniziali, come ad esempio il controllo di un nodo all’interno
della rete o la possibilità di inviare messaggi ad un host;

Gli obiettivi, ovvero l’insieme dei diritti che l’attaccante desidera acquisire al
termine dei suoi attacchi. Ad esempio, una minaccia potrebbe voler diventare
l’amministratore di un database del sistema.
Per raggiungere i propri obiettivi un attaccante seleziona ed implementa degli attacchi
complessi in funzione dei diritti in suo possesso e delle vulnerabilità a lui note. In
particolare, un attaccante può:

Implementare diversi attacchi complessi alternativi per raggiungere lo stesso
obiettivo;

Cambiare la sua sequenza di attacchi quando i suoi attacchi falliscono o vengono
scoperte nuove vulnerabilità nel sistema.
Haruspex seleziona gli attacchi che un agente esegue attraverso l’analisi di un Attack
Graph. AttGr(S, g) è un grafo diretto, etichettato e aciclico che rappresenta gli attacchi
ed i piani che una minacca ag può selezionare utilizzando i diritti in suo possesso.
Ogni nodo del grafo rappresenta un insieme di diritti r(n) che ag può possedere. Le
transizioni fra i nodi rappresentano gli attacchi elementari: esiste un arco etichettato at
fra un nodo n1 ed un nodo n2 se r(n1) include le precondizioni pre(at), e r(n2) è uguale
all’unione fra r(n1) e post(at).
Un nodo n si definisce iniziale se descrive l’insieme dei diritti posseduti dalla minaccia
ag prima che esegua un qualunque attacco. Un nodo si definisce finale se contiene
34
l’insieme di tutti i diritti che ag desidera acquisire attaccando il sistema. Il percorso che
va da un nodo iniziale ad un nodo finale definisce una sequenza di attacchi elementari
che consentono alla minaccia di raggiungere il suo obiettivo.
Per descrivere la quantità di informazioni che un agente considera nella selezione di un
attacco complesso, Haruspex associa ad ag un parametro λ(ag), definito look-ahead, un
intero non negativo. Per selezionare un percorso da implementare, un agente considera
solo cammini dell’attack graph lunghi al massimo λ(ag). Tipici valori assegnati al lookahead sono 0, 1 o 2.
Per definire il comportamento dell’attaccante Haruspex definisce un insieme di strategie
che stabiliscono il criterio secondo cui la minaccia seleziona l’attacco da eseguire in un
certo istante.
Le strategie modellate da Haruspex sono:

Max Probability: la minaccia seleziona l’attacco complesso con la più alta
probabilità di successo;

Max Increment: la minaccia seleziona l’attacco complesso che garantisce, in caso
di successo, l’acquisizione del più grande insieme di diritti;

Max Efficiency: la minaccia seleziona l’attacco complesso con il miglior rapporto
fra probabilità di successo e tempo di esecuzione;

Smart Subnet First: la minaccia seleziona uno qualsiasi degli attacchi disponibili
con la stessa probabilità, dando priorità agli attacchi che le consentono di
passare da una sottorete all’altra e, qualora si trovasse nella stessa sottorete
dell’obiettivo, agli attacchi verso l’obiettivo stesso.
Un altro parametro importante che definisce un agente è il numero di volte che tenta di
ripetere un attacco fallito prima di selezionare un attacco diverso.
35
3.4 Simulazioni
Partendo dalla definizione di uno scenario Haruspex applica il metodo Monte Carlo, ed
esegue un esperimento che comprende un numero elevato ed indipendenti di run.
Ciascun run simula il comportamento di una o più minacce che, a partire dai loro diritti
iniziali, seguendo la strategia associata, cercano di raggiungere il loro obbiettivo
sfruttando le vulnerabilità e gli attacchi che esse abilitano.
Ad ogni passo della simulazione, il simulatore considera il modello S ed i vari agenti. Se
l’agente ag non ha ancora raggiunto almeno un suo obiettivo e non è impegnato
nell’eseguire un attacco, il simulatore esegue l’attacco at successivo nella sequenza
selezionata.
Per simulare la strategia di selezione di un agente ag, Haruspex analizza un sottoinsieme
del grafo AttGr(S,ag) che include tutti i cammini di lunghezza λ(ag) a partire dal nodo
che ag ha raggiunto in quel dato istante temporale. Il sottoinsieme viene costruito
dinamicamente considerando i cammini in funzione dell’obiettivo che la minaccia
desidera raggiungere.
Il tempo che ag impiega per selezionare una sequenza dipende dalle informazioni in suo
possesso. Infatti, per poter valutare le varie sequenze, un agente deve impiegare del
tempo per scandire alcuni nodi del sistema e scoprire nuove vulnerabilità in grado di
abilitare degli attacchi.
Al termine di un singolo run tutte le informazioni collezionate durante l’esecuzione
vengono memorizzate in un database.
36
3.5 Risultati
Le simulazioni effettuate da Haruspex producono in output un database che contiene
un campione statistico. Fra le informazioni che comprende il campione risultano di
particolare interesse i seguenti dati:

La sequenza degli attacchi effettuati da ciascun agente;

Gli obiettivi che ciascun agente ha raggiunto;

Il tempo impiegato dall’agente per raggiungere gli obiettivi;

I piani di attacco utilizzati dagli agenti;

Le vulnerabilità più sfruttate dalle varie minacce;

Gli host che sono stati maggiormente attaccati;

Le curve di stress, definite in maggiore dettaglio nel paragrafo successivo.
3.5.1 Le curve di stress
Le curve di stress definiscono una misura sintetica attraverso cui è possibile esprimere
la robustezza di un sistema S bersaglio degli attacchi di un attaccante ag.
Figura 3.1 Esempio di curva di stress
Nel grafico le ascisse rappresentano il tempo che la minaccia ha a disposizione per
raggiungere il proprio obiettivo, sulle ordinate invece è rappresentata la probabilità di
successo nel tempo corrispondente.
Osservando la figura 3.1 è possibile individuare due istanti temporali principali:
37

T0: rappresenta l’istante in cui la probabilità di successo dell’agente ag diventa
maggiore di zero. E’ il momento in cui la robustezza del sistema inizia ad essere
compromessa dagli attacchi. L’istante T0 dipende dal tempo di esecuzione di ogni
singolo attacco elementare e dalla lunghezza dell’attacco complesso più corto
che consente di raggiungere l’obbiettivo g.

T1: rappresenta l’istante temporale a partire da cui la probabilità di successo
dell’attaccante è sempre uguale a 1. Questo valore dipende dalla probabilità di
successo di ogni singolo attacco effettuato dalla minaccia. Questa probabilità
determina in media il numero di volte che l’agente deve eseguire un attacco
prima che questo abbia successo.
Il valore t1 – t0 esprime quanto a lungo il sistema è in grado di resistere agli attacchi
prima di cedere completamente.
Le curve di stress consentono di confrontare la robustezza del sistema in funzione delle
varie strategie adottate dalle minacce. Nel grafico della figura 3.1, ad esempio, è
possibile verificare come un agente che implementa la strategia MaxIncrement con
look-ahead 2 riesca a compromettere più velocemente il sistema analizzato rispetto allo
stesso agente che si muove in accordo con la strategia MaxProbability con look-ahead
2.
Le curve di stress possono inoltre essere utilizzare per mettere a confronto sistemi
differenti.
Figura 3.2 Curva di stress che confronta 3 sistemi differenti
Ad esempio, il grafico della figura 3.2 mette a confronto la robustezza di 3 versioni
differenti dello stesso sistema. Una prima configurazione che prevede 6 sottoreti con 49
38
host al suo interno, una seconda che prevede 6 sottoreti con 98 host, ed una terza che
prevede 7 sottoreti con 98 host.
Un’analisi del grafo consente di identificare facilmente la configurazione del sistema che
garantisce una maggiore robustezza: nel caso della figura 3.3 è possibile verificare come
la linea gialla risulti sempre al di sotto delle altre curve, indicando una maggiore
resistenza del sistema agli attacchi.
3.6 Stato dell’arte
Prima degli interventi apportati nel corso di questa tesi, la struttura logica di Haruspex
era descritta dall’immagine seguente.
Figura 3.3 Descrizione modulare di Haruspex
Il sistema può essere considerato come due macro-moduli distinti: un primo modulo
relativo al risk assessment, comprendente un Builder, un Thread Descriptor, un Engine
ed uno Scout, ed un modulo relativo al risk management che comprende il solo
manager.
Di seguito viene illustrato brevemente il ruolo di ciascun componente della suite:
39

Builder: riceve in input l’output prodotto dai vulnerability scanner e costruisce il
modello del sistema analizzato. Il builder è logicamente suddiviso al suo interno
in 3 sottomoduli:
o Host Builder: analizza il report degli scanner per identificare i componenti
del sistema. Ad ogni componente vengono associati i vari attributi quali
le interfacce di rete, le porte aperte etc.
o Vulnerability Builder: analizza il report degli scanner per estrapolare le
vulnerabilità presenti nel sistema. Ognuna di esse viene classificata in
accordo con le informazioni presenti nel CVE ad essa associato. Queste
informazioni definiscono parametri quali le pre e le post condizioni degli
attacchi, l’impatto che ha la vulnerabilità sul sistema, la presenza di
eventuali exploit pubblici etc.
o Topology Builder: costruisce la topologia logica del sistema. Definisce le
interconnessioni fra le varie sottoreti così come le connessioni fra i singoli
host all’interno delle reti.

Threat Descriptor: è il modulo che consente di modellare i vari agenti che
attaccano il sistema negli scenari di interesse. Permette di specificare parametri
quali i diritti iniziali di un agente, gli obiettivi che desidera raggiungere, la
strategia che definisce il suo comportamento etc.

Engine: è il simulatore del sistema. A partire dalla descrizione definita attraverso
il Builder ed il Threat Descriptor applica il metodo Monte Carlo e colleziona i
campioni statistici che restituisce in un database.

Scout: il compito di questo modulo è di simulare il comportamento di più agenti
in un singolo run, in condizioni ideali per l’attaccante dove tutti gli attacchi non
falliscono mai e tutte le vulnerabilità sono già note e scoperte. Lo scout
restituisce come output un limite inferiore al tempo richiesto ad un attaccante
per raggiungere i suoi obiettivi.

Manager: utilizzando i risultati prodotti dal risk assessment, si occupa di
identificare delle contromisure che possono essere applicate al sistema per
aumentarne la robustezza.
40
4 AMBIENTI APPLICATIVI
La descrizione dello scenario Haruspex introdotta nel terzo capitolo consente di
modellare un sistema ICT come un insieme di componenti interconnessi.
A partire da tale definizione, questo capitolo presenta un’estensione del modello che
consente di specializzare le relazioni fra i vari componenti di un sistema, rendendo la
definizione dello scenario più precisa e versatile.
La definizione proposta prende considera due nuove tipologie di relazioni:

Gerarchiche: sono relazioni che stabiliscono un legame di tipo padre-figlio fra
una coppia di componenti;

Trasversali: sono relazioni tra figli dello stesso padre oppure tra componenti con
padre diverso.
Figura 4.1 Esempio di tipologie di relazione
La figura 4.1 mostra un esempio in cui i collegamenti rossi e blu definiscono,
rispettivamente, relazioni di tipo padre-figlio e di tipo trasversale. E’ importante
evidenziare come il legame gerarchico possa essere astratto ulteriormente ed esteso
41
verso l’alto senza alcuna limitazione: il componente figlio F1, ad esempio, può essere
padre di altri figli, e così via.
4.1 Modello ad ambienti
Le relazioni introdotte nel paragrafo precedente possono essere utilizzate per definire
una nuova modellazione del sistema. Consideriamo una definizione dello scenario in cui
un sistema S è descritto come un insieme di host organizzati in una o più sottoreti.
Ciascun host viene definito nel modello come la relazione tra più ambienti:

Un ambiente principale, che definisce il componente sistema operativo;

Un insieme di ambienti figli, che rappresentano gli ambienti applicativi presenti
sull’host corrispondente.
Figura 4.2 Esempio di modellazione ad ambienti
L’esempio mostrato nella figura 4.2 descrive la modellazione di un singolo host, in cui il
componente principale sistema operativo è il padre di due ambienti applicativi di tipo
figlio: un servizio RDP di connessione a desktop remoto, ed un applicativo di tipo
database.
42
4.1.1 Classificazione di ambienti applicativi
Per definire il ruolo che assume un ambiente all’interno del sistema modellato vengono
definite un insieme di classi predefinite. Ciascuna classe descrive i diritti associati
all’ambiente e le relazioni che questo assume nei confronti degli altri componenti del
sistema.
Definire la relazione tra un ambiente ed un altro permette di definire quali diritti può
acquisire una minaccia che acquisisce il controllo dell’ambiente applicativo in questione.
Le relazioni che si possono definire per ciascun ambiente sono:

Gerarchica verso i figli: acquisire il controllo di un ambiente padre permette alla
minaccia di acquisire diritti nei confronti degli ambienti figli. Ad esempio, in
riferimento alla figura 4.1, acquisire il controllo dell’ambiente P1 fornisce alla
minaccia anche dei diritti nei confronti degli ambienti F1 e F2.

Gerarchica verso il padre: controllare un ambiente figlio permette alla minaccia
di acquisire diritti nei confronti dell’ambiente padre. In riferimento alla figura
4.1, acquisire il controllo dell’ambiente F1 fornisce diritti nei confronti
dell’ambiente P1.

Trasversale: controllare un ambiente che può avere una relazione con un figlio
discendente dallo stesso padre, oppure con un ambiente appartenente ad un
padre diverso, permette alla minaccia di acquisire solamente i diritti nei
confronti dell’ambiente con cui ha la relazione. In riferimento alla figura 4.1,
prendere il controllo dell’ambiente F2 fornisce diritti nei confronti dell’ambiente
F3 (figli di padri diversi), oppure prendere il controllo dell’ambiente F4 fornisce
diritti verso l’ambiente F5 (figli dello stesso padre).
Inoltre, la relazione fra 2 ambienti è una relazione non commutativa.
La classificazione di un ambiente in una delle classi predefinite consente pertanto di
stabilire automaticamente come l’ambiente si inserisce all’interno del modello del
sistema, specificandone i diritti e le relazioni con gli altri ambienti.
43
4.2 Modello ad ambienti: servizi web
Questa sezione mostra come il modello ad ambienti descritto nel paragrafo 4.1 possa
essere istanziato per modellare i servizi web.
Figura 4.3 Modellazione di servizi web
Come mostrato dalla figura 4.3, la modellazione dei servizi web prevede la definizione
di due nuove classi di ambienti, collegate da relazioni:

La classe web;

La classe database.
4.2.1 Classe Web
La classe Web modella ambienti applicativi di tipo web, quali ad esempio i web server.
L’ambiente così definito associa tutte le vulnerabilità relative ai siti, alle applicazioni web
ed ai loro utenti.
Le relazioni generiche definite nel paragrafo 4.1.1 possono dunque essere specializzate
per modellare lo scenario web come segue:

Relazione gerarchica verso i figli: viene istanziata per modellare attacchi di tipo
“escape to OS”. Si tratta di attacchi abilitati da vulnerabilità presenti su siti web
44
e che consentono ad un attaccante di acquisire diritti nei confronti dell’ambiente
sistema operativo.
Figura 4.4 Modellazione Escape to OS
La figura 4.4 evidenzia in rosso la relazione sfruttata dall’attaccante.
Appartengono a questo tipo attacchi quali:
o Buffer Overflow [17]: in questo attacco una minaccia invia un input
costruito in modo tale da generare un overflow di memoria. Questo può
portare all’esecuzione di codice arbitrario a livello del sistema operativo,
che può permettere all’attaccante di acquisire diritti di amministratore
della macchina.
o Path Traversal [18]: quest’attacco consente ad una minaccia di accedere
a file o directory memorizzati al di fuori dell’ambiente web.
Questo consente all’attaccante di acquisire diritti di lettura ed
eventualmente di scrittura sul file system, a livello dell’ambiente sistema
operativo.

Relazione traversale: viene istanziata per modellare il caso specifico delle SQL
Injection [19].
45
Figura 4.5 Modellazione SQL Injection
Si tratta di un attacco in cui una minaccia sfrutta un input non opportunamente validato
dal servizio web per alterare la composizione delle query SQL inviate dal server web al
database. Questo consente all’attaccante di acquisire dei diritti di lettura e scrittura
verso il componente appartenente alla classe database.
Come mostrato nella figura 4.5, la modellazione così definita consente di descrivere lo
scenario in cui una minaccia è in grado di raggiungere un suo obiettivo (la scrittura nel
database) anche senza acquisire dei diritti nel componente che ospita il servizio.
L’esempio della figura 4.3 modella invece lo scenario in cui il web server ed il database
si trovano sullo stesso componente.
4.2.2 Classe Database
La classe Database modella ambienti applicativi di tipo database, quali ad esempio
Microsoft SQL server o MySQL server.
Le relazioni generiche definite nel paragrafo 4.1.1 possono essere specializzate nel
seguente modo:

Relazione gerarchica verso i figli: viene istanziata per modellare attacchi che
consentono ad un attaccante di sfruttare vulnerabilità presenti sul database per
acquisire diritti nei confronti dell’ambiente del sistema operativo.
46
4.3 Implementazione del modello web
Questa sezione descrive l’estensione implementata in Haruspex per supportare il
modello
ad
ambienti.
L’attenzione
sarà
focalizzata
in
particolar
modo
sull’implementazione degli ambienti web.
4.3.1 Web Builder
Le vulnerabilità web scoperte mediante l’analisi condotta con un web vulnerability
scanner appartengono alla categoria delle vulnerabilità non standard, ovvero
vulnerabilità per le quali non esiste un database di riferimento, come ad esempio il CVE,
a cui poter fare riferimento per una loro classificazione.
La prima estensione necessaria ad Haruspex è la definizione di un nuovo modulo,
nominato Web Builder, il cui compito è quello di analizzare e classificare l’insieme delle
vulnerabilità rilevate dagli scanner web.
Figura 4.6 Web Builder
Il Web Builder si integra nella suite come un nuovo modulo del Builder, e si affianca ai
già presenti Vulnerability Builder, Host Builder e Topology Builer, per la costruzione del
modello del sistema.
47
Il comportamento implementato dal Web Builder può essere riassunto in 3 passi
principali:
1. Analisi dell’input;
2. Classificazione delle vulnerabilità non standard;
3. Aggiornamento del database delle vulnerabilità.
4.3.1.1 Analisi dell’input
Il Web Builder riceve in input i report generati dai web vulnerability scanner. Nel caso di
Owasp Zap, lo strumento di riferimento utilizzato per il caso di studio, si tratta di file xml
organizzati come una sequenza di alert. Ciascun alert contiene informazioni utili per
descrivere una sola vulnerabilità web.
Figura 4.7 Esempio di alert generato da Owasp ZAP
La figura 4.7 mostra un esempio di alert che può apparire in un report ZAP. Fra le
informazioni utili per classificare una vulnerabilità abbiamo:

Il tipo di vulnerabilità rilevato, indicato nel campo alert;

L’impatto generato dalla vulnerabilità, indicato nel campo riskdesk;

Il componente affetto dalla vulnerabilità, indicato nei campi uri e param;
48

Gli identificatori di riferimento al CWE e WASC, indicati nei campi cweid e wascid.
L’output prodotto dalla fase di analisi genera una lista di vulnerabilità, descritte dagli
attributi sopraelencati.
4.3.1.2 Classificazione delle vulnerabilità
Il passo successivo implementato dal Web Builder utilizza le informazioni raccolte nella
prima fase per classificare le vulnerabilità web, mediante la definizione delle precondizioni e delle post-condizioni ad esse associate.
Nel capitolo 2 sono stati introdotti due standard di riferimento per la definizione delle
vulnerabilità web: WASC e CAPEC. Come è possibile verificare nella figura 4.7, i web
scanner come ZAP e Appscan associano alle vulnerabilità il solo identificativo WASC.
Le informazioni contenute su tale sito sono tuttavia insufficienti per una adeguata
classificazione delle vulnerabilità, poiché le informazioni che il sito associa alle
vulnerabilità sono troppo informali.
Figura 4.8 Esempio di descrizione WASC
La figura 4.8 contiene un estratto della descrizione di una vulnerabilità di tipo cross-site
scripting, così come riportata sul sito WASC. Come si può vedere si tratta di una
49
descrizione testuale dell’attacco abilitato dalla vulnerabilità, con esempi che ne
dimostrano il funzionamento.
La descrizione degli vulnerabilità presentata su CAPEC, invece, fornisce una definizione
più formale degli attacchi, che vengono classificati in funzione dell’impatto da essi
generato nei confronti dell’integrità, della confidenzialità e della disponibilità dei
componenti attaccati. Presso il sito CAPEC [20] è possibile scaricare il file xml che
definisce tali valori per ciascun attacco. Oltre al file xml è presente anche un documento
xsd che stabilisce l’insieme predefinito dei valori utilizzati per definire l’impatto.
Figura 4.9 Scope CAPEC
Nella figura 4.9 vengono mostrati i campi utilizzati da CAPEC per definire l’impatto
generato da un attacco. La figura 4.10 definisce invece i valori che possono essere
assunti da tali campi. Analizzando i valori della figura 4.10 è possibile identificare quali
siano le post-condizioni che consentono ad una minaccia di acquisire dei diritti nei
confronti dell’ambiente sistema operativo a partire dall’ambiente web. Tali valori sono:

Read/Modify files or directory;

Read/Modify memory;

Execute unauthorized code or commands;
Sebbene i progetti WASC e CAPEC siano indipendenti, entrambi i siti web mettono fra
loro in relazione la definizione degli attacchi [21] [22]. Questo consente di poter
50
utilizzare l’identificativo WASC riportato dai web scanner per ricondursi alla
classificazione più formale definita da CAPEC.
Figura 4.10 Valori d'impatto CAPEC
4.3.1.3 Estensione ed aggiornamento del database
Il database utilizzato da Haruspex è stato esteso con delle nuove strutture dati, in cui
vengono memorizzate le informazioni relative alle vulnerabilità classificate dal Web
Builder.
Ad ogni esecuzione, prima di procedere con la classificazione delle vulnerabilità web
individuate nei report, il Web Builder interroga il database per verificare se le
vulnerabilità siano già state classificate per non ripetere attività precedenti.
51
4.3.2 Ulteriori estensioni ad Haruspex
La definizione del Web Builder ha introdotto un meccanismo per classificare le
vulnerabilità web non standard in Haruspex.
Per supportare la definizione del modello ad ambienti, istanziato in particolar modo per
modellare ambienti web, sono stati estesi due moduli già esistenti nella suite: l’host
builder e l’engine.
Per quanto riguarda l’host builder, sono state definite delle specifiche di configurazione
che consentono di associare ad un host, identificato a partire dai report generati da
Nessus, le vulnerabilità web presenti nei report generati da Owasp Zap. Questo consente
di specificare in un host la relazione che lega l’ambiente principale del sistema operativo
con l’ambiente web.
Le specifiche di configurazione permettono di definire le relazioni tra l’ambiente web ed
uno o più database.
Le estensioni implementate sull’engine consentono al sistema di arricchire l’insieme
degli attacchi a disposizione di una minaccia, prendendo in considerazione anche le
nuove vulnerabilità web classificate dal Web Builder.
52
5 CASO DI STUDIO
Il caso di studio della tesi è stato svolto in collaborazione con Terranova Software, una
società nata nei primi anni del 2000 e che supporta l’automazione dei processi business
delle aziende che operano in svariate aree della distribuzione, come gas, energia
elettrica ed acqua.
L’attenzione del caso di studio è rivolta in particolar modo verso il sistema RETISSM
(Software di Smart Metering), una soluzione per il supporto e l’automazione dei processi
legati alla telemisura e la telegestione dei gruppi di misura nel contesto Smart Gas
Metering.
Il software di Terranova, oggetto dello studio, è una soluzione industrializzata e come
tale ampiamente utilizzata in diverse realtà produttive, il cui campo specifico di
applicazione richiede una sensibilità particolare verso i temi della sicurezza informatica.
Proprio a causa del particolare campo di applicazione, Terranova ha deciso di valutare
ulteriori scenari di sicurezza in collaborazione con l'Università di Pisa, concordando con
il gruppo di sicurezza del Dipartimento di Informatica la verifica della robustezza del del
proprio software in alcuni di scenari considerati come estremi.
Lo specifico oggetto dello studio, infatti, prevede l'attacco ad un ambiente di hosting del
software, collegato in VPN con due Reparti, A e B. L'ambiente è direttamente accessibile
dalle rispettive LAN client in modo da agevolare il lavoro del personale dell’azienda. Di
conseguenza, l'obiettivo dello studio non sarà quello di valutare la robustezza rispetto
ad un attacco ai servizi esposti sugli IP pubblici dal software e, quindi, a valutare la
robustezza dei servizi offerti direttamente dal sistema. Interessa invece verificare
l'impatto di un attacco al sistema che parta dall'interno di una rete "trusted”. In
particolare, vengono considerati due scenari di attacco alla rete fidata: attacchi di
Outsider alla Trusted LAN (TLAN) e di Insider (alla TLAN).
Gli Outsider utilizzano i servizi esposti su internet dei Reparti A e B per tentare di
accedere alla TLAN e, quindi, ai vari componenti software. Gli Insider sfrutteranno
53
l'acquisizione di diritti di una risorsa autorizzata nella TLAN per tentare l'accesso al
software. La compartimentazione dei Reparti A e B aumenta la complessità del
confronto dei risultati ottenuti dagli Outsider con quelli ottenuti dagli Insider. Infatti gli
obiettivi degli Outsider riguardano servizi esposti su LAN demilitarizzate (DMZ) e in
quanto tali in grado di comunicare con la TLAN solo tramite alcuni servizi autorizzati e
verso determinati host. La presenza di firewall compartimentali e di Intrusion Prevention
System (IPS) rendono la probabilità di successo degli outsider decisamente bassa
soprattutto perché prima di raggiungere l'obiettivo, l’attaccante deve guadagnare
l'accesso alla TLAN. Per semplificare e uniformare le condizioni di valutazione, è stato
considerato uno scenario in cui, contrariamente alla realtà, non siano presenti restrizioni
di comunicazioni tra le sottoreti e le TLAN, in modo tale che un Outsider venga posto
nelle stesse condizioni di un Insider. Allo scopo, si è assunto che gli attaccanti
conoscessero tutte le informazioni richieste in input da Haruspex. Le analisi svolte
mediante Haruspex si basano quindi sulla ipotesi semplificativa che un Outsider riesca
ad effettuare una scansione dei sistemi target a partire dalla propria posizione. Inoltre,
si è assunto che una tale minaccia possa sfruttare le vulnerabilità scoperte ignorando
volutamente i meccanismi di protezione adottati da Terranova e che nella realtà
renderebbero estremamente più bassa la probabilità di successo dei vari attacchi.
5.1 Generalita
Lo smart meter è un dispositivo elettronico di controllo per il monitoraggio in tempo
reale dei consumi di luce, acqua e gas. Sfruttando una rete di sensori wireless, gli smart
meter possono interagire con il sistema centrale di controllo per lo scambio di
informazioni utili per il monitoraggio della distribuzione, come i valori dei consumi
registrati. Gli smart meter permettono inoltre di intervenire sugli impianti in caso di
guasti o situazioni anomale senza la necessità di ricorrere ad un intervento sul posto.
Gli smart meter considerati nel caso di studio sono composti da un correttore, dotato di
sensori di pressione, sensori di temperatura e di impulsi, un misuratore ed un modem
alimentato a batteria.
54
5.2 Architettura del Sistema
Il sistema analizzato è costituito da 3 macro reti principali, a cui si farà riferimento nel
seguito con il nome di RepartoA, RepartoB e SSM.
Figura 5.1 Panoramica delle reti RepartoA e RepartoB
Lo schema della figura 5.1 descrive l’organizzazione delle reti RepartoA e RepartoB. Le
due reti sono collegate da una VPN MPLS (Virtual Private Network, Multi Protocol Label
Switching). Il collegamento tra il RepartoA ed il RepartoB ha come estremi 2 firewall.
L’accesso alla rete internet avviene attraverso il solo RepartoA.
La rete SSM è realizzata su un sistema cloud fornito e gestito da un provider esterno ed
è connessa direttamente con la rete del RepartoA attraverso una VPN.
55
5.2.1 RepartoB
La rete del RepartoB è organizzata in 4 sottoreti principali:

Una rete LAN, dove sono presenti server e database utilizzati per lo sviluppo del
software dell’azienda. In questa rete sono collocati anche i computer utilizzati
dai dipendenti.

Una rete VC e VOIP, dove sono installati i software per la gestione e
l’organizzazione delle videoconferenze.

Una rete DMZ, dove sono collocati i server di posta, alcuni server interni per il
testing, e due servizi web esposti verso l’esterno:
o Extplorer, si tratta di un file manager PHP basato su un’interfaccia web;
o HelpDesk, descritto nel paragrafo successivo.
5.2.1.1
HelpDesk
L’Helpdesk è un servizio web di tipo OTRS (Open-Source Ticket Request System) [23]. Si
tratta di un servizio software open source che consente alle aziende di gestire le richieste
di assistenza da parte dei propri clienti mediante l’assegnazione di ticket.
Il servizio web è esposto verso la rete la internet.
E’ possibile autenticarsi all’Helpdesk con 2 profili utenti differenti:

Cliente, utilizzato dai clienti dell’azienda per inviare delle segnalazioni;

Operatore, utilizzato internamente da un dipendente dell’azienda per
rispondere alle segnalazioni inviate dai clienti.
5.2.2 RepartoA
La rete del RepartoA comprende 4 sottoreti principali:

Una rete LAN, dove sono presenti database, dispositivi NAS (Network Attack
Storage), server di backup e documentazione accessibile agli sviluppatori.

Una rete DMZ, dove sono collocati alcuni server di sviluppo dell’azienda.

Una rete VOIP ed una rete VC, dove sono presenti applicazioni e dispositivi per
videoconferenze e VOIP (Voice Over IP).
56
5.2.3 Rete SSM
Figura 5.2 Rete SSM, su Cloud Provider
La figura 5.2 descrive l’organizzazione logica della rete SSM situata su cloud gestito da
un provider.
Di seguito vengono descritti i componenti di rilievo:

MDM (Meter Data Management), è un componente che si occupa dei processi
di gestione dei dati di misura e dei consumi. Oltre a ciò gli sono demandati la
gestione degli allarmi, la validazione dei dati ed il calcolo delle curve di consumo.
Le informazioni gestite dall’MDM vengono memorizzate nel database DB2.

SW - noto anche come MDR (Meter Data Reading), è il sistema di acquisizione
centrale dei dati.

NM (Network Manager), è un componente dedicato alla gestione efficiente della
rete di concentratori, necessari alla creazione della rete radio per il collegamento
con gli smart meter.
57

PW (Portale Web), è un servizio web che espone l’interfaccia utilizzata dagli
operatori per comunicare con l’MDM. E’ possibile autenticarsi al servizio con 2
profili differenti, uno di tipo Operatore ed uno Amministratore.
Gli smart meter comunicano direttamente con il SW mediante protocollo DLMS (Device
Language Message Specification) su connessione GPRS. Qualora la connessione GPRS
non sia attiva, gli smart meter inviano i dati mediante SMS.
La connessione fra gli smart meter ed il SW avviene una sola volta al giorno, in cui
vengono inviate tutte le informazioni necessarie.
Il SW invia i dati all’MDM ogni ora mediante protocollo WCF (Windows Communication
Foundation).
I componenti della rete SSM esposti verso la rete esterna sono SW e PW.
All’interno della rete SSM è presente un servizio interno, nominato Iomega, utilizzato
come NAS (Network Attached Storage).
58
5.3 Assessment del sistema
In un’ottica di responsible disclosure, nel seguito vengono fornite solo alcune
informazioni sui valori in ingresso all’analisi ed ai risultati prodotti. Di conseguenza, ad
esempio, non verranno forniti gli identificatori delle vulnerabilità scoperte.
Per la valutazione del rischio della rete Terranova sono stati utilizzati i seguenti software:

Nessus Free Edition;

Owasp ZAP;

Haruspex.
Utilizzando lo scanner Nessus sono state analizzate tutte le reti elencate nella tabella
5.1.
RepartoA
DMZ, LAN, VC, VOIP
RepartoB
DMZ, LAN, VC
Cloud
SSM
Tabella 5.1 Reti analizzate con Nessus
Utilizzando lo scanner Owasp ZAP sono stati analizzati i seguenti servizi web:

RepartoB
o Extplorer, utilizzando un account con diritti utente di sola lettura e
scrittura dei file condivisi e dei file personali;
o HelpDesk, utilizzando un account di tipo Utente ed un account di tipo
Operatore;

Cloud
o Iomega, utilizzando un account con diritti utente di sola lettura e scrittura
sui file condivisi ed i file personali;
o PW, utilizzando un account di tipo Operatore ed un account di tipo
Amministratore.
59
5.3.1 Output dello standard assessment
Il vulnerability scanning dei vari componenti ha evidenziato un numero elevato di
vulnerabilità, suddivise come segue fra le reti del sistema.
5.2.2.1 Nessus
Figura 5.3 Resoconto vulnerabilità Nessus
Il numero di vulnerabilità segnalate da Nessus non è il numero totale di vulnerabilità
presenti nel sistema, ma quello delle vulnerabilità distinte che sono state scoperte nelle
singole reti.
Il grafico della figura 5.4 mostra invece una distribuzione delle vulnerabilità classificate
secondo il valore d’impatto loro assegnato dal CVE. Nell’asse delle ordinate il numero di
riferimento è la totalità della vulnerabilità riscontrate nel sistema Terranova.
300
250
200
150
100
50
0
Critico
Alto
Medio
Basso
Figura 5.4 Impatto vulnerabilità Nessus
60
5.2.2.2 Owasp ZAP
Figura 5.5 Resoconto vulnerabilità Owasp ZAP
Il numero di vulnerabilità riportato da ZAP è quello totale delle vulnerabilità riscontrate.
Nel caso delle vulnerabilità web, il grafico della figura 5.6 mostra una distribuzione delle
vulnerabilità secondo la scala di impatto assegnata da CAPEC.
Alto
Medio
Basso
Figura 5.6 Impatto vulnerabilità Owasp Zap
Un’analisi preliminare condotta sui risultati prodotti dallo standard assessment fornisce
delle indicazioni interessanti: come è possibile vedere nel diagramma della figura 5.6, le
vulnerabilità web con un valore d’impatto alto sono un numero estremamente basso. In
particolar modo, si tratta di vulnerabilità relative al solo ambiente web, che non
consentono l’acquisizione di diritti nei confronti dell’ambiente sistema operativo.
Questo consente di anticipare che le vulnerabilità web non standard riscontrate da ZAP
avranno un ruolo marginale nelle simulazioni.
61
5.3.2 Assessment Haruspex
Nel seguito viene descritto lo scenario modellato da Haruspex, ed i risultati prodotti
dall’assessment.
5.3.2.1 Creazione del modello delle minacce
Gli esperimenti condotti con Haruspex hanno considerato 6 minacce diverse per le quali
sono state fornite tutte le informazioni che Haruspex richiede e che sono descritte nel
seguito. Le minacce sono suddivise in 2 categorie diverse in base ai diritti iniziali a loro
assegnati:

Outsider: definiscono agenti esterni al sistema Terranova, che cercano di
raggiungere i loro obiettivi a partire dai soli servizi esposti sulla rete internet. I
diritti assegnati a questo tipo di minaccia sono:
o Connessione remota verso i componenti SW, PW, Helpdesk, Extplorer;
o Utenti web dei servizi PW, Helpdesk, Extplorer;

Insider: si tratta di agenti interni al sistema Terranova, ovvero minacce che hanno
diritti su risorse interne ad una delle reti del sistema. In genere questa minaccia
rappresenta un dipendente intenzionato ad attaccare l’azienda o una minaccia
che è riuscita mediante social engineering o phishing ad impersonare il
dipendente. I diritti assegnati a questo tipo di minaccia sono:
o Amministratore locale di un host appartenente alla rete LAN del
RepartoA;
o Amministratore locale di un host appartenente alla rete LAN del
RepartoB.
Gli obiettivi assegnati ad entrambe le categorie di minacce sono i seguenti:

Goal1: il controllo del SW con diritti da amministratore, oppure rendere il
componente inagibile (Denial Of Service);

Goal2: il controllo del database DB2 della rete SSM con diritti da amministratore,
oppure i diritti di lettura e scrittura sul database DB1;
62

Goal3: il controllo del SW con diritti di amministratore, e quello dei 2 database
della rete SSM con diritti di amministratore.
La tabella 5.2 riassume le 6 minacce simulate.
Minaccia
Diritti Iniziali
Obiettivi
1
OUTSIDER
ADMIN SW or DOS SW
ADMIN DB2
2
OUTSIDER
or
READ/WRITE DB1
3
OUTSIDER
ADMIN SW + DB1 + DB2
4
INSIDER
ADMIN SW or DOS SW
ADMIN DB2
5
INSIDER
or
READ/WRITE DB1
6
INSIDER
ADMIN SW + DB1 + DB2
Tabella 5.2 Riepilogo delle minacce simulate
5.3.2.2
Simulazioni
Per ciascuna delle 6 minacce è stato eseguito un esperimento Haruspex con 50000 run,
raggiungendo un livello di confidenza del 95% sui componenti attaccati.
Per coprire tutti i vari livelli di competenza e di strategie di scelta dell’attacco, per
ciascuna delle 6 minacce sono state impiegate tutte le seguenti strategie:

Max Increment con look-ahead 1 e 2;

Max Probability con look-ahead 1 e 2;

Max Efficiency con look-ahead 2;

Subnet First con look-ahead 0.
Il tempo limite delle simulazioni è stato impostato a 10 giorni.
63
5.3.2.3 Risultati prodotti da Haruspex
Per ciascuna delle minacce considerate illustriamo nel seguito alcune informazioni ed
alcune statistiche utili per valutare il rischio che ognuna di esse genera.
Le informazioni illustrate sono:

Il numero dei piani di attacco scoperti;

Il numero medio di passi effettuati nei piani di attacco;

Il numero medio di host attaccati nei piani di attacco;

Le curve di stress.
64
5.3.3.1 Minaccia 1
 Punto di partenza: Outsider

Obiettivo: ADMIN SW or DOS SW
SubnFirst
MaxIncr 1 MaxIncr 2
MaxProb 1
MaxProb 2
MaxEff
N. Piani
2
1
2
2
2
2
N. Passi
4
2
5
5
5
5
N. Host
1
1
1
1
1
1
Tabella 5.3 Report minaccia 1
La minaccia 1 rappresenta un caso particolare: come è possibile vedere nella tabella 5.3,
nella maggior parte delle simulazioni i suoi attacchi hanno come obiettivo un solo host.
Il risultato è giustificato dal fatto che la minaccia possiede dei diritti iniziali nei confronti
dell’obiettivo, che risulta esposto verso l’esterno. Di conseguenza la minaccia cerca di
prendere immediatamente il controllo del nodo che costituisce il suo obiettivo.
Figura 5.7 Curva di stress della Minaccia 1
Le curve di stress della figura 5.7 mostrano come la minaccia sia in grado di raggiungere
il suo obiettivo dopo circa 3 ore e 30 minuti, utilizzando la strategia MaxIncrement con
look-ahead 1. Questa strategia genera un rischio predominante rispetto alle altre, quali
ad esempio MaxIncrement con look-ahead 2, poiché nel caso specifico la sequenza di
attacchi selezionata dalla strategia presenta una probabilità di successo circa 3 volte
superiore alle altre.
65
5.3.3.2 Minaccia 2

Obiettivo: ADMIN DB2 or READ/WRITE DB1
SubnFirst
MaxIncr 1 MaxIncr 2
MaxProb 1
MaxProb 2
MaxEff
N. Piani
4181
4
2
40
8
64
N. Passi
37
34
20
28
20
24
N. Host
3
3
2
3
2
3
In questo caso la minaccia ha un obiettivo non raggiungibile direttamente dall’esterno,
pertanto il numero minimo di host che deve attaccare per raggiungere il suo obiettivo è
sicuramente maggiore o uguale a 2. Ad esempio, il primo host è sempre necessario per
entrare all’interno del sistema. La strategia Subnet First, vista la selezione meno
intelligente degli attacchi da effettuare, genera un numero di piani di gran lunga
superiore a quello delle altre minacce. Questo comportamento è dovuto al fatto che,
una volta che la minaccia è entrata all’interno del sistema, non è in grado di vedere
immediatamente il suo obiettivo. In questo caso l’insieme degli attacchi fra cui deve
scegliere è molto grande a causa della dimensione del sistema.
Figura 5.8 Curve di stress della Minaccia 2
66
Le curve di stress mostrano come la minaccia sia in grado di raggiungere il suo obiettivo
dopo circa 48 ore. Le strategie che garantiscono una probabilità di successo superiore
sono la MaxProbability e la MaxIncrement con look-ahead 2, mentre la strategia
Random risulta essere la peggiore.
Ad esempio, dopo 10 ore di attacchi la minaccia più potente è migliore di circa il 30%
rispetto alla peggiore.
67
5.3.3.3 Minaccia 3

Obiettivo: ADMIN SW + DB1 + DB2
SubnFirst
MaxIncr 1 MaxIncr 2
MaxProb 1
MaxProb 2
MaxEff
N. Piani
2972
48
24
981
1005
12
N. Passi
45
44
44
42
35
26
N. Host
3
5
4
3
3
3
La tabella della minaccia 3 mostra un numero di piani superiore rispetto a quelli delle
minacce precedenti. Il comportamento è dovuto alla definizione dell’obiettivo, che
prevede l’acquisizione di diritti di tipo amministratore nei confronti di 3 componenti
distinti. Invece, le minacce precedenti prevedevano l’acquisizione di diritti su 1 o al
massimo 2 componenti. Le possibili combinazioni di attacchi che la minaccia ha a
disposizione risultano dunque superiori.
Figura 5.9 Curve di stress della minaccia 3
Le curve di stress evidenziano come la minaccia possa raggiungere i suoi obiettivi dopo
circa 60 ore di attacchi. La strategia che converge più velocemente ad uno stress uguale
a 1 è la MaxEfficiency poiché, confrontata con le altre strategie, seleziona la
combinazione di attacchi più efficiente per guadagnare i diritti sui 3 componenti.
68
5.3.3.4 Minaccia 4
 Punto di partenza: Insider

Obiettivo: ADMIN SW or DOS SW
SubnFirst
MaxIncr 1 MaxIncr 2
MaxProb 1
MaxProb 2
MaxEff
N. Piani
4
1
1
2
1
2
N. Passi
5
18
14
5
14
5
N. Host
1
1
1
1
1
1
La minaccia 4, come la minaccia 1, nella maggior parte delle simulazioni cerca di
raggiungere l’obiettivo attaccando un solo host. La ragione di questa scelta è dovuta alla
struttura della rete dei Reparti A e B che, per facilitare il lavoro di sviluppo e test,
consentono l’accesso diretto ai vari compartimenti. Poiché i computer dei dipendenti
possono raggiungere tutte le sottoreti dell’infrastruttura, essi hanno una visione
immediata del loro obiettivo, e cercano di prenderne il controllo in maniera diretta.
Le curve di stress evidenziano come la minaccia 4 possa raggiungere il suo obiettivo dopo
circa 13 ore. Le strategie che possono raggiungere più velocemente l’obiettivo sono la
MaxEfficiency e la MaxProbability con look-ahead 2.
La Subnet First segue le due strategie più potenti perché spostandosi rapidamente fra le
varie sottoreti raggiunge più velocemente il suo obiettivo.
69
5.3.3.5 Minaccia 5

Obiettivo: ADMIN DB2 or READ/WRITE DB1
SubnFirst
MaxIncr 1 MaxIncr 2
MaxProb 1
MaxProb 2
MaxEff
N. Piani
4
1
1
1
2
1
N. Passi
18
14
14
14
14
14
N. Host
1
1
1
1
1
1
La tabella della minaccia 5 descrive un comportamento analogo alla minaccia 4: i diritti
iniziali della minaccia le consentono di vedere immediatamente gli host che definiscono
il suo obiettivo. Di conseguenza entrambe le minacce cercano di raggiungerlo mediante
attacchi diretti.
Le curve di stress della figura 5.11 mostrano un comportamento molto simile delle varie
minacce poiché le probabilità di successo degli attacchi per conquistare gli obiettivi sono
molto alte.
70
5.3.3.6 Minaccia 6

Obiettivo: ADMIN SW + DB1 + DB2
SubnFirst
MaxIncr 1 MaxIncr 2
MaxProb 1
MaxProb 2
MaxEff
N. Piani
657
12
12
48
48
552
N. Passi
41
25
25
93
89
97
N. Host
3
3
3
4
4
3
Come la minaccia 3, anche la minaccia 6 ha a disposizione un numero superiore di piani.
La ragione è dovuta ancora una volta alla complessità dell’obiettivo da raggiungere.
Cambiano tuttavia i diritti iniziali della minaccia che, a causa della struttura piatta della
rete Terranova, ha una visione immediata dei suoi obiettivi.
Le curve di stress mostrano come la minaccia sia in grado di raggiungere i suoi obiettivi
in circa 60 ore adottando una strategia di tipo Max Increment con look-ahead 1 e 2.
Le due strategie sono equivalenti poiché esistono sequenze di attacchi lunghe 1 che
garantiscono il massimo dei diritti con una buona percentuale di successo. Queste
sequenze vengono dunque selezionate da entrambe le strategie.
71
5.3.3.7 Confronto delle minacce
Le curve di stress mostrate nella figura 5.13 mettono a confronto la migliore strategia
per ciascuna minaccia, quella che le permette di raggiungere più velocemente il suo
obiettivo.
Figura 5.13 Confronto fra le strategie migliori
Come è possibile vedere nel grafico, la minaccia 1 raggiunge il suo obiettivo per prima
utilizzando una strategia di tipo MaxIncrement con look-ahead 1.
Segue la minaccia 2 con MaxEfficiency, mentre la più lenta risulta essere la minaccia 3
con strategia MaxEfficiency.
Come detto più volte, questo è dovuto al fatto che la minaccia 1 ha come obiettivo
l’acquisizione di diritti verso 1 solo componente, mentre la minaccia 3 e 6 devono
conquistare diritti su 3 componenti distinti.
72
5.4 Considerazioni finali
Il vulnerability scanning del sistema Terranova ha permesso di identificare un numero
elevato di vulnerabilità che affliggono l’intera infrastruttura ICT. La valutazione globale
del rischio, condotta attraverso Haruspex, ha evidenziato come in realtà solo un numero
estremamente contenuto di vulnerabilità risulti essere rilevante perché le minacce
possano raggiungere gli obiettivi stabiliti per l’assessment. Ciò può essere provato, ad
esempio, dal fatto che il numero di piani, ovvero il numero di passi ineliminabili per
raggiungere un obiettivo è estremamente più piccolo della sequenza.
L’estensione relativa all’ambiente web introdotta nel capitolo 4 ha contribuito ad
arricchire in maniera significativa gli scenari ed i cammini presi in considerazione dalle
minacce simulate.
MINACCIA
SIM. TOTALI
SIM. CON WEB
PERCENTUALE
1
300000
18982
6%
2
300000
61849
21%
3
300000
137897
46%
Tabella 5.9 Risultati con integrazione Web
La tabella 5.9 mostra alcuni numeri che consentono di quantificare l’impatto generato
nella suite con l’introduzione del modello web. Come detto in precedenza, per ciascuna
minaccia sono state eseguite 300000 simulazioni totali, 50000 per ciascuna delle 6
strategie selezionate. Nel caso della minaccia 1 è possibile vedere come in 18982
simulazioni la minaccia abbia sfruttato vulnerabilità di tipo web nella definizione dei suoi
attacchi complessi, circa il 6% delle simulazioni totali.
Il numero cresce al 21% per la minaccia 2, sino ad arrivare al 46% per la minaccia 3.
Nessun attacco web è stato invece utilizzato dalle altre 3 minacce: il comportamento è
coerente con il modello, poiché le minacce 4, 5 e 6 definiscono lo scenario di un
attaccante interno al sistema, che non necessita dunque di attaccare i servizi web
esposti verso l’esterno per guadagnare l’accesso alla rete.
73
SIM. TOTALI
SIM. CON WEB
PERCENTUALE
1800000
218728
12%
Tabella 5.10 Riepilogo simulazioni web totale
La tabella 5.10 mostra un confronto finale: su 1800000 simulazioni totali, in 218728 le
minacce hanno considerato attacchi e vulnerabilità web nella composizione degli
attacchi complessi.
Nell’analisi dei risultati non bisogna tuttavia dimenticare le semplificazioni adottate al
sistema, per le quali, contrariamente alla realtà, viene concesso come ipotesi che gli
Outsider che guadagnino l’accesso a componenti in zone DMZ riescano ad eseguire un
vulnerability scanning del software SSM e a sfruttare gli eventuali exploit disponibili.
Nella realtà le poche vulnerabilità significative rilevate hanno bisogno di elevate
competenze tecniche per poter essere sfruttate, e anche nel caso di un attaccante che
abbia le abilità necessarie le probabilità di successo restano molto basse, anche in virtù
dei sistemi di protezioni proattiva presenti nei reparti che, nel caso oggetto di studio,
sono stati volutamente disattivati o i cui alert sono stati ignorati per non interferire con
lo studio.
Lo studio ha fornito indicazioni utili a Terranova per aumentare il livello di sicurezza dei
propri sistemi, in quanto contestualmente alla rilevazione delle vulnerabilità di
medio/alto rischio, esso ha anche fornito le informazioni necessarie ad eseguire un
hardening dei sistemi e servizi afflitti eliminando di conseguenza le vulnerabilità
descritte in precedenza.
74
BIBLIOGRAFIA
[1] HP 2012 Cyber Risk Report
http://www.hpenterprisesecurity.com/collateral/whitepaper/HP2012CyberRiskReport_0213.pdf
[2] Christopher J. Alberts, Audrey J. Dorofee, “OCTAVE Criteria Version 2.0”, 2001
[3] Gary Stoneburner, Alice Goguen, Alexis Feringa, “Risk Management Guide for
Information Technology System”, NIST SP 800-30.
[4] Mitre, “CVE - Common Vulnerabilities and Exposures”
https://cve.mitre.org/
[5] NIST, “CVSS - Common Vulnerability Scoring System”
http://nvd.nist.gov/cvss.cfm
[6] Web Application Security Consortium, “WASC Threat Classification”
http://projects.webappsec.org/w/page/13246978/Threat%20Classification
[7] Mitre, “CWE - Common Weakness Enumeration”
http://cwe.mitre.org/
[8] Standard ISO 27002
http://it.wikipedia.org/wiki/ISO/IEC_27002
[9] Standard NIST 800-53
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf
[10] Mitre, “CAPEC - Common Attack Pattern Enumeration and Classification”
https://capec.mitre.org/index.html
[11] F.Baiardi, F.Corò, F.Tonelli, D.Sgandurra, “Automating the assessment of ICT Risk”,
Journal of Internet Services and Applications (JISA), Vol. 19, Iss:3, 2014
75
[12] F.Baiardi, F.Corò, F.Tonelli, A.Bertolini, R.Bertolotti, D.Pestonesi, “Assessing and
Managing ICT Risk with Partial Information”, CSS, 2014
[13] F.Baiardi, F.Corò, F.Tonelli, D.Sgandurra, “A Scenario Method to Automatically
Assess ICT Risk”, PDP, 2014
[14] F.Baiardi, F.Corò, F.Tonelli, D.Sgandurra, “Attack Plans Against ICT Infrastructures”,
ICVRAM, 2014
[15] F.Baiardi, F.Tonelli, “Haruspex: Evaluating Risk without Data”, Computer Fraud &
Security, 2014
[16] F.Baiardi, F.Tonelli, A.Bertolini, R.Bertolotti, L.Guidi, “Security Stress: Evaluating ICT
Robustness through a Monte Carlo Method”, Critis, 2014
[17] WASC Threat Classification, Buffer Overflow
http://projects.webappsec.org/w/page/13246916/Buffer%20Overflow
[18] WASC Threat Classification, Path Traversal
http://projects.webappsec.org/w/page/13246952/Path%20Traversal
[19] WASC Threat Classification, SQL Injection
http://projects.webappsec.org/w/page/13246963/SQL%20Injection
[20] Classificazione CAPEC XML + XSD
https://capec.mitre.org/data/index.html#downloads
[21] Mapping WASC -> CAPEC
http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference%
20View
[22] Mapping CAPEC -> WASC
https://capec.mitre.org/data/definitions/333.html
[23] OTRS (OpenSource Ticket Request System)
http://it.wikipedia.org/wiki/OTRS
76
[24] F.Baiardi, F.Corò, F.Tonelli, F.Muzio, L.Guidi, “Vulnerability Assessment di Sistemi
SCADA. Sperimentazione su di un sistema di automazione di impianti di generazione
elettrica”, 2011
[25] Douglas W. Hubbard, “How to Measure Anything: Finding the Values of Intangibles
in Business”, 2010
[26] H.Holm, T.Sommestad, J.Almroth, M.Persson, “A Quantitative Evaluation of
Vulnerability Scanning”, Information Management & Computer Security, Vol. 19, Iss:4,
pp.231-247, 2011
[27] Y.Y.Haimes, “On the definition of vulnerabilities in measuring risks to
infrastructures”, Risk Analysis, Vol. 26, no. 2, pp 293296, 2006
[28] C.Sarraute, "On exploit quality metrics and how to use them for automated
pentesting," in Proc. of 8.8 Computer Security Conf., 2011.
[29] C.Taylor, A.Krings, J. Alves-Foss, “Risk Analysis and Probabilistic Survivability
Assessment (RAPSA): An Assessment Approach for Power Substation Hardening”, Proc.
ACM Workshop on Scientic Aspects of Cyber Terrorism, (SACT), 2002.
[30] C.Phillips, L.P.Swiler. "A graph-based system for network-vulnerability analysis",
Proceedings of the 1998 workshop on New security paradigms, ACM, 1998.
[31] E.Jonsson, T.Olovsson. “A quantitative model of the security intrusion process
based on attacker behaviour”, Software Engineering, IEEE Transactions on 23.4 (1997):
235-245.
[32] J.Alves-Foss, S.Barbosa. “Assessing computer security vulnerability”, ACM SIGOPS
Operating Systems Review 29.3 (1995): 3-13.
[33] Y.Wang, X.Yun, Y.Zhang, S.Jin, Y.Qiao, “Research of network vulnerability analysis
based on attack capability transfer”, In: computer and IT, 2012 IEEE 12th international
conference on, pp 3844
77

Risk Assessment di ambienti applicativi: Servizi Web

Transcript

Documenti analoghi

Vulnerabilità come chiave di ricerca - Se non ora quando

controllo di sicurezza dell`infrastruttura informatica - SIQ

Servizi di sicurezza informatica

Sicurezza per i cittadini e per le imprese

Mozilla risolve per prima le vulnerabilità individuate