Pen your network security policy

It is the rare organisation that is happy with its security policy.

Many will admit to not even having one.

But, security policies are like noses: everyone has one.

Every organisation follows either a formal or an informal security policy.

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 policy should be consistent, relevant and useable.

The process

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 doesn’t have to be.

Your policy development team should be made of people who work with your network and the Internet, but come from different functional areas of the organisation.

Each manager in your department 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.

However, don’t let the process of forming the committee halt the progress.

Before writing any policies, scope out your department’s requirements.

What regulations apply, including new state or local laws.

Start to become familiar with penalties for any non-compliance as this will help you prioritise your policies and gauge the proper level of discipline for employees who do not adhere to policy.

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?
• Does the public access your data via
the Internet?

It takes discipline to ask repeatedly, “Is there a business requirement?” for every service.

The business requirements 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, “Why are we doing that?”.

The answer will kick-start your response to the questions above.

The next step is to create a root security policy including 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 describe:

• Penalties for breaking policy. Talk to upper management and the human resources department.
• Who enforces the policy? All managers and supervisors should be responsible for the administration and enforcement of the policy.
• Who must abide by the policy? Will there be exceptions? Under what circumstances? Take the time to define an exceptions process, making sure that the process calls for periodic reviews.
• The other documents listed in the policy. The root policy forms the framework for the rest of the document.
• How to request policy changes. Specify when and how changes can be made and who can make them.
• How often your policies must be reviewed. A year is too long to go without a policy review.

Acceptable use policies

After you have the root security policy, providing the subordinate or 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 is to the mission of your departments, how do you manage it, how do you protect it? You might also review policies of how data is stored.

For example, is an employee allowed to store departmental information on a home computer? When and how should data be destroyed?

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? You probably will consider website defacement or a virus outbreak a security incident. But, is a port scan of all your Internet-facing systems a security incident? What if the LAN room was left unlocked overnight?
• If an incident occurs, who are you going to call? Everyone should know.
• When must you call the police or other local or state civil authorities?
• Which are your most important systems? Which are most difficult to recover?

Which are least important or easiest to recover?

If systems are down, balancing the importance of each will help you prioritise.

Your policy should state who is authorised to discuss your company’s security with outsiders.

Creating a draft security policy is just the starting point.

As you review what you’ve completed, look for areas where your answers could be misinterpreted, where your needs have changed or where your original ideas aren’t working out.

As with owning a house, part of owing a security policy is tinkering with it.

Don’t be afraid to make necessary changes to meet your evolving business needs.