Structuring a Security Policy - Part 1

Rather than giving guidance on the production of an individual policy, this post is designed to describe a generic process for the production of security policies.

Writing a security policy can sometimes seem like an exercise in minutiae. Starting with a clear concept of the purpose and audience of the security policy will speed up the drafting process and result in a more concise, readable document. There are two competing tensions in all work policies, they must assist workers to make sound, sensible, legal decisions and they must describe the consequences for employees who fail to abide by the requirements. Any new security policy should aim to be a combination of both of these, putting the carrot and the stick into one document. IT security is a complex subject that is baffling to outsiders, some of whom will need guidance and some of whom will not follow any advice unless it comes with a threat.

Within the overall security policy there should be three levels: the policy itself, the procedures which exist to enforce the policy and an implementation record. Using a simple example, a policy might state 'Passwords should be secure', the procedures would state that 'Passwords must be longer than eight characters and contain a number' whilst the implementation would state that 'User passwords on the Windows domain meet or exceed the procedure requirements. A group policy only allows passwords to be used which are over eight characters and contain a number.' This split means that policies are short, general and describe an ideal situation, the procedures are more detailed and describe the specific methods that are used to bring a policy about and the implementation describes how close the actual systems are to meeting the requirements of the procedures.

Obvious though the statement is, the pure policy section should be a readable, high level guide to what is important in terms of IT security to the organisation it is written for. This document will be read from cover to cover by every employee who joins the company, from a new CIO to a temporary post room worker, so it should be short, clear and well written. It should integrate completely and simply with the procedures document, so that any questions a new reader has can be simply answered by refering to the procedures. An ideal policy section should be able to be shared with third party companies, such as suppliers or clients without concern about sensitive information being contained within it, and should be able to be applicable to all systems and software within the organisation.

Procedures should get specific. They are unlikely to be read completely as part of an induction, instead line managers should ensure that the relevant sections have been read by their staff. There may need to be different streams within the procedures to cope with different levels of risk - for example, the password requirements for an account with administrator access may be more stringent than to log on as a regular user, or screen locking times may need to be longer for a sales team. As it will contain system specific information, the procedures document should not be available to any external organisation (with the exception of auditors). It is important to keep old versions of the procedures and to correctly date them - failing to follow the procedures could end up being part of a disciplinary hearing, when it will be essential to know which procedures were in place at the time of the violation.

Implementation information is not generally described as being part of the security policy, it has been spread across risk registers and audit documents. However, by including information about how the current procedures have been implemented as part of the security policy, it keeps the information readily to hand and allows for constant revision of the procedures. It also makes otherwise interminable security questionnaires from clients much quicker to deal with. Because the implementation might vary depending upon the work of developers (or even other members of the infosec team) it is important to maintain a close relationship with developers and to keep accurate date stamps on the implementations. Due to its highly sensitive nature implementation information should not be shared outside of the IT department.

During the whole process of writing, it needs to be remembered that the IT security policy should not be a bar to the normal functioning of business and should not try to create an overly powerful layer of bureaucracy. In SMEs where policies can become frayed, it is better to build a level of flexibility into the policy than creating a rigid framework that senior figures will ignore. An example of this would be creating a one page 'Emergencies' form as an appendix to the policy which would allow for work to be undertaken under the signature of a suitably senior figure - these emergencies can then be reviewed at a later date and tracked properly when there is more time. A security policy that oversteps its authority will quickly be ignored.