Stabilità, Sicurezza e Resilienza del DNS e loro impatto ...DNS stesso ed il crescente numero di...

81

SommarioOggi, sostanzialmente ogni attività umana è esposta a

minacce di sicurezza correlate all’uso inevitabile delle reti IP edel Sistema dei Nomi di Dominio (DNS). Mentre queste dueinfrastrutture mondiali hanno generalmente funzionato inmaniera affidabile e robusta per decenni, la pervasività delDNS stesso ed il crescente numero di minacce e attacchi infor-matici a tale infrastruttura pongono nuove sfide ai livelli poli-tico, di governance e tecnico. Questo articolo concentra l’atten-zione sul DNS come infrastruttura critica e sulla necessità dimisurare il suo “stato di salute” (DNS Health) ed il suolivello di sicurezza. Il contributo di questo documento è molte-plice. In primo luogo, prendendo ad esempio le reti di distri-buzione elettrica, si analizza l’impatto che eventuali attacchial sistema dei nomi di dominio avrebbero sull’operatività deimoderni sistemi energetici. A seguire, viene fornita la descri-zione di un framework per la misura dello stato di salute delDNS (Measuring the Naming System (MeNSa) frame-work), sviluppato con lo scopo di ottenere una metodologia for-male e strutturata, nonché metriche e tool, per la valutazionedei livelli di Health & Security del DNS. Infine, nell’ultimaparte del documento, si propone un processo di aggregazionedelle misure, con l’obiettivo di combinare differenti metriche di“Health & Security” in indici aggregati di valutazione.Inoltre vengono presentati i risultati ottenuti in una campagnadi test condotta su uno scenario realistico.

Abstract Today, basically every human activity is exposed to secu-

rity threats related to the inevitable use of IP networks andthe Domain Name System (DNS). While these two world-wide infrastructures have been generally operated in a reliableand robust fashion for decades, the pervasiveness problemabove mentioned and the growing number of cyber threats andattacks raise new challenges at political, governance and tech-nical level. In this work we concentrate our attention on theDNS as critical information infrastructure and on the need tomeasure the health and security level perceived. The contribu-tion of this paper is multiple: First, taking as example thePower Grid, we analyze the impact of malicious attacksagainst the Domain Name System (DNS) on the operationof the modern Energy system. Secondly, we provide a descrip-tion of the Measuring the Naming System (MeNSa) frame-work designed to provide a formal and structured methodology,metrics and tools for the measurement of DNS health andsecurity level. Finally we propose an aggregation process tocombine different health and security metrics in aggregatedindexes and we present the results obtained from a measure-ment campaign conducted in a real scenario.

Speciale Sicurezza ICT

E. CasalicchioUniversità di Roma “Tor Vergata”M. Caselli, A. Coletta, I. Nai Fovino, A. RigoniGlobal Cyber Security Center (GSEC)

STABILITÀ, SICUREZZA E RESILIENZA DEL DNS E LORO IMPATTO SULCONTROLLO DELLE INFRASTRUTTURE CRITICHE(DOmaIN Name SySTem HeaLTH)

1. Introduzione

La sicurezza informatica è uno dei principali pro-blemi della società digitale. L’ormai consolidatadipendenza dall’ICT nei processi di controllo egestione di infrastrutture critiche (IC) fa della cyber-security un elemento imprescindibile per la protezio-ne e la sicurezza dei cittadini. Oggigiorno, tali IC(centrali elettriche, reti energetiche, oleodotti e siste-mi di controllo del traffico aereo) sono esposte non

solo ai tradizionali problemi di sicurezza ed affidabi-lità ma anche e soprattutto a nuove minacce legateall’utilizzo che queste fanno delle reti IP e del DNS.Nonostante queste due infrastrutture globali abbianofunzionato per decadi in maniera affidabile e resi-liente vi sono costantemente nuove sfide da unpunto di vista operazionale, politico e di governancecausate della diffusione e del sempre crescentenumero di minacce ed attacchi informatici.

In questo lavoro concentreremo l’attenzione su

come il livello di sicurezza stabilità e resilienza delDNS impatta la sicurezza e resilienza delle IC.analizzeremo quindi gli effetti che, un potenzialeattacco al DNS potrebbe produrre sul controllo del-l’infrastruttura elettrica. In particolare considereremole principali vulnerabilità ed i principali scenari diattacco.

Nonostante il DNS sia stato recentemente rico-nosciuto, a tutti gli effetti, un’infrastruttura critica [1]ed abbia acquisito popolarità in risposta alle vulnera-bilità riscontrate di recente ed alla conseguente pub-blicità dovuta all’adozione del DNSSeC, non esisteuna 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 misu-razione di queste caratteristiche. Inoltre, non esisto-no, allo stato attuale, delle linee guida da seguire nelcaso si debba gestire una crisi o scenari di cyber-war-fare.

In questo articolo, prendendo come esempioguida i sistemi energetici, mostreremo come il DNSè un sistema critico da cui dipende il corretto funzio-namento di molte altre infrastrutture.

Inoltre, presenteremo un’iniziativa coordinata alivello internazionale, il progetto meNSa1, finanziatoda GCSeC, per lo sviluppo di un framework per lavalutazione del livello di salute e sicurezza del DNS(DNS Health & Security – DNS H&S). Il progettomeNSa propone di realizzare un framework di metri-che e misure, che sia aperto e concepito per rispon-dere ai bisogni di quegli attori direttamente o indiret-tamente influenzati dal funzionamento del DNS. Lemetodologie proposte potranno intervenire nelleazioni di definizione di policy e piani di gestione econtrollo degli incidenti ed inoltre permetteranno dirafforzare la sicurezza e la resilienza del DNS attra-verso una gestione proattiva delle sue operazioni.

Infine, mostreremo mediante una serie di esperi-menti come è possibile aggregare varie metriche, attea misurare caratteristiche specifiche del DNS, perottenere degli indicatori unici che quantifichino illivello di health e security percepito. I risultati speri-mentali sono stati ottenuti considerando un caso spe-cifico, quello di un end-user che accede, mediante unbrowser, a risorse (contenuti), distribuiti sulla reteinternet. Come vedremo nel seguito, vi sono unaserie di operazioni per la gestione delle infrastrutturecritiche che rientrano in questo scenario, mentre altre

operazioni richiederebbero di effettuare delle misurenel caso specifico, ossia accedendo direttamente allerisorse di un’infrastruttura critica, cosa che ancoranon è stata possibile. La metodologia prodotta si ècomunque dimostrata estendibile al caso appenamenzionato.

Il lavoro è organizzato come segue. La Sezione 2introduce i concetti di DNS Health, Vulnerabilità,minacce che saranno usati man mano. La Sezione 3descrive i sistemi energetici presentando le dipen-denze che questi ultimi hanno nei confronti delDNS. In questa sede si discute anche dell’importan-za di un DNS sicuro e performante dal punto di vistadegli amministratori delle IC. La Sezione 4 descrivenel dettaglio il framework meNSa elencandone i con-cetti di base e le fasi operative mentre nella Sezione 5concentriamo l’attenzione sui metodi di aggregazio-ne dati. Infine, nella Sezione 6 vengono mostrati iprimi esperimenti effettuati e come sia stato possibi-le validare le metodologie.

2. DNS Health, Vulnerabilità e Minacce

Per decenni, il DNS ha funzionato in manierageneralmente affidabile. Nonostante questo, negliultimi anni è stato posto sotto i riflettori il concettodi DNS Security, Stability e Resiliency. mentre visono numerosi studi su tecniche di monitoraggio deltraffico DNS e su eventuali metodologie di misura-zione delle perfomance ([2], [3], [4], [5]) ancora nonsono definite metriche che chiariscano il significatodi DNS SSR. allo stesso modo non sono stati tutto-ra descritti mezzi per valutare l’impatto che eventua-li cambiamenti dovuti all’incremento del numero diquery o a modifiche nelle tecnologie (come nel casodel DNSSeC) abbiano sul funzionamento del DNS.Il lavoro condotto dall’Internet Corporation forassigned Names and Numbers (ICaNN) ([6], [7]) hafornito una visione ad alto livello della nozione diDNS Health: un concetto ampio che include perfo-mance, stabilità, resilienza ma che non consideradirettamente quello di sicurezza.

Quanto segue è una proposta di revisione delledefinizioni degli indicatori di DNS Health propostiin [6] e [7].

• Availability – è definito come il grado con cuiun componente o l’intero sistema è operativoed accessibile all’utilizzo. In questo caso,

82 Speciale Sicurezza ICT

E. Casalicchio, M. Caselli, A. Coletta, I. Nai Fovino, A. Rigoni

1 The meNSa project, http://www.gcsec.org/activity/research/dns-security-and-stability

83

l’availability può essere definita anche comel’abilità del DNS di essere operativo ogni qual-volta riceve una richiesta.

• Coherency – questo è uno dei principi fonda-mentali del DNS essendo, di fatto, l’abilità dirisolvere un indirizzo IP in un dato nome didominio e viceversa. Considerando un esem-pio: se l’IP 192.0.2.1 è risolto nel valorefoo.example.com il principio di coerenzaimplica che il nome foo.example.com sia risol-to nell’IP originale, ovvero 192.0.2.1. LaCoherency è legata in gran parte ai dati man-tenuti nelle cache locali e nelle risorse condivi-se.

• Integrity – è l’abilità del DNS di proteggersicontro modifiche o cancellazioni impropriedelle informazioni ed include elementi colle-gati alla possibilità di garantire il non-ripudioe l’autenticità dei dati.

• Resiliency – è l’abilità del DNS di rispondere eritornare in uno stato consentito e sicuroall’occorrere di eventuali interruzioni di servi-zio. (es. attacchi DoS distribuiti). LaResiliency è percepita dagli utenti comeavailability mentre dai Provider come sommadei processi di individuazione, risposta e recu-pero da eventuali problemi. Inoltre, la resi-liency è una proprietà che può aumentare lafiducia degli utenti ad investire, a lungo termi-ne, nei servizi Internet. La Resiliency puòessere intesa anche come l’abilità del DNS difornire e mantenere un livello di servizio ade-guato a fronte di guasti.

• Security – è l’abilità del DNS di limitare o pro-teggersi da attività malevole (es. accessi nonautorizzati al sistema, rappresentazione frau-dolenta delle identità, intercettazione dellecomunicazioni). anche la Security può contri-buire ad aumentare la fiducia degli utenti nelDNS.

• Speed – è legata alle performance del DNS intermini di tempi di risposta (es. periodo ditempo impiegato tra l’invio di unarichiesta/query e l’arrivo di un responso) ethroughput (es. quantità di istruzioni, query ooperazioni processate nell’unità di tempo). LaSpeed non è di interesse solo per l’utente fina-le ma può essere inerente anche alle operazio-ni di gestione ed amministrazione del DNS.

• Stability – è l’abilità del DNS di funzionare inmaniera affidabile e prevedibile giorno per

giorno (es. standard e protocolli). La Stabilitypuò facilitare la percezione del DNS comesistema adeguato al soddisfacimento requisitiimposti ed il suo uso.

La salute del DNS può essere compromessa indiversi modi considerando la relazione che questihanno con tutte quelle vulnerabilità che è possibilesfruttare. Per questo motivo, gli indicatori di Healthhanno senso se considerati in relazione alle minaccee alle vulnerabilità stesse. Le problematiche relative alsistema dei nomi di dominio possono essere general-mente classificate in tre categorie principali [8]: Datacorruption, Denial of Service e Privacy.

• La Data Corruption è definita come l’insiemedei problemi relativi alla modifica non auto-rizzata dei dati propri del DNS. Tali problemipossono sorgere in ogni momento ed in ogniparte della catena di propagazione dei messag-gi DNS. Nel documento considereremo laData Corruption divisa in tre sotto-classi [8]: ◦ Repository Corruption - Il repository rappre-

senta quell’elemento del sistema in cuisono memorizzati e conservati i dati. NelDNS il repository è la fonte autorevole perle informazioni di una determinata zona.

◦ System Corruption - L’autenticità delle rispo-ste del DNS dipende fortemente dallafiducia che si ha verso l’intera catena deisistemi nella parte più rilevante della gerar-chia/albero del DNS. Per natura stessadell’architettura del DNS non tutti questisistemi sono sotto il controllo della mede-sima entità. Questo rende difficile (quasiimpossibile) per il possessore dei dati assi-curare l’autenticità degli stessi al client cheli abbia ricevuti. un esempio di systemcorruption è la modifica non autorizzatadelle risposte alle query DNS di un utente.

◦ Protocol Issues - Questa categoria di attacchitratta le falle di sicurezza riguardanti i pro-tocolli del DNS. alcuni esempi sono ilcache poisoning, la route-injection e leminacce del tipo man-in-the-middle.

La Data Corruption influenza in manieradiretta la coerenza e l’integrità di una porzio-ne o dell’intero DNS e, come conseguenza, haun impatto anche sulla resilienza del sistema.

• un attacco di Denial of Service viene sferratoper rendere il servizio inutilizzabile ai sui uten-ti. Questi attacchi usualmente possono averecome obiettivo uno specifico servizio (ad


STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe(DOmaIN Name SySTem HeaLTH)

esempio il DNS) o una porzione più ampiadella rete (ad esempio Internet). Per questomotivo distinguiamo gli attacchi DoS distri-buiti (DDoS) portati contro i server DNS daquelli relativi alle infrastrutture di rete.attacchi DoS e DDoS possono essere esegui-ti con tecniche differenti e possono avereeffetti su Speed, availability e Resiliency del-l’intero DNS o di una sua parte.

• Gli attacchi al DNS non sono solo una que-stione di sicurezza ma spesso riguardanoanche la privacy. molti attacchi infatti permet-tono, al malintenzionato, di entrare in posses-so dei “DNS data”. Il cache snooping e loNSeC walk sono esempi di minacce legate allaprivacy. attualmente la privacy non è conside-rata parte della DNS Health ma una discussio-ne sull’argomento andrebbe iniziata.

Riassumendo, una classificazione ad alto livellodell’impatto di minacce e vulnerabilità sul livello diHealth del DNS è la seguente:

• La Data Corruption si ripercuote direttamen-te sulla coerenza e sull’integrità di una partedel DNS e, come conseguenza, può avere unimpatto sulla Resiliency.

• attacchi DoS o DDoS possono essere esegui-ti con tecniche differenti e possono ripercuo-tersi su Speed, availability e Resiliency dell’in-tero 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 traminacce ed indicatori di Health. È possibile osserva-re come la Coherency e l’Integrity siano legati adaspetti di Data Corruption mentre Speed eavailability siano relativi a problematiche di DoS eDDoS. La Resiliency, essendo collegata alla capacitàdi mantenere, o recuperare, un certo livello di servi-zio è influenzata sia dalla Data Corruption che daelementi di DoS/DDoS. anche la Vulnerability ècollegata a tutte le categorie di minaccia essendo inte-sa come la probabilità che un problema del DNS,

derivante appunto da una certa vulnerabilità, si pale-si.

3. DNS Impact on CI, the Energy SystemUse Case

Come affermato nell’introduzione, il DNS vieneusato, in maniera ubiquita, in molte operazioni per lagestione ed il controllo delle infrastrutture critiche.In questa sezione, dopo una breve descrizione ad altolivello dei sistemi energetici, mostreremo come ilDNS è coinvolto in queste operazioni.

3.1 Panoramica sui sistemi energetici

I sistemi energetici comprendono un elevatonumero di sotto-sistemi, ognuno con compito diffe-rente, che insieme collaborano per garantire il corret-to funzionamento di infrastrutture trans-nazionali efornire così energia a centinaia di milioni di persone.Nel seguito di questa sezione forniremo una descri-zione ad alto livello di tutti questi elementi e delledinamiche di maggior importanza.

Il livello fisico di un sistema di alimentazione elet-trica è costituito dall’hardware di rete: stazioni, colle-gamenti, trasformatori e interruttori. Le strategie dicontrollo per il mantenimento operativo del sistemadi trasmissione sono trasferite ai sistemi fisici attra-verso periferiche e centri ICT per il controllo ed ilmonitoraggio delle informazioni (il cosiddetto livelloinformatico del sistema). Nel livello fisico è possibileclassificare gli elementi costitutivi di un sistema di ali-mentazione elettrica in:

• Stazioni di Trasmissione: generalmente gestitedirettamente dai Trasmission SystemOperator (TSO).

• Centrali di alimentazione: usualmente di pro-prietà di varie compagnie.

• alimentatori del Sistema di Distribuzione, checostituiscono l’origine del sistema di distribu-zione di medio voltaggio. Ogni Distribution



Categoria di Minaccia Tipo di Minaccia Indice di Health

Data Corruption Cache Poisoning, Coherency,modifica di query o risposta Integrity, Resiliency,Vulnerability

DoS e DDoS (contro i) DNS Server, (contro le)Infrastrutture di Rete

Speed, availability, Resiliency,Vulnerability

Privacy Cache Snooping Vulnerability

Tabella 1: Relazione tra minacce di sicurezza e indici di Health influenzabili.

85

System Operator (DSO) possiede e gestisce ilmonopolio del sistema di distribuzione su unacerta porzione del territorio.

• utilizzatori massivi: utenti del sistema energe-tico ad alto consumo (>5mW).

• utenti finali: connessi ai bus di distribuzione ecostituenti le foglie del sistema energetico.

Con l’avvento delle smart-grid in cui ogni utentepuò diventare esso stesso produttore di energiaovviamente questa classificazione subirà delle modi-fiche.

Per mantenere l’operatività, un sistema così com-plesso necessita un considerevole scambio di infor-mazioni (dati real-time, ma anche commerciali edamministrativi) tra i centri di controllo e le sotto-sta-zioni ma anche tra i vari operatori. Il sistema infor-mativo di una rete energetica è composto da diffe-renti sotto-sistemi:

• La rete di controllo: contiene tutte le RemoteTerminal unit (RTu) ed i ProgrammableLogic Controller (PLC). essa si interfacciadirettamente con la rete di campo ovvero larete degli attuatori e dei sensori che fisicamen-te svolgono i task di processo nel sistema.Inoltre essa è connessa con la rete di processo(descritta nel seguito).

• La rete di processo: è composta dai serverSCaDa e da tutti quei sistemi che si occupa-no della raccolta dei dati in arrivo dalla rete dicontrollo. È la rete di processo che inviacomandi e istruzioni alla rete di controllo.

• area di scambio: usualmente contiene i data-base di aggregazione che ricevono i dati dallarete di processo. Questi dati rappresentano lostato operativo del sistema e sono utilizzatidagli apparati diagnostici, contenuti nell’areastessa, per individuare anomalie. Gli operatoridei centri di controllo accedono in remoto aquesti database per avere una panoramica adalto livello dello stato di processo.

• Centri di controllo: sono utilizzati dagli opera-tori per ottenere informazioni sui processi eper eseguire sequenze di operazioni per lamodifica dello stato di processo (mediante larete di controllo).

Questa panoramica del sistema deve essere intesacome multi-livello, ossia alcune di queste infrastrut-ture, di proprietà di aziende differenti, interagisconosovrapponendosi l’una con l’altra su varie prospetti-ve.

a questo punto è evidente come, nell’architettura

appena descritta le reti ICT giochino un ruoloimportante implementando, di fatto, le interconnes-sioni di sistema.

facendo riferimento alla documentazione scienti-fica ed operativa scopriamo che, in questo contesto,viene rivolta pochissima attenzione al ruolo del siste-ma dei nomi di dominio. Per capire il grado di coin-volgimento dell’infrastruttura del DNS nelle opera-zioni di un sistema di alimentazione elettrica, dob-biamo guardare ad esso considerando due diverseprospettive: la “infrastruttura di alto livello” e la“infrastruttura di basso livello”. Per ognuna di esse,abbiamo identificato un insieme di classi di opera-zioni (tipiche della rete di distribuzione elettrica) edalcune classi di vulnerabilità tradizionalmente asso-ciate al DNS: Repository Corruption, SystemCorruption, Protocol Issues, Denial of Service edInformation exposure. Sulla base di queste categorieabbiamo infine fatto delle ipotesi sugli effetti che unproblema del DNS potrebbe avere sul sistema ener-getico.

3.2 Il DNS e l’infrastruttura di alto livello diun sistema di alimentazione elettrica

Possiamo definire infrastruttura di alto livello del-l’impianto di alimentazione elettrica quella parte delsistema utilizzata per le operazione dette di alto livel-lo, ossia:

1. Gestione del mercato dell’energia.2. Collegamento tra i rappresentanti dell’indu-

stria e gli utenti.3. azioni presso le sedi dei clienti.4. Collegamenti tra il settore energetico e i rap-

presentanti dell’industria.5. Coordinamento tra i produttori di energia.6. Coordinamento tra le aziende per la trasmis-

sione dell’energia.7. Gestione di crisi/blackout.Ognuna di queste operazioni funzionali coinvol-

ge in qualche modo il DNS. Nel seguito forniamouna panoramica sul suo ruolo e sugli effetti di uneventuale guasto.

3.2.1 Gestione del mercato energetico

Questa sezione include le interazioni tra i rappre-sentanti dell’industria, i mediatori, il mercato all'in-grosso e la camera di compensazione del mercato.

Queste operazioni fanno uso di strumenti dicomunicazione e cooperazione, workflow manage-



ment ed applicazioni distribuite in genere. Tutte que-ste applicazioni fanno spesso uso di tecnologie webe sono estremamente dipendenti dal corretto funzio-namento del DNS. È evidente dunque come il DNSpossa avere un impatto diretto sulla disponibilità esulla stabilità del mercato energetico considerandol’eventuale possibilità di causare gravi danni finanzia-ri.

Con riferimento alle quattro categorie di vulnera-bilità associate al DNS descriviamo brevemente alcu-ni scenari di minaccia:

• Repository Corruption: una DNS RepositoryCorruption (ad esempio una modifica nonautorizzata nei database autorevoli o dicaching) può essere parte di un attacco piùcomplesso che abbia lo scopo di reindirizzareparte dei flussi del mercato energetico versoserver compromessi, così da alterare la perce-zione sugli andamenti di mercato. In altri sce-nari, questo potrebbe avere un impatto anchesulla produzione dell’energia. Si consideri adesempio il caso in cui un produttore compridelle azioni; in una situazione dove questo siafatto attraverso server dedicati, l’accesso amacchine compromesse potrebbe essere l’ef-fetto di un DNS Repository Corruption. Ilrisultato di queste operazioni potrebbe avere alivello nazionale o, ancor peggio, a livello con-tinentale ripercussioni sul piano economico esociale (si pensi ad una situazione dove un’e-ventuale carenza energetica forzi le reti a spe-gnersi o a interrompere l’erogazione).

• System Corruption e Protocol Issues: In questi dueambiti sono valide le stesse considerazionifatte nel caso precedente.

• Denial of Service: un DNS DoS potrebbe essercausa dell’irraggiungibilità delle infrastrutturedi rete del mercato energetico. L’impatto diquesto attacco, evidente nell’immediato,sarebbe comunque limitato, dato che per uncerto lasso di tempo, ogni operatore del mer-cato energetico sarebbe in grado di lavoraresenza il bisogno di accedere ai servizi. Ècomunque vero che in alcuni casi particolari(es. durante inaspettati picchi della richiesta dienergia o in situazioni similari), l’indisponibili-tà del mercato energetico potrebbe causaredanni difficilmente prevedibili.

• Information Exposure: gli attacchi al DNS chehanno lo scopo di violare la confidenzialitàdell’infrastruttura potrebbero essere parte di

attacchi più complessi (per esempio quelli conl’obiettivo di corrompere delle cache delDNS). Il danno immediato in questo caso èpraticamente nullo ma, se consideriamo una“visione d’insieme”, sapere come certi nodidel DNS coinvolti nelle operazioni del merca-to energetico siano configurati potrebbe esse-re un’informazione molto utile a potenzialiattaccanti.

3.2.2 Collegamenti tra i rappresentanti dell’industria e gliutenti finali

Questa operazione logica si riferisce alle fasi dicomunicazione tra le società del settore energetico egli utenti finali inclusi contatori, interfacce per la fat-turazione dei servizi energetici, aggregatori di forni-tori di energia al dettaglio e fornitori dei servizi ener-getici.

In quest’ambito, un esempio in cui il DNSpotrebbe essere usato riguarda il contesto degliSmart meter: esistono già diversi esempi di infra-strutture di misura composte da un misto di tecnolo-gie GPRS e canali TCP/IP classici. Normalmente lacomunicazione è “GPRS based” dal contatore alcentro di aggregazione locale e “IP based” da que-st’ultimo ai server della piattaforma energetica. Conriferimento alla parte IP dell’architettura di controlloed acquisizione dati, ogni attacco al DNS può avereimpatto notevole su servizi come: spegnimento oavvio remoto dell’alimentazione per un certo cliente,alterazione delle statistiche sul consumo energetico,disabilitazione del servizio, interruzione nel rileva-mento dati, utilizzo non autorizzato dell’elettricità,alterazione della massima quantità di elettricità cheun cliente può richiedere, alterazione remota delpiano di fatturazione dei contatori.

esistono già applicazioni “mobile” che permetto-no ai clienti di controllare in remoto il consumoenergetico di casa; anche in questo caso è probabileche il DNS sia utilizzato per rendere il servizio acces-sibile ovunque. allo stesso modo, i servizi di fattura-zione, un altro esempio di Web application, fannouso del DNS per rendere accessibili da parte degliutenti i server di frontend e i servizi di pagamento.

In questo caso DNS Repository Corruption,DNS System Corruption e Protocol Issues possonoessere usati in diversi scenari come parte di un attac-co più complesso:

• La cache DNS può essere modificata così darendere possibile, in un punto del percorso



87

che va dai contatori ai server di aggregazione,il reindirizzamento del traffico su un servercontraffatto. allo stesso modo le categorie divulnerabilità possono essere utilizzate in unoscenario in cui sia coinvolto il processo di fat-turazione o, nel caso di produzione di energiada parte di un utente finale, adottate in unattacco che abbia lo scopo di alterare i valoridi produzione di tali utenti. Il danno in questasituazione sarebbe prettamente economicoma, fortunatamente, non avrebbe alcunimpatto su infrastrutture fondamentali.

• Denial of Service: un DNS DoS potrebbe inter-ferire nel controllo e nel processo di fattura-zione. ancora una volta parliamo di danniprettamente economici.

• Information Exposure: come nel caso preceden-te, il danno immediato è quasi nullo ma, con-siderata una “visione d’insieme”, lo scenariopotrebbe essere sicuramente quello di unostep intermedio che conduca ad altri attacchi.

3.2.3 Azioni presso le sedi dei clienti

In questo contesto consideriamo operazionicome la gestione di elettrodomestici, veicoli elettrici,altri servizi relativi (misurazione del consumo diacqua/gas), domotica, ecc.

Queste operazioni cadono, da un punto di vistatecnico, nella stessa categoria di quelle precedenti e,per questa ragione, il DNS, a seconda dall’architet-tura di comunicazione utilizzata, potrebbe avere unruolo rilevante.

3.2.4 Collegamenti tra il settore energetico e i rappresen-tanti dell’industria

Per mantenere operativo il nucleo fondamentaledell’infrastruttura (centrali di alimentazione, centri ditrasmissione, ecc.) le aziende del settore energeticosono strettamente legate ai produttori di dispositiviper l’alimentazione. È abbastanza comune che i pro-duttori di dispositivi forniscano un supporto per lamanutenzione remota. Questa attività è normalmen-te svolta attraverso l’implementazione di una con-nessione VPN (attraverso Internet) dalla sede delproduttore di dispositivi fino alla società elettrica,l’installazione di una sotto-rete, ed infine conceden-do la possibilità di eseguire operazioni remote sulsistema di controllo del processo locale. In questocaso, il DNS è coinvolto nella risoluzione dei nomi

dei server utilizzati e ogni indisponibilità, modificamalevola o problema potrebbe prevenire un’opera-zione di manutenzione necessaria all’impianto fisico.Quando viene stabilito un tunnel VPN da base abase, il processo di risoluzione dei nomi per i serverinterni viene eseguito attraverso i due sistemi DNSche agiscono da entrambe le parti. errori di configu-razione, modifiche malevole interne o problemi diindisponibilità nella sede del produttore o in quelladell’azienda elettrica influiscono inevitabilmentesulla sicurezza dell’intero sistema, con la conseguen-za che il flusso di operazioni possa essere ridirettoverso server contraffatti o che sia prevenuto deltutto.

È importante anche porre in evidenza che il DNSpuò essere usato sia per facilitare la diffusione diinfezioni (es. ridirigendo trasparentemente le richie-ste degli utenti verso siti contraffatti e conseguente-mente innescando l’installazione di codice malevoloche produca, una volta in azione, danni concreti) siacome attuatore di infezione (per esempio interve-nendo direttamente sulla disponibilità dei servizidella 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, rela-

zionata soprattutto alla quantità di energia chedebba essere prodotta. Tale coordinazione fasempre maggior uso di Internet. Di conse-guenza, l’impatto del DNS su queste opera-zioni dovrebbe essere considerato alto, tenen-do conto che, ad esempio, le società elettrichepotrebbero non essere in grado di comunicar-si in maniera adeguata piani di produzioneenergetica.

• La coordinazione tra le società di trasmissio-ne: anche in questo caso sono valide le consi-derazioni fatte al punto precedente.

• Gestione di crisi/blackout: tradizionalmentela coordinazione tra gli attori del settore ener-getico durante una crisi (es. durante un blac-kout) è ben strutturata e definita da un insie-me di linee di condotta operative. L’uso dellarete pubblica, sistemi di posta elettronica, edaltre applicazioni per coordinare le azionidurante una crisi energetica è in crescita.anche in questo caso il DNS sarebbe coinvol-to. Infatti l’impatto di Repository Corruption,System Corruption e DoS nel sistema dei



nomi di dominio è potenzialmente moltograve. un ritardo nella coordinazione di un’e-mergenza blackout può portare a situazionidrammatiche in cui intere nazioni sono lascia-te senza elettricità. Tutto ciò può essere consi-derato, a questo livello, come l’azione di mag-gior rilevanza in termini di impatto sulla vitadelle persone.

3.2.6 Considerazioni finali

essenzialmente, tutte le operazioni di alto livelloche riguardano l’infrastruttura di alimentazione, siaffidano a servizi web/applicazioni che fanno usodella rete Internet per lo scambio di informazioni,per la realizzazione di transazioni e per la fornitura diservizi. In tutte queste categorie, il DNS gioca unruolo rilevante. un guasto o una compromissione delDNS potrebbe avere un impatto drammatico, peresempio intevenendo sui prezzi o sulla disponibilitàdel mercato energetico. In maniera simile, durante lagestione di una crisi energetica (ad esempio colrischio di un blackout), se il DNS subisce un guasto,può accadere che questo si ripercuota sui centri dicontrollo di alto livello adibiti al collezionamento didati e, indirettamente, causi un rallentamento nelladefinizione di un piano di contingenza. La coordina-zione tra i produttori di elettricità è necessaria pergarantire la stabilità della rete energetica. un guastodel DNS potrebbe compromettere questo processo.

3.3 Il DNS e l’infrastruttura di basso livellodei sistemi di alimentazione elettrica

Nei primi anni ‘90 i sistemi per il controllo dell’a-limentazione elettrica erano costruiti come ambienticompletamente isolati. Il controllo della rete dicampo era basato su protocolli di comunicazioneseriale ed ogni cosa era monitorata e gestita local-mente. Con il crescente utilizzo del TCP/IP, gli inge-gneri di processo decisero di trasferire tutti i proto-colli seriali industriali sul TCP/IP (incorporandoliusualmente nel livello applicazione della suiteTCP/IP). Oggigiorno, praticamente ogni elementoattivo nei moderni sistemi di controllo del settoreenergetico è associato ad un indirizzo IP. alcuni studicondotti in questo campo (per esempio [7]) hannomostrato come stia diventando sempre più comuneper i sistemi di alimentazione elettrica affidarsi alDNS per la identificazione dei server coinvolti nelprocesso di controllo. Di seguito sono proposti alcu-

ni esempi di comuni operazioni in cui il DNSdovrebbe essere coinvolto e delle ipotesi sugli effettiche un guasto al DNS avrebbe nel corso di questeattività.

3.3.1 Operazioni di manutenzione

Centrali elettriche, sotto-stazioni di trasmissioneed altri elementi dei sistemi di alimentazione elettricarichiedono costante manutenzione. Tali attività sonotipicamente appaltate a società esterne che eseguonovarie operazioni per via remota, utilizzando quindiconnessioni di rete basate su protocollo TCP/IP o sualtre tecnologie. La procedura standard consiste nel:

1. Stabilire una connessione VPN da base a basetra la rete della società esterna e quella del pro-prietario della centrale.

2. accedere al dominio della società elettricaattraverso un’autenticazione di tipo RaDIuS.

3. accedere alla sotto-rete dell’impianto4. eseguire l’operazione di manutenzione richie-

sta.Per risolvere gli indirizzi dei server coinvolti nel

processo, siano essi appartenenti a zone pubbliche oprivate, viene normalmente utilizzato il protocolloDNS. Quindi, un guasto nel DNS (privato o pubbli-co) durante queste operazioni potrebbe avere unimpatto sulla sicurezza e sulla stabilità del sistema dialimentazione elettrico. Repository Corruption eProtocol Issues (che permetterebbero ad esempio digenerare del cache poisoning) possono essere usaticome elementi di attacchi più complessi con lo scopodi reindirizzare il flusso di operazioni di manutenzio-ne esistente tra la base del produttore di dispositivi eil centro ove risiede la rete locale della centrale. unDNS DoS può essere utilizzato per rendere difficol-toso il settaggio di una connessione tra il sito remo-to e quello ove risiedono i server su cui eseguire leoperazioni di manutenzione.

La finalità di questi attacchi può essere considera-ta duplice:

1. Generare un problema nel sistema reale,mascherandolo all’operatore mostrando infor-mazioni corrette.

2. evitare l’esecuzione corretta di un’operazionedi manutenzione.

In entrambi i casi l’impatto sull’impianto potreb-be essere estremamente grave. Quando si tratta didispositivi critici come turbine a gas, linee ad alto vol-taggio o, nel peggiore dei casi, centrali nucleari, unamancata operazione di manutenzione potrebbe avere



89

effetti drammatici.

3.3.2 Interazioni nella rete di processo

La rete di processo contiene tutti i server checontrollano i processi industriali (es. produzione dienergia, trasmissione di energia, ecc.). È abbastanzacomune affidarsi ad un DNS interno per la risolu-zione dei nomi dei server. In questo caso, un guastosul DNS potrebbe avere impatto sull’individuazionedelle anomalie nella rete di processo di un sistema dialimentazione elettrico o anche sulle capacità di con-trollo dei server SCaDa. Nel primo caso un’anoma-lia sfuggita alla ricerca (per esempio una variazionenella rotazione di una turbina a gas) potrebbe causa-re danni fisici al sistema o un blocco forzato dellostesso (questo sarebbe un problema economicamen-te costoso considerato che in media una centraleelettrica costa circa 2 milioni di euro al giorno). Nelsecondo caso, perdere la capacità di controllare i ser-ver SCaDa potrebbe rendere impossibile una rea-zione sufficientemente rapida alla transizione delsistema in uno stato critico.

3.3.3 Monitoraggio degli operatori

Il personale operativo usa le Human-machineInterface (HmI) per il monitoraggio delle attività diun sistema di processo. Per eseguire questo compito,di solito essi accedono ai server, contenuti nella retedi scambio, mantenenti la cronologia delle operazio-ni. Più raramente, essi accedono direttamente ai ser-ver SCaDa. Il trend di accesso ai server ed ai servi-zi attraverso l’utilizzo dei nomi al posto degli indiriz-zi IP è in crescita. Inoltre, in diverse situazioni, que-ste attività sono eseguite per via remota nel senso piùampio del termine; come ad esempio da operatoriubicati in luoghi completamente differenti che utiliz-zino una rete esterna e si affidino ad Internet per rag-giungere l’access point della sotto-rete dell’impianto.ancora una volta, proprio come nel caso delle ope-razioni di manutenzione, il DNS gioca un ruolo fon-damentale nel rendere questa connessione possibilee, nuovamente, un suo guasto o una modifica male-vola potrebbe rendere difficile o impossibile control-lare remotamente il sistema di processo.

In [8] Nai fovino et al. mostrano come un attac-co di DNS poisoning possa essere utilizzato comeparte di un attacco più complesso contro una centra-le turbo-gas per ridirigere l’operatore su un falso ser-ver SCaDa.

3.3.4 Operazioni del Centro di Controllo

I centri di controllo gestiscono simultaneamenteimpianti multipli dei sistemi di alimentazione elettri-ca. Le varie applicazioni in esecuzione nei centri dicontrollo generano flussi di richiesta/risposta dalleHmI locali ai database remoti degli impianti e dun-que ai server di diagnostica. Il DNS è ancora unavolta utilizzato per la risoluzione dei nomi degli entrypoint delle sotto-reti remote ed allo stesso modo perrisolvere i nomi dei server remoti. un'altra impor-tante funzione dei centri di controllo consiste nel di-stribuire i piani di produzione giornaliera con la spe-cifica della produzione di energia, ora per ora, di ognicentrale elettrica del sistema. Queste piani sono auto-maticamente consegnati ad ogni centrale usando: (a)una rete dedicata, (b) una rete pubblica combinandol’utilizzo di VPN o mPLS. un guasto nel DNS, inquesta situazione, potrebbe avere effetti significativinella definizione dei piani di reazione contro crisienergetiche o potrebbe compromettere il piano diproduzione dell’energia stessa.

In quest’ultimo scenario, dovrebbe essere ulte-riormente posta l’attenzione al ruolo del DNS comeveicolo per la disposizione di canali nascosti non fil-trati con host già compromessi all’interno dellesotto-reti delle società elettriche: il prelevamento ille-cito di dati dai sistemi di controllo o dalle reti discambio sia che si tratti di dati di misura, rapportisulle performance, piani operativi o raccolte di valu-tazioni di criticità potrebbe condurre a gravi rischiper la sicurezza e per la continuità delle operazioni.Tipicamente, sebbene siano isolate dalle reti pubbli-che, le sotto-reti delle aziende necessitano comunquedi servizi basilari come quello della risoluzione deinomi di dominio e, nel momento in cui un certo hostall’interno della sotto-rete della compagnia sia giàstato compromesso, il prelevamento illecito di datipotrebbe essere operato attraverso l’inoltro di queryDNS, che risolvano i nomi e conducano le informa-zioni verso un name-server sotto il controllo dell’at-taccante. In questo modo, applicazioni malevole, inesecuzione su una macchina compromessa potreb-bero mandare query ad-hoc verso specifici uRL cheprocurerebbero problemi per esempio nel trasferi-mento di dati sensibili archiviati nelle sotto-reti delname-server dell’attaccante, senza che vi siano fire-wall operanti a livello applicazione o intrusion detec-tion/prevention system che facciano attivamente illog sul traffico HTTP sospetto. un’ispezione accura-ta delle query e dei responsi DNS dovrebbe essere



assicurata per mitigare questo rischio.

4. Il framework MeNSa

Il concetto di DNS Health è stato proposto, nel2010, dalla comunità DNS-SSR, ossia da chi si occu-pa di SSR del DNS [7]. Definire gli indicatori vitalidel DNS è sicuramente un passo fondamentale ma,nonostante questo, la definizione di metriche di sicu-rezza è a livello embrionale, mentre le metriche per laStabilità e Sicurezza del DNS sono ancora un territo-rio inesplorato. Relativamente al problema dellamisura del livello di H&S del DNS vi sono una seriedi questioni aperte e di sfide che possono essere rias-sunte come segue:

1) Necessità di raffinare e migliorare le metricheesistenti (e gli approcci alla misurazione) perciò che riguarda: Coerency, Integrity, Speed,availability, Resiliency, Vulnerability, Security.

2) Necessità di definire nuovi indicatori per lavalutazione del livello di H&S. Tali indicatoridevono potersi adattare ai vari attori del siste-ma (operatori dei root server o anche di servernon-autoritativi, server cache ed open resol-ver, ma anche end user).

3) bisogno di progettare e raffinare appropriatemetodologie e tecniche per il calcolo degliindicatori di DNS Health & Security.

4) Necessità di identificare delle soglie di riferi-mento sulle metriche stesse che consentanoalla communità del DNS disapere, possibilmente in antici-po, se e quando la H&S delDNS sia compromessa.

Dare una risposta a queste esigen-ze concretizza la definizione di unalinea di azione globale e coerentemirata al rafforzamento ad ogni livellodella sicurezza stabilità e resilienza delDNS fornendo inoltre strumenti dianalisi che permettono agli utenti fina-li di valutare eventuali loro esposizionialle minacce. Il framework presentatoin questa sezione è una prima rispostaa queste esigenze.

Nel seguito descriviamo i compo-nenti principali del framework meNSae le sue fasi operative. Per maggioridettagli si faccia riferimento ai delive-rable di progetto [9], [10], [11].

4.1 I componenti del framework

I principali concetti alla base del frameworkmeNSa sono riassunti nei cinque punti che seguono:

• modello di riferimento del DNS [9]. In ogniframework di misura è sempre necessario defi-nire formalmente l’oggetto della misura stessa.

• Il Punto di Vista (Point-of-View o semplice-mente PoV). un PoV è inteso come la pro-spettiva da cui un attore del sistema osserva,usa, opera e influenza il DNS.

• Gli use Case. L’insieme dei casi d’uso descri-vono i possibili utilizzi del framework in situa-zioni specifiche. un caso d’uso è contraddi-stinto da un attore primario (che rappresental’utilizzatore del framework) ed eventuali atto-ri 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’a-nalisi dei dati del sistema. La loro implementa-zione dipende da due fattori: (a) ciò che puòessere realmente misurato da un determinatoPoV; e (b) il periodo di collezionamento dati(orizzonte temporale variabile in un intervalloche va dalle ore ai mesi).

La figura 1, schematizza gli elementi principalidel framework e la loro relazione logica. Nel restodella sezione forniamo una descrizione più dettaglia-te dell’architettura di riferimento, dei PoV, e dellemetriche.



Figura 1: Le componenti principali del framework MeNSa e loro relazione.

91

4.1.1 L’architettura di riferimento

La figura 2 mostra l’architettura del sistema, inte-sa a definire gli elementi e le interazioni che voglia-mo studiare. L’End User Application (es. browser) rap-presenta il componente che genera la richiesta DNS.Oltre l’azione precedente principale può avere carat-teristiche più avanzate come la possibilità di fareDNS pre-fetching e/o DNS caching.

L’Application Service Provider (aSP) è il componen-te che fornisce servizi/applicazioni distribuiti agliutenti. Nella maggior parte dei casi questo avvieneattraverso il Web.

Il Name Server è la macchina fisica che risolve lequery per una Zona specifica.

Il Resolver (R) è un server, spesso gestito da unISP, che riceve le query degli utenti e le inoltra versoi nameserver. esso può agire sia da semplice forwar-der che da nameserver (diventando quel che si defi-nisce “full resolver”).

Lo Stub Resolver (SR) rappresenta le librerie delsistema operativo che, ricevendo l’input dalle appli-cazioni, creano ed inviano richieste DNS verso iresolver (attraverso connessioni TCP/IP). Il compo-nente NET rappresenta le interconnessioni fisichetra i vari componenti.

In questo documento non considereremo altricomponenti architetturali comunque parte del fra-mework e descritti in [9]. Questi sono: Registrant,Databases, DNS Zone, Global DNS System (pseudo-ele-mento che indica il sistema nella sua interezza) e ilDNS Sub-system (servizio dei nomi di dominio gesti-to da una specifica entità gestito in maniera autono-

ma rispetto al resto dell’infrastruttura).

4.1.2 Definizione di Punto di Vista

I potenziali utenti del framework meNSa ricado-no nelle seguenti categorie.

• End Users, (ovvero i semplici utenti) per lo piùall’oscuro delle funzioni e delle operazioni delDNS. un end-user può essere un web brow-ser ma anche una qualsiasi applicazione distri-buita (ad esempio un’applicazione per il con-trollo dell’infrastruttura elettrica) che fa usodel DNS.

• Service Providers, ad esempio Internet edapplication Service Providers. Operators, adesempio 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 daicomponenti utilizzati [9]; oltretuttoun attore all’interno del sistema puòosservare solamente i processi in cuiè coinvolto direttamente e misuraresolo i componenti su cui abbia realecontrollo. La definizione di differen-ti punti di vista ha come obiettivoquello di classificare quali compo-nenti siano osservabili e misurabilida un determinato attore del sistemae quali informazioni siano necessarie(eventualmente fornite da altri atto-ri) per valutare in maniera adeguata ilivelli di DNS H&S percepiti.

I sei punti di vista attualmentedefiniti 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’Healthdel DNS misurandolo su tre dimensioni differenti:Vulnerabilities, Security e Resiliency.

Il framework meNSa organizza le metriche diVulnerability nelle categorie descritte in sezione 2,ossia: Data corruption (repository e system corrup-tion e protocol issues) e denial of service. Le metri-che di sicurezza che andiamo a proporre non sonospecifiche del mondo DNS e sono intese come uno



Figura 2: Architettura di riferimento.

strumento per valutare la prontezza di risposta del DNSin possibili scenari di attacco atti a minarne il livellodi sicurezza. Per quanto riguarda la Resiliency propo-niamo di utilizzare un set di metriche per la misuradella resilienza di un generico sistema ICT applican-dolo alle problematiche del DNS.

In Tabella 2 sono mostrati alcuni esempi di metri-che che abbiamo identificato. Per la lista completa sirimanda il lettore a [11].

4.2 Le fasi operative del framework

In questa sezione descriviamo le principali fasioperative del framework e in che modo il processo divalutazione concretizza nella pratica.

Scendendo maggiormente nel dettaglio possiamoconsiderare il periodo di funzionamento del frame-work diviso in tre macro-sessioni: PreliminaryDiagnosis, SLO and Scenario Definition, Detailed Diagnosisand Measurement.

Nella fase di Preliminary Diagnosis, scelto undeterminato PoV, viene eseguita una prima valutazio-ne sui livelli di Health percepiti. Questa viene con-dotta attraverso semplici meccanismi di misura (es.tool di monitoraggio) e con il supporto di un sotto-insieme delle metriche proposte.

Nella fase di SLO and Scenario Definition, sulmedesimo PoV, vengono selezionati uno o più sce-nari di minaccia ed al contempo quegli indicatori diDNS H&S che siano rappresentativi e misurabili



Tabella 2: Esempi di metriche per la valutazione di Health e Security del DNS.

Categorie Misure Metriche

Repository Corruption Data Staleness Differenze (in percentuale) di valori SOa tra i server autore-voli su un determinato periodo

zone drift/zone trash Probabilità di incorrere in uno stato di zone drift/zone trash

NS Parent/Chil Data Coherence

Differenze (in percentuale) tra le risposte a query di tipo NStra due zone collegate nella gerarchia del DNS

System Corruption Cache Poisoning Differenze (in percentuale) tra i contenuti di una cache e idati reali

zone Transfer failure Numero di operazioni di "zone transfer" fallite

DNS Spoofing Probabilità di essere attualmente in presenza di un attacco dispoofing e probabilità che ciò avvenga in un determinatoperiodo

Denial of Service Variation of DNS Request per Second

Variazione nel numero di richieste DNS

Incoming bandwidth Consumption

Percentuale di disponibilità della banda

Incoming Traffic Variation Variazione nel traffico DNS

Resiliency mean Time to Incident Discovery

Periodo medio intercorso tra l'identificazione di due attac-chi/incidenti

Operational mean Time between failures

Periodo medio intercorso tra due interruzioni di funziona-mento

Operational availability Percentuale di tempo in cui un sistema ICT è in funzione suun lungo periodo

Security attack Surface Percentuale di nodi di un sistema che è suscettibile ad uncerto tipo di attacco

attack Deepness Percentuale di nodi colpiti in conseguenza di un attacco

attack escalation Speed Numero di attacchi in un determinato intervallo di tempo

annualized Loss expectancy Perdità economica derivante da incidenti al sistema

93

nella specifica situazione.La fase di Detailed Diagnosis and measurement è

infine dedicata alla valutazione di: (1) livelli di H&Spercepiti, (2) raggiungibilità degli SLO, (3) eventualicause di violazione degli SLO, (4) azioni perseguibiliper migliorare la DNS H&S.

Possiamo considerare quest’ultima fase organiz-zata in tre step: selezione delle metriche, misurazioneed aggregazione.

La Metric Selection è un processo eseguito primadella valutazione di un sistema concernente la sceltadelle misure da inserire nel framework. Quest’ultimofornisce infatti agli utenti vari possibili raggruppa-menti di metriche tarati caso per caso in base agli sce-nari di minaccia ed ai PoV.

La Measurement Phase è composta da una fase dicollezionamento dati e, a seguire, una sessione in cuile metriche selezionate nella fase precedente vengo-no calcolate. abbiamo proposto un modello di misu-razione bottom up [9][10] in cui, dopo l’acquisizionedelle informazioni da altri PoV vengono in sequen-za: (1) calcolati indici come network reachability onetwork load che diano un riferimento di quanto lenostre valutazioni siano dipendenti da uno stato,eventualmente critico, dell’infrastruttura fisica e (2)calcolate metriche proprie dell’H&S.

Nella Aggregation Phase vengono combinate tuttele misure collezionate nelle precedenti ottenendo icosiddetti indici aggregati. Questi riassumono infor-mazioni riguardanti: la H&S percepita nel PoV, ilivelli di SLO realmente raggiungibili ed infine lecause di eventuali problemi.

5. Aggregazione delle metriche

Il concetto di Health & Security di un sistemaracchiude in sé aspetti complessi ed è, per questomotivo, difficilmente esprimibile attraverso singolemetriche.

Per una valutazione corretta è necessario consi-derare uno o più indicatori (o indici) aggregati. adesempio, un end user che desideri una valutazioneesauriente, sarà interessato sia ad una classificazionepiù generale della DNS H&S sia ad una valutazionespecifica dei componenti del sistema.

esistono vari modi con cui è possibile aggregarele metriche proposte. In questo documento conside-reremo due approcci (descritti in dettaglio nei para-grafi seguenti). entrambi presentano vantaggi esvantaggi. Prima di entrare nello specifico delle due

metodologie, nel seguito descriviamo i concetticomuni.

Generalmente, dato un PoV, è possibile definire:un indice di Total Evaluation (Te) che esprima unavalutazione generale della DNS Health & Securitypiù alcuni indicatori che rappresentino aspetti piùspecifici del sistema (es. problematiche nei protocol-li, vulnerabilità legate al DDoS, problemi sui compo-nenti, ecc.).

ad uno specifico PoV e agli indici ad esso colle-gati viene sempre associato un insieme di metriche,necessarie al calcolo degli indicatori stessi e misura-bili nel contesto in esame.

Infine, un altro elemento connesso al concetto diPoV è rappresentato dal quality mapping ovvero unafunzione di normalizzazione dei dati relativi allemetriche che li renda adimensionali e confrontabili.

formalmente un PoV comporta l’individuazionedi:

• un insieme di M metriche {m1,…,mM} con Didominio della metrica mi. Dunque diciamo chei valori misurati vi1, vi2,…, di mi appartengonoa Di .

• un insieme di Q funzioni di quality mappingqi: Di→ [0, 1], una per ogni metrica mi. Il map-ping qi trasforma il valore misurato vij in unvalore di qualità adimensionale qij=q(vij), dove0 indica la valutazione più bassa possibile ed 1la più alta.

• un insieme di indicatori aggregati. Ogni indi-catore Ik è definito interamente dal suovettore di pesi wk=(wk1,…,wkM) esso è taleche ∑i=1

M wki= 1 con wki compresonell’intervallo [0, 1].

Nel seguito, per semplicità di rappresentazione,identificheremo sempre il PoV con la prospettiva chel’end user ha del DNS.

5.1 Aggregazione Session-based

Questo tipo di aggregazione matematica richiedeun periodo di misura diviso in diverse sessioniT={s1,…, sS}, il cui numero S (nonché la durata)viene specificato nel PoV ed è indipendente dallemetriche considerate. Il valore di S dipende dall’o-biettivo dell’analisi, dal grado di precisione desidera-to e dai tool utilizzati nel framework. In generale, unalto numero di sessioni rende la valutazionedell’H&S più precisa. Durante ogni sessione, il colle-zionamento di dati prevede la misurazione di un



valore per ogni metrica. Tali valori saranno di volta involta manipolati ed aggregati fino all’ottenimentodegli indicatori finali. alla fine dell’esperimento, gliindici ottenuti precedentemente saranno nuovamen-te combinati insieme col fine di ottenere i valori medie le incertezze di misura.

Per ogni sessione si, i tool di misurazione forni-scono un valore vij per ogni metrica mi. Le misurazio-ni vij sono, in seguito, mappate sui valori di qualità qijattraverso la funzione qi. Per ogni indicatori Ik e perogni sessione calcoliamo l’indice Iki come mediapesata dei valori di qualità attraverso il vettore di pesidell’indicatore stesso. es.

dove Iik è il valore aggregato dell’i-esimo indica-tore Ik. al termine dell’ultima sessione, per ogni indi-catore Ik, viene calcolato il risultato aggregato finaledefinito come valore medio degli indicatori di sessio-ne Iki, mentre la deviazione standard rappresental’incertezza ∆Ik.

Vale la pena notare come questo metodo diaggregazione non permetta di avere valori vij man-canti. In uno scenario reale potrebbe capitare che,durante una sessione sia impossibile ottenere la misu-ra vih della metrica mh, ad esempio a causa di un pro-blema nel tool o della connessione. Questo fa sì cheanche il valore di qih non sia disponibile. In questocaso l’equazione precedente per il calcolo di Ik nonpotrebbe essere calcolata nel caso in cui l’indicatoreavesse wkh≠0. Calcolare la media pesata dei valoricomunque disponibili (dopo averli rinormalizzati)potrebbe essere una soluzione.

Nonostante questo, tale modifica altererebbe ilmodo con cui il vettore di pesi esprime l’importanzadi una metrica per uno specifico indicatore. Inoltre,nel caso in cui tutti i valori vih tale che wkh non fos-sero disponibili, l’equazione precedente non sarebbecomunque utilizzabile. evitare di aggregare tutte

quelle sessioni che avessero un valore mancante è l’u-nica soluzione praticabile per la metodologia propo-sta nonostante l’incertezza sulla valutazione risultimaggiore.

Come spiegato in precedenza, il metodo di aggre-gazione basato su sessioni di tempo prefissato forni-sce un metodo semplice per gestire l’errore di misu-ra, ma in caso di valutazioni mancanti, il risultatorisulterebbe irrimediabilmente meno preciso.

5.2 Aggregazione Metric-based

In questa sezione definiamo un metodo di aggre-gazione delle misure leggermente differente dal pre-cedente.

Diversamente da quanto detto prima, la lunghez-za delle sessioni può variare dipendentemente dallemetriche. Infatti, per ogni metrica mi il tempo vienediviso in Si sessioni {sij} con j=1,…,Si. Il valore diSi e la durata delle sessioni dipende dalla metrica mi especificamente dalla natura della misura. Questo,nella maggior parte dei casi, permette una miglioremisurazione della metrica. Per esempio, alcune metri-che potrebbero aver bisogno di collezionare moltidati in sessioni che non richiedono molto tempomentre altre, al contrario, potrebbero necessitare dipochi dati ma periodi di misura più lunghi. un altrovantaggio di questa metodologia è relativo alla possi-bilità di gestire misurazioni mancanti. Le specifichesulle sessioni possono essere indicate nel PoV omodificate a seconda dei requisiti di sistema (o deitool utilizzati).

Per ogni metrica mi e per ogni sessione sij di mi, ivalori vij sono mappati nei rispettivi valori di qualitàqij attraverso la funzione qi. In seguito calcoliamo ilvalore medio e la deviazione standard sulle Si sessio-ni che rappresentano rispettivamente il valore di qua-lità della metrica mi e il corrispondente livello diincertezza.

formalmente, per ogni metrica mi:

Gli indicatori aggregati sono calcolati comemedie pesate attraverso i vettori di peso. Possiamoottenere una stima dell’incertezza con la media pesa-ta degli errori per ogni metrica. formalmente l’indi-catore aggregato k-esimo e l’errore stimato sono cal-



� ��

�

��

� ��

��

��

� � ��

�

�

� ��

��

��

��

��

��

� ��

�

� �

95

colati come:

In alcuni casi, le metriche possono essere consi-derate indipendenti e dunque la stima dell’errore pre-cedente può essere sostituita con una più precisa cal-colata come segue:

L’ipotesi che le metriche siano indipendenti puòessere a volte troppo forte. Per questa ragione il PoVpuò eventualmente specificare se debba essere usatola prima o la seconda formula nel calcolo di ∆Ik.

L’aggregazione metric-based è più complessadella precedente. Il metodo proposto per aggregaregli errori potrebbe essere sottoposto a revisione nonostante la teoria degli errori sostenga le due strategieproposte. La prima, come già accennato, dovrebbeessere preferita solo nel caso di mutua dipendenzadelle metriche.

un indubbio vantaggio di questa metodologia diaggregazione risiede nella possibilità di gestire sem-plicemente eventuali valori mancanti poiché, perogni metrica, il calcolo viene fatto esclusivamentesulla base delle misure disponibili. Infine, è utilericordare come la flessibilità dello schema possarisultare molto utile in presenza di metriche conrequisiti differenti.

6. Valutazioni sperimentali

Nel seguito vengono presentati un insieme dirisultati sperimentali con lo scopo di mostrare al let-tore come il framework può essere utilizzato e latipologia dei risultati ottenibili. Il caso di studio con-siderato è quello di un end user che accede a conte-nuti informativi mediante un browser; ci collochia-mo quindi nel caso dell’end user PoV.

La stessa metodologia di aggregazione può esse-re applicata al caso del sistema energetico descritto inSezione 3. Ovviamente, nello scenario di operazionidi basso alto livello (Sezione 3.2) ci troviamo in uncaso molto simile a quello mostrato nel seguito.Nello scenario che riguarda operazioni di basso livel-lo invece (Sezione 3.3), il processo di collezionamen-

to dei dati sarebbe diverso ed i vincoli sul livello diservizio sarebbero molto più stringenti.

6.1 Misure e Metriche

Gli esperimenti condotti hanno richiesto la confi-gurazione di due testbed ognuno composto da unamacchina Windows con firefox 8.0 in esecuzione.Nel primo caso il PC era connesso alla rete Internetattraverso l’ISP italiano fastweb (7mbit/s nominali)dal laboratorio di GCSeC mentre il secondo usava larete GaRR con access point l’università di Roma“Tor Vergata” (uTV). Le risoluzioni DNS sono statedemandate rispettivamente ai resolver di fastweb edi uTV.

Ogni test ha collezionato dati su 10-12 sessioni dinavigazione sul web (web browsing). Ogni sessione èdurata dai 10 ai 15 minuti per un totale di 2 ore. Perogni sessione abbiamo collezionato ed analizzatodati ottenendo dunque 10-12 valori per metrica (unoogni sessione).

Nei nostri esperimenti abbiamo considerato, traquelle discusse in [11], le seguenti metriche:

a) Incoming Bandwidth Consumption (IbC): definitacome il rapporto tra l’ammontare dei pacchet-ti di rete in entrata durante una sessione ed iltempo della sessione stessa. Il dominio diquesta metrica è [0, IBCmax] misurato inmbit/s dove il valore di IBCmax rappresenta ilmassimo nominale nella banda dichiaratodall’ISP.

b) Incoming Traffic Variation (ITV): definito, perogni sessione i, come (IBCi - IBCi-1)/ lengthidove IBCi è l’incoming bandwidth consump-tion misurato nell’i-esima sessione. Il dominiodi questa metrica è [-ITVmax, ITVmax](mbit/s2) con:ITVmax=maxi (IBCmax/ lengthi).

c) Traffic Tolerance (TT): misurata con il RoundTrip Time di un pacchetto IP in transito tra lamacchina dell’end user ed il recursive resol-ver dell’ISP. Il dominio della metrica è [0,∞]misurato in secondi.

d) Stub Resolver Cache Poisoning (CP): misurataattraverso la percentuale di entry della cacheavvelenate. Il dominio è [0, 100]. Ogni entrydella cache è controllata usando un insieme direcursive resolver noti.

e) DNS Requests per Second (DNSR): definitacome il numero di richieste DNS fatte duran-



� ��

�

��

� � ��

�

��

� � ��

�

��

��

te la sessione. Il dominio è [0,∞].f) Rate of Repeated Queries (RRQ): definita come il

numero di richieste DNS ripetute. un com-portamento corretto dell’infrastruttura,durante una breve sessione di lavoro concaching attivo, sarebbe quello di risolvere ilnome di dominio solo una volta. La presenzadi numerose query DNS per la medesimainformazione può essere un segnale di un fun-zionamento non corretto. Il dominio è [0,∞].

Quello che segue è invece l’insieme di funzione diquality mapping per le metriche precedentementedefinite:

g) Incoming Bandwidth Consumption (IbC): siaIBCmax il massimo valore di banda fornitodall’ISP. La funzione di quality mappingq: [0, IBCmax]→ [0, 1] per questa metrica è defi-nita come:

h) Incoming Traffic Variation (ITV): la funzione diquality mapping q: [-ITVmax, ITVmax]→ [0, 1]per la metrica ITV è definita come:

i) Traffic Tolerance (TT): sia RTTavg il valore mediotra gli RTT durante la sessione. Definiamo lafunzione di quality mapping q: [0,∞]→ [0, 1]per la metrica TT come:

j) Cache Poisoning per lo Stub Resolver (CP-SR): lafunzione 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, abbiamodeciso di mappare un risultato del 10% dientry avvelenate su un valore di qualità vicinoa 0.6 ottenibile con k=20.

k) DNS Requests per Seconds (DNSR): la funzionedi quality mapping permette di confrontare ilcomportamento corrente del DNS con un

riferimento misurato a priori. Sia DNSRavg ilnumero medio di richieste DNS al secondodurante una normale sessione. La funzione diquality mapping q: [0, 100]→ [0, 1] per questametrica è definita come:

l) Rate of Repeated Queries (RRQ): sia Rmax il mas-simo numero di richieste DNS nella sessionecorrente. Vale la pena notare come Rmax possacambiare tra le varie sessioni. La funzione diquality mapping q: [0,∞]→ [0, 1] per questametrica è definita come:

6.2 Aggregazione

La figura 3 mostra i valori di qualità e l’aggrega-zione eseguita con il metodo session-based. Lafigura 4 mostra invece i medesimi valori ma con irisultati dell’aggregazione metric-based.

Per ogni sessione, le stime di qualità delle metri-che sono combinate nei seguenti indici aggregati(questi indici sono propri dell’end user PoV):

m) Total Evaluation (Te): fornisce una valutazioneglobale del PoV attraverso l’aggregazione ditutte le metriche considerate nella prospettiva.È interessante notare come la metrica diCache Poisoning possa essere interessata daproblemi relativi a falsi positivi. Per questaragione abbiamo deciso di considerarla menoinfluente nella valutazione finale del sistema.Dunque il peso della metrica CP nel risultatodell’indicatore Te sarà più basso rispetto allealtre metriche. Questo avrà l’effetto di ridurrel’impatto dei suddetti falsi positivi sul risultatofinale.

n) Protocol Issues (PI): stima eventuali problemi neiprotocolli del DNS. Nel nostro PoV è legatosolo alla metrica del cache poisoning.

o) Denial of Service (DoS): valuta quanto siaimprobabile la presenza di un attacco DoSnello scenario corrente. aggrega tutte lemetriche meno quella di cache poisoning.

p) NET: stima le performance del componenterete. Le metriche aggregate saranno: Incoming



� ��

��

� ��

��

� ��

��

��

� ��

� ��

� ��

� ��

� � ��

� ��

��

97

bandwidth Consumption, Incoming TrafficVariation, Traffic Tolerance.

q) Stub Resolver (SR): valuta le performance relati-ve allo Stub Resolver. aggrega le metriche diCache Poisoning, DNS Requests Variation perSecond, Rate of Repeated Queries. La metri-ca CP anche in questo caso ha un peso infe-riore per evitare che i falsi positivi abbiano unimpatto preponderante nella valutazione.

6.3 Valutazioni finali

La Total evaluation rappresenta il risultato finaledell’end user PoV. esso rispecchia le perfomancedel sistema concentrandosi sui servizi del DNS cheun utente è in grado di misurare. In questo scenariopossiamo accettare piccoli disservizi come ad esem-pio problemi temporanei dell’infrastruttura risolvibi-li semplicemente ricaricando una pagina web. Perquesta ragione valori dell’indicatore Te intorno allo0.8 sono possibili in un sistema che funzioni adegua-tamente. Con il nostro framework è possibile dunque

verificare la qualità del servizio edeventualmente controllare se vi fos-sero violazioni sugli SLO.

Nel primo esperimento vengonocollezionate le misure dalla reteGCSeC e vengono valutati i risulta-ti ottenuti per entrambi i metodi diaggregazione discussi precedente-mente (vedi figura 5). I valori otte-nuti per gli indicatori sono abbastan-za simili. La Total evaluation è 0.76in tutti e due i casi. Questo valorequantifica i livelli di H&S effettiva-mente percepiti dall’end user. Glialtri risultati aggregati danno unavalutazione delle perfomance deidifferenti aspetti del servizio e suisingoli componenti. Questa infor-mazione può essere importante permigliorare le perfomance del siste-ma, perché permette di evidenziaresu quali elementi eventualmentebisogni concentrarsi in casi di mal-funzionamento. I nostri calcolimostrano come lo Stub Resolver siail componente in cui, con maggioreprobabilità, possa essere riscontratoun problema poiché il valore di SR èabbastanza distante da 1 (~0.66).

Invece, il componente di rete (NeT) ha una valuta-zione positiva (~0.85). È importante notare chesarebbe possibile fare un’ulteriore analisi se i risultatidella prospettiva Recursive Resolver fossero disponi-bili come input all’end user PoV. aggregare talivalori con le metriche calcolabili localmente incre-menterebbe l’accuratezza della valutazione generale erifinirebbe quella dei singoli componenti.

analizzando i risultati ottenuti è possibile evince-re anche informazioni sui possibili scenari di minac-cia che potrebbero influenzare l’infrastruttura.alcuni indicatori danno informazioni sulla probabili-tà che un certo attacco sia in corso. Nel nostro espe-rimento, ad esempio, i valori alti negli indici PI e DoS(rispettivamente attorno a 0.7 e 0.8) indicano, conbassa incertezza, che il sistema non era affetto daproblematiche come Protocol Issues e Denial ofService al momento della misurazione.

Nel secondo esperimento abbiamo usato il fra-mework per misurare i livelli di Health and Securitydel DNS nella rete GaRR. In questo caso abbiamodeciso di utilizzare la metodologia di aggregazione



Figura 3: Valori calcolati attraverso l’aggregazione session-based.

Figura 4: Valori calcolati attraverso l’aggregazione metric-based.

session-based.La Total evaluation (vedi figura 6) assume il

valore 0.8 con un incremento di circa il 5% se para-gonata al test eseguito nel laboratorio di GCSeC.Questo è dovuto soprattutto all’ottimo risultato otte-nuto dalla metrica di cache poisoning (oltre 0.85).entrambi i componenti NeT e Stub Resolver hannobuone performance: il primo è stimato 0.86 mentre ilsecondo si attesta poco sopra 0.7.

mentre gli indicatori precedenti mostrano risulta-ti su elementi dell’infrastruttura, come abbiamoaccennato prima, DoS e PI descrivono una valuta-zione su degli scenari di minaccia. I valori di questi

due indici sono rispettivamente 0.8 e0.85. Per questo motivo, ancora unavolta, possiamo escludere l’ipotesi incui il sistema sia sotto attacco di denialof service o abbia problemi a livello diprotocolli.

Infine, nell’ultimo esperimento,abbiamo simulato del cache poisoningcon l’intento di validare la nostrametodologia di valutazione. Il cachepoisoning è stato implementato cor-rompendo manualmente il 10% delleentry della cache DNS in una macchi-na del laboratorio di GCSeC.

In conseguenza, la Totalevaluation del sistema (vedi figura 7)scende a 0.7. Il componente NeT èancora stimato attorno a 0.8 ma lavalutazione dello Stub Resolver scen-de a 0.6. Questi risultati descrivono lapresenza di problemi nelle librerie diimplementazione del DNS del sistemaoperativo, come del resto ci aspettava-mo. Proseguendo nel processo divalutazione scopriamo che la nostrainfrastruttura è sottoposta, senza dub-bio, a problematiche legate ai proto-colli dato che l’indicatore di ProtocolIssues è 0.38. L’indice DoS rimaneinvece sopra 0.75.

È significativo sottolineare come irisultati dell’ultimo esperimento guidi-no l’utente direttamente alle contro-misure da effettuare per migliorare leprestazioni del sistema. Il confrontodegli indicatori relativi ai componenticon quelli legati alle minacce ci per-mette di identificare con esattezza (edunque di intervenire) sul problema di

cache poisoning. Infatti, nel resoconto di valutazionefinale il framework dovrà suggerire all’utente di can-cellare la cache DNS. Consigliare inoltre di ripetere lavalutazione subito dopo permetterà anche di avereun’immediata validazione della correttezza dell’azio-ne intrapresa.

È importante infine notare come i test eseguitinon siano da considerare generali e come dunqueessi debbano ancora essere suffragati da un piùampio insieme di esperimenti. Il nostro obiettivo èstato quello di mostrare come sia possibile misuraredelle caratteristiche dell’infrastruttura e come le



Figura 5: Valori degli indici aggregati per la valutazione del livello di H&S effettuando lemisure dalla rete GCSEC.

Figura 6: Valori degli indici aggregati per la valutazione del livello di H&S effettuando le misure dalla rete UTV.

99

metriche identificate possano essere utilizzate edaggregate per investigare la DNS Health & Security.

7. Conclusioni

Questo lavoro analizza il DNS come infrastruttu-ra critica e pone l’accento su come da essa dipendo-no altre infrastrutture critiche, portando l’esempiodella rete di distribuzione elettrica. Sono stati consi-derati vari aspetti: le vulnerabilità del DNS, la neces-sità di un framework per la misura del livello di sicu-rezza, stabilità e resilienza (o più ad ampio spettro dihealth) del DNS, come le vulnerabilità del DNSimpattano l’operatività del sistema di distribuzioneenergetica, ed infine sono stati portati degli esempi dimisura del livello di health e security del DNS.

Per quanto riguarda la misura del livello di sicu-rezza, stabilità e resilienza, abbiamo proposto il fra-

mework meNSa che ha l’ambiziosoobiettivo di definire una metodologia,metriche e strumenti per la misura delDNS. La realizzazione di tale frame-work è estremamente sfidante sia dalpunto di vista modellistico che tecno-logico, ma soprattutto dal punto divista politico. Nonostante i proclamidella comunità (ICaNN e DNS-OaRC prevalentemente) riguardoalla necessità di condividere le infor-mazioni tra gli operatori del DNS, difatto, poco o niente viene condivisoe/o reso pubblico. Non ci sono stan-dard per la misura, non vi sono stan-dard per la condivisione delle infor-mazioni, non vi è un’entità (centrale odistribuita) in grado di coordinare le

risposte ad attacchi al DNS. Siamo convinti che il progetto meNSa, possa

essere un primo passo per dare delle soluzione aparte dei problemi citati e soprattutto possa fornirestrumenti utili sia per gli operatori, sia per gli utentifinali (siano essi operatori critici o consumatori best-effort) per contribuire a creare un DNS più sano esicuro. Inoltre, il framework meNSa vuole fornireuna base metodologia per la realizzazione di unDNS-CeRT.

Il metodo di aggregazione presentato, che è unadelle parti più importanti del framework, deve indub-biamente essere validato con dati reali, ed i risultatisperimentali hanno il solo obiettivo di mostrare unesempio di funzionamento del modello proposto.

Nel medio-lungo termine il progetto prevede unavalidazione della metodologia su più larga scala e pergli altri punti di vista definiti. Inoltre è anche previ-sto un raffinamento delle metriche proposte.



Figura 7: Risultati degli indicatori aggregati nel caso in cui venga introdotto del cache poisoning.

BIBLIOGRAFIA

[1] eastWest Institute, “Working Towards Rules for Governing Cyber Conflict: Rendering the Geneva andHague Conventions in Cyberspace”, 2011, 12.

[2] Sebastian Castro, Duane Wessels, marina fomenkov, and Kimberly Claffy, “a day at the root of the inter-net”, SIGCOmm Comput. Commun. Rev. 38, 5 (September 2008), 41-46.

[3] DNS-OaRC, The Day in the life of Internet (DITL) project.[4] 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.



[5] y. Sekiya, K. Cho, a. Kato and J. murai, “Research of method for DNS performance measurement andevaluation 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 DNSSecurity, 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 ver-sion 1.0 may 3, 2007.

[9] e. Casalicchio, m. Caselli, D. Conrad, J. Damas, I.N. fovino, “Reference architecture, models andmetrics”, 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 userPoV”, 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”, GCSeCReport, Version 1.0, may 2011 (available at http://www.gcsec.org).

Stabilità, Sicurezza e Resilienza del DNS e loro impatto ...DNS stesso ed il crescente numero di...

Documents

Transcript of Stabilità, Sicurezza e Resilienza del DNS e loro impatto ...DNS stesso ed il crescente numero di...