On Nebulous Security Policies

We interrupt our regular programming (on SIEM this quarter) in order to briefly talk about security policy. In particular, about unrealistic, crazy, unimplementable policies that nobody even intends to comply with. The ones even security people themselves violate every day. The ones that  users make fun of while violating them.

Here are some notable examples:

• No large organization on this planet (and probably on other planets within a few light years distance) can “patch EVERY vulnerability found on ALL systems within 30 days.” (try patching a router or an RDBMS on that schedule and your network ops people or DBA will eat you alive)
• Along the same vein, no large company can “monitor all access to sensitive data.” (try monitoring access to those Excel spreadsheets full of regulated data)
• Similarly, nobody can check whether “proper information confidentiality controls” are in place. “Propriety” has little to do with what we are doing here in infosec, hasn’t it?

There many reasons for creating such “self-defeating policies” – and none of them good. In fact, if you are writing just such a policy, be aware that you are likely increasing the risk for your organization, not decreasing it. If you are sued after a breach, such a policy provides a nice clean proof of your organizations negligence. Furthermore, good auditors love poking holes in  policies that don’t match the operational reality. In an adjacent field, companies had to settle with FTC (and spent millions) when they were found to be non-compliant with their own published privacy policies. Finally, if violating one policy is seen as OK by both end users and IT, then the culture of “violating ANY policy is OK” spreads like wildfire.

Thus, an unrealistic policy is a direct contributor to increased risk for the organization.  Security policy only reduces the risk of system compromise and data theft if it is implemented on production systems. Thus, Security MUST work with operations to build a policy that prescribes needed protection, BUT also consider operational realities. If 1 sysadmin manages 1000 systems with no automation, he would not patch them every month … saying it must happen won’t make it so.

We at Gartner have a lot of great policy guidance, such as this master document that links to many of our security policy documents, templates, toolkits, etc. My personal fave is of course “Top 10 Policy-Writing Mistakes” with gems of such mistakes as “applying wishful thinking”, “including unactionable items” and “biting off more than the organization can chew.” And, among all the tips, useful practices, guidance and recommendations, this one reigns supreme: “Do not write a policy that you are not prepared to follow!!!”

And now back to the comfort of large SIEM deployment architecture …