If you listen to security vendors, they’ll tell you that you need to spend substantial chunks of your hard-fought-for IT budget buying firewalls and Intrusion Protection devices to make your network secure from intruders and disgruntled and careless staff. They’re right of course, to an extent. But you can install all the kit you want, and if you don’t have the security policies and operational procedures in place, you might as well use that £10,000 firewall as a doorstop.

Policy requirements
A security policy is not something that should be written by a bunch of IT techies. It’ll end up full of in-depth detail, and most people in a company will find it impossible to understand. You also need representation from management (sponsorship by someone of an appropriately senior level is essential if this is going to be taken seriously by employees) and the business user base to determine if the rules are actually workable and your legal, or HR, departments, to fill in the details as to what happens if people don’t comply.

It’s usually easiest to write several self-contained policies, covering different aspects. This makes it easier for changes to be made: policies shouldn’t be so detailed that they need to be rewritten if you change your server supplier, or router vendor, for instance. Individual policies could be written to cover these, for example (although there could be many more):

• Computer resource acceptable use (personal email, unsuitable websites, etc)
• Remote Access Guidelines
• Password control
• Network device security
• Wireless communication
• Sensitivity and dissemination of company information
• Anti-virus use
• Test lab connectivity
• Firewall and DMZ configurations (policy rules, not specific configurations, unless you want to be constantly rewriting the policy document)

These should be written in plain and concise English, with a minimum of jargon. Remember that they should be written to be read by people. They should state what is and what is not permitted or expected, and why, and what the consequences of failing to comply are. It’s important to include reasoning behind the rules, with perhaps an indication of what the business impact of non-compliance could be, to encourage staff to accept the necessity for these rules that they might otherwise see as not their concern.

Advertise the policies
People have enough to remember just getting through their work day without bothering with some obscure IT-related information. Don’t put it on the company Intranet and just expect everyone to rush off to that site for a good read. Everyone should be given copies of the policies and made to sign them. Reminder posters in breakout areas and regular emails, or adverts in the company magazine, may sound like you’re back at school but will stop the excuse that they ‘didn’t know not to’.

Too many rules, too little attention
When writing the policies, try to make them as transparent to everyday business as possible. You can go over the top in setting up almost water-tight security rules, that are ignored because they are unworkable. Rules like these are worse than useless since they’ll lead to a feeling of false security.

Before we start having a go at users bringing in insecure wireless access points, or plugging a modem in the back of their PC, let’s take a good honest look at ourselves. There are large companies out there, with excellent IT staff and sizeable security budgets, where the comms rooms are full of ‘temporarily’ patched servers, switches and routers. They often aren’t on the correct side of the firewall, they don’t have all the patches or configs they should, and they’ve not been included in the AAA server for authentication. But they’re just there for a day or so to test something out, so that’s okay. No, actually it isn’t. But if it takes two months to get approval to connect something to the test lab, and you’re pushed for time, the temptation to circumvent the proper process can be irresistible. Don’t make things stricter than they need to be.

If people consciously make the decision to break the rules, then your company will have to decide what action to take. Fortunately that will be personnel’s problem, not yours. But if it has never been spelled out to them what is, and is not, acceptable behaviour, then it’s difficult to blame them, even though you might think it obvious that what they were doing was wrong, or just plain stupid.