|
Executive Summary
Network security experts agree that well-run corporations need a written security policy. The policy sets appropriate expectations regarding the use and administration of corporate IT assets. However, the conventional w isdom holds that composing and maintaining these documents bog down in a morass of bureaucratic inefficiency and pointless wrangling, which never ends and produces nothing useful.
This paper lays out a common-sense approach to writing corporate security policies that makes them easier to draft, maintain, and enforce. Our "question and answer" approach requires no outside consultants. Instead, you can use your in-house knowledge and resources to yield a brief, usable, and – most importantly – understandable policy document, in a reasonable amount of time. To help you generate such a policy, this paper clears away some misconceptions about the purpose of network security; details the process of writing the policy; then explains how to keep refining the drafted policy.
Introduction
It is the rare organization 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 organization 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 keep people out there from getting in."
Realistically, many security policies are ineffective. Sometimes an organization gets lucky and has a security policy that is pretty good – but not usually. To be effective, a security policy (and, let’s reset that right now to “security policies,” because we are talking about a set of policies) should be consistent, relevant, and useable. The goal of this white paper is to help you create such documents.
Armed with this paper, your small- or medium-sized enterprise (SME) can either create your first computer network security policy, or beef up what you already have. This paper covers policy but not procedures. Computer and network security policies define proper and improper behavior; they spell out what is permitted and what is denied. Procedures detail the methods to support and enforce the policies, and usually describe specific steps to take in regular system administration. For example, your policy might state, "Server administrators must adhere to the company's operating system configuration standards." A separate procedures document would specify what all those settings are.
This paper will help you set policy. First, we correct some misconceptions to help you understand what your real goals are. Then we describe the process for writing your policy, and end with some thoughts on what to do after completing your initial draft.
Four Common Misconceptions
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).
|
