Metodologie e tecniche per la sicurezza delle reti aziendali

Transcript

1 Corso di laurea in Scienze e tecnologie dell informazione Metodologie e tecniche per la sicurezza delle reti aziendali RELATORE Prof. Ernesto Damiani TESI DI LAUREA DI Lorenzi Stefano CORRELATORE Matr Dott. Claudio Agostino Ardagna Anno Accademico 2011/2012

2 Dedica La generazione dei numeri casuali è troppo importante per essere lasciata al caso. Robert R. Coveyou

3 Ringraziamenti Sonodiverselepersonechevorreiringraziare, echeinmododiversomihanno aiutato a portare a termine questo ciclo di studi. Ringrazio innanzittutto Monica e Leonardo per la pazienza avuta in questi anni, e per avermi appoggiato in questo cammino. Ringrazio il Dott. Claudio Agostino Ardagna per la pazienza avuta nel correggere questo lavoro Ringrazio l azienda Selex Elsag CyberLabs, per la quale lavoro, per la possibilità datomi di poter affrontare questa ricerca anche in ore lavorative, e tutti i colleghi, che in questi anni mi hanno aiutato a crescere professionalmente, e con i quali, quotidianamente c è un piacevole confronto sulle tematiche affrontate in questo lavoro. Ringrazio gli amici Luca e Giusy, perchè questo percorso universitario ebbe inizio, quasi casualmente, da un invito a cena a casa loro. 2

4 Prefazione L interdipendenza delle reti informatiche è in aumento, determinando nuove criticità e rischi tra i diversi sistemi, ormai fortemente integrati tra loro, interdipendenti e basati su piattaforme condivise. Oltre a disguidi tecnici, nuove minacce arrivano anche da tipologie di attacchi che fino a poco tempo fa sembravano solo teorici. Prendiamo come esempio Stuxnet, un worm informatico in grado di spiare e riprogrammare pc e plc industriali. E ormai evidente che è indispensabile proteggere tutte le nostre infrastrutture con nuove metodologie, con particolare attenzione a quelle informatiche. L obiettivo di questo lavoro di tesi è l analisi di un nuovo modello che possa fotografare nel modo più completo e dettagliato possibile il livello di sicurezza dell infrastruttura presa in considerazione e, nel limite del possibile, di migliorarla. Il progetto di tesi propone un analisi generale dell ambiente partendo dall applicazione e dall infrastruttura, fino ad arrivare ai dati transitanti dalla rete, analisi che mette in evidenza le vulnerabilità in modo da identificare con precisione dove e perché intervenire, minimizzando i rischi per il business asset. La metodologia presentata in questo lavoro di tesi si caratterizza per la circolarità e la suddivisione del Vulnerability Assessment in 3 livelli: infrastrutturale, applicativo, policy aziendali. Per quanto riguarda l analisi applicativa, in particolar modo per il mondo 3

5 web, OWASP rappresenta le fondamenta per questo tipo di analisi; essa sostiene che si raggiunge la sicurezza di un applicativo by design, ossia all interno del ciclo di vita del software. L analisi applicativa si suddivide in due parti, white e black box. La prima tecnica identifica le vulnerabilità a partire dal codice sorgente del componente, la seconda attraverso un insieme di test mirati. Nell attività di VA è presente il problema di degradazione, in quanto nel tempo, sia nuovi asset che nuovi applicativi vengono aggiunti e nuove vulnerabilità vengono scoperte, modificando in questo modo la situazione analizzata precedentemente. La tesi mette in evidenza l inadeguatezza di un approccio tradizionale con scansioni usando tool di vulnerability scanner (Nessus, Nikto etc..) e le possibilità date da un approccio complementare, come l uso del passive vulnerability scanner (PVS), ossia il continuo monitoraggio del traffico di rete. In questo modo, verrebbe gestito almeno in parte il problema della degradazione del VA tradizionale. Inoltre, PVS osserva quali sistemi sono attivi, con quali protocolli comunicano e con chi comunicano, quale applicazione eseguono e quale vulnerabilità sono presenti. Queste informazioni vengono poi confrontate con le policy aziendali e l Information Technology (IT) valuterà di conseguenza se bloccare o meno una determinata tipologia di traffico. E comunque fondamentale che la sicurezza di una struttura informatica non sia un attività fine a se stessa, ma in continua evoluzione. Sarà quindi necessario, ciclicamente, analizzare la robustezza dell infrastruttura e degli applicativi, affinché nuove vulnerabilità vengano scoperte. Sia i sistemi operativi che le applicazioni vengono continuamente aggiornate, con il rischio di introdurre nuove vulnerabilità. Il lavoro di tesi lascia spazio ad alcuni sviluppi futuri. Primo fra tutti, l appro- 4

6 fondimento del vulnerability assessment nell ambito delle basi di dati. Lavori futuri riguardano anche la ricerca di una metodologia atta a rilevare gli Advance Persistent Threat (APT). Tale metodologia permetterà di aggiungere le signature degli APT rilevati nelle regole dei sistemi di Intrusion Detection System (IDS), in modo da rendere l infrastruttura ancora più sicura. 5

7 Indice Introduzione 13 1 Risk Analysis Standard ISO La famiglia ISO Standard ISO Standard ISO Progettare un vulnerability assessment Definizioni della terminologia Vulnerability scan Vulnerability assessment Risk assessment Penetration Test Security assessment Security Auditing Cos è un vulnerability assessment Le vulnerabilità Le categorie delle vulnerabilità Limitazioni di un VA

8 3 Vulnerabilità infrastrutturali Vulnerability scanner Nessus Nmap Microsoft baseline security analyzer Nikto Modalità d uso di un vulnerability scanner Performance Analysis Valutazione prestazionale e affidabilità di Sistemi Complessi RAMS Reliability - Affidabilità Availability - Disponibilità Maintainability - Mantenibilità Safety - Sicurezza Tecniche di Analisi e Modellazione dei Sistemi Software Tool per stress test Owasp Cos è Owasp? TOP I tool di OWASP Vulnerabilità applicative Vulnerabilità applicative SQL injection Cross-site scripting Le Cross-Site Request Forgeries Buffer Overflow

9 7 Assessment applicativo Analisi della web application Analisi dinamica (black box analysis) IBM AppScan ZAP Considerazioni Analisi statica (white box analysis) Extranet services Considerazioni Ciclo di vita del software Passive vulnerability scanner Cos è un passive vulnerability scanner Vantaggi di un passive scanning PVS & vulnerability scanner Risk Exposure Analyzer Risk Analisisys overview Skybox Security Caso di studio Web Application Firewall Caratteristiche dei WAF WAF e scansione applicativa Conclusioni 139 A Raccolta dati e reportistica 143 A.1 MagicTree

10 Elenco delle figure 1 Processo per la messa in sicurezza di una infrastruttura Suddivisione in livelli della messa in sicurezza di una rete Shema Risk Analysis ISO Framework ISO ISO Suddivisione dei processi SANS Vulnerability Finestra temporale di una vulnerabilità. Fonte [5] Controllo remoto di un prompt dos Creazione di un policy con Nessus Nmap Microsoft baseline security analyzer Nikto Schema di rete Classificazione dei guasti all interno di un sistema Andamento caratterisco di Z(t) Availability

11 4.4 Sistema in serie Sistema in parallelo Safety Sicurezza - Costi Modello di Metodologia di Test Finestra temporale di una vulnerabilità Owasp Zap SDLC OWASP Guidelines e tools Struttura Web Application Tipologie di security test Esplorazione e analisi di una web application Proxy Zap Distribuzione delle vulnerabilità in modalità statica e dinamica SLDC cattura del traffico Firefox Risk Exposure Analysis CIA Mappa di rete Skybox prima del bilanciamento CIA Skybox dopo del bilanciamento CIA Riscontro scansione applicativa e WAF WAF in modalità offline WAF in modalità inline

12 A.1 MagicTree

13 Elenco delle tabelle 5.1 Security web tool tool per analisi statica Caso specifico dell intersezione Visualizzazione vulnerabilità, scanner applicativo e un WAF. 137 A.1 MagicTree tool riconosciuti

14 Introduzione I computer si sono diffusi moltissimo in questo ultimo ventennio, e le reti informatiche stanno diventando ogni giorno sempre più complesse. Anche la loro accessibilità e la loro interdipendenza è in aumento, ed è proprio quest ultima a determinare nuove criticità e rischi tra i diversi sistemi, ormai fortemente integrati ed interdipendenti, basati su piattaforme condivise. Un esempio è certamente quello accaduto nel 1998 al Galaxy IV, il satellite per telecomunicazioni in orbita geo-stazionaria sulla costa occidentale degli Stati Uniti. Il suo guasto comportò ritardi di diverse ore per una ventina di voli della United Airlines in fase di decollo a causa della mancata comunicazione del clima in quota; alcune emittenti radiofoniche rimasero oscurate. Ma la cosa più sorprendente furono le conseguenze sul sistema di trasporto viario. Infatti, per l impossibilità di trattare le carte di credito nelle aree di servizio lungo le autostrade, che utilizzavano le comunicazioni satellitari per la connessione con i circuiti degli enti emettitori, ci furono notevoli difficoltà nell effettuare anche i rifornimenti di carburante ai veicoli.[12] La qualità della vita, la sicurezza e lo sviluppo nei paesi industrializzati dipendono ormai fortemente dal funzionamento continuo e sempre più coordinato di un insieme di infrastrutture che, per la loro importanza e strategicità, sono definite Infrastrutture Critiche, come ad esempio: le varie reti di comunicazione; 13

15 le reti e le infrastrutture di trasporto persone e merci (aereo, navale, ferroviario e stradale); il sistema elettrico ed energetico; le reti a supporto del Governo, delle Regioni ed enti locali; i circuiti economico finanziari. Un altro caso si è verificato il 28 settembre del 2003, quando la rete elettrica italiana è stata separata dalla rete europea portando così ad un collasso del sistema elettrico. Non è semplice valutare il danno economico di questo black-out, ma una stima è stata valutata intorno ai 640 milioni di Euro. [11] Oltre ai disguidi tecnici, da cui bisogna ad ogni modo proteggersi, altre minacce arrivano da nuove tipologie di attacchi che fino poco tempo fa sembravano solo teorici. Prendiamo come esempio Stuxnet, un worm informatico in grado di spiare e riprogrammare pc e plc industriali. Tale worm è stato scoperto a metà del 2010; pare che la sua implementazione risalga a inizio Symantec afferma che la maggior parte di pc infetti si trova in Iran: da qui le speculazioni in base alle quali l obiettivo del virus potrebbero essere le centrali nucleari in costruzione nel paese asiatico. La contaminazione è iniziata tramite una chiavetta USB (presente praticamente in tutti i pc) per poi diffondersi attraverso la rete. La complessità di Stuxnet è insolita per un virus informatico in quanto l attacco richiede la conoscenza dei processi industriali e mira all attacco a infrastrutture industriali. Considerata la complessità del virus, per la sua realizzazione si sarebbe dovuto impiegare un team di programmatori di diverse discipline e la verifica di sistemi reali per evitare di bloccare il funzionamento del PLC. Secondo i tecnici Siemens, la creazione di questo malware avrebbe richiesto mesi se non anni di lavoro se 14

16 eseguita da una sola persona. Nonostante la sua giovane età, questo worm ha già subito diverse varianti: questo indica come gli sviluppatori di stuxnet siano attivi sul loro progetto. [15] Un nuovo modello per mettere in sicurezza una rete E ormai evidente che dobbiamo iniziare a proteggere tutte le nostre infrastrutture anche con nuove metodologie, con particolare attenzione a quelle informatiche ed è per questo motivo che questo lavoro vuole analizzare un nuovo modello, il cui obiettivo è quello di fare una fotografia il più completa e dettagliata possibile del livello di sicurezza dell infrastruttura presa in considerazione. Approccio - Il focus in questo genere di iniziativa è quello di valutare il livello di sicurezza di un Core Business Service nel suo complesso, o quanto meno di tutte le componenti tecnologiche che lo compongono; Check-up completo- Oggi i budget a disposizione della security vengono normalmente dispiegati su perimetri molto estesi ma estremamente verticali; es. su tutta l infrastruttura perimetrale, oppure su tutti i server dell infrastruttura interna, oppure su tutta la rete, oppure ancora solo su diverse applicazioni web, solo sui client, ecc. Come detto sopra, focalizzando l assessment su un unico Core Business Service, possiamo permetterci di analizzare in maniera minuziosa tutte le componenti tecnologiche che lo abilitano (infrastruttura perimetrale, infrastruttura interna, applicazioni, DB, client, ecc.) in modo da individuarne eventuali vulnerabilità tecniche e organizzative e/o di sicurezza fisica 15

17 afferenti allo specifico servizio di business. Il concetto di fondo è che individuate 100 vulnerabilità sul Core Business Service, verosimilmente l 80%, o più di queste saranno sicuramente presenti anche sulle componenti che abilitano tutti gli altri Business Service. In ultima analisi, l approccio di questo lavoro consente all ente interessato, a fronte dell esito dell assessment svolto su uno dei suoi servizi di business e messo a conoscenza dei propri processi interni usati per mettere in sicurezza tutti gli altri servizi, di andare ad applicare per analogia le evidenze emerse sul servizio analizzato agli altri componenti. Quello che si vuole proporre è un analisi generale dell ambiente partendo dall applicazione e dall infrastruttura, fino ad arrivare ai dati transitanti dalla rete. Tale analisi metterà in evidenza le vulnerabilità in modo da identificare con precisione dove e perché intervenire, al fine di minimizzare il più possibile il livello di rischio del proprio business asset. Possiamo quindi pensare che il processo utile per mettere in sicurezza una rete, possa i seguenti passi 16

18 Fig. 1: Processo per la messa in sicurezza di una infrastruttura In prima analisi, un azienda deve valutare i propri rischi, a seconda del suo core bussiness, e valutare anche quanto investire nella sicurezza della sua infrastruttura. Successivamente, con l esecuzione di Vulnerability Assessment, è possibile avere una prima fotografia della sicurezza, ed essere a conoscenza di eventuali vulnerabilità presenti nel sistema operativo,applicazione o db. Successivamente, attraverso l uso di un IDS, sarà possibile valutare cosa transita nella rete, e attraverso pattern match, valutare se il traffico passante possa considerarsi lecito o meno. La figura 2 vuole mostrare come si potrebbe suddividere la gestione della messa in sicurezza di una infrastruttura. 17

19 Fig. 2: Suddivisione in livelli della messa in sicurezza di una rete Come vedremo nei capitoli successivi, i punti chiave da prendere in considerazione sono 3, ossia controlli di tipo 1. Infrastruturale: prende in considerazione la parte hardware del mondo IT, come i server, client, firewall etc; 2. Applicativo: prende in considerazione gli applicativi presenti sull infrastruttura, dall implementazione alla configurazione; 3. Policies: prende in considerazione le regole imposte dall azienda, tipicamente gestite dal Security Manager aziendale. In questo lavoro si vuole analizzare una metodologia per mettere in sicurezza una rete aziendale di grandi dimensioni. Per fare questo, è necessario prima fare una analisi dei rischi in modo da valutare il grado di Confidentiality, Integrity, Availability (CIA) che si vuole dare all azienda. Successivamente verrà fatta una fotografia della rete attraverso un approccio semitradizionale di Vulnerability Assessment (VA). Questo permetterà di dare un 18

20 primo output al cliente in tempi rapidi. Come vedremo, l approccio tradizionale oltre a generare un alto traffico di rete, soffre del problema di degradazione. Per ovviare, almeno in parte, a questi problemi, l integrazione di un sistema di Intrusion Detection System (IDS) può essere d aiuto. La tesi è organizzata come segue: Capitolo 1: breve riassunto dei principali standard che riguardano gli aspetti del mondo ICT; in particolare vengono prese in considerazione famiglie ISO [6] [7] [8]. Capitolo 2: si imposteranno le basi di un attività di VA, chiarendo la terminologia, troppo spesso usata a sprosito. Verrà illustrato il concetto di vulnerabilità e il suo ciclo di vita. Infine, verranno discussi alcuni limiti di questa attività. Capitolo 3: in maniera sicuramente non esaustiva, verranno presi in considerazione i principali tool usati nelle attività di vulnerability scan. Capitolo 4: verrà introdotto il concetto dell acronimo Reliability (affidabilità), Availabity (disponibilità), Maintainability (manutenibilità), Safety(sicurezza) conosciuto con l acronimo Rams con valutazioni delle prestazioni dell infrastruttura analizzata. Capitolo 5: viene descritta la metodologia OWASP [10], standard de facto nella sicurezza applicativa. Vengono anche discussi alcuni tool messi a disposizione dall associazione OWASP per questo tipo di analisi. 19

21 Capitolo 6: vengono discusse le principali vulnerabilità applicative, con particolare attenzione al mondo web, e come quest ultime possono essere sfruttate da malintenzionati. Capitolo 7: assessment applicativo, differenza tra analisi white box e black box. Verranno discusse queste due modalità, che viste sotto due insiemi differenti, ma con una parte di intersecazione aiuterà ad una eliminazione veloce dei falsipositivi. Capitolo 8: verrà introdotto l uso di un Intrusion Detection System (IDS), per la ricerca di vulnerabilità. Analizzando in maniera passiva il traffico passante in una rete è possibile trovare alcune vulnerabilità, oppure vedere violazioni di policy aziendali. Questa attività non genererà traffico aggiuntivo come dimostrato nel capitolo precedente e si rivelerà complemetare al vulnerability assemente tradizionale. Capitolo 9: pesare correttamente le vulnerabilità trovate è fondamentale. Come vedremo, i tool usati danno spesso una classificazione del tipo alta, media o bassa. La stessa vulnerabilità trovata su un server web non può avere lo stesso peso della stessa vulnerabilità trovata su server di stampa. Capitolo 10: si approfondirà l uso di un WAF (Web Application Firewall) per mediare le vulnerabilità. A seguito di un alto numero di vulnerabilità trovate, non sempre è possibile sistemarle tutte in tempi brevi, mentre con l uso di questi strumenti alcune possono essere mediate, per essere sistemate successivamente. 20

22 Capitolo 1 Risk Analysis Quando si gestisce una grande infrastruttura informatica e si lavora quotidianamente per la sua sicurezza è indispensabile avere ben chiaro quale tipo di sicurezza si vuole raggiungere (visto che è impossibile pensare alla sicurezza al 100%). Deve essere chiaro a quale rischio l azienda è esposta, e a seconda del proprio core bussiness, valutare anche quali sono le priorità di remediation. Tipicamente, a seconda delle proprie esigenze e della disponibilità economica aziendale, viene anche predisposto un certo budget per trovare il giusto bilanciamento tra necessità e disponibilità. Nei capitoli successivi vedremo come trovare eventuali vulnerabilità presenti nell infrastruttura o nelle applicazioni. Ma deve essere chiaro fin da subito che ogni vulnerabilità, andrà valutata in base al contesto, e quindi ripesata rispetto al risultato che avremo. E il caso ad esempio, di una vulnerabilità presente sia su un server web che su un server di stampa, probabilmente, daremo priorità al server web, in quanto contiene dati più sensisibili rispetto al server di stampa. Come mostrato in [1], nella pratica, nel risk analysis è necessario valutare i seguenti punti: 21

23 esigenze in termini di sicurezza; tipologia del dato trattato; traffico di rete; hardware a disposizione; software utilizzato; Servizi che si vogliono offrire. Fig. 1.1: Shema Risk Analysis Negli anni sono state implementate diverse best practice, per la gestine dell analisi dei rischi, nel paragrafo successivo, vuole mostrare un breve riassunto su alcuni standard International Standard Organization (ISO). Si demanda naturalmente alla documentazione ufficiale per maggiori dettagli. 1.1 Standard ISO Lo Standard ISO 27001, è stata scritto nel 2005, riporta una serie di linee guida al fine di gestire un Sistema di Gestione della Sicurezza delle Informazioni (SGSI o ISMS dall inglese Information Security Management System), 22

24 questa linee guida includono aspetti relativi alla sicurezza logica, fisica ed organizzativa. Come vedremo in questo lavoro, i dati possono essere fortemente a rischio, infatti violazioni dei sistemi informatici, come sostengono molte statistiche sono fortemente in aumento. L obiettivo della ISO è proprio quello di proteggere le informazioni/dati, al fine di garantire l integrità, la riservatezza e la disponibilità, e fornire al tempo stesso,i requisiti per adottare un adeguato sistema di gestione della sicurezza delle informazioni (SGSI) finalizzato ad una corretta gestione dei dati sensibili dell azienda. Come la maggior parte delle ISO, anche la 27001, è stata scritta per poter essere applicata alla maggior parte dei settori commerciali. Inoltre questo standard, stabilisce i requisiti per il Sistema di Gestione della Sicurezza delle Informazioni (ISMS). L obiettivo principale è quello di creare un sistema per la gestione del rischio e la protezione delle informazioni e degli asset ICT. La norma non è business oriented, ed è quindi applicabile a diverse tipologie di imprese, siano esse private o pubbliche. E fondamentale però l adozione e gestione di un ISMS che a sua volta richiede un impegno di risorse significativo, per questo motivo spesso è un ufficio specifico che in genere coincide con l ufficio Organizzazione e Qualità. Essa specifica i requisiti per impostare, mettere in opera, utilizzare, monitorare, rivedere, manutenere e migliorare un sistema documentato all interno di un contesto di rischi legati alle attività centrali dell organizzazione. Dettaglia inoltre i requisiti per i controlli di sicurezza personalizzati in base alle necessità di una singola organizzazione o di una sua parte. Il sistema è progettato per garantire la selezione di controlli di sicurezza adeguati e proporzionati. Riassumento lo standard prevede: pianificazione e progettazione; identificazione dei rischi; 23

25 analisi e valutazione; selezione degli obiettivi di controllo e attività di controllo per la gestione dei rischi; assunzione del rischio residuo da parte del management; implementazione; monitoraggio; mantenimento e il miglioramento. All interno dello standard ISO è presente l Annex A Control objectives and controls che contiene oltre 100 controlli a cui, l organizzazione che intende applicare la norma, deve attenersi. Questi controlli spaziano su diversi argomenti, dalla politica e l organizzazione per la sicurezza alla gestione dei beni e alla sicurezza delle risorse umane, dalla sicurezza fisica e ambientale alla gestione delle comunicazioni e dell operativo, dal controllo degli accessi fisici e logici alla gestione di un monitoraggio e trattamento degli incidenti (relativi alla sicurezza delle informazioni). La gestione della Business Continuity e il rispetto normativo, completano l elenco degli obiettivi di controllo. L organizzazione deve motivare quali di questi controlli non sono applicabili all interno del suo ISMS, per esempio un organizzazione che non attua al suo interno commercio elettronico può dichiarare non applicabili i controlli del A.10.9 che si riferiscono appunto all e-commerce. 1.2 La famiglia ISO LafamigliaISO31000(checomprendela31000ela31010)èstatapubblicata nel 2009, con l intento di fornire uno standard per l attuazione della gestione 24

26 dei rischi. Lo scopo di tale norma è quello di essere applicabile e adattabile per qualsiasi impresa pubblica, privata, associazione, gruppo o individuo, ne consegue che come una famiglia di standard di gestione del rischio, non è sviluppato per un particolare gruppo di settore, ma piuttosto vuole fornire la struttura delle best practice da seguire nelle operazioni che si occupano di gestione del rischio. Lo scopo della norma ISO è quello di fornire principi e orientamentigenerali sulla gestione del rischio. questo standard mira a fornire un paradigma universalmente riconosciuto per i professionisti e le società che si occupano nei processi di gestione del rischio per sostituire la miriade degli standard presenti prima del 2009, anno di stesura dell ISO Attualmente la famiglia ISO si suddivide principalmente in due parti: 1. ISO 31000: Implementazione di principi e linee guida; 2. ISO 31010: Risk Management - Risk Assessment Techniques Standard ISO L introduzione alla nuova norma UNI ISO riporta: Le organizzazioni di tutti i tipi e dimensioni si trovano ad affrontare fattori ed influenze interni ed esterni che rendono incerto il raggiungimento dei propri obiettivi. Il rischio è l effetto che questa incertezza ha sugli obiettivi dell organizzazione. Ovviamente qualsiasi attività di un organizzazione comporta un rischio: la loro gestione può essere applicata in qualsiasi momento a un intera organizzazione, alle sue numerose aree e livelli, cosi come alle specifiche funzioni, progetti e attività. Applicabile a qualunque tipo di rischio, la UNI ISO Gestione del rischio - Principi e linee guida può essere utilizzata da imprese pubbliche, private o 25

27 sociali, associazioni, gruppi o individui e, pertanto, non è specifica per alcuna industria o settore. Per far sì che la gestione del rischio sia efficace, un organizzazione dovrebbe, a tutti i livelli, seguire gli 11 principi riportati nella norma, la figura 1.2 ne mostra il framework; 26

28 Fig. 1.2: ISO

29 il successo della gestione del rischio dipende inoltre dall efficacia della struttura gestionale di riferimento, che definisce le basi e gli assetti organizzativi per progettare, attuare e migliorare in continuo la gestione del rischio, nonchè per integrare la stessa all interno dell organizzazione. A tal fine, la norma fornisce indicazioni relative a: l impegno costante da parte della direzione per l introduzione di una efficace gestione del rischio e per la relativa definizione di politica e obiettivi; la progettazione della struttura di riferimento per gestire il rischio; la definizione delle responsabilità; l integrazione della gestione del rischio nei processi organizzativi; l assegnazione delle risorse; i meccanismi di comunicazione e reporting (interni ed esterni); l attuazione della gestione del rischio; il monitoraggio, il riesame e il miglioramento continuo della struttura di riferimento. Il processo di gestione del rischio comprende, come indicato nella norma, un piano per la comunicazione e consultazione degli stakeholder, la definizione del contesto, l identificazione e l analisi del rischio, la sua ponderazione, trattamento, monitoraggio e riesame e la registrazione del processo stesso. La UNI ISO è l adozione nazionale, in lingua italiana, della norma internazionale elaborata dal comitato tecnico ISO/TMB WG Risk management. 28

30 Per definire invece i termini di base relativi alla gestione del rischio, nel catalogo UNI è presente la norma UNI Gestione del rischio - Vocabolario che costituisce un riferimento generale applicabile a tutte le organizzazioni, al fine di promuovere un approccio coerente per la descrizione della gestione del rischio e l utilizzo della terminologia pertinente. Fulcro di questa ISO è naturalmente il framework. Fig. 1.3: Framework ISO Standard ISO La presente norma internazionale è uno standard di supporto per ISO e fornisce indicazioni sulla selezione e applicazione di tecniche sistematiche per la valutazione del rischio. La valutazione del rischio fornisce ai responsabili, di comprendere come i rischi potrebbero compromettere il conseguimento degli obiettivi dei controlli già in atto. Questo fornisce una base per le decisioni sul metodo più idoneo da utilizzare per trattare i rischi. L output del risk 29

31 assessment diventerà l input ai processi decisionali dell organizzazione. Come mostrato in figura 1.2, la valutazione dei rischi è quel processo globale che permette di: identificare i rischi; analisi dei rischi valutazione dei rischi. Il modo in cui viene applicato il processo dipende non solo dal contesto del processo di gestione del rischio, ma anche sui metodi e le tecniche utilizzati per effettuare la valutazione del rischio. Fig. 1.4: ISO

32 Capitolo 2 Progettare un vulnerability assessment Nel capitolo precedente abbiamo sottolineato l importanza del risk analisys, e la necessità da parte dell azienda di conoscere e valutare la propria esposizione al rischio. Una volta identificata quest ultima, allora sarà possibile valutare quale tipo di Vulnerability Assessment sarà necessario applicare, considerando quale grado di dettaglio, e di conseguenza di costo, si vuole affrontare. 2.1 Definizioni della terminologia Ci sono diversi termini per identificare diverse attività di IT security, purtroppo però, non sempre vengono usate correttamente. E quindi importante mettere chiarezza fin da subito alle definizioni usate, come : vulnerability scan, vulnerability assessment, 31

33 risk assessment, penetration test, security audit, security assessment Vulnerability scan Viene generalmente indicata un attività, completamente automatizzata delle vulnerabilità presenti in un sistema. Tipicamente vengono usati tool automatici, come Nessus o Iss Scanner. Il risultato di questa attività è generalmente un informazione del tipo: Il server con indirizzo ha il sistema operativo X versione y ha una vulnerabilità di questo tipo Vulnerability assessment In questa attività, oltre a eseguire un vulnerability scan, è necessaria anche una verifica umana delle vulnerabilità presenti nel contesto. L analista, dovrà pesare le vulnerabilità trovate e dare una priorità della sistemazione. Questa attività, grazie al lavoro umano, ha un valore aggiunto rispetto al vulnerability scanner. Infatti, l analista si occuperà anche di: depurazione di falsi positivi; capire bene la topologia della rete; potrebbe avere le regole dei firewall; potrebbe essere a conosceza delle policy aziendali. 32

34 In questa attività, non si simula il malintenzionato, quindi, è necessario facilitare il più possibile l attività di VA. Ad esempio, se la rete presa in considerazione ha un firewall, le varie scansioni è preferibile farle oltre il firewall. Questo perchè, come vedremo nel capitolo 3, farle prima dell apparato genererebbe molti falsi positivi, in quanto il firewall blocca le richieste. In linea di massima, questa attività è poco invasiva: il security group si limita a ricercare le vulnerabilità e le segnala al cliente; alla fine si trova la soluzione migliore, cercando di mediare le vulnerabilità trovate e eventuali costi per un remediation plain. Tuttavia, in questa attività non vengono considerate alcune componenti importanti come: componenti fisiche; componente umana; componenti procedurali. Un altro limite di questa attività è che essa soffre del problema della degradazione: infatti, periodicamente vengono aggiunti nuovi servizi, cambiate le installazioni, aggiunte o rimosse patch Risk assessment Questa attività segue una metodologia di analisi del rischio (nel mondo IT ci sono ISO 27001, e 31010) e vengono spesso usati tool BIA (Businnes Impact Analyst). Questi tool sono utili per quantificare il rischio e dimostrare l importanza dell investimento in sicurezza. 33

35 2.1.4 Penetration Test Questa attività richiede di simulare l attività di un maleintenzionato e cerca di sfruttare almeno una vulnerabilità per raggiungere il suo fine, ossia prendere possesso della macchina remota, anche con metodologie e strumenti non convenzionali. Questa attività può essere condotta sia dall interno che dall esterno della rete analizzata. Tipicamente le attività eseguite dall interno hanno lo scopo di verificare se esistono possibilità di accedere a file e/o dispositivi in modo inappropriato. Nei pentest, potrebbe essere richiesto di testare non solo le macchine, ma di valutare anche le persone addette a tali macchine; quindi tipicamente si suddivide in test di tipo: overt o evidente: i dipendenti, con particolare attenzione all IT, sono a conoscenza dell attività in corso. In un contesto siffatto non ha senso l utilizzo di metodologie di social engineering; covert o nascosto: si esegue l attività, con l autorizzazione dei manager, e all insaputa dello staff IT. In questa attività, ha senso testare anche la capacità e affidabilità degli addetti alla sicurezza durante un emergenza e la reale validità delle politiche di sicurezza dell azienda. Naturalmente, non è scontato che tale attività porti a garanzie positive. Potrebbe infatti accadere che il tecnico non penetri la macchina in questione, ma questo non significa che la macchina sia al sicuro da attacchi. Anche questa attività, come i Vulnerability assessment, soffre del problema della degradazione. Da un punto di vista teorico, ma non troppo, come dimostrato in [9], attraverso il social engineering, è possibile penetrare una rete o una macchina con ottimi livelli di sicurezza. In una attività del genere, non siamo interessati 34

36 a come una rete è stata progettata, ma nemmeno capire qual è il suo stato attuale. Siamo interessati solo alla ricerca di una vulnerabilità, e qualora non la trovassimo, possiamo sempre basarci sul social engineering Security assessment Il security assesment è un attività più ampia rispetto alle precedenti, comprende molte delle attività descritte in precedenza. Essa prende in considerazione: sicurezza logica; sicurezza informatica; sicurezza infrastrutturale; sicurezza sociale. Tale attività deve comprendere elementi di stato e di processo per evitare la degradazione. La metodologia di riferimento è proposta da OSSTMM ( Security Auditing Quest attività si preoccupa di identificare il livello di sicurezza aziendale e confrontarlo con le policy o con le best practice aziendali, entrambi prese come elemento di paragone. Quest attività dovrebbe essere parte integrante dei processi aziendali e non una consulenza saltuaria. 35

37 2.2 Cos è un vulnerability assessment Quando si parla di sicurezza informatica s intende sempre la capacità di un sistema informativo di resistere, con un determinato livello di confidenza, agli incidenti o alle azioni illecite atte a compromettere disponibilità, autenticità, integrità e riservatezza dei dati presenti nel sistema stesso, o trasmessi a servizi o a rete informatiche. L obiettivo di un VA è appunto quello di poter trovare, eventuali vulnerabilità presenti nella rete, in modo da poter successivamente proteggere al meglio l organizzazione, tenendo in considerazione le differenti dimensioni della sicurezza: disponibilità: riduzione a livelli accettabili del rischio di impedimento agli utenti autorizzati di fruire del sistema informativo e di accedere e utilizzare le informazioni, sia a seguito di fatti accidentali e/o naturali che di atti dolosi di soggetti non autorizzati; integrità: riduzione a livelli accettabili del rischio di cancellazioni o modifiche di informazioni a seguito sia di fatti accidentali e/o naturali, che di atti dolosi di soggetti non autorizzati; autenticità: che non esista dubbio di chi è responsabile di una informazione o della prestazione di un servizio, tanto al fine di avere fiducia di lui come di poterlo perseguire dopo eventuali inadempimenti o errori. In detrimento all autenticità possono esserci sostituzioni ed inganni mirati a realizzare una frode. L autenticità è la base per poter lottare contro il ripudio e, in quanto tale, fondamento per il commercio elettronico o per l amministrazione elettronica, permettendo di avere fiducia senza bisogno di documenti cartacei né di presenzia fisica; 36

38 riservatezza: riduzione a livelli accettabili del rischio di accesso improprio e dell utilizzazione dell informazione da parte di soggetti non autorizzati. Come molte attività, la pianificazione del lavoro è fondamentale, ed eseguirla bene è davvero complesso. Sono infatti molti i punti da sincronizzare in un attività siffata, occorre perciò una pianificazione accurata del lavoro, coadiuvato insieme al cliente, anche per poter tener conto del livello di CIA (Confidentiality - Integrity - Availability) da lui richiesto. Per fare ciò, come spesso accade nel mondo informatico, di fronte a problemi complessi si cerca sempre di suddividere il problema in sottoproblemi (divide et impera). Nel caso specifico si suddivide in tre processi il lavoro: 1. preparazione; 2. analisi; 3. gestione; processi di questo genere, vengono successivamente organizzati in attività che, alla fine, si suddividono in compiti da espletare. 37

39 Fig. 2.1: Suddivisione dei processi In ogni compito si indica quello che si deve fare così come le possibili difficoltà per poterlo eseguire al meglio, nonché il modo per affrontare con successo tale compito. Come detto sopra, è fondamentale, che nella fase di pianificazione sia coinvolto anche il cliente, per poter capire bene cosa si vuole fare nell attività di VA e come farla. Di solito viene effettuato un kickoff meeting per organizzare il lavoro individuando: scopo ed obiettivi: in questa fase si va alla ricerca degli asset da analizzare; parti coinvolte: viene determinato quali uffici/aree vengono coinvolte nell attività; modalità: tipicamente si cerca di essere il meno invasivi possibile, quindi si concorda ad esempio, quanti asset vengono analizzati in parallelo, maggiore saranno gli asset, maggiore sarà il traffico di rete generato; 38

40 tecniche ed approcci: si valuta il tipo di verbosità desiderata dal cliente; tempistica di esecuzione. Più dettagliamente, ma in maniera non esplicativa, al fine di poter pianificare al meglio l attività di VA è importante che nella parte di kickoff si possa rispondere ai punti seguenti, questo anche per avere delle informazioni iniziali che riguardano la struttura da analizza: E possibile consultare gli schemi di rete? Capire il perimetro della rete che si vuole analizzare; La rete su quante sedi/filiali è strutturata? Nel VA si vuole prendere in considerazione tutte le sedi/filiali? Come avviene il collegamento tra le filiali? Con quali regole (firewall,...) Le macchine sono fisiche o anche virtuali? La rete è mista (windows/linux)? Quanti sono i server? E i client? E possibile avere le regole dei firewall (questo è utile per pesare meglio eventuali vulnerabilità poi mediate dai firewall) Esiste un sistema di backup? Come avviene il backup? Esiste una gestione dei log (fw e dei sistemi)? Di quanti giorni? 39

41 E centralizzato? Come avviene il trasferimento dei dati (in chiaro o cifrato)? Che tipologia di server sono presenti? (mail server, web server...) Che tipo di applicazioni si usano in azienda? Compilate o web? Si vuole analizzare anche le applicazioni? Si hanno i sorgenti di queste applicazioni? Si vuole analizzare anche il loro comportamento? Che impatto ha l attività di VA sull infrastruttura analizzata? Valutare la sensibilità dei dati; C è qualche attività che il cliente non vuole che sia fatta? Come detto sopra, questa lista non vuole essere autoesplicativa, ma a seconda del contesto analizzato può essere perfezionata. Durante l attività, solo una piccola parte dei dipendenti deve sapere che è in atto l assessment, tipicamente managment e IT, i primi perchè hanno commissionato il lavoro, i secondi perchè dovranno dare supporto all analista. Questo è dovuto al fatto che non devono esserci comportamente diversi dalla quotidianità, al fine di non sfalsare il risultato finale. 2.3 Le vulnerabilità Quando si parla di sicurezza di una rete informatica occorre prendere in considerazione l ambiente esterno in cui il sistema viene a trovarsi. Cio permette di proteggere quest ultimo da: 40

42 accessi non autorizzati; modifica o cancellazione di dati fraudolenta; perdita di dati o introduzione di inconsistenze. Considerando che una rete è un insieme di apparati, occorre verificare periodicamente che tali apparati siano aggiornati, perchè sistemi operativi e firmware sono in continua evoluzione, nuove vulnerabilità vengono scoperte e quindi sistemate. Le vulnerabilità sono molte migliaia e riguardano sia servizi di rete, che applicazioni specifiche (IIS, Oracle, etc) e periodicamente i produttori rilasciano patch per le vulnerabilità note. In rete sono presenti molti siti che mettono a disposizione database con le vulnerabilità note, il loro stato e gravità. Seppur questa scelta sia stata in parte contestata dai produttori di software, essa rappresenta sicuramente un opportunità per l utente che viene così messo a conoscenza dei potenziali rischi a cui è esposto e possa valutarne le contromisure. Alcuni siti che offrono questo servizio sono: SANS; Secunia; Security Focus. Seppur ogni vulnerabilità è classificata con un indice di gravità (alta, media, bassa), come vedremo nel capitolo 9, di fatto queste gravità, come già detto in 1 veranno poi pesate, perchè la gravità dipende dal contesto (la stessa gravità su un server web e su pc che gestisce una stampante ha peso differente); è importante sottolineare inoltre che non esiste una lista di vulnerabilità dalle quali sia necessario o sufficiente proteggersi. Per queste motivazioni occorre: 41

43 monitorare gli annunci di nuove vulnerabilià inerenti ai propri sistemi; adottare le contromisure suggerite (installazione di patch, riconfigurazione dei servizi, filtraggio di rete); disporre di un architettura di sicurezza e di policy adatte a minimizzare l impatto di nuove vulnerabilità Le categorie delle vulnerabilità Poter categorizzare le vulnerabilità è importante per poter fissare delle priorità nelle contromisure da adottare. Ci sono situazioni, però, nelle quali non risulta conveniente installare la nuova patch che elimina una determinata vulnerabilità: è il caso di una macchina in produzione, dove eventuali patch al sistema operativo non sono state testate con una determinata applicazione. In questo caso è auspicabile testare prima il sistema in una situazione di laboratorio. Non esiste nemmeno una metrica standard per misurare la gravità di una vulnerabilità. Ogni organizzazione ha adottato criteri propri per indicare la gravità associata a ogni vulnerabilità. In questo lavoro viene preso come riferimento la classificazione CVSS, uno standard comunemente accettato. La figura 2.2 prende in considerazione il sito di SANS, il quale suddivide le vulnerabilità in quattro classi: 1. Critical; 2. High; 3. Moderate; 4. Low. 42

44 Fig. 2.2: SANS Vulnerability Sono molti i fattori chiave presi in considerazione per valutare il grado della vulnerabilità. SANS prende in considerazione i seguenti punti: diffusione del prodotto; valutazione dell asset: si tratta di un server o client? A che livello di privilegio? il problema è stato trovato nelle configurazioni di default? hanno un alto valore gli asset interessati (ad esempio database, e- commerce server)? codice di exploit è pubblicamente disponibile? quanto è difficile sfruttare la vulnerabilità? Remoto o locale? Senza credenziali o accesso fisico? 43

45 quanto è complesso per un attaccante informato, realizzare il proprio exploit? Sono disponibili dettagli tecnici della vulnerabilità? Riporto dal sito Sans come loro catalogano le vulnerabilità: CRITICAL vulnerabilities are those vulnerabilities that typically affect default installations of very widely deployed software, result in root compromise of servers or infrastructure devices, and the information required for exploitation (such as example exploit code) is widely available to attackers. Further, exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials, knowledge about individual victims, and does not need to social engineer a target user into performing any special functions. HIGH vulnerabilities are typically those that have the potential to become CRITICAL, but have one or a few mitigating factors that make exploitation less attractive to attackers. For example, vulnerabilities that have many CRITICAL characteristics but are difficult to exploit, do not result in elevated privileges, or have a minimally sized victim pool are usually rated HIGH. Note that HIGH vulnerabilities where the mitigating factor arises from a lack of technical exploit details will become CRITICAL if these details are later made available. Thus, the paranoid administrator will want to treat such HIGH vulnerabilities as CRITICAL, if it is assumed that attackers always possess the necessary exploit information. MODERATE vulnerabilities are those where the scales are slightly tipped in favor of the potential victim. Denial of service vulnerabilities are typically rated MODERATE, since they do not result in compromise of a target. Exploits that require an attacker to reside on the same local network as a 44

46 victim, only affect nonstandard configurations or obscure applications, require the attacker to social engineer individual victims, or where exploitation only provides very limited access are likely to be rated MODERATE. LOW vulnerabilities by themselves have typically very little impact on an organization s infrastructure. These types of vulnerabilities usually require local or physical system access or may often result in client side privacy or denial of service issues and information leakage of organizational structure, system configuration and versions, or network topology. A questo punto, potrebbero sorgere un paio di domande: perchè la grande maggioranza delle intrusioni avviene sfruttando vulnerabilità note, per le quali esistono patch/upgrade da lungo tempo? Perchè alcune tecniche di intrusione (es. buffer overflow), pur essendo tecnicamente complesse da implementare, riescono ad essere utilizzate così frequentemente? Per poter rispondere a queste domande è necessario introdurre due concetti: 1. ciclo di vita di una vulnerabilità; 2. finestra temporale di esposizione di un sistema. Ciclo di vita di una vulnerabilità Come ampiamente discusso in [5,16] una vulnerabilità attraversa fasi diverse della sua evoluzione che ne determinano la criticità e la diffusione. 1. Creazione: durante la fase di sviluppo viene introdotto nel codice un errore; 2. Scoperta: un esperto di sicurezza scopre l errore all interno del codice, intuisce che questo ha una o più conseguenze negative sulla sicurezza 45

47 del sistema. Da questo momento si parla di vulnerabilità e non più di errore nel codice; 3. Condivisione: la conoscenza della vulnerabilità scoperta viene fatta prima circolare in ambito ristretto, poi si diffonde anche grazie allo sviluppo di tool automatici che ne fanno uso; 4. Pubblicazione Patch/Upgrade: il produttore del sistema viene a conoscenza della vulnerabilità, quindi corregge l errore emettendo una patch o una nuova versione del codice. La presenza di tale vulnerabilità, insieme alla presenza della patch disponibile viene resa pubblica. Finestra temporale di una vulnerabilità Come visibile dalla figura 2.3 tutti i sistemi sono soggetti a una finestra di esposizione, anche se gestiti al meglio. Infatti la scoperta di nuove vulnerabilità è impredicibile. Inoltre, la conoscenza dell individuazione delle nuove vulnerabilità circola velocemente su chat, mailing list, ecc... e altrettanto velocemente la disponibilità di tool automatici atti all utilizzo delle vulnerabilità trovate. Purtroppo, le patch rappresentano una soluzione spesso inefficace in quanto: scarsa consapevolezza di molti sistemisti; frequenza di emissione troppo elevata; spesso causa di malfunzionamenti o nuovi problemi. 46

48 Fig. 2.3: Finestra temporale di una vulnerabilità. Fonte [5] E interessante notare che la curva di figura 2.3 cresce rapidamente nonostante il fatto che sfruttare alcune vulnerabilità sia complesso. Questo è dovuto principalmente a due fattori: 1. scripting: dopo le prime intrusioni, compiute da esperti, la tecnica per realizzarle viene automatizzata (scrittura di script, descrizione delle procedure); 2. script Kiddies: la disponibilità di exploit (tool automatici) permette di sfruttare con successo vulnerabilità nei sistemi anche a persone dotate di scarse competenze tecniche, aumentando drasticamente il numero dei potenziali attaccanti. Un esempio pratico è il seguente: installare un Windows Server 2003 con una installazione di default e analizzare come sia possibile attaccare questa macchina. Successivamente si lancia uno scanner (che vedremo nel paragrafo 47

49 3.1 e si osservano le vulnerabilità presenti sul server (nel caso specifico 9 vulnerabilità Alte). Si può notatare subito la presenza di vulnerabilità legate al buffer overflow, nel caso specifico del problema di RPC (vulnerabilità storica su questo sistema operativo), sarà relativamente semplice sfruttare questa vulnerabilità: in pochi minuti sarà possibile avere a disposizione un prompt di dos, da dove sarà poi possibile creare, modificare ed eliminare files. La semplicità e la velocità con cui è possibile sferrare il seguente attacco convince sempre più dell utilità di un security assesment a livello infrastuturale. 48

50 Fig. 2.4: Controllo remoto di un prompt dos 2.4 Limitazioni di un VA E importante, mettere subito in chiaro che questo genere di attività, pur portando sicuramente un valore aggiunto alla sicurezza attuale dell infrastruttura aziendale presa in considerazione, ha anche delle limitazioni. Come detto a inizio capitolo, questa attività soffre del problema di degradazione, ossia, nel tempo nuove vulnerabilità verranno scoperte, nuove macchine verranno aggiunte o tolte dalla rete, nuove patch verranno installate sulle macchine, nuovi servizi pure. Inoltre è importante sottolineare che il VA, è una fotografia della situazione del momento, è quindi fondamentale che i vari apparati, che si vuole analizzare, siano accesi e collegati alla rete. 49

51 Spesso le workstation sono multi-utente, ed ogni utente abilita servizi personali, ovviamente durante l attività di VA essendo attivo un solo utente, solo quest ultimo verrà analizzato. E quindi fondamentale, che l attività di analisi, la macchina sia loggata con l utenza più usata, o comunque di maggior interesse. Inoltre a volte è possibile che alcune workstation, abbiano installata una o più macchine virtuali, e anche quest ultime potrebbero essere messe in rete, queste macchine, se non sono attive, non saranno analizzate. 50

52 Capitolo 3 Vulnerabilità infrastrutturali In questo capitolo sono elencati i principali tool per le scansioni a livello infrastrutturale, come vedremo nel seguito, un aspetto fondamentale è dove posizionarsi all interno dell infrastruttura al fine di trovare le vulnerabilità. 3.1 Vulnerability scanner Sono molti i tool di vulnerability scanner presenti sul mercato. In questo lavoro verrà preso in considerazione Nessus. Questa scelta è dovuta al fatto che è sicuramente il tool più noto per questa tipologia di attività, inoltre, rilascia il report finale in diversi formati, tra cui il formato xml. Questo formato, è molto malneabile, e ci permette di gestirlo nel tool che vedremo nel capitolo 9 e nell appendice A, infatti, questo formato ci permetterà di poter correlare una serie di vulnerabilità trovate nelle diverse fasi dell assessment. E importante sottolineare che il focus di questa parte del lavoro è quello di riuscire, tramite questa metodologia di vulnerability assessment, di assegnare un peso alle vulnerabilità trovate. Questo ci permetterà di concentrarsi meglio sulle vulnerabilità realmente critiche per l azienda. Supponiamo che 51

53 il tool di vulnerability scanner usato rilevi una stessa vulnerabilità critica a diverse macchine. Pur avendo la stessa vulnerabilità, è probabile che peseremo in maniera differente la criticità trovata sul server web, rispetto al server di stampa. Oppure, se abbiamo una vulnerabilità alta, ma siamo certi che tale vulnerabilità non possa essere sfruttata in quanto bloccata dal firewall, probabilmente ci concentreremo su altre vulnerabilità trovate Nessus Nessus è un progetto che ha come scopo quello di fornire alla comunità uno strumento potente e facile da usare, per poter scoprire e analizzare le vulnerabilità presenti in una rete, al fine di evitarne lo sfruttamento da parte di utenti maliziosi. E probabilmente il più completo ed evoluto strumento di vulnerability scanning disponibile nel mondo free-ware. Come riportato in [4], Nessus è un software proprietario del tipo client/server sviluppato da Tenable Network Security. Il client è basato su un interfaccia web sviluppata in Flash. Periodicamente vengono rilasciati dei nuovi plugin che coprono i diversi protocolli, backdoor, applicazioni e vulnerabilità locali: in questo modo è possibile rilevare le reali applicazioni in esecuzione su ogni porta aperta. Alla base del suo funzionamento vi è un sistema di abilitazione di plugin, al fine di creare le cosiddette policy. Al momento dell esecuzione di una scansione, è necessario creare una policy adatta alla scansione in atto. Tale prodotto è installabile sui seguenti sistemi operativi: Microsoft Windows; Mac OS X; Linux; 52

54 FreeBSD; Solaris. Sono possibili scansioni diverse: dall interno della rete (per ottenere quante più informazioni è possibile su potenziali vulnerabilità o debolezze del sistema target) e dall esterno. In questo modo è possibile valutare quali vulnerabilità sono presenti e a seconda del contesto sarà possibile capire ciò che un malintenzionato (interno o esterno) è in grado di poter fare. E prassi fare un approfondita analisi dei server a livello di interfaccia tra la rete locale e internet, ovvero quell insieme di server che viene normalmente definito come DMZ (zona demilitarizzata). Quest ultimo termine specifica una sottorete inserita come zona neutrale tra la rete privata di un organizzazione e internet, zona che permette connessioni esclusivamente verso l esterno: server di posta elettronica, server HTTP con applicazioni web o server VPN. Nessus, inizialmente lancia una scansione sulle porte per verificare quali sono i servizi attivi e la tipologia di sistema operativo presente sulla macchina o presenti nella sottorete target. La fase di scansione delle porte è fondamentale: questo ci permette di stabilire la tipologia del target e, di conseguenza, ci permette di sapere quali plugin sono pertinenti a quel target (ad esempio Apache o ISS plugin per un server web o vulnerabilità del sistema operativo) e quale servizio è attivo su tale porta. Naturalmente, questo tool è anche in grado di rilevare servizi anche su porte non standard. Qualora fosse necessario eseguire una scansione su una rete di grande dimensioni, sarebbe opportuno posizionare un server Nessus per ogni segmento di rete. Inoltre, qualora fossero note alcune caratteristiche della macchina sulla quale si esegue la scansione, come ad esempio il sistema operativo o servizi in esecuzione, allora è possibile impostarli al momento della creazione della 53

55 policy. Ciò permette di fare scansioni molto mirate e più performanti. Finita la scansione, Nessus genera un report indicante una lista di tutte le porte aperte e i potenziali rischi associati. Sarà poi possibile esportare tali report in vari formati, come ad esempio HTML o PDF, oppure un formato nativo (un file xml che viene poi importato successivamente in un tool di risk analysis che vedremo nel capitolo 9). Fig. 3.1: Creazione di un policy con Nessus 3.2 Nmap E probabilmente il port scanning più famoso al mondo è molto affidabile e versatile, ormai presente in tutte le distribuzioni linux, sistemi windows e mac. E capace di effettuare scansioni delle porte ad un computer, o ad un intera rete allo scopo di rilevare i servizi attivi; ipotizza il sistema operativo del computer remoto, in maniera molto affidabile. Permette inoltre di trovare applicazioni server installate su una macchina. Le scansioni possono 54

56 essere eseguite in diverse modalità, al fine di non farsi rilevare dai vari apparati presenti nella rete, o per non generare troppo traffico, è infatti possibile effettuare scansioni tcp (con handshake completo), con scansioni syn, XMAS e molte altre modalità. Fig. 3.2: Nmap 3.3 Microsoft baseline security analyzer La piattaforma più utilizzata, almeno nell ambito workstation, è senza dubbio quella Microsoft, questo comporta un maggior interesse, da parte dei malintenzionati, a trovare vulnerabilità su tale piattaforma. Per questo motivo, è fondamentale, avere tali macchine aggiornate con tutte le patch di sicurezza, che Microsoft rilascia regolarmente il primo martedi di ogni mese. Inoltre Microsoft, mette a disposizione di tutti, gratuitamente un prodotto che si chiama Microsoft baseline security analyzer. Tale prodotto, fa una scansione di tutti i software microsoft installati come: 55

57 Microsoft Windows; Internet Explorer; IIS web server; Microsoft SQL Server; Microsoft Office. E fondamentale, fare un controllo con questo tool, in un contesto di macchine Microsoft. Fig. 3.3: Microsoft baseline security analyzer 3.4 Nikto Nikto è uno web server scanner open source, che esegue test completi e approfonditi contro i vari elementi di un server Web, potenzialmente pericolosi, come CGI, verifiche di versioni obsolete di server, e problemi specifici di una determinata versione di server. Inoltre, controlla alcuni parametri di configurazione del web server, come ad esempio alcune parametri di default che 56

58 potrebbero essere modificati, per rendere meno lasche le regole; ricerca anche eventuali plugin installati (spesso le vulnerabilità sono presenti proprio nei plugin). Non tutti i controlli riguardano la sicurezza, seppur lo siano la maggioranza, ma ci sono alcuni verifiche che sono solo informazioni. Nikto, non è concepito come uno strumento furtivo, ma al contrario, uno strumento per valutare il livello di sicurezza del proprio server web. Permette infatti di testare un server web nel minor tempo possibile. Tuttavia, vi è il supporto anti-ids, ossia metodi nel caso in cui si desidera fare un tentativo di penetrazione al server, ma questo deve essere visto, come una possibilità di mettere alla prova il vostro sistema IDS. Fig. 3.4: Nikto 3.5 Modalità d uso di un vulnerability scanner I tool di scansione delle vulnerabilità sono sicuramente utili, tuttavia è richiesto una modalità d uso adeguata al contesto, e un lavoro manuale, a fine scansione, per poter eliminare eventuali falsi positivi. Infatti, questi tool in alcune circostanze possono portare a esiti non corretti: 57