P2PE and other PCI DSS changes

1. P2PE AND OTHER PCI DSS
CHANGES
OCTOBER 19, 2012
1

2. Agenda
• PCI Standards and Typical Card data flow
• Data breaches, Threats and existing Mitigation efforts
• P2PE overview and Concept
• Benefits
• Preparing for P2PE
• ControlCase P2PE offerings
2

3. PCI Family of Standards
Protection of Cardholder Payment Data
Software Developers Merchant &
Manufacturers Processors
PCI PA – DSS PCI Security
PCI PTS PCI DSS
Pin Entry Devices Payment Application
Data Security
& Compliance
Vendors
Standard
3

4. Typical Payment Method
Encrypted at
Communication Layer
Encrypted at
Communication Layer
Encrypted at
Communication Layer
Acquirer / PG
4

5. Typical Payment Method
May or may not be May or may not be
encrypted encrypted
CHD CHD
Acquirer / PG
5

6. Data Breaches
6

7. Industry groups represented by
percent of breaches
Source: 2012 data breach investigations report by Verizon
7

8. Top 10 Threat Action Types by number
of breaches and records
Source: 2012 data breach investigations report by Verizon
8

9. Where should Mitigation efforts be
focused?
9 Source: 2012 data breach investigations report by Verizon

10. Addition of member in PCI Family
Acquires,
Payment
Software Gateways Merchant &
Manufacturers Developers Software Processors
PCI PTS PCI PA – DSS Developers, PCI DSS
Pin Entry Payment KIFs
Data Security
Devices Application
Vendors PCI Standard
P2PE
10

11. What is PCI P2PE?
 It is either a solution or Application.
 P2PE Solution
A point-to-point encryption solution consists of point-to-point encryption and
decryption environments, the configuration and design thereof, and the P2PE
Components that are incorporated into, a part of, or interact with such environment.
 P2PE Application
A software application that is included in a P2PE Solution and assessed per P2PE
Domain 2 Requirements, and is intended for use on a PCI-approved point-of-
interaction (POI) device or otherwise by a merchant.
 P2PE Components
Any application or device that stores, processes, or transmits account data as part
of payment authorization or settlement, or that performs cryptographic key
management functions, and is incorporated into or a part of any P2PE Solution.
11

12. P2PE Concept
Encrypted at POI
Encrypted at POI
Encrypted at POI
POI HSM
Encrypts data Decrypted by HSM at
immediately after P2PE Solution
reading Provider
Acquirer / PG
12

13. P2PE Concept cont..
Encrypted at POI
Encrypted at POI
Encrypted at POI
PTS devices with
SRED (secure HS
reading and
exchange of M
FIPS 140-2 Level 3
data) listed as a (or higher) certified
“function provided”. or PCI-approved
Acquirer / PG
13

14. Benefits
Stakeholders in the payments value chain benefit from these requirements in a
variety of ways, including but not limited to the following:
 Customers may choose to implement Validated P2PE Solutions in order to
reduce the scope of their PCI DSS assessments.
 Listed P2PE Solutions have been validated as compliant with the P2PE
Standard by P2PE Assessors.
 Recognized by all Participating Payment Brands
14

15. Characteristics for Merchants Eligible for Reduced
Scope for PCI DSS via P2PE Solutions
 Use validated P2PE solution
 Never stores, processes, or transmits clear-text account data within
their P2PE environment outside of a PCI-approved POI device.
 Physical environment controls for POI terminals, third-party
agreements, and relevant merchant policies and procedures are in
place.
 Followed the P2PE Instruction Manual (PIM), provided to the
merchant by the P2PE Solution Provider.
 Adequately segmented (isolated) the P2PE environment from any
non-P2PE payment channels or confirmed that no other channels
exist.
 Removed or isolated any legacy cardholder data, or systems that
stored, processed, or transmitted cardholder data, from the P2PE
environment.
15

16. P2PE – Key Points
 It is OPTIONAL
 P2PE scenarios (e.g. hardware-hardware)
 Requires the use of SCDs for encryption and decryption of account data and
management of cryptographic keys.
 POI devices must be PCI SSC approved PTS devices with SRED (secure
reading and exchange of data) listed as a “function provided.”
 HSMs must be either FIPS 140-2 Level 3 (or higher) certified or PCI-approved
(listed on the PCI SSC website, with a valid SSC listing number, as Approved
PCI PTS Devices under the approval class “HSM”).
 Applications with access to clear-text account data must undergo validation per
all P2PE Domain 2 Requirements
16

17. Relationship between P2PE and other PCI
standards (PCI DSS, PA-DSS, PTS, and PIN)
 POI devices must meet PIN Transaction Security (PTS)
requirements validation.
 Cryptographic-key operations for both encryption and
decryption environments use key-management practices
derived from the PTS PIN Security Standard.
 Applications on POI devices meet requirements derived
from the Payment Application Data Security Standard
(PA-DSS).
 The decryption environment is PCI DSS compliant.
 P2PE standard does not supersede or replace any
requirements in the PCI PIN Security Requirements
17

18. PA-DSS Applicability to P2PE
 Applications used within P2PE Solutions may
or may not be eligible for PA-DSS validation.
 Both are distinct PCI SSC standards with
different requirements
 Validation against one of these standards does
not guarantee or provide automatic validation
against the other standard.
18

19. P2PE Domains
Domain 1
Encryption Device
Domain 2 Domain 3
Management Application Security Encryption Environment
Use Approved devices and Secure applications in the Secure environments where
protect devices from P2PE environment POI devices are present
tampering
Domain 4 Domain 5 Domain 6
Transmission between Decryption Environment
P2PE Cryptographic Key
encryption and Decryption and Device Management
Operations
Environments Secure decryption
environments and decryption Use strong cryptographic
Secure operations between keys and secure key-
encryption and decryption devices
environments management functions
19

20. Domain 1
Environments with Encryption, Decryption, and Key Management within Secure
Cryptographic Devices
Domain Characteristics P2PE validation P2PE validation
Requirements Responsibility
Domain 1: • POI is a PCI- 1A Build PCI-approved P2PE Solution Provider
Encryption Device approved POI POI devices.
Management device.
1B Securely manage
Use secure encryption • POI device managed equipment used to
devices and protect by solution provider. encrypt account data.
devices from
tampering. • Hardware encryption
performed by device.
20

21. Domain 2
Environments with Encryption, Decryption, and Key Management within Secure
Cryptographic Devices
Domain Characteristics P2PE validation P2PE validation
Requirements Responsibility
Domain 2: • Application on a PCI- 2A Protect PAN and Application Vendor
Application Security approved POI SAD.
device. P2PE Solution Provider
Secure applications in 2B Develop and
the P2PE • All applications are maintain secure
environment. assessed as part of applications.
the validated P2PE
solution. 2C Implement secure
application
management
processes.
21

22. Domain 3
Environments with Encryption, Decryption, and Key Management within Secure
Cryptographic Devices
Domain Characteristics P2PE P2PE validation
validation Responsibility
Requirements
Domain 3: • No storage of CHD after 3A Secure POI P2PE Solution Provider
Encryption transaction processes are devices throughout
Environment complete. the
• Within the segmented device lifecycle.
Secure applications P2PE environment, no
in the P2PE CHD stored, processed, or 3B Implement
environment. transmitted through secure device
channels or methods management
external from an approved processes.
SCD.
• All device-administration 3C Maintain P2PE
and cryptographic Instruction Manual
operations are managed by for
solution provider. merchants.
• The P2PE Instruction
Manual (PIM) for
22 merchants, with instructions
on how to implement and

23. Domain 4
Environments with Encryption, Decryption, and Key Management within Secure
Cryptographic Devices
Domain Characteristics P2PE validation P2PE validation
Requirements Responsibility
Domain 4: • All decryption
Segmentation operations managed
between Encryption by solution provider.
and Decryption • Merchant has no
Environments access to the Domain 4 has no applicable requirements for
encryption this hardware/hardware scenario.
Segregate duties and environment (within
functions between POI device) or
encryption and decryption
decryption environment.
environments. • Merchant has no
involvement in
encryption or
decryption
operations.
23

24. Domain 5
Environments with Encryption, Decryption, and Key Management within Secure
Cryptographic Devices
Domain Characteristics P2PE validation P2PE validation
Requirements Responsibility
Domain 5: • Decryption 5A Use approved P2PE Solution Provider
Decryption environment decryption devices.
Environment and implemented at and
Device Management managed by solution 5B Secure all
provider. decryption systems and
Secure decryption • Merchant has no devices.
environments access to the
and decryption decryption 5C Implement secure
devices. environment. device management
• Decryption processes.
environment must be
PCI DSS compliant. 5D Maintain secure
decryption environment.
24

25. Domain 6
Environments with Encryption, Decryption, and Key Management within Secure
Cryptographic Devices
Domain Characteristics P2PE validation P2PE validation
Requirements Responsibility
Domain 6: P2PE • All key- 6A Use secure encryption P2PE Solution Provider
Cryptographic management methodologies.
Key Operations functions
implemented and 6B Use secure key generation
Use strong managed by methodologies.
cryptographic solution provider
keys 6C Distribute cryptographic
and secure key- • Merchant has no keys in a secure manner.
management involvement in key
functions. management 6D Load cryptographic keys in
operations a secure manner.
6E Ensure secure usage of
cryptographic keys.
6F Ensure secure
25 administration of
cryptographic keys.

26. At a Glance – Illustration of a typical P2PE
Implementation and Associated Requirements
26

27. Developing and Validating a P2PE Solution
Note: Domain 4 is greyed out in the diagram below as there are no applicable
27 requirements in this Domain for the current phase of P2PE.

28. Overview of P2PE Solution Validation Processes
The P2PE Solution Provider selects a P2PE Assessor
The P2PE Solution Provider then provides access to the P2PE Solution to the P2PE
Assessor
The P2PE Assessor determines the scope and assesses key-injection facilities,
Certification Authorities and others, Device, Applications
Preparation of P-ROV and P-ROV (if applicable) and submitting to PCI SSC for Review
Review of P-ROV and Application P-ROV (if applicable) by PCI SSC
28

29. How to Prepare for P2PE Assessment
Prepare following
1. Be ready with approved POI Devices, HSM
2. List of applications used
3. Detailed cryptographic key matrix
4. P2PE Instruction Manual
5. Implementation Guides for applications
assessed against Domain 2
6. Key-management procedures and
7. Change control documentation
29

30. Revalidation of P2PE
 Yearly Interim Assessment (Healthcheck)
 Full Re-assessment after 2 years
30

31. ControlCase P2PE offerings
 Guidance on designing P2PE Solutions
 Review of P2PE Solution design
 Guidance on preparing the P2PE Instruction
Manual
 Pre-assessment (“gap” analysis) services
 Guidance for bringing the P2PE Solution into
compliance with the P2PE Standard if gaps or
areas of non-compliance are noted during the
assessment.
 Certifying P2PE solutions and Applications
31

32. Questions And Answers
32

33. Thank You
33