SlideShare a Scribd company logo
1 of 188
Download to read offline
La sicurezza informatica
come ‘business as usual’:
utilità ed efficacia
della certificazione PCI DSS
Carlo Peroli
Facoltà di Scienze e tecnologie informatiche
Corso di Laurea in Sicurezza dei Sistemi e
delle Reti Informatiche
Università degli Studi di Milano
Relatore: Prof. Ernesto Damiani
Correlatore: Dott. Fulvio Frati
a Elisa e Joel
iii
Ringraziamenti
Grazie a mia moglie Elisa e a mio figlio Joel che hanno
partecipato sostenendomi (e sopportandomi) per tutto il percorso di
studi.
Grazie a mia madre, che mi ha sempre spronato con
entusiasmo a continuare e portare a termine questo progetto. Grazie
anche a mio padre, che ho sentito spiritualmente vicino nei momenti
difficili.
Grazie agli amici, che anche da lontano, mi hanno aiutato a
superare gli ostacoli, con un ringraziamento speciale a Nicola.
Un doveroso e sentito ringraziamento anche al professor
Ernesto Damiani, che mi ha aiutato ad arricchire di contenuti questa
tesi, al dott. Fulvio Frati, che mi ha affiancato nel percorso di
revisione della stessa con preziosi consigli e concreta disponibilità, ai
professori, agli assistenti, ai tutor del dipartimento di Crema per
avermi permesso di conseguire questa laurea e un particolare
ringraziamento a Sabrina Papini per la sua grande disponibilità.
i
Abstract
Obiettivo della tesi è fornire una serie di guideline (propositive e
non comparative) per il processo di certificazione PCI DSS (Payment
Card Industry Data Security Standard) di un’organizzazione e dare
una descrizione approfondita dello stesso.
La scelta dello standard è dettata dal fatto che, pur essendo
focalizzato sulle transazioni economiche effettuate con carte di
pagamento, è fortemente orientato alla sicurezza del DATO in generale
e può essere quindi esteso con facilità ad altri ambiti; inoltre si
configura per le aziende come un indispensabile strumento per poter
operare nel settore, dal momento che da esso deriva la possibilità di
usufruire dei servizi offerti dai circuiti internazionali (i payment brand
come VISA e Mastercard) e dai service provider necessari allo
svolgimento di tutte le attività di business; infine, la sua corretta
applicazione permette di coprire tutti gli ambiti aziendali avendo i
requisiti come oggetto TECNOLOGIE, PROCESSI e PERSONE.
Le guideline per la corretta applicazione dello standard si
basano sull’analisi, effettuata sul campo, delle procedure da seguire
durante l’assessment, focalizzando aspetti tecnici, procedurali, di
gestione delle risorse umane e di compliance contrapposti alle esigenze
di business delle aziende che operano in un mercato altamente
concorrenziale.
La parte finale è dedicata alle metodologie da adottare per
utilizzare la compliance PCI DSS come un framework completo per la
gestione della sicurezza informatica in tutti i settori dell’information
technology ed in tutti i processi dell’organizzazione, promuovendo una
gestione della IT security che non si focalizzi solo su alcune tecnologie o
su particolari momenti della vita aziendale, ma che diventi “business
as usual”.
ii
Indice
1. Capitolo 1 ............................................................................................................... 1
1.1 Lo standard PCI DSS.......................................................................................... 1
1.1.1 PCI Security Standard Council................................................................ 1
1.1.2 I payment brands ......................................................................................... 2
1.1.3 Processi di gestione delle transazioni con carte di
pagamento.................................................................................................................... 4
1.2 Applicabilità dello standard PCI DSS............................................................ 6
1.2.1 Livelli di certificazione ................................................................................ 6
1.2.1.1 Merchant................................................................................................. 7
1.2.1.2 Service Provider .................................................................................. 23
1.2.2 Relazioni con altri standard PCI ........................................................... 33
1.3 Ruoli....................................................................................................................... 34
1.3.1 PCI SSC (Security Standards Council)................................................ 34
1.3.2 Payment Brands (AmEx, Discover, JCB, MC, VISA)....................... 35
1.3.3 Qualified Security Assessor .................................................................... 35
1.3.4 Internal Security Assessor (ISA)............................................................ 36
1.3.5 Merchant e Service Provider................................................................... 37
1.3.6 Approved Scanning Vendor (ASV)......................................................... 37
1.4 I singoli requisiti dello standard PCI DSS.................................................. 37
1.4.1 Descrizione dei requisiti e delle procedure di test........................... 38
2. Capitolo 2 ............................................................................................................. 40
2.1 Linee guida sulle fasi dell'assessment PCI DSS....................................... 40
2.1.1 Gap Analysis................................................................................................ 41
2.1.2 Scoping.......................................................................................................... 42
2.1.3 Network Segmentation ............................................................................. 44
2.1.4 Prioritized Approach.................................................................................. 46
2.1.5 Remediations............................................................................................... 47
2.1.6 On-site Assessment................................................................................... 48
iii
2.1.7 Compensating Controls............................................................................ 50
2.1.8 Report on Compliance .............................................................................. 52
2.1.9 Attestation of Compliance ....................................................................... 52
2.2 Linee guida per la determinazione dello scope......................................... 53
2.2.1 Passi operativi ............................................................................................. 53
2.2.2 Inventario delle risorse coinvolte .......................................................... 60
2.3 Linee guida per la determinazione dei sampling ..................................... 61
2.4 Linee guida per la ricerca di dati dei titolari di carte di pagamento . 62
2.4.1 Use Case per il Data Discovery.............................................................. 64
2.5 Linee guida per la segmentazione della rete ............................................. 69
2.5.1 Use Case per la segmentazione della rete.......................................... 69
2.6 Analisi dei processi e delle persone coinvolte........................................... 74
2.7 Errori comuni nella definizione dello scope PCI DSS............................. 76
2.8 Linee guida sui controlli previsti per ciascun requisito ........................ 77
2.8.1 Tecnologie, procedure, risorse umane e compliance...................... 77
2.8.2 Il software ..................................................................................................... 78
2.8.3 Aspetti di business dell'azienda ............................................................ 80
3. Capitolo 3 ............................................................................................................. 83
3.1 Utilità ed efficacia della certificazione PCI DSS ....................................... 83
3.1.1 Come rendere "possibile" una certificazione ..................................... 84
3.1.2 Linee guida per l’estensione della sicurezza
informatica oltre il perimetro di certificazione PCI DSS.............................. 86
3.1.3 Miglioramento continuo della sicurezza informatica...................... 90
3.1.4 Il conflitto di interessi............................................................................... 91
Conclusioni ........................................................................................................................ 98
4. Bibliografia e citazioni ...................................................................................... 99
i. Appendice A: i requisiti PCI DSS 3.0 e le procedure di test............... 102
ii. Appendice B: GANTT di un progetto di assessment PCI DSS ........... 164
iii. Appendice C: Strumento operativo per la raccolta delle evidenze ... 165
iv
Introduzione
Gli standard internazionali e le certificazioni di sicurezza
informatica sono spesso viste nel mondo dell’information technology
come un complesso ed oneroso impegno a cui dover sottostare per
poter continuare a svolgere il proprio business.
La realtà aziendale testimonia che la compliance e la sicurezza
informatica sono due concetti non completamente sovrapponibili,
soprattutto per il fatto che la compliance ha bisogno di una data della
sua fotografia, mentre la sicurezza informatica è una pratica da
adottare giorno per giorno (business as usual) in ogni processo che
coinvolge il settore IT.
La complessità dello standard PCI DSS impone un approccio
graduale dei requisiti cercando di ottemperare alle loro richieste in un
primo tempo in modo ciclico e, una volta raggiunti gli obiettivi di
conformità, in modo lineare, cercando di evitare successive
reiterazioni su argomenti già trattati in precedenza.
Per le aziende che operano nel settore dei pagamenti elettronici
effettuati con carte di credito (ma anche di debito, purché si
avvalgano dei servizi offerti da circuiti internazionali quali VISA e
Mastercard), la certificazione PCI DSS è uno strumento
indispensabile per poter usufruire dei servizi offerti da payment
brands e service provider già certificati.
Obiettivo di questa tesi è proporre delle linee guida che
consentano una gestione il più possibile automatizzata del processo
di certificazione PCI DSS, sia che si tratti della valutazione di un
merchant o di un service provider, descrivere come lo standard possa
essere utilizzato per la gestione della sicurezza informatica di dati,
processi e persone estendibile a tutti gli ambiti dell’organizzazione ed
in continua e costante applicazione (business as usual) e, infine,
analizzare le differenze che esistono tra compliance e IT security,
evidenziando come una possa essere utile all’altra per poter innalzare
concretamente e progressivamente il livello di sicurezza informatica di
un’organizzazione che opera sul mercato.
Il Capitolo 1 è focalizzato proprio sull’analisi dello standard in
tutti i suoi aspetti (ambito di applicazione, attori e ruoli, definizione
dello scope, analisi dei singoli requisiti).
v
Proprio per questo motivo è necessario utilizzare delle linee
guida per condurre in modo efficace ed efficiente un assessment PCI
DSS, che deve prevedere una fase finale di controllo delle conformità
di tutti i requisiti che non superi l’intervallo di tempo di tre mesi. Tale
intervallo è valutato come il massimo periodo di tempo in cui,
nell’ambito dell’infrastruttura tecnologica di un’azienda, siano assenti
modifiche ed aggiornamenti significativi della stessa che possano
invalidare le valutazioni già fatte da parte di un QSA (Qualified
Security Assessor).
Il Capitolo 2 descrive le linee guida proponendo un framework
da utilizzare per un assessment PCI DSS e mettendo in relazione
aspetti a volte tra loro contrastanti (compliance, IT security,
business).
Il Capitolo 3 tratta infine della reale utilità ed efficacia della
certificazione PCI DSS, considerando le informazioni su cui si
concentra (transazioni economiche con l’utilizzo delle carte di
pagamento) come sostituibili con altri tipi di informazioni “sensibili”
dal punto di vista della sicurezza informatica; l’intento è quello di
estendere il framework alla gestione della sicurezza delle informazioni
di tutta l’azienda, non solamente per ottenere una certificazione di
compliance, ma per innalzare concretamente il livello di sicurezza
delle informazioni durante tutti i processi per la loro gestione. Questo
è reso possibile dal fatto che lo standard PCI DSS è orientato al DATO
attorno al quale ruotano tutti i requisiti per la messa in sicurezza
dello stesso; sostituire quindi i dati dei titolari di carte di pagamento
con altri tipi di dati che per un’organizzazione sono ritenuti “sensibili”
risulta particolarmente facile.
Al fine di rendere la trattazione più scorrevole, è necessario
prevedere un breve glossario che disambigui le possibili
interpretazioni (PCI Security Standards Council, LLC, 2006-2015):
 Carta di pagamento: per gli scopi dello standard PCI DSS, è
ogni carta o strumento che espone il logo dei membri fondatori
del PCI Security Standard Council (American Express, Discover
Financial Services, JCB International, MasterCard Worldwide, e
Visa, Inc.).
 PAN (Primary Account Number): numero unico di ciascuna
carta di pagamento che identifica l’issuer e un particolare conto
del titolare della carta stessa.
vi
 CHD (Cardholder Data): nella forma minima i cardholder data
consistono nel singolo PAN (Primary Account Number), ma
possono anche apparire nella forma di PAN unito ad uno o più
dei seguenti dati: nome del titolare della carta di pagamento,
data di scadenza e codice di servizio utilizzato per la
transazione. Altri dati che sono parte dei CHD sono i SAD
(Sensitive Authentication Data).
 SAD (Sensitive Authentication Data): informazioni legate alla
sicurezza che possono includere informazioni quali Card
Validation Code/Values, dati contenuti nelle tracce magnetiche
(o quelli equivalenti presenti nei chip), PIN (Personal
Identification Number) e PIN Block utilizzati per autenticare i
Cardholder e/o autorizzare le transizioni di pagamento.
 PIN (Personal Identification Number): numero segreto
conosciuto solo al possessore dello stesso ed al sistema che lo
deve autenticare. Tipicamente sono utilizzati per gli ATM
(Automated Teller Machine da noi conosciuti come “Bancomat”).
Un’altro tipo di PIN è quello utilizzato dalle carte di pagamento
dove lo stesso sostituisce la firma del titolare.
 PIN Block: blocco di dati utilizzato per incapsulare il PIN
durante le transazioni ed è composto dal PIN, dalla sua
lunghezza e può contenere sottoinsiemi del PAN.
Capitolo 1
1
1. Capitolo 1
Lo standard internazionale PCI DSS definisce un framework
volto a favorire l’adozione di misure di sicurezza tecnologiche e
procedurali per proteggere i dati di titolari di carte di pagamento
(CHD) e/o sensitive authentication data (SAD) durante tutti i processi
che li coinvolgono (autorizzazioni di pagamento, operazioni di
settlement, gestione delle frodi, ecc.).
Lo standard è stato sviluppato dal PCI Security Standard
Council con l’obiettivo di integrare in un unico programma i singoli
standard che ciascun payment brand fondatore (VISA, MasterCard,
JCB, Discover ed American Express) già prevede per la gestione
sicura dei dati.
Esso rappresenta una linea di base, definita nei suoi requisiti,
per la certificazione di conformità PCI Data Security Standard di
entità che svolgono molteplici ruoli nel processo dei pagamenti
elettronici con carte e non intende sostituire leggi e regolamenti che
vengono adottate da ogni paese per la sicurezza dei dati personali
come, per l’Italia, il Decreto Legislativo sulla privacy 196/2003.
1.1 Lo standard PCI DSS
1.1.1 PCI Security Standard Council
Il PCI SSC (Payment Card Industry – Security Standard
Council) è un organismo indipendente dai payment brands che ha il
compito di definire, diffondere e gestire gli standard PCI in tutto il
mondo, non solo il PCI DSS, ma anche gli standard PA-DSS (Payment
Application Data Security Standard) per le applicazioni, P2PE (Point-to-
Point Encryption) per le trasmissioni cifrate point-to-point, PTS (PIN
Transaction Security) per i device utilizzati nei processi di pagamento
elettronico con carte ecc.
È possibile sintetizzare i compiti del PCI SSC nei seguenti
punti:
 mantenimento di una lista di FAQ che possono essere
consultate da tutti gli operatori per la corretta interpretazione
degli standard definiti;
Capitolo 1
2
 mantenimento della lista degli operatori qualificati in tutto il
mondo che hanno la facoltà di condurre e certificare gli
assessment previsti dagli standard PCI;
 mantenimento di:
o una lista di applicazioni
o una lista di device
o una lista di soluzioni
utilizzate per i pagamenti elettronici che hanno superato con
successo gli assessment definiti dagli standard PCI;
 formazione periodica degli operatori (gli assessors) con la
produzione di materiale didattico sia cartaceo che in modalità
e-learning ;
 diffusione degli standard in tutto il mondo, con l’intento di
stimolare la sensibilità sulla sicurezza necessaria per la
gestione delle transazioni economiche effettuate con carte di
pagamento, sia in presenza di terminali fisici di lettura delle
carte (card-present) che per gli acquisti su portali di e-
commerce (card-not-present);
 organizzazione e gestione dei Community Meetings annuali per
discutere degli standard e acquisire feedback per il loro
continuo miglioramento.
1.1.2 I payment brands
Ognuno dei cinque payment brands mantiene il suo
programma di gestione delle conformità rispetto alla sicurezza
informatica in base alle proprie politiche di gestione dei rischi. In
particolare:
 American Express ha sviluppato il proprio programma
denominato Data Security Operating Policy;
 Discover allo stesso modo ha sviluppato il proprio programma
denominato Discover Information Security Compliance;
 JCB International ha sviluppato il programma Data Security
Program per la sicurezza nella gestione dei dati;
 MasterCard ha sviluppato il proprio programma di gestione
della sicurezza orientato sia ai dati che alle infrastrutture
tecnologiche denominato Site Data Protection;
Capitolo 1
3
VISA ha sviluppato due differenti programmi di security
compliance, uno per l’Europa e uno per il resto del mondo. In
particolare:
 Visa Europe ha sviluppato il programma Account Information
Security Program che promuove nell’area europea per la
gestione della sicurezza e della compliance;
 Visa Inc ha invece sviluppato il programma Cardholder
Information Security Program che promuove la gestione della
compliance in tema di sicurezza informatica in tutto il resto del
mondo;
Tali programmi di gestione di security compliance sono il
riferimento ultimo per la determinazione dei livelli di validazione per
la certificazione PCI DSS sia per i merchant che per i service provider.
A ciascun livello di validazione (che può essere determinato in modo
differente dai singoli programmi dei payment brands) competono dei
precisi compiti da assolvere per poter ottenere la compliance PCI
DSS.
I livelli di validazione sono determinati dagli acquirer (o da un
payment brand quando assume anche il ruolo di acquirer) in base ai
volumi di transazioni effettuate, basati su un’aggregazione per
differente payment brand anche a fronte di differenti acquirer.
Tuttavia l’applicazione delle politiche di sicurezza IT dei payment
brands può variare in accordo con ciascun brand e/o acquirer i quali
devono valutare il corretto livello di validazione, considerando anche
che un merchant o un service provider possono avere diverse linee di
business o diversi acquirer.
I payment brands definiscono anche le tariffe e le multe che
devono essere pagate dalle entità che partecipano alla gestione dei
processi di transazioni economiche con carte di pagamento; tali multe
vengono di solito comminate agli acquirer, che rappresentano l’attore
responsabile della compliance PCI DSS di ciascun merchant che
utilizza i propri servizi di acquiring, oltre che di ciascun service
provider che viene utilizzato per gestire l’intero ciclo delle transazioni
con carte di pagamento.
Infine la responsabilità dei payment brands riguarda le indagini
forensi che si rendono necessarie dopo il verificarsi di incidenti
informatici (normalmente denominati Data Breach Incidents) che
hanno compromesso la sicurezza di CHD o di SAD.
Capitolo 1
4
1.1.3 Processi di gestione delle transazioni con carte di
pagamento
Tutte le transazioni economiche con carte di pagamento sono
gestite (con particolari eccezioni di scarso rilievo) utilizzando gli
stessi processi. Prima di descriverli è necessario fare alcune
precisazioni sulla terminologia utilizzata (PCI Security Standards
Council, LLC, 2006-2015):
 cardholder: è il titolare della carta di pagamento utilizzata per
le transazioni o comunque una persona fisica autorizzata al
suo utilizzo;
 issuer: entità che emette la carta di pagamento o che ne
supporta l’emissione attraverso i propri issuing services che
può includere (in modo non esaustivo) banche e issuing
processors;
 payment brand: i cosiddetti circuiti internazionali
rappresentati da VISA, Mastercard, JCB, Discover ed American
Express;
 acquirer: entità che stabilisce e mantiene relazioni con
merchants per l’accettazione di transazioni con carte di
pagamento;
 merchant: per gli scopi dello standard PCI DSS, un merchant è
definito come un’entità che accetta carte di pagamento che
riportano il logo di uno dei cinque membri costituenti il PCI
Standard Security Council (American Express, Discover, JCB,
MasterCard o VISA) come pagamento di beni e/o servizi. È da
notare che un merchant può essere anche un service provider
se il servizio richiesto prevede la memorizzazione, l’elaborazione
o la trasmissione di cardholder data per conto di altri mercants
o service providers. Ad esempio un internet service provider è un
merchant che accetta carte di pagamento per la fatturazione
mensile, ma è anche un service provider se effettua hosting di
merchants o altri clienti.
Il processo di autorizzazione per una transazione economica
con carte di pagamento prevede che al momento dell’acquisto il
merchant riceva un codice di autorizzazione che permette la
Capitolo 1
5
conclusione dell’acquisto stesso. I passi dell’autorizzazione sono
descritti nella Fig. 1:
$
$
$
Cardholder Merchant
$
IssuerPayment BrandAcquirer
2 3 4 5
678
Il merchant
spedisce il
pagamento
all’acquirer
L’acquirer richiede al network
dei payment brands di
determinare l’issuer della
carta di pagamento
Il payment brand
determina l’issuer e
richiede l’approvazione
per l’acquisto
L’issuer approva
l’acquisto
Il payment brand invia
l’approvazione
dell’acquisto all’aquirer
L’acquirer invia
l’approvazione
dell’acquisto al merchant
Il merchant stampa
la ricevuta
Il cardholder
utilizza la carta di
pagamento da un
merchant
1
Il cardholder
completa l’acquisto
e ritira la ricevuta
9
Fig. 1: processo di autorizzazione (Fonte: PCI Security Standard Council)
Nel processo di clearing l’acquirer e l’issuer si scambiano
informazioni contabili sull’acquisto per completare la transazione. I
passi previsti dal processo sono descritti nella Fig. 2:
$
IssuerPayment BrandAcquirer
1 2 3
45
L’acquirer spedisce le
informazioni riguardanti
l’acquisto ai payment brands
Il payment brand invia
le informazioni di
acquisto all’issuer
L’issuer prepara i dati per
l’addebito dell’importo al titolare
della carta di pagamento
Il payment brand invia
notifica di clearing
all’acquirer
L’acquirer riceve la
notifica
Fig. 2: Processo di Clearing (Fonte: PCI Security Standard Council)
Il termine del processo di pagamento è rappresentato dal
processo di settlement. La banca del merchant (rappresentata
dall’acquirer) paga il merchant per l’acquisto del cardholder e la banca
Capitolo 1
6
del cardholder (rappresentata dall’issuer) addebita l’importo al
titolare. Nella Fig. 3 sono descritti i passi del processo:$
$
$
Cardholder
Merchant
$
Issuer Payment Brand Acquirer
432
Il merchant riceve il
pagamento
L’acquirer paga il
merchant per la
vendita effettuata
L’issuer tramite Il
payment brand
spedisce il pagamento
all’acquirer
L’issuer determina
l’acquirer tramite i
payment brands
L’issuer addebita
l’importo dell’acquisto
al cardholder
5
1
Fig. 3: Processo di settlement (Fonte: PCI Security Standards Council)
1.2 Applicabilità dello standard PCI DSS
Lo standard PCI DSS si applica a tutte le entità coinvolte nei
processi di transazione economica con carte di pagamento
(merchants, payment processors, payment gateways, acquirers,
issuers, service providers e ogni altra entità che memorizza, processa
o trasmette dati di titolari di carte di pagamento).
Le modalita con cui si applica lo standard ad un’entità
(requisiti per i quali garantire la conformità e tipi di reportistica da
presentare) sono determinate in base al numero di transazioni annue
effettuate utilizzando carte di pagamento: tali numeri individuano il
corrispondente livello di certificazione.
Ogni payment brand ha il suo proprio set di requisiti di
validazione e di reportistica richiesta e a ciascuna entità che intende
certificarsi è richiesto il livello di validazione che prevede il maggior
numero di requisiti da rispettare, anche se per un differente payment
brand basterebbe un livello inferiore.
1.2.1 Livelli di certificazione
I livelli di certificazione sono stabiliti in base a differenti soglie
nel numero di transazioni effettuate con carte di pagamento in un
anno per merchant e per service provider, perché mentre i primi si
Capitolo 1
7
limitano generalmente ad accettare e trasmettere CHD, gli ultimi ne
effettuano anche elaborazione e, in alcuni casi, memorizzazione.
Le informazioni in queste sezioni sono tratte dai siti web dei
payment brand (American Express Company, 2015), (JCB Co., Ltd.),
(MasterCard, 2015), (Visa Europe, 2015), (DFS Services LLC, 2015).
1.2.1.1 Merchant
Per i merchant sono stabiliti 4 livelli di certificazione e ciascun
payment brand prevede differenti soglie nel numero delle transazioni
con carte di pagamento gestite in un anno.
Nelle successive tabelle sono rappresentati i requisiti di
validazione e di reportistica previsti per ciascun livello di
certificazione in cui si colloca un merchant:
 Livelli di certificazione per i Merchant
Livelli di certificazione per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
1  Merchant che
gestiscono più di 2,5
milioni di transazioni
all’anno con carte di
pagamento
American Express
 Qualunque
Merchant
determinato come
Level 1 da parte di
American Express
 Merchant che
gestiscono più di 6
milioni di transazioni
all’anno con carte di
pagamento Discover
 Qualunque
Merchant
determinato come
Level 1 da parte di
Discover
 Qualunque
Merchant che un
altro Payement
Brand ha
determinato essere
di Level 1
 Merchant che
gestiscono più di 1
milione di
transazioni all’anno
con carte di
pagamento JCB
 Qualunque
Merchant che abbia
subito una
compromissione
Capitolo 1
8
Livelli di certificazione per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
2  Merchant che
gestiscono da 50000
a 2,5 milioni di
transazioni all’anno
con carte di
pagamento
American Express
 Merchant che
gestiscono da 1 a 6
milioni di transazioni
all’anno con carte di
pagamento Discover
 Qualunque
Merchant
determinato come
Level 2 da parte di
Discover
 Merchant che
gestiscono meno di
1 milione di
transazioni all’anno
con carte di
pagamento JCB
3  Merchant che
gestiscono meno di
50000 transazioni
all’anno con carte di
pagamento
American Express
 Merchant che
gestiscono da 20000
a 1 milione di
transazioni all’anno
con carte di
pagamento Discover
 Qualunque
Merchant
determinato come
Level 3 da parte di
Discover
 N/A
4  N/A  Tutti i rimanenti
Merchant
 N/A
Capitolo 1
9
Livelli di certificazione per i Merchant (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
1  Merchant che
gestiscono più di 6
milioni di
transazioni all’anno
con carte di
pagamento
MasterCard e
Maestro
 Qualunque
Merchant che abbia
subito una
compromissione
nell’ultimo anno
 Qualunque
Merchant
determinato come
Level 1 da parte di
MasterCard
 Qualunque
Merchant
determinato come
Level 1 secondo i
criteri Visa
 Merchant che
gestiscono più di 6
milioni di
transazioni all’anno
con carte di
pagamento Visa
 Qualunque
Merchant che opera
a livello mondiale e
determinato come
Level 1 in una
qualunque regione
Visa
 Merchant che
gestiscono più di 6
milioni di
transazioni all’anno
con carte di
pagamento Visa
 Qualunque
Merchant che ha
subito una
compromissione
nell’ultimo anno a
discrezione della
regione
2  Merchant che
gestiscono da 1 a 6
milioni di
transazioni all’anno
con carte di
pagamento
MasterCard e
Maestro
 Qualunque
Merchant
determinato come
Level 2 secondo i
criteri Visa
 Merchant che
gestiscono da 1 a 6
milioni di
transazioni all’anno
con carte di
pagamento Visa
 Merchant che
gestiscono da 1 a 6
milioni di
transazioni all’anno
con carte di
pagamento Visa
Capitolo 1
10
Livelli di certificazione per i Merchant (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
3  Merchant che
gestiscono da 20000
e 1 milione di
transazioni all’anno
di tipo e-commerce
con carte di
pagamento
MasterCard e
Maestro
 Qualunque
Merchant
determinato come
Level 3 secondo i
criteri Visa
 Merchant che
gestiscono da 20000
a 1 milione di
transazioni all’anno
di tipo e-commerce
con carte di
pagamento Visa
 Merchant che
gestiscono da 20000
a 1 milione di
transazioni all’anno
di tipo e-commerce
con carte di
pagamento Visa
4  Tutti i rimanenti
Merchant
 Merchant che
gestiscono meno di
20000 transazioni
all’anno di tipo e-
commerce
 Tutti gli altri
Merchant che
gestiscono fino a 1
milione di
transazioni all’anno
con carte di
pagamento Visa
 Merchant che
gestiscono meno di
20000 transazioni
all’anno di tipo e-
commerce
 Tutti gli altri
Merchant che
gestiscono fino a 1
milione di
transazioni all’anno
con carte di
pagamento Visa
Capitolo 1
11
 Requisiti di validazione per i Merchant
Requisiti di validazione per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
1  Assessment on-site
annuale effettuato
da un QSA oppure
dal merchant stesso
se certificato dal
chief executive
officer
(amministratore
delegato), chief
fianancial officer
(direttore
finanziario), chief
information security
officer (direttore IT
security) o dal
principal (direttore
responsabile)
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Assessment on-site
annuale effettuato
da un QSA oppure
da un auditor
interno al merchant
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Assessment on-site
annuale effettuato
da un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
Capitolo 1
12
Requisiti di validazione per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
2  Self Assessment
Questionnaire
annuale effettuato
dal merchant stesso
e certificato dal
chief executive
officer
(amministratore
delegato), chief
fianancial officer
(direttore
finanziario), chief
information security
officer (direttore IT
security) o dal
principal (direttore
responsabile)
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
3  Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 N/A
Capitolo 1
13
Requisiti di validazione per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
4  N/A Per merchant Discover:
 Self Assessment
Questionnaire
annuale
Per merchant acquisiti:
 l’acquirer determina
i requisiti di
validazione
sono raccomandati
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 N/A
Capitolo 1
14
Requisiti di validazione per i Merchant (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
1  Assessment on-site
annuale effettuato
da un QSA o da un
auditor interno con
qualifica di Internal
Security Auditor
rilasciata dal PCI SSC
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Assessment on-site
annuale effettuato
da un QSA o da un
auditor interno (o
da altro staff
indipendente) con
qualifica di Internal
Security Auditor
rilasciata dal PCI SSC
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
 Report On
Compliance a
seguito di un
assessment on-site
annuale effettuato
da un QSA o da un
auditor interno (o
da altro staff
indipendente) con
qualifica di Internal
Security Auditor
rilasciata dal PCI SSC
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliance form
2  Assessment on-site
annuale effettuato
da un QSA o da un
auditor interno con
qualifica di Internal
Security Auditor
rilasciata dal PCI SSC
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
Capitolo 1
15
Requisiti di validazione per i Merchant (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
3  Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
4 La certificazione PCI
DSS è richiesta a
discrezione
dell’acquirer. Quando
richiesta prevede:
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Self Assessment
Questionnaire
annuale solo
raccomandato
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV) se
applicabile
 l’acquirer deve
determinare quali
siano i requisiti di
validazione
Per chi effettua solo e-
commerce:
 sufficiente l’utilizzo
di Service Provider
che siano compliant
PCI DSS oppure
 Self Assessment
Questionnaire
annuale
Per gli altri:
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
Capitolo 1
16
 Requisiti di reportistica per i Merchant
Requisiti di reportistica per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
1 Se compliant
 Attestation of
Compliance
dall’assessment on-
site annuale
 Attestaion of Scan
Compliance o
Executive summary
degli External
Vulnerability Scan
trimestrali
Se non compliant
 Attestation of
Compliance che
includa la parte di
piano d’azione per
le remediation
 Data di
implementazione
delle remediation
(non oltre i 12 mesi
seguenti)
Merchant Discover
 Attestation of
Compliance
dall’assessment on-
site annuale
 Attestation of
Compliance che (Se
non completamente
compliant) includa
la parte di piano
d’azione per le
remediation
Mechant acquisiti
 Consultare
l’acquirer che deve
inviare il modulo
“Discover Acquirer
Portfolio
Compliance Status
Submission” a
Discover due volte
all’anno
 Nessun requisito per
la reportistica
richiesto
Capitolo 1
17
Requisiti di reportistica per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
2 Se compliant
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestaion of Scan
Compliance o
Executive summary
degli External
Vulnerability Scan
trimestrali
Se non compliant
 Attestation of
Compliance che
includa la parte di
piano d’azione per
le remediation
 Data di
implementazione
delle remediation
(non oltre i 12 mesi
seguenti)
Merchant Discover
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestation of
Compliance che (se
non completamente
compliant) includa
la parte di piano
d’azione per le
remediation
Mechant acquisiti
 Consultare
l’acquirer che deve
inviare il modulo
“Discover Acquirer
Portfolio
Compliance Status
Submission” a
Discover due volte
all’anno
 Nessun requisito per
la reportistica
richiesto
Capitolo 1
18
Requisiti di reportistica per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
3  Nessun requisito per
la reportistica
richiesto
Merchant Discover
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestation of
Compliance che (se
non completamente
compliant) includa
la parte di piano
d’azione per le
remediation
Mechant acquisiti
 Consultare
l’acquirer che deve
inviare il modulo
“Discover Acquirer
Portfolio
Compliance Status
Submission” a
Discover due volte
all’anno
 N/A
Capitolo 1
19
Requisiti di reportistica per i Merchant (American Express, Discover, JCB)
Livello American Express Discover JCB
4  N/A Merchant Discover
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestation of
Compliance che (se
non completamente
compliant) includa
la parte di piano
d’azione per le
remediation
Mechant acquisiti
 Consultare
l’acquirer che deve
inviare il modulo
“Discover Acquirer
Portfolio
Compliance Status
Submission”
(oppure il piano
d’azione del
merchant) a
Discover due volte
all’anno
 N/A
Capitolo 1
20
Requisiti di reportistica per i Merchant (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
1  Gli acquirer
comunicano
trimestralmente a
MasterCard lo stato
dei propri merchant
 Il MasterCard Global
Compliance
Program prescrive
che ogni merchant
non conforme
comunichi ai propri
acquirer lo stato di
compliance e lo
stato di
avanzamento lavori
per il
completamento
delle remediation
utilizzando il tool
fornito dal PCI SSC
denominato
“Prioritized
Approach”
 L’acquirer per ogni
merchant comunica
due volte all’anno lo
stato di compliance
o non compliance
 Attestation of
Compliance
dall’assessment on-
site annuale
 Su richiesta gli
acquirer devono
fornire anche una
copia del Report on
Compliance dei
merchant
 L’acquirer per ogni
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
 Attestation of
Compliance
dall’assessment on-
site annual dei
merchant
 Su richiesta gli
acquirer devono
fornire anche una
copia del Report on
Compliance dei
merchant incluse le
Attestation of Scan
Compliance
trimestrali
Capitolo 1
21
Requisiti di reportistica per i Merchant (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
2  Gli acquirer
comunicano
trimestralmente a
MasterCard lo stato
dei propri merchant
 Il MasterCard Global
Compliance
Program prescrive
che ogni merchant
non conforme
comunichi ai propri
acquirer lo stato di
compliance e lo
stato di
avanzamento lavori
per il
completamento
delle remediation
utilizzando il tool
fornito dal PCI SSC
denominato
“Prioritized
Approach”
 L’acquirer per ogni
merchant comunica
due volte all’anno lo
stato di compliance
o non compliance
 Attestation of
Compliance
dall’assessment on-
site annuale
 Su richiesta gli
acquirer devono
fornire anche una
copia del Self
Assessment
Questionnaire dei
merchant
 L’acquirer per ogni
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
 Su richiesta gli
acquirer devono
fornire anche Self
Assessment
Questionnaire e
Attestation of
Compliance dei
merchant
Capitolo 1
22
Requisiti di reportistica per i Merchant (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
3  Gli acquirer
comunicano
trimestralmente a
MasterCard lo stato
dei propri merchant
 Il MasterCard Global
Compliance
Program prescrive
che ogni merchant
non conforme
comunichi ai propri
acquirer lo stato di
compliance e lo
stato di
avanzamento lavori
per il
completamento
delle remediation
utilizzando il tool
fornito dal PCI SSC
denominato
“Prioritized
Approach”
 L’acquirer per ogni
merchant comunica
due volte all’anno lo
stato di compliance
o non compliance
 L’acquirer per ogni
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
 Su richiesta gli
acquirer devono
fornire anche Self
Assessment
Questionnaire e
Attestation of
Compliance dei
merchant
4  Nessun requisito
per la reportistica
richiesto
 Requisiti definiti
dagli acquirer
 L’acquirer per ogni
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
 Su richiesta gli
acquirer devono
fornire anche Self
Assessment
Questionnaire e
Attestation of
Compliance dei soli
merchant che
effettuano e-
commerce
Capitolo 1
23
1.2.1.2 Service Provider
Anche per i service provider sono stabiliti diversi livelli di
certificazione e ciascun payment brand prevede differenti soglie nel
numero delle transazioni con carte di pagamento gestite in un anno.
I service provider sono classificati in alternativa anche per tipo.
Ad esempio JCB considera service provider tutte le terze parti che
assumono il ruolo di processor di transazioni effettuate con carte di
pagamento a prescindere dai livelli.
American Express è l’unico payment brand a prevedere 3 livelli,
mentre Discover MasterCard, Visa Inc e Visa Europe ne prevedono
solo 2.
Nelle successive tabelle sono rappresentati i requisiti di
validazione e di reportistica previsti per ciascun livello di
certificazione in cui si colloca un service provider:
 Livelli di certificazione per i Service Provider
Livelli di certificazione per i Service Provider (American Express, Discover, JCB)
Livello American Express Discover JCB
1  Service Provider che
gestiscono più di 2,5
milioni di transazioni
all’anno con carte di
pagamento
American Express
 Qualunque Service
Provider
determinato come
Level 1 da parte di
American Express
 Service Provider che
gestiscono più di
300000 transazioni
all’anno con carte di
pagamento Discover
 Qualunque Service
Provider
determinato come
Level 1 da parte di
Discover
 Tutte le entità
identificate come
TPP (Third Party
Processors) a
prescindere dal
numero di
transazioni gestite
2  Service Provider che
gestiscono da 50000
a 2,5 milioni di
transazioni all’anno
con carte di
pagamento
American Express
 Service Provider che
gestiscono meno di
300000 transazioni
all’anno con carte di
pagamento Discover
 N/A
Capitolo 1
24
Livelli di certificazione per i Service Provider (American Express, Discover, JCB)
Livello American Express Discover JCB
3  Service Provider che
gestiscono meno di
50000 transazioni
all’anno con carte di
pagamento
American Express
 N/A  N/A
Livelli di certificazione per i Service Provider (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
1  Entità identificate
come TPP (Third
Party Processors) a
prescindere dal
numero di
transazioni gestite
 Entità identificate
come Data Store
Entities (DSE) che
gestiscono più di
300000 transazioni
all’anno con carte di
pagamento
MasterCard e
Maestro
 Qualunque TPP o
DSE che abbia
subito una
compromissione
nell’ultimo anno
 Tutti i VisaNet
Payment Processors
 Service Provider che
gestiscono più di
300000 transazioni
all’anno con carte di
pagamento Visa
 Tutti i Visa System
Processors
 Service Provider che
gestiscono più di
300000 transazioni
all’anno con carte di
pagamento Visa
2  Tutte le entità
identificate come
Data Store Entities
(DSE) che gestiscono
meno di 300000
transazioni all’anno
con carte di
pagamento
MasterCard e
Maestro
 Service Provider che
gestiscono meno di
300000 transazioni
all’anno con carte di
pagamento Visa
 Service Provider che
gestiscono meno di
300000 transazioni
all’anno con carte di
pagamento Visa
Capitolo 1
25
 Requisiti di validazione per i Service Provider
Req. di validazione per i Service Provider (American Express, Discover, JCB)
Livello American Express Discover JCB
1  Assessment on-site
annuale effettuato
da un QSA oppure
dal Service Provider
stesso se certificato
dal chief executive
officer
(amministratore
delegato), chief
fianancial officer
(direttore
finanziario), chief
information security
officer (direttore IT
security) o dal
principal (direttore
responsabile)
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Al di fuori dell’area
del Nord America è
necessario
consultare American
Express per la
corretta
classificazione
 Assessment on-site
annuale effettuato
da un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Assessment on-site
annuale effettuato
da un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
Capitolo 1
26
Req. di validazione per i Service Provider (American Express, Discover, JCB)
Livello American Express Discover JCB
2  Self Assessment
Questionnaire
annuale effettuato
dal Service Provider
stesso e certificato
dal chief executive
officer
(amministratore
delegato), chief
fianancial officer
(direttore
finanziario), chief
information security
officer (direttore IT
security) o dal
principal (direttore
responsabile)
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Tutti i Service
Provider non
compliant devono
presentare un piano
d’azione Discover
completo per la
realizzazione delle
remediations
 N/A
3  Self Assessment
Questionnaire
annuale
(fortemente
raccomandato)
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
(fortemente
raccomandato)
 N/A  N/A
Capitolo 1
27
Req. di validazione per i Service Provider (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
1  Assessment on-site
annuale effettuato
da un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
VisaNet Processor e
Service Provider:
 Assessment on-site
annuale effettuato
da un QSA con
produzione di un
Report on
Compliance (ROC)
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
 Inclusione nella
Global List di
Serrvice Provider
certificati PCI DSS
Service Provider
(Member Agent):
 Report On
Compliance dopo
assessment on-site
di un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
ASV
 Attestation of
Compliance form
 Registrazione come
Member Agent da
parte di un Visa
Europe Member con
Agent Registration
Designation form
(ARD)
 Inclusione nella Visa
Europe List di
Serrvice Provider
certificati PCI DSS
Merchant Agent:
 Scope of Audit form
compilata da un
QSA
 External
Vulnerability Scan
Assessment non più
vecchio di 90 giorni
(ASV)
 Attestation of
Compliace form
Capitolo 1
28
Req. di validazione per i Service Provider (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
2  Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Tutti i Service
Provider non
compliant devono
presentare un piano
d’azione
MasterCard
completo per la
realizzazione delle
remediations
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
Service Provider
(chiamati anche
Member Agent):
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment non più
vecchio di 90 giorni
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliance form
 Registrazione come
Member Agent da
parte di un Visa
Europe Member
tramite una Agent
Registration
Designation form
(ARD)
Merchant Agent:
 Self Assessment
Questionnaire
annuale
 External
Vulnerability Scan
Assessment non più
vecchio di 90 giorni
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliace form
Capitolo 1
29
 Requisiti di ri-validazione per i Service Provider
Requisiti di ri-validazione per i Service Provider (American Express, Discover, JCB)
American Express Discover JCB
 Tutta la procedura per
la validazione della
compliance è annuale
 Tutta la procedura per
la validazione della
compliance è annuale
in base alla data
indicata sulla
Attestaion of
Compliance
 Necessario contattare
JCB
MasterCard Visa Inc. Visa Europe
 Tutta la procedura per
la validazione della
compliance è annuale
 Il QSA deve produrre e
consegnare a
MasterCard la PCI DSS
Attestation of
Compliance for Onsite
Assessment – Service
Provider form
 I Report on Compliance
non sono accettati
 Una nuova AOC deve
essere fornita prima
della scadenza della
precedente pena la
decurtazione dalla lista
dei service provider PCI
DSS compliant
presente sul sito web
MasterCard
 Tutta la procedura per
la validazione della
compliance è annuale
in base alla data di
accettazione del Report
on Compliance
 Passata la data di
scadenza della
compliance precedente
il service provider
comparirà in colore
giallo nella lista di
Serrvice Provider
certificati PCI DSS per
un massimo di 60
giorni e in colore rosso
per un massimo di altri
30 giorni dopodiché
scomparirà dalla lista
Service Provider (chiamati
anche Member Agent):
 Tutta la procedura per
la validazione della
compliance è annuale
in base alla data di
accettazione del Report
on Compliance
 Passata la data di
scadenza della
compliance precedente
il service provider
comparirà in colore
giallo nella lista di
Serrvice Provider
certificati PCI DSS per
un massimo di 60
giorni e in colore rosso
per un massimo di altri
30 giorni dopodiché
scomparirà dalla lista
Merchant Agent:
 Tutta la procedura per
la validazione della
compliance deve
essere ripetuta entro
60 giorni dalla
scadenza del ROC/SAQ
Capitolo 1
30
 Requisiti di reportistica per i Service Provider
Requisiti di reportistica per i Service Provider (American Express, Discover, JCB)
Livello American Express Discover JCB
1 Se compliant
 Attestation of
Compliance
dall’assessment on-
site annuale
 Attestaion of Scan
Compliance o
Executive summary
degli External
Vulnerability Scan
trimestrali
Se non compliant
 Attestation of
Compliance che
includa la parte di
piano d’azione per
le remediation
 Data di
implementazione
delle remediation
(non oltre i 12 mesi
seguenti)
 Attestation of
Compliance
dall’assessment on-
site annuale
 Attestation of
Compliance che (se
non completamente
compliant) includa
la parte di piano
d’azione per le
remediation
 Nessun requisito per
la reportistica
richiesto
Capitolo 1
31
Requisiti di reportistica per i Service Provider (American Express, Discover, JCB)
Livello American Express Discover JCB
2 Se compliant
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestaion of Scan
Compliance o
Executive summary
degli External
Vulnerability Scan
trimestrali
Se non compliant
 Attestation of
Compliance che
includa la parte di
piano d’azione per
le remediation
 Data di
implementazione
delle remediation
(non oltre i 12 mesi
seguenti)
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestation of
Compliance che (se
non completamente
compliant) includa
la parte di piano
d’azione per le
remediation
 N/A
3  Nessun requisito per
la reportistica
richiesto
 N/A  N/A
Capitolo 1
32
Requisiti di reportistica per i Service Provider (MasterCard, Visa Inc., Visa Europe)
Livello MasterCard Visa Inc. Visa Europe
1  Attestation of
Compliance
dall’assessment on-
site annuale
 MasterCard non
accetta né revisiona
Report on
Compliance
 Attestation of
Compliance che
includa la parte di
piano d’azione per
le remediation solo
se non
completamente
compliant e solo se
si tratta di una
prima registrazione
Third Party Agents
 Attestation of
Compliance
dall’assessment on-
site annuale
VisaNet Processor
 Attestation of
Compliance
dall’assessment on-
site annuale
 Report on
Compliance
completo
Member Agents
 Attestation of
Compliance
dall’assessment on-
site annual
 QSA confirmation
form (sito Visa)
2  Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestation of
Compliance che
includa la parte di
piano d’azione per
le remediation solo
se non
completamente
compliant e solo se
si tratta di una
prima registrazione
Third Party Agents
 Attestation of
Compliance
dall’assessment on-
site annuale
VisaNet Processor
 Attestation of
Compliance
dall’assessment on-
site annuale
 Report on
Compliance
completo
Member Agents
 Attestation of
Compliance
dall’assessment on-
site annual
 QSA confirmation
form (sito Visa)
Capitolo 1
33
1.2.2 Relazioni con altri standard PCI
Il PCI SSC ha tra i suoi compiti la responsabilità di definire e
diffondere anche altri standard legati alla sicurezza informatica. Tali
standard possono essere legati alla certificazione PCI DSS
principalmente per il fatto che la loro applicazione può renderne più
facile il percorso. Di seguito si presenta un sintetico elenco degli
stessi con una breve descrizione:
 PA-DSS Payment Application Data Security Standard (PCI
Security Standards Council, LLC, 2006 - 2015):
o la certificazione PA-DSS è rivolta ai software vendor per
facilitare la compliance PCI DSS dei propri clienti;
o è applicabile solamente a software di terze parti che
memorizzano, elaborano o trasmettono CHD come parte
del processo di Autorizzazione e/o di Settlement;
o per le applicazioni che risiedono su terminali PCI PTS
Approved Point of Interaction, la compliance può essere
una combinazione di caratteristiche hardware (del POI
Point of Interaction che può essere un terminale POS) e
software (ossia l’applicazione stessa);
o tale certificazione non è applicabile a sistemi
personalizzati, come un’applicazione sviluppata per conto
di un unico cliente o comunque che ha subito pesanti
personalizzazioni;
o le applicazioni candidate alla PA-DSS devono essere
quelle cosiddette Off the Shelf che non prevedono pre-
installazioni personalizzate da parte dei vendors;
o infine, nonostante ne faciliti il percorso, un’applicazione
certificata PA-DSS non garantisce la compliance PCI
DSS;
 P2PE (Point-to-Point Encryption) (PCI Security Standards
Council, LLC, 2006 - 2015):
o applicabile a soluzioni che assicurano la corretta
cifratura dal POI alle P2PE validated applications;
o garantisce la corretta gestione dei device, delle cifrature,
delle chiavi;
o riduce il perimetro di certificazione PCI DSS dei CDE
(CardHolder Data Environment) dei merchant;
o non garantisce ma facilita la compliance PCI DSS;
Capitolo 1
34
 PTS (PIN Transaction Security) (PCI Security Standards
Council, LLC, 2006 - 2015):
o rivolta ai terminali (o POI Point of Interaction) utilizzati
per i pagamenti card-present;
o definisce i requisiti per la compliance PCI dei POI in base
a caratteristiche fisiche, funzionali e di gestione
(lifecycle);
o non garantisce ma facilita la compliance PCI DSS;
 Card Production (PCI Security Standards Council, LLC, 2006 -
2015):
o rivolta a sistemi e processi di business legati alla
personalizzazione delle carte di pagamento (produzione,
generazione PIN, trasmissione PIN);
o definisce una serie di requisiti “logici” (ruoli, policy,
procedure, data security e network security);
o definisce una serie di requisiti “fisici” (personale, edifici,
procedure, monitoraggio).
1.3 Ruoli
Lo standard PCI DSS prevede l’esistenza di una serie di attori,
ciascuno con il proprio ruolo.
1.3.1 PCI SSC (Security Standards Council)
Il PCI Security Standard Council è responsabile per la
redazione e l’aggiornamento degli standard di sicurezza legati alla
Payment Card Industry (PCI DSS, PA-DSS, PTS, P2PE, Card
Production).
È responsabilità del Council definire i requisiti di qualificazione
per gli assessors (QSA, PA-QSA, ASV e ISA) che operano in tutto il
mondo per l’ottenimento della compliance da parte delle entità che ne
fanno richiesta.
Inoltre certifica le aziende che svolgono servizi di PCI DSS
assessment, PA-DSS assessment (le QSA Companies) e ASV
vulnerabilities assessment (Approved Scanning Vendors) e mantiene le
liste degli stessi sul proprio sito.
Compito del PCI SSC è anche mantenere aggiornate una serie
di liste che contengono:
Capitolo 1
35
 l’elenco delle applicazioni certificate PA-DSS;
 l’elenco dei device certificati PTS;
 l’elenco delle soluzioni certificate P2PE.
Altre responsabilità sono revisionare a campione report (ROC,
ROV, P-ROV e ASV scan) che vengono redatti dagli assessors, erogare
il training per QSA, PA-QSA, ASV, ISA, QIR, PCIP oltre a un più
generico awareness training accessibile attraverso diversi canali,
redigere linee guida su specifiche tecnologie utilizzate nei processi di
transazioni economiche con l’uso di carte di pagamento e infine
promuovere la messa in sicurezza di tali processi di pagamento a
livello globale.
1.3.2 Payment Brands (AmEx, Discover, JCB, MC, VISA)
Un fondamentale attore della Payment Card Industry è il
payment brand.
I payment brands, oltre ad essere parte costitutiva del PCI
Security Standards Council sono responsabili dello sviluppo dei propri
programmi di compliance (da cui peraltro derivano nella sostanza i
requisiti dello standard PCI DSS), definiscono multe e sanzioni per le
non-compliance rilevate nei confronti di acquirer che, ad esempio,
non hanno prodotto evidenze per la compliance dei propri merchant,
approvano i criteri di qualificazione per le aziende QSA, PA-QSA e
ASV, accettano la documentazione di certificazione da parte delle
aziende QSA, PA-QSA e ASV (oltre che dai loro dipendenti qualificati
come tali), forniscono feedback al PCI SSC per le performances di
QSA, PA-QSA e ASV ed infine sono l’entità preposta ad effettuare le
indagini forensi a fronte di incidenti informatici che hanno generato
perdita o compromissione di dati.
1.3.3 Qualified Security Assessor
Il QSA è il professionista (o il gruppo di professionisti) che
definisce e valida lo scope degli assessment presso le entità candidate
per l’ottenimento della certificazione PCI DSS.
Infatti il QSA effettua concretamente gli assessment PCI DSS
presso le sedi dei merchant e dei service provider per tutta la durata
di tempo necessaria (che viene stimata in non più di 3 mesi
Capitolo 1
36
considerando che sia questo il tempo massimo in cui non avvengano
modifiche sostanziali dell’ecosistema).
Inoltre il QSA verifica le informazioni fornite da merchant e
service provider valutandole in modo indipendente e sulla base di
evidenze che possano comprovare le proprie conclusioni. Nel caso in
cui siano rilevate delle non conformità che rendono necessari dei
rimedi, il QSA è incaricato di validare le soluzioni adottate
considerando anche l’applicabilità di eventuali controlli compensativi
a fronte di requisiti non rispettati per giustificabili difficoltà
tecnologiche o economiche.
Non essendo possibile, in alcuni casi, procedere con un esame
di tutto il perimetro afferente la certificazione, il QSA stabilisce, ove
richiesto dallo standard, i criteri di sampling da utilizzare durante
l’assessment.
Infine il QSA redige i report per la compliance, che dovranno
essere valutati dal sistema di qualità interno all’azienda QSA per cui
l’assessor opera e che saranno poi spediti ai payment brands che li
richiedono.
1.3.4 Internal Security Assessor (ISA)
L’Internal Security Assessor è il corrispondente di un QSA
all’interno di un’organizzazione che intende ottenere la certificazione
PCI DSS. Egli definisce e valida lo scope degli assessment oltre a
effettuare concretamente gli assessment PCI DSS presso la propria
azienda, laddove previsto dai requisiti di validazione da parte dei
payment brands descritti al paragrafo 1.2.1.
All’interno della propria azienda fornisce supporto per i processi
di compliance, verifica le informazioni valutandole in modo
indipendente, valida le soluzioni adottate a fronte di rilevazione di
non conformità e valuta eventuali controlli compensativi a fronte di
requisiti non rispettati per giustificabili difficoltà tecnologiche o
economiche.
Stabilisce inoltre, ove richiesto dallo standard, i criteri di
sampling da utilizzare durante l’assessment ed infine, laddove
previsto dai requisiti di validazione da parte dei payment brands
descritti al paragrafo 1.2.1, redige i report per la compliance.
Capitolo 1
37
1.3.5 Merchant e Service Provider
Merchant e service provider sono le entità a cui è rivolto lo
standard PCI DSS. Essi sono tenuti a conoscere gli standard PCI e le
politiche di sicurezza determinate dai singoli payment brand verso i
quali dimostrano, attraverso l’attestazione di conformità (AOC
Attestation of Compliance), la propria compliance. Dal momento che
gli standard subiscono un aggiornamento a cadenze ben determinate
(per la PCI DSS il ciclo di validità di una versione è di tre anni salvo
aggiornamenti straordinari di alcune parti) merchant e service
provider sono tenuti anche ad essere aggiornati sulle modifiche agli
stessi.
Un loro preciso dovere è quello di fornire la propria AOC a
acquirer o direttamente ai payment brand.
Infine è loro responsabilità quella di garantire il mantenimento
della compliance durante tutto il periodo di attività e non solo nel
periodo di certificazione.
1.3.6 Approved Scanning Vendor (ASV)
Gli ASV sono rappresentati dalle organizzazioni titolate ad
effettuare i Vulnerability Scan esterni secondo le regole stabilite dallo
standard PCI DSS.
Nello svolgimento del loro lavoro, scandagliano tutti i range IP e
i domini che sono esposti su reti pubbliche forniti dalle entità per cui
effettuano il servizio, determinando, in accordo con i clienti, anche
eventuali aggiunte di indirizzi IP rilevati.
Al termine della fase di scan, gli ASV forniscono un report
dettagliato sui risultati degli stessi e ne certificano la compliance con
lo standard PCI DSS.
1.4 I singoli requisiti dello standard PCI DSS
I requisiti dello standard PCI DSS prevedono due principali tipi
di raggruppamento: i goals e i requirements. Nella tabella seguente
sono descritti brevemente tali raggruppamenti:
Capitolo 1
38
Goals Req Descrizione
Sviluppo e gestione
di sistemi e reti
sicure
1
Installare e gestire una configurazione firewall
per proteggere i dati dei titolari di carta
2
Non utilizzare valori predefiniti del fornitore per
le password di sistema e altri parametri di
protezione
Protezione dei dati
dei titolari di carta
3 Proteggere i dati dei titolari di carta memorizzati
4
Cifrare i dati dei titolari di carta trasmessi su reti
aperte e pubbliche
Utilizzare un
programma per la
gestione delle
vulnerabilità
5
Proteggere tutti i sistemi dal malware e
aggiornare regolarmente i programmi o il
software antivirus
6 Sviluppare e gestire sistemi e applicazioni sicure
Implementazione di
rigide misure di
controllo
dell’accesso
7
Limitare l’accesso ai dati dei titolari di carta solo
se effettivamente necessario
8
Individuare e autenticare l’accesso ai
componenti di sistema
9
Limitare l’accesso fisico ai dati dei titolari di
carta
Monitoraggio e test
delle reti regolari
10
Registrare e monitorare tutti gli accessi a risorse
di rete e dati dei titolari di carta
11
Eseguire regolarmente test dei sistemi e processi
di protezione.
Gestione di una
politica di sicurezza
delle informazioni
12
Gestire una politica che garantisca la sicurezza
delle informazioni per tutto il personale.
1.4.1 Descrizione dei requisiti e delle procedure di test
Ciascun requisito dello standard PCI DSS prevede che siano
eseguite delle procedure di verifica da parte di un QSA per poter
determinare la compliance di sistemi, processi e documentazione che
sono compresi nel Cardholder Data Environment (CDE).
Tutte le evidenze, i controlli, le interviste che sono richieste da
ciascun requisito devono essere considerate nella loro interezza, cioè
un requisito non può risultare “parzialmente conforme”, altrimenti
verrebbe considerato come una non conformità.
In alcuni casi ci possono essere degli ambienti in cui alcuni
requisiti possono risultare non applicabili e tale condizione deve
Capitolo 1
39
essere in ogni caso verificata dal QSA che effettua l’assessment e che
deve giustificare lo stato di non applicabilità. Per fare un esempio ci
possono essere organizzazioni che non prevedono l’utilizzo di reti
wireless: in questi casi il QSA deve verificare e certificare che nessuna
rete wireless è utilizzata dall’azienda inserendo tali motivazioni in
ogni requisito che richieda delle procedure di test che coinvolgono
tale tecnologia.
Diverso è il trattamento dei requisiti che possono essere definiti
come “not tested”, perché tale stato è attribuibile solamente ai
requisiti che possono essere completamente esclusi dalle procedure
di test. Un esempio è costituito dai requisiti che un acquirer esclude
dalla richiesta di compliance di un proprio merchant oppure quando
un’organizzazione ha la necessità di validare un nuovo sistema di
sicurezza che coinvolge solo un certo numero di requisiti (ad esempio
un nuovo sistema di crittografia che richiede la verifica dei soli
requisiti 2, 3 e 4)
Nell’Appendice A sono riportati tutti i requisiti dello standard
PCI DSS versione 3.0 con le corrispondenti procedure di test.
Capitolo 2
40
2. Capitolo 2
In questo capitolo si descriveranno le linee guida da seguire per
effettuare un assessment PCI DSS, con l’obiettivo di stabilire una
serie di passi operativi che consentiranno l’automatizzazione (anche
se non completa) del processo.
2.1 Linee guida sulle fasi dell'assessment PCI DSS
Le fasi di un assessment PCI DSS non sono determinate con
esattezza dal PCI SSC ed ogni QSA può definire un proprio progetto
con l’unico vincolo di produrre la documentazione richiesta (Report on
Compliance, Attestation of Compliance e, per Visa, la Scope of Audit
form).
Una proposta sulle fasi dell’assessment è il principale obiettivo
del presente lavoro. I punti seguenti, insieme al diagramma a blocchi
rappresentato nella Fig. 4, la sintetizzano, mentre i successivi
paragrafi ne approfondiscono gli aspetti:
 Gap Analysis
 Scoping
 Network Segmentation
 Prioritized Approach
 Remediations
 On-site Assessment
 Compensating Controls
 Report on Compliance
 Attestation of Compliance
Capitolo 2
41
Gap Analysis
Descrizione dell’attività
svolta dall’entità
Definizione di un diagramma
di network ad alto livello
Network
Segmentation
Report On
Compliance
Compensating
Controls
Scoping
Implementazione
Remediations
Prioritized
Approach
On-Site Assessment (check
requisiti)
Attestation Of
Compliance
Sì
Determinazione
dello scope
Analisi della riduzione dello scope
Definizione del network diagram
dettagliato
Determinazione dei flussi di CHD e
SAD
Dipartimenti che necessitano di CHD
Segmenti rete che memorizzano
CHD
Segmenti rete che elaborano/
trasmettono CHD
Segmenti rete collegati al CDE
Segmenti rete dei CLIENT collegati
Altri segmenti di rete
Censimento FW, Switch, Router...
Config. FW, Switch, Router
Verifica
remediation
Inplementazion
e Remediations
No
Censimento delle basi di dati collegate alle
applicazioni
Censimento di tutti gli host (IP address) su cui sono
installate applicazoni e database
Censimento di tutti i sistemi che si connettono agli host
del punto precedente
Censimento delle parti di infrastruttura in outsourcing
Censimento di tutti i segmenti di rete su cui si attestano
host e client del punto 3 e 4
Censimento dei sistemi operativi coinvolti di
tutti i sistemi del CDE
Censimento reti wireless
Censimento di tutti gli apparati di rete per gestione del
traffico dei segmenti di rete
Disegno dell’intera rete
Censimento collegamenti con reti esterne (Internet, VPN
...) e relative DMZ
Censimento ATM/POI
Disegno flussi di CHD da e verso l’esterno dell’entità e
sulle reti interne
Censimento di tutti i sistemi non elettronici di gestione
dei CHD (carta o altro)
Censimento dei processi organizzativi per la gestione dei
CHD
Censimento dipartimenti e persone
Censimento di tutte le applicazioni che
gestiscono CHD
Fasi dell’assessment PCI-DSS
Remediation
necessarie?
Sì
Remediation
necessarie?
No
Figura 4: Fasi dell'assessment PCI DSS
2.1.1 Gap Analysis
Durante la fase di Gap Analysis uno dei compiti da eseguire
consiste nella redazione di una descrizione dettagliata dell’attività
svolta dall’entità che si sta certificando, mettendo in risalto quali
siano i servizi offerti che sono sottoposti a verifica di conformità da
parte del QSA. All’interno di tale sommario è necessario specificare
nel modo più preciso possibile come e perché sono memorizzati,
elaborati o trasmessi i CHD, quali tipi di pagamenti sono gestiti
(MOTO, e-commerce, card-present, card-not-present) ed infine
specificare quali sono le relazioni con altre entità con cui i CHD sono
condivisi.
La fase descrittiva deve anche prevedere la definizione di un
diagramma ad alto livello che contenga in maniera schematica e
Capitolo 2
42
facilmente comprensibile l’architettura complessiva dell’ambiente
sottoposto ad assessment, tutte le sedi dell’entità con la
rappresentazione dei sistemi chiave dell’ambiente ed i rispettivi
confini, le connessioni inbound e outbound tra i sistemi appartenenti
al Cardholder Data Environment (CDE) e quelli delle altre zone, la
chiara rappresentazione di sistemi critici quali apparati di rete
preposti al controllo del traffico (firewall, router, IDS/IPS), Point of
Sales (POS), database server, application server, web server, DNS,
authentication server, wireless access point e tutto ciò che è ritenuto
rilevante per la certificazione stessa. Nella Fig. 5 è rappresentato un
esempio di diagramma ad alto livello:
Fig. 5: Esempio di diagramma di rete ad alto livello
2.1.2 Scoping
La fase di Scoping è probabilmente la più delicata, quella che
richiede la maggior cura e precisione, proprio perché è il momento in
Capitolo 2
43
cui si determina il perimetro, sia tecnologico che di processi e
persone, che costituirà il Cardholder Data Environment.
L’estrema importanza di questa fase è determinata dal fatto che
in primo luogo essa identifica con precisione quali sono le risorse che
memorizzano, processano o trasmettono dati di titolari di carte di
pagamento e successivamente circoscrive l’applicabilità di tutti i
requisiti dello standard PCI DSS alle sole risorse individuate.
Un errore in questa fase comprometterebbe tutto il processo di
certificazione, costringendo a un riciclo dello stesso ove, in una fase
successiva, venissero scoperti nuovi asset da inserire nel perimetro.
Il compito principale dell’entità sottoposta alla fase di
assessment PCI DSS, per essere sufficientemente sicura di poter
conseguire la certificazione, è quello di adottare tutte le tecniche
messe a disposizione, sia dal punto di vista tecnologico che
organizzativo, per ridurre il perimetro di certificazione e, di
conseguenza, lo sforzo richiesto per essere conforme.
La riduzione del perimetro di certificazione può essere ottenuta,
per esempio, segregando i sistemi che gestiscono i dati di titolari di
carte di pagamento con la tecnica della segmentazione della rete, con
l’obiettivo di fare in modo che chi non ha bisogno di entrare in
contatto con tali dati, sia posto al di fuori del perimetro di
certificazione e quindi non obbligato a rispettare i requisiti di
compliance dello standard PCI DSS, anche se una buona pratica di
gestione della sicurezza dei sistemi IT consiglierebbe di farlo.
Pertanto al termine della fase di Scoping è necessario definire
un diagramma di network dettagliato, contenente, per ciascuna area
individuata nel diagramma di alto livello durante la fase di Gap
Analysis, i sistemi che sono da considerare in perimetro con i
collegamenti che ci sono tra essi, nonché i flussi di dati di titolari di
carte di pagamento che insistono su tale ambiente.
Nella Fig. 6 è rappresentato un esempio di come il diagramma
di alto livello precedentemente descritto possa essere specificato per
determinare lo scope della certificazione.
Capitolo 2
44
Fig. 6: Esempio di diagramma di rete dettagliato
Nel paragrafo 2.2 sono meglio dettagliati i singoli passi da
effettuare per la determinazione del perimetro di certificazione.
2.1.3 Network Segmentation
La segmentazione della rete è il primo e più importante
strumento che può essere utilizzato per ottenere una effettiva
riduzione del perimetro di certificazione PCI DSS.
Attraverso di essa è possibile escludere interi rami d’azienda
partendo dal presupposto che tale suddivisione rispecchi anche
un’effettiva separazione delle mansioni (separation of duties) dal
punto di vista organizzativo.
Segmentare una rete non è di per se sufficiente a garantire una
riduzione dello scope: è necessario che il traffico tra i vari segmenti
sia controllato da componenti come firewall, router o switch che,
attraverso le regole definite all’atto della configurazione degli stessi o
attraverso la definizione di Access Control List, permettano o
impediscano le comunicazioni, con lo scopo di segregare i segmenti di
Capitolo 2
45
rete che dovranno essere sottoposti alla certificazione PCI DSS dagli
altri segmenti che non saranno obbligati ad essere conformi ai
requisiti, nonostante sia fortemente consigliato farlo.
Per poter implementare una effettiva segregazione dell’ambiente
sottoposto alle regole dello standard PCI DSS, è innanzitutto
necessario determinare quali siano i flussi di dati di titolari di carte di
pagamento tra i segmenti della rete.
Contemporaneamente alla determinazione dei flussi, si
individuano i dipartimenti dell’azienda che hanno la necessità di
gestire questo tipo di dati, verificando quali di essi abbiano
un’effettiva titolarità ad accedervi e, di conseguenza, restringendo il
perimetro tecnologico interessato dalla certificazione.
Una volta stabilito quali siano i flussi e i dipartimenti compresi
nel perimetro, si determinano con precisione quali siano i segmenti di
rete da includervi, per poter procedere alla conseguente
configurazione (se non già effettuata) degli apparati di controllo del
traffico. Si può iniziare dei segmenti di rete su cui sono attestati i
sistemi che effettuano memorizzazione di CHD e/o SAD come ad
esempio database server e file server.
Si procede quindi con la determinazione dai segmenti di rete su
cui si attesteranno i sistemi che effettuano elaborazione o
trasmissione di CHD e/o SAD senza necessariamente memorizzarli
(ad esempio quelli si cui insistono gli application server).
Successivamente si determinano i segmenti di rete su cui si
attestano i server che necessitano di un collegamento col Cardholder
Data Environment (DNS, Authentication server, Log server,
Monitoring server, Antivirus server, Proxy server, ecc).
I passi successivi riguardano la definizione dei segmenti di rete
su cui si attestano i client che necessitano di un collegamento con i
server precedentemente individuati (siano essi collegamenti wired che
wireless), di tutti gli altri segmenti di rete dell’azienda che non hanno
interazioni dirette con il CDE e quindi dei componenti preposti al
controllo del traffico (firewall, switch/router) tra i segmenti di rete
individuati.
Infine si procede con la configurazione dei sistemi di controllo
del traffico, oppure con il controllo delle configurazioni stesse laddove
siano già state implementate.
Capitolo 2
46
2.1.4 Prioritized Approach
Un valido strumento per poter effettuare un primo ciclo
dell’assessment ad un livello più alto è costituito dal foglio excel
fornito direttamente dal PCI Security Standards Council denominato
Prioritized Approach. Tale strumento è utilizzabile soprattutto per i
merchant, in quanto la riorganizzazione dei requisiti in base ad un
criterio di priorità diverso dalla semplice sequenza degli stessi,
permette di ottenere l’accettazione dello stato di conformità prima di
aver terminato tutti i requisiti dello standard, dal momento che i
payment brands concedono ai merchant la possibilità di dimostrare il
progresso del loro lavoro per ottenere la completa certificazione in
occasione della comunicazione periodica che perviene loro dagli
acquirer con cadenza semestrale.
Il Prioritized Approach riorganizza i requisiti PCI DSS in base a
sei security milestones tracciando un percorso che aiuta le
organizzazioni ad affrontare la certificazione stabilendo delle priorità,
con lo scopo di implementare i requisiti PCI DSS identificando prima
gli obiettivi a più alto rischio di sicurezza.
La seguente tabella sintetizza la definizione delle milestones
mentre sul sito del PCI Security Standards Council si può trovare il
foglio excel da utilizzare per la fase di assessment.
Milestone Goal
1
Rimuovere i Sensitive Authentication Data e limitare la ritenzione dei
dati. Questa milestone si concentra su un’area chiave per la gestione
del rischio di entità che possono essere compromesse. È importante
ricordare che se i Sensitive Authentication Data non sono memorizzati,
gli effetti di una eventuale compromissione sarebbero fortemente
ridotti.
2
Proteggere il perimetro interno e le reti wireless. Questa milestone
comprende i controlli per i possibili punti di accesso dei più frequenti
eventi di compromissione, sia per quanto riguarda la rete interna
wired d che quella wireless.
3
Implementare la sicurezza delle applicazioni di pagamento con carte.
Questa milestone ha come obiettivo la messa in sicurezza delle
applicazioni utilizzate per gestire le transazioni economiche con carte
di pagamento, sia per quanto riguarda i processi che le tecnologie
(application server). Le vulnerabilità in quest’area offrono facili
percorsi per avere accesso a dati di titolari di carta di pagamento e
comprometterli o rubarli.
Capitolo 2
47
Milestone Goal
4
Controllare l’accesso ai propri sistemi. I controlli compresi in questa
milestone permettono di rilevare CHI accede, COSA gestisce, QUANDO
e COME opera nella rete e nel Cardholder Data Environment.
5
Proteggere i dati di titolari di carte di pagamento memorizzati. Per
tutte quelle organizzazioni che hanno la necessità di memorizzare PAN
e altri cardholder data, questa milestone indirizza tutte le attività di
protezione degli stessi.
6
Finalizzare le rimanenti attività di compliance ed assicurare che tutti i
controlli siano attivi. L’obiettivo della milestone 6 è quello di
completare tutti i rimanenti requisiti PCI DSS e rifinire tutte le
rimanenti politiche, procedure e processi di gestione della sicurezza
del Cardholder Data Environment.
L’approccio permette di diminuire il rischio di compromissione
o perdita di dati di titolari di carte di pagamento prima possibile
durante il processo di certificazione, consente di monitorare
l’andamento della certificazione con grafici e percentuali di
conformità già raggiunti e aiuta gli acquirers a misurare il progresso
delle attività di certificazione dei merchants da loro serviti.
È importante sottolineare che il Prioritized Approach non
sostituisce i documenti come il Self Assessment Questionnaire SAQ o
il ROC per poter ottenere la certificazione, ma aiuta solo a organizzare
meglio il percorso.
Sul sito del PCI Security Standards Council (PCI Security
Standards Council, LLC, 2006-2015) esiste un questo tool che può
essere facilmente arricchito e migliorato per poter automatizzare la
verifica di coerenza delle informazioni raccolte e per avere uno
strumento di gestione di ciascun progetti di certificazione.
Esistono già altri strumenti molto più evoluti e disponibili nel
web. Un esempio è la PCI Compliance Dashboard (Godart, PCI
Compliance Dashboard, 2015) che può essere scaricata ed utilizzata
liberamente da chiunque voglia intraprendere un progetto di
certificazione PCI DSS.
2.1.5 Remediations
Per ogni requisito che risulta Not-in-place devono essere
stabilite delle attività di adeguamento. Queste attività possono essere
effettuate in parallelo all’analisi dei requisiti sia utilizzando
Capitolo 2
48
l’approccio sequenziale che quello “per priorità” definito dal Prioritized
Approach.
Nelle organizzazioni ben strutturate gruppi diversi di persone
possono occuparsi in modo complementare delle attività di gestione
del progetto di certificazione PCI DSS e, parallelamente, delle attività
di adeguamento che possono consistere in:
 adeguamenti tecnologici: sono attività che prevedono lo
spostamento di sistemi su diversi segmenti di rete, la
configurazione di sistemi che risultino non conformi per
vulnerabilità riscontrate, l’aggiunta di sistemi di controllo del
traffico, l’aggiunta di applicazioni o di strumenti per
l’innalzamento della sicurezza dell’ambiente, l’eliminazione di
sistemi inutili se non dannosi, ecc;
 adeguamenti di processi aziendali: sono attività prettamente
organizzative che possono prevedere la correzione o la
riscrittura di politiche, processi e procedure che non siano del
tutto conformi, la determinazione di nuovi processi di gestione
laddove mancanti, la schedulazione di attività periodiche (quali
la revisione dei log, il test del piano di risposta agli incidenti,
l’analisi dei rischi, la verifica dell’esistenza di nuove
vulnerabilità, il controllo delle patch di sicurezza, ecc.).
Al termine dell’implementazione gli adeguamenti devono essere
verificati dal QSA che ne deve determinare la conformità con lo
standard PCI DSS e tale attività può prevedere diversi cicli finché sia
certificata la bontà delle soluzioni adottate.
2.1.6 On-site Assessment
La fase di analisi effettuata in questi primi passi è da
considerarsi preparatoria al vero e proprio On-site Assessment.
Una volta terminata la fase di analisi guidata dall’approccio per
priorità oppure con un normale metodo sequenziale, si passa alla
verifica nel dettaglio di tutti i controlli previsti dal template del Report
on Compliance che può essere scaricato dal sito del PCI Security
Standards Council (PCI Security Standards Council, LLC, 2006-
2015).
Il template prevede che per ogni requisito siano effettuati una
serie di controlli (descritti nella colonna denominata “Reporting
Capitolo 2
49
instructions”) che possono andare dalla verifica di un documento a
quella di una configurazione, dalla verifica di un processo
all’intervista di persone dei dipartimenti compresi nel perimetro di
certificazione PCI DSS.
Anche in questo caso, a seconda delle risorse che si hanno a
disposizione, la fase può essere svolta in parallelo con quella degli
adeguamenti che devono essere implementati.
Tutti i controlli effettuati portano il requisito ad assumere uno
stato definito tra i seguenti:
 In Place: tutti gli aspetti del requisito oltre che dei requisiti di
livello più basso sono stati controllati e risultano conformi;
 In Place with CCW: i controlli effettuati hanno evidenziato una
o più non conformità rispetto al requisito così come
esplicitamente richiesto, che è coperto da un Controllo
Compensativo (Compensating Control);
 Not Applicable: il requisito non è applicabile all’ambiente da
certificare (ad esempio i requisiti che riguardano le reti wireless
possono essere non applicabili per assenza delle reti wireless
stesse all’interno dell’organizzazione);
 Not Tested: il requisito è escluso dal controllo, ad esempio, per
motivi di richiesta parziale da parte dell’acquirer, per la
validazione di un nuovo sistema che ha impatto solo su un
sottoinsieme di requirement o per il fatto che il service provider
offre solo un sottoinsieme di servizi da validare (es. solo servizi
di outsourcing fisico);
 Not In Place: i controlli del requisito, oltre che dei requisiti di
livello più basso, hanno dato esito negativo e sarà previsto un
adeguamento con successiva verifica di conformità.
Dal momento che si suppone che un’organizzazione non possa
stare in uno stato di immobilità per un periodo indeterminato di
tempo, si conviene, anche se nessun documento lo prescrive, che
l’intera fase di on-site assessment, fino all’emissione del ROC, non
debba superare i tre mesi di tempo.
Nell’Appendice B è rappresentato un diagramma di GANTT con
le attività previste per una fase di on-site assessment della durata di
tre mesi.
Capitolo 2
50
2.1.7 Compensating Controls
È possibile adottare compensating control per la maggior parte
dei requisiti PCI DSS, quando un’entità non è in grado di soddisfare
un requisito nel modo esplicitamente richiesto, a causa di limitazioni
aziendali o tecniche dettagliatamente documentate e legittime, ma ha
posto in essere altri controlli sufficienti a mitigare il rischio associato
a tale requisito.
I controlli compensativi devono soddisfare i seguenti criteri:
 rispondere allo scopo del requisito PCI DSS originale;
 offrire un livello di protezione simile al requisito PCI DSS
originale;
 andare oltre la copertura di altri requisiti richiesti (garantire la
conformità ad altri requisiti PCI DSS non è considerato un
controllo compensativo);
 essere adeguato al rischio ulteriore provocato dal mancato
pieno rispetto del requisito PCI DSS.
L’efficacia di un controllo compensativo dipende dalle specifiche
dell’ambiente in cui il controllo viene implementato. La valutazione di
un controllo compensativo prevede i seguenti vincoli:
 i requisiti PCI DSS esistenti non possono essere considerati
come controlli compensativi se sono già richiesti per il
componente oggetto del check. Ad esempio, le password per
l’accesso amministrativo non effettuato da console devono
essere inviate già cifrate per ridurre il rischio di intercettazione
delle stesse con testo in chiaro. Un’organizzazione non può
utilizzare altri requisiti di password PCI DSS, come ad esempio
quelli che ne definiscono la complessità, per compensare la
mancanza di password cifrate, poiché non riducono il rischio di
intercettazione;
 i requisiti PCI DSS esistenti possono essere considerati
controlli compensativi solo se sono richiesti per un’altra area,
ma non per il componente sottoposto a esame. Ad esempio
l’autenticazione a due fattori è un requisito PCI DSS per
l’accesso remoto, quindi la stessa, effettuata per accessi dalla
rete interna, può anche essere considerata un controllo
compensativo per l’accesso amministrativo non effettuato da
Capitolo 2
51
console, se la trasmissione di password cifrate non è
supportata;
 i requisiti PCI DSS esistenti possono essere combinati con
nuovi controlli per diventare un controllo compensativo. Ad
esempio se una società non è in grado di rendere illeggibili i
dati dei titolari di carta di pagamento quando memorizzati in
modo permanente secondo quanto prescritto dal requisito 3.4
(ad esempio tramite cifratura), un controllo compensativo
potrebbe essere composto da:
o segmentazione di rete interna con isolamento dei sistemi
che effettuano memorizzazione di CHD;
o filtro degli indirizzi IP o MAC per il collegamento a tali
sistemi solo da parte di chi è autorizzato;
o autenticazione a due fattori anche per accessi dalla rete
interna;
o processi e controlli periodici per garantire che i controlli
compensativi rimangano attivi una volta terminato
l’assessment;
Ogni controllo compensativo deve essere descritto nel dettaglio
utilizzando il Compensating Control Worksheet che è parte del Report
on Compliance. Le informazioni richieste riguardano:
 vincoli: è necessario elencare tutti i vincoli sia di tipo tecnico
che di tipo gestionale che impediscono di soddisfare il requisito
originale;
 obiettivo: il controllo originale ha un preciso obiettivo che deve
essere definito contestualmente con una sintetica descrizione
dell’obiettivo soddisfatto mediante il controllo compensativo;
 rischio identificato: identificare eventuali rischi aggiuntivi
dovuti alla non applicazione del controllo originale per
dimostrare che è stata effettuata un’approfondita analisi dei
rischi da parte dell’organizzazione;
 definizione del controllo compensativo: definire il controllo
compensative spiegando come soddisfa gli obiettivi del controllo
originale e come copre il rischio maggiore identificato
dall’analisi precedente;
 validazione: definire quali procedure e quali test sono stati
effettuati per poter verificare la validità del controllo
compensativo;
Capitolo 2
52
 manutenzione: definire i processi e i controlli periodici che
sono in atto per poter garantire l’effettiva efficacia del controllo
compensativo anche al termine dell’assessment PCI DSS.
2.1.8 Report on Compliance
Il Report on Compliance è l’elaborato finale che deve essere
redatto da un QSA perché un merchant o un service provider (che
possegga i requisiti necessari come spiegato nel paragrafo 1.2.1)
possa ottenere la certificazione PCI DSS.
Tale report deve essere realizzato seguendo le precise
indicazioni del PCI Security Standards Council che, a tal proposito,
ha realizzato il ROC Reporting Template scaricabile dal proprio sito 1.
Il ROC deve riportare TUTTI i requisiti in uno qualunque degli
stati elencati al paragrafo 2.1.6 ad eccezione dello stato Not-In-Place
perché la certificazione possa essere ottenuta.
Insieme al ROC è rilasciato anche il documento di Attestation of
Compliance (AOC).
2.1.9 Attestation of Compliance
L’Attestation of Compliance (AOC) è una dichiarazione di
conformità allo standard PCI DSS dove sono riportati in estrema
sintesi i risultati dell’assessment. L’organizzazione che ha superato
l’assessment a sua volta la invia a chi ne chiede una copia
(generalmente gli acquirer, i payment brands o i service provider che
collaborano con l’organizzazione stessa).
Esistono due versioni differenti dell’AOC, una per i merchant e
una per i service provider.
È firmata da un rappresentante dell’organizzazione certificata
che faccia parte del consiglio di amministrazione o che sia comunque
un manager con potere di firma e dal QSA (ove richiesto).
Anche in questo caso tali documenti possono essere scaricati
direttamente dal sito del PCI Security Standard Council 2.
1
https://www.pcisecuritystandards.org/
2
https://www.pcisecuritystandards.org/
Capitolo 2
53
2.2 Linee guida per la determinazione dello scope
Tutti i requisiti PCI DSS si applicano a tutte (e “tutte” è inteso
in senso letterale) le componenti dei sistemi (compresi network
devices, server ed applicazioni) incluse nel CDE o connesse ad esso.
Il CDE è costituito da persone, processi e tecnologie che
memorizzano, elaborano o trasmettono CHD o SAD.
2.2.1 Passi operativi
La determinazione del perimetro di certificazione, più
comunemente chiamato scope, è l’attività su cui si basa tutto il
percorso di certificazione di un’organizzazione, ed è perciò molto
importante che sia condotta con precisione e completezza.
Innanzitutto cominciamo a fare una prima distinzione tra i tipi
di sistemi che ci aspettiamo di trovare nell’ambiente informatico di
un’organizzazione dove sono gestiti CHD o SAD. In un ambiente di
questo tipo i sistemi possono essere suddivisi in 3 categorie (D.
Cougias, 2012):
 Categoria 1: componenti che effettuano elaborazione,
memorizzazione o trasmissione di CHD e SAD o non sono
isolati o limitati attraverso accesso controllato da altri
componenti di categoria 1; fanno parte di questa categoria
anche sistemi che definiremo come device contagiosi, cioè
dispositivi che sono considerati parte del CDE di categoria 1
anche se non effettuano elaborazione, memorizzazione o
trasmissione di CHD e SAD a causa dell'assenza di isolamento
o accesso controllato;
 Categoria 2 - Componenti che NON effettuano elaborazione,
memorizzazione o trasmissione di CHD e SAD e che hanno
accesso controllato a componenti di categoria 1; i componenti
di categoria 2 sono in scope e costituiti da device non-
contagiosi, cioè dispositivi che sono considerati parte del CDE
di categoria 2 che effettuano accesso controllato ai dispositivi di
categoria 1;
 Categoria 3 - Componenti che NON effettuano elaborazione,
memorizzazione o trasmissione di CHD e SAD e che sono isolati
da tutti i componenti di categoria 1;
Capitolo 2
54
La Fig. 7 sintetizza la suddivisione dei sistemi in categorie:
CATEGORIA 3 - Componenti che NON
effettuano ELABBORAZIONE,
MEMORIZZAZIONE o TRASMISSIONE di
CHD e SAD e che sono ISOLATI da tutti i
componenti di CATEGORIA 1
CATEGORIA 1 - Componenti che
effettuano ELABBORAZIONE,
MEMORIZZAZIONE o
TRASMISSIONE di CHD e SAD o
non sono ISOLATI o limitati
attraverso ACCESSO
CONTROLLATO da altri
componenti di CATEGORIA 1
CATEGORIA 2 - Componenti che NON
effettuano ELABBORAZIONE,
MEMORIZZAZIONE o TRASMISSIONE di
CHD e SAD e che hanno accesso
controllato a Componenti di
CATEGORIA 1
I componenti di
categoria C1 e C2
sono IN SCOPEDEVICE CONTAGIOSI:
Dispositivi che sono
considerati parte del CDE di
CATEGORIA 1 anche se non
effettuano ELABBORAZIONE,
MEMORIZZAZIONE o
TRASMISSIONE di CHD e SAD
a causa dell'assenza di
ISOLAMENTO o ACCESSO
CONTROLLATO
I componenti di categoria C2
sono IN SCOPE e costituiti da
DEVICE NON-CONTAGIOSI:
Dispositivi che sono
considerati parte del CDE di
CATEGORIA 2 che effettuano
ACCESSO CONTROLLATO ai
dispositivi di CATEGORIA 1.
Categorie
Fig. 7: Categorie per la determinazione dello scope (Fonte: D. Cougias)
La determinazione dell’appartenenza di un sistema ad una
categoria può essere fatta attraverso il seguente Decision Tree (Fig. 8):
Capitolo 2
55
Il componente
MEMORIZZA, ELABORA
o TRASMETTE CHD o
SAD?
CATEGORIA 1a
Esistono sistemi di
controllo dell’accesso che
limitano la connettività di
rete tra questo componente
e quelli di
CATEGORIA 1?
CATEGORIA 1b
Il componente,
direttamente o
indirettamente fornisce
funzionalità di sicurezza quali
autorizzazione, autenticazione
o controllo dell'accesso a un
componente di
CATEGORIA 1?
Il componente può
Iniziare una connessione a un
componente di
CATEGORIA 1?
Un componente
di CATEGORIA 1
può iniziare una connessione
con questo
componente?
Questo
componente è utilizzato
per amministrare un
componente di CATEGORIA 1
attraverso un componente
intermedio di
CATEGORIA 2?
CATEGORIA 2a
CATEGORIA 2b
CATEGORIA 2c
CATEGORIA 2x
CATEGORIA 3
1
2
3
4
5
6
7
8
9
10
11
12
13
SI
SI
NO
NO
NO
NO
NO
SI
SI
SI
SI
NO
Decision
Tree
I componenti di CATEGORIA 2
sono sempre in scope.
Tutti i requisiti PCI devono
essere valutati per accertarne
l’applicabilità sulla base di una
valutazione del rischio per il CDE
in generale e per l’intero
ambiente
Un componente può essere
definito ISOLATO da
componenti di CATEGORIA 1
se e solo se le risposte al
domande nei box 1, 4, 7, 9 e
11 sono "No".
I componenti di CATEGORIA 2X
sono sempre in scope;
tuttavia i controlli necessari per
ridurre il rischio di questi
componenti del CDE sono limitati
ai requisiti 1.4, 2, 5 e 6.1
I componenti di CATEGORIA 3 non
ELABORANO, non MEMORIZZANO e non
TRASMETTONO CHD.
La connettività diretta tra componenti di
CATEGORIA 3 e quelli di CATEGORIA 1 è
attivamente bloccata.
Fig. 8: Decision Tree per la determinazione dello scope (Fonte: D. Cougias)
Per avere una visione schematica ed immediata dei passi
operativi, si rimanda al paragrafo 2.1 che contiene un diagramma a
blocchi sintetico ma completo.
Capitolo 2
56
 Censimento delle applicazioni che gestiscono CHD
La proposta che qui si descrive e che deriva dall’esperienza sul
campo, consiste nel cominciare ad effettuare un censimento
degli strumenti di lavoro che le persone tutti i giorni utilizzano
per svolgere i propri compiti. Ad oggi i principali strumenti che
vengono utilizzati sono le applicazioni software, delle quali si
può avere un quadro generale attraverso le interviste con gli
operatori che le utilizzano, con i sistemisti che ne fanno
manutenzione e consultando la documentazione a corredo delle
stesse. Naturalmente questo primo passaggio permetterà di
tracciare il primo confine tra le applicazione che gestiscono dati
di titolari di carte di pagamento da quelle che invece hanno
altre funzioni (contabilità, gestione risorse, automazione
d’ufficio, ecc.).
 Censimento delle basi di dati collegate alle applicazioni
Una volta individuate le applicazioni che fanno parte del
cardholder data environment, è quindi necessario censire quali
siano le basi di dati (siano esse dei database o dei file
proprietari) a cui esse attingono per poter eseguire le loro
specifiche funzioni.
 Censimento di tutti gli host (IP address) su cui sono
installate applicazioni e database (sistemi di categoria 1)
Con la lista delle applicazioni e delle basi di dati, si può
procedere all’individuazione dei sistemi (fisici o virtuali) su cui
sono installate, compilando una lista di indirizzi IP che servirà
anche più avanti per individuare i sistemi che saranno
sottoposti agli scan per i vulnerability assessment e ai
penetration test.
 Censimento di tutti i sistemi che si connettono ai sistemi
di categoria 1 (sistemi di categoria 2)
Individuati i sistemi di categoria 1, si può quindi passare al
censimento dei sistemi che si connettono ad essi, come ad
esempio client, server di servizi come DNS, anti-virus,
monitoring, log o macchine di Backup. I sistemi di categoria 1
uniti ai sistemi di categoria 2 fanno parte del perimetro di
certificazione e costituiscono quindi il Cardholder Data
Environment.
 Censimento di tutti gli altri sistemi (sistemi di categoria 3)
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5
Peroli_Tesi_v3.5

More Related Content

What's hot

Rapporto e gov italia 19dic2010
Rapporto e gov italia 19dic2010Rapporto e gov italia 19dic2010
Rapporto e gov italia 19dic2010Between
 
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...Alberto Scotto
 
Innovazione, comunità professionali e pubblica amministrazione il caso csi
Innovazione, comunità professionali e pubblica amministrazione  il caso csiInnovazione, comunità professionali e pubblica amministrazione  il caso csi
Innovazione, comunità professionali e pubblica amministrazione il caso csiCarlo Mazzocco
 
La responsabilità sanitaria tra valutazione del rischio e assicurazione
La responsabilità sanitaria tra valutazione del rischio e assicurazioneLa responsabilità sanitaria tra valutazione del rischio e assicurazione
La responsabilità sanitaria tra valutazione del rischio e assicurazioneFabrizio Callarà
 
Manuale del centro diurno
Manuale del centro diurnoManuale del centro diurno
Manuale del centro diurnoFranco Pesaresi
 
Netex learningCentral | Student Manual v4.4 [It]
Netex learningCentral | Student Manual v4.4 [It]Netex learningCentral | Student Manual v4.4 [It]
Netex learningCentral | Student Manual v4.4 [It]Netex Learning
 
DECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETO
DECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETODECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETO
DECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETOMichele Ficara Manganelli
 

What's hot (8)

Rapporto e gov italia 19dic2010
Rapporto e gov italia 19dic2010Rapporto e gov italia 19dic2010
Rapporto e gov italia 19dic2010
 
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...
Cloud Computing: Una Soluzione "Private" Basata Su Software IBM (Tesi di laur...
 
Innovazione, comunità professionali e pubblica amministrazione il caso csi
Innovazione, comunità professionali e pubblica amministrazione  il caso csiInnovazione, comunità professionali e pubblica amministrazione  il caso csi
Innovazione, comunità professionali e pubblica amministrazione il caso csi
 
La responsabilità sanitaria tra valutazione del rischio e assicurazione
La responsabilità sanitaria tra valutazione del rischio e assicurazioneLa responsabilità sanitaria tra valutazione del rischio e assicurazione
La responsabilità sanitaria tra valutazione del rischio e assicurazione
 
Manuale del centro diurno
Manuale del centro diurnoManuale del centro diurno
Manuale del centro diurno
 
Netex learningCentral | Student Manual v4.4 [It]
Netex learningCentral | Student Manual v4.4 [It]Netex learningCentral | Student Manual v4.4 [It]
Netex learningCentral | Student Manual v4.4 [It]
 
Resport linee guida ita 20 gennaio 2020
Resport linee guida ita 20 gennaio 2020Resport linee guida ita 20 gennaio 2020
Resport linee guida ita 20 gennaio 2020
 
DECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETO
DECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETODECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETO
DECRETO SVILUPPO CRESCITALIA 2.0 - TESTO COMPLETO
 

Viewers also liked

Bitmap & vectorial
Bitmap & vectorialBitmap & vectorial
Bitmap & vectorialfloriin10
 
Talk on Electronic Commerce
Talk on Electronic CommerceTalk on Electronic Commerce
Talk on Electronic Commerceyjchang
 
background check
background checkbackground check
background checkxilvar
 
สร้างอักษร
สร้างอักษรสร้างอักษร
สร้างอักษรKittisak Keawsanit
 
Khaled ayoub updated cv 2016
Khaled ayoub updated cv 2016Khaled ayoub updated cv 2016
Khaled ayoub updated cv 2016Khaled Ayoub
 
Ativ 7 4_maria
Ativ 7 4_mariaAtiv 7 4_maria
Ativ 7 4_mariamdasdores
 
Tecnología educativa y comunicación
Tecnología educativa y comunicaciónTecnología educativa y comunicación
Tecnología educativa y comunicaciónjorgeelacrobata
 
百部名著導讀
百部名著導讀百部名著導讀
百部名著導讀Su Jason
 
Segurança autenticação apache -ppt
Segurança autenticação apache -pptSegurança autenticação apache -ppt
Segurança autenticação apache -pptCarlos Melo
 
Pesquisa_accenture
Pesquisa_accenturePesquisa_accenture
Pesquisa_accentureCarlos Melo
 
Acentos
AcentosAcentos
Acentosbuya74
 

Viewers also liked (17)

Bitmap & vectorial
Bitmap & vectorialBitmap & vectorial
Bitmap & vectorial
 
Talk on Electronic Commerce
Talk on Electronic CommerceTalk on Electronic Commerce
Talk on Electronic Commerce
 
Eibar
EibarEibar
Eibar
 
Programa
ProgramaPrograma
Programa
 
background check
background checkbackground check
background check
 
สร้างอักษร
สร้างอักษรสร้างอักษร
สร้างอักษร
 
Khaled ayoub updated cv 2016
Khaled ayoub updated cv 2016Khaled ayoub updated cv 2016
Khaled ayoub updated cv 2016
 
Las tic
Las ticLas tic
Las tic
 
1a its
1a its1a its
1a its
 
Ativ 7 4_maria
Ativ 7 4_mariaAtiv 7 4_maria
Ativ 7 4_maria
 
Guión del estudiante
Guión del estudianteGuión del estudiante
Guión del estudiante
 
Mapas
MapasMapas
Mapas
 
Tecnología educativa y comunicación
Tecnología educativa y comunicaciónTecnología educativa y comunicación
Tecnología educativa y comunicación
 
百部名著導讀
百部名著導讀百部名著導讀
百部名著導讀
 
Segurança autenticação apache -ppt
Segurança autenticação apache -pptSegurança autenticação apache -ppt
Segurança autenticação apache -ppt
 
Pesquisa_accenture
Pesquisa_accenturePesquisa_accenture
Pesquisa_accenture
 
Acentos
AcentosAcentos
Acentos
 

Similar to Peroli_Tesi_v3.5

Strategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informaticaStrategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informaticapeppespe
 
Realizzazione di un workflow integrato per la rilevazione di domini phishing
Realizzazione di un workflow integrato per la rilevazione di domini phishingRealizzazione di un workflow integrato per la rilevazione di domini phishing
Realizzazione di un workflow integrato per la rilevazione di domini phishingGiuliaMilan4
 
Sistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionSistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionAmmLibera AL
 
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...danieledegan
 
Dispensa Interazione Uomo Macchina
Dispensa Interazione Uomo MacchinaDispensa Interazione Uomo Macchina
Dispensa Interazione Uomo MacchinaStefano Bussolon
 
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...Donato Clun
 
CaputiDomenicoMagistrale
CaputiDomenicoMagistraleCaputiDomenicoMagistrale
CaputiDomenicoMagistraleDomenico Caputi
 
Tecnologie per la traccibilità
Tecnologie per la traccibilitàTecnologie per la traccibilità
Tecnologie per la traccibilitàLie Chen
 
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Luca Bressan
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingNicola Mezzetti
 
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEMTesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEMDavide Ciambelli
 
Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...
Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...
Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...Grogdunn
 
Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...
Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...
Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...lucafiore1
 
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...Ce.Se.N.A. Security
 
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...Davide Ciambelli
 
Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...
Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...
Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...Nicola Cerami
 

Similar to Peroli_Tesi_v3.5 (20)

Strategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informaticaStrategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informatica
 
Realizzazione di un workflow integrato per la rilevazione di domini phishing
Realizzazione di un workflow integrato per la rilevazione di domini phishingRealizzazione di un workflow integrato per la rilevazione di domini phishing
Realizzazione di un workflow integrato per la rilevazione di domini phishing
 
Sistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionSistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisition
 
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
 
Dispensa Interazione Uomo Macchina
Dispensa Interazione Uomo MacchinaDispensa Interazione Uomo Macchina
Dispensa Interazione Uomo Macchina
 
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
 
CaputiDomenicoMagistrale
CaputiDomenicoMagistraleCaputiDomenicoMagistrale
CaputiDomenicoMagistrale
 
Privacy nel Cloud
Privacy nel CloudPrivacy nel Cloud
Privacy nel Cloud
 
Mobile e Privacy
Mobile e PrivacyMobile e Privacy
Mobile e Privacy
 
Tecnologie per la traccibilità
Tecnologie per la traccibilitàTecnologie per la traccibilità
Tecnologie per la traccibilità
 
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based Routing
 
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEMTesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
 
Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...
Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...
Analisi e sviluppo di uno strumento per l'automazione della verifica di confo...
 
Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...
Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...
Libro "La valutazione dei rischi di incendio" L. Fiorentini (TECSA S.p.A.), L...
 
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
 
Tesi
TesiTesi
Tesi
 
Tesi
TesiTesi
Tesi
 
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
 
Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...
Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...
Progetto per lo sviluppo di un sistema di gestione della conoscenza per il pr...
 

Peroli_Tesi_v3.5

  • 1. La sicurezza informatica come ‘business as usual’: utilità ed efficacia della certificazione PCI DSS Carlo Peroli Facoltà di Scienze e tecnologie informatiche Corso di Laurea in Sicurezza dei Sistemi e delle Reti Informatiche Università degli Studi di Milano Relatore: Prof. Ernesto Damiani Correlatore: Dott. Fulvio Frati
  • 2.
  • 3.
  • 4. a Elisa e Joel
  • 5. iii Ringraziamenti Grazie a mia moglie Elisa e a mio figlio Joel che hanno partecipato sostenendomi (e sopportandomi) per tutto il percorso di studi. Grazie a mia madre, che mi ha sempre spronato con entusiasmo a continuare e portare a termine questo progetto. Grazie anche a mio padre, che ho sentito spiritualmente vicino nei momenti difficili. Grazie agli amici, che anche da lontano, mi hanno aiutato a superare gli ostacoli, con un ringraziamento speciale a Nicola. Un doveroso e sentito ringraziamento anche al professor Ernesto Damiani, che mi ha aiutato ad arricchire di contenuti questa tesi, al dott. Fulvio Frati, che mi ha affiancato nel percorso di revisione della stessa con preziosi consigli e concreta disponibilità, ai professori, agli assistenti, ai tutor del dipartimento di Crema per avermi permesso di conseguire questa laurea e un particolare ringraziamento a Sabrina Papini per la sua grande disponibilità.
  • 6.
  • 7. i Abstract Obiettivo della tesi è fornire una serie di guideline (propositive e non comparative) per il processo di certificazione PCI DSS (Payment Card Industry Data Security Standard) di un’organizzazione e dare una descrizione approfondita dello stesso. La scelta dello standard è dettata dal fatto che, pur essendo focalizzato sulle transazioni economiche effettuate con carte di pagamento, è fortemente orientato alla sicurezza del DATO in generale e può essere quindi esteso con facilità ad altri ambiti; inoltre si configura per le aziende come un indispensabile strumento per poter operare nel settore, dal momento che da esso deriva la possibilità di usufruire dei servizi offerti dai circuiti internazionali (i payment brand come VISA e Mastercard) e dai service provider necessari allo svolgimento di tutte le attività di business; infine, la sua corretta applicazione permette di coprire tutti gli ambiti aziendali avendo i requisiti come oggetto TECNOLOGIE, PROCESSI e PERSONE. Le guideline per la corretta applicazione dello standard si basano sull’analisi, effettuata sul campo, delle procedure da seguire durante l’assessment, focalizzando aspetti tecnici, procedurali, di gestione delle risorse umane e di compliance contrapposti alle esigenze di business delle aziende che operano in un mercato altamente concorrenziale. La parte finale è dedicata alle metodologie da adottare per utilizzare la compliance PCI DSS come un framework completo per la gestione della sicurezza informatica in tutti i settori dell’information technology ed in tutti i processi dell’organizzazione, promuovendo una gestione della IT security che non si focalizzi solo su alcune tecnologie o su particolari momenti della vita aziendale, ma che diventi “business as usual”.
  • 8. ii Indice 1. Capitolo 1 ............................................................................................................... 1 1.1 Lo standard PCI DSS.......................................................................................... 1 1.1.1 PCI Security Standard Council................................................................ 1 1.1.2 I payment brands ......................................................................................... 2 1.1.3 Processi di gestione delle transazioni con carte di pagamento.................................................................................................................... 4 1.2 Applicabilità dello standard PCI DSS............................................................ 6 1.2.1 Livelli di certificazione ................................................................................ 6 1.2.1.1 Merchant................................................................................................. 7 1.2.1.2 Service Provider .................................................................................. 23 1.2.2 Relazioni con altri standard PCI ........................................................... 33 1.3 Ruoli....................................................................................................................... 34 1.3.1 PCI SSC (Security Standards Council)................................................ 34 1.3.2 Payment Brands (AmEx, Discover, JCB, MC, VISA)....................... 35 1.3.3 Qualified Security Assessor .................................................................... 35 1.3.4 Internal Security Assessor (ISA)............................................................ 36 1.3.5 Merchant e Service Provider................................................................... 37 1.3.6 Approved Scanning Vendor (ASV)......................................................... 37 1.4 I singoli requisiti dello standard PCI DSS.................................................. 37 1.4.1 Descrizione dei requisiti e delle procedure di test........................... 38 2. Capitolo 2 ............................................................................................................. 40 2.1 Linee guida sulle fasi dell'assessment PCI DSS....................................... 40 2.1.1 Gap Analysis................................................................................................ 41 2.1.2 Scoping.......................................................................................................... 42 2.1.3 Network Segmentation ............................................................................. 44 2.1.4 Prioritized Approach.................................................................................. 46 2.1.5 Remediations............................................................................................... 47 2.1.6 On-site Assessment................................................................................... 48
  • 9. iii 2.1.7 Compensating Controls............................................................................ 50 2.1.8 Report on Compliance .............................................................................. 52 2.1.9 Attestation of Compliance ....................................................................... 52 2.2 Linee guida per la determinazione dello scope......................................... 53 2.2.1 Passi operativi ............................................................................................. 53 2.2.2 Inventario delle risorse coinvolte .......................................................... 60 2.3 Linee guida per la determinazione dei sampling ..................................... 61 2.4 Linee guida per la ricerca di dati dei titolari di carte di pagamento . 62 2.4.1 Use Case per il Data Discovery.............................................................. 64 2.5 Linee guida per la segmentazione della rete ............................................. 69 2.5.1 Use Case per la segmentazione della rete.......................................... 69 2.6 Analisi dei processi e delle persone coinvolte........................................... 74 2.7 Errori comuni nella definizione dello scope PCI DSS............................. 76 2.8 Linee guida sui controlli previsti per ciascun requisito ........................ 77 2.8.1 Tecnologie, procedure, risorse umane e compliance...................... 77 2.8.2 Il software ..................................................................................................... 78 2.8.3 Aspetti di business dell'azienda ............................................................ 80 3. Capitolo 3 ............................................................................................................. 83 3.1 Utilità ed efficacia della certificazione PCI DSS ....................................... 83 3.1.1 Come rendere "possibile" una certificazione ..................................... 84 3.1.2 Linee guida per l’estensione della sicurezza informatica oltre il perimetro di certificazione PCI DSS.............................. 86 3.1.3 Miglioramento continuo della sicurezza informatica...................... 90 3.1.4 Il conflitto di interessi............................................................................... 91 Conclusioni ........................................................................................................................ 98 4. Bibliografia e citazioni ...................................................................................... 99 i. Appendice A: i requisiti PCI DSS 3.0 e le procedure di test............... 102 ii. Appendice B: GANTT di un progetto di assessment PCI DSS ........... 164 iii. Appendice C: Strumento operativo per la raccolta delle evidenze ... 165
  • 10. iv Introduzione Gli standard internazionali e le certificazioni di sicurezza informatica sono spesso viste nel mondo dell’information technology come un complesso ed oneroso impegno a cui dover sottostare per poter continuare a svolgere il proprio business. La realtà aziendale testimonia che la compliance e la sicurezza informatica sono due concetti non completamente sovrapponibili, soprattutto per il fatto che la compliance ha bisogno di una data della sua fotografia, mentre la sicurezza informatica è una pratica da adottare giorno per giorno (business as usual) in ogni processo che coinvolge il settore IT. La complessità dello standard PCI DSS impone un approccio graduale dei requisiti cercando di ottemperare alle loro richieste in un primo tempo in modo ciclico e, una volta raggiunti gli obiettivi di conformità, in modo lineare, cercando di evitare successive reiterazioni su argomenti già trattati in precedenza. Per le aziende che operano nel settore dei pagamenti elettronici effettuati con carte di credito (ma anche di debito, purché si avvalgano dei servizi offerti da circuiti internazionali quali VISA e Mastercard), la certificazione PCI DSS è uno strumento indispensabile per poter usufruire dei servizi offerti da payment brands e service provider già certificati. Obiettivo di questa tesi è proporre delle linee guida che consentano una gestione il più possibile automatizzata del processo di certificazione PCI DSS, sia che si tratti della valutazione di un merchant o di un service provider, descrivere come lo standard possa essere utilizzato per la gestione della sicurezza informatica di dati, processi e persone estendibile a tutti gli ambiti dell’organizzazione ed in continua e costante applicazione (business as usual) e, infine, analizzare le differenze che esistono tra compliance e IT security, evidenziando come una possa essere utile all’altra per poter innalzare concretamente e progressivamente il livello di sicurezza informatica di un’organizzazione che opera sul mercato. Il Capitolo 1 è focalizzato proprio sull’analisi dello standard in tutti i suoi aspetti (ambito di applicazione, attori e ruoli, definizione dello scope, analisi dei singoli requisiti).
  • 11. v Proprio per questo motivo è necessario utilizzare delle linee guida per condurre in modo efficace ed efficiente un assessment PCI DSS, che deve prevedere una fase finale di controllo delle conformità di tutti i requisiti che non superi l’intervallo di tempo di tre mesi. Tale intervallo è valutato come il massimo periodo di tempo in cui, nell’ambito dell’infrastruttura tecnologica di un’azienda, siano assenti modifiche ed aggiornamenti significativi della stessa che possano invalidare le valutazioni già fatte da parte di un QSA (Qualified Security Assessor). Il Capitolo 2 descrive le linee guida proponendo un framework da utilizzare per un assessment PCI DSS e mettendo in relazione aspetti a volte tra loro contrastanti (compliance, IT security, business). Il Capitolo 3 tratta infine della reale utilità ed efficacia della certificazione PCI DSS, considerando le informazioni su cui si concentra (transazioni economiche con l’utilizzo delle carte di pagamento) come sostituibili con altri tipi di informazioni “sensibili” dal punto di vista della sicurezza informatica; l’intento è quello di estendere il framework alla gestione della sicurezza delle informazioni di tutta l’azienda, non solamente per ottenere una certificazione di compliance, ma per innalzare concretamente il livello di sicurezza delle informazioni durante tutti i processi per la loro gestione. Questo è reso possibile dal fatto che lo standard PCI DSS è orientato al DATO attorno al quale ruotano tutti i requisiti per la messa in sicurezza dello stesso; sostituire quindi i dati dei titolari di carte di pagamento con altri tipi di dati che per un’organizzazione sono ritenuti “sensibili” risulta particolarmente facile. Al fine di rendere la trattazione più scorrevole, è necessario prevedere un breve glossario che disambigui le possibili interpretazioni (PCI Security Standards Council, LLC, 2006-2015):  Carta di pagamento: per gli scopi dello standard PCI DSS, è ogni carta o strumento che espone il logo dei membri fondatori del PCI Security Standard Council (American Express, Discover Financial Services, JCB International, MasterCard Worldwide, e Visa, Inc.).  PAN (Primary Account Number): numero unico di ciascuna carta di pagamento che identifica l’issuer e un particolare conto del titolare della carta stessa.
  • 12. vi  CHD (Cardholder Data): nella forma minima i cardholder data consistono nel singolo PAN (Primary Account Number), ma possono anche apparire nella forma di PAN unito ad uno o più dei seguenti dati: nome del titolare della carta di pagamento, data di scadenza e codice di servizio utilizzato per la transazione. Altri dati che sono parte dei CHD sono i SAD (Sensitive Authentication Data).  SAD (Sensitive Authentication Data): informazioni legate alla sicurezza che possono includere informazioni quali Card Validation Code/Values, dati contenuti nelle tracce magnetiche (o quelli equivalenti presenti nei chip), PIN (Personal Identification Number) e PIN Block utilizzati per autenticare i Cardholder e/o autorizzare le transizioni di pagamento.  PIN (Personal Identification Number): numero segreto conosciuto solo al possessore dello stesso ed al sistema che lo deve autenticare. Tipicamente sono utilizzati per gli ATM (Automated Teller Machine da noi conosciuti come “Bancomat”). Un’altro tipo di PIN è quello utilizzato dalle carte di pagamento dove lo stesso sostituisce la firma del titolare.  PIN Block: blocco di dati utilizzato per incapsulare il PIN durante le transazioni ed è composto dal PIN, dalla sua lunghezza e può contenere sottoinsiemi del PAN.
  • 13. Capitolo 1 1 1. Capitolo 1 Lo standard internazionale PCI DSS definisce un framework volto a favorire l’adozione di misure di sicurezza tecnologiche e procedurali per proteggere i dati di titolari di carte di pagamento (CHD) e/o sensitive authentication data (SAD) durante tutti i processi che li coinvolgono (autorizzazioni di pagamento, operazioni di settlement, gestione delle frodi, ecc.). Lo standard è stato sviluppato dal PCI Security Standard Council con l’obiettivo di integrare in un unico programma i singoli standard che ciascun payment brand fondatore (VISA, MasterCard, JCB, Discover ed American Express) già prevede per la gestione sicura dei dati. Esso rappresenta una linea di base, definita nei suoi requisiti, per la certificazione di conformità PCI Data Security Standard di entità che svolgono molteplici ruoli nel processo dei pagamenti elettronici con carte e non intende sostituire leggi e regolamenti che vengono adottate da ogni paese per la sicurezza dei dati personali come, per l’Italia, il Decreto Legislativo sulla privacy 196/2003. 1.1 Lo standard PCI DSS 1.1.1 PCI Security Standard Council Il PCI SSC (Payment Card Industry – Security Standard Council) è un organismo indipendente dai payment brands che ha il compito di definire, diffondere e gestire gli standard PCI in tutto il mondo, non solo il PCI DSS, ma anche gli standard PA-DSS (Payment Application Data Security Standard) per le applicazioni, P2PE (Point-to- Point Encryption) per le trasmissioni cifrate point-to-point, PTS (PIN Transaction Security) per i device utilizzati nei processi di pagamento elettronico con carte ecc. È possibile sintetizzare i compiti del PCI SSC nei seguenti punti:  mantenimento di una lista di FAQ che possono essere consultate da tutti gli operatori per la corretta interpretazione degli standard definiti;
  • 14. Capitolo 1 2  mantenimento della lista degli operatori qualificati in tutto il mondo che hanno la facoltà di condurre e certificare gli assessment previsti dagli standard PCI;  mantenimento di: o una lista di applicazioni o una lista di device o una lista di soluzioni utilizzate per i pagamenti elettronici che hanno superato con successo gli assessment definiti dagli standard PCI;  formazione periodica degli operatori (gli assessors) con la produzione di materiale didattico sia cartaceo che in modalità e-learning ;  diffusione degli standard in tutto il mondo, con l’intento di stimolare la sensibilità sulla sicurezza necessaria per la gestione delle transazioni economiche effettuate con carte di pagamento, sia in presenza di terminali fisici di lettura delle carte (card-present) che per gli acquisti su portali di e- commerce (card-not-present);  organizzazione e gestione dei Community Meetings annuali per discutere degli standard e acquisire feedback per il loro continuo miglioramento. 1.1.2 I payment brands Ognuno dei cinque payment brands mantiene il suo programma di gestione delle conformità rispetto alla sicurezza informatica in base alle proprie politiche di gestione dei rischi. In particolare:  American Express ha sviluppato il proprio programma denominato Data Security Operating Policy;  Discover allo stesso modo ha sviluppato il proprio programma denominato Discover Information Security Compliance;  JCB International ha sviluppato il programma Data Security Program per la sicurezza nella gestione dei dati;  MasterCard ha sviluppato il proprio programma di gestione della sicurezza orientato sia ai dati che alle infrastrutture tecnologiche denominato Site Data Protection;
  • 15. Capitolo 1 3 VISA ha sviluppato due differenti programmi di security compliance, uno per l’Europa e uno per il resto del mondo. In particolare:  Visa Europe ha sviluppato il programma Account Information Security Program che promuove nell’area europea per la gestione della sicurezza e della compliance;  Visa Inc ha invece sviluppato il programma Cardholder Information Security Program che promuove la gestione della compliance in tema di sicurezza informatica in tutto il resto del mondo; Tali programmi di gestione di security compliance sono il riferimento ultimo per la determinazione dei livelli di validazione per la certificazione PCI DSS sia per i merchant che per i service provider. A ciascun livello di validazione (che può essere determinato in modo differente dai singoli programmi dei payment brands) competono dei precisi compiti da assolvere per poter ottenere la compliance PCI DSS. I livelli di validazione sono determinati dagli acquirer (o da un payment brand quando assume anche il ruolo di acquirer) in base ai volumi di transazioni effettuate, basati su un’aggregazione per differente payment brand anche a fronte di differenti acquirer. Tuttavia l’applicazione delle politiche di sicurezza IT dei payment brands può variare in accordo con ciascun brand e/o acquirer i quali devono valutare il corretto livello di validazione, considerando anche che un merchant o un service provider possono avere diverse linee di business o diversi acquirer. I payment brands definiscono anche le tariffe e le multe che devono essere pagate dalle entità che partecipano alla gestione dei processi di transazioni economiche con carte di pagamento; tali multe vengono di solito comminate agli acquirer, che rappresentano l’attore responsabile della compliance PCI DSS di ciascun merchant che utilizza i propri servizi di acquiring, oltre che di ciascun service provider che viene utilizzato per gestire l’intero ciclo delle transazioni con carte di pagamento. Infine la responsabilità dei payment brands riguarda le indagini forensi che si rendono necessarie dopo il verificarsi di incidenti informatici (normalmente denominati Data Breach Incidents) che hanno compromesso la sicurezza di CHD o di SAD.
  • 16. Capitolo 1 4 1.1.3 Processi di gestione delle transazioni con carte di pagamento Tutte le transazioni economiche con carte di pagamento sono gestite (con particolari eccezioni di scarso rilievo) utilizzando gli stessi processi. Prima di descriverli è necessario fare alcune precisazioni sulla terminologia utilizzata (PCI Security Standards Council, LLC, 2006-2015):  cardholder: è il titolare della carta di pagamento utilizzata per le transazioni o comunque una persona fisica autorizzata al suo utilizzo;  issuer: entità che emette la carta di pagamento o che ne supporta l’emissione attraverso i propri issuing services che può includere (in modo non esaustivo) banche e issuing processors;  payment brand: i cosiddetti circuiti internazionali rappresentati da VISA, Mastercard, JCB, Discover ed American Express;  acquirer: entità che stabilisce e mantiene relazioni con merchants per l’accettazione di transazioni con carte di pagamento;  merchant: per gli scopi dello standard PCI DSS, un merchant è definito come un’entità che accetta carte di pagamento che riportano il logo di uno dei cinque membri costituenti il PCI Standard Security Council (American Express, Discover, JCB, MasterCard o VISA) come pagamento di beni e/o servizi. È da notare che un merchant può essere anche un service provider se il servizio richiesto prevede la memorizzazione, l’elaborazione o la trasmissione di cardholder data per conto di altri mercants o service providers. Ad esempio un internet service provider è un merchant che accetta carte di pagamento per la fatturazione mensile, ma è anche un service provider se effettua hosting di merchants o altri clienti. Il processo di autorizzazione per una transazione economica con carte di pagamento prevede che al momento dell’acquisto il merchant riceva un codice di autorizzazione che permette la
  • 17. Capitolo 1 5 conclusione dell’acquisto stesso. I passi dell’autorizzazione sono descritti nella Fig. 1: $ $ $ Cardholder Merchant $ IssuerPayment BrandAcquirer 2 3 4 5 678 Il merchant spedisce il pagamento all’acquirer L’acquirer richiede al network dei payment brands di determinare l’issuer della carta di pagamento Il payment brand determina l’issuer e richiede l’approvazione per l’acquisto L’issuer approva l’acquisto Il payment brand invia l’approvazione dell’acquisto all’aquirer L’acquirer invia l’approvazione dell’acquisto al merchant Il merchant stampa la ricevuta Il cardholder utilizza la carta di pagamento da un merchant 1 Il cardholder completa l’acquisto e ritira la ricevuta 9 Fig. 1: processo di autorizzazione (Fonte: PCI Security Standard Council) Nel processo di clearing l’acquirer e l’issuer si scambiano informazioni contabili sull’acquisto per completare la transazione. I passi previsti dal processo sono descritti nella Fig. 2: $ IssuerPayment BrandAcquirer 1 2 3 45 L’acquirer spedisce le informazioni riguardanti l’acquisto ai payment brands Il payment brand invia le informazioni di acquisto all’issuer L’issuer prepara i dati per l’addebito dell’importo al titolare della carta di pagamento Il payment brand invia notifica di clearing all’acquirer L’acquirer riceve la notifica Fig. 2: Processo di Clearing (Fonte: PCI Security Standard Council) Il termine del processo di pagamento è rappresentato dal processo di settlement. La banca del merchant (rappresentata dall’acquirer) paga il merchant per l’acquisto del cardholder e la banca
  • 18. Capitolo 1 6 del cardholder (rappresentata dall’issuer) addebita l’importo al titolare. Nella Fig. 3 sono descritti i passi del processo:$ $ $ Cardholder Merchant $ Issuer Payment Brand Acquirer 432 Il merchant riceve il pagamento L’acquirer paga il merchant per la vendita effettuata L’issuer tramite Il payment brand spedisce il pagamento all’acquirer L’issuer determina l’acquirer tramite i payment brands L’issuer addebita l’importo dell’acquisto al cardholder 5 1 Fig. 3: Processo di settlement (Fonte: PCI Security Standards Council) 1.2 Applicabilità dello standard PCI DSS Lo standard PCI DSS si applica a tutte le entità coinvolte nei processi di transazione economica con carte di pagamento (merchants, payment processors, payment gateways, acquirers, issuers, service providers e ogni altra entità che memorizza, processa o trasmette dati di titolari di carte di pagamento). Le modalita con cui si applica lo standard ad un’entità (requisiti per i quali garantire la conformità e tipi di reportistica da presentare) sono determinate in base al numero di transazioni annue effettuate utilizzando carte di pagamento: tali numeri individuano il corrispondente livello di certificazione. Ogni payment brand ha il suo proprio set di requisiti di validazione e di reportistica richiesta e a ciascuna entità che intende certificarsi è richiesto il livello di validazione che prevede il maggior numero di requisiti da rispettare, anche se per un differente payment brand basterebbe un livello inferiore. 1.2.1 Livelli di certificazione I livelli di certificazione sono stabiliti in base a differenti soglie nel numero di transazioni effettuate con carte di pagamento in un anno per merchant e per service provider, perché mentre i primi si
  • 19. Capitolo 1 7 limitano generalmente ad accettare e trasmettere CHD, gli ultimi ne effettuano anche elaborazione e, in alcuni casi, memorizzazione. Le informazioni in queste sezioni sono tratte dai siti web dei payment brand (American Express Company, 2015), (JCB Co., Ltd.), (MasterCard, 2015), (Visa Europe, 2015), (DFS Services LLC, 2015). 1.2.1.1 Merchant Per i merchant sono stabiliti 4 livelli di certificazione e ciascun payment brand prevede differenti soglie nel numero delle transazioni con carte di pagamento gestite in un anno. Nelle successive tabelle sono rappresentati i requisiti di validazione e di reportistica previsti per ciascun livello di certificazione in cui si colloca un merchant:  Livelli di certificazione per i Merchant Livelli di certificazione per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 1  Merchant che gestiscono più di 2,5 milioni di transazioni all’anno con carte di pagamento American Express  Qualunque Merchant determinato come Level 1 da parte di American Express  Merchant che gestiscono più di 6 milioni di transazioni all’anno con carte di pagamento Discover  Qualunque Merchant determinato come Level 1 da parte di Discover  Qualunque Merchant che un altro Payement Brand ha determinato essere di Level 1  Merchant che gestiscono più di 1 milione di transazioni all’anno con carte di pagamento JCB  Qualunque Merchant che abbia subito una compromissione
  • 20. Capitolo 1 8 Livelli di certificazione per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 2  Merchant che gestiscono da 50000 a 2,5 milioni di transazioni all’anno con carte di pagamento American Express  Merchant che gestiscono da 1 a 6 milioni di transazioni all’anno con carte di pagamento Discover  Qualunque Merchant determinato come Level 2 da parte di Discover  Merchant che gestiscono meno di 1 milione di transazioni all’anno con carte di pagamento JCB 3  Merchant che gestiscono meno di 50000 transazioni all’anno con carte di pagamento American Express  Merchant che gestiscono da 20000 a 1 milione di transazioni all’anno con carte di pagamento Discover  Qualunque Merchant determinato come Level 3 da parte di Discover  N/A 4  N/A  Tutti i rimanenti Merchant  N/A
  • 21. Capitolo 1 9 Livelli di certificazione per i Merchant (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 1  Merchant che gestiscono più di 6 milioni di transazioni all’anno con carte di pagamento MasterCard e Maestro  Qualunque Merchant che abbia subito una compromissione nell’ultimo anno  Qualunque Merchant determinato come Level 1 da parte di MasterCard  Qualunque Merchant determinato come Level 1 secondo i criteri Visa  Merchant che gestiscono più di 6 milioni di transazioni all’anno con carte di pagamento Visa  Qualunque Merchant che opera a livello mondiale e determinato come Level 1 in una qualunque regione Visa  Merchant che gestiscono più di 6 milioni di transazioni all’anno con carte di pagamento Visa  Qualunque Merchant che ha subito una compromissione nell’ultimo anno a discrezione della regione 2  Merchant che gestiscono da 1 a 6 milioni di transazioni all’anno con carte di pagamento MasterCard e Maestro  Qualunque Merchant determinato come Level 2 secondo i criteri Visa  Merchant che gestiscono da 1 a 6 milioni di transazioni all’anno con carte di pagamento Visa  Merchant che gestiscono da 1 a 6 milioni di transazioni all’anno con carte di pagamento Visa
  • 22. Capitolo 1 10 Livelli di certificazione per i Merchant (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 3  Merchant che gestiscono da 20000 e 1 milione di transazioni all’anno di tipo e-commerce con carte di pagamento MasterCard e Maestro  Qualunque Merchant determinato come Level 3 secondo i criteri Visa  Merchant che gestiscono da 20000 a 1 milione di transazioni all’anno di tipo e-commerce con carte di pagamento Visa  Merchant che gestiscono da 20000 a 1 milione di transazioni all’anno di tipo e-commerce con carte di pagamento Visa 4  Tutti i rimanenti Merchant  Merchant che gestiscono meno di 20000 transazioni all’anno di tipo e- commerce  Tutti gli altri Merchant che gestiscono fino a 1 milione di transazioni all’anno con carte di pagamento Visa  Merchant che gestiscono meno di 20000 transazioni all’anno di tipo e- commerce  Tutti gli altri Merchant che gestiscono fino a 1 milione di transazioni all’anno con carte di pagamento Visa
  • 23. Capitolo 1 11  Requisiti di validazione per i Merchant Requisiti di validazione per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 1  Assessment on-site annuale effettuato da un QSA oppure dal merchant stesso se certificato dal chief executive officer (amministratore delegato), chief fianancial officer (direttore finanziario), chief information security officer (direttore IT security) o dal principal (direttore responsabile)  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Assessment on-site annuale effettuato da un QSA oppure da un auditor interno al merchant  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Assessment on-site annuale effettuato da un QSA  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)
  • 24. Capitolo 1 12 Requisiti di validazione per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 2  Self Assessment Questionnaire annuale effettuato dal merchant stesso e certificato dal chief executive officer (amministratore delegato), chief fianancial officer (direttore finanziario), chief information security officer (direttore IT security) o dal principal (direttore responsabile)  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV) 3  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  N/A
  • 25. Capitolo 1 13 Requisiti di validazione per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 4  N/A Per merchant Discover:  Self Assessment Questionnaire annuale Per merchant acquisiti:  l’acquirer determina i requisiti di validazione sono raccomandati  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  N/A
  • 26. Capitolo 1 14 Requisiti di validazione per i Merchant (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 1  Assessment on-site annuale effettuato da un QSA o da un auditor interno con qualifica di Internal Security Auditor rilasciata dal PCI SSC  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Assessment on-site annuale effettuato da un QSA o da un auditor interno (o da altro staff indipendente) con qualifica di Internal Security Auditor rilasciata dal PCI SSC  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form  Report On Compliance a seguito di un assessment on-site annuale effettuato da un QSA o da un auditor interno (o da altro staff indipendente) con qualifica di Internal Security Auditor rilasciata dal PCI SSC  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliance form 2  Assessment on-site annuale effettuato da un QSA o da un auditor interno con qualifica di Internal Security Auditor rilasciata dal PCI SSC  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form
  • 27. Capitolo 1 15 Requisiti di validazione per i Merchant (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 3  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form 4 La certificazione PCI DSS è richiesta a discrezione dell’acquirer. Quando richiesta prevede:  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Self Assessment Questionnaire annuale solo raccomandato  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV) se applicabile  l’acquirer deve determinare quali siano i requisiti di validazione Per chi effettua solo e- commerce:  sufficiente l’utilizzo di Service Provider che siano compliant PCI DSS oppure  Self Assessment Questionnaire annuale Per gli altri:  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form
  • 28. Capitolo 1 16  Requisiti di reportistica per i Merchant Requisiti di reportistica per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 1 Se compliant  Attestation of Compliance dall’assessment on- site annuale  Attestaion of Scan Compliance o Executive summary degli External Vulnerability Scan trimestrali Se non compliant  Attestation of Compliance che includa la parte di piano d’azione per le remediation  Data di implementazione delle remediation (non oltre i 12 mesi seguenti) Merchant Discover  Attestation of Compliance dall’assessment on- site annuale  Attestation of Compliance che (Se non completamente compliant) includa la parte di piano d’azione per le remediation Mechant acquisiti  Consultare l’acquirer che deve inviare il modulo “Discover Acquirer Portfolio Compliance Status Submission” a Discover due volte all’anno  Nessun requisito per la reportistica richiesto
  • 29. Capitolo 1 17 Requisiti di reportistica per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 2 Se compliant  Attestation of Compliance dal Self Assessment Questionnaire annuale  Attestaion of Scan Compliance o Executive summary degli External Vulnerability Scan trimestrali Se non compliant  Attestation of Compliance che includa la parte di piano d’azione per le remediation  Data di implementazione delle remediation (non oltre i 12 mesi seguenti) Merchant Discover  Attestation of Compliance dal Self Assessment Questionnaire annuale  Attestation of Compliance che (se non completamente compliant) includa la parte di piano d’azione per le remediation Mechant acquisiti  Consultare l’acquirer che deve inviare il modulo “Discover Acquirer Portfolio Compliance Status Submission” a Discover due volte all’anno  Nessun requisito per la reportistica richiesto
  • 30. Capitolo 1 18 Requisiti di reportistica per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 3  Nessun requisito per la reportistica richiesto Merchant Discover  Attestation of Compliance dal Self Assessment Questionnaire annuale  Attestation of Compliance che (se non completamente compliant) includa la parte di piano d’azione per le remediation Mechant acquisiti  Consultare l’acquirer che deve inviare il modulo “Discover Acquirer Portfolio Compliance Status Submission” a Discover due volte all’anno  N/A
  • 31. Capitolo 1 19 Requisiti di reportistica per i Merchant (American Express, Discover, JCB) Livello American Express Discover JCB 4  N/A Merchant Discover  Attestation of Compliance dal Self Assessment Questionnaire annuale  Attestation of Compliance che (se non completamente compliant) includa la parte di piano d’azione per le remediation Mechant acquisiti  Consultare l’acquirer che deve inviare il modulo “Discover Acquirer Portfolio Compliance Status Submission” (oppure il piano d’azione del merchant) a Discover due volte all’anno  N/A
  • 32. Capitolo 1 20 Requisiti di reportistica per i Merchant (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 1  Gli acquirer comunicano trimestralmente a MasterCard lo stato dei propri merchant  Il MasterCard Global Compliance Program prescrive che ogni merchant non conforme comunichi ai propri acquirer lo stato di compliance e lo stato di avanzamento lavori per il completamento delle remediation utilizzando il tool fornito dal PCI SSC denominato “Prioritized Approach”  L’acquirer per ogni merchant comunica due volte all’anno lo stato di compliance o non compliance  Attestation of Compliance dall’assessment on- site annuale  Su richiesta gli acquirer devono fornire anche una copia del Report on Compliance dei merchant  L’acquirer per ogni merchant comunica trimestralmente lo stato di compliance o non compliance  Attestation of Compliance dall’assessment on- site annual dei merchant  Su richiesta gli acquirer devono fornire anche una copia del Report on Compliance dei merchant incluse le Attestation of Scan Compliance trimestrali
  • 33. Capitolo 1 21 Requisiti di reportistica per i Merchant (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 2  Gli acquirer comunicano trimestralmente a MasterCard lo stato dei propri merchant  Il MasterCard Global Compliance Program prescrive che ogni merchant non conforme comunichi ai propri acquirer lo stato di compliance e lo stato di avanzamento lavori per il completamento delle remediation utilizzando il tool fornito dal PCI SSC denominato “Prioritized Approach”  L’acquirer per ogni merchant comunica due volte all’anno lo stato di compliance o non compliance  Attestation of Compliance dall’assessment on- site annuale  Su richiesta gli acquirer devono fornire anche una copia del Self Assessment Questionnaire dei merchant  L’acquirer per ogni merchant comunica trimestralmente lo stato di compliance o non compliance  Su richiesta gli acquirer devono fornire anche Self Assessment Questionnaire e Attestation of Compliance dei merchant
  • 34. Capitolo 1 22 Requisiti di reportistica per i Merchant (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 3  Gli acquirer comunicano trimestralmente a MasterCard lo stato dei propri merchant  Il MasterCard Global Compliance Program prescrive che ogni merchant non conforme comunichi ai propri acquirer lo stato di compliance e lo stato di avanzamento lavori per il completamento delle remediation utilizzando il tool fornito dal PCI SSC denominato “Prioritized Approach”  L’acquirer per ogni merchant comunica due volte all’anno lo stato di compliance o non compliance  L’acquirer per ogni merchant comunica trimestralmente lo stato di compliance o non compliance  Su richiesta gli acquirer devono fornire anche Self Assessment Questionnaire e Attestation of Compliance dei merchant 4  Nessun requisito per la reportistica richiesto  Requisiti definiti dagli acquirer  L’acquirer per ogni merchant comunica trimestralmente lo stato di compliance o non compliance  Su richiesta gli acquirer devono fornire anche Self Assessment Questionnaire e Attestation of Compliance dei soli merchant che effettuano e- commerce
  • 35. Capitolo 1 23 1.2.1.2 Service Provider Anche per i service provider sono stabiliti diversi livelli di certificazione e ciascun payment brand prevede differenti soglie nel numero delle transazioni con carte di pagamento gestite in un anno. I service provider sono classificati in alternativa anche per tipo. Ad esempio JCB considera service provider tutte le terze parti che assumono il ruolo di processor di transazioni effettuate con carte di pagamento a prescindere dai livelli. American Express è l’unico payment brand a prevedere 3 livelli, mentre Discover MasterCard, Visa Inc e Visa Europe ne prevedono solo 2. Nelle successive tabelle sono rappresentati i requisiti di validazione e di reportistica previsti per ciascun livello di certificazione in cui si colloca un service provider:  Livelli di certificazione per i Service Provider Livelli di certificazione per i Service Provider (American Express, Discover, JCB) Livello American Express Discover JCB 1  Service Provider che gestiscono più di 2,5 milioni di transazioni all’anno con carte di pagamento American Express  Qualunque Service Provider determinato come Level 1 da parte di American Express  Service Provider che gestiscono più di 300000 transazioni all’anno con carte di pagamento Discover  Qualunque Service Provider determinato come Level 1 da parte di Discover  Tutte le entità identificate come TPP (Third Party Processors) a prescindere dal numero di transazioni gestite 2  Service Provider che gestiscono da 50000 a 2,5 milioni di transazioni all’anno con carte di pagamento American Express  Service Provider che gestiscono meno di 300000 transazioni all’anno con carte di pagamento Discover  N/A
  • 36. Capitolo 1 24 Livelli di certificazione per i Service Provider (American Express, Discover, JCB) Livello American Express Discover JCB 3  Service Provider che gestiscono meno di 50000 transazioni all’anno con carte di pagamento American Express  N/A  N/A Livelli di certificazione per i Service Provider (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 1  Entità identificate come TPP (Third Party Processors) a prescindere dal numero di transazioni gestite  Entità identificate come Data Store Entities (DSE) che gestiscono più di 300000 transazioni all’anno con carte di pagamento MasterCard e Maestro  Qualunque TPP o DSE che abbia subito una compromissione nell’ultimo anno  Tutti i VisaNet Payment Processors  Service Provider che gestiscono più di 300000 transazioni all’anno con carte di pagamento Visa  Tutti i Visa System Processors  Service Provider che gestiscono più di 300000 transazioni all’anno con carte di pagamento Visa 2  Tutte le entità identificate come Data Store Entities (DSE) che gestiscono meno di 300000 transazioni all’anno con carte di pagamento MasterCard e Maestro  Service Provider che gestiscono meno di 300000 transazioni all’anno con carte di pagamento Visa  Service Provider che gestiscono meno di 300000 transazioni all’anno con carte di pagamento Visa
  • 37. Capitolo 1 25  Requisiti di validazione per i Service Provider Req. di validazione per i Service Provider (American Express, Discover, JCB) Livello American Express Discover JCB 1  Assessment on-site annuale effettuato da un QSA oppure dal Service Provider stesso se certificato dal chief executive officer (amministratore delegato), chief fianancial officer (direttore finanziario), chief information security officer (direttore IT security) o dal principal (direttore responsabile)  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Al di fuori dell’area del Nord America è necessario consultare American Express per la corretta classificazione  Assessment on-site annuale effettuato da un QSA  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Assessment on-site annuale effettuato da un QSA  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)
  • 38. Capitolo 1 26 Req. di validazione per i Service Provider (American Express, Discover, JCB) Livello American Express Discover JCB 2  Self Assessment Questionnaire annuale effettuato dal Service Provider stesso e certificato dal chief executive officer (amministratore delegato), chief fianancial officer (direttore finanziario), chief information security officer (direttore IT security) o dal principal (direttore responsabile)  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Tutti i Service Provider non compliant devono presentare un piano d’azione Discover completo per la realizzazione delle remediations  N/A 3  Self Assessment Questionnaire annuale (fortemente raccomandato)  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV) (fortemente raccomandato)  N/A  N/A
  • 39. Capitolo 1 27 Req. di validazione per i Service Provider (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 1  Assessment on-site annuale effettuato da un QSA  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV) VisaNet Processor e Service Provider:  Assessment on-site annuale effettuato da un QSA con produzione di un Report on Compliance (ROC)  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form  Inclusione nella Global List di Serrvice Provider certificati PCI DSS Service Provider (Member Agent):  Report On Compliance dopo assessment on-site di un QSA  External Vulnerability Scan Assessment trimestrale effettuato da un ASV  Attestation of Compliance form  Registrazione come Member Agent da parte di un Visa Europe Member con Agent Registration Designation form (ARD)  Inclusione nella Visa Europe List di Serrvice Provider certificati PCI DSS Merchant Agent:  Scope of Audit form compilata da un QSA  External Vulnerability Scan Assessment non più vecchio di 90 giorni (ASV)  Attestation of Compliace form
  • 40. Capitolo 1 28 Req. di validazione per i Service Provider (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 2  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Tutti i Service Provider non compliant devono presentare un piano d’azione MasterCard completo per la realizzazione delle remediations  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment trimestrale effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form Service Provider (chiamati anche Member Agent):  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment non più vecchio di 90 giorni effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliance form  Registrazione come Member Agent da parte di un Visa Europe Member tramite una Agent Registration Designation form (ARD) Merchant Agent:  Self Assessment Questionnaire annuale  External Vulnerability Scan Assessment non più vecchio di 90 giorni effettuato da un Approved Scanning Vendor (ASV)  Attestation of Compliace form
  • 41. Capitolo 1 29  Requisiti di ri-validazione per i Service Provider Requisiti di ri-validazione per i Service Provider (American Express, Discover, JCB) American Express Discover JCB  Tutta la procedura per la validazione della compliance è annuale  Tutta la procedura per la validazione della compliance è annuale in base alla data indicata sulla Attestaion of Compliance  Necessario contattare JCB MasterCard Visa Inc. Visa Europe  Tutta la procedura per la validazione della compliance è annuale  Il QSA deve produrre e consegnare a MasterCard la PCI DSS Attestation of Compliance for Onsite Assessment – Service Provider form  I Report on Compliance non sono accettati  Una nuova AOC deve essere fornita prima della scadenza della precedente pena la decurtazione dalla lista dei service provider PCI DSS compliant presente sul sito web MasterCard  Tutta la procedura per la validazione della compliance è annuale in base alla data di accettazione del Report on Compliance  Passata la data di scadenza della compliance precedente il service provider comparirà in colore giallo nella lista di Serrvice Provider certificati PCI DSS per un massimo di 60 giorni e in colore rosso per un massimo di altri 30 giorni dopodiché scomparirà dalla lista Service Provider (chiamati anche Member Agent):  Tutta la procedura per la validazione della compliance è annuale in base alla data di accettazione del Report on Compliance  Passata la data di scadenza della compliance precedente il service provider comparirà in colore giallo nella lista di Serrvice Provider certificati PCI DSS per un massimo di 60 giorni e in colore rosso per un massimo di altri 30 giorni dopodiché scomparirà dalla lista Merchant Agent:  Tutta la procedura per la validazione della compliance deve essere ripetuta entro 60 giorni dalla scadenza del ROC/SAQ
  • 42. Capitolo 1 30  Requisiti di reportistica per i Service Provider Requisiti di reportistica per i Service Provider (American Express, Discover, JCB) Livello American Express Discover JCB 1 Se compliant  Attestation of Compliance dall’assessment on- site annuale  Attestaion of Scan Compliance o Executive summary degli External Vulnerability Scan trimestrali Se non compliant  Attestation of Compliance che includa la parte di piano d’azione per le remediation  Data di implementazione delle remediation (non oltre i 12 mesi seguenti)  Attestation of Compliance dall’assessment on- site annuale  Attestation of Compliance che (se non completamente compliant) includa la parte di piano d’azione per le remediation  Nessun requisito per la reportistica richiesto
  • 43. Capitolo 1 31 Requisiti di reportistica per i Service Provider (American Express, Discover, JCB) Livello American Express Discover JCB 2 Se compliant  Attestation of Compliance dal Self Assessment Questionnaire annuale  Attestaion of Scan Compliance o Executive summary degli External Vulnerability Scan trimestrali Se non compliant  Attestation of Compliance che includa la parte di piano d’azione per le remediation  Data di implementazione delle remediation (non oltre i 12 mesi seguenti)  Attestation of Compliance dal Self Assessment Questionnaire annuale  Attestation of Compliance che (se non completamente compliant) includa la parte di piano d’azione per le remediation  N/A 3  Nessun requisito per la reportistica richiesto  N/A  N/A
  • 44. Capitolo 1 32 Requisiti di reportistica per i Service Provider (MasterCard, Visa Inc., Visa Europe) Livello MasterCard Visa Inc. Visa Europe 1  Attestation of Compliance dall’assessment on- site annuale  MasterCard non accetta né revisiona Report on Compliance  Attestation of Compliance che includa la parte di piano d’azione per le remediation solo se non completamente compliant e solo se si tratta di una prima registrazione Third Party Agents  Attestation of Compliance dall’assessment on- site annuale VisaNet Processor  Attestation of Compliance dall’assessment on- site annuale  Report on Compliance completo Member Agents  Attestation of Compliance dall’assessment on- site annual  QSA confirmation form (sito Visa) 2  Attestation of Compliance dal Self Assessment Questionnaire annuale  Attestation of Compliance che includa la parte di piano d’azione per le remediation solo se non completamente compliant e solo se si tratta di una prima registrazione Third Party Agents  Attestation of Compliance dall’assessment on- site annuale VisaNet Processor  Attestation of Compliance dall’assessment on- site annuale  Report on Compliance completo Member Agents  Attestation of Compliance dall’assessment on- site annual  QSA confirmation form (sito Visa)
  • 45. Capitolo 1 33 1.2.2 Relazioni con altri standard PCI Il PCI SSC ha tra i suoi compiti la responsabilità di definire e diffondere anche altri standard legati alla sicurezza informatica. Tali standard possono essere legati alla certificazione PCI DSS principalmente per il fatto che la loro applicazione può renderne più facile il percorso. Di seguito si presenta un sintetico elenco degli stessi con una breve descrizione:  PA-DSS Payment Application Data Security Standard (PCI Security Standards Council, LLC, 2006 - 2015): o la certificazione PA-DSS è rivolta ai software vendor per facilitare la compliance PCI DSS dei propri clienti; o è applicabile solamente a software di terze parti che memorizzano, elaborano o trasmettono CHD come parte del processo di Autorizzazione e/o di Settlement; o per le applicazioni che risiedono su terminali PCI PTS Approved Point of Interaction, la compliance può essere una combinazione di caratteristiche hardware (del POI Point of Interaction che può essere un terminale POS) e software (ossia l’applicazione stessa); o tale certificazione non è applicabile a sistemi personalizzati, come un’applicazione sviluppata per conto di un unico cliente o comunque che ha subito pesanti personalizzazioni; o le applicazioni candidate alla PA-DSS devono essere quelle cosiddette Off the Shelf che non prevedono pre- installazioni personalizzate da parte dei vendors; o infine, nonostante ne faciliti il percorso, un’applicazione certificata PA-DSS non garantisce la compliance PCI DSS;  P2PE (Point-to-Point Encryption) (PCI Security Standards Council, LLC, 2006 - 2015): o applicabile a soluzioni che assicurano la corretta cifratura dal POI alle P2PE validated applications; o garantisce la corretta gestione dei device, delle cifrature, delle chiavi; o riduce il perimetro di certificazione PCI DSS dei CDE (CardHolder Data Environment) dei merchant; o non garantisce ma facilita la compliance PCI DSS;
  • 46. Capitolo 1 34  PTS (PIN Transaction Security) (PCI Security Standards Council, LLC, 2006 - 2015): o rivolta ai terminali (o POI Point of Interaction) utilizzati per i pagamenti card-present; o definisce i requisiti per la compliance PCI dei POI in base a caratteristiche fisiche, funzionali e di gestione (lifecycle); o non garantisce ma facilita la compliance PCI DSS;  Card Production (PCI Security Standards Council, LLC, 2006 - 2015): o rivolta a sistemi e processi di business legati alla personalizzazione delle carte di pagamento (produzione, generazione PIN, trasmissione PIN); o definisce una serie di requisiti “logici” (ruoli, policy, procedure, data security e network security); o definisce una serie di requisiti “fisici” (personale, edifici, procedure, monitoraggio). 1.3 Ruoli Lo standard PCI DSS prevede l’esistenza di una serie di attori, ciascuno con il proprio ruolo. 1.3.1 PCI SSC (Security Standards Council) Il PCI Security Standard Council è responsabile per la redazione e l’aggiornamento degli standard di sicurezza legati alla Payment Card Industry (PCI DSS, PA-DSS, PTS, P2PE, Card Production). È responsabilità del Council definire i requisiti di qualificazione per gli assessors (QSA, PA-QSA, ASV e ISA) che operano in tutto il mondo per l’ottenimento della compliance da parte delle entità che ne fanno richiesta. Inoltre certifica le aziende che svolgono servizi di PCI DSS assessment, PA-DSS assessment (le QSA Companies) e ASV vulnerabilities assessment (Approved Scanning Vendors) e mantiene le liste degli stessi sul proprio sito. Compito del PCI SSC è anche mantenere aggiornate una serie di liste che contengono:
  • 47. Capitolo 1 35  l’elenco delle applicazioni certificate PA-DSS;  l’elenco dei device certificati PTS;  l’elenco delle soluzioni certificate P2PE. Altre responsabilità sono revisionare a campione report (ROC, ROV, P-ROV e ASV scan) che vengono redatti dagli assessors, erogare il training per QSA, PA-QSA, ASV, ISA, QIR, PCIP oltre a un più generico awareness training accessibile attraverso diversi canali, redigere linee guida su specifiche tecnologie utilizzate nei processi di transazioni economiche con l’uso di carte di pagamento e infine promuovere la messa in sicurezza di tali processi di pagamento a livello globale. 1.3.2 Payment Brands (AmEx, Discover, JCB, MC, VISA) Un fondamentale attore della Payment Card Industry è il payment brand. I payment brands, oltre ad essere parte costitutiva del PCI Security Standards Council sono responsabili dello sviluppo dei propri programmi di compliance (da cui peraltro derivano nella sostanza i requisiti dello standard PCI DSS), definiscono multe e sanzioni per le non-compliance rilevate nei confronti di acquirer che, ad esempio, non hanno prodotto evidenze per la compliance dei propri merchant, approvano i criteri di qualificazione per le aziende QSA, PA-QSA e ASV, accettano la documentazione di certificazione da parte delle aziende QSA, PA-QSA e ASV (oltre che dai loro dipendenti qualificati come tali), forniscono feedback al PCI SSC per le performances di QSA, PA-QSA e ASV ed infine sono l’entità preposta ad effettuare le indagini forensi a fronte di incidenti informatici che hanno generato perdita o compromissione di dati. 1.3.3 Qualified Security Assessor Il QSA è il professionista (o il gruppo di professionisti) che definisce e valida lo scope degli assessment presso le entità candidate per l’ottenimento della certificazione PCI DSS. Infatti il QSA effettua concretamente gli assessment PCI DSS presso le sedi dei merchant e dei service provider per tutta la durata di tempo necessaria (che viene stimata in non più di 3 mesi
  • 48. Capitolo 1 36 considerando che sia questo il tempo massimo in cui non avvengano modifiche sostanziali dell’ecosistema). Inoltre il QSA verifica le informazioni fornite da merchant e service provider valutandole in modo indipendente e sulla base di evidenze che possano comprovare le proprie conclusioni. Nel caso in cui siano rilevate delle non conformità che rendono necessari dei rimedi, il QSA è incaricato di validare le soluzioni adottate considerando anche l’applicabilità di eventuali controlli compensativi a fronte di requisiti non rispettati per giustificabili difficoltà tecnologiche o economiche. Non essendo possibile, in alcuni casi, procedere con un esame di tutto il perimetro afferente la certificazione, il QSA stabilisce, ove richiesto dallo standard, i criteri di sampling da utilizzare durante l’assessment. Infine il QSA redige i report per la compliance, che dovranno essere valutati dal sistema di qualità interno all’azienda QSA per cui l’assessor opera e che saranno poi spediti ai payment brands che li richiedono. 1.3.4 Internal Security Assessor (ISA) L’Internal Security Assessor è il corrispondente di un QSA all’interno di un’organizzazione che intende ottenere la certificazione PCI DSS. Egli definisce e valida lo scope degli assessment oltre a effettuare concretamente gli assessment PCI DSS presso la propria azienda, laddove previsto dai requisiti di validazione da parte dei payment brands descritti al paragrafo 1.2.1. All’interno della propria azienda fornisce supporto per i processi di compliance, verifica le informazioni valutandole in modo indipendente, valida le soluzioni adottate a fronte di rilevazione di non conformità e valuta eventuali controlli compensativi a fronte di requisiti non rispettati per giustificabili difficoltà tecnologiche o economiche. Stabilisce inoltre, ove richiesto dallo standard, i criteri di sampling da utilizzare durante l’assessment ed infine, laddove previsto dai requisiti di validazione da parte dei payment brands descritti al paragrafo 1.2.1, redige i report per la compliance.
  • 49. Capitolo 1 37 1.3.5 Merchant e Service Provider Merchant e service provider sono le entità a cui è rivolto lo standard PCI DSS. Essi sono tenuti a conoscere gli standard PCI e le politiche di sicurezza determinate dai singoli payment brand verso i quali dimostrano, attraverso l’attestazione di conformità (AOC Attestation of Compliance), la propria compliance. Dal momento che gli standard subiscono un aggiornamento a cadenze ben determinate (per la PCI DSS il ciclo di validità di una versione è di tre anni salvo aggiornamenti straordinari di alcune parti) merchant e service provider sono tenuti anche ad essere aggiornati sulle modifiche agli stessi. Un loro preciso dovere è quello di fornire la propria AOC a acquirer o direttamente ai payment brand. Infine è loro responsabilità quella di garantire il mantenimento della compliance durante tutto il periodo di attività e non solo nel periodo di certificazione. 1.3.6 Approved Scanning Vendor (ASV) Gli ASV sono rappresentati dalle organizzazioni titolate ad effettuare i Vulnerability Scan esterni secondo le regole stabilite dallo standard PCI DSS. Nello svolgimento del loro lavoro, scandagliano tutti i range IP e i domini che sono esposti su reti pubbliche forniti dalle entità per cui effettuano il servizio, determinando, in accordo con i clienti, anche eventuali aggiunte di indirizzi IP rilevati. Al termine della fase di scan, gli ASV forniscono un report dettagliato sui risultati degli stessi e ne certificano la compliance con lo standard PCI DSS. 1.4 I singoli requisiti dello standard PCI DSS I requisiti dello standard PCI DSS prevedono due principali tipi di raggruppamento: i goals e i requirements. Nella tabella seguente sono descritti brevemente tali raggruppamenti:
  • 50. Capitolo 1 38 Goals Req Descrizione Sviluppo e gestione di sistemi e reti sicure 1 Installare e gestire una configurazione firewall per proteggere i dati dei titolari di carta 2 Non utilizzare valori predefiniti del fornitore per le password di sistema e altri parametri di protezione Protezione dei dati dei titolari di carta 3 Proteggere i dati dei titolari di carta memorizzati 4 Cifrare i dati dei titolari di carta trasmessi su reti aperte e pubbliche Utilizzare un programma per la gestione delle vulnerabilità 5 Proteggere tutti i sistemi dal malware e aggiornare regolarmente i programmi o il software antivirus 6 Sviluppare e gestire sistemi e applicazioni sicure Implementazione di rigide misure di controllo dell’accesso 7 Limitare l’accesso ai dati dei titolari di carta solo se effettivamente necessario 8 Individuare e autenticare l’accesso ai componenti di sistema 9 Limitare l’accesso fisico ai dati dei titolari di carta Monitoraggio e test delle reti regolari 10 Registrare e monitorare tutti gli accessi a risorse di rete e dati dei titolari di carta 11 Eseguire regolarmente test dei sistemi e processi di protezione. Gestione di una politica di sicurezza delle informazioni 12 Gestire una politica che garantisca la sicurezza delle informazioni per tutto il personale. 1.4.1 Descrizione dei requisiti e delle procedure di test Ciascun requisito dello standard PCI DSS prevede che siano eseguite delle procedure di verifica da parte di un QSA per poter determinare la compliance di sistemi, processi e documentazione che sono compresi nel Cardholder Data Environment (CDE). Tutte le evidenze, i controlli, le interviste che sono richieste da ciascun requisito devono essere considerate nella loro interezza, cioè un requisito non può risultare “parzialmente conforme”, altrimenti verrebbe considerato come una non conformità. In alcuni casi ci possono essere degli ambienti in cui alcuni requisiti possono risultare non applicabili e tale condizione deve
  • 51. Capitolo 1 39 essere in ogni caso verificata dal QSA che effettua l’assessment e che deve giustificare lo stato di non applicabilità. Per fare un esempio ci possono essere organizzazioni che non prevedono l’utilizzo di reti wireless: in questi casi il QSA deve verificare e certificare che nessuna rete wireless è utilizzata dall’azienda inserendo tali motivazioni in ogni requisito che richieda delle procedure di test che coinvolgono tale tecnologia. Diverso è il trattamento dei requisiti che possono essere definiti come “not tested”, perché tale stato è attribuibile solamente ai requisiti che possono essere completamente esclusi dalle procedure di test. Un esempio è costituito dai requisiti che un acquirer esclude dalla richiesta di compliance di un proprio merchant oppure quando un’organizzazione ha la necessità di validare un nuovo sistema di sicurezza che coinvolge solo un certo numero di requisiti (ad esempio un nuovo sistema di crittografia che richiede la verifica dei soli requisiti 2, 3 e 4) Nell’Appendice A sono riportati tutti i requisiti dello standard PCI DSS versione 3.0 con le corrispondenti procedure di test.
  • 52. Capitolo 2 40 2. Capitolo 2 In questo capitolo si descriveranno le linee guida da seguire per effettuare un assessment PCI DSS, con l’obiettivo di stabilire una serie di passi operativi che consentiranno l’automatizzazione (anche se non completa) del processo. 2.1 Linee guida sulle fasi dell'assessment PCI DSS Le fasi di un assessment PCI DSS non sono determinate con esattezza dal PCI SSC ed ogni QSA può definire un proprio progetto con l’unico vincolo di produrre la documentazione richiesta (Report on Compliance, Attestation of Compliance e, per Visa, la Scope of Audit form). Una proposta sulle fasi dell’assessment è il principale obiettivo del presente lavoro. I punti seguenti, insieme al diagramma a blocchi rappresentato nella Fig. 4, la sintetizzano, mentre i successivi paragrafi ne approfondiscono gli aspetti:  Gap Analysis  Scoping  Network Segmentation  Prioritized Approach  Remediations  On-site Assessment  Compensating Controls  Report on Compliance  Attestation of Compliance
  • 53. Capitolo 2 41 Gap Analysis Descrizione dell’attività svolta dall’entità Definizione di un diagramma di network ad alto livello Network Segmentation Report On Compliance Compensating Controls Scoping Implementazione Remediations Prioritized Approach On-Site Assessment (check requisiti) Attestation Of Compliance Sì Determinazione dello scope Analisi della riduzione dello scope Definizione del network diagram dettagliato Determinazione dei flussi di CHD e SAD Dipartimenti che necessitano di CHD Segmenti rete che memorizzano CHD Segmenti rete che elaborano/ trasmettono CHD Segmenti rete collegati al CDE Segmenti rete dei CLIENT collegati Altri segmenti di rete Censimento FW, Switch, Router... Config. FW, Switch, Router Verifica remediation Inplementazion e Remediations No Censimento delle basi di dati collegate alle applicazioni Censimento di tutti gli host (IP address) su cui sono installate applicazoni e database Censimento di tutti i sistemi che si connettono agli host del punto precedente Censimento delle parti di infrastruttura in outsourcing Censimento di tutti i segmenti di rete su cui si attestano host e client del punto 3 e 4 Censimento dei sistemi operativi coinvolti di tutti i sistemi del CDE Censimento reti wireless Censimento di tutti gli apparati di rete per gestione del traffico dei segmenti di rete Disegno dell’intera rete Censimento collegamenti con reti esterne (Internet, VPN ...) e relative DMZ Censimento ATM/POI Disegno flussi di CHD da e verso l’esterno dell’entità e sulle reti interne Censimento di tutti i sistemi non elettronici di gestione dei CHD (carta o altro) Censimento dei processi organizzativi per la gestione dei CHD Censimento dipartimenti e persone Censimento di tutte le applicazioni che gestiscono CHD Fasi dell’assessment PCI-DSS Remediation necessarie? Sì Remediation necessarie? No Figura 4: Fasi dell'assessment PCI DSS 2.1.1 Gap Analysis Durante la fase di Gap Analysis uno dei compiti da eseguire consiste nella redazione di una descrizione dettagliata dell’attività svolta dall’entità che si sta certificando, mettendo in risalto quali siano i servizi offerti che sono sottoposti a verifica di conformità da parte del QSA. All’interno di tale sommario è necessario specificare nel modo più preciso possibile come e perché sono memorizzati, elaborati o trasmessi i CHD, quali tipi di pagamenti sono gestiti (MOTO, e-commerce, card-present, card-not-present) ed infine specificare quali sono le relazioni con altre entità con cui i CHD sono condivisi. La fase descrittiva deve anche prevedere la definizione di un diagramma ad alto livello che contenga in maniera schematica e
  • 54. Capitolo 2 42 facilmente comprensibile l’architettura complessiva dell’ambiente sottoposto ad assessment, tutte le sedi dell’entità con la rappresentazione dei sistemi chiave dell’ambiente ed i rispettivi confini, le connessioni inbound e outbound tra i sistemi appartenenti al Cardholder Data Environment (CDE) e quelli delle altre zone, la chiara rappresentazione di sistemi critici quali apparati di rete preposti al controllo del traffico (firewall, router, IDS/IPS), Point of Sales (POS), database server, application server, web server, DNS, authentication server, wireless access point e tutto ciò che è ritenuto rilevante per la certificazione stessa. Nella Fig. 5 è rappresentato un esempio di diagramma ad alto livello: Fig. 5: Esempio di diagramma di rete ad alto livello 2.1.2 Scoping La fase di Scoping è probabilmente la più delicata, quella che richiede la maggior cura e precisione, proprio perché è il momento in
  • 55. Capitolo 2 43 cui si determina il perimetro, sia tecnologico che di processi e persone, che costituirà il Cardholder Data Environment. L’estrema importanza di questa fase è determinata dal fatto che in primo luogo essa identifica con precisione quali sono le risorse che memorizzano, processano o trasmettono dati di titolari di carte di pagamento e successivamente circoscrive l’applicabilità di tutti i requisiti dello standard PCI DSS alle sole risorse individuate. Un errore in questa fase comprometterebbe tutto il processo di certificazione, costringendo a un riciclo dello stesso ove, in una fase successiva, venissero scoperti nuovi asset da inserire nel perimetro. Il compito principale dell’entità sottoposta alla fase di assessment PCI DSS, per essere sufficientemente sicura di poter conseguire la certificazione, è quello di adottare tutte le tecniche messe a disposizione, sia dal punto di vista tecnologico che organizzativo, per ridurre il perimetro di certificazione e, di conseguenza, lo sforzo richiesto per essere conforme. La riduzione del perimetro di certificazione può essere ottenuta, per esempio, segregando i sistemi che gestiscono i dati di titolari di carte di pagamento con la tecnica della segmentazione della rete, con l’obiettivo di fare in modo che chi non ha bisogno di entrare in contatto con tali dati, sia posto al di fuori del perimetro di certificazione e quindi non obbligato a rispettare i requisiti di compliance dello standard PCI DSS, anche se una buona pratica di gestione della sicurezza dei sistemi IT consiglierebbe di farlo. Pertanto al termine della fase di Scoping è necessario definire un diagramma di network dettagliato, contenente, per ciascuna area individuata nel diagramma di alto livello durante la fase di Gap Analysis, i sistemi che sono da considerare in perimetro con i collegamenti che ci sono tra essi, nonché i flussi di dati di titolari di carte di pagamento che insistono su tale ambiente. Nella Fig. 6 è rappresentato un esempio di come il diagramma di alto livello precedentemente descritto possa essere specificato per determinare lo scope della certificazione.
  • 56. Capitolo 2 44 Fig. 6: Esempio di diagramma di rete dettagliato Nel paragrafo 2.2 sono meglio dettagliati i singoli passi da effettuare per la determinazione del perimetro di certificazione. 2.1.3 Network Segmentation La segmentazione della rete è il primo e più importante strumento che può essere utilizzato per ottenere una effettiva riduzione del perimetro di certificazione PCI DSS. Attraverso di essa è possibile escludere interi rami d’azienda partendo dal presupposto che tale suddivisione rispecchi anche un’effettiva separazione delle mansioni (separation of duties) dal punto di vista organizzativo. Segmentare una rete non è di per se sufficiente a garantire una riduzione dello scope: è necessario che il traffico tra i vari segmenti sia controllato da componenti come firewall, router o switch che, attraverso le regole definite all’atto della configurazione degli stessi o attraverso la definizione di Access Control List, permettano o impediscano le comunicazioni, con lo scopo di segregare i segmenti di
  • 57. Capitolo 2 45 rete che dovranno essere sottoposti alla certificazione PCI DSS dagli altri segmenti che non saranno obbligati ad essere conformi ai requisiti, nonostante sia fortemente consigliato farlo. Per poter implementare una effettiva segregazione dell’ambiente sottoposto alle regole dello standard PCI DSS, è innanzitutto necessario determinare quali siano i flussi di dati di titolari di carte di pagamento tra i segmenti della rete. Contemporaneamente alla determinazione dei flussi, si individuano i dipartimenti dell’azienda che hanno la necessità di gestire questo tipo di dati, verificando quali di essi abbiano un’effettiva titolarità ad accedervi e, di conseguenza, restringendo il perimetro tecnologico interessato dalla certificazione. Una volta stabilito quali siano i flussi e i dipartimenti compresi nel perimetro, si determinano con precisione quali siano i segmenti di rete da includervi, per poter procedere alla conseguente configurazione (se non già effettuata) degli apparati di controllo del traffico. Si può iniziare dei segmenti di rete su cui sono attestati i sistemi che effettuano memorizzazione di CHD e/o SAD come ad esempio database server e file server. Si procede quindi con la determinazione dai segmenti di rete su cui si attesteranno i sistemi che effettuano elaborazione o trasmissione di CHD e/o SAD senza necessariamente memorizzarli (ad esempio quelli si cui insistono gli application server). Successivamente si determinano i segmenti di rete su cui si attestano i server che necessitano di un collegamento col Cardholder Data Environment (DNS, Authentication server, Log server, Monitoring server, Antivirus server, Proxy server, ecc). I passi successivi riguardano la definizione dei segmenti di rete su cui si attestano i client che necessitano di un collegamento con i server precedentemente individuati (siano essi collegamenti wired che wireless), di tutti gli altri segmenti di rete dell’azienda che non hanno interazioni dirette con il CDE e quindi dei componenti preposti al controllo del traffico (firewall, switch/router) tra i segmenti di rete individuati. Infine si procede con la configurazione dei sistemi di controllo del traffico, oppure con il controllo delle configurazioni stesse laddove siano già state implementate.
  • 58. Capitolo 2 46 2.1.4 Prioritized Approach Un valido strumento per poter effettuare un primo ciclo dell’assessment ad un livello più alto è costituito dal foglio excel fornito direttamente dal PCI Security Standards Council denominato Prioritized Approach. Tale strumento è utilizzabile soprattutto per i merchant, in quanto la riorganizzazione dei requisiti in base ad un criterio di priorità diverso dalla semplice sequenza degli stessi, permette di ottenere l’accettazione dello stato di conformità prima di aver terminato tutti i requisiti dello standard, dal momento che i payment brands concedono ai merchant la possibilità di dimostrare il progresso del loro lavoro per ottenere la completa certificazione in occasione della comunicazione periodica che perviene loro dagli acquirer con cadenza semestrale. Il Prioritized Approach riorganizza i requisiti PCI DSS in base a sei security milestones tracciando un percorso che aiuta le organizzazioni ad affrontare la certificazione stabilendo delle priorità, con lo scopo di implementare i requisiti PCI DSS identificando prima gli obiettivi a più alto rischio di sicurezza. La seguente tabella sintetizza la definizione delle milestones mentre sul sito del PCI Security Standards Council si può trovare il foglio excel da utilizzare per la fase di assessment. Milestone Goal 1 Rimuovere i Sensitive Authentication Data e limitare la ritenzione dei dati. Questa milestone si concentra su un’area chiave per la gestione del rischio di entità che possono essere compromesse. È importante ricordare che se i Sensitive Authentication Data non sono memorizzati, gli effetti di una eventuale compromissione sarebbero fortemente ridotti. 2 Proteggere il perimetro interno e le reti wireless. Questa milestone comprende i controlli per i possibili punti di accesso dei più frequenti eventi di compromissione, sia per quanto riguarda la rete interna wired d che quella wireless. 3 Implementare la sicurezza delle applicazioni di pagamento con carte. Questa milestone ha come obiettivo la messa in sicurezza delle applicazioni utilizzate per gestire le transazioni economiche con carte di pagamento, sia per quanto riguarda i processi che le tecnologie (application server). Le vulnerabilità in quest’area offrono facili percorsi per avere accesso a dati di titolari di carta di pagamento e comprometterli o rubarli.
  • 59. Capitolo 2 47 Milestone Goal 4 Controllare l’accesso ai propri sistemi. I controlli compresi in questa milestone permettono di rilevare CHI accede, COSA gestisce, QUANDO e COME opera nella rete e nel Cardholder Data Environment. 5 Proteggere i dati di titolari di carte di pagamento memorizzati. Per tutte quelle organizzazioni che hanno la necessità di memorizzare PAN e altri cardholder data, questa milestone indirizza tutte le attività di protezione degli stessi. 6 Finalizzare le rimanenti attività di compliance ed assicurare che tutti i controlli siano attivi. L’obiettivo della milestone 6 è quello di completare tutti i rimanenti requisiti PCI DSS e rifinire tutte le rimanenti politiche, procedure e processi di gestione della sicurezza del Cardholder Data Environment. L’approccio permette di diminuire il rischio di compromissione o perdita di dati di titolari di carte di pagamento prima possibile durante il processo di certificazione, consente di monitorare l’andamento della certificazione con grafici e percentuali di conformità già raggiunti e aiuta gli acquirers a misurare il progresso delle attività di certificazione dei merchants da loro serviti. È importante sottolineare che il Prioritized Approach non sostituisce i documenti come il Self Assessment Questionnaire SAQ o il ROC per poter ottenere la certificazione, ma aiuta solo a organizzare meglio il percorso. Sul sito del PCI Security Standards Council (PCI Security Standards Council, LLC, 2006-2015) esiste un questo tool che può essere facilmente arricchito e migliorato per poter automatizzare la verifica di coerenza delle informazioni raccolte e per avere uno strumento di gestione di ciascun progetti di certificazione. Esistono già altri strumenti molto più evoluti e disponibili nel web. Un esempio è la PCI Compliance Dashboard (Godart, PCI Compliance Dashboard, 2015) che può essere scaricata ed utilizzata liberamente da chiunque voglia intraprendere un progetto di certificazione PCI DSS. 2.1.5 Remediations Per ogni requisito che risulta Not-in-place devono essere stabilite delle attività di adeguamento. Queste attività possono essere effettuate in parallelo all’analisi dei requisiti sia utilizzando
  • 60. Capitolo 2 48 l’approccio sequenziale che quello “per priorità” definito dal Prioritized Approach. Nelle organizzazioni ben strutturate gruppi diversi di persone possono occuparsi in modo complementare delle attività di gestione del progetto di certificazione PCI DSS e, parallelamente, delle attività di adeguamento che possono consistere in:  adeguamenti tecnologici: sono attività che prevedono lo spostamento di sistemi su diversi segmenti di rete, la configurazione di sistemi che risultino non conformi per vulnerabilità riscontrate, l’aggiunta di sistemi di controllo del traffico, l’aggiunta di applicazioni o di strumenti per l’innalzamento della sicurezza dell’ambiente, l’eliminazione di sistemi inutili se non dannosi, ecc;  adeguamenti di processi aziendali: sono attività prettamente organizzative che possono prevedere la correzione o la riscrittura di politiche, processi e procedure che non siano del tutto conformi, la determinazione di nuovi processi di gestione laddove mancanti, la schedulazione di attività periodiche (quali la revisione dei log, il test del piano di risposta agli incidenti, l’analisi dei rischi, la verifica dell’esistenza di nuove vulnerabilità, il controllo delle patch di sicurezza, ecc.). Al termine dell’implementazione gli adeguamenti devono essere verificati dal QSA che ne deve determinare la conformità con lo standard PCI DSS e tale attività può prevedere diversi cicli finché sia certificata la bontà delle soluzioni adottate. 2.1.6 On-site Assessment La fase di analisi effettuata in questi primi passi è da considerarsi preparatoria al vero e proprio On-site Assessment. Una volta terminata la fase di analisi guidata dall’approccio per priorità oppure con un normale metodo sequenziale, si passa alla verifica nel dettaglio di tutti i controlli previsti dal template del Report on Compliance che può essere scaricato dal sito del PCI Security Standards Council (PCI Security Standards Council, LLC, 2006- 2015). Il template prevede che per ogni requisito siano effettuati una serie di controlli (descritti nella colonna denominata “Reporting
  • 61. Capitolo 2 49 instructions”) che possono andare dalla verifica di un documento a quella di una configurazione, dalla verifica di un processo all’intervista di persone dei dipartimenti compresi nel perimetro di certificazione PCI DSS. Anche in questo caso, a seconda delle risorse che si hanno a disposizione, la fase può essere svolta in parallelo con quella degli adeguamenti che devono essere implementati. Tutti i controlli effettuati portano il requisito ad assumere uno stato definito tra i seguenti:  In Place: tutti gli aspetti del requisito oltre che dei requisiti di livello più basso sono stati controllati e risultano conformi;  In Place with CCW: i controlli effettuati hanno evidenziato una o più non conformità rispetto al requisito così come esplicitamente richiesto, che è coperto da un Controllo Compensativo (Compensating Control);  Not Applicable: il requisito non è applicabile all’ambiente da certificare (ad esempio i requisiti che riguardano le reti wireless possono essere non applicabili per assenza delle reti wireless stesse all’interno dell’organizzazione);  Not Tested: il requisito è escluso dal controllo, ad esempio, per motivi di richiesta parziale da parte dell’acquirer, per la validazione di un nuovo sistema che ha impatto solo su un sottoinsieme di requirement o per il fatto che il service provider offre solo un sottoinsieme di servizi da validare (es. solo servizi di outsourcing fisico);  Not In Place: i controlli del requisito, oltre che dei requisiti di livello più basso, hanno dato esito negativo e sarà previsto un adeguamento con successiva verifica di conformità. Dal momento che si suppone che un’organizzazione non possa stare in uno stato di immobilità per un periodo indeterminato di tempo, si conviene, anche se nessun documento lo prescrive, che l’intera fase di on-site assessment, fino all’emissione del ROC, non debba superare i tre mesi di tempo. Nell’Appendice B è rappresentato un diagramma di GANTT con le attività previste per una fase di on-site assessment della durata di tre mesi.
  • 62. Capitolo 2 50 2.1.7 Compensating Controls È possibile adottare compensating control per la maggior parte dei requisiti PCI DSS, quando un’entità non è in grado di soddisfare un requisito nel modo esplicitamente richiesto, a causa di limitazioni aziendali o tecniche dettagliatamente documentate e legittime, ma ha posto in essere altri controlli sufficienti a mitigare il rischio associato a tale requisito. I controlli compensativi devono soddisfare i seguenti criteri:  rispondere allo scopo del requisito PCI DSS originale;  offrire un livello di protezione simile al requisito PCI DSS originale;  andare oltre la copertura di altri requisiti richiesti (garantire la conformità ad altri requisiti PCI DSS non è considerato un controllo compensativo);  essere adeguato al rischio ulteriore provocato dal mancato pieno rispetto del requisito PCI DSS. L’efficacia di un controllo compensativo dipende dalle specifiche dell’ambiente in cui il controllo viene implementato. La valutazione di un controllo compensativo prevede i seguenti vincoli:  i requisiti PCI DSS esistenti non possono essere considerati come controlli compensativi se sono già richiesti per il componente oggetto del check. Ad esempio, le password per l’accesso amministrativo non effettuato da console devono essere inviate già cifrate per ridurre il rischio di intercettazione delle stesse con testo in chiaro. Un’organizzazione non può utilizzare altri requisiti di password PCI DSS, come ad esempio quelli che ne definiscono la complessità, per compensare la mancanza di password cifrate, poiché non riducono il rischio di intercettazione;  i requisiti PCI DSS esistenti possono essere considerati controlli compensativi solo se sono richiesti per un’altra area, ma non per il componente sottoposto a esame. Ad esempio l’autenticazione a due fattori è un requisito PCI DSS per l’accesso remoto, quindi la stessa, effettuata per accessi dalla rete interna, può anche essere considerata un controllo compensativo per l’accesso amministrativo non effettuato da
  • 63. Capitolo 2 51 console, se la trasmissione di password cifrate non è supportata;  i requisiti PCI DSS esistenti possono essere combinati con nuovi controlli per diventare un controllo compensativo. Ad esempio se una società non è in grado di rendere illeggibili i dati dei titolari di carta di pagamento quando memorizzati in modo permanente secondo quanto prescritto dal requisito 3.4 (ad esempio tramite cifratura), un controllo compensativo potrebbe essere composto da: o segmentazione di rete interna con isolamento dei sistemi che effettuano memorizzazione di CHD; o filtro degli indirizzi IP o MAC per il collegamento a tali sistemi solo da parte di chi è autorizzato; o autenticazione a due fattori anche per accessi dalla rete interna; o processi e controlli periodici per garantire che i controlli compensativi rimangano attivi una volta terminato l’assessment; Ogni controllo compensativo deve essere descritto nel dettaglio utilizzando il Compensating Control Worksheet che è parte del Report on Compliance. Le informazioni richieste riguardano:  vincoli: è necessario elencare tutti i vincoli sia di tipo tecnico che di tipo gestionale che impediscono di soddisfare il requisito originale;  obiettivo: il controllo originale ha un preciso obiettivo che deve essere definito contestualmente con una sintetica descrizione dell’obiettivo soddisfatto mediante il controllo compensativo;  rischio identificato: identificare eventuali rischi aggiuntivi dovuti alla non applicazione del controllo originale per dimostrare che è stata effettuata un’approfondita analisi dei rischi da parte dell’organizzazione;  definizione del controllo compensativo: definire il controllo compensative spiegando come soddisfa gli obiettivi del controllo originale e come copre il rischio maggiore identificato dall’analisi precedente;  validazione: definire quali procedure e quali test sono stati effettuati per poter verificare la validità del controllo compensativo;
  • 64. Capitolo 2 52  manutenzione: definire i processi e i controlli periodici che sono in atto per poter garantire l’effettiva efficacia del controllo compensativo anche al termine dell’assessment PCI DSS. 2.1.8 Report on Compliance Il Report on Compliance è l’elaborato finale che deve essere redatto da un QSA perché un merchant o un service provider (che possegga i requisiti necessari come spiegato nel paragrafo 1.2.1) possa ottenere la certificazione PCI DSS. Tale report deve essere realizzato seguendo le precise indicazioni del PCI Security Standards Council che, a tal proposito, ha realizzato il ROC Reporting Template scaricabile dal proprio sito 1. Il ROC deve riportare TUTTI i requisiti in uno qualunque degli stati elencati al paragrafo 2.1.6 ad eccezione dello stato Not-In-Place perché la certificazione possa essere ottenuta. Insieme al ROC è rilasciato anche il documento di Attestation of Compliance (AOC). 2.1.9 Attestation of Compliance L’Attestation of Compliance (AOC) è una dichiarazione di conformità allo standard PCI DSS dove sono riportati in estrema sintesi i risultati dell’assessment. L’organizzazione che ha superato l’assessment a sua volta la invia a chi ne chiede una copia (generalmente gli acquirer, i payment brands o i service provider che collaborano con l’organizzazione stessa). Esistono due versioni differenti dell’AOC, una per i merchant e una per i service provider. È firmata da un rappresentante dell’organizzazione certificata che faccia parte del consiglio di amministrazione o che sia comunque un manager con potere di firma e dal QSA (ove richiesto). Anche in questo caso tali documenti possono essere scaricati direttamente dal sito del PCI Security Standard Council 2. 1 https://www.pcisecuritystandards.org/ 2 https://www.pcisecuritystandards.org/
  • 65. Capitolo 2 53 2.2 Linee guida per la determinazione dello scope Tutti i requisiti PCI DSS si applicano a tutte (e “tutte” è inteso in senso letterale) le componenti dei sistemi (compresi network devices, server ed applicazioni) incluse nel CDE o connesse ad esso. Il CDE è costituito da persone, processi e tecnologie che memorizzano, elaborano o trasmettono CHD o SAD. 2.2.1 Passi operativi La determinazione del perimetro di certificazione, più comunemente chiamato scope, è l’attività su cui si basa tutto il percorso di certificazione di un’organizzazione, ed è perciò molto importante che sia condotta con precisione e completezza. Innanzitutto cominciamo a fare una prima distinzione tra i tipi di sistemi che ci aspettiamo di trovare nell’ambiente informatico di un’organizzazione dove sono gestiti CHD o SAD. In un ambiente di questo tipo i sistemi possono essere suddivisi in 3 categorie (D. Cougias, 2012):  Categoria 1: componenti che effettuano elaborazione, memorizzazione o trasmissione di CHD e SAD o non sono isolati o limitati attraverso accesso controllato da altri componenti di categoria 1; fanno parte di questa categoria anche sistemi che definiremo come device contagiosi, cioè dispositivi che sono considerati parte del CDE di categoria 1 anche se non effettuano elaborazione, memorizzazione o trasmissione di CHD e SAD a causa dell'assenza di isolamento o accesso controllato;  Categoria 2 - Componenti che NON effettuano elaborazione, memorizzazione o trasmissione di CHD e SAD e che hanno accesso controllato a componenti di categoria 1; i componenti di categoria 2 sono in scope e costituiti da device non- contagiosi, cioè dispositivi che sono considerati parte del CDE di categoria 2 che effettuano accesso controllato ai dispositivi di categoria 1;  Categoria 3 - Componenti che NON effettuano elaborazione, memorizzazione o trasmissione di CHD e SAD e che sono isolati da tutti i componenti di categoria 1;
  • 66. Capitolo 2 54 La Fig. 7 sintetizza la suddivisione dei sistemi in categorie: CATEGORIA 3 - Componenti che NON effettuano ELABBORAZIONE, MEMORIZZAZIONE o TRASMISSIONE di CHD e SAD e che sono ISOLATI da tutti i componenti di CATEGORIA 1 CATEGORIA 1 - Componenti che effettuano ELABBORAZIONE, MEMORIZZAZIONE o TRASMISSIONE di CHD e SAD o non sono ISOLATI o limitati attraverso ACCESSO CONTROLLATO da altri componenti di CATEGORIA 1 CATEGORIA 2 - Componenti che NON effettuano ELABBORAZIONE, MEMORIZZAZIONE o TRASMISSIONE di CHD e SAD e che hanno accesso controllato a Componenti di CATEGORIA 1 I componenti di categoria C1 e C2 sono IN SCOPEDEVICE CONTAGIOSI: Dispositivi che sono considerati parte del CDE di CATEGORIA 1 anche se non effettuano ELABBORAZIONE, MEMORIZZAZIONE o TRASMISSIONE di CHD e SAD a causa dell'assenza di ISOLAMENTO o ACCESSO CONTROLLATO I componenti di categoria C2 sono IN SCOPE e costituiti da DEVICE NON-CONTAGIOSI: Dispositivi che sono considerati parte del CDE di CATEGORIA 2 che effettuano ACCESSO CONTROLLATO ai dispositivi di CATEGORIA 1. Categorie Fig. 7: Categorie per la determinazione dello scope (Fonte: D. Cougias) La determinazione dell’appartenenza di un sistema ad una categoria può essere fatta attraverso il seguente Decision Tree (Fig. 8):
  • 67. Capitolo 2 55 Il componente MEMORIZZA, ELABORA o TRASMETTE CHD o SAD? CATEGORIA 1a Esistono sistemi di controllo dell’accesso che limitano la connettività di rete tra questo componente e quelli di CATEGORIA 1? CATEGORIA 1b Il componente, direttamente o indirettamente fornisce funzionalità di sicurezza quali autorizzazione, autenticazione o controllo dell'accesso a un componente di CATEGORIA 1? Il componente può Iniziare una connessione a un componente di CATEGORIA 1? Un componente di CATEGORIA 1 può iniziare una connessione con questo componente? Questo componente è utilizzato per amministrare un componente di CATEGORIA 1 attraverso un componente intermedio di CATEGORIA 2? CATEGORIA 2a CATEGORIA 2b CATEGORIA 2c CATEGORIA 2x CATEGORIA 3 1 2 3 4 5 6 7 8 9 10 11 12 13 SI SI NO NO NO NO NO SI SI SI SI NO Decision Tree I componenti di CATEGORIA 2 sono sempre in scope. Tutti i requisiti PCI devono essere valutati per accertarne l’applicabilità sulla base di una valutazione del rischio per il CDE in generale e per l’intero ambiente Un componente può essere definito ISOLATO da componenti di CATEGORIA 1 se e solo se le risposte al domande nei box 1, 4, 7, 9 e 11 sono "No". I componenti di CATEGORIA 2X sono sempre in scope; tuttavia i controlli necessari per ridurre il rischio di questi componenti del CDE sono limitati ai requisiti 1.4, 2, 5 e 6.1 I componenti di CATEGORIA 3 non ELABORANO, non MEMORIZZANO e non TRASMETTONO CHD. La connettività diretta tra componenti di CATEGORIA 3 e quelli di CATEGORIA 1 è attivamente bloccata. Fig. 8: Decision Tree per la determinazione dello scope (Fonte: D. Cougias) Per avere una visione schematica ed immediata dei passi operativi, si rimanda al paragrafo 2.1 che contiene un diagramma a blocchi sintetico ma completo.
  • 68. Capitolo 2 56  Censimento delle applicazioni che gestiscono CHD La proposta che qui si descrive e che deriva dall’esperienza sul campo, consiste nel cominciare ad effettuare un censimento degli strumenti di lavoro che le persone tutti i giorni utilizzano per svolgere i propri compiti. Ad oggi i principali strumenti che vengono utilizzati sono le applicazioni software, delle quali si può avere un quadro generale attraverso le interviste con gli operatori che le utilizzano, con i sistemisti che ne fanno manutenzione e consultando la documentazione a corredo delle stesse. Naturalmente questo primo passaggio permetterà di tracciare il primo confine tra le applicazione che gestiscono dati di titolari di carte di pagamento da quelle che invece hanno altre funzioni (contabilità, gestione risorse, automazione d’ufficio, ecc.).  Censimento delle basi di dati collegate alle applicazioni Una volta individuate le applicazioni che fanno parte del cardholder data environment, è quindi necessario censire quali siano le basi di dati (siano esse dei database o dei file proprietari) a cui esse attingono per poter eseguire le loro specifiche funzioni.  Censimento di tutti gli host (IP address) su cui sono installate applicazioni e database (sistemi di categoria 1) Con la lista delle applicazioni e delle basi di dati, si può procedere all’individuazione dei sistemi (fisici o virtuali) su cui sono installate, compilando una lista di indirizzi IP che servirà anche più avanti per individuare i sistemi che saranno sottoposti agli scan per i vulnerability assessment e ai penetration test.  Censimento di tutti i sistemi che si connettono ai sistemi di categoria 1 (sistemi di categoria 2) Individuati i sistemi di categoria 1, si può quindi passare al censimento dei sistemi che si connettono ad essi, come ad esempio client, server di servizi come DNS, anti-virus, monitoring, log o macchine di Backup. I sistemi di categoria 1 uniti ai sistemi di categoria 2 fanno parte del perimetro di certificazione e costituiscono quindi il Cardholder Data Environment.  Censimento di tutti gli altri sistemi (sistemi di categoria 3)