Payment Card Industry Data Security Standard

(PCI DSS)

A Navigation and Explanation of Changes from

v2.0 to v3.0

November 11 – 14th 2013

Agenda

• THE PCI STANDARDS CYCLE

• DEFINING THE TYPES OF CHANGES

• EVOLVING REQUIREMENTS

• ADDITIONAL GUIDANCE

• CLARIFICATIONS

• SUMMARY AND HIGHLIGHTS

• QUESTIONS

The PCI Standards Cycle

PCI 2.0 valid

until Dec 31

2014

Note: some 3.0 requirements are not

mandatory until July 2015

Defining the Types of Changes

• Evolving Requirements (Changes)

• Material changes to ensure standards are up to date with emerging

technologies, such as new controls or changes to the implementation of

existing controls.

• Additional Guidance

• Explanation, definition and/or instruction to increase understanding or provide

further information or guidance where controls have remained the same, but

have traditionally been difficult to interpret.

• Clarifications

• Clarifies the intent of the requirement. Ensures that concise wording in the

standard portrays the desired intent of the requirements.

Requirement ‘Zero’ Changes

PCI DSS commences BEFORE Requirement 1. In both PCI DSS 2.0 and 3.0 there are a number of pre-requisites to compliance. These are instructions for both the entity being assessed and the QSA and can be referred to collectively as Requirement ‘0’. These are:

• PCI DSS Applicability Information

• Clarified that SAD must not be stored after authorization, regardless of PAN.

• Direct Post / Redirections still in scope, new SAQ proposed.

• Relationship between PCI and PA DSS

• Scope of PCI DSS Requirements

• PCI DSS Business-as-Usual Processes

• Sampling Instructions (for assessors)

• Instructions for Report on Compliance (for assessors)

• Detailed Security Assessment Procedures

• Requirements now include guidance and intent, and no more QSA-only instructions such as ‘In Place’ column.

Evolving Requirements (Changes)

• Requirement 1

• 1.1.2 & 1.1.3 (1.1.2)

• Requirement 2

• 2.4

• Requirement 5

• 5.1.2 (New)

• 5.3 (New)

• Requirement 6

• 6.5.10* (New)

• Requirement 11

• 11.1.x

• 11.3* (New)

• 11.3.4 (New)

• 11.5.1 (New)

• Requirement 12

• 12.2 (12.1.2)

• 12.8.5 (New)

• 12.9* (New)

• Requirement 8

• 8.2.3 (8.5.10 & 8.5.11)

• 8.5.1* (New)

• 8.6 (New)

• Requirement 9

• 9.3 (New)

• 9.9.x* (New)

• Requirement 10

• 10.2.5

• 10.2.6

Grey text denotes PCI v2.0 requirement numbers

“*” requirements are not mandatory until July 2015

22 Evolving Requirements

Additional Guidance

• Requirement 11

• 11.2

Multiple scan reports can be combined for the quarterly scan process to show

that all systems were scanned and all applicable vulnerabilities have been

addressed. Additional documentation may be required to verify non-

remediated vulnerabilities are in the process of being addressed.

Clarifications

• Requirement 1

• 6 changes

• Requirement 2

• 4 changes

• Requirement 3

• 8 changes

• Requirement 4

• 1 change

• Requirement 9

• 4 changes

• Requirement 10

• 3 changes

• Requirement 11

• 7 changes

• Requirement 12

• 8 changes

• Requirement 5

• 2 changes

• Requirement 6

• 9 changes

• Requirement 7

• 5 changes

• Requirement 8

• 7 changes

64 Clarifications

Evolving Requirements

Requirements 1 & 2

Requirement 1: Build and Maintain a Secure Network

1.1.2

Current diagram that identifies all networks, network devices, and system components, with all

connections between the CDE and other networks, including any wireless networks.

1.1.3

Current diagram that shows all cardholder data flows across systems and networks.

Requirement 2: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

2.4

Maintain an inventory of system components that are in scope for PCI DSS.

Requirements 5

Requirement 5: Maintain a Vulnerability Management Program

5.1.2

For systems considered to be not commonly affected by malicious software, perform periodic

evaluations to identify and evaluate evolving malware threats in order to confirm whether such

systems continue to not require anti-virus software.

5.3

Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users,

unless specifically authorized by management on a case-by-case basis for a limited time period.

Requirement 6

Requirement 6: Develop and Maintain Secure Systems and Applications

Prevent common coding vulnerabilities in software-development processes as follows:

6.5.10 (effective July 2015)

Broken Authentication and Session Management

6.5.6 (removed from draft standard)

Insecure handling of PAN and SAD in memory

Note that this is still required by the Standard! (Req 6.5.c)

Requirement 8

Requirement 8: Identify and Authenticate Access to System Components

8.2.3

Passwords/phrases must meet the following:

• Require a minimum length of at least seven characters.

• Contain both numeric and alphabetic characters.

Alternatively, the passwords/phrases must have complexity and strength at least equivalent to

the parameters specified above.

(To be measured either as ‘entropy’ or resistance to attack.)

Requirement 8 (cont’d)

8.5.1 (effective July 2015)

Service providers with access to customer environments must use a unique authentication credential

(such as a password/phrase) for each customer environment.

8.6

Use of authentication mechanisms such as physical security tokens, smart cards, and certificates

must be assigned to an individual account as follows:

• Authentication mechanisms must be assigned to an individual account and not shared among

multiple accounts.

• Physical and/or logical controls must be in place to ensure only the intended account can use that

mechanism to gain access.

Requirement 9

Requirement 9: Restrict Physical Access to Cardholder Data

9.3

Control physical access for onsite personnel to the sensitive areas as follows:

• Access must be authorized and based on individual job function.

• Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

9.9

Protect point-of-sale (POS) devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

Note: This includes card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.

Requirement 9 (cont’d)

Both requirements effective from July 2015

9.9.1

Maintain an up-to-date list of point-of-sale (POS) devices. The list should include the following:

• Make, model of device.

• Location of device (for example, the address of the site or facility where the device is located.)

• Device serial number or other method of unique identification.

9.9.2

Periodically inspect POS device surfaces to detect tampering (for example, addition of card skimmers

to devices), or substitution (for example, by checking the serial number or other device characteristics

to verify it has not been swapped with a fraudulent device.)

Requirement 10

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Implement automated audit trails for all system components to reconstruct the following events:

10.2.5

Use of and changes to identification and authentication mechanisms — including, but not limited to,

creation of new accounts and elevation of privileges — and all changes, additions, or deletions to

accounts with root or administrative privileges.

10.2.6

Initialization, stopping, or pausing of the audit logs.

Requirement 11

Requirement 11: Regularly Test Security Systems and Processes

11.1.1

Maintain an inventory of authorized wireless access points including a documented business justification.

11.1.2

Implement incident response procedures in the event unauthorized wireless access points are detected.

11.3 – continued on next slide.

11.5.1

Implement a process to respond to any alerts generated by the change detection solution.

Requirement 11.3

11.3 (effective July 2015)

Develop and implement a methodology for penetration testing that:

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115).

• Includes coverage for the entire CDE perimeter and critical systems.

• Includes testing from both inside the network, and from outside of the network attempting to get in.

• Includes testing to validate any segmentation and scope-reduction controls.

• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5.

• Defines network-layer penetration tests to include components that support network functions as well as operating systems.

• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months.

• Specifies retention of penetration testing results and remediation activities results.

11.3.4

If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.

Requirement 12

Requirement 12: Maintain a Policy that Addresses Information Security for all Personnel

12.2

Implement a risk-assessment process that is performed at least annually and upon significant

changes to the environment (for example, acquisition, merger, relocation, etc.)

12.4.1 (removed from draft standard)

Information security responsibilities must be assigned such that separation of duties for security

functions is maintained. For example, persons tasked with monitoring or auditing a security control

should not also be responsible for administering that control.

This is now a recommendation in the Business As Usual guidance, but not a requirement.

12.8 & 12.9 – continued on next slide.

Requirements 12.8 & 12.9

12.8.2 (merchants) & 12.9 (service providers)

Applicable from July 2015 for service providers only

Maintain a written agreement that includes an acknowledgement that the service providers will

maintain all applicable PCI DSS requirements to the extent the service provider handles, has access

to, or otherwise stores, processes, or transmits the customer’s cardholder data or sensitive

authentication data, or manages the customer's cardholder data environment on behalf of a customer.

Additional requirement for service providers: Service providers acknowledge in writing to customers

that they will maintain all applicable PCI DSS requirements […]

12.8.5

Maintain information about which PCI DSS requirements are managed by each service provider, and

which are managed by the entity.

Summary

• 13 – 19 months until mandatory compliance with v3.0 applies.

• New requirements are a reflection of real-world feedback from merchants, service providers, card brands and QSAs, and are designed to defend against actual threats to cardholder data.

• New business-as-usual requirements include:

• regular evaluation of malware and vulnerable systems,

• responding to any failures of security controls, and continuously improving,

• inventories of CDE, wireless Aps and POS devices.

• Software development to include a greater focus on CHD in memory – not a new concept!

• More physical security – monitoring and review – of card terminals in retail environments.

• Penetration testing to become a more formal and structured process, both for the entity being assessed, and the penetration testing provider.

More Information

Our Website www.nccgroup.com

Our Blog www.nccgroup.com/en/blog

Our Research www.nccgroup.com/research

Follow us on Twitter :

@NCCGroupplc

@NCCGroupInfosec

@iSECPartners

Rob Chahin, QSA

Managing Consultant

NCC Group

e: rob.chahin@nccgroup.com

UK Offices

Manchester - Head Office

Cheltenham

Edinburgh

Leatherhead

London

Thame

North American Offices

San Francisco

Atlanta

New York

Seattle

Australian Offices

Sydney

European Offices

Amsterdam - Netherlands

Munich – Germany

Zurich - Switzerland