Writing Security Policies and Procedures

Anyone who has ever written a set of policies and procedures knows how time consuming, headache ridden and tedious they are to create. For those of you who are in need of updating or creating new policies and procedures, this blog will be going over some things to keep in mind. We’ll also go over tips to making your writing easier for you and easier for your users to understand.

Whether you’re just starting to write brand new policies and procedures or you’re doing your yearly updates on existing ones, I think the thing that everyone needs to keep in mind is simplicity. So that means, for any lawyers that may be reading this, you guys aren’t allowed to write these. This also means that the techie-guys that don’t know how to speak to normal people, you aren’t allowed to write these either. There are some companies out there that have policies that have the procedures right in the same document, and this single document spans hundreds of pages. Who will honestly read and follow that?

Now I know there are a ton of policies and procedures that are needed for different aspects of business but we are only going to look at the one that most people see: the End User Security Policy. The ideas we cover for this policy can easily be applied to any other policy you’re putting together. This end user security policy is notoriously filled with jargon that lawyers and techies love to throw in there. People, you have to realize that your end users need to be able to read and understand this policy so that they can easily remember it and apply it when necessary. They shouldn’t be long, there’s no need for that. The policy should be short enough that people can read and interpret it within 10 mins. Any longer than that and your end users will read half of it, maybe skim the rest of it and throw it in a big pile of papers on their desk. That creates two problems: 1. they didn’t read the whole thing, and 2. they won’t sign off on it that they did read and understand it.

Many end user policies are not enforceable based solely on the language used in the policy, or the fact that the policy doesn’t set metrics on what will happen if you do break the policy. The policy has to be enforceable, and when you are writing the policy you have to think of what you would do, seriously, in the same situation. If you say, you have to set a strong password for your windows login, there’s no way around that in a domain, so you don’t have a choice, you have to follow that. But let’s say you specify to your end users that if they receive corporate mail to their phone they have to have it password protected. Are you going to do that on your phone? Do you have a way to enforce that? Are you planning on running an internal security assessment to test this? If you find a user not doing that, what is the penalty? Is the penalty the same for every user? (The answer to that question had better be YES! Otherwise you’re going to be talking to those pesky lawyers about discrimination!)

What would you do if a user brought their home laptop in and plugged it in to the corporate network? Or worse, a wireless access point? What is the policy on that and what are the repercussions? What about non-employees such as contractors, visitors and such? Make sure to set the policy on this stuff, and remember to make it enforceable. Now if you say something like, the person who does this is fired, then what are you going to do if the CEO brings his son to work? His kid gets on the network just to use the internet. Are you going to fire the CEO?

What security methods are you going to make your end users aware of? Do they need to understand what drive encryption is or how to use it? Your end users may be complete tech novices, but your security policy/end user information technology policy should try to lay out what a user needs to know. And in this they need to understand the expectation of privacy. The expectation of privacy shouldn’t be documented too much here because you should have logon banners on every single network device that can be logged into. But you should explain what the banner says and what it means. And technically, if you don’t remove the expectation of privacy on a company computer or network device, then your user still maintains it, so make sure you stay consistent.

Obviously if your end security policy exists then you need to have an end user security procedure document as well. Every policy document should have a corresponding procedure document. And this procedure document needs to be referenced in your policy document. So, for instance, if your policy states that you have to make sure Windows Updates are installed every month, you should follow that up with something like, “Page 7 of the End User Procedures document explains how to do this.” You can’t expect your end users to know what Windows Updates are, let alone how to install or make sure they are installed every month. Try to do this as often as possible. It may take a lot of time to set up initially, but you can cut down on a lot of IT helpesk calls if you reference your procedures and keep all of this documentation easily accessible on the corporate intranet website. C’mon, throw a dog a bone. We aren’t the police here, we’re here to help, not criminalize.

Security doesn’t only mean network equipment either, now does it? Physically speaking, how do company employees get in the building? Do you require swiping an ID badge at every outside door? How about pin numbers or cipher locks? What doors do you not allow people to use unless emergency? Who gets keys to the building? What’s the policy for getting an ID badge or set of keys to the building? There are a lot of things to think about from an end user perspective. Be sure to go through every possible scenario that your company has and address it in your policy and explain how to do it in your procedures. Again, what about non-employees in the building? Do you require people without badges to show proof of who they are or ask questions on how they got in?

How about protecting intellectually property? What is the company policy for that one? This one is a touchy subject that needs to be discussed with some folks at the top of the chain. If you can get the Director of HR, the CEO and your CIO/CSO to give you their opinions on this first, you’d be in a better place to write this policy. Either way, when writing this policy, you have to make sure you are consistent. Any contradictions in your policies and procedures and you can throw these out the window.

Lastly, now you need to follow what you wrote and so does everyone else in the company. That means that all employees should review the policies once a year and sign off that they read them. Encourage people to ask questions. Get a training group together if needed. And if you think you’re going to get away with not having to follow your own document, you better believe other people are going to try their best not to follow it as well. If you made the cool-aid, you better drink it, unless you’re a malicious person by nature, then you shouldn’t be making cool-aid, let alone writing security policies. If you follow these simple tips, I promise that writing your company information technology and security policies and procedures will be much easier, not to mention that your end users will follow them much better.