The security vs. compliance debate continues, though I’ve lost track of who is actually still arguing that compliance is security. Maybe it’s auditors? Or managers? This topic comes up a lot for me, both at work and from listeners of my security podcast.
The “compliance” mindset often leads to a belief that if some particular scenario is not prohibited by policy, it must be safe. After all, if it weren’t safe, it would be explicitly addressed in policy.
I can look around and see compliance thinking behind many breaches.: “If it isn’t safe for card readers to pass unencrypted credit card information to a POS terminal, surely PCI DSS would not permit it!”
For many in the information security field, this is a quaint discussion. In my advanced age, I’m becoming more convinced that “compliance” is not just a fun philosophical debate, with auditors, but rather an active contributor to the myriad security issues we wrestle with.
Clearly, the better path to take is one of assessing risks in IT systems and addressing those risks. However, we must keep in mind that we are often asking for that assessment to be performed by the same people who are apt to accept policy as the paragon of protection.
As we debate the perils of focusing too much on offensive security and not enough on defense, it’s important to point out that, without understanding offensive techniques, our imaginations are hobbled as we evaluate risks to IT systems.
For example it probably seems reasonable to the average IT person to connect an Internet-facing Windows web server to her organization’s Active Directory domain. There is no policy or regulations that prohibit such a thing. In fact, AD provides many great security capabilities, like the ability to centrally provision and remove user IDs. Without the context of how this situation can, and indeed often is, leveraged by attackers in significant breaches, the perceived benefits outweigh the risks.
I see value in exposing general IT workers, not just information security personnel, to offensive techniques. I am not advocating that we teach a Windows administrator how to perform code injection into running processes, but rather that code CAN be injected into running processes. And so on.
To me. this is lack of understanding is a major contributor to the issues underlying the “security vs. compliance” discussion. Organizations spend a quite a lot of effort on security awareness programs for employees, but I see almost no focus on educating IT staff on higher order security threats. I don’t expect much to change until we change this state of affairs.