pci standards, from participation to implementation and review
TRANSCRIPT
PCI STANDARDS, FROM PARTICIPATION TO IMPLEMENTATION AND REVIEW - THE
PCI DSS V3.2 PARADIGM
C. Stavropoulos (TW – PCI QSA)
S. Mavrovouniotis (FD – PCI ISA)
25 October 2016
WHO WE ARE AND HOW WE ARE INVOLVED
World’s leading third party financial service
provider. Around the world, 2,300 times every
second, First Data simplifies the connections that
make commerce possible for merchants, financial
institutions and their customers.
www.firstdata.com
Participating organization with certified Internal Security Assessors and
implementer of Security standards
Trustwave helps businesses fight cybercrime,
protect data and reduce security risk.
www.trustwave.com
Qualified Security Assessor Company
Approved Scanning Vendor Company
Payment Application Qualified Security Assessor Company (PA-QSA)
Qualified Security Assessors P2PE (QSA (P2PE)
Payment Application Qualified Security Assessors P2PE (PA-QSA (P2PE)
PCI Forensic Investigator Company
INTRODUCTION TO PCI COUNCIL
• PCI council (PCI SSC), founded in 2006, is an independent body, providing oversight of the development and management of Payment Card Industry Security Standards on a global basis.
• PCI council is founded from multi-national acceptance brand members: American Express, Discover, JCB, MC Worldwide and Visa Inc and has a board of advisors from the biggest companies of the payment industry.
• PCI Council provides the standards, their supporting documents, roster of approved solutions and devices based on those standards, list of approved auditors, guidelines, and education programs for its Members.
• PCI Council doesn’t enforce standards, and doesn’t assess against them, it just manages them.
• PCI Council trains and qualifies the auditors, and at times reviews their reports to ensure quality
•All Standards and resources are available from PCI Council’s site: https://www.pcisecuritystandards.org/
INTRODUCTION TO PCI COUNCIL
PCI council (PCI SSC) standards aim at the protection of cardholder payment data, during transit and at rest. The main standards published include:
PCI DSS
• covers the security of the environments that store, process or transmit account data
PCI PA DSS
•covers secure payment off-the-shelf applications
PCI PTS
•covers device tampering detection, cryptographic processes and other mechanisms to protect PIN
PCI P2PE
•covers encryption, decryption and key management within secure cryptographic devices (from Hardware to Hardware)
PCI PIN
•covers secure management, processing and transmission of PIN data during online and offl ine payment card transaction processi ng
PCI Card Production
• covers the processes to generate and distribute a card and its PIN
INTRODUCTION TO PCI COUNCIL
Standards Life Cycle
Year 0
• October: standard gets published
Year 1
• January: standard gets effective and implemented in the market
• November: Feedback on the standard begins
• December: previous version retires
Year 2
• April -August: feedback is reviewed
• November –April: Draft revision begins
Year 3
• May July: Final review
• October:next version gets published
THE PCI DSS STANDARD Six Goals
Twelve Requirements
INTRODUCTION TO PCI DSS
December 2004 (PCI DSS 1.0): MasterCard, Visa, American Express, Discover, and JCB create payment card safe practices. The companies collaborated to create a concise and specific set of compliance standards. The first security standard managed by al participating brands for merchants and other organizations in the payment processing lifecycle
September 2006 (PCI DSS 1.1): Created the PCI Security Standards Council, an independent group that manages the standard; Implemented requirements for web facing applications
October 2008 (PCI DSS 1.2): New requirements for wireless networks protection and antivirus fro all operating systems
October 2010 (PCI DSS 2.0): Streamlines the assessment process
November 2013 (PCI DSS 3.0): Emphasizes provider compliance and best practice for day to day operations. The standard is active from January 1, 2014 to December 31, 2015
April 2015 (PCI DSS 3.1): The Council issues an updated version of the standard and ends the three year cycle. Clarifications are provided for existing controls and weak encryption for transmitted data is not an evolving New Requirement. The Standard will be retired in October 31. 2016
April 2016 (PCI DSS 3.2): Eight New requirements are introduces based on market trends and feedback from the industry. Multifactor Authentication is now required for both remote and local access.
The Story…
THE COMPLIANCE CYCLE
Assess - identifying all locations of cardholder data, taking an inventory of your IT assets and business processes for payment card processing and analyzing them for vulnerabilities that could expose cardholder data.
Repair - fixing identified vulnerabilities, securely removing any unnecessary cardholder data storage, and implementing secure business processes.
Report - documenting assessment and remediation details, and submitting compliance reports to the acquiring bank and card brands you do business with (or other requesting entity if you’re a service provider).
Compliance is a on-going cycle of assessment, remediation, and reassessment
The three on-going steps for adhering to the PCI DSS
Assess
Repair
Report
WHOM DOES PCI DSS AFFECT?
The standard applies to all card network members, merchants and service providers that store, process, or transmit cardholder data.
Specific Compliance requirements are based on service provider or merchant level. Compliance levels are determined by the type of the entity assessed and transaction volumes.
The responsibility to enforce the PCI DSS lies with the Acquiring Banks (organizations that initiate and maintain relationships with merchants for the acceptance of payment cards).
The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data.
The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment.
Connected to components are components that can affect the security of the cardholder data or the systems in the cardholder data environment (CDE) .
“System components” include network devices, servers, computing devices, and applications.
Security Services, Network, Virtualization, NTP servers
2. Do not use vendor-supplied
defaults for system passwords
and other security parameters
1. Install and maintain a
firewall configuration to
protect cardholder data
Build and Maintain a
Secure Network and
Systems
Protect cardholder
data
Maintain a vulnerability management
program
Implement strong access
control measures
Regularly monitor and
test networks
Maintain an information
security policy
SIX GOALS, TWELVE REQUIREMENTS
Secure network perimeter protected infrastructure
Secure system baseline reliable platform
2. Do not use vendor-supplied
defaults for system passwords
and other security parameters
1. Install and maintain a
firewall configuration to
protect cardholder data
4. Encrypt transmission of
cardholder data across open,
public networks
3. Protect stored cardholder
data
Build and Maintain a
Secure Network and
Systems
Protect Cardholder
Data
Maintain a vulnerability management
program
Implement strong access
control measures
Regularly monitor and
test networks
Maintain an information
security policy
Encrypted, truncated data reduced risk to data
Secure communications prevent data leakage
SIX GOALS, TWELVE REQUIREMENTS
6. Develop and maintain
secure systems and
applications
5. Protect all systems against
malware and regularly update
antivirus software or programs
2. Do not use vendor-supplied
defaults for system passwords
and other security parameters
1. Install and maintain a
firewall configuration to
protect cardholder data
4. Encrypt transmission of
cardholder data across open,
public networks
3. Protect stored
cardholder data
Build and Maintain a
Secure Network and
Systems
Protect Cardholder
Data
Maintain a Vulnerability Management
Program
Implement strong access
control measures
Regularly monitor and
test networks
Maintain an information
security policy
Active Anti-virus prevent bypassing
of security controls
Secure systems secure handling of
confidential data
SIX GOALS, TWELVE REQUIREMENTS
7. Restrict access to
cardholder data by
business need to know
8. Identify and
authenticate access to
system components
Build and Maintain a Secure Network
Protect cardholder
data
Maintain a vulnerability management
program
9. Restrict physical access to
cardholder data
Implement Strong Access
Control Measures
Regularly monitor and
test networks
Maintain an information
security policy
Authenticated users ensure
accountability
Proper access control prevent information
misuse and exposure
Secure facilities prevent data theft
SIX GOALS, TWELVE REQUIREMENTS
7. Restrict access to
cardholder data by
business need to know
8. Identify and
authenticate access to
system components
Build and Maintain a Secure Network
Protect cardholder
data
Maintain a vulnerability management
program
9. Restrict physical access to
cardholder data
Implement Strong Access
Control Measures
11. Regularly test security
systems and processes
10. Track and monitor all
access to network resources
and cardholder data
Regularly Monitor and
Test Networks
Maintain an information
security policy
Track system events prompt discovery of
anomalies and policy violations
Identify and fix vulnerabilities prevent weakness
exploitation
SIX GOALS, TWELVE REQUIREMENTS
7. Restrict access to
cardholder data by
business need to know
8. Identify and
authenticate access to
system components
Build and Maintain a Secure Network
Protect cardholder
data
Maintain a vulnerability management
program
9. Restrict physical access to
cardholder data
Implement Strong Access
Control Measures
11. Regularly test security
systems and processes
10. Track and monitor all
access to network resources
and cardholder data
Regularly Monitor and
Test Networks
12. Maintain a policy
that addresses
information security
for all personnel
Maintain an Information
Security Policy
Formalize and enforce security policies and
procedures ensure consistency in data security
SIX GOALS, TWELVE REQUIREMENTS
6. Develop and maintain
secure systems and
applications
5. Protect all systems against
malware and regularly update
antivirus software or programs
2. Do not use vendor-supplied
defaults for system passwords
and other security parameters
1. Install and maintain a
firewall configuration to
protect cardholder data
4. Encrypt transmission of
cardholder data across open,
public networks
3. Protect stored
cardholder data
7. Restrict access to
cardholder data by
business need to know
8. Identify and
authenticate access to
system components
Build and Maintain a
Secure Network and
Systems
Protect Cardholder
Data
Maintain a Vulnerability Management
Program
9. Restrict physical access to
cardholder data
Implement Strong Access
Control Measures
11. Regularly test security
systems and processes
10. Track and monitor all
access to network resources
and cardholder data
Regularly Monitor and
Test Networks
12. Maintain a policy
that addresses
information security
for all personnel
Maintain an Information
Security Policy
SIX GOALS, TWELVE REQUIREMENTS
PCI DSS 3.2 The Change
PCI SECURITY STANDARDS V3.2
Released April 2016
Feedback from Industry
Changing payment and threat environment
Attack trends in breach reports
PCI DSS is a “MATURE” Standard and no more 3 year cycle
Summary of Key Charges
Accommodate Updated migration dates for SSL/early TLS
Support for display for PAN beyond first six/last four
Incorporate some Business-As-Usual (BAU) Requirements (Future- Dated)
Expand multi-factor authentication requirement
PCI SECURITY STANDARDS V3.2
Evolving Requirement - Changes to ensure that the standards are up to date with emerging threats and changes in the market.
3 for both Merchants and Service providers
5 only for Service Providers
Additional guidance -Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Clarification - Clarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.
Three Change Types
47
3
8
PCI DSS 3.2
CLARIFICATION ADDITIONAL GUIDANCE
EVOLVING REQUIREMENT
PCI SECURITY STANDARDS V3.2Key Dates to Note!
New PCI DSS 3.2 is released and available
from PCI SCC
April 28th 2016
PCI DSS Version 3.1 will be retired
All Assessments after this date must be with
Version 3.2 (ROC/AOC/SAQ)
October 31st 2016
FINAL DATE to implement “Evolving
Requirements”
February 1st 2018
EVOLVING REQUIREMENT This requirements are best
practice until January 31, 2018,
after which they become a
requirement.
NEW REQUIREMENTS FOR PCI DSS 3.2
PCI DSS requirement 3.3 - to ensure that only the minimum number of digits are displayed as necessary to perform a specific business function.
PCI DSS requirement 6.4.6 - Ensure security controls are in place following a change in the cardholder data environment have a process to analyze how changes may impact the environment and the security controls that
organizations rely on to protect cardholder data
PCI DSS requirement 8.3 - Multi-factor authentication as a requirement for any personnel with non-console administrative access to the systems handling card data, so that a password alone is not enough to verify the user’s identity and grant access to sensitive information
Both for Merchants and Service Providers
NEW REQUIREMENTS FOR PCI DSS 3.2
PCI DSS requirement 3.5.1 – service providers to maintain a documented description of the cryptographic architecture.
PCI DSS requirement 10.8 – outline that service providers need to detect and report on failures of critical security control systems
PCI DSS requirement 11.3.4.1 - indicates that service providers need to perform penetration testing on segmentation controls every six months.
PCI DSS requirement 12.4 - for executive management of service providers to establish responsibilities and a PCI DSS compliance program.
PCI DSS requirement 12.11 - asks that service providers perform quarterly reviews to confirm that personnel are following security policies and operational procedures
For Service Providers only
IMPLEMENTATION AND REVIEW Examples in Enforcing
Requirements
ASSESSOR’S APPROACH FOR REVIEW
Market Update Draft Version Internal
Review
and
Feedback
New Release
Requirements
Sampling
Guidelines
BAU Update
IMPLEMENTER’S APPROACH
Gap Analysis – Second Step (if necessary)
Documentation Update Assessments per BU & Action Plan
Gap Analysis - First Step
Against other Standards Against Corporate Global Docs.
New Version gets Published
Review Changes Identify Potential Gaps
TYPES OF CHANGES WITH EXAMPLES
• Agree on Understanding and Evidence
• Confirm status • Evidence for Implementation
Changes already addressed
(ex. Change Management)
• Agree on Understanding and Evidence
• Action Plan • Evidence for Implementation
Small Changes
(ex. Crypto Architecture)
• Agree on Understanding and Evidence
• Action Plan• Secure Budget and Resources
• Evidence for Implementation
Bigger Changes
(ex. 2FA, Pen Tests)
WORKING TOGETHER
TAKE AWAYS
Internal SMEs & Training
Up to Date with standards
Work Together with the auditors and not against
them
Compliance like Security requires time, people and
budget
Compliance like Security is an
ongoing and never ending process
THANK YOUEfstathios Mavrovouniotis
Christos Stavropoulos