Pci standards, from participation to implementation and review

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

http://www.firstdata.com/

http://www.trustwave.com/

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/


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


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







4. Encrypt transmission of

cardholder data across open,

public networks

3. Protect stored cardholder

data


Secure Network and

Systems

Protect Cardholder

Data


program


control measures


test networks


security policy

Encrypted, truncated data reduced risk to data

Secure communications prevent data leakage


6. Develop and maintain

secure systems and

applications

5. Protect all systems against

malware and regularly update

antivirus software or programs









public networks

3. Protect stored

cardholder data


Secure Network and

Systems

Protect Cardholder

Data

Maintain a Vulnerability Management

Program


control measures


test networks


security policy

Active Anti-virus prevent bypassing

of security controls

Secure systems secure handling of

confidential 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

Protect cardholder

data


program

9. Restrict physical access to

cardholder data

Implement Strong Access

Control Measures


test networks


security policy

Authenticated users ensure

accountability

Proper access control prevent information

misuse and exposure

Secure facilities prevent data theft



cardholder data by


8. Identify and


system components


Protect cardholder

data


program


cardholder data


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


security policy

Track system events prompt discovery of

anomalies and policy violations

Identify and fix vulnerabilities prevent weakness

exploitation



cardholder data by


8. Identify and


system components


Protect cardholder

data


program


cardholder data


Control Measures





and cardholder data


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


6. Develop and maintain

secure systems and

applications

5. Protect all systems against

malware and regularly update

antivirus software or programs









public networks

3. Protect stored

cardholder data


cardholder data by


8. Identify and


system components


Secure Network and

Systems

Protect Cardholder

Data

Maintain a Vulnerability Management

Program


cardholder data


Control Measures





and cardholder data


Test Networks

12. Maintain a policy

that addresses

information security

for all personnel

Maintain an Information

Security Policy


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)


• Action Plan • Evidence for Implementation

Small Changes

(ex. Crypto Architecture)


• 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

[email protected]

Christos Stavropoulos

[email protected]

mailto:[email protected]

mailto:[email protected]

Pci standards, from participation to implementation and review

Technology

Transcript of Pci standards, from participation to implementation and review