When I got this Gartner blog, I made a promise to myself to avoid rants, as a matter of personal policy. I’ve done my share of rants on my previous blog (examples), and while they are fun to write sometimes, they don’t help people do stuff better or faster. They also make me part of the dreaded echo-chamber of the security community, densely populated with plenty of rant-spewing characters. Sure, I’ve broken this promise a few times, deceptively masquerading the rants using the tag philosophy.
This is one more rant! Sorry, but I just have to do it- otherwise I will “asplode.”
So, security and compliance is again the topic. Sure, plenty of people have stated that “security is not equal to compliance” with various meanings loaded into the line. Plenty of presentations (example) and conference panels have touched on the subject of the interrelationship of security and compliance. Why another post – and a rant at that?
In the past, I’ve tried to promote a healthy relationship between security and compliance, such as:
- Compliance (such as PCI DSS) is a healthy motivator for improving security, sledgehammer as it may be.
- Compliance can also be used as a budget driver to buy security tools (with an obvious assumption that they would be actually used for security)
- Compliance defines minimum-security; that proverbial low bar, a subset of what is needed based on the organizational view of risk
- Compliance may also be seen as an example of documented and auditor-proof security (“secured and knows it”)
In essence, my interpretation of “security is not equal to compliance” is rather literal – they are not one and the same, but they certainly should be in a happy, mutually enriching relationship. After all, compliance opened plenty of purse strings to fund meaningful security improvements at many organizations, improvements that many of those organizations would not have accomplished.
Well, some recent experiences have led me to believe that quite a few organizations have built a deep chasm between security and compliance. Under these circumstances, their problem is not that “security is not compliance”, but that nothing they do for compliance helps security. So, while I was aware of some abuses (example), I was not aware of many environments where compliance is in complete and utter disconnection from security.
but guess what – there are environments where this thinking is exactly what happens. Similarly, a notable security vendor recently came up with a novel idea – that their security tool can actually be used by security professionals to help security by detecting compromised systems. Upon seeing this, I experienced a bit of a brain freeze: WTF? It is a security tool – it has been used successfully by security professionals to detect incidents way before compliance became fashionable (which is roughly, 2004-2006). Why is this thinking novel? Buying and using a security tool for security – how new is that, really?
However, upon pondering this for some time, I realized that they are right: many environments buy security tools for compliance and then not use them at all [not even for compliance], or only use them to the extent needed to satisfy the most creatively minimalistic interpretation of a particular mandate or regulation.
People, has compliance burned your brains?!!! We are NOT doing it to impress an auditor; we are doing it to stop an attacker!
Posts that may be considered rants by some:
- On NTP Reflection DDoS: 1990s Strike Back?
- Security Chasm Illustrated
- Too Late to Fight “Cyber”
- On Buying Boxes and Not Using Them