Skip to main content

PCI DSS 3.0: What You Need to Know for November

October 18, 2013

Every three years the PCI Security Standards Council releases a new version of both PCI DSS and PA-DSS. As the November 2013 release of PCI 3.0 quickly approaches, there are a handful of things merchants and service providers alike should be aware of.

Whether you are embarking on re-certification or initial certification, each PCI revision comes with new requirements, clarifications, documentation changes and revamped testing procedures. Although there are no dramatic show-stoppers in 3.0, if you want to achieve and maintain compliance, attention to detail is needed nonetheless.

For the purpose of this blog, we’ll just look at the new PCI DSS requirements.

New PCI DSS Requirements


Know your scope

Essentially PCI is asking you to know, define and evaluate your scope through a process of documentation.

  • 1.1.3 - Provide a current diagram that shows all cardholder data flows across systems and networks.
  • 2.4 - Maintain an inventory of system components that are in scope for PCI DSS. Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each.


Solving the antivirus debate

There has been much discussion over antivirus running on Linux and whether it’s necessary, or just an unnecessary precaution. PCI is now adding a guideline that requires a company to have a process in place to further gauge the risk if no antivirus is in place.

  • 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 antivirus 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.

Note:  Antivirus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-malware protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-malware protection is not active.


Defining user role access

Further adding to the granularity of documentation for compliance, PCI would like to see access needs based on each role. This could provide valuable when understanding the details of a breach and who should have access to what. From a physical aspect, users must be able to be tracked by their access, with no shared or team keys/badges.

  • 7.1.1 - Define 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.
  • 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.
  • 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.


Putting action behind a process

Beyond just scanning for rogue wireless devices, PCI would now like an organization to provide an inventory of authorized devices. This will assist in quickly identifying a true rogue device. As for change detection, generating alerts is one thing. But if there is no actionable process on how to react, then the alert is pointless. Documentation around next steps is now needed.

  • 11.1.1 - Need to maintain an inventory of authorized wireless devices including justification.
  • 11.5.1 - Implement a process to respond to any alerts generated by the change-detection solution.


Accountability further defined

PCI has always been big on documentation. These new requirements have been put into place to clearly define roles and responsibilities not only for in-house personnel, but also for service providers.

  • 12.4.1 - 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.          
  • 12.8.5 - Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.


In addition to the new requirements, here are some notable clarifications to existing requirements:

  • 1.3.7 - Cardholder data is explicitly not allowed to be stored anywhere with direct access to the Internet or untrusted networks
  • 3.2 - Sensitive authentication data (SAD) is to be rendered unrecoverable once a transaction is completed.
  • 3.4.1 - When using whole disk encryption, the key management process must be separate and independent from the underlying OS, i.e., Windows BitLocker is not an acceptable whole disk encryption solution.
  • 4.1 - Defined “open, public networks” to include:
    • The Internet
    • Wireless technologies, including 802.11 and Bluetooth
    • Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)
    • General Packet Radio Service (GPRS)
    • Satellite communications
  • 6.5.x - Updated to reflect the changes in application software risks
  • 6.6 - “Web application firewall” terminology replaced with “automated technical solution”. As to not force an entity into buying a Web Application Firewall solely for compliance, this change in verbiage will now allow this.
  • 9.2 - Visitor ID badges are not the only option.
  • 10.2.6 - Now includes logging of pausing and/or stopping audit logging.  Since logs are extremely important in putting together a timeline of a breach, any stoppage or pausing can be critical to those details.
  • 10.6 - Changes of note include:
    • Intent of log reviews is to identify anomalies or suspicious activity.
    • Provides guidance about scope of daily log reviews.
  • 11.2 - Changes of note include:
    • Explicitly allows multiple scanning reports to be combined to meet the quarterly requirement.
    • Rescanning must be performed until all “high” vulnerabilities are resolved.
  • 11.5 - Now allows for any mechanism to be used that can detect critical file changes. Similar to the change in 6.6 for web application firewalls, file integrity monitoring is no longer specifically called out, meaning other options will be considered passing.
  • 12.3.4 - No longer requires that mobile devices be labeled.


Best Practice Requirements

Beyond new requirements and clarifications, PCI has thrown in a new batch of six “best practice” requirements that must be in place by June 30, 2015. But for the time being, they are simply best practice recommendations. These can be more difficult to quickly put into place; therefore, the ground work to get in compliance with them should be reviewed now.

  • 6.5.6 - Insecure handling of PAN and SAD in memory. Since many breaches involve memory scrapping malware, this best practice guidance should be looked at sooner than later for most entities.
  • 6.5.11 - New requirement for coding practices to protect against broken authentication and session management
  • 8.5.1 - Service providers with access to customer environments must use a unique authentication credential (such as a password/phrase) for each customer environment.
  • 9.9 - Protect point-of-sale (POS) devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
  • 11.3 - For any company that currently has its penetration testing performed by an internal resource, this will impact them the most. A very detailed methodology will have to be observed by the QSA to confirm not only that the resource is qualified, but that the penetration test is fully comprehensive as well.
    • 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, and…
      • Specifies retention of penetration testing results and remediation activities results.
  • 12.9 - Liability is always a concern, and PCI is trying to further the due diligence from each side by formally implementing contract language for Service Providers around maintaining PCI compliance.
    • Additional requirement for service providers: Service providers acknowledge in writing to customers that they 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.

All entities have until December 31, 2014 to align with PCI 3.0, but as we have all experienced in the past, PCI compliance is no easy task. The sooner these new, clarifying and best practice requirements are addressed, the better. Good luck!

Related Blogs

March 08, 2018

Part 2: Frameworks in Context: The Business-Aligned Information Security Program and Control Frameworks

In part 1 of this series, we provided insights responding to the frequent question regarding control frameworks and their place in the security strate...

See Details

March 07, 2018

PCI Compliance Every Day – Requirement 4

In this latest post of my Payment Card Industry Data Security Standard (PCI DSS) compliance blog series, we will explore Requirement 4 of the standard...

See Details

May 30, 2012

2012 Hospitality Industry Security Trends

ue to tightening requirements from the PCI Security Standards Council, FishNet Security has seen a significant increase in the number of Hospitality c...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Privacy Policy

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.


Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.