The much anticipated PCI-DSS 3.0 is out, and the new Self Assessment Questionnaires (SAQ’s) have been released. We’ve had a lot of questions over the last month about what new changes actually mean to Merchants. One notable introduction is the SAQ-A EP for partially outsourced e-Commerce merchants (check out topic 6 below), but otherwise as you would expect the changes aren’t significant. With PCI-DSS 3.0 the PCI-SSC has made some rule clarifications and updated a few areas to touch on emerging threats in the Industry. Depending on how your environment is architected, it’s best to start assessing the impact of these changes now! In reading the new SAQ’s and Report on Compliance Assessment Procedures there were 6 changes that caught my attention and decided to enumerate them here:

Topic 1: The Inventory of System Components

The new requirement 2.4 specifies that merchants “maintain an inventory of system components that are in scope for PCI-DSS”. While seemingly an innocent requirement, the rabbit hole goes a little a deeper to and the testing procedure requires that the assessor “verify that a list of hardware and software components is maintained and includes a description of function/use for each”. Not only does this include systems in the Card Holder Data environment, but also includes requirement 11.1.1 “maintain an inventory of authorized wireless access points including a documented business justification.” In the case of 11.1.1, I do see the value in scanning for wireless access points but this is significant to me because I believe this is a sign of scope expansions to come.

Take-aways: similar to your firewall Access Control List and having appropriate business justification, this requirement now extends to in-scope hardware and applications.

Topic 2: Anti-Virus

Requirement 5.1.2 now requires that merchants “identify and evaluate evolving malware threats” for “systems considered to be not commonly affected by malicious software.” This means that you need to ratchet up your Vulnerability Management program–in theory it’s a simple idea but is a little more involved to evolving IT Security teams who also need to track vulnerabilities for systems that historically haven’t been targeted such as Unix or Mainframes.

Requirement 5.3 requires specific management approval to disable or change the operation of antivirus mechanisms and that if antivirus is disabled then disablement should be time-bound. This could have sweeping impacts in that it could require hardening of Group Policy so the anti-virus service can’t be disabled by the local user OR more significantly it might mean that applications that trip anti-virus policy because of configurations or not patched regularly will need to be remediated or compensating controls established.

Take-aways: First, (on requirement 5.1.2) be very clear on concise on what systems exist in your environment, and track vulnerabilities to those systems. If there is no anti-virus for your system you are trying to protect–then it’s important to put that malware signature into your next-generation IDS/IPS systems. Second, (on requirement 5.3) start hardening your anti-virus installation now so you have time to fix or establish compensating controls where needed.

Topic 3: Physical Access

Requirement 9.9 introduces the need to “protect devices that capture payment card data” “to detect tampering with or substitution”. This seems like common sense, but too often I see restaurants or coffee shops where the telecommunications hardware is in a common staff area or is a storage closet for supplies.

Take-aways: Take inventory of your Point of Sale devices associated hardware/software. Start planning now on how to secure data hardware in private (secured) closets (i.e. separate from common areas or storage closets). Also begin training local staff on how to check devices for tampering, how to handle vendors, and the rules of the road when it comes to protecting your technology.

Topic 4: Penetration Testing

Requirement 11.3 was updated to include the use of an “industry-accepted penetration testing methodology” such as as NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment). This will be challenging for smaller companies to comply with, most small companies don’t have the trained IT Security Staff with expertise in penetration testing and it can be costly to have an external firm perform penetration testing in your environment.

Take-aways: Start developing a strategy for this requirement, you have until June 2015 to comply. This requirement is referenced annually and after significant change to your environment. IT Security teams that start now with an Information Security staffing plan, and begin training their IT Security Staff will have plenty of time to develop this competency in house. One thing worth pointing out, Penetration Testing should be performed independent of the function that configured the system or a segregation of duties problem could exist (i.e. you don’t want the person who configured the systems to test their own work.)

Topic 5: Vendor Relationships

Requirement 12.8.5 and 12.9 now require that organizations be explicit, purposeful, and document what each vendor does for your organization and specifically what their responsibility is related your compliance with the PCI-DSS. The new requirement also requires that your vendor (or service provider) acknowledge in writing what they are responsible for.

Take-aways: Start working with your QSA to determine what level of documentation they deem to be sufficient. Also start documenting what controls your organization is responsible for and what controls your Vendor (or Service Provider) responsible for. This process can take a long especially if you find gaps on the initial assessment.

Topic 6: Changes in Scoping based on your Architecture

One of the most significant changes is the introduction of the SAQ-A EP. This is a new SAQ with the arrival of the 3.0 Data Security Standard. This requires that merchants who relied on tokenization or iFrames and currently complete an SAQ-A under the PCI-DSS 2.0 now have an additional 139 security requirements (or questions) to consider. The SAQ-A EP applies to “e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.” The SAQ continues to qualify the merchant by noting “your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor” or “your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions”.

So what does this mean? It means that companies that use tokenization and/or iFrames to reduce PCI-DSS scope need to take another look on how the technology works and work with your QSA to determine based on the new PCI-DSS 3.0 if your environment is still out-of-scope.

Take-aways: If you’re an e-Commerce only merchant and you are partially outsourced OR rely on third parties to reduce your scope, you should call your QSA and start determining what these changes mean to your environment.

The PCI-SSC documentation and summary of changes can be found here:

The NuHarbor Consulting Group is an Information Security and Risk advisory firm. We specialize in Information Security, Information Risk Management, IT Compliance, and Security Technology Integration Services. For help with PCI-DSS or any other Security or Compliance framework we can be reached at or 1-800-917-5719.

Pin It on Pinterest

Share This