Payment Card Industry (PCI) 3.0 andEmerging Technologies

Adam Shnider

CISSP, CISM, CISA, QSA

Vice President, Coalfire Systems

State of the Union (Stats on Breaches)

SAQ Identification and 3.0 Changes

PCI 3.0 Scoping and Major Changes

Point to Point Encryption

Mobile Payment Applications

PCI in the Cloud

EMV and PCI

Agenda

What are we protecting?

PCI 101 Overview

Primary Account Number (PAN)

Cardholder Verification Number (CVN)

•Visa/Discover's Card Verification Value (CVV)

•Mastercard's Card Validation Code (CVC)

•Called Prohibited Data – can not retain after authorization

Track Data (from magnetic stripe)

PCI 101 Overview Merchant Levels

All Merchants Must meet PCI Standards• What you must do, and how you must validate are totally separate. (Compliance

vs. Validation)

• All merchants must be PCI compliant at all times

• Level 2, 3, and 4 merchants validate compliance through the SAQ and quarterly scans (except for MasterCard Level 2 merchants)

• PCI DSS 11.2 requires that all merchants perform external network scanning from an Approved Scan Vendor (ASV)

PCI 101 Overview

PCI 101 Overview VISA Compromise Statistics

• Over 90% of all compromised merchants are PCI level 4 (small) merchants or merchants with less than 1 million transactions per year

• Over 80% of compromised systems were “card present” or in person transactions

• Majority of compromise incidents involve use of vulnerable payment applications

• Over 50% of the merchants do not survive the breach … or undergo disruptive business changes

PCI DSS 3.0 – Business as Usual

The PCI SSC is pushing the concept of ongoing or continuous compliance management.

[See page 13 of the new PCI DSS 3.0 Standard for more information]

Monitoring of security controls Detect and respond to failures in security

controls Review all changes to the environment Organization structure changes Periodic reviews Annual hardware/software review

Identification of the correct SAQ is critical

Careful and close review of the “Eligibility to Complete” is critical (Part 2g of the SAQ form)

All criteria listed must be met to use the SAQ, otherwise another form should be explored

SAQ Identification with 3.0

SAQ Identification with 3.0 - Changes

Card-Not Present,

All Cardholder Data

Functions

Outsourced

Terminal and/or

Imprint Only, No

Cardholder Data

Storage

Payment

Application

Systems

Connected to the

Internet

All other methods

and Level 2 Service

Providers

SAQ A (13) (14)

SAQ A-EP (139)

SAQ B (28) (41)

SAQ B-IP (83)

SAQ C (80) (139)

SAQ C-VT (51) (73)

SAQ D (286)

(326 )

SAQ A includes a statement about the origination of pages

SAQ A-EP addresses redirection and segmentation specifically

SAQ A-EP sets a much higher bar for compliance than previously performed by SAQ A customers….but why

SAQ A vs. SAQ A-EP

Historically, merchants were believed to need to do nothing accept manage any hardcopy materials, vendor management and some policies requirements.

Modern day attacks are directed at the merchant to modify the redirection to the hosted page

Need controls for the following:

• Firewalls to protect servers calling hosted payment provider

• Server hardening, patching and anti-virus for web servers calling payment provider

• Physical security

• Logging and monitoring

• External scanning and penetration testing to identify risks

• Policies and procedures

SAQ A-EP – Why is it needed

SAQ B is focused on stand-alone DIAL-UP terminals

SAQ B-IP addresses NETWORK-CONNECTED terminals

SAQ B-IP provides better and more direct guidance than requiring the use of SAQ D

SAQ B vs. SAQ B-IP

It’s important to review the guidance on how to accurately determine the scope of a PCI DSS engagement and the intent of segmentation.

PCI DSS 3.0 Scope and Segmentation

Systems that provide security services to the CDE = “In Scope”

As per the PCI SSC “Segmentation = Isolation”

Scope Identification Process (for assessed organizations)

PCI-DSS and PA-DSS 3.0 Standards – What Comes Next?• Requires data flow diagrams and system inventory

• New/evolved processes

o Monitoring for systems that may be susceptible to malware

o Security considerations for authentication mechanisms

o Improved Penetration Testing methodology

• Maintaining compliance (Business As Usual)

PCI DSS 3.0 Changes

PCI DSS 3.0 Critical Changes

Even More Documentation

Documentation requirements have been emphasized more by the required

testing procedures.

Additional requirements for vendor documentation has also been added for

testing.

PCI DSS 3.0 More Critical Changes

Requirement 6.6 Flexibility

Added options to the interpretation of this requirement by changing “web-application

firewall” to “automated technical solution that detects and prevents web-based attacks”.

PCI DSS 3.0 More Critical Changes

Password Complexity Flexibility

Password complexity and strength requirements have been combined into

a single requirement and the PCI SSC has now allowed for some flexibility in

meeting these requirements.

PCI DSS 3.0 More Critical Changes

Protecting POS Terminals

Requires inventory, tracking and methods to identify tampering of

devices. This may require local resources to be able to identify compromised

devices. A method to continuously track devices.

PCI DSS 3.0 More Critical Changes

New Logging Events

Enhanced logging requirement to include stopping or pausing

of the audit logs.

Log Reviews for Critical Components

Daily or continuous log reviews have been split into two categories: Critical systems and

“Everything else”.

PCI DSS 3.0 More Critical Changes

Expanded Penetration Testing Expectations

The penetration testing requirements are much more detailed and

now require testing to validate segmentation technologies

(best practice until July, 2015).

PCI DSS 3.0 More Critical Changes

Service Provider Compliance Clarity

Requires Merchants to maintain information about which PCI DSS

requirements are managed by the service provider. Requires service

providers to provide clear documentation of controls they

manage.

Emerging Technologies

Emerging Technologies and PCI

• Present challenges as they may not be directly addressed by the PCI standards

• Technology is moving faster than the oversight bodies can/will update standards or even provide guidance

• Organizations are inventing new ways to accept payments that do not fit into the typical framework

• Organizations will not wait for regulations to change, it is the assessors and regulatory community that will need to adjust

Point to Point Encryption (P2PE)

Point-to-Point encryption (P2PE) was seen as having the

most immediate promise as an emerging technology.

Technologies that focused on encryption at the head in a

tamper resistant device/terminal with decryption happening

at the processor/acquirer provided the most PCI scope

reduction for merchants by removing the POS and some

down stream systems and processes from most PCI control

scope.

P2PE update Risk and Scope Reduction

P2PE Solutions

Card-present transactions only

Encrypted at the magnetic card reader and sent through systems and networks to a centralized decryption point

One of the highest scope reduction solution when decryption is done by a validated service provider and no cardholder data is ever in the possession of the merchant

Usually includes a tokenization option for card on file requirements to avoid storage by merchant

Reduces risk of data compromise because encryption occurs as early as possible

P2PE SolutionsPCI SSC Validated Solution Providers

• Reviewed by a PCI P2PE QSA and validated as compliant solution provider including the following:

• PinPad encryption mechanisms

• Key Injection processes for PinPad

• PinPad Application Security

• Decryption Environment

• Viable Solution Architectures

• Hardware/Hardware

• Hardware/Hybrid

• Only 3 officially validated solutions since May 2012 (2 years)

P2PE Solutions

Other Solutions

• Other solutions have emerged prior to and since the official P2PE Standard was released

• Solutions not officially listed by PCI SSC may also be viable options for implementation and scope reduction

• Acquiring bank should be included for using an alternative P2PE solution that is not listed by the PCI SSC

• Most alternative solutions will require third-party technical testing and documentation of the anticipated scope reduction in coordination with acquiring bank

• Risk reduction should be realized at a minimum with alternative solutions

Mobile Payments

Mobile Payment Applications

PCI SSC published and FAQ for mobile applications

• 3 categories of Mobile Payment Applications

• Only Category 1 (PTS-approved) and 2 (purpose-built and bundled) devices will be considered for PA-DSS

• Category 3 devices (smartphones/iPod touch) are becoming more prominent. Does not mean Category 3 applications cannot be used, but need to be custom built for merchants or delivered as part of a service

• PCI SSC control does not extend to consumer applications

Mobile Discussion

Outsource to validated service provider

P2PE

Mobile Guidance published September 2012

• Secure devices and networks

• Segmentation

• Tokenization and data elimination

• Secure coding

• Etc.

Cash only!!! :)

Mobile Discussion

Cloud and PCI

What is the “Cloud Computing”?• Cloud computing is a means “for enabling convenient, on-demand network access to a shared pool of

configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

– The NIST Definition of Cloud Computing, version 15 (Gaithersburg, Md., Oct. 7, 2009).

The Cloud

YES, it is possible, but know what you are getting

Identify a couple options for vendors (Cloud Service Providers)

Make sure the CSP is PCI validated (not just “compliant”)

Insist on getting a responsibility document from the CSP

Align your requirements with CSP responsibilities

Cloud and PCI Compliance

EMV (Chip and Pin) and PCI update

Fraud reduction not compliance reduction

Chip Data = Track Data

PCI is still applicable

No scope change with the introduction of EMV

EMV (Chip and maybe Pin) and PCI update

VisaNet Acquirers had to be prepared to accept EMV by April 2013

• Only includes the need to require Chip but PIN is still under debate

October 2015 for all POS (excluding fuel pumps)

October 2017 including fuel pumps

EMV Implementation Dates

Org Compliance Program Website

PCI SSC Payment Card Industry Security Standards Council www.pcisecuritystandards.org

VISA CISP (Cardholder Information Security Program) www.visa.com/cisp

MasterCard SDP (Site Data Protection) www.mastercard.com/sdp

AMEX DSOP (Data Security Operating Procedures) www.americanexpress.com/datasecurity

Discover DISC (Discover Information Security and Compliance) www.discovernetwork.com/DISC

JCB JCB Data Security Program www.jcb-global.com/english/pci

Resources

Q & A

Thank You!

Contact:

Adam Shnider

adam.shnider@coalfire.com

http://www.coalfire.com