Risk Assessment di ambienti applicativi: Servizi...

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.

1

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

2

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

3

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

4

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

5

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

6

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.

8

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.

9

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à.

10

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

11

come punti di arrivo ma anche come un nuovo punto di partenza che permette di

eseguire nuove sequenze di attacchi.

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.

2° attacco

3° attacco 1° attacco

12

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:

13

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

14

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.

15

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:

16

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

17

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:

18

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.

19

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à.

20

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.

21

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.

22

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

23

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

24

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

25

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 add-

on, 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

26


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.

27


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

28

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.

29

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.

30

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.

31

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.

32

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.

33

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.

34

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

35

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 look-

ahead 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.

36

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.

37

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:

38

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

39

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:

40

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.

41

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

42

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.

43

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.

44

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

45

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].

46

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.

47

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.

48

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;

49

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 pre-

condizioni 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

50

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

51

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.

52

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.

53

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

54

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.

55

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.

56

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).

57

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.

58

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).

59

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.

60

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

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.

Figura 5.4 Impatto vulnerabilità Nessus

0

50

100

150

200

250

300

Critico Alto Medio Basso

Figura 5.3 Resoconto vulnerabilità Nessus

61

5.2.2.2 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.

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.

Alto Medio Basso

Figura 5.5 Resoconto vulnerabilità Owasp ZAP

62

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;

63

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

2 OUTSIDER

ADMIN DB2

or

READ/WRITE DB1

3 OUTSIDER ADMIN SW + DB1 + DB2

4 INSIDER ADMIN SW or DOS SW

5 INSIDER

ADMIN DB2

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.

64

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.

65

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.

66

5.3.3.2 Minaccia 2


Obiettivo: ADMIN DB2 or READ/WRITE DB1


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

67

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.

68

5.3.3.3 Minaccia 3


Obiettivo: ADMIN SW + DB1 + DB2


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.

69

5.3.3.4 Minaccia 4

Punto di partenza: Insider

Obiettivo: ADMIN SW or DOS SW


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.

70

5.3.3.5 Minaccia 5


Obiettivo: ADMIN DB2 or READ/WRITE DB1


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.

71

5.3.3.6 Minaccia 6


Obiettivo: ADMIN SW + DB1 + DB2


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.

72

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.

73

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.

74

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.

75

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

http://www.hpenterprisesecurity.com/collateral/whitepaper/HP2012CyberRiskReport_0213.pdf

https://cve.mitre.org/

http://nvd.nist.gov/cvss.cfm

http://projects.webappsec.org/w/page/13246978/Threat%20Classification

http://cwe.mitre.org/

http://it.wikipedia.org/wiki/ISO/IEC_27002

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf

https://capec.mitre.org/index.html

76

[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

http://projects.webappsec.org/w/page/13246916/Buffer%20Overflow

http://projects.webappsec.org/w/page/13246952/Path%20Traversal

http://projects.webappsec.org/w/page/13246963/SQL%20Injection

https://capec.mitre.org/data/index.html#downloads

http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference%20View

http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference%20View

https://capec.mitre.org/data/definitions/333.html

http://it.wikipedia.org/wiki/OTRS

77

[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

Risk Assessment di ambienti applicativi: Servizi...

Documents

Transcript of Risk Assessment di ambienti applicativi: Servizi...