Once More on Insta-Fail Security Policies – Rant Alert!

Monday, June 15, 2015

Anton Chuvakin

Ebb72d4bfba370aecb29bc7519c9dac2

For a while, I was under impression that my deep disdain for “insta-FAIL security policies” (i.e. those written without any chance of ever being complied with, even during the policy-writing process) knows no equal. I was pleasantly surprised to learn that my former teammate, Ben Tomhave, apparently hates them even more [I wonder why? :–)]

As Ben so eloquently puts it in his insightful post called “The Policy Trap” (required reading for any budding security policy writer!): ‘One of the most amusing notions is that of the aspirational security policy. “If we write this policy at this level, then everyone will come into line. We just need the strength of a policy to force people into a new way of behavior.”’

The result of such 'aspirations'? What is more evil than Saddam Hussein, more stupid than a brainless monkey and more corrupt than a typical Russian bureaucrat? An insta-fail security policy!

Here are some sadly not-uncommon examples:

  • “We patch all vulnerabilities within 30 days of release” – No, you DO NOT! Not for RDBMS, not for ERP, not for some of your own applications. FAIL!
  • “We monitor all access to sensitive data.” – No, you don’t – you probably don’t even know what some of your sensitive data is and where it is located. FAIL!
  • “We review all the logs” – No, you don’t. You don’t even know where some of the logs are and how to get to them. FAIL!
  • “We maintain PCI DSS compliance at all times” – No, you very likely don’t. In fact, you probably cannot even check whether you do or you don’t. FAIL!

To make it even clearer, here are Anton’s top 6 reasons to avoid insta-fail security policies:

  1. Such policies teach people that breaking rules is acceptable, desired [to get anything done] and even rule-makers do it
  2. They also teach the users and IT managers that security policies, in general, should not be complied with – including the parts that are realistic.
  3. This situation simplifies proving that you were (well, still are) negligent in case of a breach (after all, you were not even following your own rules, much less the industry standards) <- a big deal!
  4. Also, such policies increase the chance of not getting any cyber insurance payouts (as was reported privately to me several times)
  5. They destroy your risk management and, specifically, prioritization activities (after all, if some policy gaps are designed to last forever, why both closing them and prioritizing the efforts?)
  6. They create a corrupt and skewed view of your security posture, defraud senior management (that naively assumes that you are or soon will be compliant) and may enrage IT auditors…

There you have it — go look at your security policies and BRUTALLY weed-out the “instal-fail” kind… Also, go read “Five Golden Rules for Creating Effective Security Policy” and “How to Craft and Plan Your Security Policy” (and even “Planning Information Security and Risk Management Policy” from 2012) [Gartner access required]

P.S. I was told that a robust exception process may sometimes justify creating such a fanciful security policy – while this may work, judging the value of such an approach is left as an exercise to the reader …

This was cross-posted from the Gartner blog.

6689
Budgets Enterprise Security Policy Security Awareness Security Training
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.