Last updated at Fri, 11 Aug 2017 20:26:48 GMT

I've never been a big fan of – or have believed in the value of – security policies. Sure, they're necessary for setting expectations and auditors want to see them. They can also serve as a sort of insurance policy to fall back on when an unexpected security “event” occurs. But, at the end of the day, security policies often contribute minimal value to the overall information security function. As I've seen time times before: many organizations have great paperwork but their security program stinks.

If you're reading this blog, you're no doubt somehow responsible for information security in your business. You may not be responsible for everything security-related but odds are good that the things you're doing, such as vulnerability scanning, penetration testing, and incident response, are an integral part of your overall security program. That's all good but there's an elephant in the room. It's your security policies. You know those documents that are scattered about making your information security program look better than it actually is.

Don't get me wrong. I'm not trying to be critical of or shun your efforts. I know what you're up against, but I also see what the research shows and what happens when people have a false sense of security. When it comes to policies, one of the best things you can do, starting today, is to stop relying on them to fix your security problems. And tell your peers and management to do the same thing. You can tell them I said so. I've heard it a thousand times: “We have a policy for that.” The assumption is since there's a policy, then all is well in IT. That's hardly the case.

Looking at areas across your information security program—from security assessments to patch management to mobile computing—you may have a policy mandating this or that. Even a policy as basic as acceptable computer usage that's known by everyone is likely in place. They're probably all very well-written and would satisfy the requirements of many a gullible auditor. But how is it working for you? Probably not as well as you had hoped—or as well as management believes it does.

The following scenarios describe very common misconceptions about enterprise security:

  • We have a password policy. Yet all passwords across all systems are nowhere near compliant. Executives are often exempt. Some passwords are unenforceable. Numerous risks are further facilitated because strong passwords are assumed to be in place, but they're really not.
  • We have an acceptable usage policy. But users don't know about it. There's no tracking or accountability for violations. There's little to no integration with user awareness and training initiatives. Why even state what the rules are when they're ignored?
  • We have a data backup policy. However, desktops, mobile devices, and even IoT and cloud data are being overlooked. Shadow IT-borne systems are completely out of the loop. The lack of backups of some of the most critical data is unknown until a ransomware infection hits.
  • We have a patch management policy. Still, patches are not being applied (especially third-party patches for Java and Adobe products) and malware and related exploits are still occurring.

You see where I'm going with this.

The interesting thing is that most of the IT and security pros I work with understand the reality of the policy vs. practice disconnect. It's often people outside of those circles who assume that all is well in security because, after all, it's documented. I'm convinced that if you're going to have a truly resilient security environment, you're going to have to move beyond the paperwork. See this disconnection for what it is. Bring it up in security discussions. Use it as leverage to get more support for your security initiatives. Ask for help. Whatever you do, don't assume that policies will keep your environment locked down. Assumptions about these types of security challenges make fools of us all.