Network Security Blog

Time for my second discussion of the three P’s of security: People, policies and procedures. Last week I wrote about the importance of having the right people behind you (mainly the C-level management). Today I want to talk about policies. Yesterday I was reading an article in Information Security about … well information security, and guess what the very first item on their top 10 list was. You guessed it, policies. Number 2 was physical security, which is a topic I’ll save for another time (I had an interesting time getting into the office this morning, having forgotten my badge at home).

Corporate policies should be a series of high level documents that spell out in very general terms what is and is not allowed in the enterprise, what is expected of users and systems, and the consequences for not following the policies. What the policies should not do is specify which particular technology should be used to meet the guidelines, name specific people who are responsible, or be so restrictive as to be unenforcable. Policies are meant to be general documents that set up the guidelines for your business to do business. They should be specific enough to address security issues, but not so restrictive that they have to be re-written every couple of months. Thats what procedures are for.

Too many of the companies that I have worked for have no or poorly defined policies. Most of the policies they do have in place are of the unwritten variety; “That’s the way it’s always been done”. And if the company consists of 1 boss and his three employees, that’s fine. But if you are a company that employs hundreds of people, it’s kind of hard to disseminate via word of mouth to all of them. More importantly, you better have the policies in writing if you ever want to discipline an employee for abusing priviledges. It’s hard to enforce unwritten policies.

The company I work for is currently in the process of re-writing their policies. They have been in the process for quite some time, and now have two CISSP’s dedicated to the task. I don’t envy these gentlemen. They are having to write guidelines for a corporate culture that quite regularly ignores any IT policy that inconveniences the user in any way. Coming up with an enforceable set of policies for this place will be difficult at best.

This brings up two of my biggest issues with the way many corporations do policies: make sure the end user knows the policies exist and make sure they know that there are repercussions for not following the policies. Even I can’t expect an end user to follow a set of policies that they don’t know exist. As much as I’d like to say that most policies are just codification of common sense, we all know that common sense isn’t all that common. And most users are going to try to circumvent any policy that inconveniences them; it’s human nature. They need to know that they will get their hand slapped if they ignore corporate policy. Figuratively, of course.

So to sum up my rant: have a written policy in place, make sure the corporate populace knows about the policy, and write in penalties for breaking the policy. One of the better ideas I’ve heard of his making the employees re-read and sign off on the policy document on a yearly basis. Administratively a nightmare, but legally a real good idea. Finally, have a procedure in place for exceptions to policies. There are always going to be reasons, both good and bad, for not following a policy. Take this into account and write into your policy a set of guidelines to follow if you have to make an exception. Think of it as a pressure release valve; if you have to break policy to make something work, than the policy is more easily broken in the future. If you have an exception guideline, than every exception will have to follow the same guidelines.