E. Casalicchio
Università di Roma “Tor Vergata”
M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
Global Cyber Security Center (GSEC)
STABILITÀ, SICUREZZA E RESILIENZA DEL DNS E LORO IMPATTO SUL
CONTROLLO DELLE INFRASTRUTTURE CRITICHE
(DOmaIN Name SySTem HeaLTH)
Sommario
Oggi, sostanzialmente ogni attività umana è esposta a
minacce di sicurezza correlate all’uso inevitabile delle reti IP e
del Sistema dei Nomi di Dominio (DNS). Mentre queste due
infrastrutture mondiali hanno generalmente funzionato in
maniera affidabile e robusta per decenni, la pervasività del
DNS stesso ed il crescente numero di minacce e attacchi informatici a tale infrastruttura pongono nuove sfide ai livelli politico, di governance e tecnico. Questo articolo concentra l’attenzione sul DNS come infrastruttura critica e sulla necessità di
misurare il suo “stato di salute” (DNS Health) ed il suo
livello di sicurezza. Il contributo di questo documento è molteplice. In primo luogo, prendendo ad esempio le reti di distribuzione elettrica, si analizza l’impatto che eventuali attacchi
al sistema dei nomi di dominio avrebbero sull’operatività dei
moderni sistemi energetici. A seguire, viene fornita la descrizione di un framework per la misura dello stato di salute del
DNS (Measuring the Naming System (MeNSa) framework), sviluppato con lo scopo di ottenere una metodologia formale e strutturata, nonché metriche e tool, per la valutazione
dei livelli di Health & Security del DNS. Infine, nell’ultima
parte del documento, si propone un processo di aggregazione
delle misure, con l’obiettivo di combinare differenti metriche di
“Health & Security” in indici aggregati di valutazione.
Inoltre vengono presentati i risultati ottenuti in una campagna
di test condotta su uno scenario realistico.
1. Introduzione
La sicurezza informatica è uno dei principali problemi della società digitale. L’ormai consolidata
dipendenza dall’ICT nei processi di controllo e
gestione di infrastrutture critiche (IC) fa della cybersecurity un elemento imprescindibile per la protezione e la sicurezza dei cittadini. Oggigiorno, tali IC
(centrali elettriche, reti energetiche, oleodotti e sistemi di controllo del traffico aereo) sono esposte non
Speciale Sicurezza ICT
A bstract
Today, basically every human activity is exposed to security threats related to the inevitable use of IP networks and
the Domain Name System (DNS). While these two worldwide infrastructures have been generally operated in a reliable
and robust fashion for decades, the pervasiveness problem
above mentioned and the growing number of cyber threats and
attacks raise new challenges at political, governance and technical level. In this work we concentrate our attention on the
DNS as critical information infrastructure and on the need to
measure the health and security level perceived. The contribution of this paper is multiple: First, taking as example the
Power Grid, we analyze the impact of malicious attacks
against the Domain Name System (DNS) on the operation
of the modern Energy system. Secondly, we provide a description of the Measuring the Naming System (MeNSa) framework designed to provide a formal and structured methodology,
metrics and tools for the measurement of DNS health and
security level. Finally we propose an aggregation process to
combine different health and security metrics in aggregated
indexes and we present the results obtained from a measurement campaign conducted in a real scenario.
solo ai tradizionali problemi di sicurezza ed affidabilità ma anche e soprattutto a nuove minacce legate
all’utilizzo che queste fanno delle reti IP e del DNS.
Nonostante queste due infrastrutture globali abbiano
funzionato per decadi in maniera affidabile e resiliente vi sono costantemente nuove sfide da un
punto di vista operazionale, politico e di governance
causate della diffusione e del sempre crescente
numero di minacce ed attacchi informatici.
In questo lavoro concentreremo l’attenzione su
81
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
come il livello di sicurezza stabilità e resilienza del
DNS impatta la sicurezza e resilienza delle IC.
analizzeremo quindi gli effetti che, un potenziale
attacco al DNS potrebbe produrre sul controllo dell’infrastruttura elettrica. In particolare considereremo
le principali vulnerabilità ed i principali scenari di
attacco.
Nonostante il DNS sia stato recentemente riconosciuto, a tutti gli effetti, un’infrastruttura critica [1]
ed abbia acquisito popolarità in risposta alle vulnerabilità riscontrate di recente ed alla conseguente pubblicità dovuta all’adozione del DNSSeC, non esiste
una definizione condivisa del concetto di stabilità
(Stability), sicurezza (Security) e resilienza
(Resiliency) del DNS (di seguito denotata con SSR)
né vi è alcun accordo su un framework per la misurazione di queste caratteristiche. Inoltre, non esistono, allo stato attuale, delle linee guida da seguire nel
caso si debba gestire una crisi o scenari di cyber-warfare.
In questo articolo, prendendo come esempio
guida i sistemi energetici, mostreremo come il DNS
è un sistema critico da cui dipende il corretto funzionamento di molte altre infrastrutture.
Inoltre, presenteremo un’iniziativa coordinata a
livello internazionale, il progetto meNSa1, finanziato
da GCSeC, per lo sviluppo di un framework per la
valutazione del livello di salute e sicurezza del DNS
(DNS Health & Security – DNS H&S). Il progetto
meNSa propone di realizzare un framework di metriche e misure, che sia aperto e concepito per rispondere ai bisogni di quegli attori direttamente o indirettamente influenzati dal funzionamento del DNS. Le
metodologie proposte potranno intervenire nelle
azioni di definizione di policy e piani di gestione e
controllo degli incidenti ed inoltre permetteranno di
rafforzare la sicurezza e la resilienza del DNS attraverso una gestione proattiva delle sue operazioni.
Infine, mostreremo mediante una serie di esperimenti come è possibile aggregare varie metriche, atte
a misurare caratteristiche specifiche del DNS, per
ottenere degli indicatori unici che quantifichino il
livello di health e security percepito. I risultati sperimentali sono stati ottenuti considerando un caso specifico, quello di un end-user che accede, mediante un
browser, a risorse (contenuti), distribuiti sulla rete
internet. Come vedremo nel seguito, vi sono una
serie di operazioni per la gestione delle infrastrutture
critiche che rientrano in questo scenario, mentre altre
operazioni richiederebbero di effettuare delle misure
nel caso specifico, ossia accedendo direttamente alle
risorse di un’infrastruttura critica, cosa che ancora
non è stata possibile. La metodologia prodotta si è
comunque dimostrata estendibile al caso appena
menzionato.
Il lavoro è organizzato come segue. La Sezione 2
introduce i concetti di DNS Health, Vulnerabilità,
minacce che saranno usati man mano. La Sezione 3
descrive i sistemi energetici presentando le dipendenze che questi ultimi hanno nei confronti del
DNS. In questa sede si discute anche dell’importanza di un DNS sicuro e performante dal punto di vista
degli amministratori delle IC. La Sezione 4 descrive
nel dettaglio il framework meNSa elencandone i concetti di base e le fasi operative mentre nella Sezione 5
concentriamo l’attenzione sui metodi di aggregazione dati. Infine, nella Sezione 6 vengono mostrati i
primi esperimenti effettuati e come sia stato possibile validare le metodologie.
2. DNS Health, Vulnerabilità e Minacce
Per decenni, il DNS ha funzionato in maniera
generalmente affidabile. Nonostante questo, negli
ultimi anni è stato posto sotto i riflettori il concetto
di DNS Security, Stability e Resiliency. mentre vi
sono numerosi studi su tecniche di monitoraggio del
traffico DNS e su eventuali metodologie di misurazione delle perfomance ([2], [3], [4], [5]) ancora non
sono definite metriche che chiariscano il significato
di DNS SSR. allo stesso modo non sono stati tuttora descritti mezzi per valutare l’impatto che eventuali cambiamenti dovuti all’incremento del numero di
query o a modifiche nelle tecnologie (come nel caso
del DNSSeC) abbiano sul funzionamento del DNS.
Il lavoro condotto dall’Internet Corporation for
assigned Names and Numbers (ICaNN) ([6], [7]) ha
fornito una visione ad alto livello della nozione di
DNS Health: un concetto ampio che include perfomance, stabilità, resilienza ma che non considera
direttamente quello di sicurezza.
Quanto segue è una proposta di revisione delle
definizioni degli indicatori di DNS Health proposti
in [6] e [7].
• Availability – è definito come il grado con cui
un componente o l’intero sistema è operativo
ed accessibile all’utilizzo. In questo caso,
1 The meNSa project, http://www.gcsec.org/activity/research/dns-security-and-stability
82
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
•
•
•
•
•
•
l’availability può essere definita anche come
l’abilità del DNS di essere operativo ogni qualvolta riceve una richiesta.
Coherency – questo è uno dei principi fondamentali del DNS essendo, di fatto, l’abilità di
risolvere un indirizzo IP in un dato nome di
dominio e viceversa. Considerando un esempio: se l’IP 192.0.2.1 è risolto nel valore
foo.example.com il principio di coerenza
implica che il nome foo.example.com sia risolto nell’IP originale, ovvero 192.0.2.1. La
Coherency è legata in gran parte ai dati mantenuti nelle cache locali e nelle risorse condivise.
Integrity – è l’abilità del DNS di proteggersi
contro modifiche o cancellazioni improprie
delle informazioni ed include elementi collegati alla possibilità di garantire il non-ripudio
e l’autenticità dei dati.
Resiliency – è l’abilità del DNS di rispondere e
ritornare in uno stato consentito e sicuro
all’occorrere di eventuali interruzioni di servizio. (es. attacchi DoS distribuiti). La
Resiliency è percepita dagli utenti come
availability mentre dai Provider come somma
dei processi di individuazione, risposta e recupero da eventuali problemi. Inoltre, la resiliency è una proprietà che può aumentare la
fiducia degli utenti ad investire, a lungo termine, nei servizi Internet. La Resiliency può
essere intesa anche come l’abilità del DNS di
fornire e mantenere un livello di servizio adeguato a fronte di guasti.
Security – è l’abilità del DNS di limitare o proteggersi da attività malevole (es. accessi non
autorizzati al sistema, rappresentazione fraudolenta delle identità, intercettazione delle
comunicazioni). anche la Security può contribuire ad aumentare la fiducia degli utenti nel
DNS.
Speed – è legata alle performance del DNS in
termini di tempi di risposta (es. periodo di
tempo impiegato tra l’invio di una
richiesta/query e l’arrivo di un responso) e
throughput (es. quantità di istruzioni, query o
operazioni processate nell’unità di tempo). La
Speed non è di interesse solo per l’utente finale ma può essere inerente anche alle operazioni di gestione ed amministrazione del DNS.
Stability – è l’abilità del DNS di funzionare in
maniera affidabile e prevedibile giorno per
Speciale Sicurezza ICT
giorno (es. standard e protocolli). La Stability
può facilitare la percezione del DNS come
sistema adeguato al soddisfacimento requisiti
imposti ed il suo uso.
La salute del DNS può essere compromessa in
diversi modi considerando la relazione che questi
hanno con tutte quelle vulnerabilità che è possibile
sfruttare. Per questo motivo, gli indicatori di Health
hanno senso se considerati in relazione alle minacce
e alle vulnerabilità stesse. Le problematiche relative al
sistema dei nomi di dominio possono essere generalmente classificate in tre categorie principali [8]: Data
corruption, Denial of Service e Privacy.
• La Data Corruption è definita come l’insieme
dei problemi relativi alla modifica non autorizzata dei dati propri del DNS. Tali problemi
possono sorgere in ogni momento ed in ogni
parte della catena di propagazione dei messaggi DNS. Nel documento considereremo la
Data Corruption divisa in tre sotto-classi [8]:
◦ Repository Corruption - Il repository rappresenta quell’elemento del sistema in cui
sono memorizzati e conservati i dati. Nel
DNS il repository è la fonte autorevole per
le informazioni di una determinata zona.
◦ System Corruption - L’autenticità delle risposte del DNS dipende fortemente dalla
fiducia che si ha verso l’intera catena dei
sistemi nella parte più rilevante della gerarchia/albero del DNS. Per natura stessa
dell’architettura del DNS non tutti questi
sistemi sono sotto il controllo della medesima entità. Questo rende difficile (quasi
impossibile) per il possessore dei dati assicurare l’autenticità degli stessi al client che
li abbia ricevuti. un esempio di system
corruption è la modifica non autorizzata
delle risposte alle query DNS di un utente.
◦ Protocol Issues - Questa categoria di attacchi
tratta le falle di sicurezza riguardanti i protocolli del DNS. alcuni esempi sono il
cache poisoning, la route-injection e le
minacce del tipo man-in-the-middle.
La Data Corruption influenza in maniera
diretta la coerenza e l’integrità di una porzione o dell’intero DNS e, come conseguenza, ha
un impatto anche sulla resilienza del sistema.
• un attacco di Denial of Service viene sferrato
per rendere il servizio inutilizzabile ai sui utenti. Questi attacchi usualmente possono avere
come obiettivo uno specifico servizio (ad
83
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
esempio il DNS) o una porzione più ampia
della rete (ad esempio Internet). Per questo
motivo distinguiamo gli attacchi DoS distribuiti (DDoS) portati contro i server DNS da
quelli relativi alle infrastrutture di rete.
attacchi DoS e DDoS possono essere eseguiti con tecniche differenti e possono avere
effetti su Speed, availability e Resiliency dell’intero DNS o di una sua parte.
• Gli attacchi al DNS non sono solo una questione di sicurezza ma spesso riguardano
anche la privacy. molti attacchi infatti permettono, al malintenzionato, di entrare in possesso dei “DNS data”. Il cache snooping e lo
NSeC walk sono esempi di minacce legate alla
privacy. attualmente la privacy non è considerata parte della DNS Health ma una discussione sull’argomento andrebbe iniziata.
Riassumendo, una classificazione ad alto livello
dell’impatto di minacce e vulnerabilità sul livello di
Health del DNS è la seguente:
• La Data Corruption si ripercuote direttamente sulla coerenza e sull’integrità di una parte
del DNS e, come conseguenza, può avere un
impatto sulla Resiliency.
• attacchi DoS o DDoS possono essere eseguiti con tecniche differenti e possono ripercuotersi su Speed, availability e Resiliency dell’intero DNS o di una sua parte.
Come precedentemente affermato, la privacy non
è considerata rilevante per la DNS Health.
Nella Tabella 1 viene riassunta la relazione tra
minacce ed indicatori di Health. È possibile osservare come la Coherency e l’Integrity siano legati ad
aspetti di Data Corruption mentre Speed e
availability siano relativi a problematiche di DoS e
DDoS. La Resiliency, essendo collegata alla capacità
di mantenere, o recuperare, un certo livello di servizio è influenzata sia dalla Data Corruption che da
elementi di DoS/DDoS. anche la Vulnerability è
collegata a tutte le categorie di minaccia essendo intesa come la probabilità che un problema del DNS,
Categoria di Minaccia
Data Corruption
DoS e DDoS
Privacy
84
derivante appunto da una certa vulnerabilità, si palesi.
3. DNS Impact on CI, the Energy System
Use Case
Come affermato nell’introduzione, il DNS viene
usato, in maniera ubiquita, in molte operazioni per la
gestione ed il controllo delle infrastrutture critiche.
In questa sezione, dopo una breve descrizione ad alto
livello dei sistemi energetici, mostreremo come il
DNS è coinvolto in queste operazioni.
3.1 Panoramica sui sistemi energetici
I sistemi energetici comprendono un elevato
numero di sotto-sistemi, ognuno con compito differente, che insieme collaborano per garantire il corretto funzionamento di infrastrutture trans-nazionali e
fornire così energia a centinaia di milioni di persone.
Nel seguito di questa sezione forniremo una descrizione ad alto livello di tutti questi elementi e delle
dinamiche di maggior importanza.
Il livello fisico di un sistema di alimentazione elettrica è costituito dall’hardware di rete: stazioni, collegamenti, trasformatori e interruttori. Le strategie di
controllo per il mantenimento operativo del sistema
di trasmissione sono trasferite ai sistemi fisici attraverso periferiche e centri ICT per il controllo ed il
monitoraggio delle informazioni (il cosiddetto livello
informatico del sistema). Nel livello fisico è possibile
classificare gli elementi costitutivi di un sistema di alimentazione elettrica in:
• Stazioni di Trasmissione: generalmente gestite
direttamente dai Trasmission System
Operator (TSO).
• Centrali di alimentazione: usualmente di proprietà di varie compagnie.
• alimentatori del Sistema di Distribuzione, che
costituiscono l’origine del sistema di distribuzione di medio voltaggio. Ogni Distribution
Tipo di Minaccia
Indice di Health
Cache Poisoning, Coherency,
modifica di query o risposta
Integrity, Resiliency,Vulnerability
Cache Snooping
Vulnerability
(contro i) DNS Server, (contro le)
Infrastrutture di Rete
Speed, availability, Resiliency,
Vulnerability
Tabella 1: Relazione tra minacce di sicurezza e indici di Health influenzabili.
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
System Operator (DSO) possiede e gestisce il
monopolio del sistema di distribuzione su una
certa porzione del territorio.
• utilizzatori massivi: utenti del sistema energetico ad alto consumo (>5mW).
• utenti finali: connessi ai bus di distribuzione e
costituenti le foglie del sistema energetico.
Con l’avvento delle smart-grid in cui ogni utente
può diventare esso stesso produttore di energia
ovviamente questa classificazione subirà delle modifiche.
Per mantenere l’operatività, un sistema così complesso necessita un considerevole scambio di informazioni (dati real-time, ma anche commerciali ed
amministrativi) tra i centri di controllo e le sotto-stazioni ma anche tra i vari operatori. Il sistema informativo di una rete energetica è composto da differenti sotto-sistemi:
• La rete di controllo: contiene tutte le Remote
Terminal unit (RTu) ed i Programmable
Logic Controller (PLC). essa si interfaccia
direttamente con la rete di campo ovvero la
rete degli attuatori e dei sensori che fisicamente svolgono i task di processo nel sistema.
Inoltre essa è connessa con la rete di processo
(descritta nel seguito).
• La rete di processo: è composta dai server
SCaDa e da tutti quei sistemi che si occupano della raccolta dei dati in arrivo dalla rete di
controllo. È la rete di processo che invia
comandi e istruzioni alla rete di controllo.
• area di scambio: usualmente contiene i database di aggregazione che ricevono i dati dalla
rete di processo. Questi dati rappresentano lo
stato operativo del sistema e sono utilizzati
dagli apparati diagnostici, contenuti nell’area
stessa, per individuare anomalie. Gli operatori
dei centri di controllo accedono in remoto a
questi database per avere una panoramica ad
alto livello dello stato di processo.
• Centri di controllo: sono utilizzati dagli operatori per ottenere informazioni sui processi e
per eseguire sequenze di operazioni per la
modifica dello stato di processo (mediante la
rete di controllo).
Questa panoramica del sistema deve essere intesa
come multi-livello, ossia alcune di queste infrastrutture, di proprietà di aziende differenti, interagiscono
sovrapponendosi l’una con l’altra su varie prospettive.
a questo punto è evidente come, nell’architettura
Speciale Sicurezza ICT
appena descritta le reti ICT giochino un ruolo
importante implementando, di fatto, le interconnessioni di sistema.
facendo riferimento alla documentazione scientifica ed operativa scopriamo che, in questo contesto,
viene rivolta pochissima attenzione al ruolo del sistema dei nomi di dominio. Per capire il grado di coinvolgimento dell’infrastruttura del DNS nelle operazioni di un sistema di alimentazione elettrica, dobbiamo guardare ad esso considerando due diverse
prospettive: la “infrastruttura di alto livello” e la
“infrastruttura di basso livello”. Per ognuna di esse,
abbiamo identificato un insieme di classi di operazioni (tipiche della rete di distribuzione elettrica) ed
alcune classi di vulnerabilità tradizionalmente associate al DNS: Repository Corruption, System
Corruption, Protocol Issues, Denial of Service ed
Information exposure. Sulla base di queste categorie
abbiamo infine fatto delle ipotesi sugli effetti che un
problema del DNS potrebbe avere sul sistema energetico.
3.2 Il DNS e l’infrastruttura di alto livello di
un sistema di alimentazione elettrica
Possiamo definire infrastruttura di alto livello dell’impianto di alimentazione elettrica quella parte del
sistema utilizzata per le operazione dette di alto livello, ossia:
1. Gestione del mercato dell’energia.
2. Collegamento tra i rappresentanti dell’industria e gli utenti.
3. azioni presso le sedi dei clienti.
4. Collegamenti tra il settore energetico e i rappresentanti dell’industria.
5. Coordinamento tra i produttori di energia.
6. Coordinamento tra le aziende per la trasmissione dell’energia.
7. Gestione di crisi/blackout.
Ognuna di queste operazioni funzionali coinvolge in qualche modo il DNS. Nel seguito forniamo
una panoramica sul suo ruolo e sugli effetti di un
eventuale guasto.
3.2.1 Gestione del mercato energetico
Questa sezione include le interazioni tra i rappresentanti dell’industria, i mediatori, il mercato all'ingrosso e la camera di compensazione del mercato.
Queste operazioni fanno uso di strumenti di
comunicazione e cooperazione, workflow manage-
85
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
ment ed applicazioni distribuite in genere. Tutte queste applicazioni fanno spesso uso di tecnologie web
e sono estremamente dipendenti dal corretto funzionamento del DNS. È evidente dunque come il DNS
possa avere un impatto diretto sulla disponibilità e
sulla stabilità del mercato energetico considerando
l’eventuale possibilità di causare gravi danni finanziari.
Con riferimento alle quattro categorie di vulnerabilità associate al DNS descriviamo brevemente alcuni scenari di minaccia:
• Repository Corruption: una DNS Repository
Corruption (ad esempio una modifica non
autorizzata nei database autorevoli o di
caching) può essere parte di un attacco più
complesso che abbia lo scopo di reindirizzare
parte dei flussi del mercato energetico verso
server compromessi, così da alterare la percezione sugli andamenti di mercato. In altri scenari, questo potrebbe avere un impatto anche
sulla produzione dell’energia. Si consideri ad
esempio il caso in cui un produttore compri
delle azioni; in una situazione dove questo sia
fatto attraverso server dedicati, l’accesso a
macchine compromesse potrebbe essere l’effetto di un DNS Repository Corruption. Il
risultato di queste operazioni potrebbe avere a
livello nazionale o, ancor peggio, a livello continentale ripercussioni sul piano economico e
sociale (si pensi ad una situazione dove un’eventuale carenza energetica forzi le reti a spegnersi o a interrompere l’erogazione).
• System Corruption e Protocol Issues: In questi due
ambiti sono valide le stesse considerazioni
fatte nel caso precedente.
• Denial of Service: un DNS DoS potrebbe esser
causa dell’irraggiungibilità delle infrastrutture
di rete del mercato energetico. L’impatto di
questo attacco, evidente nell’immediato,
sarebbe comunque limitato, dato che per un
certo lasso di tempo, ogni operatore del mercato energetico sarebbe in grado di lavorare
senza il bisogno di accedere ai servizi. È
comunque vero che in alcuni casi particolari
(es. durante inaspettati picchi della richiesta di
energia o in situazioni similari), l’indisponibilità del mercato energetico potrebbe causare
danni difficilmente prevedibili.
• Information Exposure: gli attacchi al DNS che
hanno lo scopo di violare la confidenzialità
dell’infrastruttura potrebbero essere parte di
86
attacchi più complessi (per esempio quelli con
l’obiettivo di corrompere delle cache del
DNS). Il danno immediato in questo caso è
praticamente nullo ma, se consideriamo una
“visione d’insieme”, sapere come certi nodi
del DNS coinvolti nelle operazioni del mercato energetico siano configurati potrebbe essere un’informazione molto utile a potenziali
attaccanti.
3.2.2 Collegamenti tra i rappresentanti dell’industria e gli
utenti finali
Questa operazione logica si riferisce alle fasi di
comunicazione tra le società del settore energetico e
gli utenti finali inclusi contatori, interfacce per la fatturazione dei servizi energetici, aggregatori di fornitori di energia al dettaglio e fornitori dei servizi energetici.
In quest’ambito, un esempio in cui il DNS
potrebbe essere usato riguarda il contesto degli
Smart meter: esistono già diversi esempi di infrastrutture di misura composte da un misto di tecnologie GPRS e canali TCP/IP classici. Normalmente la
comunicazione è “GPRS based” dal contatore al
centro di aggregazione locale e “IP based” da quest’ultimo ai server della piattaforma energetica. Con
riferimento alla parte IP dell’architettura di controllo
ed acquisizione dati, ogni attacco al DNS può avere
impatto notevole su servizi come: spegnimento o
avvio remoto dell’alimentazione per un certo cliente,
alterazione delle statistiche sul consumo energetico,
disabilitazione del servizio, interruzione nel rilevamento dati, utilizzo non autorizzato dell’elettricità,
alterazione della massima quantità di elettricità che
un cliente può richiedere, alterazione remota del
piano di fatturazione dei contatori.
esistono già applicazioni “mobile” che permettono ai clienti di controllare in remoto il consumo
energetico di casa; anche in questo caso è probabile
che il DNS sia utilizzato per rendere il servizio accessibile ovunque. allo stesso modo, i servizi di fatturazione, un altro esempio di Web application, fanno
uso del DNS per rendere accessibili da parte degli
utenti i server di frontend e i servizi di pagamento.
In questo caso DNS Repository Corruption,
DNS System Corruption e Protocol Issues possono
essere usati in diversi scenari come parte di un attacco più complesso:
• La cache DNS può essere modificata così da
rendere possibile, in un punto del percorso
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
che va dai contatori ai server di aggregazione,
il reindirizzamento del traffico su un server
contraffatto. allo stesso modo le categorie di
vulnerabilità possono essere utilizzate in uno
scenario in cui sia coinvolto il processo di fatturazione o, nel caso di produzione di energia
da parte di un utente finale, adottate in un
attacco che abbia lo scopo di alterare i valori
di produzione di tali utenti. Il danno in questa
situazione sarebbe prettamente economico
ma, fortunatamente, non avrebbe alcun
impatto su infrastrutture fondamentali.
• Denial of Service: un DNS DoS potrebbe interferire nel controllo e nel processo di fatturazione. ancora una volta parliamo di danni
prettamente economici.
• Information Exposure: come nel caso precedente, il danno immediato è quasi nullo ma, considerata una “visione d’insieme”, lo scenario
potrebbe essere sicuramente quello di uno
step intermedio che conduca ad altri attacchi.
3.2.3 Azioni presso le sedi dei clienti
In questo contesto consideriamo operazioni
come la gestione di elettrodomestici, veicoli elettrici,
altri servizi relativi (misurazione del consumo di
acqua/gas), domotica, ecc.
Queste operazioni cadono, da un punto di vista
tecnico, nella stessa categoria di quelle precedenti e,
per questa ragione, il DNS, a seconda dall’architettura di comunicazione utilizzata, potrebbe avere un
ruolo rilevante.
3.2.4 Collegamenti tra il settore energetico e i rappresentanti dell’industria
Per mantenere operativo il nucleo fondamentale
dell’infrastruttura (centrali di alimentazione, centri di
trasmissione, ecc.) le aziende del settore energetico
sono strettamente legate ai produttori di dispositivi
per l’alimentazione. È abbastanza comune che i produttori di dispositivi forniscano un supporto per la
manutenzione remota. Questa attività è normalmente svolta attraverso l’implementazione di una connessione VPN (attraverso Internet) dalla sede del
produttore di dispositivi fino alla società elettrica,
l’installazione di una sotto-rete, ed infine concedendo la possibilità di eseguire operazioni remote sul
sistema di controllo del processo locale. In questo
caso, il DNS è coinvolto nella risoluzione dei nomi
Speciale Sicurezza ICT
dei server utilizzati e ogni indisponibilità, modifica
malevola o problema potrebbe prevenire un’operazione di manutenzione necessaria all’impianto fisico.
Quando viene stabilito un tunnel VPN da base a
base, il processo di risoluzione dei nomi per i server
interni viene eseguito attraverso i due sistemi DNS
che agiscono da entrambe le parti. errori di configurazione, modifiche malevole interne o problemi di
indisponibilità nella sede del produttore o in quella
dell’azienda elettrica influiscono inevitabilmente
sulla sicurezza dell’intero sistema, con la conseguenza che il flusso di operazioni possa essere ridiretto
verso server contraffatti o che sia prevenuto del
tutto.
È importante anche porre in evidenza che il DNS
può essere usato sia per facilitare la diffusione di
infezioni (es. ridirigendo trasparentemente le richieste degli utenti verso siti contraffatti e conseguentemente innescando l’installazione di codice malevolo
che produca, una volta in azione, danni concreti) sia
come attuatore di infezione (per esempio intervenendo direttamente sulla disponibilità dei servizi
della sotto-rete dell’azienda di installazione).
3.2.5 Coordinazione tra i produttori di energia
In questa categoria di operazioni consideriamo:
• La coordinazione tra le società elettriche, relazionata soprattutto alla quantità di energia che
debba essere prodotta. Tale coordinazione fa
sempre maggior uso di Internet. Di conseguenza, l’impatto del DNS su queste operazioni dovrebbe essere considerato alto, tenendo conto che, ad esempio, le società elettriche
potrebbero non essere in grado di comunicarsi in maniera adeguata piani di produzione
energetica.
• La coordinazione tra le società di trasmissione: anche in questo caso sono valide le considerazioni fatte al punto precedente.
• Gestione di crisi/blackout: tradizionalmente
la coordinazione tra gli attori del settore energetico durante una crisi (es. durante un blackout) è ben strutturata e definita da un insieme di linee di condotta operative. L’uso della
rete pubblica, sistemi di posta elettronica, ed
altre applicazioni per coordinare le azioni
durante una crisi energetica è in crescita.
anche in questo caso il DNS sarebbe coinvolto. Infatti l’impatto di Repository Corruption,
System Corruption e DoS nel sistema dei
87
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
nomi di dominio è potenzialmente molto
grave. un ritardo nella coordinazione di un’emergenza blackout può portare a situazioni
drammatiche in cui intere nazioni sono lasciate senza elettricità. Tutto ciò può essere considerato, a questo livello, come l’azione di maggior rilevanza in termini di impatto sulla vita
delle persone.
3.2.6 Considerazioni finali
essenzialmente, tutte le operazioni di alto livello
che riguardano l’infrastruttura di alimentazione, si
affidano a servizi web/applicazioni che fanno uso
della rete Internet per lo scambio di informazioni,
per la realizzazione di transazioni e per la fornitura di
servizi. In tutte queste categorie, il DNS gioca un
ruolo rilevante. un guasto o una compromissione del
DNS potrebbe avere un impatto drammatico, per
esempio intevenendo sui prezzi o sulla disponibilità
del mercato energetico. In maniera simile, durante la
gestione di una crisi energetica (ad esempio col
rischio di un blackout), se il DNS subisce un guasto,
può accadere che questo si ripercuota sui centri di
controllo di alto livello adibiti al collezionamento di
dati e, indirettamente, causi un rallentamento nella
definizione di un piano di contingenza. La coordinazione tra i produttori di elettricità è necessaria per
garantire la stabilità della rete energetica. un guasto
del DNS potrebbe compromettere questo processo.
3.3 Il DNS e l’infrastruttura di basso livello
dei sistemi di alimentazione elettrica
Nei primi anni ‘90 i sistemi per il controllo dell’alimentazione elettrica erano costruiti come ambienti
completamente isolati. Il controllo della rete di
campo era basato su protocolli di comunicazione
seriale ed ogni cosa era monitorata e gestita localmente. Con il crescente utilizzo del TCP/IP, gli ingegneri di processo decisero di trasferire tutti i protocolli seriali industriali sul TCP/IP (incorporandoli
usualmente nel livello applicazione della suite
TCP/IP). Oggigiorno, praticamente ogni elemento
attivo nei moderni sistemi di controllo del settore
energetico è associato ad un indirizzo IP. alcuni studi
condotti in questo campo (per esempio [7]) hanno
mostrato come stia diventando sempre più comune
per i sistemi di alimentazione elettrica affidarsi al
DNS per la identificazione dei server coinvolti nel
processo di controllo. Di seguito sono proposti alcu-
88
ni esempi di comuni operazioni in cui il DNS
dovrebbe essere coinvolto e delle ipotesi sugli effetti
che un guasto al DNS avrebbe nel corso di queste
attività.
3.3.1 Operazioni di manutenzione
Centrali elettriche, sotto-stazioni di trasmissione
ed altri elementi dei sistemi di alimentazione elettrica
richiedono costante manutenzione. Tali attività sono
tipicamente appaltate a società esterne che eseguono
varie operazioni per via remota, utilizzando quindi
connessioni di rete basate su protocollo TCP/IP o su
altre tecnologie. La procedura standard consiste nel:
1. Stabilire una connessione VPN da base a base
tra la rete della società esterna e quella del proprietario della centrale.
2. accedere al dominio della società elettrica
attraverso un’autenticazione di tipo RaDIuS.
3. accedere alla sotto-rete dell’impianto
4. eseguire l’operazione di manutenzione richiesta.
Per risolvere gli indirizzi dei server coinvolti nel
processo, siano essi appartenenti a zone pubbliche o
private, viene normalmente utilizzato il protocollo
DNS. Quindi, un guasto nel DNS (privato o pubblico) durante queste operazioni potrebbe avere un
impatto sulla sicurezza e sulla stabilità del sistema di
alimentazione elettrico. Repository Corruption e
Protocol Issues (che permetterebbero ad esempio di
generare del cache poisoning) possono essere usati
come elementi di attacchi più complessi con lo scopo
di reindirizzare il flusso di operazioni di manutenzione esistente tra la base del produttore di dispositivi e
il centro ove risiede la rete locale della centrale. un
DNS DoS può essere utilizzato per rendere difficoltoso il settaggio di una connessione tra il sito remoto e quello ove risiedono i server su cui eseguire le
operazioni di manutenzione.
La finalità di questi attacchi può essere considerata duplice:
1. Generare un problema nel sistema reale,
mascherandolo all’operatore mostrando informazioni corrette.
2. evitare l’esecuzione corretta di un’operazione
di manutenzione.
In entrambi i casi l’impatto sull’impianto potrebbe essere estremamente grave. Quando si tratta di
dispositivi critici come turbine a gas, linee ad alto voltaggio o, nel peggiore dei casi, centrali nucleari, una
mancata operazione di manutenzione potrebbe avere
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
effetti drammatici.
3.3.2 Interazioni nella rete di processo
La rete di processo contiene tutti i server che
controllano i processi industriali (es. produzione di
energia, trasmissione di energia, ecc.). È abbastanza
comune affidarsi ad un DNS interno per la risoluzione dei nomi dei server. In questo caso, un guasto
sul DNS potrebbe avere impatto sull’individuazione
delle anomalie nella rete di processo di un sistema di
alimentazione elettrico o anche sulle capacità di controllo dei server SCaDa. Nel primo caso un’anomalia sfuggita alla ricerca (per esempio una variazione
nella rotazione di una turbina a gas) potrebbe causare danni fisici al sistema o un blocco forzato dello
stesso (questo sarebbe un problema economicamente costoso considerato che in media una centrale
elettrica costa circa 2 milioni di euro al giorno). Nel
secondo caso, perdere la capacità di controllare i server SCaDa potrebbe rendere impossibile una reazione sufficientemente rapida alla transizione del
sistema in uno stato critico.
3.3.3 Monitoraggio degli operatori
Il personale operativo usa le Human-machine
Interface (HmI) per il monitoraggio delle attività di
un sistema di processo. Per eseguire questo compito,
di solito essi accedono ai server, contenuti nella rete
di scambio, mantenenti la cronologia delle operazioni. Più raramente, essi accedono direttamente ai server SCaDa. Il trend di accesso ai server ed ai servizi attraverso l’utilizzo dei nomi al posto degli indirizzi IP è in crescita. Inoltre, in diverse situazioni, queste attività sono eseguite per via remota nel senso più
ampio del termine; come ad esempio da operatori
ubicati in luoghi completamente differenti che utilizzino una rete esterna e si affidino ad Internet per raggiungere l’access point della sotto-rete dell’impianto.
ancora una volta, proprio come nel caso delle operazioni di manutenzione, il DNS gioca un ruolo fondamentale nel rendere questa connessione possibile
e, nuovamente, un suo guasto o una modifica malevola potrebbe rendere difficile o impossibile controllare remotamente il sistema di processo.
In [8] Nai fovino et al. mostrano come un attacco di DNS poisoning possa essere utilizzato come
parte di un attacco più complesso contro una centrale turbo-gas per ridirigere l’operatore su un falso server SCaDa.
Speciale Sicurezza ICT
3.3.4 Operazioni del Centro di Controllo
I centri di controllo gestiscono simultaneamente
impianti multipli dei sistemi di alimentazione elettrica. Le varie applicazioni in esecuzione nei centri di
controllo generano flussi di richiesta/risposta dalle
HmI locali ai database remoti degli impianti e dunque ai server di diagnostica. Il DNS è ancora una
volta utilizzato per la risoluzione dei nomi degli entry
point delle sotto-reti remote ed allo stesso modo per
risolvere i nomi dei server remoti. un'altra importante funzione dei centri di controllo consiste nel distribuire i piani di produzione giornaliera con la specifica della produzione di energia, ora per ora, di ogni
centrale elettrica del sistema. Queste piani sono automaticamente consegnati ad ogni centrale usando: (a)
una rete dedicata, (b) una rete pubblica combinando
l’utilizzo di VPN o mPLS. un guasto nel DNS, in
questa situazione, potrebbe avere effetti significativi
nella definizione dei piani di reazione contro crisi
energetiche o potrebbe compromettere il piano di
produzione dell’energia stessa.
In quest’ultimo scenario, dovrebbe essere ulteriormente posta l’attenzione al ruolo del DNS come
veicolo per la disposizione di canali nascosti non filtrati con host già compromessi all’interno delle
sotto-reti delle società elettriche: il prelevamento illecito di dati dai sistemi di controllo o dalle reti di
scambio sia che si tratti di dati di misura, rapporti
sulle performance, piani operativi o raccolte di valutazioni di criticità potrebbe condurre a gravi rischi
per la sicurezza e per la continuità delle operazioni.
Tipicamente, sebbene siano isolate dalle reti pubbliche, le sotto-reti delle aziende necessitano comunque
di servizi basilari come quello della risoluzione dei
nomi di dominio e, nel momento in cui un certo host
all’interno della sotto-rete della compagnia sia già
stato compromesso, il prelevamento illecito di dati
potrebbe essere operato attraverso l’inoltro di query
DNS, che risolvano i nomi e conducano le informazioni verso un name-server sotto il controllo dell’attaccante. In questo modo, applicazioni malevole, in
esecuzione su una macchina compromessa potrebbero mandare query ad-hoc verso specifici uRL che
procurerebbero problemi per esempio nel trasferimento di dati sensibili archiviati nelle sotto-reti del
name-server dell’attaccante, senza che vi siano firewall operanti a livello applicazione o intrusion detection/prevention system che facciano attivamente il
log sul traffico HTTP sospetto. un’ispezione accurata delle query e dei responsi DNS dovrebbe essere
89
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
assicurata per mitigare questo rischio.
4. Il framework MeNSa
Il concetto di DNS Health è stato proposto, nel
2010, dalla comunità DNS-SSR, ossia da chi si occupa di SSR del DNS [7]. Definire gli indicatori vitali
del DNS è sicuramente un passo fondamentale ma,
nonostante questo, la definizione di metriche di sicurezza è a livello embrionale, mentre le metriche per la
Stabilità e Sicurezza del DNS sono ancora un territorio inesplorato. Relativamente al problema della
misura del livello di H&S del DNS vi sono una serie
di questioni aperte e di sfide che possono essere riassunte come segue:
1) Necessità di raffinare e migliorare le metriche
esistenti (e gli approcci alla misurazione) per
ciò che riguarda: Coerency, Integrity, Speed,
availability, Resiliency, Vulnerability, Security.
2) Necessità di definire nuovi indicatori per la
valutazione del livello di H&S. Tali indicatori
devono potersi adattare ai vari attori del sistema (operatori dei root server o anche di server
non-autoritativi, server cache ed open resolver, ma anche end user).
3) bisogno di progettare e raffinare appropriate
metodologie e tecniche per il calcolo degli
indicatori di DNS Health & Security.
4) Necessità di identificare delle soglie di riferimento sulle metriche stesse che consentano
alla communità del DNS di
sapere, possibilmente in anticipo, se e quando la H&S del
DNS sia compromessa.
Dare una risposta a queste esigenze concretizza la definizione di una
linea di azione globale e coerente
mirata al rafforzamento ad ogni livello
della sicurezza stabilità e resilienza del
DNS fornendo inoltre strumenti di
analisi che permettono agli utenti finali di valutare eventuali loro esposizioni
alle minacce. Il framework presentato
in questa sezione è una prima risposta
a queste esigenze.
Nel seguito descriviamo i componenti principali del framework meNSa
e le sue fasi operative. Per maggiori
dettagli si faccia riferimento ai deliverable di progetto [9], [10], [11].
90
4.1 I componenti del framework
I principali concetti alla base del framework
meNSa sono riassunti nei cinque punti che seguono:
• modello di riferimento del DNS [9]. In ogni
framework di misura è sempre necessario definire formalmente l’oggetto della misura stessa.
• Il Punto di Vista (Point-of-View o semplicemente PoV). un PoV è inteso come la prospettiva da cui un attore del sistema osserva,
usa, opera e influenza il DNS.
• Gli use Case. L’insieme dei casi d’uso descrivono i possibili utilizzi del framework in situazioni specifiche. un caso d’uso è contraddistinto da un attore primario (che rappresenta
l’utilizzatore del framework) ed eventuali attori secondari che interagiscono con esso.
• Le metriche. esse valutano i livelli di Health &
Security del DNS.
• Tecniche e tool di misura per la raccolta e l’analisi dei dati del sistema. La loro implementazione dipende da due fattori: (a) ciò che può
essere realmente misurato da un determinato
PoV; e (b) il periodo di collezionamento dati
(orizzonte temporale variabile in un intervallo
che va dalle ore ai mesi).
La figura 1, schematizza gli elementi principali
del framework e la loro relazione logica. Nel resto
della sezione forniamo una descrizione più dettagliate dell’architettura di riferimento, dei PoV, e delle
metriche.
Figura 1: Le componenti principali del framework MeNSa e loro relazione.
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
4.1.1 L’architettura di riferimento
La figura 2 mostra l’architettura del sistema, intesa a definire gli elementi e le interazioni che vogliamo studiare. L’End User Application (es. browser) rappresenta il componente che genera la richiesta DNS.
Oltre l’azione precedente principale può avere caratteristiche più avanzate come la possibilità di fare
DNS pre-fetching e/o DNS caching.
L’Application Service Provider (aSP) è il componente che fornisce servizi/applicazioni distribuiti agli
utenti. Nella maggior parte dei casi questo avviene
attraverso il Web.
Il Name Server è la macchina fisica che risolve le
query per una Zona specifica.
Il Resolver (R) è un server, spesso gestito da un
ISP, che riceve le query degli utenti e le inoltra verso
i nameserver. esso può agire sia da semplice forwarder che da nameserver (diventando quel che si definisce “full resolver”).
Figura 2: Architettura di riferimento.
Lo Stub Resolver (SR) rappresenta le librerie del
sistema operativo che, ricevendo l’input dalle applicazioni, creano ed inviano richieste DNS verso i
resolver (attraverso connessioni TCP/IP). Il componente NET rappresenta le interconnessioni fisiche
tra i vari componenti.
In questo documento non considereremo altri
componenti architetturali comunque parte del framework e descritti in [9]. Questi sono: Registrant,
Databases, DNS Zone, Global DNS System (pseudo-elemento che indica il sistema nella sua interezza) e il
DNS Sub-system (servizio dei nomi di dominio gestito da una specifica entità gestito in maniera autonoSpeciale Sicurezza ICT
ma rispetto al resto dell’infrastruttura).
4.1.2 Definizione di Punto di Vista
I potenziali utenti del framework meNSa ricadono nelle seguenti categorie.
• End Users, (ovvero i semplici utenti) per lo più
all’oscuro delle funzioni e delle operazioni del
DNS. un end-user può essere un web browser ma anche una qualsiasi applicazione distribuita (ad esempio un’applicazione per il controllo dell’infrastruttura elettrica) che fa uso
del DNS.
• Service Providers, ad esempio Internet ed
application Service Providers. Operators, ad
esempio resolvers (forwarded o full).
• Nameservers (autorevoli o non).
• Registrars.
Ogni potenziale utente del framework può avere
una o più viste del sistema DNS e ciò dipende dai
componenti utilizzati [9]; oltretutto
un attore all’interno del sistema può
osservare solamente i processi in cui
è coinvolto direttamente e misurare
solo i componenti su cui abbia reale
controllo. La definizione di differenti punti di vista ha come obiettivo
quello di classificare quali componenti siano osservabili e misurabili
da un determinato attore del sistema
e quali informazioni siano necessarie
(eventualmente fornite da altri attori) per valutare in maniera adeguata i
livelli di DNS H&S percepiti.
I sei punti di vista attualmente
definiti sono: end user PoV,
application Service Provider PoV,
Resolver PoV, Nameserver PoV,
zone PoV, Global PoV.
4.1.3 Le metriche
Le metriche proposte servono a valutare l’Health
del DNS misurandolo su tre dimensioni differenti:
Vulnerabilities, Security e Resiliency.
Il framework meNSa organizza le metriche di
Vulnerability nelle categorie descritte in sezione 2,
ossia: Data corruption (repository e system corruption e protocol issues) e denial of service. Le metriche di sicurezza che andiamo a proporre non sono
specifiche del mondo DNS e sono intese come uno
91
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
strumento per valutare la prontezza di risposta del DNS
in possibili scenari di attacco atti a minarne il livello
di sicurezza. Per quanto riguarda la Resiliency proponiamo di utilizzare un set di metriche per la misura
della resilienza di un generico sistema ICT applicandolo alle problematiche del DNS.
In Tabella 2 sono mostrati alcuni esempi di metriche che abbiamo identificato. Per la lista completa si
rimanda il lettore a [11].
4.2 Le fasi operative del framework
In questa sezione descriviamo le principali fasi
operative del framework e in che modo il processo di
valutazione concretizza nella pratica.
Categorie
Misure
Repository Corruption Data Staleness
zone drift/zone trash
System Corruption
NS Parent/Chil Data
Coherence
Cache Poisoning
zone Transfer failure
DNS Spoofing
Denial of Service
Resiliency
Variation of DNS Request
per Second
Metriche
Differenze (in percentuale) di valori SOa tra i server autorevoli su un determinato periodo
Probabilità di incorrere in uno stato di zone drift/zone trash
Differenze (in percentuale) tra le risposte a query di tipo NS
tra due zone collegate nella gerarchia del DNS
Differenze (in percentuale) tra i contenuti di una cache e i
dati reali
Numero di operazioni di "zone transfer" fallite
Probabilità di essere attualmente in presenza di un attacco di
spoofing e probabilità che ciò avvenga in un determinato
periodo
Variazione nel numero di richieste DNS
Incoming bandwidth
Consumption
Percentuale di disponibilità della banda
mean Time to Incident
Discovery
Periodo medio intercorso tra l'identificazione di due attacchi/incidenti
Operational availability
Percentuale di tempo in cui un sistema ICT è in funzione su
un lungo periodo
Incoming Traffic Variation
Operational mean Time
between failures
Security
Scendendo maggiormente nel dettaglio possiamo
considerare il periodo di funzionamento del framework diviso in tre macro-sessioni: Preliminary
Diagnosis, SLO and Scenario Definition, Detailed Diagnosis
and Measurement.
Nella fase di Preliminary Diagnosis, scelto un
determinato PoV, viene eseguita una prima valutazione sui livelli di Health percepiti. Questa viene condotta attraverso semplici meccanismi di misura (es.
tool di monitoraggio) e con il supporto di un sottoinsieme delle metriche proposte.
Nella fase di SLO and Scenario Definition, sul
medesimo PoV, vengono selezionati uno o più scenari di minaccia ed al contempo quegli indicatori di
DNS H&S che siano rappresentativi e misurabili
attack Surface
attack Deepness
attack escalation Speed
Variazione nel traffico DNS
Periodo medio intercorso tra due interruzioni di funzionamento
Percentuale di nodi di un sistema che è suscettibile ad un
certo tipo di attacco
Percentuale di nodi colpiti in conseguenza di un attacco
Numero di attacchi in un determinato intervallo di tempo
annualized Loss expectancy Perdità economica derivante da incidenti al sistema
Tabella 2: Esempi di metriche per la valutazione di Health e Security del DNS.
92
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
nella specifica situazione.
La fase di Detailed Diagnosis and measurement è
infine dedicata alla valutazione di: (1) livelli di H&S
percepiti, (2) raggiungibilità degli SLO, (3) eventuali
cause di violazione degli SLO, (4) azioni perseguibili
per migliorare la DNS H&S.
Possiamo considerare quest’ultima fase organizzata in tre step: selezione delle metriche, misurazione
ed aggregazione.
La Metric Selection è un processo eseguito prima
della valutazione di un sistema concernente la scelta
delle misure da inserire nel framework. Quest’ultimo
fornisce infatti agli utenti vari possibili raggruppamenti di metriche tarati caso per caso in base agli scenari di minaccia ed ai PoV.
La Measurement Phase è composta da una fase di
collezionamento dati e, a seguire, una sessione in cui
le metriche selezionate nella fase precedente vengono calcolate. abbiamo proposto un modello di misurazione bottom up [9][10] in cui, dopo l’acquisizione
delle informazioni da altri PoV vengono in sequenza: (1) calcolati indici come network reachability o
network load che diano un riferimento di quanto le
nostre valutazioni siano dipendenti da uno stato,
eventualmente critico, dell’infrastruttura fisica e (2)
calcolate metriche proprie dell’H&S.
Nella Aggregation Phase vengono combinate tutte
le misure collezionate nelle precedenti ottenendo i
cosiddetti indici aggregati. Questi riassumono informazioni riguardanti: la H&S percepita nel PoV, i
livelli di SLO realmente raggiungibili ed infine le
cause di eventuali problemi.
5. Aggregazione delle metriche
Il concetto di Health & Security di un sistema
racchiude in sé aspetti complessi ed è, per questo
motivo, difficilmente esprimibile attraverso singole
metriche.
Per una valutazione corretta è necessario considerare uno o più indicatori (o indici) aggregati. ad
esempio, un end user che desideri una valutazione
esauriente, sarà interessato sia ad una classificazione
più generale della DNS H&S sia ad una valutazione
specifica dei componenti del sistema.
esistono vari modi con cui è possibile aggregare
le metriche proposte. In questo documento considereremo due approcci (descritti in dettaglio nei paragrafi seguenti). entrambi presentano vantaggi e
svantaggi. Prima di entrare nello specifico delle due
Speciale Sicurezza ICT
metodologie, nel seguito descriviamo i concetti
comuni.
Generalmente, dato un PoV, è possibile definire:
un indice di Total Evaluation (Te) che esprima una
valutazione generale della DNS Health & Security
più alcuni indicatori che rappresentino aspetti più
specifici del sistema (es. problematiche nei protocolli, vulnerabilità legate al DDoS, problemi sui componenti, ecc.).
ad uno specifico PoV e agli indici ad esso collegati viene sempre associato un insieme di metriche,
necessarie al calcolo degli indicatori stessi e misurabili nel contesto in esame.
Infine, un altro elemento connesso al concetto di
PoV è rappresentato dal quality mapping ovvero una
funzione di normalizzazione dei dati relativi alle
metriche che li renda adimensionali e confrontabili.
formalmente un PoV comporta l’individuazione
di:
• un insieme di M metriche {m1, …, mM} con Di
dominio della metrica mi. Dunque diciamo che
i valori misurati vi1, vi2, …, di mi appartengono
a Di .
• un insieme di Q funzioni di quality mapping
qi: Di → [0, 1], una per ogni metrica mi. Il mapping qi trasforma il valore misurato vij in un
valore di qualità adimensionale qij = q(vij), dove
0 indica la valutazione più bassa possibile ed 1
la più alta.
• un insieme di indicatori aggregati. Ogni indicatore Ik è definito interamente dal suo
vettore di pesi wk = (wk1, …, wkM) esso è tale
M
che ∑i=1
wki = 1 con wki compreso
nell’intervallo [0, 1].
Nel seguito, per semplicità di rappresentazione,
identificheremo sempre il PoV con la prospettiva che
l’end user ha del DNS.
5.1 Aggregazione Session-based
Questo tipo di aggregazione matematica richiede
un periodo di misura diviso in diverse sessioni
T = {s1, …, sS}, il cui numero S (nonché la durata)
viene specificato nel PoV ed è indipendente dalle
metriche considerate. Il valore di S dipende dall’obiettivo dell’analisi, dal grado di precisione desiderato e dai tool utilizzati nel framework. In generale, un
alto numero di sessioni rende la valutazione
dell’H&S più precisa. Durante ogni sessione, il collezionamento di dati prevede la misurazione di un
93
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
valore per ogni metrica. Tali valori saranno di volta in
volta manipolati ed aggregati fino all’ottenimento
degli indicatori finali. alla fine dell’esperimento, gli
indici ottenuti precedentemente saranno nuovamente combinati insieme col fine di ottenere i valori medi
e le incertezze di misura.
Per ogni sessione si, i tool di misurazione forniscono un valore vij per ogni metrica mi. Le misurazioni vij sono, in seguito, mappate sui valori di qualità qij
attraverso la funzione qi. Per ogni indicatori Ik e per
ogni sessione calcoliamo l’indice Iki come media
pesata dei valori di qualità attraverso il vettore di pesi
dell’indicatore stesso. es.
dove Iik è il valore aggregato dell’i-esimo indicatore Ik. al termine dell’ultima sessione, per ogni indicatore Ik, viene calcolato il risultato aggregato finale
definito come valore medio degli indicatori di sessione Iki, mentre la deviazione standard rappresenta
l’incertezza ∆Ik.
Vale la pena notare come questo metodo di
aggregazione non permetta di avere valori vij mancanti. In uno scenario reale potrebbe capitare che,
durante una sessione sia impossibile ottenere la misura vih della metrica mh, ad esempio a causa di un problema nel tool o della connessione. Questo fa sì che
anche il valore di qih non sia disponibile. In questo
caso l’equazione precedente per il calcolo di Ik non
potrebbe essere calcolata nel caso in cui l’indicatore
avesse wkh ≠ 0. Calcolare la media pesata dei valori
comunque disponibili (dopo averli rinormalizzati)
potrebbe essere una soluzione.
Nonostante questo, tale modifica altererebbe il
modo con cui il vettore di pesi esprime l’importanza
di una metrica per uno specifico indicatore. Inoltre,
nel caso in cui tutti i valori vih tale che wkh non fossero disponibili, l’equazione precedente non sarebbe
comunque utilizzabile. evitare di aggregare tutte
94
quelle sessioni che avessero un valore mancante è l’unica soluzione praticabile per la metodologia proposta nonostante l’incertezza sulla valutazione risulti
maggiore.
Come spiegato in precedenza, il metodo di aggregazione basato su sessioni di tempo prefissato fornisce un metodo semplice per gestire l’errore di misura, ma in caso di valutazioni mancanti, il risultato
risulterebbe irrimediabilmente meno preciso.
5.2 Aggregazione Metric-based
In questa sezione definiamo un metodo di aggregazione delle misure leggermente differente dal precedente.
Diversamente da quanto detto prima, la lunghezza delle sessioni può variare dipendentemente dalle
metriche. Infatti, per ogni metrica mi il tempo viene
diviso in Si sessioni {sij} con j = 1, …, Si. Il valore di
Si e la durata delle sessioni dipende dalla metrica mi e
specificamente dalla natura della misura. Questo,
nella maggior parte dei casi, permette una migliore
misurazione della metrica. Per esempio, alcune metriche potrebbero aver bisogno di collezionare molti
dati in sessioni che non richiedono molto tempo
mentre altre, al contrario, potrebbero necessitare di
pochi dati ma periodi di misura più lunghi. un altro
vantaggio di questa metodologia è relativo alla possibilità di gestire misurazioni mancanti. Le specifiche
sulle sessioni possono essere indicate nel PoV o
modificate a seconda dei requisiti di sistema (o dei
tool utilizzati).
Per ogni metrica mi e per ogni sessione sij di mi, i
valori vij sono mappati nei rispettivi valori di qualità
qij attraverso la funzione qi. In seguito calcoliamo il
valore medio e la deviazione standard sulle Si sessioni che rappresentano rispettivamente il valore di qualità della metrica mi e il corrispondente livello di
incertezza.
formalmente, per ogni metrica mi:
Gli indicatori aggregati sono calcolati come
medie pesate attraverso i vettori di peso. Possiamo
ottenere una stima dell’incertezza con la media pesata degli errori per ogni metrica. formalmente l’indicatore aggregato k-esimo e l’errore stimato sono calSpeciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
colati come:
to dei dati sarebbe diverso ed i vincoli sul livello di
servizio sarebbero molto più stringenti.
6.1 Misure e Metriche
In alcuni casi, le metriche possono essere considerate indipendenti e dunque la stima dell’errore precedente può essere sostituita con una più precisa calcolata come segue:
L’ipotesi che le metriche siano indipendenti può
essere a volte troppo forte. Per questa ragione il PoV
può eventualmente specificare se debba essere usato
la prima o la seconda formula nel calcolo di ∆Ik.
L’aggregazione metric-based è più complessa
della precedente. Il metodo proposto per aggregare
gli errori potrebbe essere sottoposto a revisione non
ostante la teoria degli errori sostenga le due strategie
proposte. La prima, come già accennato, dovrebbe
essere preferita solo nel caso di mutua dipendenza
delle metriche.
un indubbio vantaggio di questa metodologia di
aggregazione risiede nella possibilità di gestire semplicemente eventuali valori mancanti poiché, per
ogni metrica, il calcolo viene fatto esclusivamente
sulla base delle misure disponibili. Infine, è utile
ricordare come la flessibilità dello schema possa
risultare molto utile in presenza di metriche con
requisiti differenti.
6. Valutazioni sperimentali
Nel seguito vengono presentati un insieme di
risultati sperimentali con lo scopo di mostrare al lettore come il framework può essere utilizzato e la
tipologia dei risultati ottenibili. Il caso di studio considerato è quello di un end user che accede a contenuti informativi mediante un browser; ci collochiamo quindi nel caso dell’end user PoV.
La stessa metodologia di aggregazione può essere applicata al caso del sistema energetico descritto in
Sezione 3. Ovviamente, nello scenario di operazioni
di basso alto livello (Sezione 3.2) ci troviamo in un
caso molto simile a quello mostrato nel seguito.
Nello scenario che riguarda operazioni di basso livello invece (Sezione 3.3), il processo di collezionamenSpeciale Sicurezza ICT
Gli esperimenti condotti hanno richiesto la configurazione di due testbed ognuno composto da una
macchina Windows con firefox 8.0 in esecuzione.
Nel primo caso il PC era connesso alla rete Internet
attraverso l’ISP italiano fastweb (7mbit/s nominali)
dal laboratorio di GCSeC mentre il secondo usava la
rete GaRR con access point l’università di Roma
“Tor Vergata” (uTV). Le risoluzioni DNS sono state
demandate rispettivamente ai resolver di fastweb e
di uTV.
Ogni test ha collezionato dati su 10-12 sessioni di
navigazione sul web (web browsing). Ogni sessione è
durata dai 10 ai 15 minuti per un totale di 2 ore. Per
ogni sessione abbiamo collezionato ed analizzato
dati ottenendo dunque 10-12 valori per metrica (uno
ogni sessione).
Nei nostri esperimenti abbiamo considerato, tra
quelle discusse in [11], le seguenti metriche:
a) Incoming Bandwidth Consumption (IbC): definita
come il rapporto tra l’ammontare dei pacchetti di rete in entrata durante una sessione ed il
tempo della sessione stessa. Il dominio di
questa metrica è [0, IBCmax] misurato in
mbit/s dove il valore di IBCmax rappresenta il
massimo nominale nella banda dichiarato
dall’ISP.
b) Incoming Traffic Variation (ITV): definito, per
ogni sessione i, come (IBCi - IBCi-1) / lengthi
dove IBCi è l’incoming bandwidth consumption misurato nell’i-esima sessione. Il dominio
di questa metrica è [-ITVmax, ITVmax]
(mbit/s2) con:
ITVmax = maxi (IBCmax / lengthi).
c) Traffic Tolerance (TT): misurata con il Round
Trip Time di un pacchetto IP in transito tra la
macchina dell’end user ed il recursive resolver dell’ISP. Il dominio della metrica è [0, ∞]
misurato in secondi.
d) Stub Resolver Cache Poisoning (CP): misurata
attraverso la percentuale di entry della cache
avvelenate. Il dominio è [0, 100]. Ogni entry
della cache è controllata usando un insieme di
recursive resolver noti.
e) DNS Requests per Second (DNSR): definita
come il numero di richieste DNS fatte duran-
95
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
te la sessione. Il dominio è [0, ∞].
f) Rate of Repeated Queries (RRQ): definita come il
numero di richieste DNS ripetute. un comportamento corretto dell’infrastruttura,
durante una breve sessione di lavoro con
caching attivo, sarebbe quello di risolvere il
nome di dominio solo una volta. La presenza
di numerose query DNS per la medesima
informazione può essere un segnale di un funzionamento non corretto. Il dominio è [0, ∞].
Quello che segue è invece l’insieme di funzione di
quality mapping per le metriche precedentemente
definite:
g) Incoming Bandwidth Consumption (IbC): sia
IBCmax il massimo valore di banda fornito
dall’ISP. La funzione di quality mapping
q: [0, IBCmax] → [0, 1] per questa metrica è definita come:
h) Incoming Traffic Variation (ITV): la funzione di
quality mapping q: [-ITVmax, ITVmax] → [0, 1]
per la metrica ITV è definita come:
i) Traffic Tolerance (TT): sia RTTavg il valore medio
tra gli RTT durante la sessione. Definiamo la
funzione di quality mapping q: [0, ∞] → [0, 1]
per la metrica TT come:
j) Cache Poisoning per lo Stub Resolver (CP-SR): la
funzione di quality mapping q: [0, 100] → [0, 1]
per questa metrica è definita come:
Dove k è un parametro tarato appositamente.
Nel nostro caso, dopo alcuni test, abbiamo
deciso di mappare un risultato del 10% di
entry avvelenate su un valore di qualità vicino
a 0.6 ottenibile con k = 20.
k) DNS Requests per Seconds (DNSR): la funzione
di quality mapping permette di confrontare il
comportamento corrente del DNS con un
96
riferimento misurato a priori. Sia DNSRavg il
numero medio di richieste DNS al secondo
durante una normale sessione. La funzione di
quality mapping q: [0, 100] → [0, 1] per questa
metrica è definita come:
l) Rate of Repeated Queries (RRQ): sia Rmax il massimo numero di richieste DNS nella sessione
corrente. Vale la pena notare come Rmax possa
cambiare tra le varie sessioni. La funzione di
quality mapping q: [0, ∞] → [0, 1] per questa
metrica è definita come:
6.2 Aggregazione
La figura 3 mostra i valori di qualità e l’aggregazione eseguita con il metodo session-based. La
figura 4 mostra invece i medesimi valori ma con i
risultati dell’aggregazione metric-based.
Per ogni sessione, le stime di qualità delle metriche sono combinate nei seguenti indici aggregati
(questi indici sono propri dell’end user PoV):
m) Total Evaluation (Te): fornisce una valutazione
globale del PoV attraverso l’aggregazione di
tutte le metriche considerate nella prospettiva.
È interessante notare come la metrica di
Cache Poisoning possa essere interessata da
problemi relativi a falsi positivi. Per questa
ragione abbiamo deciso di considerarla meno
influente nella valutazione finale del sistema.
Dunque il peso della metrica CP nel risultato
dell’indicatore Te sarà più basso rispetto alle
altre metriche. Questo avrà l’effetto di ridurre
l’impatto dei suddetti falsi positivi sul risultato
finale.
n) Protocol Issues (PI): stima eventuali problemi nei
protocolli del DNS. Nel nostro PoV è legato
solo alla metrica del cache poisoning.
o) Denial of Service (DoS): valuta quanto sia
improbabile la presenza di un attacco DoS
nello scenario corrente. aggrega tutte le
metriche meno quella di cache poisoning.
p) NET: stima le performance del componente
rete. Le metriche aggregate saranno: Incoming
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
Figura 3: Valori calcolati attraverso l’aggregazione session-based.
Figura 4: Valori calcolati attraverso l’aggregazione metric-based.
bandwidth Consumption, Incoming Traffic
Variation, Traffic Tolerance.
q) Stub Resolver (SR): valuta le performance relative allo Stub Resolver. aggrega le metriche di
Cache Poisoning, DNS Requests Variation per
Second, Rate of Repeated Queries. La metrica CP anche in questo caso ha un peso inferiore per evitare che i falsi positivi abbiano un
impatto preponderante nella valutazione.
6.3 Valutazioni finali
La Total evaluation rappresenta il risultato finale
dell’end user PoV. esso rispecchia le perfomance
del sistema concentrandosi sui servizi del DNS che
un utente è in grado di misurare. In questo scenario
possiamo accettare piccoli disservizi come ad esempio problemi temporanei dell’infrastruttura risolvibili semplicemente ricaricando una pagina web. Per
questa ragione valori dell’indicatore Te intorno allo
0.8 sono possibili in un sistema che funzioni adeguatamente. Con il nostro framework è possibile dunque
Speciale Sicurezza ICT
verificare la qualità del servizio ed
eventualmente controllare se vi fossero violazioni sugli SLO.
Nel primo esperimento vengono
collezionate le misure dalla rete
GCSeC e vengono valutati i risultati ottenuti per entrambi i metodi di
aggregazione discussi precedentemente (vedi figura 5). I valori ottenuti per gli indicatori sono abbastanza simili. La Total evaluation è 0.76
in tutti e due i casi. Questo valore
quantifica i livelli di H&S effettivamente percepiti dall’end user. Gli
altri risultati aggregati danno una
valutazione delle perfomance dei
differenti aspetti del servizio e sui
singoli componenti. Questa informazione può essere importante per
migliorare le perfomance del sistema, perché permette di evidenziare
su quali elementi eventualmente
bisogni concentrarsi in casi di malfunzionamento. I nostri calcoli
mostrano come lo Stub Resolver sia
il componente in cui, con maggiore
probabilità, possa essere riscontrato
un problema poiché il valore di SR è
abbastanza distante da 1 (~0.66).
Invece, il componente di rete (NeT) ha una valutazione positiva (~0.85). È importante notare che
sarebbe possibile fare un’ulteriore analisi se i risultati
della prospettiva Recursive Resolver fossero disponibili come input all’end user PoV. aggregare tali
valori con le metriche calcolabili localmente incrementerebbe l’accuratezza della valutazione generale e
rifinirebbe quella dei singoli componenti.
analizzando i risultati ottenuti è possibile evincere anche informazioni sui possibili scenari di minaccia che potrebbero influenzare l’infrastruttura.
alcuni indicatori danno informazioni sulla probabilità che un certo attacco sia in corso. Nel nostro esperimento, ad esempio, i valori alti negli indici PI e DoS
(rispettivamente attorno a 0.7 e 0.8) indicano, con
bassa incertezza, che il sistema non era affetto da
problematiche come Protocol Issues e Denial of
Service al momento della misurazione.
Nel secondo esperimento abbiamo usato il framework per misurare i livelli di Health and Security
del DNS nella rete GaRR. In questo caso abbiamo
deciso di utilizzare la metodologia di aggregazione
97
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
due indici sono rispettivamente 0.8 e
0.85. Per questo motivo, ancora una
volta, possiamo escludere l’ipotesi in
cui il sistema sia sotto attacco di denial
of service o abbia problemi a livello di
protocolli.
Infine, nell’ultimo esperimento,
abbiamo simulato del cache poisoning
con l’intento di validare la nostra
metodologia di valutazione. Il cache
poisoning è stato implementato corrompendo manualmente il 10% delle
entry della cache DNS in una macchina del laboratorio di GCSeC.
In conseguenza, la Total
evaluation del sistema (vedi figura 7)
Figura 5: Valori degli indici aggregati per la valutazione del livello di H&S effettuando le
scende a 0.7. Il componente NeT è
misure dalla rete GCSEC.
ancora stimato attorno a 0.8 ma la
valutazione dello Stub Resolver scende a 0.6. Questi risultati descrivono la
presenza di problemi nelle librerie di
implementazione del DNS del sistema
operativo, come del resto ci aspettavamo. Proseguendo nel processo di
valutazione scopriamo che la nostra
infrastruttura è sottoposta, senza dubbio, a problematiche legate ai protocolli dato che l’indicatore di Protocol
Issues è 0.38. L’indice DoS rimane
invece sopra 0.75.
È significativo sottolineare come i
risultati dell’ultimo esperimento guidino l’utente direttamente alle contromisure da effettuare per migliorare le
prestazioni del sistema. Il confronto
Figura 6: Valori degli indici aggregati per la valutazione del livello di H&S effettuando le
degli
indicatori relativi ai componenti
misure dalla rete UTV.
con quelli legati alle minacce ci permette di identificare con esattezza (e
dunque di intervenire) sul problema di
session-based.
cache poisoning. Infatti, nel resoconto di valutazione
La Total evaluation (vedi figura 6) assume il
finale il framework dovrà suggerire all’utente di canvalore 0.8 con un incremento di circa il 5% se paracellare la cache DNS. Consigliare inoltre di ripetere la
gonata al test eseguito nel laboratorio di GCSeC.
valutazione subito dopo permetterà anche di avere
Questo è dovuto soprattutto all’ottimo risultato otteun’immediata
validazione della correttezza dell’azionuto dalla metrica di cache poisoning (oltre 0.85).
ne intrapresa.
entrambi i componenti NeT e Stub Resolver hanno
È importante infine notare come i test eseguiti
buone performance: il primo è stimato 0.86 mentre il
non siano da considerare generali e come dunque
secondo si attesta poco sopra 0.7.
essi debbano ancora essere suffragati da un più
mentre gli indicatori precedenti mostrano risultaampio insieme di esperimenti. Il nostro obiettivo è
ti su elementi dell’infrastruttura, come abbiamo
stato quello di mostrare come sia possibile misurare
accennato prima, DoS e PI descrivono una valutadelle caratteristiche dell’infrastruttura e come le
zione su degli scenari di minaccia. I valori di questi
98
Speciale Sicurezza ICT
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
(DOmaIN Name SySTem HeaLTH)
mework meNSa che ha l’ambizioso
obiettivo di definire una metodologia,
metriche e strumenti per la misura del
DNS. La realizzazione di tale framework è estremamente sfidante sia dal
punto di vista modellistico che tecnologico, ma soprattutto dal punto di
vista politico. Nonostante i proclami
della comunità (ICaNN e DNSOaRC prevalentemente) riguardo
alla necessità di condividere le informazioni tra gli operatori del DNS, di
fatto, poco o niente viene condiviso
e/o reso pubblico. Non ci sono standard per la misura, non vi sono standard
per la condivisione delle inforFigura 7: Risultati degli indicatori aggregati nel caso in cui venga introdotto del cache poisoning.
mazioni, non vi è un’entità (centrale o
distribuita) in grado di coordinare le
metriche identificate possano essere utilizzate ed
risposte ad attacchi al DNS.
aggregate per investigare la DNS Health & Security.
Siamo convinti che il progetto meNSa, possa
essere un primo passo per dare delle soluzione a
parte dei problemi citati e soprattutto possa fornire
7. Conclusioni
strumenti utili sia per gli operatori, sia per gli utenti
finali (siano essi operatori critici o consumatori bestQuesto lavoro analizza il DNS come infrastruttueffort) per contribuire a creare un DNS più sano e
ra critica e pone l’accento su come da essa dipendosicuro. Inoltre, il framework meNSa vuole fornire
no altre infrastrutture critiche, portando l’esempio
una base metodologia per la realizzazione di un
della rete di distribuzione elettrica. Sono stati consiDNS-CeRT.
derati vari aspetti: le vulnerabilità del DNS, la necesIl metodo di aggregazione presentato, che è una
sità di un framework per la misura del livello di sicudelle parti più importanti del framework, deve indubrezza, stabilità e resilienza (o più ad ampio spettro di
biamente essere validato con dati reali, ed i risultati
health) del DNS, come le vulnerabilità del DNS
sperimentali hanno il solo obiettivo di mostrare un
impattano l’operatività del sistema di distribuzione
esempio di funzionamento del modello proposto.
energetica, ed infine sono stati portati degli esempi di
Nel medio-lungo termine il progetto prevede una
misura del livello di health e security del DNS.
validazione della metodologia su più larga scala e per
Per quanto riguarda la misura del livello di sicugli altri punti di vista definiti. Inoltre è anche previrezza, stabilità e resilienza, abbiamo proposto il frasto un raffinamento delle metriche proposte.
BIBLIOGRAFIA
[1]
[2]
[3]
[4]
eastWest Institute, “Working Towards Rules for Governing Cyber Conflict: Rendering the Geneva and
Hague Conventions in Cyberspace”, 2011, 12.
Sebastian Castro, Duane Wessels, marina fomenkov, and Kimberly Claffy, “a day at the root of the internet”, SIGCOmm Comput. Commun. Rev. 38, 5 (September 2008), 41-46.
DNS-OaRC, The Day in the life of Internet (DITL) project.
Richard Liston, Sridhar Srinivasan and ellen zegura, “Diversity in DNS performance measures.”, In
Proceedings of the 2nd aCm SIGCOmm Workshop on Internet measurment (ImW ’02), 2002, aCm,
New york, Ny, uSa, 19-31.
Speciale Sicurezza ICT
99
E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni
[5]
y. Sekiya, K. Cho, a. Kato and J. murai, “Research of method for DNS performance measurement and
evaluation based on benchmark DNS servers”, electronics and Communications in Japan (Part I:
Communications), 89: 66–75, 2006.
[6] ICaNN, “Security, Stability and Resiliency of the Domain Name System”, Jan. 2009,
http://www.gtisc.gatech.edu/pdf/DNSSSRPaper.pdf
[7] “measuring the health of the Domain Name System”, Report of the 2nd annual Symposium on DNS
Security,
Stability,
&
Resiliency,
feb
2010,
Kyoto,
Japan
(apr.
2010),
https://www.icann.org/en/topics/ssr/dns-ssr-symposium- report-1-3feb10-en.pdf
[8] mark Santcroos, Olaf m. Kolkman, “DNS Threat analysis”, NLnet Labs document, 2006-Se-01 version 1.0 may 3, 2007.
[9] e. Casalicchio, m. Caselli, D. Conrad, J. Damas, I.N. fovino, “Reference architecture, models and
metrics”, GCSeC Report, Version 1.5, July 2011 (available at http://www.gcsec.org).
[10] e. Casalicchio, m. Caselli, D. Conrad, J. Damas, I. Nai fovino, “framework operation, the Web user
PoV”, GCSeC Report, Version 1.1, July 2011 (available at http://www.gcsec.org).
[11] e. Casalicchio, D. Conrad, J. Damas, S. Diblasi, I. Nai fovino, “DNS metric use Cases”, GCSeC
Report, Version 1.0, may 2011 (available at http://www.gcsec.org).
100
Speciale Sicurezza ICT