Analisi e sviluppo di uno strumento per l'automazione della verifica di conformità allo standard pci dss

Analisi e sviluppo di uno strumento per l'automazione della verifica di conformità allo standard pci dss
Università degli Studi di Trieste Facoltà di Ingegneria Tesi di Laurea Magistrale in INGEGNERIA INFORMATICA A NALISI E SVILUPPO DI UNO STRUMENTO PER L ’ AUTOMAZIONE DELLA VERIFICA DI CONFORMITÀ ALLO STANDARD PCI - DSS Laureando: Relatore: Lorenzo Caenazzo Prof. Alberto Bartoli Correlatori: Alessandro Budai Enrico Milanese Anno Accademico 2011-2012
Indice Introduzione iv Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv Obiettivi e vincoli progettuali . . . . . . . . . . . . . . . . . . . . . . iv Risultato e fasi del lavoro . . . . . . . . . . . . . . . . . . . . . . . . v Articolazione della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . v 1 Analisi e progettazione 1 1.1 Problema e situazione preesistente . . . . . . . . . . . . . . . . . 1 1.2 Workow PCI-DSS . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Denizione delle entità . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Scelta DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1 Documenti . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Avvisi, riepiloghi . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7 Metodologia di sviluppo e tecnologie adottate . . . . . . . . . . 9 2 Realizzazione 11 2.1 Interfaccia utente . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.2 Pagina di gestione . . . . . . . . . . . . . . . . . . . . . 15 2.1.3 Analisi Usabilità . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 Gerarchia delle classi . . . . . . . . . . . . . . . . . . . . 22 2.2.2 Package core . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.3 Package web . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4 Avvisi mail . . . . . . . . . . . . . . . . . . . . . . . . . 30 ii
2.2.5 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3 Conclusioni 37 3.1 Obiettivi e sviluppi futuri . . . . . . . . . . . . . . . . . . . . . 37 3.2 Lavoro svolto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3 Valutazioni personali . . . . . . . . . . . . . . . . . . . . . . . . 38 4 Bibliograa 39 Ringraziamenti 41 iii
Introduzione Questa tesi illustra il lavoro da me svolto presso la Emaze Networks S.p.A. Contesto Le maggiori emittenti di carte di credito hanno deciso di formare un'orga- 1 2 nizzazione chiamata PCI che ha formulato uno standard (DSS ). L'Ente responsabile degli standard di protezione PCI è un forum globale aperto dedicato allo sviluppo, al miglioramento, alla memorizzazione, alla distribuzione e all'implementazione degli standard di sicurezza per la protezione dei dati degli account. La missio- ne dell'Ente responsabile degli standard di protezione PCI è mi- gliorare la sicurezza dei dati relativi ai pagamenti garantendo una formazione appropriata e una conoscenza degli standard PCI. Tutti i soggetti che trattano dati di carte di credito devono aderire allo standard PCI DSS. Uno dei requisiti richiesti è l'analisi di Vulnerability Assessment sulla 3 propria infrastruttura pubblica da parte di una società certicata PCI ASV . Questo standard oltre a ssare i limiti per il rilascio della certicazione delinea un workow che il certicatore è tenuto a seguire. Il progetto è stato avviato in previsione di una espansione della domanda di tale certicazione. Obiettivi e vincoli progettuali L'obiettivo è di costruire uno strumento che faciliti gli operatori a seguire il usso imposto dallo standard, con particolare attenzione anche ai fattori com- 1 Payment Card Industry 2 Data Security Standard 3 Approved Scanning Vendor iv
merciali delle analisi. Inoltre dovrà inviare resoconti giornalieri agli operatori sulle situazioni di allarme, gestire contratti, ticket di supporto al cliente, anagraca dei clienti, gestione documentale e lo stato di ogni analisi eettuata. Si è scelto di sviluppare un'applicazione web, accessibile solamente dalla rete privata aziendale. Per la realizzazione sono state usate le seguenti tecnologie: • Java; • Spring, un framework con molte funzioni, in particolare è stato usato per 4 la gestione del pattern architetturale MVC ; • ExtJS, un framework per la creazione di pagine web e l'interazione client- server; • Apache Tomcat, come servlet container; • un DBMS, a scelta tra PostGreSQL o MongoDB. Queste tecnologie sono state imposte per politica aziendale. Risultato e fasi del lavoro Il lavoro di tesi si è svolto con una parte iniziale di apprendimento generale delle tecnologie impiegate. Successivamente si è iniziato ad implementare i vari aspetti seguendo i principi dello sviluppo agile, rivedendo più volte la struttura logica e sica del progetto tramite prototipi, no all'ottenimento del risultato voluto. Il lavoro risultante è un portale web che permette la gestione degli aspetti sopra citati. Articolazione della tesi Di seguito, un breve riepilogo dei contenuti presenti nei capitoli: 1. Si analizza il problema denendo i requisiti e le caratteristiche che dovranno essere implementate; 4 Model View Controller è un design pattern che divide in modo rigido i compiti delle varie classi all'interno di un'applicazione web v
2. Si descrive l'interfaccia utente realizzata e l'implementazione della logica del sistema; 3. Si delineano le conclusioni sul lavoro svolto e possibili sviluppi futuri; 4. Si espongono i riferimenti bibliograci e le fonti utilizzate. vi
Capitolo 1 Analisi e progettazione 1.1 Problema e situazione preesistente In previsione di un aumento della domanda delle certicazioni PCI-DSS, si è scelto di creare uno strumento atto alla gestione: • delle analisi eettuate; • della relativa documentazione, upload e download dei documenti; • dell'anagraca del cliente; • della situazione contrattuale. Si è scelto di avviare un progetto completamente nuovo perché non era presente alcuna piattaforma simile da poter usare come base di partenza. Pre- cedentemente per la gestione dei dati sopra citati, a causa dell'esiguo numero di clienti, veniva usato un foglio di calcolo per ogni cliente contenente tutte le informazioni. All'aumentare dei clienti e delle analisi l'uso di fogli di calcolo risulta poco agevole, in quanto introduce problemi di allineamento dei dati tra le copie locali dei fogli. 1.2 Workow PCI-DSS Lo standard PCI-DSS per il corretto svolgimento dell'attività di analisi di 1 vulnerabilità impone all'ASV di seguire il seguente workow. 1 Approved Scanning Vendor 1
Figura 1.1: Workow PCI-DSS. Questo workow descrive le fasi e le interazioni che devono avvenire tra l'a- zienda che esegue l'analisi e quella che l'ha commissionato. Lo schema è diviso in due zone per gli obblighi di ogni attore. Delinea anche i comportamenti da adottare in caso di: • informazioni parziali; • analisi andata a buon ne; • analisi fallita. In prima approssimazione ogni scambio di dati tra ASV e cliente è accom- pagnato da una serie di documenti e tali interazioni possono portare ad un blocco, momentaneo, della procedura di analisi. Prima dell'analisi delle vulnerabilità si procede ad una verica degli indirizzi IP forniti, e qualora si rilevino altri indirizzi IP pubblici collegati ai domini sotto analisi si rende necessario decidere insieme al cliente se inserirli nella analisi da eettuare. Una volta individuati tutti gli IP da testare e ricevuta l'autorizzazione a 2 procedere, viene eseguita l'analisi di vulnerabilità tramite ipLegion . Ogni 2 un software sviluppato internamente dalla Emaze per il controllo automatizzato delle vulnerabilità 2
vulnerabilità è classicata con un livello di rischio che va da zero a dieci. Il cliente viene considerato protetto se vengono individuate solo vulnerabilità di grado da 0 a 3,9. Nel caso in cui l'analisi termini con un fallimento inizia un confronto tra ASV e cliente in modo da accertare eventuali falsi positivi. Una volta esclusi gli eventuali falsi positivi se rimangono vulnerabilità di grado maggiore a 4 l'analisi risulta a tutti gli eetti fallita. Per ottenere la certicazione il cliente dovrà applicare i suggerimenti consigliati all'interno del report dell'attività e richiedere una nuova analisi. 1.3 Denizione delle entità Il sistema deve poter gestire il dettaglio dei clienti con associati i relativi: indirizzi IP, analisi eettuate e contratti stipulati. Inoltre deve mantenere lo storico di queste entità. Per il soddisfacimento di tali requisiti di gestione anagraca e documentale sono state individuate quattro entità separate per modellare gli aspetti essenziali. Le entità individuate, con relativi attributi, sono: • Analisi (data di esecuzione, contratto associato, indirizzi IP in esame, risultato); • Contratti (massimo numero di analisi eettuabili, inizio validità contrat- to, ne validità contratto, cliente associato); • Clienti (anagraca varia); • Indirizzi IP (indirizzi IP, data di inserimento nel sistema, contratto associato). 3
Figura 1.2: Schema provvisorio delle entità. Una volta realizzato il primo prototipo basato su queste entità basilari, e sottoponendolo alla valutazione da parte dei futuri utilizzatori del sistema, sono state notate delle lacune nel modello dei dati iniziale. In accordo con il modello dello sviluppo agile si è reso necessario rimodellare le entità fondamentali cambiando struttura a quelle già presenti, aggiungendone delle altre e modicandone le relazioni tra esse. Da tale confronto è anche emerso un caso d'uso inizialmente non preso in esame: il cliente acquista un pacchet- to di analisi e cede tali analisi a sua volta a suoi clienti. Questo caso d'uso modica il rapporto di parentela tra tutte le entità no ad ora individuate e risulta mancante un'entità che rappresenti il cliente principale. Si è inoltre deciso di aggiungere un'entità che rappresenti i ticket di assistenza forniti ai clienti in modo da tracciare anche questo aspetto delle analisi per una corretta rendicontazione. Inoltre per questioni pratiche è stato inserito un campo note. Le nuove entità identicate sono: • Analisi (data di esecuzione, contratto associato, cliente slave associato, indirizzi IP in esame, risultato, note); • Contratti (numero massimo di analisi eettuabili, numero massimo di ticket di assistenza usabili, inizio validità contratto, ne validità contratto, cliente master associato); • Clienti slave (anagraca varia, cliente master associato, note); 4
• Clienti master (anagraca varia, note); • Indirizzi IP (indirizzi IP, data di inserimento nel sistema, cliente slave associato); • Ticket assistenza (data esecuzione, durata, contratto associato, operatore che ha eseguito il ticket, note). Figura 1.3: Schema denitivo delle entità. Questo schema rappresenta le entità che eettivamente formano la base dati del sistema. 1.4 Scelta DBMS La scelta si poneva tra un database relazionale come PostGreSQL, ed uno non relazionale orientato ai documenti come MongoDB. Si è deciso di usare 5
quest'ultimo per sfruttare la possibilità di salvare les in modo nativo al suo interno. Questo particolare DBMS non richiede la denizione di tabelle e relazioni prima di poterlo usare, e conseguentemente, non si deniscono i tipi di dato che dovrà contenere. Quindi non necessita di una progettazione vera e propria in quanto, all'atto di salvare un'entità, il driver si prenderà l'onere ove non sia già presente di creare una collezione, simile al concetto di tabella dei database relazionali, in cui salvare l'entità stessa. All'interno di tale collezione 3 verranno salvate tutte le entità dello stesso tipo codicate in BSON , per motivi prestazionali. MongoDB permette di salvare anche entità con struttura diversa all'interno della stessa collezione. Ad esempio se dalla shell di amministrazione si eseguono i seguenti comandi: db.test.save({num : 1}) db.test.save({num : 2 , str : Stringa}) db.test.find() {_id : ObjectId(50fd69fb8eadef9a1d8c1315), num : 1} {_id : ObjectId(50fd6a0e8eadef9a1d8c1316), num : 2, str : Stringa} non ricevo alcun errore, anche se il secondo documento salvato ha un attributo in più. Da questo esempio si può notare la struttura simile al formato JSON e l'aggiunta di un ID univoco generato automaticamente. La possibilità di salvare entità con struttura diversa, risulta molto utile per la memorizzazione di entità complesse che al loro interno includono altre entità. Inoltre MongoDB permette di eettuare backup senza interrompere l'attività, in aggiunta qualora si renda necessario, gestisce automaticamente la replica su più nodi così da aumentare la sicurezza dei dati. Di contro MongoDB non implementa il concetto di transazione come i DBMS relazionali, preferendo il salvataggio di intere entità. Non implementa nessun concetto di relazione, quindi è esclusa la possibilità di far eseguire in modo automatico delle query di join, ma qualora sia possibile, è da preferire 3 formato JSON binario 6
una denormalizzazione salvando un unico documento con all'interno tutte le informazioni ad esso collegate. Tale denormalizzazione è stata eettuata sull'entità delle analisi che inglo- ba l'entità degli indirizzi IP così da salvarne esattamente lo stato in un dato istante. Se non fosse possibile eseguire questa denormalizzazione risulta necessario eseguire più interrogazioni per reperire tutte le informazioni. Per questi motivi, se si è costretti a gestire più collezioni, il database potrebbe perdere di consistenza in caso di cancellazioni. 1.4.1 Documenti Il sistema nale pone come requisito fondamentale la gestione del salvataggio di documenti in qualsiasi formato e di ogni dimensione. Questi documenti, solitamente in formato PDF, devono essere associati alle singole analisi in quanto sono: • autorizzazioni a analizzare i sistemi; • report dell'analisi di vulnerabilità; • informative; • altri documenti. Si è deciso di implementare questa particolare funzionalità tramite codice 4 nativo dopo aver vagliato l'opportunità di usare un CMS come Alfresco, scartato per l'elevata complessità necessaria per la gestione di un'operazione così semplice. Per eseguire il salvataggio dei le esistono sostanzialmente due metodi: • salvataggio nel File System; • salvataggio nella base dati (MongoDB). Inizialmente, prima di scegliere il DBMS da usare, il salvataggio avveniva nel File System del server. Questo particolare approccio consente di accedere 4 Content Management System 7
ai le memorizzati tramite connessione remota alla cartella di salvataggio, ma rende il backup dell'intero sistema più elaborato. Come accennato precedentemente la decisione di usare MongoDB come DBMS ha permesso di salvare nativamente documenti all'interno del database tramite GridFS. GridFS è una funzione di MongoDB che permette di salvare le di di- mensioni arbitrarie all'interno del database. Il salvataggio avviene in modo automatico creando due collezioni fs.les e fs.chunks; la prima collezione contiene tutti i dati relativi alle informazioni sul le quali: nome, dimensione, l'hash MD5, data di caricamento, eventuali metadati accessori. La seconda collezione contiene il le vero e proprio serializzato e diviso in pezzi da 256 kB. 1.5 Avvisi, riepiloghi Il sistema nale deve mettere in evidenza le situazioni che richiedono l'attenzione di un operatore come: • contratti in scadenza; • certicazioni che stanno per terminare la propria validità; • raggiungimento da parte di un cliente del limite delle analisi o dei ticket di supporto. Per fare ciò si è scelto di visualizzare queste informazioni all'apertura del- l'applicazione, sulla home page. Inoltre si è deciso di far compilare ed inviare quotidianamente al sistema delle email automatiche ad una mailing list interna. Oltre alle situazioni d'allarme precedentemente elencate, si è scelto di inviare tramite mail un'ulteriore avviso che riguarda un'analisi bloccata in uno stato intermedio da almeno una settimana. L'applicazione deve anche fornire un riepilogo delle analisi eseguite e dei ticket usati ltrati per contratto. Tale riepilogo come requisito aggiuntivo, oltre ad essere accessibile tramite interfaccia web, deve essere esportabile in formato CSV per essere poi utilizzato come riepilogo consuntivo del contratto. 8
1.6 Sicurezza Anche se è previsto che il sistema sia accessibile solamente da rete interna è stato richiesto di implementare un sistema di autenticazione dell'operatore tramite il server di autenticazione aziendale. In modo da consentire l'accesso solamente al gruppo di lavoro autorizzato e rendendo possibile l'identicazione degli operatori che hanno eseguito alcune operazioni. Inoltre, principalmente a scopo didattico, si è dovuto prestare particolare attenzione ad eventuali problematiche di sicurezza applicative seguendo in fase di realizzazione le best security practice per lo sviluppo in ambito web. 1.7 Metodologia di sviluppo e tecnologie adottate La tecnica di sviluppo utilizzata, per questo ed altri progetti dell'azienda, è lo sviluppo agile. Tale tecnica prevede una iterazione continua su brevi periodi temporali delle fasi di analisi, progettazione e sviluppo; confondendo di fatto i margini delle varie fasi. Lo sviluppo agile mette al centro l'interazione con il committente ed eventualmente gli altri membri del team. Questa interazione stretta porta spesso ad un cambiamento dei requisiti, e per cui si rende necessario ridisegnare il modello dei dati, implementare qualche funzione non prevista nell'interfaccia utente, modicare la logica applicativa. Questa strategia di sviluppo, per essere ecace, deve essere supportata da altre tecniche come il Test Driven Development, che mette in risalto l'impor- tanza di scrivere test d'unità, integrazione e test di accettazione per ogni classe implementata. Inoltre tale tecnica deve essere supportata anche da opportune tecnologie. Si rende quindi necessaria un'infrastruttura di Continuous Integration per rilasciare le nuove versioni del progetto appena pronte. In modo da riceve- re immediatamente delle valutazioni sulle funzioni appena implementate. Il Continuous Integration è stato garantito tramite le seguenti tecnologie: • Mercurial, sistema di version control; 9
• Jenkins e Maven, per eseguire compilazioni e test in modo automatico; • Tamakoji, per mantenere un repository contenente i pacchetti da instal- lare sull'ambiente di test (o produzione). Figura 1.4: Schema struttura Continuous Integration. 5 Tamakoji è uno strumento per mantenere un repository YUM contenente 6 pacchetti RPM sviluppato internamente derivato da Koji. 5 Yellowdog Updater, Modied è un sistema di gestione dei pacchetti compatibile con i pacchetti RPM 6 Red Hat Package Manager, pacchetto di installazione compatibile con la distribuzione Linux Fedora e derivate 10
Capitolo 2 Realizzazione A causa del metodo di sviluppo utilizzato, la fase di realizzazione non è realmente separata dalle fasi di analisi e progettazione, infatti sia l'interfaccia graca che l'implementazione della logica applicativa si sono sviluppate mentre venivano aggiunti o modicati i requisiti iniziali in base al prototipo fornito. 2.1 Interfaccia utente L'interfaccia graca è stata implementata tramite il framework Javascript ExtJS. Grazie a questo framework è possibile creare interfacce complesse, lo- gicamente simili alle interfacce scritte tramite codice nativo. Tale framework rende disponibile in Javascript il concetto di classe, consentendo l'ereditarietà ed uno stile di programmazione ad oggetti. Grazie all'ereditarietà fra classi, mette a disposizione la possibilità di estendere e personalizzare gli elementi precongurati e - usando i container di basso livello - creare componenti propri aderenti alle proprie necessità. Il framework si occupa inoltre di mantenere le viste consistenti ad eventuali zoom da parte degli utenti e garantisce la stessa rappresentazione su tutti i browser. Tra i componenti graci più utilizzati troviamo: • Grid, usato per la visualizzazione dei dati sotto forma di tabella; • Form, usato per l'inserimento dei dati e la modica. Il framework porta con se anche una serie di fogli di stile, personalizzabili qualora si presenti la necessità. 11
Inoltre implementa componenti che si occupano dell'interazione client-server che, consentono di acquisire informazioni dal server in formato JSON, e di elaborarle automaticamente per la corretta visualizzazione nel browser. Ta- li componenti sono principalmente reader e store. I primi si occupano di interpretare in modo corretto la risposta JSON, mentre gli store rendono disponibili le informazioni agli altri componenti dopo averli, ad esempio, ordinati o convertiti in un formato più appropriato. Le richieste sono inviate al server tramite richieste AJAX, per non bloccare l'interfaccia mentre si attende una risposta. I componenti graci possono venir combinati insieme ai componenti di invio e ricezione per rendere dinamica la pagina. Per popolare una tabella c'è bisogno almeno di: • uno store JSON; • un reader JSON; • la tabella dove visualizzare i dati ricevuti (grid). A meno di congurazioni particolarmente complesse, si può congurare il reader all'intero della dichiarazione dello store, per poi associarlo alla tabella che visualizzerà i dati presenti nello store mantenendo la vista aggiornata ad un'eventuale modica dei dati contenuti nello store. Usando questo framework i sorgenti delle pagine web non contengono quasi per nulla codice HTML, ma solo Javascript. L'uso di ExtJS, come potenziale svantaggio, porta ad una dichiarazione prolissa di ogni aspetto per tutti i pannelli fonte di facili errori. Ogni pop-up introdotto è una nestra modale, cioè disabilita il resto del- l'interfaccia utente nché rimane attiva. Inoltre è stato richiesto di associare la scorciatoia da tastiera ESC per chiudere la nestra attiva più velocemente. Immediatamente dopo l'autenticazione, si viene rediretti verso l'home page da cui si può accedere a tutte le funzioni del progetto. 12
2.1.1 Home Page Figura 2.1: Pagina principale. Questa pagina riassume tutte le situazioni d'allarme e d'interesse sia per questioni commerciali sia per questioni legate alle analisi eettuate. Nella parte superiore sono elencate, raggruppate per cliente principale, tutte le ultime analisi di tutti i clienti, mettendone in risalto lo stato. Nella parte inferiore invece si possono eseguire delle interrogazioni che ri- guardano i contratti in scadenza, le analisi eseguite, e le analisi che sono in scadenza. Figura 2.2: Dettaglio contratti in scadenza. 13
Figura 2.3: Dettaglio analisi rimanenti. Figura 2.4: Dettaglio analisi in scadenza. In tutte le viste è stato introdotto nella parte inferiore uno slider, per una rapida modica del valore di soglia con cui eseguire la ricerca ed un selettore numerico per aver maggior precisione. Eseguendo un doppio click sulle analisi di vulnerabilità presenti nella parte superiore, si apre una nestra di dettaglio contenente tutte le informazioni disponibili per quella specica analisi. 14
Figura 2.5: Dettaglio analisi. Tramite il link in alto a sinistra si accede alla sezione di gestione anagraca, contrattuale e delle analisi. 2.1.2 Pagina di gestione In questa pagina è concentrato tutto il contenuto informativo della base dati. È possibile aggiungere e modicare le informazioni di: • Cliente principale; • Cliente secondario; • Contratti; • Ticket di supporto; • Indirizzi IP; • Analisi; 15
• Documentazione (upload e download). Figura 2.6: Pagina di gestione. I pulsanti funzione appaiono disabilitati se non è possibile eseguire l'o- perazione associata. Selezionando un cliente principale le tabelle secondarie vengono popolate con le informazioni riguardanti i contratti e le informazioni riguardanti i clienti associati al cliente principale; sbloccando nel contempo anche la possibilità di aggiungerne di nuovi. Selezionando un contratto, o un cliente si attivano le restanti operazioni disponibili, spiegate successivamente. Eseguendo un doppio click su un cliente, sia principale che secondario, si apre un pop-up di dettaglio, dal quale è possibile modicare alcune informazioni; ad esempio si potrà modicare l'indirizzo email o il numero di telefono ma non la denominazione sociale e la partita IVA. Selezionando un contratto è possibile: • gestire i ticket di supporto; • esportare in formato CSV i dati relativi al contratto. 16
Dalla nestra di dettaglio del ticket, è possibile aggiungere, eliminare e modicare tickets. All'atto di inserimento e modica il sistema registra chi ha immesso il ticket ai ni di una corretta fatturazione. Figura 2.7: Dettaglio Ticket. Selezionando un cliente si attivano le seguenti funzioni: • gestione indirizzi IP; • gestione analisi con relativa documentazione. La nestra di gestione degli indirizzi IP mostra la sequenza degli indirizzi associati al cliente con relativa data d'immissione e fornisce la possibilità di aggiungerne nuovi. 17
Figura 2.8: Dettaglio Indirizzi IP. Nella vista delle analisi è presente lo storico di tutte le analisi svolte da un dato cliente raggruppate per contratto. È messo in risalto lo stato di ogni analisi. Da questa vista è possibile con un doppio click modicare lo stato e alcuni dettagli dell'analisi. Figura 2.9: Dettaglio Analisi. Gli stati disponibili identicano vari momenti in cui un'analisi di vulne- rabilità può essere sospesa in attesa di un'azione del cliente o del personale interno. Ad esempio l'attesa di documentazione da parte del cliente, l'attesa dell'autorizzazione a procedere o l'analisi è stata pianicata. 18
Ad ogni analisi dalla vista precedente si possono aggiungere un numero arbitrario di documenti di qualsiasi dimensione, tali le una volta caricati si potranno scaricare dall'apposita vista con un semplice doppio click sulla riga corrispondente. Figura 2.10: Download e upload dei le. 2.1.3 Analisi Usabilità In generale l'applicazione è stata strutturata per richiedere meno di dieci click per qualsiasi operazione. Di seguito vengono esposte alcune analisi di usabilità del sistema per alcuni i casi d'uso più frequenti. Visualizzazione situazioni d'allarme Immediatamente dopo il log-in, nella pagina iniziale sono in evidenza le principali situazioni d'allarme. Numero di click: da 0 a 2. Visualizzazione ultime analisi con relativo stato Immediatamente dopo il log-in, nella pagina iniziale sono le ultime analisi di tutti i clienti con relativo stato. Numero di click: 0 per la visualizzazione 2 per il dettaglio. Visualizzazione, inserimento, modica analisi Dalla home page è necessario andare nella pagina di gestione selezionare prima i cliente principale poi il cliente secondario ed inne aprire il dettaglio delle analisi. 19
Numero di click: 4 per la visualizzazione, 5 per l'inserimento, 6 per la modica. Visualizzazione, inserimento, modica ticket supporto Dalla home page è necessario andare nella pagina di gestione selezionare prima i cliente principale poi il contratto associato ed inne aprire il dettaglio dei ticket di supporto. Numero di click: 4 per la visualizzazione, 5 per l'inserimento, 6 per la modica. 20
2.2 Implementazione 1 Per rispettare il pattern architetturale MVC le entità sopra citate (sez. 2 1.3) sono state divise in packages e trascritte come dei POJO . Per ogni classe 3 così creata si è reso necessario creare delle classi accessorie chiamate DTO che sono gli unici oggetti abilitati a valicare i conni tra Model-View-Controller. Il design pattern adottato si può immaginare come un grattacielo dove il livello più basso è a contatto con il modello dei dati mentre il più alto è a contatto con l'operatore. Ogni livello può interagire solo con il livello immediatamente sopra e sotto. Ogni livello non deve conoscere l'implementazione dei livelli a lui vicini, ma solo l'interfaccia dei metodi esposti, ed inoltre deve ignorare l'esistenza dei livelli più distanti. Rispettando queste regole si potrà cambiare l'implementazione di un qualsiasi livello, o parte di esso, senza intaccare l'operatività degli altri livelli. Inoltre il progetto, nel rispetto del pattern MVC, è stato suddiviso in tre packages principali: • core, suddiviso a sua volta in packages contenenti le entità, raggruppa tutta la logica applicativa; • web, raggruppa i controller e classi di supporto per la gestione dell'interfaccia utente; • mail, raggruppa le classi necessarie a comporre e spedire le email di notica. Per l'implementazione è stato usato il framework per applicazioni aziendali Spring. Questo framework fornisce molti moduli importabili separatamente secondo le esigenze di progetto. Tra questi troviamo: • Spring Web MVC, fornisce strumenti per facilitare la corretta implementazione del pattern MVC; 1 Model View Controller 2 Plain Old Java Object, cioè che non implementa nessuna interfaccia del framework 3 Data Transfer Object 21
• Spring Security, fornisce strumenti per l'autenticazione e autorizzazione dell'utente; • Spring Data, fornisce strumenti per la gestione di basi di dati. Ad ogni macro modulo si possono aggiungere dei moduli specializzati, come un modulo specico per MongoDB. Similmente esistono specializzazioni che aiutano nella congurazione della sicurezza e consentono di usare diversi protocolli per l'autenticazione. Spring fornisce la possibilità di iniettare i parametri dei costruttori delle classi tramite appositi les di congurazione. All'interno di questi les si dichiarano dei bean che rappresentano l'istanza della classe creata tramite Spring. È possibile iniettare i bean deniti in altri bean, creando una catena di dipendenze. Questa caratteristica risulta particolarmente utile quando si rende necessario cambiare implementazione di una classe slegando, di fatto, la classe utilizzatrice da una precisa implementazione della classe utilizzata. Tramite l'uso di apposite annotazioni è possibile far eseguire l'iniezione automatica delle dipendenze al framework in modo da diminuire la lunghezza del le di congurazione; l'iniezione automatica cerca tra tutti i beans deniti il bean di tipo compatibile con il parametro del costruttore annotato. Questa caratteristica è stata largamente usata nella parte web dell'applicazione, si è usato un approccio misto nella parte mail e totalmente dichiarativo nel package core preferendo un maggior controllo. 2.2.1 Gerarchia delle classi L'interazione tra i vari packages e componenti esterni può essere schema- tizzata: 22
Figura 2.11: Interazione tra i packages. Nello schema si nota la divisione dei compiti secondo il pattern architetturale MVC tra i packages principali. Dove il package core contiene il livello basso dell'architettura MVC. I packages web e mail sono allo stesso livello ed entrambi usano le funzionalità messe a disposizione dal core. La struttura delle classi del packages core può essere espressa con il seguente schema, dove vengono tralasciate le interfacce e viene presentata solo un'implementazione delle varie classi. 23
Figura 2.12: Classi appartenenti al package core. 24
Per il corretto funzionamento le classi di Facade dipendono da uno o più classi Repository mentre esse dipendono solo dal DBMS scelto. Di seguito sono riportate le dipendenze delle Facade nei confronti dei Re- pository: • AnalysisFacade AnalysisRepository ContractRepository CustomerRepository MasterCustomerRepository SupportTicketRepository • CustomerFacade CustomerRepository MasterCustomerRepository • ContractFacade ContractRepository AnalysisRepository MasterCustomerRepository SupportTicketRepository • SupportTicketFacade SupportTicketRepository • MasterCustomerFacade MasterCustomerRepository • IpPoolFacade IpPoolRepository 25
• DocumentFacade DocumentRepository Il package web ha al suo interno delle classi chiamate Controller che, tramite il framework Spring e le sue servlet, collega ad URL specici dei metodi che verranno eseguiti quando verrà eettuata una richiesta all'URL. Inoltre ha al suo interno classi di supporto per l'esportazione in formato CSV dei dati e per l'integrazione con il framework ExtJS. Il package mail contiene le classi necessarie a compilare ed inviare ad una mailing list delle e-mail contenenti le situazioni d'allarme. 2.2.2 Package core Questo package comprende al suo interno tutte le classi che implementano: • la logica applicativa; • la denizione della struttura degli oggetti da persistere; • il collegamento con la base dati. I repository fanno parte del livello più basso dell'astrazione MVC. Imple- mentano il collegamento tra applicazione e la base dati. Ricevono dal livello superiore dei DTO e li convertono in oggetti da salvare, estraggono dal database i dati richiesti e il restituiscono al livello superiore. Per la loro implementazione si è deciso di procedere inizialmente con la creazione di repository residenti in memoria usando strutture dati come liste e 4 mappe di oggetti. Sono stati aggiunti metodi per eseguire le operazioni CRUD oltre a dei metodi specici per eseguire delle query prestabilite. Questa implementazione è servita solo a rendere il prototipo più completo e consentire la scrittura di test di unità, che sono serviti a stipulare un contratto sulle operazioni consentite e come comportarsi con operazioni non concesse. Inoltre questo tipo di implementazione serve esclusivamente per lo sviluppo delle prime 4 Create Read Update Delete 26
versioni del prototipo iniziale perché poco soggetta al cambio della struttura delle entità che si vuole salvare. Una volta scelto MongoDB come DBMS da usare si è proceduto ad implementare tutte le interfacce dei repository per l'uso del DBMS. È stato deciso di usare il mapper di oggetti per MongoDB del framework Spring. In questo modo il mapper, in associazione al driver per MongoDB, si occupa di salvare l'entità desiderata in una collezione con il nome dell'entità. Se questa collezione non è presente verrà creata dinamicamente. Per concludere il salvataggio l'oggetto viene mappato estraendo ogni sua proprietà e salvandola come: {Property : Value} aggiungendo un campo contenente il nome di classe completo del package di appartenenza. Se non presente viene anche aggiunto un campo id genera- to automaticamente da MongoDB. Ad esempio un'analisi memorizzata ha la seguente struttura: { _id : ObjectId(50ffad82991ad77dc97025a3), _class : net.emaze.pci.core.analysis.Analysis, dateInMillis : NumberLong(1333013378360), contractId : 1, customerId : 50ffad82991ad77dc970259c, ipPool : { addresses : [ 192.168.1.1, localhost ], dateInMillis : NumberLong(1333013378360), customerId : 50ffad82991ad77dc970259c }, result : stOK, note : analysis note } Una volta implementate le operazioni CRUD, si è proceduto ad implementare anche i metodi specici per eseguire delle interrogazioni più complesse alla base dati. Per questo passaggio sono stati fondamentali i test di unità scritti precedentemente per i repository in memoria, facendo in modo di garantire che le due implementazioni della interfaccia di repository risultassero del tutto confondibili dagli altri moduli software. Le facade sono posizionate ad un livello intermedio che si pone tra il livello dei controller ed i repository. Queste classi implementano gran parte della 27
logica applicativa sgravando il livello dei controller dall'implementazione della logica più complessa, come l'interrogazione di più repository per la compila- zione di un report. Se non sono previste operazioni particolari, questo livello viene introdotto per coerenza e semplicemente richiamerà i metodi delle classi di livello inferiore restituendo i risultati al livello superiore. Questo livello solitamente viene usato anche per le funzioni di log e auditing. 2.2.3 Package web Questo package raccoglie al suo interno le classi responsabili di intercettare le richieste provenienti dalla GUI, comporre e inviare le risposte in un formato standard. È stata usata la servlet DispatcherServlet, un'implementazione inclusa nel framework Spring, specializzandola successivamente per gestire le richieste a: • pagine HTML e JSP; • risorse JSON. Per la specializzazione della servlet che gestisce le richieste a pagine con estensione htm si è deciso di usare un InternalResourceViewResolver che si occupa, tramite un opportuno controller, di restituire una specica pagina JSP. La congurazione di questa specializzazione risulta: bean id=viewResolver class= org.springframework.web.servlet.view. InternalResourceViewResolver property name=prefix value=/WEB-INF/views// property name=suffix value=.jsp/ /bean Un controller associato risulta: @RequestMapping(value = home.htm, method = RequestMethod.GET) public ModelAndView showHomePage(MapString, Object model) { return new ModelAndView(home, model); } 28
così facendo ad ogni richiesta a ./home.htm la servlet si occupa di ricercare la pagina ./WEB-INF/views/home.jsp e restituirla al browser. Similmente è stata congurata la specializzazione della servlet che è responsabile di soddisfare le richieste in formato JSON. Per tale specializzazione è stata usata la classe MappingJacksonJsonView che si occupa di serializza- re in formato JSON il valore di ritorno dei metodi presenti nei controller per costruire la risposta. A questa servlet sono associati svariati controller più complessi, rispetto ai precedenti. Ad esempio, il controller per la memorizzazione di una nuova analisi risulta: @RequestMapping(value = storeAnalysis.json, method = RequestMethod.POST) @ResponseBody public ExtjsJsonBuilderExtjsJsonStringBuilder storeAnalysis( @RequestParam(dateInMillis) long dateInMillis, @RequestParam(result) String result, @RequestParam(contractId) String contractId, @RequestParam(customerId) String customerId, @RequestParam(note) String note) { try { final IpPool ipPool = ipPoolFacade.loadLastIpPoolOfCustomerId( customerId ); analysisFacade.storeAnalysis( new RequestAnalysis(dateInMillis, contractId, customerId, ipPool, result, note) ); return ExtjsJsonBuilder.successMessage( Analisi memorizzata con successo); } catch (Exception e) { logger.error( Errore durante il salvataggio di un'analisi,e); return ExtjsJsonBuilder.failMessage( Memorizzazione analisi fallita + e.getMessage()); } } nel quale si nota l'uso massivo di annotazioni per eseguire la mappatura tra parametri della richiesta e parametri del metodo, e l'uso di una classe di supporto per la costruzione di una risposta JSON in un formato compatibile con il framework ExtJS. 29
Tale classe di supporto si è resa necessaria in quanto il framework ExtJS richiede che le risposte in formato JSON abbiano un campo booleano che identica se la risposta è stata generata in modo corretta o è frutto di un errore. 2.2.4 Avvisi mail Le mail vengono inviate tramite protocollo SMTP gestito attraverso Java- Mail e Spring. Vengono inviate ad una mailing list predenita usando un template per ogni situazione d'allarme in modo da avvisare gli operatori interni. Si è scelto di noticare le seguenti situazioni ritenute rilevanti: • Analisi in scadenza; • Limite di analisi quasi raggiunto; • Contratti in scadenza; • Analisi bloccate in uno stato intermedio. Per la schedulazione dell'invio delle mail di avviso poteva essere eseguita in due modi: • schedulazione tramite cron; • schedulazione interna ad Apache-Tomcat. Si è scelta la seconda opzione in quanto la schedulazione attraverso cron avrebbe richiesto la divisione del progetto in due o più sotto progetti, e schedulare l'avvio di uno di questi a periodi pressati attraverso la modica di un le di congurazione del sistema operativo. Ciò avrebbe reso l'invio delle email immune da un'eventuale interruzione di Apache, ma è stata valutata una bassa criticità a fronte dell'inserimento di una maggiore complessità nel progetto. La schedulazione tramite Apache-Tomcat può essere programmata in svariati modi. Si è deciso di implementarla usando Spring-Task, che oltre ad una riga nel le di congurazione 30
task:annotation-driven / e l'annotazione del metodo da schedulare @Scheduled(cron = 0 0 0 * * ?) public void scheduledMethod() {...} non richiede altre operazioni. 2.2.5 Sicurezza Per gestire l'autenticazione si è deciso di usare Spring-Security, che fornisce tramite le di congurazione le funzionalità di autenticazione e autorizzazione con svariati metodi. Si è deciso di congurare opportunamente questo modulo per l'uso del ser- 5 ver LDAP interno per fare in modo che gli utenti registrati nella rete possano accedervi senza ulteriori registrazioni. In questo modo un utente non autenti- cato, che cerca di accedere, viene rediretto ad un semplice form d'autenticazione. Il sistema delega la verica delle credenziali al server remoto. È possibile inoltre limitare l'autorizzazione dell'uso del sistema ad un gruppo ristretto di utenti, tramite la creazione di un gruppo di lavoro sul server LDAP. 5 Lightweight Directory Access Protocol 31
Figura 2.13: Processo di autorizzazione. 32
2.3 Test 6 Un tassello molto importante della tecnica di sviluppo adottata è il TDD . Per la scrittura e l'esecuzione dei test è stato usato il framework JUnit. Sono stati scritti principalmente tre tipi di test: • test unitari; • test di integrazione; • test di accettazione. I test scritti tramite JUnit si possono generalmente suddividere in tre fasi: 1. precondizioni; 2. operazioni; 3. asserzione. Nella prima fase si creano tutte le condizioni necessarie anché si possa eseguire il test. In questa fase si istanziano classi, si riempiono liste, mappe e tabelle, anche con dati errati o non validi per testare se un determinato metodo in situazioni che potrebbero causare un arresto imprevisto dell'applicazione. Può essere eseguita anche al di fuori del metodo di test se le operazioni di inizializzazione risultano particolarmente onerose, come la connessione ad un database. Nella seconda fase si testano le singole operazioni. Se possibile all'interno di un test si dovranno usare solo operazioni già testate o facenti parte di framework o delle API Java in quanto queste operazioni sono già largamente testate ed il comportamento previsto è descritto nella documentazione. Nella terza ed ultima fase si confronta il risultato dell'operazione con il risultato previsto. Questa fase può avvenire sia se l'operazione da testare fallisce lanciando un'eccezione sia confrontando lo stato precedente e quello successivo o il valore di ritorno dell'operazione. 6 Test Driven Development 33
I test unitari servono a testare le funzionalità di una classe. Per dimostrare che la classe in esame è conforme alle speciche è necessario che superi con successo tutti i test. Per ogni metodo di ogni classe scritta, soprattutto per le classi della parte core, sono stati scritti uno o più test per certicarne il comportamento. Visto che molte classi utilizzano il concetto di tempo si è reso necessario creare due implementazioni di un interfaccia Clock, una che restituisce il tempo in millisecondi del sistema, usata nella versione reale del sistema, l'altra invece gestibile per poter testare il passare del tempo nel sistema. I test d'unità sull'implementazione in memoria delle classi di repository sono serviti anche a dimostrare che le implementazioni speciche per MongoDB avessero lo stesso comportamento prima di procedere al cambio. Ad esempio: Per testare il repository in memoria: @Test public void canStoreACustomer() { HashMapString, Customer map = new HashMapString, Customer(); InMemoryCustomerRepository inMemoryCustomerRepository = new InMemoryCustomerRepository(map); inMemoryCustomerRepository. storeCustomer(NEW_CUSTOMER); Assert.assertEquals(1, map.values().size()); } Per il repository che fa uso del DBMS MongoDB: @Test public void canStoreACustomer() { repository.storeCustomer(NEW_CUSTOMER); Assert.assertEquals(1, mongoOperations.findAll(Customer.class).size()); } Similmente le due implementazioni dovranno lanciare le stesse eccezioni a causa degli stessi eventi. Per testare il repository in memoria: 34
@Test(expected = IllegalArgumentException.class) public void storingNullCustomerThrows() { HashMapString, Customer map = new HashMapString, Customer(); InMemoryCustomerRepository inMemoryCustomerRepository = new InMemoryCustomerRepository(map); inMemoryCustomerRepository.storeCustomer(null); } Per il repository che fa uso del DBMS MongoDB: @Test(expected = IllegalArgumentException.class) public void storingNullCustomerThrows() { repository.storeCustomer(null); } I test di integrazione vericano la corretta interazione tra più classi. I test eseguiti sulle classi di facade, e sulle classi del package mail, si possono raggruppare sotto questa categoria. Come descritto nella sezione 2.2.1 ogni classe di facade ha uno o più repository da cui dipende. Da questo fatto si è reso necessario, per eseguire i test, introdurre delle implementazioni semplicate dei repository. Queste implementazioni che simulano il componente reale si chiamano mock implementando solo alcuni metodi e anch'essi con una logica estremamente semplicata. Ad esempio le implementazioni mock dei repository restituiscono un ele- mento predenito invece di memorizzare gli elementi dall'esterno, oppure hanno della logica comandabile dall'esterno come: @Override public CollectionContract loadExpiringContracts(long deadlineInMillis) { if (expiring) { return Collections.singletonList(contract); } else { return Collections.ContractemptyList(); } } public void setExpiring(boolean expiring) { this.expiring = expiring; } in cui è possibile decidere dalla classe di test se il contratto è in scadenza oppure no. 35
I test di accettazione simulano alcuni requisiti forniti dal cliente per dimostrare che i requisiti sono stati capiti e soddisfatti. Quest'ultimi sono dei test abbastanza complessi, perché un test di accettazione deve dimostrare che la logica del backend per operazioni complesse è stata scritta in modo da soddisfare i requisiti, senza alcun riferimento all'interfaccia graca. Per fare ciò si testano molte classi nello stesso momento e si verica se il sistema risponde nel modo desiderato. Ad esempio se si vuole vericare se il sistema restituisce le analisi in scadenza sarà necessario inserire: • uno o più clienti principali; • uno o più clienti secondari; • almeno un contratto; • degli indirizzi IP; • almeno una analisi. inne spostando il fronte temporale vericare se il sistema restituisce eettivamente l'analisi, o le analisi, in scadenza. 36
Capitolo 3 Conclusioni 3.1 Obiettivi e sviluppi futuri Tutti gli obiettivi principali per la messa in produzione del sistema sono stati raggiunti, consentendo ad Emaze di poter sfruttare il sistema per seguire in modo più preciso il workow PCI-DSS, mettendo a disposizione degli operatori un sistema di gestione delle analisi e dei clienti centralizzato. Come sviluppi futuri il sistema potrebbe: • avviare automaticamente le analisi pianicate tramite il software aziendale ipLegion; • inviare ai clienti e-mail automatiche di notica compilate tramite oppor- tuni template; • controllare in modo semi-automatico il report di un'analisi per determi- nare se si è stata completata con un successo od un insuccesso; • inviare ai clienti, dopo una revisione, i documenti che attestano l'esito dell'analisi; • guidare l'operatore in modo più rigido attraverso le fasi delle analisi; • collegare, se possibile, il sistema al software gestionale SAP usato in azienda per la rendicontazione automatica del lavoro svolto. 37
3.2 Lavoro svolto Sono state scritte complessivamente più di 8500 linee di codice e congurazione suddivise in: • 2200 codice Javascript; • 3400 codice Java, per un totale di 82 classi suddivise in 12 packages; • 2300 codice per il test delle varie classi. Sul sistema di Continuous Integration sono state eseguite più di 60 build automatiche con più di 200 commit nel sistema di Version Control. Al momento della stesura della tesi, sono state applicati alcuni bug x minori ed il portale viene messo in produzione all'interno della intranet di Emaze. 3.3 Valutazioni personali Personalmente sono soddisfatto del lavoro svolto che mi ha permesso di acquisire capacità e conoscenze, di confrontarmi con un ambiente lavorativo di livello avanzato. Mi ha permesso di acquisire nozioni di medio-alto livello su diversi framework utilizzati comunemente per la creazione di applicazioni enterprise. 38
Capitolo 4 Bibliograa 1. Head First Design Patterns, Eric Freeman Elisabeth Freeman, O'Reilly Media 2. Spring in action, Craig Walls, Manning Pubblications Co. terza edizione 3. MongoDB in action, Kyle Banker, Manning Pubblications Co. terza edizione 4. Sito e documentazione Spring http://www.springsource.org/ (a) Pacchetto base http://www.springsource.org/spring-framework i. Spring MVC http://static.springsource.org/spring/docs/3.1.x/ spring-framework-reference/html/mvc.html (b) Mapper e driver MongoDB http://www.springsource.org/spring-data/mongodb (c) Autenticazione http://www.springsource.org/spring-security i. Autenticazione tramite LDAP http://static.springsource.org/spring-security/ site/docs/3.1.x/reference/ldap.html 5. Sito ExtJS http://www.sencha.com/products/extjs 39
(a) API della specica versione utilizzata http://docs.sencha.com/ext-js/4-1/#!/api 6. Sito MongoDB http://www.mongodb.org/ 7. Sito PCI-DSS https://www.pcisecuritystandards.org/security_standards/ 40
Ringraziamenti Il primo ringraziamento va ai miei genitori, nanziatori unici di questo periodo universitario. A Cinzia la mia ragione di vita. Un ringraziamento particolare va a Davide fonte di innita conoscenza, che ha saputo guidarmi in questa avventura. Inne ringrazio tutti i miei amici che mi hanno pazientemente sopportato in tutti questi anni. 41

Analisi e sviluppo di uno strumento per l'automazione della verifica di conformità allo standard pci dss

Recommandé

Contenu connexe

Similaire à Analisi e sviluppo di uno strumento per l'automazione della verifica di conformità allo standard pci dss(20)

Dernier(20)

Analisi e sviluppo di uno strumento per l'automazione della verifica di conformità allo standard pci dss