PCI 30 seconds newsletter #29 - Do all PCI DSS requirements apply?

Blog Post created by dgodart on May 2, 2013


I recently assisted a medium size organization to align with PCI. The gap analysis and design phase raised a number of concerns from their side. All of the concerns started as something similar to: "Why do we need this? It induces more risks".


Implementing protection mechanisms without considering their added values and impact on the environment and the business does not make sense. Security is a risk mitigation and management discipline and all security responsible individuals know perfectly well that the right security balance for their environment is somewhere between the complete ignorance of a risk and its total protection.


Security could be considered as layers of clothes one could decide to slip on or not according to the environment and their sensitivity. Compliance however must be seen as THE uniform that MUST be slipped on independently of our environment and our own sensitivity.


Note: The PCI Council defined 5 types associated with the way organizations handle and process cardholder data (see PCI 30 seconds newsletter #5). If they are used to determine which sections of the PCI bible are applicable all rules within these sections are applicable whatever the entity environment, nature and size.


This fact is enforced by the Council in such terms:


"Decisions about applicability of PCI DSS requirements are not to be based on an entity's perception of the risk of not implementing the requirement. Organizations may not choose which PCI DSS requirements they want to implement, and risk assessments cannot be used as a means of avoiding or bypassing applicable PCI DSS requirements."


This makes us think as "Risk analysis" is one of the PCI-DSS requirement. Let me be clear, I am not saying that risk analysis is not important, it is definitely a key element of a security program. I'm just wondering the value of such a requirement if it could not be used to justify applicability of a requirement.  The only risk assessment that makes sense within the context of PCI compliance is the risk of non compliance. Can my organization afford to not comply?


Practically, it's never white or black. Organizations could discuss with their acquiring bank potential waivers or an implementation roadmap of several years. Services providers have not had this opportunity.


The Pen Test case


pentestjpg.jpgOne of the points argued by this organization was the need for an "internal pen test" required under PCI 11.3. This is an excellent case study for  "Why do we need this? It induces more risks". Here are highlights extracted from an opinion poll on this topic:


  • A pen test is a validation of the security controls in place, proof that the security design choices that were made are sound
  • A large number of companies were hacked out of business by relying entirely on the vulnerability scans to report the security of their external applications and infrastructure.
  • Although it's an expensive burden, it's absolutely necessary to have penetration tests done. At least an external one.
  • There should be very little risk introduced by pen test activity unless the penetration testing company is very sloppy or incompetent. Unfortunately in the context of PCI this is the case. There are far too many shoddy pen testers who have brought down entire networks and/or denied services to critical infrastructure due to their "pentesting/security knowledge". There is no list of certified pen test companies organizations could refer to. According to the Council any "qualified" individual could perform this job. However nothing is said on what "Qualified" means and how this qualification should be assessed. Furthermore QSA's have very little ability to judge or reject their work.


In the current context, (PCI rules), running a pen test just for the purpose of checking a box doesn't really bring any value. On the contrary it generates more risks than it helps to minimize; No guidance on the selection of a qualified testers and no clear guidance on the validation of their work. Pen tests are an expensive burden that organizations could attempt to minimize through the selection of cheap sloppy testers with the associated risks. Pen tests are however a serious and necessary activity for the validation of the security controls and design requiring a careful selection of professional testers. As a minimum: the  rules of engagement and experience of the individual testers must be scrutinized. Additionally whenever possible organizations should allocate an internal resource to oversee the pen test and request the pen test be stopped if something goes wrong.


There is no chance to pass PCI Compliance without running an external pen test. It's a MUST. However QSA's are more divided about the requirement for internal testing especially when the case is clearly justified and documented. Examples: No internal threats, high risk of business disruption, isolated segment, no Web application.


Alternatively you may want to test the idea suggested by the above picture: "Oh Yes Mr. QSA, I tested several pens this year and they are all working perfectly!"




What's your opinion on this topic?

Did you get/attribute PCI Compliance without implementing all requirements?

Would you vote for more flexibility in the implementation of the standard according to the real risks?


Did you read our previous newsletter: PCI 30 Seconds newsletter #28 - The PCI Library - What docs are required for compliance?


Thank You

Thanks for your contribution to the opinion poll: Bogdan Dragomir, Joseph Pierini,Ray Thorpe, Michael Hammer, Christian Molde and Russell Dench.