Your Security Policy Is So Lame

Published: 2015-08-02
Last Updated: 2015-08-02 00:20:56 UTC
by Russell Eubanks (Version: 1)
4 comment(s)

Every person should avoid lame security policies because of the lack of clarity they leave behind. Often times we find ourselves forced into creating security policies due to compliance requirements. Is there a way to lean into this requirement and get value beyond the checkbox? I certainly think so and would like to share some ideas on how you can do this as well.
I personally avoided being the “policy guy” until the patience of my management had finally expired. It was truly the job that none on the team wanted and it was my turn. My first step was pulling a security policy template book off the shelf. I remember that dust covered book very well. When working on the security policies, unexpectedly and out of no where it suddenly occurred to me - there is a great amount of influence when security policies are done properly. Sure, there are meetings with people who are not on your team, but working together is how anything meaningful gets done these days. I found that by working together with key business areas that security policies could be written so that more than just the auditor was interested in them.
The following are several tips and tricks you can use to make sure you move from "no good to great” security policies. 
  • Do not fail to add an expiration date to your security policies. Otherwise they get stinky, just like that jar of mayonnaise in your refrigerator. This will force you to both review and update them on a regular basis or risk being embarrassed because they are out of date.
  • Do not ask anyone to memorize your security policies. Why waste time memorizing a reference document? Spend your time doing something meaningful instead, such as reviewing ways to implement the 20 Security Controls in your company.
  • Do not use your security policy as an attempt to control small and often times personal issues. Instead, make sure your security policy addresses specific risk in your organization. Without a direct mapping to risk, it will be very easy to have too many security policies scattered all over the place.
  • Do not have too many security policies. I recommend you hold up both hands right now and wiggle your fingers as you consider how many security policies you might actually need. I’ll wait.
  • Will violation of your security policy eventually lead to the policy violator realizing their opportunity to violate security policy at a different company? It should - Otherwise your document is really a suggestion and not a policy.
  • Do have your security policy stored in one single and easy to find location? It would be a shame to spend all that time and no one ever read your security policies. Reminds me of that story about a tree that falls in the forest.
One of the very best security policy resources you will find is just a click away at the SANS Institute website. Specifically, the SANS Information Security Policy Templates. There you will readily find many examples that you can customize and make your own.
What are you doing to make sure your security policy is not lame? Use the comments section to share what has worked for you.
Russell Eubanks
Follow me on Twitter @RussellEubanks
Keywords: Policy
4 comment(s)


Two words: Be concise. The fastest way for a policy to end up in the proverbial back of the dusty shelf is for it to be full of redundant language and unnecessary legalese. Are you hung up on your user community surfing porn? Great: Mention it once, mention it clearly, and move on. If you want to remind people about it, save it for the awareness program - don't repeat it 17 times in your written security policy.

Another way to help is to separate the user-facing policies from the IT facing procedure or standards documents. The specialist in the marketing department doesn't need to read about how you perform monthly penetration tests or patch your servers.
@BeigeHat - You are right - Security Policies that are full of IT jargon and acronyms are a disservice to everyone. It is easy for us technologists to use hide behind own language. Fight that urge.

Real business value emerges when we are able to clearly communicate with those who are outside our teams. To me this is a great litmus test - can someone who does not work in technology understand the security policy both quickly and clearly.

Most security policies are so fluffy that you can't get any technician to read them, and comply to them. For the technical stuff to have any value, you must be clear to the letter. If you write that encryption must be used, then you need to say which encryption methods are allowed for say HTTPS. Otherwise XOR is the algorithm that is preferred, or 56-bit DES. And 123qweasd 1qaz2wsx are considered strong password unless people are told otherwise, since they are not dictionary words. You can't blame anybody for their interpretation of interpretable information.

Thing needs to end up in tech specs as they are called in IBM jargon. And clearly define what you mean by words like must, should etc. Only requirements, not recommendations are implemented by the operations people.

And for end-user facing policies, have HR write the text in a language they expect the average end-user to understand, and have HR distribute it.

A security policy is everything from a half page management approved principles down to a 1000+ pages tech specs collection.
Base your policies on a chosen and agreed upon standard framework (NIST CSF, COBIT etc.)so you can have consistency and a common nomenclature, don't make them up out of thin air. Once you've done that, select the technical controls and metrics that will be used to measure and enforce compliance with those policies.

I've seen too many people just make up policies and it tends to muck up the works with inconsistencies.

Diary Archives