Highlights from2016 North America Community Meeting
John MarkhStandards Manager, PCI Security Standards Council
Educate. Empower. Protect.
PCI DSS
PA-DSS
PTS (HSM, POI, PIN)
P2PE
Card Production (Logical, Physical)
Token Service Providers
PCI SSC trains over
5,000+security professionals
globally every year
Global StructureAssessor Community
2,061QSAs
1,718ISAs
19PFIs
2,418PCIPs
107ASVs
Common Approach to Payment Security
Unified voice for industryUnified approach
for validation
Consistent training and educational material
Consistent security requirements for all payments
- 7,729 Questions answered
- 1,100+ FAQs
- Thousands of pages of guidance
- 1,063 currently listed applications
- 737 PTS-lab tested devices
- 2,061* trained assessors
- 4,906 trained ISAs and PCIPs
- 13,228 people trained
- Card Production, Provisioning,
HSM, Applications, PIN-entry,
token service providers…
PTS Labs
France
China
SERMA Lab
By Year-end
Canada
U.S.A.
U.K.
The Netherlands
Germany
Australia
Technology Solutions
P2PE QSA Assessors: P2PE PA-QSA Assessors:
Training here this week in Las Vegas:
Listed Solutions:Solutions in Queue:
Listed Applications:Applications in Queue:
Listed Components:Components in Queue:
Certifications and what’s in the pipeline:
49
35
9
23
9
47
4
3
5
P2PE Solution Listings – Historical Perspective
PCI-Listed P2PE Solutions – Cumulative View
0
5
10
15
20
25 84.6% increase since last year
* Data current as of August 2016
• Migrating away from stored account data
• Account data being protected even if breached
• Common coding flaws being detected prior to coming to market
• Awareness of payment data risks and PCI compliance
“Sony Encrypted PlaystationUsers’ Credit Cards” - Forbes
“Don’t need it, Don’t Store it” - Wall Street Journal
Overall Improvements in Payment Security
Current and FutureThreat Landscape
Breaches can be Prevented
Breaches were preventable − caused by known vulnerabilities with
fixable patches
99.9% 76% 67%
Companies took weeks or more to discover breach
Organizations did not adequately test
the security of all in-scope systems
Diversity of Payment Acceptance
• Mobile Payments
• Growth in e-commerce
• Growth in merchants accepting payments
Reliance on Software
New coding platforms and developers
Agile programming and speed of updates
Need for app developer education
Need new approaches to secure development and testing
Contactless Payments Vulnerabilities
Card Not Present Fraud
Account Takeover
Ransomware
Future Threats
Man in the Middle Attack
The Road Ahead
Qualified Security Assessors (QSAs)
The Goal:“Business As Usual” Approach to Security
Security is a 24x7 Mentality
Not a Check-The-Box once a year and be done
Detection Monitoring and Incident Response
Staying Current
Ensuring Continued Excellence of QSAs
The Growth of QSAs
2,061 QSAs
The Growth of QSAs
The Common Goal
Devalue Data: Make it useless for criminals
Point-to-Point Encryption
Tokenization
EMV
Software Security Framework
Continued Focus on Small Merchants
Mobile
3D Secure 2.0
Token Service Provider
Card Production
Mobile Task Force
International Collaboration
Upcoming Dates for PCI DSS and PA-DSS
Dates for PCI DSS and PA-DSS
April, 2016
•PCI DSS 3.2 is Released
May 2016
•PA-DSS 3.2 is Released
September 1, 2016
•PA-DSS 3.1 is Retired
October 28, 2016
•PA-DSS 2.0 applications moved to “Acceptable only for Pre-Existing Deployment”
October 31, 2016
•PCI DSS 3.1 is Retired
February 1, 2018
•PCI DSS 3.2 “Best Practices” become requirements.
October 28, 2019
•PA-DSS 3.1 Administrative, Low Impact and No Impact Changes Deadline
•PA-DSS 3.1 Application moved to “Acceptable only for Pre-Existing Deployment”
Overview of PCI DSS v3.2
PCI DSS – Then and Now
PCI DSS v1.0 – v1.1
• 12 high-level requirements
• Layered security
• Based on industry-accepted security best practices
• Allows for use of Compensating Controls
PCI DSS v3.2
• 12 high-level requirements
• Layered security
• Based on industry-accepted security best practices
• Allows for use of Compensating Controls
20162006
What Has Changed
• More guidance added over time
• Increased flexibility for some requirements
• Evolving requirements – e.g.:
− What is considered “strong” cryptography
− Physical security of POI devices
• Summary of Changes
• Glossary
• ROC template, SAQs, AOCs
• Prioritized Approach
• Information Supplement: Migrating from SSL/Early TLS
What’s New in v3.2
What’s New in 3.2
Multi-Factor Authentication
Change Management
Service Provider Updates
New Appendices for SSL/TLS and DESV
Masking formats
“Future Dated” Requirements for PCI DSS
Best Practice until January 31, 2018:
• All entities• 6.4.6 – “All relevant PCI DSS requirements must be implemented on all new or changed systems and
networks.”• PCI DSS Requirement 8.3.1 – “Incorporate multi-factor authentication for all non-console access into the
CDE for personnel with administrative access.”
• Service Providers• 3.5.1 – “Maintain a documented description of the cryptographic architecture.”
• 10.8 and 10.8.1 – “Implement a process for the timely detection and reporting of failures of critical security control systems.”
• 11.3.4.1 – “Confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.”
• 12.4.1 – “Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program.”
• 12.11 and 12.11.1 – “Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.”
Appendices in PCI DSS 3.2
Appendices in PCI DSS 3.2
Appendix A: Additional PCI DSS Requirements
• Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers
• Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS
• Appendix A3: Designated Entities Supplemental Validation
Appendices in PCI DSS 3.2Appendix A3: Designated Entities Supplemental Validation (DESV)
• An entity is required to undergo an assessment according to this Appendix ONLY if instructed to do so by an acquirer or a payment brand.
• These supplemental validation steps are intended to provide greater assurance that PCI DSS controls are maintained effectively and on a continuous basis, including:• More frequent (every 6 months) penetration testing on segmentation controls
• Data-discovery methodology
• Mechanisms for detecting and preventing clear-text PAN from leaving the CDE
• Immediate detection and alerting on critical security control failures
• Review user accounts and access privileges to in-scope system components at least every six months
• Quarterly review of BAU activities
PAN Masking Formats
PAN Masking Formats
• “First six / last four” baseline
• Business justification for any format that displays more than first six and/or last four PAN digits
Multi-factor Authentication
Understanding “Multi-Factor Authentication”
• Updated terminology
− “two-factor” replaced with “multi-factor”
− Does not change intent of original requirement
− Still can’t use one factor twice
• MFA already required for all remote access to the CDE
• Now also required for personnel with non-console administrative access into the CDE
Multi-Factor Authentication in v3.2
New Requirement 8.3.1
Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
This requirement is a best practice until January 31, 2018,
after which it becomes a requirement.
SSL / Early TLS Requirements
Dates for PCI DSS and PA-DSSSSL/early TLS Requirements
New implementations must not use SSL or early TLS as a security control.
To support entities working to migrate away from SSL/early TLS:
• All service providers must provide a secure service offering by June 30, 2016.
• Prior to June 30, 2018, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
• After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol.
• POS POI terminals that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after June 30, 2018.
SSL/early TLS RequirementsReporting Difference between PCI DSS 3.1 and PCI DSS 3.2
• For PCI DSS 3.1:• FAQ 1372 – “How should entities apply the new SSL/TLS migration dates to Requirements 2.2.3, 2.3
and 4.1 for PCI DSS v3.1?”, and
• FAQ 1373 – “How should entities complete their ROC or SAQ for PCI DSS v3.1 using the new SSL/TLS migration dates?” provide additional guidance.
• For PCI DSS 3.2:• Appendix A2 should be completed for entities using SSL/early TLS as a security control:
• Not only Requirements 2.2.3, 2.3 and 4.1!
• FAQ 1440 provides additional guidance when requirements in Appendix A2 are applicable.
SSL/early TLS Requirements
• All entities, including service providers, are required to migrate to secure version of TLS by June 30, 2018.
• Service providers are also required to offer a secure alternative to SSL/early TLS by June 30, 2016.
Service Providers
SSL/early TLS RequirementsPOS POI Terminals
• POS POI terminals that can be verified as not being susceptible to any known exploits for SSL/early TLS: • If SSL/early TLS is not needed in the environment, use of and fallback to
these versions should be disabled.
• terminal provider and/or acquirer (merchant bank) may be able to help to determine the POS POI terminals are affected by the vulnerabilities.
• When assessing SSL/early TLS implementation, review supporting documentation (for example, documentation provided by the POI vendor, system/network configuration details, etc.)
SSL/early TLS Requirements“New” vs. “Existing” Implementations
• New implementations must not use SSL or early TLS as a security control:• Implementations are considered “new implementations” when there is no existing
dependency on the use of the vulnerable protocols.
• Conversely, “existing” implementations are those where there is a pre-existing reliance or use of a vulnerable protocol(s).
• If a new implementation does not need to support a pre-existing use of a vulnerable protocol, use only secure protocols and strong cryptography, and do not allow fallback to the vulnerable protocol.
SSL/early TLS RequirementsSecure Version of TLS
• TLS 1.2 is the currently recommended version of the protocol.• TLS 1.2 is a more secure version of the protocol
• helps to “Future proof” the deployment
• TLS 1.1 can potentially meet PCI DSS requirements for “strong cryptography” depends on:• For what purpose it is used…
• How it is configured…
• What ciphers it uses…
• If assessing an environment which relies on TLS 1.1 as a security control, refer to NIST SP 800-52 rev 1 for guidance on secure TLS configurations.
2017 SIG Process
History
• Over a dozen guidance documents produced since 2010
• Collaboration with the industry
SIG Process
SIG Proposals from Community
Selection of Proposals for Vote
Objectives Created from Proposal
Develop Table of Contents
Content Developed through Iterative Process
Role of SIG Participants
Facilitates discussions,
preparation of deliverables,
and approvals
Provide subject matter
expertise and develop content
Review and final approval
PCI SSC Chair
SIG Members Payment Brands’
Technical Working Group
& Management Committee
2017 SIG Process
• Selection from existing SIG collateral
• Election occurs after the EU CM
• Announce topic(s) selected
• Open SIG participation sign-up
• 2017 SIG begins in January
• Best Practices for Implementing a Security Awareness Program
• Best Practices for Maintaining PCI DSS Compliance
• Skimming Prevention: Best Practices for Merchants
• PCI DSS Risk Assessment Guidelines
• PCI DSS Tokenization Guidelines
• PCI DSS Wireless Guidelines
• PCI DSS Cloud Computing Guidelines
• PCI DSS Virtualization Guidelines
PCI Guidance and Best Practices
PCI Guidance and Best Practices
• Building a security awareness program
• Protecting against malware
• Skimming prevention
• Defending against phishing attacks
• Working with third parties
• Maintaining PCI DSS compliance
• Accepting payments with a mobile phone
Available at: www.pcisecuritystandards.org
Upcoming Guidance
Protecting Telephone-based Payment Card Data
Scoping and Segmentation
Q & A