How to create a Root Security Policy

In this section we will interactively start to draft your policies, beginning with the Root Security Policy and then working through a few of the others. Each policy sets out the definitive answer to a set of key questions.

The Root Security Policy

The first document you’ll draft is the “Root Security Policy.” This is also the easiest to write, as it is the framework which points to the other policy documents.

As you draft a Root Security Policy, you will also enumerate the initial list of subordinate policies that you should produce next.

Your list will be specific to your organization, but will probably include the following subordinate policies:

Computer Acceptable Use. A general document covering all computer use by employees and contractors, including desktop, mobile, home PCs, and servers.

Password. A description of the requirements for password protecting computer systems, the rules for choosing passwords, and how the password policy is enforced.

Email. This policy covers the use of email sent from any company email address and received at any company computer system.

Web. A specification of what browsers may be used, how they should be configured, and any restrictions on which sites employees can visit.

Mobile Computing and Portable Storage. A description of who owns the mobile computing and portable storage on your network, how they are supported, and what specific devices (if any) are authorized for use on the company network.

Remote Access. A policy stating who can access what information from which locations under what circumstances.

Internet. A description of your Internet-facing gateway configuration, stating what is allowed in and out, and why.

Wireless. A specification stating how wireless access will be managed on your network; how access points will be plugged in, secured, and maintained; who is allowed to use them; and under what circumstances.

Servers. A statement of the company standards for servers, what services are enabled or disabled by default, and important distinctions between production, test, and development environments.

Incident Response Plan. No policy is complete until it also specifies what to do when defenses fail: what is considered a security incident; who gets called; who is authorized to shut things down if needed; who is responsible for enforcing applicable local laws; who speaks for the company.

The Root Security Policy will also specify numerous easy-to-describe items, such as:

• The company name. Does this policy apply to your whole company, or a distinct division, office, or locale?
• The purpose of the policy. What is it for? What do you hope to gain by creating a policy?
• The individuals or organizations responsible for the policy. Who is responsible for overall network security? The head of the IT department? The information systems security officer? Some other executive? (Tip: In the drafting phase, you are allowed to write “To Be Determined.”) Eventually, you will also want a “Site Security Committee,” a small group of managers and technical people representing various user groups in the organization, including the HR department. This committee is responsible for maintaining the policy so that it is current and relevant.
• The scope of the policies. Make sure that you state what geographies, organizations, and assets you are covering. State explicitly which geographies, organizations, and assets the policy does not cover, as well.

The Root Security Policy should also briefly describe:

• Penalties for breaking policy. Determining this will probably require talking to upper management and the Human Resources department, but will almost always include words such as, “disciplinary action up to and including termination of employment.”
• 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. All employees should be responsible for adhering to 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 review of the exceptions.
• The other documents listed in the policy. The root policy forms the framework for the rest of the document. This entry can be as simple as a bulleted list or as detailed as a bibliography.
• How to request policy changes. There will and should be changes as the policy matures. Specify when and how changes can be made, and who can make them.
• How often your policies must be reviewed. For most SMEs, a year is too long to go without a policy review. Monthly reviews are too frequent. If you are not sure what interval to specify, start with “quarterly, or as needed.” (“As needed,” for example, might be after a request for a change, or when the requirements or the apparent threats change.)

How many pages will all this fill up? As many as it takes, but usually no more than two to five pages (initially) for the Root Security Policy, and one or two pages for each individual sub-policy. In school, you might have gotten used to padding your documents to meet some minimum page requirement. In security policies, follow the opposite route: brevity reads like wisdom.