Yes, I know, I know: math fans will cringe at my post title :-)
In any case, this post was inspired by a weird conversation I had with a particular QSA, who shall remain nameless. Right in the middle of the discussion, he uttered the usual “compliance does not equal security.” I nodded and made some incomprehensible agreement sounds.
And then he tossed a bomb: “And, as you know, security does not equal compliance.”
I was like: “… ah … eh … mmmm … really?… mmmm … I guess so”
But seriously?
Blabbing “compliance does not equal security” is a secret rite of passage into the League of High Priests of the Arcane Art of Security today. Still, it is often quietly assumed that a well-managed, mature security program, backed up by astute technology purchases and their solid implementation will render compliance “easy” or at least “easier.” One of my colleagues also calls it “compliance as a byproduct.” So, I was shocked to find out that not everyone agrees…
Let’s explore what the deal is.
First, we all know that “focus on compliance, ignore security” is a recipe for EPIC FAIL, usually of both. This is what I called “compliance first” thinking and it is indeed scary. For those who like FUD, you end up BOTH “0wned” and fined + embarrassed in the media [if you are big], on top of it.
Second, let’s assume for simplicity that you completely ignore regulatory requirements (not sure why anybody would want to do that though …) and just focus on your best understanding on what you need to do for protecting data, infrastructure, “keeping the wheels on,“ etc. If you execute perfectly on that and then go read, say, PCI DSS, you will find out that you likely have a gap. How big of a gap? I don’t now, but it is likely that closing the gap will not make you less secure. For some regulations, you can also argue that your measures protect the data better than the prescribed ones (see Branden’s “The Art of Compensating Control” for more on that). So, in the worst case, you’d waste a bit of time/money … or so the thinking goes.
Are we missing something?
Yes, we are! The third, most interesting case is: you read the regulations, you consider what you need for protecting data and then implement what you think is an intelligent combination of both. Then the assessor (PCI DSS)/auditor(other) comes to validate your compliance. And he finds a particular control that you implemented to protect the data (e.g. an appliance has no administrative access from the local network; it is managed by the vendor only) and says that this control is not compliant (e.g. requirement 8.5.6 says that you can “Enable accounts used by vendors for remote maintenance only during the time period needed”). Now, an obvious first reaction is to dismiss such assessor as an idiot, who just doesn’t “get security.” However, the situation is real: security thinking (even if stale at times…) evolves faster than any regulations. But I’d really like to hear about cases where security-inspired compliance requirements forced somebody to reduce security that was the motivation for those very requirements? I bet these would be extremely rare – and if you subtract those that are explained by the assessor/auditor inexperience, the number would be very, very close to zero!
What I suggest is that the whole industry debate about “security vs compliance” should be switched from a mildly idiotic “equals” (well, they are called different names, maybe it means they are not really equal") to a saner “helps.”
- Does security helps with compliance? Yes, in most cases.
- Does compliance helps with security? Yes, in many cases.
- Are they the same? No.
Thoughts? Other examples where security didn’t lead to compliance?
UPDATE: a very interesting response here from CSOandy.
Possibly related posts:
