The duties of a security manager are far reaching, and probably one of the most difficult duties is the implementation and upkeep of a security policy. This tip from James Michael Stewart provides some guidelines for building a security policy.
Many of us who are technically oriented have a strong aversion to paperwork. Unfortunately, paperwork is often the foundation required to establish a reliable and secure IT environment. The paperwork I'm referring to is the collection of documents that comprise a formalized security infrastructure. Those documents include polices, standards, baselines, guidelines and procedures. Each of these documents focuses on a specific type or category of information related to the design and implementation of security within an organization. These documents following a hierarchical order with policies being at the top of the pyramid, followed by standards, baselines, guidelines and finally procedures forming the base of the pyramid.
The pyramid pinnacle is the security policy. A policy is a strategic document that defines the scope of security required by an organization. A policy discusses issues in broad terms using statements of goals, missions, objectives and purpose. It defines why security is important, why assets are to be protected and to what extent security should reach. A policy is a long-term document that should look out about five years and include visions of the future. In addition to establishing a direction for an organization's security implementation system, the security policy also serves as proof that senior management has performed prudent due care.
The expansion and creation of the remaining elements of the formalized security structure round out with due diligence. The remaining documents follow in order: standards, baselines, guidelines and procedures. These tactical documents range from generalized information (standards) to very detailed and specific information (procedures).
Standards define the compulsory requirements for the security of an organization. They discuss the types of technology to be deployed and establish uniformity of implementation across the entire environment. Standards define the steps, methods and means by which the goals of the security policy are to be accomplished.
Baselines flow directly from standards. A baseline is a specific set of security requirements that all systems within an organization must meet or exceed. The baseline establishes a common minimum secure state from which more stringent conditions can be applied. Often baselines are system specific. They may be imposed by industry or government standards, such as TCSEC, ITSEC, Common Criteria or CIS Baselines.
Guidelines are operational handbooks on how standards and baselines are implemented. Guidelines offer some flexibility in implementation procedures to allow for system or condition specific alterations. Guidelines prescribe methodologies and suggest specific solutions for implementing security.
Procedures are the detailed how-to documents that define exactly step-by-step how to implement the security mechanisms from the upper tier security documents. Most procedures are platform, OS, software and security mechanism specific. That means that a single computer on a network could easily have dozens if not hundreds of individual procedures applicable to it.
The importance of these documents can be clearly seen. However, here are some tips to make working with a formalized security structure a bit smoother:
- Maintain each level or hierarchy of document as a separate entity. Don't fall into the trap of creating a single document to serve all functions.
- Keep general statements in the upper tier documents and keep specific statements in the lower tier documents.
- Update the lower tier documents as often as necessary.
- Review and update the upper tier documents periodically -- policies: yearly, standards/baselines: quarterly, guidelines: monthly.
- Once a document is updated, destroy all previous versions from the production site. Maintain archived copies for historical reference.
- End users, managers and system administrators should have access to documents in the formalized security structure on a need-to-know basis only
