20.03.2014_guasconi-morini

Transcript

PCI-DSS, terza versione
20 Marzo 2014, Security Summit, Milano
Sezione 0
PREMESSA
© 2014 BL4CKSWAN S.r.l. – Pagina 2
Speakers
Fabio Guasconi + Francesco Morini
Fabio Guasconi





Direttivo CLUSIT e UNINFO
Presidente del ISO/IEC JTC1 SC27 di UNINFO
QSA dal 2009
CISA, CISM, PCI-QSA, ITIL, ISFS, Lead Auditor 27001 & 9001
Partner e co-founder Bl4ckswan S.r.l.
Francesco Morini
 QSA dal 2008
 CISSP, OPST, CCNA, PCI-QSA, ITIL, ISFS, Lead Auditor 27001 & 9001
 Partner e co-founder Bl4ckswan S.r.l.
BL4CKSWAN
FONDAZIONE
ESPERIENZA DEI SOCI FONDATORI
2012 a Milano, Italia da parte di 4 soci
54 anni uomo sul mercato italiano e internazionale
SETTORE
PROPRIETA'
Consulenza
Direzionale
Italiana
100%
Sicurezza delle
Informazioni
SERVIZI FORNITI
Governance
Risk
Compliance
PARTECIPAZIONI
PRINCIPALI SETTORI SERVITI
Servizi ICT
23%
18%
59%
Finance
Trasporti
Energetico
Telco
Aerospaziale
BASI OPERATIVE
Agenda
PCI-DSS
in pillole
COSA cambia nella
nuova versione
COME allinearsi
allo standard
QUAL E' la situazione
del mercato
Sezione 1
PCI-DSS IN PILLOLE
PCI-DSS in pillole
cosa è – i diretti interessati – requisiti – applicare lo standard - timeline
PCI-DSS in pillole
•
Risultato dell’unione dei security programs dei principali circuiti di carte di credito.
•
Definisce i requisiti per implementare un processo di sicurezza per l’acquisizione, elaborazione,
trasmissione e memorizzazione (cardholder data processing).
•
Lo standard si applica a qualsiasi entità che:
•
Supporta direttamente o indirettamente uno o più processi di cardholder data processing.
•
Svolga delle attività che possano alterare la capacità di protezione di uno o più processi.
PCI-DSS in pillole
Quando c’è di mezzo un PAN...
Esercenti
Istituti di pagamento
•
•
•
Online
MOTO
Brick and Mortar
•
•
•
•
•
•
•
GDO
Trasporti
Retail
Government
Professionisti privati
Fornitori di Servizi
Acquirer
Issuer
•
Payment Gateway
•
•
•
Body Rental
Managed Security Services
Remote Storage locations *
PCI-DSS in pillole
no domini, solo tematiche (e pure vecchie):
Progettazione
Rete
Configurazione
sistemi e apparati
Cifratura dati
“at-rest”
Cifratura dati
“in-transit”
Implementazione
di “Sec-Techs”
Patch + Change
Management
Sviluppo Sicuro
del Software
Profilazione
Utenze
Autenticazione
Sicurezza fisica
perimetrale
Sicurezza fisica
supporti
Logging e
Monitoraggio
Audit Tecnico
Gestione
Fornitori
Incident
Management
Analisi del
Rischio
Politiche per la
Sicurezza
Ruoli e
Responsabilità
PCI-DSS in pillole
Fonte: Verizon 2014 PCI Compliance Report
PCI-DSS in pillole
VISA
Mastercard
Amex
Discover
JCB
Livello 1
>6M Transazioni
Violazione subita
l’anno precedente
>6M Transazioni
Violazione subita
l’anno precedente
VISA Livello 1
>2,5M Transazioni
>6M Transazioni
Livello 1 per altro
Brand
>1M Transazioni
Violazione subita
l’anno precedente
Livello 2
Tra 1M e 6M
Transazioni
Tra 1M e 6M
Transazioni
VISA Livello 2
Tra 50K e 2,5M
Transazioni
Tra 1M e 6M
Transazioni
Livello 2 per altro
Brand
<1M Transazioni
Livello 3
Tra 20K e 1M
Transazioni ecommerce
Tra 20K e 1M
MasterCard e
Maestro
VISA Livello 3
Meno di 50K
Transazioni
Tra 20K e 1M
Livello 3 per altro
Brand
N/A
Livello 4
< 20K Transazioni
e-commerce
Tutti gli altri
merchant <1M
Transazioni
Tutti i merchant
non compresi nei
precedenti
N/A
Tutti i merchant
non compresi nei
precedenti
N/A
PCI-DSS in pillole
if Level = 1
ROC
4x ASV
if Level = 2,3,4
SAQ
4x ASV
PCI-DSS in pillole
A
?
B
?
C
• Applicabile a contesti caratterizzati dalla totale esternalizzazione dei processi di
payment processing presso una terza parte.
• L’entità non acquisisce, memorizza, elabora e/o trasmette dati di carta attraverso i propri
sistemi e/o all’interno della propria sede.
• Il dato di carta (PAN) viene memorizzato esclusivamente su supporto cartaceo.
13
C
VT
D
requisiti
1
2
3
4
5
6
7
8
9
10
11
12
PCI-DSS in pillole
A
?
B
?
C
C
• Applicabile a contesti di payment processing basati esclusivamente sull’utilizzo di
terminali di vendita (POS, PED, PDQ, etc. ) e/o macchinette stampigliatrici.
• I terminali sono considerati “stand-alone”, ovvero unicamente collegati ad un payment
gateway mediante una connessione autonoma e dedicata.
• I terminali non sono in alcun modo connessi ad altri ambienti del sistema informativo
29
dell’entità.
VT
D
requisiti
1
2
3
4
5
6
7
8
9
10
11
12
PCI-DSS in pillole
A
?
B
?
C
• Applicabile a contesti di payment processing basati sull’utilizzo di una payment
application la quale non esegue archiviazione del dato.
• L’entità non memorizza, elabora o trasmette dati di carta in formato digitale sui propri
sistemi e/o all’interno della propria sede.
80
C
VT
D
requisiti
1
2
3
4
5
6
7
8
9
10
11
12
PCI-DSS in pillole
A
?
• Applicabile a contesti di payment processing basati sull’utilizzo di Virtual POS, a cui si
accede via browser.
B
• Il virtual POS deve essere fornito, attivo e gestito presso/da una terza parte.
?
• Il virtual POS deve poter essere acceduto solo da un insieme di postazioni di lavoro
C
C
dedicate e non comunicanti con altri ambienti del sistemi informativo.
51
VT
D
requisiti
1
2
3
4
5
6
7
8
9
10
11
12
PCI-DSS in pillole
A
?
B
?
• Applicabile a contesti di payment processing basati su modelli che non rientrano nelle
opzioni descritte nei SAQ A, B, C e C-VT.
• Il processo di payment processing è tipicamente caratterizzato dalla conservazione dei
dati di carta.
C
288
C
VT
D
requisiti
1
2
3
4
5
6
7
8
9
10
11
12
PCI-DSS in pillole
La compliance PCI DSS è un’attività onerosa... ma serve?
Essere compliant non è un
...ma è un buon punto d’inizio...
PCI-DSS in pillole
2004
2006
2008
2011
2014
V1.0
V1.1
V1.2
V2.0
V3.0
2009
2012
2013
Web applications
Wireless
Mobile POS
Tokenisation
Virtualization
Mobile payment apps
PCI-DSS in pillole
Sezione 2
COSA CAMBIA NELLA NUOVA VERSIONE
Cosa cambia nella nuova versione
Nuovi requisiti – Requisiti spostati – Requisiti cambiati e chiariti – Requisiti rimossi
La versione 3.0 di PCI-DSS è fondamentalmente una
riedizione della versione precedente riorganizzata e chiarita
 Aggiunta delle guidelines nello standard (prima erano separate)
 Aggiunta di sezione relativa al "Business as usual" per il mantenimento nel tempo della
conformità a PCI-DSS
 Spostamento del ROC reporting in un template separato ad uso dei QSA
 Miglioramento delle procedure di testing
 Chiarimento della criticità dei SAD indipendentemente dal PAN
11 nuovi
requisiti
24 requisiti
spostati
8 requisiti
cambiati e
chiariti
1 requisito
dismesso
1.1.3 Current diagram that shows all cardholder data flows across systems and
networks
2.4 Maintain an inventory of system components that are in scope for PCI-DSS
environment for implementing PCI DSS controls.
5.1.2 For systems considered to be not commonly affected by malicious software,
perform periodic evaluations to identify and evaluate evolving malware threats in
order to confirm whether such systems continue to not require anti-virus software
5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or
altered by users, unless specifically authorized by management on a case-by-case
basis for a limited time period.
6.5.10 (Address common coding vulnerabilities on …)
Broken authentication and session management
1 Luglio
2015
8.5.1 Service providers with remote access to customer premises (for example, for
1 Luglio
support of POS systems or servers) must use a unique authentication credential
2015
(such as a password/phrase) for each customer
8.6 Where other authentication mechanisms are used (for example, physical or
logical security tokens, smart cards, certificates, etc.), use of these mechanisms must
be assigned as follows:
- Authentication mechanisms must be assigned to an individual account and
not shared among multiple accounts.
- Physical and/or logical controls must be in place to ensure only the intended
account can use that mechanism to gain access.
9.3 Control physical access for onsite personnel to the sensitive areas as follows:
- Access must be authorized and based on individual job function.
- Access is revoked immediately upon termination, and all physical access
mechanisms, such as keys, access cards, etc., are returned or disabled
9.9 Protect devices that capture payment card data via direct physical interaction
with the card from tampering and substitution.
1 Luglio
2015
11.3 Implement a methodology for penetration testing that includes the
following:
- Is based on industry-accepted penetration testing approaches (for example, NIST
SP800-115)
- Includes coverage for the entire CDE perimeter and critical systems
- Includes testing from both inside and outside the network
- Includes testing to validate any segmentation and scope-reduction controls
1 Luglio
- Defines application-layer penetration tests to include, at a minimum, the
2015
vulnerabilities listed in Requirement 6.5
- Defines network-layer penetration tests to include components that support
network functions as well as operating systems
- Includes review and consideration of threats and vulnerabilities experienced in the
last 12 months
- Specifies retention of penetration testing results and remediation activities results
12.9 Service providers acknowledge in writing to customers that they are
responsible for the security of cardholder data the service provider possesses or
1 Luglio
otherwise stores, processes, or transmits on behalf of the customer, or to the extent
2015
that they could impact the security of the customer’s cardholder data environment.
2.2.2 Enable only necessary services, protocols, daemons, etc., as required
for the function of the system.
2.2.2
2.2.3 Implement additional security features for any required services,
protocols, or daemons that are considered to be insecure
3.1
3.1.1
3.1 Keep cardholder data storage to a minimum by implementing data
retention and disposal policies, procedures and processes that include at
least the following for all cardholder data (CHD) storage: …
3.5.2
3.5.2 Store secret and private keys used to encrypt/decrypt cardholder
data in one (or more) of the following forms at all times:
- Encrypted with a key-encrypting key that is at least as strong as the
data-encrypting key, and that is stored separately from the dataencrypting key
- Within a secure cryptographic device (such as a host security
module (HSM) or PTS-approved point-of-interaction device)
- As at least two full-length key components or key shares, in
accordance with an industry-accepted method
3.5.3 Store cryptographic keys in the fewest possible locations
6.1
6.2 Ensure that all system components and software are protected from
known vulnerabilities by installing applicable vendor-supplied security
patches. Install critical security patches within one month of release.
6.2
6.1 Establish a process to identify security vulnerabilities, using reputable
outside sources for security vulnerability information, and assign a
risk ranking (for example, as “high,” “medium,” or “low”) to newly
discovered security vulnerabilities.
8.4
8.2.1 Using strong cryptography, render all authentication credentials
(such as passwords/phrases) unreadable during transmission and storage
on all system components.
8.5.2
8.2.2
Verify user identity before modifying any authentication
credential—for example, performing password resets,
provisioning new tokens, or generating new keys.
8.5.6
8.1.5 Manage IDs used by vendors to access, support, or maintain system
components via remote access as follows:
- Enabled only during the time period needed and disabled when not in use
- Monitored when in use
8.5.7
8.4 Document and communicate authentication procedures and policies
to all users including:
- Guidance on selecting strong authentication credentials
- Guidance for how users should protect their authentication credentials
- Instructions not to reuse previously used passwords
- Instructions to change passwords if there is any suspicion the
password could be compromised
8.5.10
8.5.11
8.2.3 Passwords/phrases must meet the following:
- Require a minimum length of at least seven characters.
- Contain both numeric and alphabetic characters.
Alternatively, the passwords/phrases must have complexity and strength at
least equivalent to the parameters specified above
8.5.16
8.7 All access to any database containing cardholder data (including
access by applications, administrators, and all other users) is restricted as
follows:
- All user access to, user queries of, and user actions on databases are
through programmatic methods.
- Only database administrators have the ability to directly access or query
databases.
- Application IDs for database applications can only be used by the
applications (and not by individual users or other non-application
processes).
9.6
9.5 Physically secure all media.
9.7
9.6 Maintain strict control over the internal or external distribution of any
kind of media, including the following.
9.8
9.6.3 Ensure management approves any and all media that is moved from a
secured area (including when media is distributed to individuals).
9.9
9.7 Maintain strict control over the storage and accessibility of media.
9.10
9.8 Destroy media when it is no longer needed for business or legal reasons
as follows
11.3
11.3.3 Exploitable vulnerabilities found during penetration testing are corrected
and testing is repeated to verify the corrections
1.5 Ensure that security policies and operational procedures for managing
firewalls are documented, in use, and known to all affected parties.
2.5 Ensure that security policies and operational procedures for managing
vendor defaults and other security parameters are documented, in use, and
known to all affected parties
12.1.1
3.7 Ensure that security policies and operational procedures for protecting
stored cardholder data are documented, in use, and known to all affected
parties.
4.3 Ensure that security policies and operational procedures for encrypting
transmissions of cardholder data are documented, in use, and known to all
affected parties.
5.4 Ensure that security policies and operational procedures for protecting
systems against malware are documented, in use, and known to all affected
parties.
6.7 Ensure that security policies and operational procedures for developing
and maintaining secure systems and applications are documented, in use,
and known to all affected parties.
7.3 Ensure that security policies and operational procedures for restricting
access to cardholder data are documented, in use, and known to all affected
parties.
12.1.1
8.8 Ensure that security policies and operational procedures for identification
and authentication are documented, in use, and known to all affected parties.
9.10 Ensure that security policies and operational procedures for restricting
physical access to cardholder data are documented, in use, and known to all
affected parties.
10.8 Ensure that security policies and operational procedures for monitoring
all access to network resources and cardholder data are documented, in use,
and known to all affected parties.
12.1.1
11.6 Ensure that security policies and operational procedures for security
monitoring and testing are documented, in use, and known to all affected
parties.
12.1.2
12.2 Implement a risk-assessment process that:
- Is performed at least annually and upon significant changes to the
environment (for example, acquisition, merger, relocation, etc.),
- Identifies critical assets, threats, and vulnerabilities, and
- Results in a formal risk assessment.
12.1.3
12.1.1 Review the security policy at least annually and update the policy when
the environment changes
12.9
12.10 Implement an incident response plan. Be prepared to respond
immediately to a system breach
1.1.6 Documentation and business justification for use of all services,
protocols, and ports allowed, including documentation of security features
implemented for those protocols considered to be insecure.
Examples of insecure services, protocols, or ports include but are not
limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2
6.5 Address common coding vulnerabilities in software-development processes as
follows:
- Train developers in secure coding techniques, including how to avoid common
coding vulnerabilities, and understanding how sensitive data is handled in
memory.
- Develop applications based on secure coding guidelines
6.6 … Installing an automated technical solution that detects and prevents webbased attacks (for example, a web-application firewall) in front of public-facing web
applications, to continually check all traffic
7.1.1 Define access needs for each role, including:
- System components and data resources that each role needs to access for
their job function
- Level of privilege required (for example, user, administrator, etc.) for accessing
resources.
10.2.5 Use of and changes to identification and authentication mechanisms—
including but not limited to creation of new accounts and elevation of
privileges—and all changes, additions, or deletions to accounts with root or
administrative privileges
11.1.1 Maintain an inventory of authorized wireless access points including a
documented business justification
11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect
and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the
cardholder data environment as well as at critical points in the cardholder data
environment, and alert personnel to suspected compromises.
11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring
tools) to alert personnel to unauthorized modification of critical system files,
configuration files, or content files; and configure the software to perform critical file
comparisons at least weekly.
7.1.4 Implementation of an automated access control system
Sezione 3
COME ALLINEARSI ALLO STANDARD
Come allinearsi allo standard
Partendo dalla 2.0 – Partendo da zero – Strategie per l'ottimizzazione – Interazione con altre norme – Nuovi SAQ
Ragionando per priorità:
PCI-DSS v 3.0
SAQ
A-EP
Priorità 0: verifica dei nuovi SAQ (se applicabile)
SAQ
B-IP
Priorità 1: nuovi requisiti e requisiti modificati in vigore
subito
Priorità 2: nuovi requisiti e requisiti modificati in vigore
dal 1 Luglio 2015
Per chi deve affrontare in toto la PCI-DSS conviene orientarsi direttamente verso la 3.0
L'approccio consigliato rimane per il resto lo stesso, come schematizzato di seguito:
Scoping
Gap
analysis
Remediation
Preaudit
Audit
SAQ
Livelli ≠ 1
Vediamo come ottimizzare l'implementazione di alcuni dei nuovi requisiti:
1.1.3 Current diagram that shows all cardholder data flows across systems and
networks
 arricchire i diagrammi esistenti con i flussi è la strada più semplice
 può essere una buona occasione per aggiornare i flussi censiti
5.1.2 For systems considered to be not commonly affected by malicious
software, perform periodic evaluations …
 non avete ancora uno scadenziario per le attività periodiche? E' arrivata l'ora
11.3 Implement a methodology for penetration testing …
 se è un fornitore esterno sceglietene uno che già usi una metodologia
documentata
 se è svolto internamente il NIST SP800-115 costituisce un'ottima guida anche
presa direttamente
Gestione dei service provider o dei merchant (dove applicabile)
Gli standard del Council sono sempre di più, cosa si applica a chi?
PA-QSA
 l'uso di applicazioni certificate permette di non dover verificare come sono state
sviluppate (ma solo che siano state installate e configurate correttamente)
PTS
 non ci sono particolari legami tra PCI-PTS e PCI-DSS
P2PE
 una soluzione certificata P2PE può essere utilizzata per ridurre l'ambito di
applicazione della PCI-DSS soprattutto dove vi sono più punti di acquisizione dati
Card Production
 non ci sono particolari legami tra i requisiti per la Card Production e PCI-DSS
A
• Applicabile a contesti di payment processing basati su modelli “card not present”.
A
• Totale esternalizzazione dei processi di payment processing presso una terza parte, certificata PCI
EP
DSS.
B
• Il sito dell’esercente non raccoglie il dato di carta, e gestisce il reindirizzamento verso il payment
B
IP
processor.
C
• Il sito dell’esercente è isolato da qualsiasi altro elemento infrastrutturale.
C
• Il pagamento è effettuato attraverso infterfacce gestite dal payment processor..
VT
D
105
• La memorizzazione di dati di carta è svolta esclusivamente su supporti cartacei.
• Applicabile esclusivamente a canali “e-commerce”.
requisiti
1
2
3
4
5
6
7
8
9
10
11
12
A
• Applicabile a contesti di payment processing basati esclusivamente sull’utilizzo di terminali di vendita
(POS, PED, PDQ, etc. ) certificati PCI PTS.
A
EP
• I terminali sono connessi mediante IP al payment processor.
B
• I terminali non sono in alcun modo connessi ad altri ambienti del sistema informativo dell’esercente,
B
IP
inclusi dispostivi.
C
C
• Non applicabile a modelli di pagamento basati su e-commerce.
VT
62
D
requisiti
1
2
3
4
5
6
7
8
9
10
11
12
Sezione 4
QUAL E' LA SITUAZIONE DEL MERCATO
Qual è la situazione del mercato
Mercato mondiale – Mercato italiano
56.2% of North America organizations complied with 80%+ of controls
75.0% of Asia-Pafic organizations complied with 80%+ of controls
31.3% of European organizations complied with 80%+ of controls
Fonte: Verizon 2014 PCI Compliance Report
Qual è la situazione del mercato
Mercato mondiale – Mercato italiano
 Lo scudo "stiamo lavorando su SEPA" sta venendo meno per le banche europee
 I principali acquirer italiani iniziano a concludere le loro certificazioni
 Il mercato nazionale si sta arricchendo di attori che entrano nel settore
 Nuove modalità di pagamento (mobile POS, NFC) pongono nuove sfide per la
sicurezza dei dati relativi alle carte di pagamento
 Alcune associazioni di settore stanno iniziando a mettersi insieme per cercare strade
comuni e meno onerose d'accordo con i Brand
 Le controllanti e i partner stranieri iniziano a spingere per traguardare un
allineamento a PCI-DSS
 Il Garante per la Privacy sta studiando misure per tutelare i dati personali tra i dati
relativi alle carte di pagamento
Per riassumere …
No PCI-DSS Compliance?

20.03.2014_guasconi-morini

Transcript

Documenti analoghi

Gli Obiettivi della PCI-DSS

PCI-DSS

GlobalTrust RMS

Credit Card Authorization Form

Modulo FAST CLAIM Data/ Date

Configurazione Porte - eMule-Wiki

La Comunità Educante risponde.. di Kristian Galanti

Prodotti e Servizi per gli

Configurazione Firewalls - eMule-Wiki

AVG Internet Security

The SonicWALL Advantage

kit chiavi “security lock”