UNIVERSITÀ DEGLI STUDI DI TRIESTEDipartimento di Ingegneria e Architettura

Corso di Studi in Ingegneria Informatica

INTEGRAZIONE E SVILUPPO DI UNAPIATTAFORMA PER LA GESTIONE

DELLE CONFORMITÀ ALLOSTANDARD PCI-DSS

Tesi di Laurea Triennale

Laureando:Alessandro UMEK

Relatore:prof. Alberto BARTOLI

CorrelatoreEnrico Milanese

_____________________________________

ANNO ACCADEMICO 2014-2015

IndiceIntroduzione..................................................................................................................2

Contesto...............................................................................................................2Problema..............................................................................................................2Soluzione.............................................................................................................3Vincoli progettuali...............................................................................................3Risultato...............................................................................................................4Articolazione della tesi........................................................................................4

Analisi e progettazione.................................................................................................51.1 Situazione preesistente.......................................................................................5

1.1.1 Esempio pratico del procedimento in caso di falso negativo.....................51.1.2 Piattaforma PciWebApp.............................................................................61.1.2 Database analisi..........................................................................................61.1.3 Database delle vulnerabilità.......................................................................61.1.4 Script per la generazione del report............................................................7

1.2 Analisi del report di vulnerability assesment.....................................................71.3 Definizione delle entità....................................................................................15

Realizzazione..............................................................................................................162.1 Implementazione..............................................................................................16

2.1.1 Struttura delle classi.................................................................................162.1.2 Configurazione Spring Framework e dependency injection....................172.1.2.1 Configurazione xml-based....................................................................182.1.2.2 Configurazione annotation-based..........................................................182.1.3 Struttura dell'applicativo...........................................................................20

2.1.4 Integrazioni al package core.....................................................................202.1.4.1 Il package xml.......................................................................................212.1.4.2 XmlRepository......................................................................................232.1.4.3 PciGen...................................................................................................252.1.4.4 XmlFacade.............................................................................................262.1.4.5 Il package emvdb...................................................................................282.1.5 Integrazioni al package web.....................................................................30

2.2 Interfaccia utente..............................................................................................312.2.2 Scelta del report........................................................................................332.2.2 Pagina di visualizzazione del report.........................................................352.2.2.1 Il pannello degli host.............................................................................382.2.2.2 Il pannello delle porte............................................................................382.2.2.3 Il pannello delle vulnerabilità................................................................382.2.2.4 Pannello di dettaglio della vulnerabilità................................................392.2.2.5 Pannello nuova vulnerabilità.................................................................412.2.2.6 Il pannello delle modifiche....................................................................422.2.3 La finestra emvdb.....................................................................................432.2.3 La finestra di salvataggio..........................................................................44

Conclusioni.................................................................................................................473.1 Obiettivi............................................................................................................473.2 Lavoro svolto...................................................................................................473.3 Valutazioni personali........................................................................................48

Bibliografia.................................................................................................................49

1

Introduzione

Questa tesi illustra il lavoro svolto da me presso Emaze Network s.p.a.

Contesto

PCI è un consorzio creato da American Express, Discover Financial Services, JCB,

MasterCard Worldwide e Visa International. Il consorzio è stato formato allo scopo

di realizzare uno standard a cui tutte le aziende che implementano soluzioni che

prevedono la trasmissione, la memorizzazione o l'utilizzo di carte di credito devono

attenersi. Il risultato è lo standard DSS.

Uno dei requisiti richiesti dallo standard è l'analisi delle vulnerabilità sulla propria

infrastruttura pubblica da parte di una società certificata(ASV).

Problema

Emaze s.p.a è una ASV e si occupa quindi di effettuare le scansioni secondo quanto

richiesto dallo standard PCI-DSS e fornire ai clienti una documentazione contenente

il risultato della scansione.

La documentazione viene realizzata inserendo in alcuni template i dati relativi alle

scansioni effettuate. Questi dati sono memorizzati all'interno di un documento xml

che contiene quindi tutte le informazioni tra cui:

• ip pubblici scansionati

• porte aperte per ogni ip

• vulnerabilità trovate

A seguito di una verifica da parte dell'operatore preposto alla scansione potrebbero

2

essere necessarie delle modifiche ai dati aggiungendo (falsi negativi) o rimuovendo

(falsi positivi) delle vulnerabilità.

Visto il numero di clienti a cui Emaze forniva questo servizio il processo di modifica

era diventato molto oneroso in quanto veniva eseguito in maniera manuale tramite

l'utilizzo di alcuni script che venivano eseguiti da terminale per inserire, rimuovere le

vulnerabilità o per generare i nuovi documenti da fornire al cliente.

Soluzione

La soluzione individuata è stata di creare una piattaforma centralizzata per:

1. storicizzare i risultati (secondo la normativa devono essere conservati almeno

due anni)

2. gestire i clienti e i contratti in essere con limiti di analisi e limiti temporali

3. automatizzare il processo documentale

4. modificare i report di vulnerability assessment tramite interfaccia grafica

5. facilitare la creazione di report

In precedenza Emaze aveva realizzato una piattaforma che risolveva i punti 1,2,3, la

piattaforma PciWebApp, per questo motivo si è scelto di integrare tale piattaforma

implementando le funzioni di modifica e generazione dei report

Vincoli progettuali

Trattandosi di un'integrazione ad una piattaforma già esistente il progetto è stato

realizzato con le tecnologie con le quali era stata implementata questultima:

• Java

• Spring Framework, framework utilizzato per la realizzazione MVC

• Apache Tomcat, servlet container

• PostgreSQL, dbms per il database delle vulnerabilità

3

• MongoDB, dbms nosql utilizzato dall'applicazione per memorizzare le analisi

svolte

Risultato

L'applicazione realizzata rispetta i vincoli progettuali

Tramite l'applicativo realizzato l'utente può :

• modificare i report tramite l'interfaccia grafica aggiungendo o rimuovendo

vulnerabilità e porte aperte

• generare i report aggiornati in formato pdf e xml

Articolazione della tesi

I capitoli seguenti saranno così suddivisi:

• Analisi e progettazione : analisi del problema, definizione dei requisiti

dell'applicativo che dovrà essere realizzato.

• Realizzazione: descrizione di come è stato realizzato l'applicativo, sia lato

server sia l'interfaccia utente

• Conclusioni: descrizione del lavoro svolto, possibili sviluppi futuri

• Bibliografia: riferimenti bibliografici e fonti utilizzate

4

CAPITOLO 1

Analisi e progettazione

1.1 Situazione preesistente

Con il tempo Emaze aveva già realizzato vari strumenti per l'automatizzazione delle

scansioni, la generazione dei report e la gestione documentale. Ciò che bisognava

realizzare era quindi un'integrazione tra le varie piattaforme esistenti in modo da

automatizzare alcuni passaggi che venivano svolti in maniera manuale dall'utente.

1.1.1 Esempio pratico del procedimento in caso di falso negativo

Un falso negativo si presenta quando un operatore rileva una vulnerabilità su un

sistema che non era stata individuata durante la scansione automatica. In questo caso

la vulnerabilità deve essere inserita nel report xml, deve venir rigenerata tutta la

documentazione che deve restare memorizzata per la durata di tempo stabilita dalla

secondo la normativa.

Per eseguire questa operazione l'operatore doveva

1. Individuare l'identificativo della vulnerabilità che deve essere aggiunta al

report nel database delle vulnerabilità.

2. Eseguire lo script per la generazione dei report passando in input il vecchio

report e l'identificativo della vulnerabilità da aggiungere e ricevendo in output

il nuovo report aggiornato in formato xml

5

3. Eseguire lo script per la generazione dei report in formato Pdf e Docx

4. Importare tutti i nuovi documenti nella piattaforma PciWebApp

1.1.2 Piattaforma PciWebApp

La piattaforma PciWebApp era stata realizzata in precedenza allo scopo di gestire le

analisi effettuate, la relativa documentazione, l'anagrafica dei clienti e la relativa

situazione contrattuale.

Le nuove funzionalità, necessarie alla modifica del report di valutazione di

vulnerabilità del sistema, verranno integrate all'interno di questa piattaforma. Per

questo motivo rivestono particolare importanza le scelte1 effettuate precedentemente

dallo sviluppatore per realizzarla.

Per quanto riguarda l'interfaccia utente era stato utilizzato il framework Javascript

ExtJS, per l'implementazione del web server era stato utilizzato il framework Spring.

1.1.2 Database analisi

Il database delle analisi si basa sul DBMS MongoDB, all'interno di questo database

dovranno essere memorizzati i nuovi documenti che verranno generati.

Non sarà necessario sviluppare nuove funzionalità per interfacciarsi al database in

quanto verranno utilizzate le funzioni già presenti all'interno della piattaforma

PciWebApp.

1.1.3 Database delle vulnerabilità

Il database delle vulnerabilità utilizza il DMBS PostgreSQL e contiene l'elenco delle

vulnerabilità conosciute per le quali viene eseguita la scansione Pci-Dss.

Per realizzare l'applicativo sarà necessario implementare le funzionalità necessarie

per interfacciarsi a questo database solo in lettura.

1 Linguaggio di progrtammazione. Framework, design pattern

6

1.1.4 Script per la generazione del report

Gli script per la generazione dei report sono stati realizzati tramite il linguaggio di

programmazione Python. Per realizzare i report venivano eseguiti due script diversi,

uno per aggiungere o rimuovere le vulnerabilità dal file xml mentre l'altro per

generare i documenti in formato pdf e docx da inviare al cliente.

Questi due script verranno modificati in parte per poter essere eseguiti in maniera

automatica nella fase di creazione del nuovo report.

1.2 Analisi del report di vulnerability assesment

I dati che dovranno essere elaborati sono presenti all'interno del report in formato

xml. Questi report sono memorizzati nel database delle analisi, l'applicativo che si

vuole realizzare dovrà recuperare il report dal database delle analisi, fare il parsing

del documento xml e fornire i dati necessari all'utente.

L'applicativo dovrà poi ricevere le modifiche effettuate al report dall'utente e

generare un nuovo report, a partire da quello iniziale, applicando le modifiche

effettuate.

La prima fase del progetto è stata quindi l'analisi dei dati contenuti all'interno del

7

Illustrazione 1: Struttura base del report

documento in modo da individuare quali fossero quelli utili alla realizzazione

dell'applicativo.

Il report contiene una grande mole di dati, di cui alcuni ridondanti e soltanto alcune

parti rilevanti ai fini dell'applicativo. Dall'illustrazione 1 si può notare la struttura del

report. L'elemento report è l'elemento root dell'xml al cui interno sono presenti 12

elementi figli. Tutti i dati utili per le operazioni di modifica si trovano all'interno

dell'elemento hosts, mentre negli altri elementi sono presenti dati che saranno utili

per la generazione del report in pdf come il titolo o l'intestazione del documento da

generare, oppure dati ridondanti che possono essere calcolati sulla base di quelli

presenti all'interno dell'elemento host. Nella fase di generazione del nuovo report

sarà lo script Python a ricalcolare i campi ridondanti in base a quelli presenti

nell'elemento hosts.

L'elemento hosts ha come attributo il campo “count” contenete il numero di host

scansionati, anche questo elemento può essere calcolato e verrà rigenerato

automaticamente. Sono invece rilevanti gli elementi figli del campo hosts: gli

elementi host. Quest'ultimi rappresentano gli host del cliente sui cui è stata eseguita

la scansione. Per quanto riguarda gli attributi del campo host è presente l'ip del host e

una serie attributi che rappresentano il livello di vulnerabilità dell'host. Di questi dati

soltanto l'ip è rilevante gli altri invece possono essere calcolati.

8

Illustrazione 2: Struttura dell'elemento hosts

L'elemento host contiene al suo interno tutti i dati di maggior interesse. Al suo

interno infatti sono presenti sia le porte aperte, sia le vulnerabilità suddivise in

confermate, potenziali e security notices.

L'elemento openPorts contiene al suo interno l'elemento protocol che suddivide le

porte tra quelle che utilizzano il protocollo TCP2 e quelle che utilizzano quello UDP3.

Gli elementi protocol a loro volta contengono gli elementi port al cui interno sono

presenti il numero di porta, il nome del servizio e il conteggio di vulnerabilità e

notice rilevate su quella porta. I dati rilevanti ai fini dell'applicativo sono il

2 Transmission Control Protocol3 User Datagram Protocol

9

Illustrazione 3: Struttura del elemento host

Illustrazione 4: Struttura dell'elemento openPorts

protocollo il numero di porta ed il nome del servizio.

Due delle possibili operazioni che possono essere effettuate dall'operatore sono:

1. la rimozione della porta, in questo caso sarà necessario cercare l'elemento

port in base a protocollo e numero di porta ed eliminarlo dal report

2. l'aggiunta di una porta, in questo caso sarà necessario aggiungere un

elemento port con il numero di porta ed il nome del servizio specificati

Oltre all'elemento openPorts rivestono notevole importanza i dati contenuti

all'interno degli elementi confirmedVulnerabilities e potentialVulnerabilities, al cui

interno troviamo le vulnerabilità rilevate. L'elemento vulnerabilità contiene

l'identificativo della vulnerabilità, il livello di gravità, il nome della vulnerabilità, il

valore cvss4 e il conteggio delle istanze rilevate della vulnerabilità.

Altro elemento importante è securityNotice, che contiene al suo interno una lista di

elementi notice. L'elemento notice rappresenta degli avvisi che vengono forniti al

4 Common Vulnerability Scoring System

10

Illustrazione 5: Struttura di una vulnerabilità

Illustrazione 6: Struttura di una Notice

cliente all'interno del documento finale. Analizzando la struttura dell'elemento notice

(avviso) si può notare come questa sia molto simile a quella dell'elemento

vulnerability con la differenza che non sono presenti i campi severity, possiamo

infatti trattare un avviso come una vulnerabilità di gravità “notice”.

Anche per vulnerabilità ed avvisi sono previste le operazione di cancellazione ed

inserimento alle quali si aggiunge l'operazione di spostamento tra una lista e l'altra,

ad esempio una vulnerabilità potenziale può diventare confermata.

Per quanto riguarda l'inserimento sarà sufficiente inserire un elemento vulnerability o

notice con al suo interno l'elemento id, tutti gli altri campi saranno poi inseriti in

maniera automatica dallo script di generazione del report.

L'ultima parte del elemento host è quella composta dagli elementi

confirmedVulnerabilityList, potentialVulnerabilitiesList, noticesList al cui interno

sono presenti vulnerabilità e gli avvisi che erano presenti anche in precedenza ma al

cui interno sono presenti dati diversi.

Ai fini dell'applicativo risultano rilevanti gli elementi standards e istances.

Gli standard contengono delle valutazioni della rilevanza della vulnerabilità secondo

11

Illustrazione 7: Struttura dell'elemento confirmedVulnerabilityList

vari indici e dovranno essere visualizzati all'operatore. L'elemento standard è

composto dal tipo5 di standard e dal valore della vulnerabilità secondo quest'ultimo.

Su questo elemento non sono previste operazioni di modifica.

L'elemento istances invece contiene le singole istanze delle vulnerabilità rilevate, ad

esempio una vulnerabilità potrebbe affliggere più porte di servizi differenti.

Per quanto riguarda le istanze a differenza degli standard non solo devono esser

visualizzate ma è prevista anche la creazione di nuove e la rimozione di quelle

esistenti. Da notare che non può esistere una vulnerabilità senza istanze quindi nel

caso venisse rimossa l'ultima istanza di una vulnerabilità la vulnerabilità stessa dovrà

essere rimossa.

1.3 Definizione delle entità

Sulla base dell'analisi del report di vulnerability assesment sono state individuate le

entità che dovranno essere manipolate dall'utente tramite l'applicativo.

Le entità rilevate sono:

• host, rappresentano il singolo host su cui è stata svolta la scansione. Ogni host

è caratterizzato da un indirizzo ip.

• port, le porte aperte rilevate durante la scansione si distinguono in base al

protocollo (TCP, UDP) al numero di porta su cui sono in ascolto ed al nome

del servizio

• vulnerability, le vulnerabilità rilevate che possono essere potenziali,

confermate oppure avvisi. Ogni vulnerabilità avrà un nome, una descrizione,

una famiglia, la data di pubblicazione e quella in cui è stata aggiornata. Per

quanto riguarda le vulnerabilità potenziali e confermate è presente un

5 Nome dello standard

12

ulteriore informazione riguardante la gravità della vulnerabilità.

• instance, una vulnerabilità può esser presente su più porte del singolo host

ogni singola porta cui è presente la vulnerabilità rappresenta un'istanza di

quest'ultima. Per alcune vulnerabilità è previsto anche il caso di istanze non

legate alla porte

• standard, sono coppie composte da identificativo dello standard e valore con

cui vengono catalogate le vulnerabilità

Per quanto riguarda le relazioni tra le entità si è cercato di mantenere la struttura ad

albero del documento xml per rendere più semplici possibili le operazioni di lettura e

modifica.

L'entità host conterrà quindi al suo interno un elenco di porte suddivise in base al

protocollo e di vulnerabilità suddivise in confermate e potenziali ed avvisi. A sua

volta le vulnerabilità conterranno un elenco di istanze e standard.

Nell'illustrazione 8 è rappresentata la struttura delle classi Java realizzate in base

all'analisi effettuata.

13

Illustrazione 8: Diagramma UML realizzato in base alle entità

CAPITOLO 2

Realizzazione

2.1 Implementazione

L'applicativo è stato realizzato rispettando il pattern architetturale MVC in cui si ha

una netta separazione tra il model che contiene di metodi di accesso ai dati, la view

che visualizza i dati all'utente e il controller che riceve i comandi dall'utente ed

esegue le operazioni necessarie.

Oltre al pattern MVC si è scelto di utilizzare il pattern facade, in italiano facciata, che

permette di nascondere la complessità di un'operazione ad una classe client.

2.1.1 Struttura delle classi

Per rispettare i pattern previsti la struttura del programma realizzato è la seguente:

• il model costituito dalla rappresentazione delle entità individuate in fase di

analisi in classi POJO

• la view è stata realizzata con il framework extjs che si occuperà di

rappresentare i dati e raccogliere gli input da parte dell'utente ed inviarli al

controller per essere eseguiti

• il controller che riceve le richieste da parte della view le elabora eseguendo i

metodi dei service

• il service riceve le richieste del service ed esegue i metodi delle classi

repository

• il repository sono le classi che si occupano di elaborare i dati quindi nel caso

14

dell'xml riceverà la richiesta da parte del service elaborerà il file xml in modo

da trasferire i dati presenti all'interno delle classi POJO6 che verranno poi

inviate dal controller alla view, mentre nel caso del database emvdb si

occuperà della lettura dei dati dal database.

Utilizzando questa struttura ogni livello dell'applicativo comunica solamente con

quello successivo e quello precedente, ad esempio la classe controller non conosce

l'esistenza della classe repository e dei suoi metodi. In questa maniera l'applicativo

risulterà facilmente estendibile o modificabile. Se ad esempio si vorrà modificare un

metodo del service basterà realizzare una nuova implementazione di quella classe

senza dover effettuare alcuna modifica ai livelli adiacenti.

2.1.2 Configurazione Spring Framework e dependency injection

Come visto in precedenza l'applicativo è stato realizzato utilizzando Spring

Framework. Quest'ultimo tra le altre cose si occupa, quando viene eseguito

l'applicativo, di creare le istanze delle classi necessarie all'esecuzione della web

application ed “iniettarle” dove è necessario, gli oggetti che vengono istanziati in

questo modo prendono il nome di bean.

Per il corretto funzionamento devono essere create le istanze dei service, dei

controller e dei repository. I repository vengono poi iniettati come variabile nel

service e la stessa cosa deve essere poi eseguita con il service all'interno del

controller.

I metodi previsti da Spring Framework per effettuare questa operazione sono 2 e

sono stati utilizzati entrambi all'interno dell'applicativo:

1. Xml based

6 Plain Old Java Object: classi Java che non implementano un'interfaccia ne estendono una classe

15

2. Annotation based

La scelta di utilizzarli entrambi è stata determinata dalla volontà di dare continuità

alle scelte che erano state effettuate per realizzare la piattaforma per la quale si sta

eseguendo l'integrazione.

2.1.2.1 Configurazione xml-based

Utilizzando la configurazione basata sull'xml i bean vengono definiti all'interno di un

file di xml a parte. Nell'applicativo è stata utilizzata questa configurazione per

istanziare i service ed i repository.

Queste sono ad esempio le configurazioni necessarie per istanziare un repository ed

un service.

<bean id="vulnerabilityFacade" class="net.emaze.pci.core.emvdb.DefaultVulnerabilityFacade">

<constructor-arg ref="vulnerabilityRepository" /></bean>

<bean id="vulnerabilityRepository"

class="net.emaze.pci.core.emvdb.DefaultVulnerabilityRepository"> <constructor-arg ref="jdbcTemplate" /></bean>

Le classi da istanziare vengono racchiuse nel tag bean che contiene gli attributi id e

class. L'id è l'identificatore del bean che potrà essere usato dagli altri bean. La classe

rappresenta il tipo di oggetto da istanziare. All'interno di ogni bean è presente un

ulteriore tag il constructor-arg, tale oggetto rappresenta un'istanza che deve essere

passata al costruttore del bean. L'istanza da passare al costruttore viene poi

identificata dall'attributo ref al cui interno è presente l'identificativo del bean

istanziato in precedenza.

2.1.2.2 Configurazione annotation-based

La configurazione basata sulle annotazioni non prevede l'utilizzo di file aggiuntivi

16

per la configurazione dei bean che vengono invece definiti in base ad alcune

annotazioni Java inserite direttamente all'interno della classe.

Questo tipo di configurazione è stato utilizzato per istanziare i controller del

applicativo.

@Controller

public class VulnerabilityController {

VulnerabilityFacade vulnerabilityFacade;

private static final Logger logger = Logger.getLogger();

@Autowired

public VulnerabilityController(VulnerabilityFacade vulnerabilityFacade) {

this.vulnerabilityFacade = vulnerabilityFacade;

}

}

Le annotazioni utilizzate in questo esempio sono 2 :

• @Controller

• @Autowired

L'annotazione @Controller ha come target una classe e viene interpretata come

il tag bean nella configurazione xml-based, le classi annotate con questa annotazione

verranno quindi istanziate automaticamente. Oltre all'annotazione @Controller

esistono altre annotazioni che vengono interpretate allo stesso modo la Spring

Framework, ad esempio se per i service ed i repository fosse stata utilizzata la

configurazione annotation-based le rispettive classi sarebbero state annotate con

@Service, @Repository7.

L'annotazione @Autowired invece può essere utilizzata sia a livello di campo, sia

di metodo, sia di costruttore. Nell'applicativo è stata utilizzata a livello di costruttore

7 Spingframework instanzia tutte le classi che sono annotate con @Compontent, annotazione con cui tutte queste annotazioni sono annotate

17

e svolge quindi la funzione di iniettare come parametro del costruttore il service

istanziato in precedenza.

Da notare che mentre nella configurazione xml-based veniva utilizzato un

identificativo per iniettare il bean all'interno del costruttore nella configurazione

annotation-based l'oggetto da iniettare viene identificato automaticamente in base

alla classe dell'oggetto. Questo tipo di approccio potrebbe portare a dei problemi se

esisterebbero due bean della stessa classe oppure, nel caso in esempio, che

implementano la stessa interfaccia.

2.1.3 Struttura dell'applicativo

Lo sviluppatore che aveva realizzato in precedenza la piattaforma PciWebApp aveva

deciso di suddividere l'applicativo in 3 packages

• net.emaze.pci.core: contenente i metodi per intefacciarsi ai dati elaborati

dall'applicativo

• net.emaze.pci.web: contenente i controller dell'applicativo

• net.emaze.pci.mail: contenente i metodi per l'invio delle notifiche via email

Come in precedenza si è scelto di mantenere le scelte progettuali effettuate dallo

sviluppatore per dare continuità al progetto. Le nuove funzionalità sono state quindi

integrate all'interno packages esistenti.

2.1.4 Integrazioni al package core

All'interno del package “core” sono stati inseriti 2 nuovi package:

• net.emaze.pci.core.xml: contenente i metodi per gestire i report xml

• net.emaze.pci.core.emvdb: contenente i metodi per interfacciarsi al database

delle vulnerabilità

18

2.1.4.1 Il package xml

All'interno di questo package sono presenti tutte le interfacce e le classi che sono

state realizzate per permettere l'elaborazione del report xml. Per prima cosa sono

state realizzate della classi POJO a partire dalle entità trovate in fase di analisi.

Nel diagramma sono stati omessi i metodi getter e setter delle classi. Queste classi

non implementano nessuna logica ma contengono i dati e i metodi per accedervi.

Oltre alle entità è stata individuata una ulteriore classe necessaria all'elaborazione

dell'xml, questa classe conterrà l'elenco dei cambiamenti da effettuare dal xml di

partenza per generare il nuovo xml elaborato.

Le informazioni presenti nella classe Change sono le seguenti:

• operazioni da eseguire (rimozione od aggiunta)

19

Illustrazione 9- Diagramma UML dell'entità del package XML

Illustration 10- Diagramma UML Classe Change

• type (porta tpc,porta udp, vulnerabilità potenziale, vulnerabilità confermata,

notice)

• ip del server su cui deve essere eseguita l'operazione

• number (numero della porta o identificativo della vulnerabilità)

La scelta di utilizzare questa classe è dovuta al fatto che essendo la modifica dell'xml

una procedura molto lunga si è scelto di mantenere tutte le modifiche in memoria

lato client e trasferirle soltanto a fine elaborazione al server. Il server riceverà una

lista di cambiamenti da effettuare, modificherà il report xml e una volta generato il

nuovo xml con le modifiche effettuate verrà passato come parametro allo script

PciGen che lo elaborerà per renderlo conforme allo standard PCI-DSS.

Le classi che contengono la logica del package sono le classi repository e service.

Entrambe le classi sono stare realizzate prevedendo prima di tutto le interfacce e poi

provvedendo ad implementarle. Nella classe XmlDefaultFacade sarà definito un

oggetto del tipo XmlRepository. In questo modo. In questo modo il service non

conoscerà l'implementazione del repository che potrà essere variata in un secondo

momento in maniera completamente trasparente al service.

2.1.4.2 XmlRepository

Le funzioni svolte dal repository possono essere suddivise in due aree, la lettura dei

dati dal report e la scrittura delle modifiche. I metodi che svolgono la lettura sono:

parseXml, parseHostFromXml, parsePortFromXml, parseVulnerabilityFromXml.

Questi metodi ricevono in input il report come oggetto java GridFSDBFile e

ritornano in output una lista degli oggetti richiesti8.

8 Host, porte o vulnerabilità

20

In una prima fase l'applicativo era stato sviluppato con un'unica richiesta di lettura da

parte del client. Questo tipo di approccio si è però poi rivelato non adatto nei casi in

cui il report fosse particolarmente complesso, si è quindi deciso di suddividere le

operazioni di lettura. La prima richiesta sarà di ricevere l'elenco degli ip scansionati,

successivamente, quando l'utente selezionerà un indirizzo ip da esaminare, verranno

effettuate le richieste di lettura di porte e vulnerabilità per quell'indirizzo ip. Per

questo motivo sono quindi stati inseriti i metodi parseHostFromXml,

parsePortFromXml, parseVulnerabilityFromXml. Con questo approccio a differenza

del precedente si sono ridotti drasticamente i dati trasmessi tra il client ed il server

riducendo quindi i tempi di elaborazione per report con molti host.

Per quanto riguarda la scrittura dei dati il metodo di maggior interesse è il metodo

setChanges, che riceve in input l'elenco dei cambiamenti e li elabora restituendo un

oggetto che implementa l'interfaccia Document9. L'interfaccia Document permette di

trasformare il report xml in un oggetto Java semplificando le operazioni di lettura e

modifica. Anche le operazioni di lettura sono state effettuare trasformando prima di

tutto il report in un oggetto di tipo document. Nella fase di modifica si è scelto di

restituire questo tipo di oggetto per evitare di effettuare diversi operazioni

effettuando un'unica volta il parsing dell'xml.

9 org.w3c.dom.document

21

Illustrazione 11- Diagramma UML dell'interfaccia XmlRepository

2.1.4.3 PciGen

La classe PciGen è la classe che si occupa della generazione del report. Oltre alla

classe PciGen è stato necessario creare una classe che verrà utilizzata in fase di

generazione dei report per settare alcune informazioni, la classe DocXInfo.

Come per le altre classi anche per la classe DocXInfo sono stati omessi i metodi

getter e setter. Lo scopo di questa classe è quello di contenere le informazioni che

dovranno poi essere inserite al momento della generazione del file in formato docx.

Nello specifico i 4 attributi sono:

• company name, il nome del cliente per cui è stata effettuata la scansione

• reportDate, la data in cui è stata generato il report da modificare

• scanEndDate, il momento in cui il report viene generato

• scanExpirationDate, 90 giorni dopo la fine della scansione

La classe PciGen contiene 4 attributi istanziati nel costruttore tramite dependency

injection e i due metodi per la generazione del report xml. Gli attributi contengono i

comandi che lanceranno l'esecuzione degli script Python e vengono letti da un file di

properties ed iniettati nel costruttore. I comandi sono stati definiti in questa maniera

in modo da essere modificabili senza che sia necessario ricompilare il programma.

I primo metodo della classe PciGen è il metodo executeUpdate che riceve in input

22

Illustrazione 12: Diagramma delle classi PciGen e DocXInfo

l'oggetto Document elaborato, chiama lo script Python che si occupa di eseguire

l'update e restituisce in output un oggetto java di tipo HashMap10 contente il file

elaborato e l'output delle script stesso. Questo metodo verrà chiamato dalla classe

facade per ottenere il file xml da salvare nel database dopo che sono stati eseguiti dei

cambiamenti.

Il secondo metodo invece riceve nuovamente in input un oggetto di tipo document

ma restituisce un file zip contenente tutti i documenti da consegnare al cliente11,

riceve inoltre come parametro l'oggetto DocXInfo contenete le informazioni che

serviranno per generare i report in formato docx e pdf.

2.1.4.4 XmlFacade

La classe facade, come previsto dai pattern adottati ha lo scopo di nascondere la

complessità delle operazioni di modifica del report al repository.

Anche nel service, come in precedenza per il repository, la lettura dei dati in una

prima fase la lettura veniva svolta esclusivamente dal metodo

getHostFromDocument ma per problemi di prestazioni sono stati poi aggiunti i

metodi per la lettura delle sole vulnerabilità o delle porte in base all'host.

A differenza dei repository, i metodi che svolgono le funzionalità di lettura non

hanno come parametro il file ma la stringa id, sarà compito del service, infatti,

10 java.util.HasMap<K,V>11 Pdf, DocX ed Xml

23

Illustrazione 12: UML Interfaccia XmlFacade

interrogare il database delle analisi per ottenere il file xml da passare al repository

per essere elaborato.

Un'altra differenza rispetto al repository è la suddivisione in tre metodi per la lettura

delle vulnerabilità, sarà infatti il service in base al metodo chiamato ad impostare il

parametro tipo da passare come parametro al metodo parseVulnerabilityFromXml

del repository.

// Esempio di implementazione di un metodo di lettura della classe facade

@Override

public Collection<Vulnerability> getSecurityNotices(String id, String ip) {

// richiedo il file dal documentRepository iniettato in

// precedenza nel costruttore

GridFSDBFile loadDocument = (GridFSDBFile) documentRepository.loadDocument(id);

// richiamo la funzione parseVulnerabilityFromXml passando come //parametri il documento da elaborare, l'ip e come tipo il

// tipo “noticeList” restituisco al controller la riposta del //repository

return xmlRepository.parseVulnerabilityFromXml(loadDocument, ip, "noticesList");

}

Le altre funzioni svolte dalla classe facade sono la scrittura del documento xml,

svolta dal metodo saveXml e la generazione dei report svolta dal metodo getZipFile.

Questi due metodi sono quelli per i quali è maggiormente evidente l'importanza

dell'implementazione del facade design pattern in quanto le implementazioni si

interfacciano a diversi repository.

Ad esempio, il metodo getZipFile si interfaccia con il repository delle analisi, dei

clienti, dei documenti, oltre che con l'xml repository e la classe PciGen.

@Override

public File getZipFile(String id) {

// richiedo il documento al repository dei documenti

GridFSDBFile loadDocument = (GridFSDBFile) documentRepository.loadDocument(id);

// richiedo al repository di trasformare il file in un oggetto

24

//document

Document document = xmlRepository.loadXml(loadDocument);

// interfacciandomi prima con il repository dei documenti e poi con //quello delle analisi ottenendo l'id dell'analisi

Analysis analisi = analysisRepository.loadAnalysisById(

documentRepository.getAnalysisIdfromDocumentId(id)

);

// ottengo il cliente dal repository dei clienti

Customer c = =customerRepository.loadCustomerById(analisys.getCustomerId());

// ottengo la data di scansione dall'xml repository

String scanDate = xmlRepository.getStartDate(document);

// ottenute tutte le informazioni posso chiamare il metodo createZip//della classe pci che si occupa della generazione dei report

return pciGen

.createZip(document, new DocxInfo(loadCustomerById.getName(),scanDate));

}

2.1.4.5 Il package emvdb

Il package emvdb contiene tutte le classi che permettono di interfacciarsi al database

emvdb. Per lo sviluppo dell'applicativo è stato necessario esclusivamente interrogare

il database per ottenere l'elenco delle vulnerabilità, non sono previste infatti

operazioni di inserimento,modifica o cancellazione dei dati.

Il motivo per cui è stato necessario interfacciarsi con il database è per permettere

l'aggiunta di una vulnerabilità non presente nel report. Le possibili richieste sono

quindi:

1. ottenere l'elenco delle vulnerabilità

2. ottenere i dettagli delle vulnerabilità in modo da poterla aggiungere al report

Oltre ai metodi per ottenere l'elenco delle vulnerabilità è stato realizzato un metodo

che restituisca il conteggio delle vulnerabilità totali in base al filtro per permettere al

framework ExtJS una corretta paginazione dei risultati.

Inoltre è stata realizzata una terza classe, la classe Filter, per trasformare i filtri

ricevuti dal server in condizioni da inserire all'interno della query SQL.

25

Come in precedenza nel diagramma UML sono state omesse le implementazioni dei

repository e delle classi facade.

La connessione al database è stata effettuata sfruttando le classi fornite dal

framework Spring. Nel dettaglio sono state usate le classi:

• DriverManagerDataSource12, classe che si occupa della connessione con il

database

• SimpleJdbcTemplate13, classe che semplifica le operazioni crud sul database

Per istanziare gli oggetti è stata usata la configurazione xml-based e i dati necessari

alla connessione sono stati inseriti in un file di properties.

Il template è stato poi iniettato nel repository per consentire l'interrogazione del

database.

<bean id="psqlDataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="org.postgresql.Driver" /> <property name="url" value="${postgres.url}"/> <property name="username" value="${postgres.username}"/> <property name="password" value="${postgres.password}"/></bean> <bean id="jdbcTemplate" class="org.springframework.jdbc.core.simple.SimpleJdbcTemplate"> <constructor-arg ref="psqlDataSource" /></bean>

12 org.springframework.jdbc.datasource.DriverManagerDataSource13 org.springframework.jdbc.core.simple.SimpleJdbcTemplate

26

Illustrazione 13: Diagramma UML delle classi del package Emvdb

<bean id="vulnerabilityRepository" class="net.emaze.pci.core.emvdb.DefaultVulnerabilityRepository"> <constructor-arg ref="jdbcTemplate" /></bean>

2.1.5 Integrazioni al package web

Il package web è quello che contiene tutti i controller dell'applicazione. I controller

di una web application contengono i metodi che vengono eseguiti quando viene

ricevuta una richiesta web. I metodi dei controller sono infatti annotati con

l'annotation @RequestMapping che contiene come parametro il path a cui il

metodo è associato.

Ad ogni richiesta ricevuta viene individuato il metodo corrispondente, che all'interno

di un blocco try-catch, a sua volta, richiama il metodo necessario della classe facade.

Se la richiesta viene elaborata senza errori viene restituito l'oggetto richiesto nel

formato fruibile dal client, altrimenti verrà restituito un messaggio di errore.

// questo metodo viene chiamato per le richieste al path //getVulnerabilityFromId

@RequestMapping("getVulnerabilityFromId.json")

// l'annotazione ResponseBody indica che il valore ritornato dal //metodo sarà come body della risposta http

@ResponseBody

public ExtjsJsonBuilder<?> readVulnerabilityfromId(

// il metodo richiede che ci sia un parametro id nella richiesta

// tale parametro verrà mappato in un oggetto Java di tipo String

@RequestParam("id") String id) {

Vulnerability vulnerability;

try {

vulnerability = vulnerabilityFacade.getVulnerabilityFromID(id);

} catch (Exception ex) {

logger.error("Errore nella lettura del file '%s'", ex, id);

return ExtjsJsonBuilder.failMessage(ex.getMessage());

}

return ExtjsJsonBuilder.success(vulnerability);

}

27

La classe utilizzata per mappare l'oggetto Java in un oggetto di tipo json è la classe

ExtjsJsonBuilder. Questa classe fa parte del package web, la classe era già presente

nell'applicativo ed era già stata usata per lo stesso scopo dagli altri controller

dell'applicativo per questo motivo si è preferito utilizzare questa classe piuttosto che

utilizzare framework esterni per svolgere il mapping dell'oggetto.

Per lo sviluppo dell'applicativo è stata necessaria l'implementazione di due controller,

uno per quanto riguarda le richieste di elaborazione dell'xml e l'altro per interrogare

il database delle vulnerabilità.

2.2 Interfaccia utente

L'interfaccia utente è state realizzata mediante il framework ExtJs, questo framework

permette lo sviluppo di codice javascript OOP14, implementando oggetti javascript

che prevedendo il concetto di classe e di ereditarietà.

Il Framework inoltre permette di utilizzare vari componenti tra cui quelli che

permettono l'iterazione tra client e server, la memorizzazione dei dati e quelli grafici.

L'oggetto che si occupa di memorizzare i dati è lo Store. Quest'ultimo necessita a sua

volta di un altro oggetto di tipo Proxy che si occupa della comunicazione tra client e

server, ricevendo i dati da visualizzare ed inviando i dati elaborati dall'utente.

Per quanto riguarda i componenti grafici quelli più utilizzati per la visualizzazione

dei dati sono:

• Grid, usato per visualizzare i dati in forma tabellare

• Form, usato per visualizzare i dettagli dei dati e permettere la modifica e

l'inserimento

Oltre ai componenti per la manipolazione dei dati è stato utilizzato il componente

14 Object Oriented Programming

28

Modal che permette di aprire delle finestre pop-up. All'apertura della finestra il resto

dell'interfaccia viene disabilitato e l'utente può interagire esclusivamente con il

contenuto di quella in primo piano.

ExtJS è anche responsabile della corretta visualizzazione cross-browser e del

mantenimento della compatibilità con browser datati. Importa inoltre dei fogli di stile

che possono essere eventualmente modificati dall'utente.

2.2.2 Scelta del report

La prima modifica ad essere stata implementata all'interno dell'applicativo esistente è

la scelta del report da aprire e, nell'illustrazione 13, sono evidenti i passaggi

necessari.

La finestra modale in primo piano contiene i documenti della scansione effettuata, il

tasto modifica presente al suo interno è l'unico cambiamento effettuato all'interfaccia

e permette l'apertura della pagina di visualizzazione report con come parametro

l'identificativo del report selezionato.

29

Illustrazione 13: Scelta del report da modificare

Nel finestra sono presenti due report ottenuti tramite l'utilizzo dell'applicativo

realizzato e si distinguono dagli altri per il nome del file che inizia con

reportUpdated.

2.2.2 Pagina di visualizzazione del report

Una volta selezionato il report da modificare l'utente viene reindirizzato alla pagina

di modifica e tutte le operazioni seguenti saranno svolte all'interno di questa pagina.

Per permettere la visualizzazione dei vari componenti grafici necessari ad eseguire

30

Illustrazione 14: Schermata iniziale di modifica del report

tutte le operazioni previste sui report sono stati utilizzati Panel15 che appaiono in base

a determinati eventi e finestre modali.

La pagina dei report è composta da 6 pannelli e due finestre modali che vengono

visualizzate per la ricerca delle vulnerabilità nel database emvdb ed in fase di

salvataggio delle modifiche.

I pannelli sono:

• il pannello degli host

• il pannello delle porte

• il pannello delle vulnerabilità

• il pannello dettaglio vulnerabilità

• il pannello di creazione nuova vulnerabilità

• il pannello dei cambiamenti

Come si può notare dall'illustrazione 14 la pagina è suddivisa in 4 zone: le 3 zone

nella parte superiore e la parte inferiore. Non tutti i pannelli sono visibili al momento

dell'apertura, i pannelli host, porte e cambiamenti sono sempre visibili mentre nella

porzione più a destra a seconda delle scelte dell'utente sarà visibile uno dei 3 pannelli

restanti.

Per rendere più agevole l'elaborazione del report tutti i pannelli possono essere

minimizzati tramite i pulsanti presenti nella parte superiore di ognuno oppure

possono essere ridimensionati a piacimento.

2.2.2.1 Il pannello degli host

Il pannello degli host è situato nella parte superiore più a sinistra e contiene al suo

15 Ext.tab.Panel

31

interno un solo componente di tipo grid che permette la visualizzazione di tutti gli

indirizzi ip scansionati. Sul pannello dell'host l'unica operazione che può essere

effettuata è la scelta dell'host selezionato. Non sono infatti previste operazioni di

aggiunta o cancellazione. Quando la pagina viene aperta nessun host è selezionato e

gli altri pannelli di conseguenza sono vuoti. Quando l'utente seleziona un indirizzo ip

verrano visualizzati negli altri panel tutti i dati riguardanti le porte e le vulnerabilità

in base all'host selezionato.

2.2.2.2 Il pannello delle porte

Il pannello delle porte è posizionato nella parte superiore alla sinistra del pannello

degli host e contiene 3 componenti, due grid ed un form. Le porte aperte relative a

l'host selezionato vengono visualizzate tramite i due componenti grid, uno per le

porte tcp mentre l'altro per le porte udp.

L'operazione di aggiunta di una porta può essere effettuata tramite il form

posizionato in alto mentre la rimozione tramite il pulsante rosso presente nelle due

grid a fianco di ogni singola porta.

2.2.2.3 Il pannello delle vulnerabilità

Il pannello delle vulnerabilità è composto da tre grid ed una toolbar nella parte

superiore. All'interno delle tre grid sono presenti i dati delle vulnerabilità, una per

quelle confermate, una per quelle potenziali ed una per gli avvisi.

Tramite il pannello delle vulnerabilità l'utente potrà:

• eliminare le vulnerabilità tramite il pulsate presente a fianco di ognuna

• spostare una vulnerabilità da potenziale e confermata e viceversa tramite il

drag&drop semplicemente trascinando una riga della tabella da una grid

all'altra

32

• aprire il pannello di dettaglio di una vulnerabilità cliccando sulla riga di

quest'ultima

Utilizzando i pulsanti presenti sulla toolbar l'utente potrà inoltre aprire il pannello per

l'inserimento di una nuova vulnerabilità oppure la finestra per la ricerca delle

vulnerabilità presenti nel database emvdb.

2.2.2.4 Pannello di dettaglio della vulnerabilità

Il pannello di dettaglio della vulnerabilità viene utilizzato per la visualizzazione e la

modifica di una vulnerabilità già presente nel report. Quando questo pannello viene

visualizzato all'utente e si posiziona al posto di quello delle vulnerabilità mentre

resteranno visibili gli altri.

Il pannello si compone di una toolbar, un form e due grid. Nella toolbar ritroviamo

come in quella delle vulnerabilità il pulsante cerca che permette di aprire la finestra

per la ricerca delle vulnerabilità. Al posto del pulsante per l'inserimento di una nuova

vulnerabilità sono invece presenti i pulsanti per salvare le modifiche oppure uscire

senza salvare. Una volta che l'utente ha premuto sui tasti di salvataggio o uscita il

pannello viene nascosto e torna in primo piano quello delle vulnerabilità.

Il form contiene i dettagli della vulnerabilità, più precisamente sono presenti i campi:

id, nome, severity, family, description e published date. Oltre al form è presente la

grid standards contente la catalogazione delle vulnerabilità in base agli standard.

Tutti questi campi sono in sola lettura in quanto vengono inseriti soltanto per dare

una panoramica della vulnerabilità all'operatore.

33

L'ultimo componente del pannello di dettaglio della vulnerabilità è la grid delle

istanze. Tramite questa grid l'utente potrà aggiungere, rimuovere o modificare istanze

alla vulnerabilità. Essendo obbligatoria la presenza di almeno un'istanza per ogni

vulnerabilità in fase di salvataggio verrà effettuato un controllo e in caso non ve ne

sia nessuna verrà mostrato una finestra modale di tipo alert all'utente richiedendo di

aggiungere un'istanza oppure uscire senza salvare.

2.2.2.5 Pannello nuova vulnerabilità

Il pannello per l'inserimento di una nuova vulnerabilità è molto simile a quello del

dettaglio visto in precedenza. Questo pannello si differenzia dal precedente perché è

in grado di ricevere degli input da parte dell'operatore.

Per poter inserire un report infatti l'utente dovrà:

34

Illustrazione 15: Pannello dettaglio di una vulnerabilità

1. selezionare mediante il radio button di che tipo di vulnerabilità si tratta

2. inserire il campo id

Quando il focus esce dal campo id gli altri campi vengono popolati in automatico in

base ai dati presenti nel database emvdb.

Il funzionamento del resto del pannello resta lo stesso di quello di modifica con i

campi in sola lettura e la tabella delle istanze presente nella parte inferiore.

2.2.2.6 Il pannello delle modifiche

Essendo stato sviluppato l'applicativo in modo che tutte le modifiche vengono

memorizzate lato client e trasmesse contemporaneamente al server per il salvataggio,

si è scelto di visualizzarle in una tabella in modo che l'utente le abbia sempre sotto

mano. Questa tabella è stata inserita in un pannello che è stato posizionato nella parte

inferiore della pagina. Come tutti gli altri pannelli anche questo può essere

minimizzato, riducendo al minimo lo spazio occupato nella pagina oppure

ridimensionato in modo da aver un'ottima visuale delle modifiche applicate.

Per ogni modifica sarà presente una riga nella tabella contente i dati: host, tipo di

operazione16, entità su cui è stata effettuata17 e descrizione.

16 Inserimento, cancellazione17 Porta, vulnerabilità oppure istanza

35

Illustrazione 16: Dettaglio del pannello nuova vulnerabilità

Come per le vulnerabilità e per le porte sarà presente in ogni riga il tasto di

cancellazione della modifica.

A completare il pannello è stata inserita una toolbar che consetirà di procedere al

salvataggio delle modifiche ed alla generazione del nuovo report aggiornato.

2.2.3 La finestra emvdb

La finestra emvdb è una finestra modale realizzata allo scopo di permettere la ricerca

di una vulnerabilità nel database interno. La finestra può essere visualizzata tramite il

pulsante cerca presente nelle toolbar di tutti pannelli delle vulnerabilità.

All'interno della finestra sono presenti una toolbar e 2 panel. Il panel principale è

quello di destra al suo interno troviamo una grid con elencate tutte le vulnerabilità in

base al filtro selezionato.

36

Illustrazione 17: Finestra emvdb

Nella toolbar sono invece presenti i componenti per l'inserimento di nuovi filtri.

Nell'illustrazione 17 è visibile una combobox, i suoi possibili valori corrispondono

ad ognuno dei filtri che possono essere applicati. Una volta selezionato un valore

appariranno altri campi di input di tipo testo o combobox per impostare il valore

desiderato per il filtro selezionato.

Il pannello di sinistra contiene al suo interno un campo di tipo radio da cui l'utente

potrà selezionare se i filtri devono essere collegati dall'operatore AND oppure OR ed

una grid contente tutti i filtri impostati. A fianco di ogni filtro è presente il pulsante

per rimuoverlo.

Una volta trovata la vulnerabilità ricercata l'utente potrà, effettuando un doppio click

sulla riga corrispondente aggiungerla al report. La finestra modale si chiuderà e sarà

visualizzato in primo piano il pannello di creazione di una nuova vulnerabilità con

inseriti i dati relativi a quella selezionata.

2.2.3 La finestra di salvataggio

Una volta completate le operazioni da effettuare, cliccando sul pulsante procedi nella

toolbar del pannello delle modifiche, comparirà la finestra di salvataggio. Questa

finestra contiene un riepilogo più ordinato, rispetto al pannello delle modifiche, delle

operazioni effettuate. Le modifiche sono infatti suddivise prima per indirizzo ip, poi

per entità ed infine per tipo di operazione.

La finestra modale si compone di

• una toolbar al cui interno è presente il pulsante di salvataggio ed una

combobox per la selezione dell'indirizzo ip18

• un panel al cui interno troviamo un radio button per la scelta del tipo di entità

di cui visualizzare il dettaglio tra porte, vulnerabilità confermate, potenziale

18 Tra quelli che hanno subito modifiche

37

ed avvisi di sicurezza

• quattro panel ognuno dei quali contiene al suo interno le modifiche effettuate

ad un tipo di entità

Soltanto un panel sarà visualizzato per volta. Se per un indirizzo ip non è stata

effettuata alcuna modifica ad una entità la casella del radio button corrispondente

sarà disattiva impedendo all'utente di selezionarla.

Nell'illustrazione 18 è visibile ad esempio la finestra di salvataggio relativa a delle

modifiche effettuare ad un report. In questo caso per quell'indirizzo ip erano state

rimosse delle vulnerabilità confermate mentre non erano state effettuate operazioni

su altre entità. Per questo motivo l'unica casella abilitata del radiobutton è quella

relativa alle vulnerabilità confermate.

Sempre dall'illustrazione 18 è visibile la composizione del singolo pannello delle

38

Illustrazione 18: Finestra di conferma prima del salvataggio

modifiche che è composto da 4 tabelle:

• la tabella delle vulnerabilità aggiunte

• la tabella delle vulnerabilità rimosse

• la tabella delle istanze aggiunte

• la tabella delle istanze rimosse

Quando l'operatore ha verificato la correttezza delle modifiche effettuate può

procedere al salvataggio definitivo del report tramite il pulsante salva. Il client

effettuerà la richiesta di salvataggio al server e resterà in attesa della risposta.

Il server risponderà con il risultato dell'operazione e gli output della generazione del

nuovo report. Gli output verranno visualizzati all'interno di un alert all'utente che in

caso di esito positivo successivamente verrà reindirizzato alla pagina di

visualizzazione del report aggiornato da cui sarà possibile scaricare il file zip

contenente tutti i documenti.

39

CAPITOLO 3

Conclusioni

3.1 Obiettivi

Tutti gli obiettivi previsti sono stati raggiunti permettendo all'operatore un'agile

modifica e rigenerazione del report pci tramite un intuitiva interfaccia web e

garantendo la corretta storicizzazione dei report che vengono automaticamente

memorizzati nel database secondo la normativa vigente.

I possibili sviluppi futuri dell'applicativo potrebbero essere:

• integrazione con il motore di Vulnerability Assessment proprietario di

Emaze19 per schedulare e programmare le analisi direttamente dalla

dashboard pcimanager (la dashbord si potrà interfacciare direttamente con lo

strumento per avviare le analisi di VA e recuperare in autonomia i risultati)

• modifica del comportamento della piattaforma PCI manager per aderire

ai nuovi requisiti della normativa PCI DSS 3.1

• aggiunta di una funzionalità che permetta di marcare una vulnerabilità anche

se ad alto impatto (critica per lo score CVSS) come PCI PASS inserendo una

motivazione

3.2 Lavoro svolto

Per lo sviluppo dell'applicativo sono state scritte complessivamente più 5000 righe

19 Iplegion

40

tra codice e configurazione di cui:

• 2600 righe di codice javascript per la realizzazione dell'interfaccia utente

• 2400 righe di codice Java, suddivise in 21 classi per l'implementazione lato

server

Al momento della stesura della tesi l'applicativo è in produzione sull'intranet di

Emaze.

3.3 Valutazioni personali

Sono molto soddisfatto del periodo di stage svolto presso Emaze che mi ha permesso

di acquisire conoscenze di framework comunemente utilizzati per applicazioni

enterprise ma soprattutto di confrontarmi con un ambiente lavorativo di ottimo

livello.

41

Capitolo 4

Bibliografia

Sito Standard PCI-DSS,

https://www.pcisecuritystandards.org/security_standards/

Head First Design Patterns , Eric Freeman & Elisabeth Freeman, O'Reilly

Media

Spring in action, Craig Walls, Manning Pubblications Co. terza edizione

Documentazione Spring Framework , http://www.spring.io/

Documentazione ExtJS,

http://www.sencha.com/products/extjs

42