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
http://www.coalfire.com