Upload
hoangquynh
View
228
Download
6
Embed Size (px)
Citation preview
Payment Card Industry Compliance Standards
1. Introduction
2. Target audience
3. Payment Card Ecosystem
4. Ecosystem Participants
5. Payment Ecosystem Regulators
6. Focus & Common Goals
7. Responsibilities & Co‐operation
8. Standards versus Specifications
9. Comparison PCI DSS versus EMVCo
10.Differing but Complementing
11.PCI DSS versus ISO27001
12.Q&A Session
OverviewOverview
Introduction - The SpeakerIntroduction - The Speaker
Martin Petrov
Martin Petrov is an experienced information systems audit and security professional who is a Certified Information Systems
Security Professional (CISSP) , Certified Information System Auditor (CISA) and former Qualified Security Assessor (QSA ).
Martin’s extensive network within the industry coupled with expert knowledge and over 10 years of infosec experience hasenabled him to provide vendor agnostic advice to organizations on adopting best‐practice implementation of complianceprograms. This led Visa Europe and Visa CEMEA to select Martin as the lead trainer for the delivery of a series of 2 dayTraining Seminars across their respective regions during the past 3 years.
Martin has worked as an Information Security Consultant and Qualified Security Assessor on various enterprise scaleprojects for customers such as government agencies, ministries, banks, international corporations, blue chip serviceproviders as well as a number of small and middle sized companies.
Martin joined One‐SEC in 2005, Europe’s leading QSA company as the principle European information security consultant. In2007 One‐SEC was acquired by the global QSA company leader Trustwave where Martin continued as full time Lead PCI DSSauditor and executed over 75 compliance audits for a significant number of European processors, acquiring banks, paymentservice providers and large merchants. Martin joined Onformonics in September 2008 to help develop a merchant risk basedcompliance management portal.
Martin co‐founded NTT Security in 2009 to provide audit and consulting services to acquirers, merchants, service providersand the card schemes as a subject matter expert having the highest level of expertise within the Payment Card Industryhelping organisations implement & successfully maintain their PCI compliance programs.
Government Regulators
Industry Regulators
Payment Schemes
Card Brands
Merchants
Service Providers
Payment Application Developers
Payment Hardware Developers
Acquirers
Issuers
Delegate CompositionDelegate Composition
Ecosystem ParticipantsEcosystem Participants
Member Banks Issuers Acquirers
Service Providers Gateways Processors ISOs/MSPs Wallet Providers
Merchants Face to Face E‐Commerce / M‐Commerce Mail Order / Telephone Order
Consumer Users
Government Regulators Central Banks Payment Council Financial Conduct Authorities
Payment Card Industry Regulators PCI SSC EMVCo
d Brands / Schemes Visa MasterCard American Express JCB Discover Union Pay
Card Ecosystem Industry RegulatorsCard Ecosystem Industry Regulators
To facilitate the worldwide interoperability & acceptance of secure payment transactions by managing & evolving EMV Specifications & related testing processes.
Defines Specifications for card & terminal evaluation, security evaluation, management of interoperability issues. EMV Specifications for contact chip, contactless chip, common payment application (CPA), card personalization, and tokenization.
The PCI Security Standards Council goal is to develop, enhance, disseminate and assist with the understanding of security standards for payment card security.
Helps merchants & financial institutions understand and implement standards for security policies, technologies & processes that prevent theft of cardholder data.Helps software & hardware vendors understand & implement standards for creating secure payment solutions.
FocusFocus
Interoperability
By developing Technology Specifications for Electrical, Mechanical & Communication Protocol characteristics for:
ICC Chips Terminals Tokenisation Authentication
Security
By developing Security Standards that address People, Processes & Technology where Account Data is present:
Payment Environments Payment Applications Hardware Components Card Issuance Environments
Common GoalsCommon Goals
1. Royalty Free Global Standards2. Standardised, Interoperable & Secure Ecosystem3. Foundation for innovative payment products & solutions
ResponsibilitiesResponsibilities
Owns and manages PCI DSS and related standards
Defines common audit requirements
Manages certification process for QSA, PA‐QSAs, ASVs, PFI, P2PE‐QSA, QIR, ISA
Maintain lists of Validated Applications & Solutions
Enforce and monitor compliance – fines, deadlines
Establish PCI DSS validation requirements
Manage communications, education & support
Manage and evolve EMV Specifications
Perform product testing & certification
Enhance payment security
Support emerging payment technologies
Product development
Specify EMV mandates
Provide Commercial incentives
Define fraud liability shift policy
Co-operationCo-operation
NFC Forum
GlobalPlatform
GSM Alliance
PCI SSC
AFSCM
APSCA
ACT Canada
ETSI
European Payments Council
Smart Card Alliance
EMV Migration Forum
+60 EMVCo Technical Associates
+60 EMVCo Business Associates
NFC Forum
EMVCo
European Card Payment Association
GSM Alliance
European Payments Council
Smart Card Alliance
+750 PCI SSC Participating Organisations
Standards and SpecificationsStandards and Specifications
EMV v4.3
EMV Common Payment Application Specification (CPA) v1.0
EMV Card Personalization Specification (CPS) v1.1
EMV Contactless v2.6
EMV Mobile Payment v1.0
EMV Payment Tokenisation v1.0
EMV 3D Secure v2.0
PCI DSS v3.2
PA‐DSS v3.2
PCI P2PE v2.0
PCI PTS v2.0
Card Production Logical Security Requirements v1.1
Card Production Physical Security Requirements v1.1
PCI TSP v1.1 (EMV Payment Tokens)
Elements of a Payment CardElements of a Payment CardAccou
nt Data
10 20 30
; 5 1 0 5 1 0 5 1 0 5 1 0 5 1 0 0 = 0 3 1 5 2 0 1 1 2 3 4 5 9 9 9 0 0 0
Sta
rting
Sen
tinal
PA
N
Del
imite
r / S
epar
ator
Exp
iratio
n D
ate
Ser
vice
Cod
e
PV
V
CV
V /
CV
C
Dis
cret
iona
ryD
ata
Track Data
PCI DSS Standards EcosystemPCI DSS Standards Ecosystem
Ecosystem of payment devices, applications, infrastructure and users
PCI DSSPCI DSS
1. The PCI DSS security requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server, or application that STORES, PROCESSES OR TRANSMITS Cardholder Data.
2. System components that are included in or are CONNECTED to the Cardholder Data Environment.
3. Or could IMPACT THE SECURITY of the cardholder data environment.
PeopleProcesses
Technologies
StoreProcessTransmit
Account Data(CHD + SAD)
Cardholder Data environment
PA DSSPA DSSApplicable to software developers & integrators of applications that:
Store, process or transmit cardholder data as part of authorization or settlement
When these applications are sold, distributed or licensed to third parties.
PA DSS principles can be applied to in‐house & 3rd party developed custom applications, but such applications are covered by SDLC requirements within PCI DSS. PA DSS is not applicable
Use of PA DSS compliant application by itself does not make an entity PCI DSS compliant.
PA DSS validated payment applications are included in the scope of a PCI DSS assessment – their configuration and use are tested
Validated applications are listed on the PCI SSC websiteTypes: Card Not Present, POS Admin,POS F2F, POS Kiosk, POS Specialized, POS Suite, Back Office, Gateway / Switch, Middleware, Fuel Dispenser, Payment Module, Settlement, Shopping Cart & Store Front
PCI PTSPCI PTS
PCI PTS is a set of security requirements focused on characteristics and management of devices used in the protection of cardholder PINs and other payment processing related activities.
The requirements are for manufacturers to follow in the design, manufacture and transport of a device to the entity that implements it.
Financial institutions, processors, merchants and service providers should only use devices or components that are tested and approved by the PCI SSC.
Validated devices are listed on the PCI SSC website.
P2PEP2PE
A combination of secure devices, applications and processes that encrypt Account Data from the point of interaction (for example, at the point of swipe or dip) until the data reaches the solution provider’s secure decryption environment – i.e. as it travels through the merchant IT environment
Eliminates storage and availability of plain text Account Data by means of encryption, which is implemented at the payload level as opposed to the connection / communication link level
P2PE Encrypted Data Encrypted Data
Reduced PCI DSS Scope
EMVEMV
A set of requirements to ensure interoperability between chip‐based payment cards and terminals which additionally provide:
Card authentication, protecting against counterfeit cards. The card is authenticated during the payment transaction, protecting against counterfeit cards. Card validation either online by the issuer using a dynamic cryptogram or offline with the terminal using Static, Dynamic or Combined Data Authentication. EMV transactions also create unique transaction data, so that any captured data cannot be used to execute new transactions.
Cardholder verification, authenticating the cardholder and protecting against lost and stolen cards. EMV supports four cardholder verification methods (CVM): offline PIN, online PIN, signature, or no CVM
Transaction authorization, using issuer‐defined rules either online and offline. For an online authorization information is sent to the issuer, along with a transaction‐specific cryptogram, and the issuer either authorizes or declines the transaction. In an offline EMV transaction, the card and terminal communicate and use issuer‐defined risk parameters that are set in the card to determine whether the transaction can be authorized. Offline transactions are used when terminals do not have online connectivity.
Note: EMV Specification only defines protection by means of encryption of the Card’s PIN number and not any of the other elements, such as PAN, Track Data, etc.
P2PE & EMVP2PE & EMV
Phase Protects PIN Protects PAN Reduces Scope
EMV
P2PE
EMV (Chip‐and‐PIN) is a great anti‐fraud mechanism for F2F EMV environments
complements PCI DSS controls
provides cardholder authentication
doesn’t provide confidentiality of the PAN or Tack Data
does not protect card‐not‐present transactions
EMV transactions are in scope for PCI DSS use of EMV compliant terminals does not make an entity PCI DSS compliant
3D Secure3D Secure 3D Secure is a technical standard created by Visa and MasterCard to further secure
CNP (Cardholder Not Present) transactions over the Internet. Version 1.0 remains under management of Visa, while v2.0 was transitioned under management of EMVCo
MasterCard brand their system as 'Secure Code' and Visa call theirs 'Verified by Visa', American Express call it 'SafeKey'
Is an online, real time service that allows E‐commerce merchants to validate that a cardholder is the owner of a specific account number.
The service requires that cardholders register/enroll their card at their issuer's website. Once a card is activated with the 3D Secure service, the card number will be recognised whenever a consumer purchases at participating online merchant. The consumer enters his/her password or SMS OTP code in the 3D Secure window, the consumer's identity is then verified, and the transaction is completed.
3D Secure payment security creates what is called a 'trust chain‘ throughout the transaction, shifting the liability for fraud from the merchant to the issuer under a range of conditions.
Implementation of 3D Secure does not make a Merchant PCI DSS compliant
EMV TokenisationEMV Tokenisation
Tokenization refers to a process which replaces sensitive cardholder data (the PAN in particular) with a non-sensitive token that represents the data and may not be easily or readily monetized.
Tokenization eliminates the storage of actual cardholder data to bring the following benefits:
– Scope reduction by allowing fewer system components to have access to real cardholder data
– Account Data security can be improved when data encryption is combined with tokenization
– Avoids the complexity of key management requirements when replacing encryption
c46dbbb08c9fb89df5513fafa2d814cb95893bd9
4608 9895 5132 8145
Differing but ComplementingDiffering but ComplementingPCI DSS EMV
• Protect Account Data
• Reduce Fraud
• Liable for fraud & compromise
if not compliant
• Ensures Account Data Can not be Stolen
• Covers People, Processes & Technology
• Covers both Card Present & Card Not Present
• Prevents Criminals from using stolen Cards
• Provides Cardholder Verification
• EMV Covers Card Present Transactions
• 3D Secure Covers Card Not Present transactions
• Qualifying organizations can self‐assess
PCI DSS versus ISO27001PCI DSS versus ISO27001
PCI DSS
HIPAA
CobIT
ISO 27001
SOX 404
PrescriptiveGeneric
Con
sist
ency
of C
ontro
ls
Exp
ertis
e R
equi
red
PCI DSS versus ISO27001PCI DSS versus ISO27001
ISO 27002:2005
Appropriate, timely action should be taken in response to the identification of potential technical vulnerabilities. The following guidance should be followed to establish an effective management process for technical vulnerabilities:
A timeline should be defined to react to notifications of potentially relevant technical vulnerabilities;
PCI DSS v3.2
6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor‐supplied security patches installed. Install critical security patches within one month of release.
Note: An organization may consider applying a risk based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public‐facing devices and systems, databases higher than less‐critical internal devices ), to ensure high‐priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.
PCI DSS versus ISO27001PCI DSS versus ISO27001
Topic PCI DSS ISO 27000
Compliance Mandates Compliance Mandatory Compliance Voluntary
Scope Defined by Functioning Levels Vision and Objectives
Degree of Compliance Must Meet All Requirements Voluntary
Separation of Systems High Low
Degree of Flexibility Low High
Question and AnswersQuestion and Answers
Any Questions?
The EndThe End
Thank You!