Unrealistic Security Expectations - part 2
Unrealistic expectations are not only related to technology. In fact, I believe it’s more common to see that in security policies and standards. Based on the unrealistic expectation that anything written in a policy will be blindly followed, we end up writing prescriptive documents describing everything an organization must do for security. Done! By putting words on paper, we solved our security problems!
The problem begins with the extremely unrealistic assumption that someone reads the security policy! Sometimes I try to understand how someone can possibly believe that a hundred-page security policy will be read; most of the times reading the policies is not only unnecessary for people to do their jobs, it’s also something that will prevent them from working! It’s plain economics, there’s almost no incentive for them to read those documents. An assumption like that is pretty unrealistic, eh? So why do we keep being surprised when people don’t comply with the policy?
Anyway, there are processes we can use to force people to comply with policies and standards. But no process or mandate will help if we keep writing policies that are impossible to comply with. Ok, that sounds obvious, right? Well, it should, but there are lots of security policies out there just like that.
Even if it’s possible to comply, there’s another thing that will make a policy fail: Exemptions. In every organization with a security policy there’s a process to get exemptions. That’s ok, until you realize so many exemptions are being granted that the policy is simply wishful thinking. You shouldn’t expect a policy to act as a control if it’s not being followed. Yet many professionals do that. The basic “enforcement rule” applies here; if you can’t enforce a policy, or if it’s easier to get an exemption them to comply, it doesn’t meet its purpose.
Discussions about policies and standards effectiveness usually flow to whether the bar is being set too high or too low. That’s not always the case. Sometimes the issue is related to how prescriptive the policy is. Prescriptive policies can only be applied where the current conditions are aligned to the original expectations of whoever wrote the policy. Do you remember the older version of the antivirus requirement in PCI DSS? The requirement had originally been written with Windows environments in mind. It was funny to see mainframe shops puzzled about how to comply with that requirement. Less prescriptive policies have far less expectations about the environment where they will be applied, reducing the need for exemptions.
However, it’s not as easy as just writing non-prescriptive policies and standards. Write them too open and won’t be sure if they will be interpreted in the way they should be. Policies with generic requirements are often based on an unrealistic expectation how they will be interpreted. Balance is the key here.
In the end, policies and standards are just that: guidelines and rules. They might not be followed. Have you ever thought how your security will perform if people choose not to comply with your policies? Do it. You should build your defenses based on reality, not on unrealistic expectations.