ISC2 Hellenic Chapter 25/10/2016

1. 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

2. 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

3. INTRODUCTION TO PCI COUNCIL
• PCI council (PCI SSC), founded in 2006, is an independentbody, providing oversight of the development and
management of Payment CardIndustry 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 supportingdocuments, 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/

4. 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 environmentsthat 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 offline payment card transaction processi ng
PCI Card Production
• covers the processes to generate and distribute a card and its PIN

5. 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

6. THE PCI DSS STANDARD Six Goals
Twelve Requirements

7. 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…

8. 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

9. 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 sensitiveauthentication 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

10. 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
strongaccess
control
measures
Regularly
monitor and
test networks
Maintain an
information
security
policy
SIX GOALS, TWELVE REQUIREMENTS
 Secure networkperimeter  protected infrastructure
 Secure systembaseline reliableplatform

11. 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
strongaccess
control
measures
Regularly
monitor and
test networks
Maintain an
information
security
policy
 Encrypted, truncated data  reducedrisk to data
 Secure communications preventdata leakage
SIX GOALS, TWELVE REQUIREMENTS

12. 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
strongaccess
control
measures
Regularly
monitor and
test networks
Maintain an
information
security
policy
 ActiveAnti-virus  preventbypassing
of security controls
 Secure systems secure handlingof
confidentialdata
SIX GOALS, TWELVE REQUIREMENTS

13. 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 preventinformation
misuse and exposure
 Secure facilitiespreventdata theft
SIX GOALS, TWELVE REQUIREMENTS

14. 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 discoveryof
anomaliesand policyviolations
 Identify and fix vulnerabilitiespreventweakness
exploitation
SIX GOALS, TWELVE REQUIREMENTS

15. 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
 Formalizeand enforce security policiesand
proceduresensure consistencyin data security
SIX GOALS, TWELVE REQUIREMENTS

16. 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

17. PCI DSS 3.2 The Change

18. 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

19. 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

20. PCI SECURITY STANDARDS V3.2
Key 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

21. EVOLVING REQUIREMENT
This requirements are best
practice until January 31, 2018,
after which they become a
requirement.

22. 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

23. 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

24. IMPLEMENTATION AND REVIEW Examples in Enforcing
Requirements

25. ASSESSOR’S APPROACH FOR REVIEW
Market Update Draft Version Internal
Review
and
Feedback
New Release
Requirements
Sampling
Guidelines
BAU Update

26. 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

27. 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)

28. WORKING TOGETHER

29. 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

30. THANK YOU
Efstathios Mavrovouniotis
Efstathios.Mavrovouniotis@firstdata.com
Christos Stavropoulos
CStavropoulos@trustwave.com