Tesi laurea triennale

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Informatica
INTEGRAZIONE E SVILUPPO DI UNA
PIATTAFORMA PER LA GESTIONE
DELLE CONFORMITÀ ALLO
STANDARD PCI-DSS
Tesi di Laurea Triennale
Laureando:
Alessandro UMEK
Relatore:
prof. Alberto BARTOLI
Correlatore
Enrico Milanese
_____________________________________
ANNO ACCADEMICO 2014-2015

2. Indice
Introduzione..................................................................................................................2
Contesto...............................................................................................................2
Problema..............................................................................................................2
Soluzione.............................................................................................................3
Vincoli progettuali...............................................................................................3
Risultato...............................................................................................................4
Articolazione della tesi........................................................................................4
Analisi e progettazione.................................................................................................5
1.1 Situazione preesistente.......................................................................................5
1.1.1 Esempio pratico del procedimento in caso di falso negativo.....................5
1.1.2 Piattaforma PciWebApp.............................................................................6
1.1.2 Database analisi..........................................................................................6
1.1.3 Database delle vulnerabilità.......................................................................6
1.1.4 Script per la generazione del report............................................................7
1.2 Analisi del report di vulnerability assesment.....................................................7
1.3 Definizione delle entità....................................................................................15
Realizzazione..............................................................................................................16
2.1 Implementazione..............................................................................................16
2.1.1 Struttura delle classi.................................................................................16
2.1.2 Configurazione Spring Framework e dependency injection....................17
2.1.2.1 Configurazione xml-based....................................................................18
2.1.2.2 Configurazione annotation-based..........................................................18
2.1.3 Struttura dell'applicativo...........................................................................20
2.1.4 Integrazioni al package core.....................................................................20
2.1.4.1 Il package xml.......................................................................................21
2.1.4.2 XmlRepository......................................................................................23
2.1.4.3 PciGen...................................................................................................25
2.1.4.4 XmlFacade.............................................................................................26
2.1.4.5 Il package emvdb...................................................................................28
2.1.5 Integrazioni al package web.....................................................................30
2.2 Interfaccia utente..............................................................................................31
2.2.2 Scelta del report........................................................................................33
2.2.2 Pagina di visualizzazione del report.........................................................35
2.2.2.1 Il pannello degli host.............................................................................38
2.2.2.2 Il pannello delle porte............................................................................38
2.2.2.3 Il pannello delle vulnerabilità................................................................38
2.2.2.4 Pannello di dettaglio della vulnerabilità................................................39
2.2.2.5 Pannello nuova vulnerabilità.................................................................41
2.2.2.6 Il pannello delle modifiche....................................................................42
2.2.3 La finestra emvdb.....................................................................................43
2.2.3 La finestra di salvataggio..........................................................................44
Conclusioni.................................................................................................................47
3.1 Obiettivi............................................................................................................47
3.2 Lavoro svolto...................................................................................................47
3.3 Valutazioni personali........................................................................................48
Bibliografia.................................................................................................................49
1

3. 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

4. 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

5. • 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

6. 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

7. 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

8. 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

9. 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

10. 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 Protocol
3 User Datagram Protocol
9
Illustrazione 3: Struttura del elemento host
Illustrazione 4: Struttura dell'elemento openPorts

11. 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

12. 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

13. 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

14. 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à

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. • 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

22. 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

23. 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

24. 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

25. 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

26. //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

27. 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.DriverManagerDataSource
13 org.springframework.jdbc.core.simple.SimpleJdbcTemplate
26
Illustrazione 13: Diagramma UML delle classi del package Emvdb

28. <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

29. 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

30. 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

31. 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

32. 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

33. 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

34. • 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

35. 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à

36. 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, cancellazione
17 Porta, vulnerabilità oppure istanza
35
Illustrazione 16: Dettaglio del pannello nuova vulnerabilità

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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