Peroli_Tesi_v3.5

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

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
le informazioni di
acquisto all’issuer
L’issuer prepara i dati per
l’addebito dell’importo al titolare
della carta di pagamento
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
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
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)
2  Merchant che
gestiscono da 50000
a 2,5 milioni di
con carte di
pagamento
American Express
 Merchant che
gestiscono da 1 a 6
pagamento Discover
 Qualunque
Merchant
determinato come
Level 2 da parte di
Discover
 Merchant che
gestiscono meno di
1 milione di
con carte di
pagamento JCB
3  Merchant che
gestiscono meno di
50000 transazioni
pagamento
American Express
 Merchant che
gestiscono da 20000
a 1 milione di
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
milioni di
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
milioni di
con carte di
pagamento Visa
 Qualunque
Merchant che opera
a livello mondiale e
determinato come
Level 1 in una
qualunque regione
Visa
 Merchant che
milioni di
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
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
con carte di
pagamento Visa
 Merchant che
gestiscono da 1 a 6
milioni di
con carte di
pagamento Visa

Capitolo 1
10
Livelli di certificazione per i Merchant (MasterCard, Visa Inc., Visa Europe)
3  Merchant che
gestiscono da 20000
e 1 milione di
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
di tipo e-commerce
con carte di
pagamento Visa
 Merchant che
gestiscono da 20000
a 1 milione di
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
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
con carte di
pagamento Visa

Capitolo 1
11
 Requisiti di validazione per i Merchant
Requisiti di validazione per i Merchant (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)
annuale effettuato
da un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)

Capitolo 1
12
2  Self Assessment
Questionnaire
annuale effettuato
dal merchant stesso
e certificato dal
chief executive
officer
(amministratore
delegato), chief
fianancial officer
(direttore
finanziario), chief
security) o dal
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)
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
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)
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)
annuale effettuato
da un QSA o da un
auditor interno (o
da altro staff
indipendente) con
Security Auditor
 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
Security Auditor
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
 Attestation of
Compliance form
annuale effettuato
da un QSA o da un
auditor interno con
Security Auditor
 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)
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)
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
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
2 Se compliant
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
Compliance o
Executive summary
degli External
Vulnerability Scan
trimestrali
Se non compliant
 Attestation of
Compliance che
includa la parte di
le remediation
 Data di
implementazione
delle remediation
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
inviare il modulo
Portfolio
Compliance Status
Submission” a
Discover due volte
all’anno
la reportistica
richiesto

Capitolo 1
18
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
inviare il modulo
Portfolio
Compliance Status
Submission” a
Discover due volte
all’anno
 N/A

Capitolo 1
19
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
inviare il modulo
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)
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
site annuale
 Su richiesta gli
acquirer devono
fornire anche una
copia del Report on
Compliance dei
merchant
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
 Attestation of
Compliance
site annual dei
merchant
acquirer devono
fornire anche una
copia del Report on
Compliance dei
merchant incluse le
Attestation of Scan
Compliance
trimestrali

Capitolo 1
21
2  Gli acquirer
comunicano
trimestralmente a
MasterCard lo stato
dei propri merchant
Compliance
Program prescrive
che ogni merchant
non conforme
comunichi ai propri
compliance e lo
stato di
avanzamento lavori
per il
completamento
delle remediation
utilizzando il tool
fornito dal PCI SSC
denominato
“Prioritized
Approach”
merchant comunica
stato di compliance
o non compliance
 Attestation of
Compliance
site annuale
acquirer devono
fornire anche una
copia del Self
Assessment
Questionnaire dei
merchant
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
acquirer devono
fornire anche Self
Assessment
Questionnaire e
Attestation of
Compliance dei
merchant

Capitolo 1
22
3  Gli acquirer
comunicano
trimestralmente a
MasterCard lo stato
dei propri merchant
Compliance
Program prescrive
che ogni merchant
non conforme
comunichi ai propri
compliance e lo
stato di
avanzamento lavori
per il
completamento
delle remediation
utilizzando il tool
fornito dal PCI SSC
denominato
“Prioritized
Approach”
merchant comunica
stato di compliance
o non compliance
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
acquirer devono
fornire anche Self
Assessment
Questionnaire e
Attestation of
Compliance dei
merchant
4  Nessun requisito
per la reportistica
richiesto
 Requisiti definiti
dagli acquirer
merchant comunica
trimestralmente lo
stato di compliance
o non compliance
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)
1  Service Provider che
gestiscono più di 2,5
pagamento
American Express
 Qualunque Service
Provider
determinato come
Level 1 da parte di
American Express
 Service Provider che
gestiscono più di
300000 transazioni
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
gestiscono da 50000
a 2,5 milioni di
con carte di
pagamento
American Express
gestiscono meno di
300000 transazioni
pagamento Discover
 N/A

Capitolo 1
24
Livelli di certificazione per i Service Provider (American Express, Discover, JCB)
gestiscono meno di
50000 transazioni
pagamento
American Express
 N/A  N/A
Livelli di certificazione per i Service Provider (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
pagamento
MasterCard e
Maestro
 Qualunque TPP o
DSE che abbia
subito una
compromissione
nell’ultimo anno
 Tutti i VisaNet
Payment Processors
gestiscono più di
300000 transazioni
pagamento Visa
 Tutti i Visa System
Processors
gestiscono più di
300000 transazioni
pagamento Visa
2  Tutte le entità
identificate come
Data Store Entities
(DSE) che gestiscono
meno di 300000
con carte di
pagamento
MasterCard e
Maestro
gestiscono meno di
300000 transazioni
pagamento Visa
gestiscono meno di
300000 transazioni
pagamento Visa

Capitolo 1
25
 Requisiti di validazione per i Service Provider
Req. di validazione per i Service Provider (American Express, Discover, JCB)
annuale effettuato
da un QSA oppure
dal Service Provider
stesso se certificato
dal chief executive
officer
(amministratore
delegato), chief
fianancial officer
(direttore
finanziario), chief
security) o dal
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
annuale effettuato
da un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
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)
Questionnaire
annuale effettuato
dal Service Provider
stesso e certificato
dal chief executive
officer
(amministratore
delegato), chief
fianancial officer
(direttore
finanziario), chief
security) o dal
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
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)
annuale effettuato
da un QSA
 External
Vulnerability Scan
Assessment
trimestrale
effettuato da un
Approved Scanning
Vendor (ASV)
VisaNet Processor e
Service Provider:
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)
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ù
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ù
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
in base alla data
indicata sulla
Attestaion of
Compliance
 Necessario contattare
JCB
MasterCard Visa Inc. Visa Europe
 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
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):
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:
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)
1 Se compliant
 Attestation of
Compliance
site annuale
Compliance o
Executive summary
degli External
Vulnerability Scan
trimestrali
Se non compliant
 Attestation of
Compliance che
includa la parte di
le remediation
 Data di
implementazione
delle remediation
seguenti)
 Attestation of
Compliance
site annuale
 Attestation of
Compliance che (se
non completamente
compliant) includa
la parte di piano
d’azione per le
remediation
la reportistica
richiesto

Capitolo 1
31
Requisiti di reportistica per i Service Provider (American Express, Discover, JCB)
2 Se compliant
 Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
Compliance o
Executive summary
degli External
Vulnerability Scan
trimestrali
Se non compliant
 Attestation of
Compliance che
includa la parte di
le remediation
 Data di
implementazione
delle remediation
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)
1  Attestation of
Compliance
site annuale
 MasterCard non
accetta né revisiona
Report on
Compliance
 Attestation of
Compliance che
includa la parte di
le remediation solo
se non
completamente
compliant e solo se
si tratta di una
prima registrazione
Third Party Agents
 Attestation of
Compliance
site annuale
VisaNet Processor
 Attestation of
Compliance
site annuale
 Report on
Compliance
completo
Member Agents
 Attestation of
Compliance
site annual
 QSA confirmation
form (sito Visa)
2  Attestation of
Compliance dal Self
Assessment
Questionnaire
annuale
 Attestation of
Compliance che
includa la parte di
le remediation solo
se non
completamente
compliant e solo se
si tratta di una
prima registrazione
Third Party Agents
 Attestation of
Compliance
site annuale
VisaNet Processor
 Attestation of
Compliance
site annuale
 Report on
Compliance
completo
Member Agents
 Attestation of
Compliance
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
MEMORIZZAZIONE o
TRASMISSIONE di CHD e SAD o
non sono ISOLATI o limitati
attraverso ACCESSO
CONTROLLATO da altri
CATEGORIA 2 - Componenti che NON
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
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
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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (8)

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie Peroli_Tesi_v3.5

Ähnlich wie Peroli_Tesi_v3.5 (20)

Peroli_Tesi_v3.5