Many good words have been spoken and written about the need to have a Security Policy. Doubtless, most of them are good and true. But the overwhelming problem with Security Policy is that there is so much of it. And there needs to be. There are so many situations that need to be covered. So much technology, each piece of which needs its own set of standards. Its own guidelines on use. Its own policy. And as the technology race keeps driving on, so more and more policy needs to be written to cover it. The result is a burgeoning file that is impossible to keep up to date. The security team work with it as best they can, but when the Head of Security is replaced, the new man comes and, deciding he cannot work with the old policy, with a flourish of a new broom, he sweeps it into the nearest skip (there is too much of it to go in the bin!). He then starts the cycle again.

And what do the users think of all this? Well they all have to have their own copy, don't they? After all, if they don't know it exists, how can they be expected to follow it. So each manager gets their own version. Neatly packed into a binder. The best that money will allow. And each manager in turn receives it gratefully and puts it to good use. Propping up the other corporate manuals, or acting as a doorstop. Well all right, there are some ungrateful recipients also who just put it into the nearest skip.

And in their time, there have been many security folk, good and true, who have recognised the issue and tried many and various remedies. Some more successful than others. The basic problems still remain. There is a lot to be put across to a variety of audiences in a shape and form that they can understand, and will work with. And there isn't a simple solution.

The problem becomes worse when one thinks beyond the organisation in which the policy exists. How is the policy communicated to those outside the organisation that need to know? Suppliers, partners, even customers have an interest. In these days of e-commerce and e-business, e-marketing and e-sales. E-everybody ends up with a need to know. And it is not as if each group is lacking their own policy (OK, I admit it, many of them do lack their own policy but the situation is improving which is why the Security market is expanding). But things are made worse by all these differing policies. How can I trust you and your organisation if I don't know what your policy says. Do I have the time to read your doorstop? Or do you have time to read mine? How can I have confidence that your policy covers everything I think it should? I am not even sure my policy does that. How can I be sure that your organisation implements it properly (I know it can't because I know what things are like in my own back yard). Ignoring all this heartache, the organisations merrily carry on working together, exchanging information, connecting their networks, taking risks. What else can they do? Such things are always more dependent on relationships between key individuals than on the security experts. And sometimes things do go seriously wrong. Information suffers loss or harm and the organisation suffers as a result. Questions are asked in the house and people are strung from the yardarm.

It would be wrong to say that nothing has happened to improve the situation. Good men and true have deliberated long and hard over the situation. Some have actually done something. For example, the UK Department of Trade & Industry, working with a number of commercial organisations came up with a 'Standard of Good Practice for Information Security Management' which went on to become British Standard BS7799. This lead was followed by Germany, Australia and other countries. There is hope that this might become an International Standard. It is not perfect (what is?) but it does provide a framework for policy. A yardstick by which to measure completeness. It is now feasible for two organisations to compare each of their policies against BS7799, and then use that cross referencing as a means to confirm that their policies are similar to an extent. It is even possible now to be independently accredited as matching up to BS7799. No mean feat! So congratulations, well done chaps.

But there are still some problems. In fact, most of the problems still remain. The framework is still only part of the body of necessary policy material. It is not an easy read. (How many people do you know that prefer policy to a good novel?). It is not something that can reasonably be given to managers, users, other organisations, and is definitely not designed for consumption by customers. Where a security manager has preferred policies that explain things his users are interested in (an Internet policy, an email policy etc.) how can completeness be demonstrated? For consenting organisations it is still a long, tedious process to follow (and costly now, if accreditation is insisted upon). How can trust be built? How can organisations be helped to work together whilst quickly grasping the different attitudes to Information Risk?

Is there a solution? Can anything more be done? There is no panacea, but perhaps a different model of policy will help.

Starting with a smaller set of things to agree should help. It is argued in a separate paper 'Information Security Principles' that there is a small set of principles from which all security policy can be derived. If agreement can be reached on these, then there is a start point around which trust can be built.

The framework is then a broad set of material covering the breadth of Information Security Policy. It is actually smaller than BS7799 because that worthy document also includes detail on, for example, password standards.

The standards contain details of particular settings. E.g. passwords should contain a mix of alpha and numeric characters, be at least 6 characters long etc. etc. It is probably convenient to make the standards hierarchical. Generic standards that apply across the patch, then e.g. standards for UNIX systems where not already covered, then standards for a particular flavour of UNIX, then for a particular version of that flavour.

Policy and standards are mandatory. Guidelines are a body of material that contain useful explanatory material that is good practice, but is not mandatory.

You will see (hopefully) that this overall hierarchical approach from Principles through the layers of increasing detail, does make it easier to leave agreement on detail till later. Indeed, there may be no need to agree that CRUIX version 2.3.7 must have the overlap switch set on for night running.

There are two further parts to the model to assist better joint understanding of policy.

Firstly, Scenarios.

These are combinations of principles, framework, standards and guidelines used to make the policy for a particular area crystal clear. For example, an Internet Policy would be a scenario. A scenario will be consistent with the organisation's overall policy.

Secondly, Waivers

These are agreed exceptions to Standards, and potentially the framework. For example, The widget control system can only provide 3 character passwords. The risks have been formally analysed and accepted by the organisation for a period of 6 months from the date of this document.

Now that we have made some progress with the comparison issues, we can move on to tackle others. It may still be useful to create paper versions of parts of the documentation, for example Principles and Framework. To be of most use though, electronic publishing has to be the way to go. Break the text up into small pieces and put some effort into cross-referencing. References from principles down through the framework and into standards, and back up again. Add in references to BS7799 and other worthy documents such as the Information Security Forum (ISF) Survey. Quite a task. Then put the whole thing into a database and make it available on your Intranet. Use the cross-references to create hyperlinks. Add in a search mechanism. Now you have a useful tool that won't be relegated to being a doorstop. It may not be the most used item on your Intranet, but it will be used. Particularly if you spend a little effort on communicating its existence, and how to use it.

So, if you want to get your policy out there and really taken seriously, then
1. Start with the basic principles
2. take on board a new model
3. relate it to BS7799
4. put it all in a database
5. make it available on the Intranet
6. with extensive hyperlinks and a search capability
and measure how much it is used.