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.

Four Common Misconceptions done when creating a Network Policy for Business

1.

"The goal of network security is to secure the network" (or "the computers"). Securing the network is easy, but it's not your goal. Your real goal ― and a more difficult job ― is securing the business. The goal of network security is to support the network and computer business requirements, using methods that reduce risk. Security policies describe what you must secure, and the ways you secure them, to support your business or mission. Firewalls, intrusion detection systems (IDS), anti-virus (AV), backup and restore strategies, locked doors, and system administration checklists are all some of the things you might use. Security policies provide the blueprint for using them: the what, how, why, when, and by whom.

2.

"Security policies must be long and complex." In fact, just the opposite is true. We believe the well-known security axiom, “Complexity and security are inversely proportional.” Complex systems are usually less secure than simple systems. Complex policies are usually ignored; simple policies might live. A good security policy is really a set of documents, each addressing a specific need. By breaking your overall policy into smaller pieces, each managed separately, you greatly simplify the process of creating effective, consistent, relevant, and useable documents. This is not to say that the entire set of security policies will or should be just a few pages. But each individual element — each policy — should be usable by the target audience. “Usable” does not mean merely "understandable,” or even “readable” and “memorable.” It also has to take into account your corporate culture. So keep it real. Don't write academic tomes (unless that is your corporate culture). Write something your target audience can read and understand, in the amount of time their duties permit them.

3.

"Security policies have to be nearly perfect, or 100% complete." No. Good enough security now is better than perfect security never. For some reason organizations treat security as something sacred, when this is exactly the area where practicality should reign. There is not one right way to write a security policy. You are also allowed to modify it later. General George S. Patton said, “A good plan, violently executed right now, is far better than a perfect plan executed next week.” That is not to say that your goal should be to produce something shoddy or incomplete and call it “whole.” But it is perfectly fine to build security policies in parts, refining each part separately in the ongoing process of security policy development. Some parts will seem fully baked before other parts do. That's OK. That's how the process works.

4.

"Security policies only have to be written once." Until there are no more bad guys in the world and everyone agrees to mind his or her own business, the process of managing a security policy never ends. The threats your organization faces will change over time. As the threats to your business change, so too will your company’s business requirements. The vulnerabilities will change as well, and so will the risks you are willing to take to do business, and so will the tools you use to reduce or counter those risks. Because of all this, the security policy process is never really done. It only lies dormant for a time.