PCI-DSS

Programma

Introduzione




PCI-DSS










Frodi e SSC
Soggetti coinvolti
Carte e processi
Famiglia di standard
Applicabilità
Conformità
Requisiti
Audit e scansione
Statistiche e sanzioni
Materiale a disposizione
Rapporto con altri standard
Conclusioni

Alcune Soluzioni tecnologiche per la
PCI-DSS







Cifratura dati in transito e nel database
Separazione dei ruoli
Accesso ai dati per classificazione degli
utenti
Funzionalita` di auditing
Mascheramento dei dati
Gestione delle identita` e controllo
accessi
Gestione della sicurezza dei documenti
Domande e discussione
PCI-DSS
2
Prima di iniziare
Alberto Perrone
(in sostituzione di Fabio Guasconi)
Lead Auditor qualificato ISO/IEC 27001:2005
OSSTMM Professional Security Tester
Divisione Sicurezza Informazioni
@ Mediaservice.net S.r.l.
PCI-DSS
3
Prima Parte:
INTRODUZIONE
PCI-DSS
4
Frodi sulle carte
In risposta al preoccupante fenomeno delle frodi, i principali Brand delle carte
di pagamento hanno deciso di unire le forze.





Furto della carta
Skimming
Furto d’identità
Phishing
Attacchi informatici
Tutte le tipologie di frodi sono basate sull’acquisizione
non autorizzata di dati relativi alle carte.
Il dato di una carta singola non è rilevante, i DB
di dati o i sistemi che ne trattano numerose (siti internet,
POS, ATM) sono l’obiettivo preferenziale.
PCI-DSS
5
PCI-SSC
PCI-DSS
6
Soggetti coinvolti: chi
Titolare
• Intestatario della carta di pagamento, può usarla fisicamente o via
elettronica
• Riceve gli estratti conti dall’Issuer
Merchant
• Soggetto a favore del quale il cliente effettua una transazione
Acquirer
• Soggetto che elabora la transazione per conto del Merchant
• Dialoga con l’Issuer, direttamente o tramite reti proprietarie
• Amex, Discover e JCB possono essere acquirer
Issuer*
Service
Provider
• Soggetto che emette la carta di pagamento:
- presso cui il titolare ha un conto (Banca)
- a cui il titolare ha richiesto una carta (Amex, Discovery, JCB)
• Soggetto coinvolto nel trattamento dei dati delle carte
• Può essere legato al Merchant, all’Acquirer o all’Issuer
*i Brand delle carte sono associazioni di soggetti Issuer.
PCI-DSS
7
Soggetti coinvolti: cosa
PCI-SSC
• Gestisce gli standard creando un punto di convergenza unico
• Gestisce l’accreditamento e la QA di QSA, PA-QSA, ASV e i
PED Labs nonché le liste di prodotti conformi
Merchant
• Deve dimostrare la conformità all’Acquirer
Acquirer
• E’ responsabile della conformità dei Merchant
• Come l’Issuer deve essere conforme a PCI-DSS senza
dover però dimostrarlo come un Merchant
Service
Provider
• E’ coinvolto nella conformità del Merchant a seconda del
servizio fornito
• Può essere escluso (e.g. storage senza chiave crittografica)
Brand
• Gestisce il proprio programma di conformità ricevendone
adeguata documentazione
• Effettua le indagini forensi a valle degli incidenti per stabilire
cause e responsabilità
PCI-DSS
8
Transazioni con carta
Authorization (secondi): Il Merchant richiede l’autorizzazione all’Issuer
Service Provider
Service Provider
1
6
2
3
5
4
Cliente
Issuer
Merchant
Acquirer
Clearance (un giorno): Acquirer e Issuer si scambiano i dati della transazione
Service Provider
Service Provider
1
2
Cliente
Issuer
Merchant
Acquirer
Settlement (due giorni): L’Acquirer accredita la somma transata al Merchant e
l’Issuer la addebita al Titolare della carta
Service Provider
Service Provider
2
1
Issuer
Merchant
Cliente
Acquirer
PCI-DSS
9
Carte: storia e tipi
Timeline




1920 - Prima carta di credito negli USA
1950 - Primo brand moderno (Diners)
1958 - Amex, Bank Americard (futura VISA)
1967 - Everything Card (futura MasterCard)
Tipi più diffusi di carte





Classic - Limite tra 100$ e 2.000$
Gold - Limite tra 500$ e 15.000$
Business - Limite tra 500$ e 25.000$
Platinum - Limite tra 1.000$ e 100.000$
Amex Black (centurion) - Illimitata
PCI-DSS
10
Carte
Il PAN (Primary Account Number) è il dato singolo più importante della carta,
ed è costituito da 13, 14, 15 o 16 caratteri.
I PAN non sono casuali e la loro validità può facilmente essere verificata.
Formula di Luhn
PCI-DSS
11
Carte
Espressioni regolari e lunghezze dei PAN:

VISA (16 caratteri, 13 caratteri alcune “vecchie”): ^4[0-9]{12}(?:[0-9]{3})?$

MasterCard (16 caratteri): ^5[1-5][0-9]{14}$ All MasterCard numbers start
with the numbers 51 through 55. All have 16 digits.

American Express (15 caratteri): ^3[47][0-9]{13}$

Diners Club (14 caratteri): ^3(?:0[0-5]|[68][0-9])[0-9]{11}$
Esistono carte Diners che iniziano con 5 e hanno 16 caratteri ma vengono
trattate come MasterCard

Discover (16 caratteri): ^6(?:011|5[0-9]{2})[0-9]{12}$

JCB (15 o 16 caratteri): ^(?:2131|1800|35\d{3})\d{11}$
PCI-DSS
12
Carte
Come misura anti frode sono stati aggiunti dei codici di sicurezza, denominati e
formattati in modo diverso da ogni Brand.
La differenza fondamentale tra di essi è che possono essere a 3 o 4 caratteri.
CVV e CVC sono memorizzati nelle tracce magnetiche, uso se card-present.
PCI-DSS
13
Tracce
Le carte hanno una banda magnetica suddivisa in tracce.
Traccia 1: lunghezza fino a 79 caratteri, comprende la traccia 2
(Pin Verification)
PCI-DSS
14
Tracce
Traccia 2: lunghezza fino a 40 caratteri, legata a compatibilità per strumenti
che effettuano dial-up.
I Chip contengono anche le informazioni della prima e della seconda traccia,
cambia la protezione delle stesse.
PCI-DSS
15
Dati dei Titolari delle Carte
La tabella seguente riassume quali sono i dati considerati dallo standard.
Memorizzazione
Consentita
Protezione
Richiesta
Req. 3.4 PCIDSS
Sì
Sì
Sì
Sì
Sì
Sì
Sì
Sì
Sì
No
No
No
No
N/A
N/A
CAV2/CVC2/CVV2/CID
No
N/A
N/A
PIN/Blocco PIN
No
N/A
N/A
Elemento di dati
Dati di titolari delle
carte
Dati sensibili di
autenticazione
*
PAN (Primary Account
Number
Nome titolare di carta*
Codice di servizio*
Data di scadenza*
Dati completi della
banda magnetica
Questi elementi devono essere protetti se memorizzati assieme al PAN.
Memorizzazione e protezione si riferiscono ai momenti successivi
all’autorizzazione.
PCI-DSS
16
Seconda Parte:
PCI-DSS
PCI-DSS
17
Standard



PCI-PED (ora PTS) applicabile a POS, Pin Pad, HSM, UPT
PCI PA-DSS applicabile ad applicazioni commerciali per authorization o
settlement delle transazioni
PCI-DSS applicabile ai soggetti che trattano dati delle carte
PCI-DSS se legata agli altri standard si limita a controllarne il corretto impiego
PCI-DSS
18
Passato
2001 VISA lancia il programma Cardholder Information Security Program
(CISP), seguita dagli altri Brand
2004 A Dicembre viene pubblicata la prima versione della PCI-DSS, gestita da
VISA e MasterCard
2005 Visa crea la Payment Applications Best Practices (PABP)
2006 VISA, MasterCard, American Express, Discover e JCB fondano il PCISSC
2006 E’ resa pubblica la versione 1.1 della PCI-DSS
2008 E’ resa pubblica la versione 1.0 della PA-DSS
2008 E’ resa pubblica la versione 1.2 della PCI-DSS
PCI-DSS
19
Futuro
Periodo di revisione rapido: 24 mesi
Fase attuale: 3
Versioni: 1.0, 1.1, 1.2
PCI-DSS
20
Applicabilità
Qualsiasi soggetto effettui un trattamento di dati delle carte (PAN)
Principalmente (98%):
Merchant fisici (negozi, catene)
Merchant elettronici (e-commerce via web o telefono)
Service Provider dei Merchant (hosting, fornitori di DR, stampatori delle
carte, agenti di vendita, call center, payment gateway)
Alcune operazioni oltre ai pagamenti:
Programmi di fedeltà
Annullamento di transazioni
Pagamento di rimborsi
Backup
PCI-DSS
21
Applicabilità
PCI-DSS si applica in modo diverso a tutti i componenti di sistema inclusi o
connessi nell’ambiente in cui sono trattati i dati delle carte di pagamento.
Il primo passo necessario è definire i flussi di tali dati attraverso:

Sistemi informatici

Apparecchiature

Applicazioni

Database

Dispositivi di rete

Personale

Terze parti
Nota: attenzione ai metodi meno facilmente individuabili, come registrazioni
vocali e log, ma anche al cartaceo.
PCI-DSS
22
Applicabilità
Uno dei concetti fondamentali riguardanti i dati delle carte:
“if you don’t need it, get rid of it”
Spesso la memorizzazione non è necessaria oppure può essere effettuata in
forma parziale:

mascheramento (6/4: 5412 75** **** 0000)

hashing crittografico a una sola via
La segmentazione della rete e la separazione dell’ambiente in cui sono trattati
i dati delle carte di pagamento permettono a loro volta di ridurre notevolmente
l’ambito, come esemplificato di seguito.
PCI-DSS
23
Applicabilità: esempio di rete
PCI-DSS
24
Conformità a PCI-DSS
Per raggiungere la conformità allo standard ci sono una serie di passaggi
propedeutici:
Definizione del
livello (Acquirer)
Validazione
(Merchant)
Reportizzazione
(Merchant)
La prima validazione può avere diverse caratteristiche da quelle successive,
tecnicamente denominate rivalidazioni.
Normalmente questo succede per i Service Provider,
PCI-DSS
25
Definizione del livello: merchant
Il livello non è legato al rispetto dei requisiti!
L’Acquirer stabilisce il livello del Merchant o del Service Provider, partendo da
quanto definito dai Brand. Per i Merchant:
VISA
Mastercard
Livello 1
>6M Transazioni
Violazione subita
l’anno precedente
>6M Transazioni
Violazione subita
l’anno precedente
Livello 2
Tra 1M e 6M
Transazioni
Livello 3
Livello 4
Amex
Discover
JCB
>2,5M
Transazioni
Così definito da
Amex
>6M Transazioni
Livello 1 per altro
Brand
>1M Transazioni
Violazione subita
l’anno precedente
Tra 1M e 6M
Transazioni
Tra 50K e 2,5M
Transazioni
Così definito da
Amex
Tra 1M e 6M
Transazioni
Livello 2 per altro
Brand
<1M Transazioni
>20K Transazioni
e-commerce
>20K Transazioni
e-commerce o
Maestro
Meno di 50K
Transazioni
>20K Transazioni
e-commerce
Livello 3 per altro
Brand
N/A
Tutti i merchant
non compresi nei
precedenti
Tutti i merchant
non compresi nei
precedenti
N/A
Tutti i merchant
non compresi nei
precedenti
N/A
PCI-DSS
26
Definizione del livello: TPP
I Service Providers (definiti anche come TPP, Third Party Processors),
seguono logiche differenti:
VISA
Mastercard
Amex
Discover
JCB
Livello 1
>300K
Transazioni
>300K
Transazioni
Tutti i TPP
Tutti i TPP
Tutti i TPP
Livello 2
<300K
Transazioni
<300K
Transazioni
N/A
N/A
N/A
VISA pubblica i Service Provider di livello 1 conformi in un elenco. Ogni SP può
validarsi secondo i le modalità più onerose del livello 1 per comparire in questa
lista.
PCI-DSS
27
Altri soggetti?
Acquirer

Sono tenuti a raggiungere la conformità esattamente come i Merchant

Devono assicurarsi della conformità dei Merchant e dei fornitori

Non sono obbligati ad avvalersi di QSA
Issuer

Sono tenuti a raggiungere la conformità esattamente come i Merchant, con
l’eccezione che possono memorizzare i dati sensibili
PCI-DSS
28
Validazione
Merchant
Livello 1
Merchant
Livello 2
Merchant
Livello 3
Merchant
Livello 4
TPP
Livello 1
TPP
Livello 2
VISA
Mastercard
Amex
Discover
JCB
QSA on-site audit
annuale
ASV scansione
trimestrale
QSA on-site audit
annuale
ASV scansione
trimestrale
QSA o IA on-site
audit annuale
ASV scansione
trimestrale
QSA on-site audit
annuale
ASV scansione
trimestrale
QSA on-site audit
annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
QSA on-site audit
annuale (facoltativo)
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
N/A
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
N/A
SAQ annuale
ASV scansione
trimestrale
N/A
QSA on-site audit
annuale
ASV scansione
trimestrale
QSA on-site audit
annuale
ASV scansione
trimestrale
QSA o IA on-site
audit annuale
QSA on-site audit
annuale
ASV scansione
trimestrale
o SAQ annuale
QSA on-site audit
annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
SAQ annuale
ASV scansione
trimestrale
N/A
N/A
N/A
PCI-DSS
29
Livelli: esempi
Caso di un electronic commerce merchant, per il quale tutte le transazioni
derivano dai siti internet:
VISA
Acquirer A
Mastercard
Amex
Discover
JCB
Totale
5M
Livello 2
800K
Livello 3
-
-
-
Livello 2
Acquirer B 2M
Livello 2
400K
Livello 3
-
10K
Livello 3
20K
Livello 2
Livello 2
Acquirer C -
-
20K
Livello 3
-
-
Livello 3
Totale
1,2M NO
Livello 2
-
-
-
7M, NO
Livello 1
PCI-DSS
30
Requisiti
La versione 1.2 della PCI-DSS comprende 210 + 4 requisiti divisi in 13 sezioni:
1: Configurazione dei firewall
2: Valori di default
3: Protezione dei dati archiviati
4: Protezione dei dati trasmessi
5: Antivirus
6: Sviluppo e manutenzione
7: Controllo degli accessi
8: Identificazione, autenticazione
9: Sicurezza fisica
10: Log
11: Testing
12: Policy
A: Service Providers
PCI-DSS
31
Requisiti
La distribuzione dei requisiti per numerosità è così rappresentabile:
4%
40
2% 2%
3% 3% 2%
12
6
21%
10
9%
35
8
15%
9%
30
1
9%
10%
25
9
11%
3
2
20
7
11
15
10
5
0
12
6
10
8
9
1
3
2
7
11
A
4
5
PCI-DSS
32
1: Configurazione dei firewall










Configurazione sicura di firewall e router
Adozione di standard di configurazione
Controllo del traffico in entrata e in uscita
Individuazione di servizi e protocolli in uso e loro giustificazione
Revisione semestrale delle regole
Approccio “deny all”
Installazione di firewall davanti alle reti wireless
Creazione di DMZ tra carte e Internet
Uso di tecnologie di stateful inspection e NAT
Installazione di personal firewall su sistemi portatili/esterni
PCI-DSS
33
2: Valori di default








Rimozione di account e password di default su componenti di sistema
Cambio di chiavi, communities SNMP, password su AP wireless
Adozione di standard di configurazione sicuri
Impostazione di una sola funzione primaria per server
Rimozione di servizi, protocolli e demoni inutili
Impostazione di parametri di configurazione sicuri
Crittografia degli accessi amministrativi non da console
Separazione totale degli ambienti dei vari clienti da parte dei service
provider di hosting condiviso
PCI-DSS
34
3: Protezione dei dati archiviati










Politiche di mantenimento dei dati e di loro dismissione (tempi)
Rimozione trimestrale automatica dei dati che superano la soglia
Non memorizzazione di dati sensibili oltre all’autorizzazione
Mascheramento del PAN visualizzato ove possibile
Troncamento, hashing, indicizzazione o crittografia del PAN, ovunque
Uso di tecniche di crittografia del file system non legate agli utenti
Separazione di DEK e di KEK, controllo degli accessi alle chiavi
Impiego di split-knowledge e/o dual control per le chiavi
Sostituzione almeno annuale delle chiavi o in caso di compromissione
Assegnazione del ruolo di custode delle chiavi
Algoritmi crittografici accettati: standard di mercato, non compromessi. L’uso di
hashing non sicuri è permesso tramite salting.
PCI-DSS
35
4: Protezione dei dati trasmessi



Uso di SSLv3+, TLS o IPSEC per trasmissione dei dati su reti pubbliche
Non trasmissione di dati su reti pubbliche se non protetti con crittografia
Impiego di tecniche di protezione WPA o superiori per trasmissione dei dati
su reti wireless
Il WEP è tollerato fino al 30 Giugno 2010 ma solo per le installazioni già
esistenti al 31 Marzo 2009.
PCI-DSS
36
5: Antivirus






Installazione di software antivirus sui sistemi affetti da malware
Adozione di prodotti in grado di individuare, rimuovere e proteggere contro
tutti i tipi di malware
Aggiornamento costante delle definizioni
Impostazione di scansioni periodiche
Impossibilità di disattivazione del software
Generazione e conservazione dei log
PCI-DSS
37
6: Sviluppo e manutenzione











Aggiornamento dei sistemi e del software
Individuazione e installazione delle patch critiche di sicurezza entro 30 giorni
Allineamento degli standard di configurazione (2) in base alle patch
Adozione di un processo di sviluppo sicuro del software
Testing dei cambiamenti prima del rilascio
Separazione degli ambienti di sviluppo (no PAN attivi) e produzione, in termini
sistemistici e di personale
Rimozione di account e dati di test prima dei passaggi in produzione
Revisione automatica/manuale del nuovo codice scritto, non fatta dall’autore
Adozione di procedure di controllo dei cambiamenti inclusive di
documentazione degli impatti, approvazione, testing e roll-back
Uso di tecniche di programmazione sicura
Revisione annuale o dopo ogni cambiamento significativo delle applicazioni
web aperte al pubblico / adozione di un WAF
PCI-DSS
38
7: Controllo degli accessi




Approccio del minimo privilegio
Impiego di sistemi RBAC
Autorizzazione necessaria da parte del management
Controllo automatizzato su tutti i componenti di sistema
PCI-DSS
39
8: Identificazione, autenticazione












Tutti gli utenti hanno un ID unico per l’accesso ai componenti di sistema
Le password relative agli ID non sono salvate o trasmesse in chiaro
Uso di due fattori di autenticazione per gli accessi remoti
Verifica dell’identità del richiedente per il reset della password
Impostazioni di password iniziali univoche
Rimozione degli account inattivi da 90 giorni
Attivazione e disattivazione degli account esterni in base all’uso
Le password devono essere cambiate ogni 90 giorni e devono essere lunghe
almeno 7 caratteri, con vincoli di complessità e senza poter riutilizzare le 4
precedenti
Divieto di utilizzo di account di gruppo e di condivisione delle password
Attivazione di lockout di almeno 30 minuti dopo 6 tentativi di autenticazione
Attivazione di screen-saver dopo un massimo di 15 minuti di inattività
Limitazione dell’accesso diretto ai DB ai DBA e delle application ID alle sole
applicazioni
PCI-DSS
40
9: Sicurezza fisica









Installazione di videocamere all’ingresso delle aree sensibili e mantenimento
delle registrazioni
Controllo delle prese di rete
Limitazione dell’accesso fisico ai dispositivi di rete (AP, chioschi etc.)
Assegnazione di badge distintivi
Associazione dei badge ad un periodo di validità e controllo della restituzione
Adozione di un registro degli accessi esterno e alle aree sensibili
Ispezione annuale delle località di conservazione dei supporti
Classificazione, tracciatura, etichettatura ed inventario dei supporti
Dismissione sicura dei supporti
PCI-DSS
41
10: Log







Logging centralizzato di tutte le attività amministrative
Controllo degli accessi e dell’integrità dei log
Mantenimento di informazioni di logging complete
Logging derivanti da tutti i componenti di sistema (OS, applicazioni,
dispositivi, antivirus, DNS etc.)
Mantenimento di riferimenti temporali attendibili con due o più server interni
Retention dei log per 1 anno, di cui almeno 3 mesi consultabili online
Revisione giornaliera (automatica) dei log
PCI-DSS
42
11: Testing





Analisi della presenza di reti wireless trimestrale o adozione di WIDS/WIPS
Esecuzione di vulnerability assessment esterne (ASV) e interne trimestrali o a
valle di cambiamenti significativi
Effettuazione di penetration test annuali o a valle di cambiamenti significativi
sia a livello di rete sia a livello applicativo
Implementazione e mantenimento della funzionalità di sistemi IDS o IPS per
monitorare tutto il traffico
Adozione di sistemi per il monitoraggio dell’integrità dei file di configurazione
e loro controllo settimanale
PCI-DSS
43
12: Policy








Diffusione e revisione annuale di una Policy di Sicurezza
Sviluppo di procedure inerenti le attività giornaliere di sicurezza
Diffusione di una Politica per l’Uso Accettabile della strumentazione
Definizione e assegnazione delle responsabilità per la sicurezza
Adozione di un programma di formazione annuale sulla sicurezza
Screening preventivo all’assunzione per posizioni critiche
Gestione dei Service Provider e della loro conformità
Diffusione di un Piano di Risposta agli Incidenti comprensivo di procedure di
reazione per le violazioni di sicurezza e testato annualmente
PCI-DSS
44
A: Service Provider
Se si tratta di fornitori di hosting condiviso:



Impossibilità per i clienti di accedere ad ambienti oltre al loro o di
monopolizzare le risorse dei sistemi
Distinzione e separazione dei log dei diversi ambienti
Adozione di procedure che permettano immediate indagini forensi in caso di
compromissione
PCI-DSS
45
Controlli Compensativi
E se un requisito non si può applicare? Devono esserci:


Legittimi vincoli tecnici oppure
Documentati vincoli di business
A questo punto è possibile indicare delle contromisure che compensano la
mancata soddisfazione di un particolare requisito, le quali devono


Essere allineati con l’intenzione e il rigore del requisito originale, mitigando
in modo equivalente i rischi collegati
Essere al di sopra degli altri requisiti di PCI-DSS implementati sul
componente di sistema e non creare rischi aggiuntivi
I controlli compensativi devono essere documentati in modo rigoroso.
PCI-DSS
46
2: Valori di default
3: Protezione dei dati archiviati
4: Protezione dei dati trasmessi
6: Sviluppo e manutenzione
8: Identificazione, autenticazione
x
x
x
x
x
x
x
locali
x
x
persone
x
x
x
5: Antivirus
7: Controllo degli accessi
sistemi
x
x
db
1: Configurazione dei firewall
applicazioni
rete
Scoping dei Requisiti
x
x
x
x
x
x
x
9: Sicurezza fisica
x
10: Log
x
x
11: Testing
x
x
12: Policy
A: Service Providers
x
PCI-DSS
x
x
x
x
x
x
x
x
47
Approccio Prioritizzato
Il PCI-SSC ha sviluppato una guida per dare priorità ai requisiti che hanno
maggiore impatto sui rischi. Ogni requisito appartiene a una delle sei milestone.
A
Milestones
12
11
10
9
1
8
2
7
3
6
4
5
5
1
Rimozione dei dati sensibili e
limitazione del loro mantenimento
2
Protezione del perimetro, delle reti
interne e wireless
3
Securizzazione delle applicazioni
4
Monitoraggio e controllo degli
accessi ai sistemi
5
Protezione dei dati memorizzati
6
Completamento delle misure e
verifica finale
6
4
3
2
1
0
10
20
30
40
50
PCI-DSS
48
Passaggi chiave
1. Analisi dei flussi dei dati
2. Esecuzione di una Gap Analysis
3. Remediation di prima e terza parte
4. Verifica di conformità
5. Documentazione e reportizzazione
PCI-DSS
49
Audit on-site e Scansione
Per due attività di validazione della conformità entrano in gioco degli attori
riconosciuti direttamente dal PCI-SSC: i QSA e gli ASV
Approved Scanning Vendor (ASV)
Requisito 11.2: Scansioni di rete esterne e interne trimestrali o a fronte di
cambiamenti significativi. Si applica a tutti.
Qualified Security Assessor (QSA)
Audit on-site per i livelli più elevati.
Entrambe le figure sono una combinazione di persone esperte in sicurezza e
aziende del settore.
I requisiti includono professionalità, organizzazione, indipendenza, qualità e
opportune polizze assicurative.
PCI-DSS
50
Audit on-site
Le procedure di audit sono definite e pubblicate dal PCI-SSC.
Ogni singolo requisito deve essere verificato e documentato sotto diversi
aspetti nel report of compliance (ROC). Gli aspetti considerati sono, a seconda:





osservazione di settaggi o configurazioni
revisione di documentazione
intervista
osservazione di processi, azioni o stati
monitoraggio del traffico
Tutti questi parametri sono controllati e valutati rigidamente nei report dei QSA
da parte del PCI-SSC. I QSA possono essere sospesi o radiati.
Chi si occupa di seguire la remediation deve essere diverso dall’assessor.
SAMPLING
PCI-DSS
51
Scansione
Le procedure di scansione (esterne) sono definite e pubblicate dal PCI-SSC.
Per PCI-SSC una scansione individua le vulnerabilità mentre un’attività di
penetration test le sfrutta per raggiungere i dati.
Vulnerabilità di livello 3, 4, 5 o che ottengono uno score CVSS pari o maggiore
a 4 devono essere risolte entro 30 giorni pena la non validità del test.
NON SAMPLING
PCI-DSS
52
ISA Programme
Lanciato ufficialmente nel 2010, aggiunge la figura dell’ Internal Security
Assessor, rivolta a tutte le ISA Sponsor Companies (merchant, processor,
service provider o altra che deve essere conforme a PCI-DSS) per:



Migliorare i self assessment interni
Supportare l’applicazione dei requisiti di PCI-DSS
Interagire con i QSA
A questa figura non è però riconosciuto alcun ruolo ufficiale per la conformità
alla PCI-DSS.
PCI-DSS
53
Scadenze principali
31/07/2007 – VISA: Termine ultimo per la conformità dei merchant (solo
USA)
30/09/2009 – VISA: Termine ultimo per la non memorizzazione dei codici
di autorizzazione
31/12/2009 – Certificazione obbligatoria per legge in Nevada e Minnesota
30/06/2010 – Non più accettato l’uso del protocollo WEP
30/06/2010 – VISA: Non più accettato l’uso di applicazioni non conformi
PA-DSS
30/06/2010 – VISA: Non più accettato l’uso di device non conformi a PTS
30/09/2010 – VISA: Conformità a PCI-DSS dei merchant di livello 1
30/06/2011 – MC: Conformità a PCI-DSS dei merchant di livello 2 negli
USA, conformità a PCI-DSS dei merchant di livello 1
PCI-DSS
54
Statistiche: violazioni
81
Payment Card Data
36
Personal Information
31
Authentication Credentials
16
Account Numbers
13
Intellectual Property
Monetary Assets
11
Other
11
Corporate Financial Data
6%
6
3% 4%
Retail
6%
Financial Services
31%
6%
Food and Beverage
Manufacturing
Business Services
14%
Hospitality
Technology
30%
Other
Fonte: data breach investigation report 2009, Verizon Business
PCI-DSS
55
Ponemon Study, USA 2009



71% PCI non è un’iniziativa strategica, 79% ha sofferto violazioni di sicurezza
Incertezza su cui è internamente responsabile per PCI-DSS
Budget per PCI = 1/3 di quello per IT Security (in media $ 5M)
PCI-DSS
56
Mercato Italiano
2008


2009
2010
2011
2012
2013
2014
La conformità a PCI-DSS richiede tempo: tipicamente dai 6 ai 18 mesi
Ogni attore ha le sue opportunità come “early adopter”
PCI-DSS
57
Statistiche: conformità
Fonte: VISA CISP report 31/12/2009, i nuovi merchant hanno un anno di tempo
PCI-DSS
58
Sanzioni
Al momento è noto che solo un brand abbia erogato sanzioni ma un altro ha
reso pubblico un listino di multe:
VISA
A valle di compromissione se non compliant tra 5.000 e 25.000 $ a trimestre
A partire dal 2011, multe da 10.000 a 200.000 $ per evento, a seconda del
livello e della ripetizione
… e i merchant che subiscono violazioni possono essere “spostati” a livello 1!
PCI-DSS
59
Pro e Contro di PCI-DSS
Vantaggi
Svantaggi
• Opportunità per focalizzarsi
sulla sicurezza
• Allineata alle best practices di
sicurezza
• Possibilità di ottenere migliori
condizioni dagli Acquirer
• Ritorno di immagine verso i
Clienti (finali e non)
• Oneri aggiuntivi per l’azienda
• Prevede uno schema di
validazione proprietario
• Possibilità di ricevere sanzioni
dai Brand
• Difformità di gestione tra i
diversi Brand e incertezza
PCI-DSS
60
Materiale disponibile
Il sito www.pcisecuritystandards.org contiene una buona quantità di
documentazione online, di diversa natura e utilità. Diverse sono anche reperibili
nella versione italiana.










TUTTI GLI STANDARD
Self Assessment Questionnaire (tipo A, B, C, D-Merchant, D-TPP)
Security Scanning Procedures
Security Audit Procedures
Attestation of Compliance (AOC) legata a SAQ/ROC
Glossario
Guide (approccio prioritizzato, navigazione della norma)
Registro di QSA e ASV
Lista delle applicazioni validate
Lista dei TPP validati (prossimamente)
PCI-DSS
61
Altri Standard e PCI-DSS
PCI-DSS
62
Altri Standard e PCI-DSS
PCI-DSS può interfacciarsi utilmente all’interno di contesti in cui altri standard
già si applicano:






ITIL o ISO/IEC 20000
COBIT
ISO/IEC 27001
ISO/IEC 38500
Common Criteria o ISO/IEC 15408
Basilea 2
Oppure appoggiarsi a certi standard per la sua attuazione




OSSTMM e OWASP
BS 25999 o BS25777
ISO/IEC 27005
NIST SP800
PCI-DSS
63
Confronto con CobIT/ITIL
CobIT e ITIL (oltre a ISO/IEC 20000), hanno uno scope più allargato rispetto
ma sono comunque legati alle medesime tematiche di sicurezza.
PCI-DSS risulta completamente inclusa in entrambi.
CobIT
PCI-DSS
ITIL
Risk Control Matrix e mappature tra standard possono essere un primo passo
per individuare i punti di contatto.
PCI-DSS
64
Confronto con ISO/IEC 27001
I requisiti di PCI-DSS sono derivanti da standard e best practice di settore, non
sorprende quindi che siano completamente compresi nella ISO/IEC 27001.
Lo schema seguente riassume le principali differenze tra le norme.
PCI-DSS
ISO/IEC 27001
Scope fisso
Scope variabile
Contromisure uniformi
Contromisure selezionabili
Approccio prefissato al
rischio
Approccio reattivo al rischio
Contromisure dettagliate
Contromisure generali
Applicazione coatta
Applicazione opzionale
PCI-DSS
65
Confronto con ISO/IEC 27001
Esistono tre possibili scenari di interazione tra PCI-DSS e ISO/IEC 27001:
1. PCI-DSS e 27001 sono impostate ex-novo contemporaneamente
Requisiti fissati per parte dell’ambito
Risk assessment complessivo
Estensione delle contromisure tra le parti
2. Si aggiunge la PCI-DSS ad un contesto già 27001
Esportazione di prassi e processo in uso, effort ridotto
Integrazione di misure di sicurezza
3. Si aggiunge la 27001 ad un contesto già PCI-DSS
Confezionamento dei processi attorno all’ambito esistente, effort ridotto
Maggiore ritorno d’immagine
PCI-DSS
66
Riferimenti








www.pcisecuritystandards.org
www.visaeurope.com/aboutvisa/security/ais
www.visa.com/cisp
www.mastercard.com/sdp
www.americanexpress.com/datasecurity
www.discovernetwork.com/fraudsecurity/disc.html
www.jcb-global.com/english/pci
www.pciitalia.org
[email protected]
PCI-DSS
67