Last updated at Wed, 30 Aug 2017 00:11:47 GMT

I'm here again with a song in mind: Why should I care?

You have probably noticed that PCI DSS Version 3 is available! It is applicable on a voluntary basis until Jan 2015, when it becomes mandatory. But, should you care? Should you prepare yourselves? Well, it depends.

In this newsletter, I'm sharing with you the result of my analysis of the new version of the PCI Bible. You will learn what has changed and what the impact is for companies already in compliance with PCI DSS version 2 (V2). 

  • Low: Nothing or no much to do (for companies already in compliance with V2).
  • Medium: Implementation could require some effort for the development of additional documentation, for implementation of new processes, or for the execution of new activities.
  • High: Don't wait, as implementation will require a lot of efforts and budget allocation.

You may also be interested in this associated webcast about what's new in PCI DSS 3.0 that I produced.

Scope

Merchant websites that redirect the customer to payment providers are now explicitly in scope of PCI DSS as of version 3. (Impact: High for this category of merchants, Low for others.)

Alignment with testing procedures in PCI DSS Version 2 (Impact: Low)

Some testing procedures in V2 go further than the associated requirements. PCI DSS Version 3 corrects this by making sure that each testing procedure is associated to a requirement. Companies already in compliance with V2 should no be impacted by these new requirements, namely:

2.2.3 Implement additional security features for unsecured services and protocoles

3.5.2 Protection of secret and private keys

4.1 Safeguard sensitive data during transmission

6.5 Train developers

10.6.3 Handling of exceptions and anomalies found during review

11.1 Process for wireless detection

11.1.2 Incident response plan for WAP detection

11.2.1 Qualified people

11.2.2 Rescans as needed

11.2.3 Qualified people

11.3.3 Correct and retest (pen test)

Transfer of Policies and Operational Procedures into Sections (Impact: Low)

The requirement V2 12.2 "Develop daily operational security procedures that are consistent with requirements in this specification" is now incorporated at the level of each specific section of PCI DSS V3. Companies already in compliance with V2 12.2 should not be impacted.  Associated new requirements: 1.5, 3.7, 4.3, 5.4, 7.3, 8.8, 9.10, 10.8, 11.6.

Notes transformed into requirements (Impact: Medium)

Some requirements in V2 incorporate guidance notes that have been transformed into specific requirements in V3. As these guidances become requirements, there is potentially a medium impact for companies already in compliance. Associated new requirements:

2.2.3 - Implement additional security features for unsecured services and protocoles

3.5.2 - Protection of secret and private keys

Flexibility (Impact: Low to Medium)

V3 adds some flexibility in the choice of the solution by adapting the requirements.

1.3.4 Prevent Internal IP into the DMZ -> Implement anti-spoofing measures (Low)

10.6.1 Components for which logs must be reviewed daily (Low)

10.6.2 Review periodically other logs based on risk management strategy (Medium)

11.5 “file-integrity monitoring” -> by  “change-detection” to alert personnel to unauthorized modification of critical system files (Low)

Additional Documents and Processes Required (Impact: Low to High)

The following new requirements are associated with new documentation, new processes, or new activity:

1.1.3 Data Flow diagram (High)

2.4 Maintain an inventory of system components

5.1.2 Periodic evaluation of systems not commonly affected by malware (Medium)

6.5.10 Test for broken authentication and session management (Medium)

7.1.1 Define access needs for each role (High)

8.1 Define and implement policies and procedure for proper user identification management (Medium)

8.4 Additional list of guidance and instruction to be communicated (Low)

8.5.1 Service providers must use unique authentication credential when connecting remotely to their customer premises (Medium-High)

8.6 Protect other authentication mechanisms (than passwords) appropriately (Low)

11.1.1Inventory of WAP (Medium)

11.3 Implement a methodology for penetration testing (High)

11.4 Validate any segmentation and scope-reduction controls (High)

11.5.1 Incident response process for change-detection alert (Medium)

12.9 Acknowledgement of responsibility for Service providers (Medium)

Other Clarifications (Impact: Low to Medium)

Additional clarifications brought by PCI DSS Version 3:

1.1.2 Diagram showing all connections TO CDE -> All connections BETWEEN the CED and other networks (Medium)

1.4 Personal Firewall configuration (Low)

6.3.2 Code review (Low)

New Requirements for Card-Present Merchants

These new requirements are related to the protection of payment devices:

9.9  Physically protect payment devices (Medium)

9.9.1 Inventory of payment devices (Medium)

9.9.2 Inspect device for tampering or substitution (Medium)

9.9.3 Provide inspection device training (Medium)

Detailed Analysis Per Requirement

Build and Maintain Secure Networks and Systems

V3 #TopicDecriptionImpact1.1.2All connections TO CDE -> BETWEEN the CED and other networks

V2  1.1.2 requires a current network diagram showing all connections to cardholder data

V3 clarifies all connection between the cardholder data environment and other networks must be showed. So not just the interface with the open public network but also with the internal surrounding ones.

Low1.3.4Prevent Internal IP into the DMZ -> Implement anti-spoofing measures

V2 1.3.4 requires preventing internal addresses to pass from the Internet into the DMZ.

V3 provides us with some flexibility by requiring Implementation of anti-spoofing measures to detect and block forged source IP addresses from entering the network.

V2 requirement is used as an example of possible measure.

Low1.4Personal Firewall configuration

V2 1.4 requires personal firewall to be installed on laptop and mobile.

V3 clarifies that:

•Specific configuration settings must be defined for personal firewall software.

•Personal firewall software must be actively running.

Personal firewall software may not alterable by the users.

Low1.1.3Data Flow diagram

V3 is requiring a diagram showing all cardholder data flows across systems and networks.

One can suspect that complying with this requirement will require quite some efforts to gather the information.

High1.5Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

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

V3 #TopicDecriptionImpact2.2.3Implement additional security features for unsecured services and protocoles

V2 2.2.2 “Enable only necessary and secure service” has this as a note. There were however testing procedures associated to this note.

V3 makes it now a separate new requirement.

Low2.4

Inventory of system components

Maintain an inventory of system components that are in scope for PCI DSS.High2.5Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Protect Stored Cardholder Data

V3 #TopicDecriptionImpact3.5.2Protection of secret and private keys

V2 3.5 has this as a note as well as some testing procedures.

V3 makes it a separated new requirement and extends it by explicitly authorizing three storage forms.

Medium3.7Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Encrypt Transmission of Cardholder Data Across Open, Public Networks

V3 #TopicDecriptionImpact4.1Safeguard sensitive data during transmission

V2 4.1 has some specific testing procedures that are not part of the requirements.

V3 clarifies this by amending the requirement to include:

  • Usage of trusted keys and certificates
  • Usage of secure version or configuration of protocols
  • Usage of appropriate encryption strength.
Low4.3Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Protect All Systems Against Malware and Regularly Update Anti-Virus Software or Programs

V3 #TopicDecriptionImpact5.1.2Periodic evaluation of systems not commonly affected by malware

Systems not commonly targeted or affected by malware are not required to have anti-virus installed.

V3 explicitly authorizes this non applicability  BUT requires to have a documented process in place to be stay informed of the evolution of malware threats for these systems.

Low5.4Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Develop and Maintain Secure Systems and Applications

V3 #TopicDecriptionImpact6.3.2Code review

V3 amends this requirement by clarifying that the code review must include:

  • Reviewed by individuals other than the originating code author
  • Knowledgeable about code-review techniques and secure coding practices.
  • Developed according to secure coding guidelines
  • Appropriate corrections implemented prior to release.
  • Results are reviewed and approved

Low

6.5Train developersTraining of developers is a testing procedure in V2. Now it's a specific requirement in V3Low6.5.10Test for broken authentication and session managementV3 adds in the list of common vulnerabilities to test: Broken authentication and session management (Best practice till June 2015)Medium6.7Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Restrict Access to Cardholder Data by Business Need-to-Know

V3 #TopicDecriptionImpact7.1.1Define access needs for each role

V3 adds this requirement for a definition of access needs for each role including:

  • System components and data resources that each role needs to access for their job function
  • Level of privilege required (for example, user, administrator, etc.) for accessing resources.
Medium7.3Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Note: V2 7.1.4 'Implementation of an automated access control system' has been removed from V3.

Identify and Authenticate Access to System Components (Formally: "Assign a unique ID...")


Note: The structure of this section has been completely modified.

V3 #TopicDecriptionImpact8.1Define and implement policies and procedure for proper user identification management

V3 starts this section by asking for policies and procedures not required in V2.

Low8.4Document and communicate authentication proceduresV3 adds a list of guidance and instruction that must at least be sharedLow8.5.1Unique authentication credential for service providersThis new requirement for service providers with remote access to customer premises asks to use unique credential for each customers.Low8.6Other authentication mechanismsV3 requires that where other authentication mechanisms than passwords are used, they must be uniquely assigned and appropriately protected.Low8.8Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Physical Security

V3 #TopicDecriptionImpact9.9Protect payment devices

Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

Medium9.9.1Maintain an up-to-date list of devicesMaintain an up-to-date list of devicesMedium9.9.2Devices inspectionPeriodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitutionMedium9.9.3TrainingProvide training for personnel to be aware of attempted tampering or replacement of devices.Medium9.10Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Monitor and Test Networks

V3 #TopicDecriptionImpact10.6.1Components to review daily

V2 asks for a review of logs for all system components on a daily basis.

V3 makes it lighter by specifying what logs must be reviewed at least on a daily basis

Low10.6.2Review periodically other logs based on risk management strategyAs a continuation of 10.6.1 V3 specific that periodicity of logs review of for all other system components must be based on the organization's policies and risk management strategy.Medium10.6.3Handling of exceptions and anomalies found during review.

V3 aligns with V2 testing procedures by explicitly asking for a documented and applied process to follow up exceptions and anomalies identified during the review process.

10.8Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Regularly Test Security Systems and Processes

V3 #TopicDecriptionImpact11.1Process for wireless detection

V2 11.1 does not ask for a wireless testing process but the associated testing procedures well.

V3 11.1 corrects this.

Low11.1.1Inventory of WAPV3 now asks for an inventory of authorized wireless access points including a documented business justification.Medium11.1.2Incident response plan for WAP detectionV3 aligns to the testing procedure in V2 by asking explicitly for incident response procedures in the event unauthorized wireless access points are detected.Low11.2Combination of scan reports

V3 adds a note clarifying that:

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

2) Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

Low11.2.1Qualified peopleV3 aligns this requirement to the existing testing procedure in V2 asking to verify the qualification of the scanning personnel.Low11.2.2Rescans as neededV3 aligns with V2 testing procedure by asking explicitly for “rescan”.Low11.2.3Qualified peopleV3 aligns this requirement to the existing testing procedure in V2 asking to verify the qualification of the scanning personnel.Low11.3Implement a methodology for penetration testingV3 requires to have a penetration testing methodology in place.Medium11.3.1External pen testV2 11.3 (external and internal pen test) has been split into two requirements.Low11.3.2Internal pen testV2 11.3 (external and internal pen test) has been split into two requirements.Low11.3.3Correct and retestV3 aligns with the V2 11.3.b testing procedure by asking than Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the correction.Low11.4Validate any segmentation and scope-reduction controlsV3 requires to include in the pen test the validation of any segmentation and other scope-reduction controlsHigh11.5Change-detectionV3 provides some flexibility by replacing the requirement for “file-integrity monitoring” by “change-detection” to alert personnel to unauthorized modification of critical system files.Low11.5.1Incident response processV3 asks for Implement a process to respond to any alerts generated by the change- detection solution.Medium11.6Policies and procedures

This is not a new requirement per se but rather a transfer of V2 12.2

« Develop daily operational security procedures that are consistent with requirements in this specification » at the level of each specific section of DSS.

Low

Maintain a Policy that Addresses Information Security for All Personnel

V3 #TopicDecriptionImpact12.9Acknowledge responsibility

V3 asks service providers to acknowledge in writing to customers that they are responsible for the security of cardholder data under their control.

This is a best practice until June 30, 2015.

Medium

Questions

What are your questions and concerns about these changes?

Did you read our previous newsletter? PCI 30 seconds newsletter #33 - Key take-away from the PCI Community meeting 2013

New version of the PCI Dashboard aligned with PCI DSS V3. Get it Now

    Didier Godart