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!