Planning a policy is the first step towards good security.
It is the rare organisation that is happy with its security policy – many will admit to not even having one. Every organisation follows either a formal or an informal security policy, even if it is what we jokingly refer to as the Primordial Network Security Policy: allow anyone in here to get out, for anything, but stop everyone out there from getting in.
Realistically, many security policies are ineffective. Sometimes an organisation gets lucky and has a security policy that is pretty good – but not usually. To be effective, a security policy should be consistent, relevant and useable.
The first step in writing your policies is to gather a team. Writing a set of security policies is usually a top-down process, but it does not have to be and many combine bottom-up and top-down approaches. Your policy development team should be made up of people who work with your network and the internet, but come from different functional areas of the organisation.
Each manager in your organisation has a unique view of the company’s needs and risks. You need people who know something about the technology, but also some who know about the organisation. Include some people from the trenches too, but don’t let the process of forming the committee halt the progress.
Before writing any policies, scope out your organisation’s requirements, such as what regulations apply. To consider other issues, ask yourself:
- What services are required for your department and how might you provide them securely?
- How much do employees depend on internet access, use of email and availability of intranet services?
- Do your users need remote access to the internal network?
- Is there a business requirement for everyone to have access to the web?
- Do your customers access your data via the internet?
It takes discipline to repeatedly ask yourselves if there is a business requirement for every service, but these are the most important drivers of your security policies. Business drivers help you distinguish between what the organisation really needs, as opposed to what a few employees want. If you have trouble getting started, look at what you are already doing and ask yourselves why.
The next step is then to create a Root Security Policy, which will include subordinate policies for computer acceptable use, passwords, email and web usage, mobile computing and portable storage, remote access, wireless and an incident response plan. The Root Security Policy should also briefly describe:
- Penalties for breaking policy
- Who enforces the policy
- Who must abide by the policy
- How to request policy changes
- How often the policies must be reviewed
Acceptable Use Policies
After you have the Root Security Policy, providing the Acceptable Use Policy largely means making lists and asking questions.
Your list might include acceptable use policies for desktop computers, mobile computers, servers, routers, email systems and applications’ data.
For each asset, define who administers the asset, who uses it, how critical it is to the mission of your departments, how to manage it and how to protect it. You might like to also review policies of how data is stored.
Even with the best Acceptable Use Policies, you still might find yourself dealing with a network security intrusion or incident. Since mid-incident is the worst time to develop a plan, your next step is to formulate an Incident Response Policy. Initial questions to answer may include:
- What do you consider a security incident?
- If an incident occurs, who are you going to call? Communicate your decision to everyone in the organisation.
- When must you call the police or other local authorities?
- Which are your most important systems? If a security incident brings systems down, balancing the importance of each system against how long it takes to recover it will help you prioritise your triage efforts.
Creating a draft security policy is just the starting point. You must refine it, and then – when you are satisfied with it – you must periodically pick it up and view it again. Review with a critical eye.
Ask questions, challenge your assumptions, write it all down and give yourself permission to be less than perfect.