Why PCI Is Not Security (Part 2).
'Letter' vs. 'Spirit' or 'Intent'.
With compliance-based frameworks like PCI, where very specific requirements are established, another issue is introduced. The PCI-DSS requirements can be looked at from one of two primary perspectives –
- the ‘letter’ of the requirement (doing exactly what the requirement says through a literal interpretation of the wording used, and doing the absolute minimum to satisfy that wording);
- or the ‘spirit’ of the requirement (looking at each requirement with an eye toward what the goal behind the requirement really is – not based on its wording, but on the protective value the requirement is intended to provide).
Let’s take firewalls for example – an easily understood security technology that is common in pretty much every organization these days. Firewalls get a lot of attention in requirement 1 of the PCI-DSS. There is one specific requirement that mandates ‘firewall rule reviews’ once every six months.
Now, if you look at the specific wording of the requirement, it basically says ‘review your firewalls rules once every six months, and document that you did it’. You can easily satisfy this particular requirement by quickly looking through your rules, seeing if there are any glaring issues that an assessor might pick up on, and fixing things so that they ‘look’ right to anyone who doesn’t understand the environment. In a lot of cases – this approach might just pass muster.
But does this actually do anything to protect the cardholder data that PCI is intended to address? The answer is ‘of course not’! The real intent behind doing a firewall rules review is to uncover misconfigurations, identify potential risks, remove conflicting or outdated rules, and ensure that every rule exists to support a specific, well documented business purpose. Most importantly, the goal is to ensure that each rule is necessary, appropriate, and as restrictive as it can be.
That’s an example of how the letter differs from the intent – and this is only one example of one sub-requirement. Now let’s take this example and blow it out across the entire PCI standard. Is the organization compliant? Sure, according to the exact wording of each and every requirement – and assuming the evidence is relatively believable, you’ll pass. Is the organization secure? Who knows?
I'm not even going to get into the mess that a PCI compliance focus can make of your security initiatives, funding, prioritization, etc. Let alone the anger among senior executives and business leaders that bubbles to the surface when you have to 'redo' PCI every year (just before the assessors comes in). "Why is this security thing so damn hard" becomes a mantra as the dollars and hours go racing down the drain.
Ohhh yea, and what about that 'false sense of security' that arises from "being compliant", or the challenge you run into after you 'pass', but you still want to spend money on an actual security solution at some point later on down the road - you're told "but we're compliant, so why would we need that". A literal definition of 'shooting yourself in the foot' comes to mind in these situations.
Been there, done that... and it's no fun. There is indeed a better way...
