Document Organization Considerations
Although there are many ways to organize a library of policies, one thing they all have in common is the need for a numbering scheme. A numbering scheme helps you organize the material by topic; it becomes a quick reference point for people to use to refer to specific content. You can create your own numbering scheme or use an existing one. Should you decide to use an existing framework like ISO/IEC 27002, you can begin with the taxonomy it provides.
NOTE
Taxonomy is the practice and science of classification. A hierarchical taxonomy is a tree structure of classifications for a given set of objects or documents.
FIGURE 7-2 offers an example that you might consider using for your taxonomy. Think of Figure 7-2 as a sideways tree. The program-level policy or information security charter on the left side is the “root.” It establishes the tree and delegates the authority for managing the tree to the information security department of the organization. Let’s call it IS (for information security), POL (for policy), and add “001” because it’s the first document: IS-POL-001.
FIGURE 7-2 A possible policy and standards library taxonomy.
To the right, you find a collection of program framework policies. This framework uses ISO/IEC 27002 topics for policy types. They are numbered in groups of 100 to allow for growth. Each of these policies stands on its own and serves as the first major branches of the tree. From these branches, standards and their supporting documents appear.
Looking at the Access Control (IS-POL-800) framework policy as an example, you can see control standards labeled IS-CSTD-810 through 840. The CSTD label is short for Control Standard. FIGURE 7-3 shows just this part of the policy and standards library.
FIGURE 7-3 Control standards branch out from the Access Control (IS-POL-800) framework policy.
Baseline standards are then numbered to maintain the consistency of the taxonomy and support the control standards upon which they’re based. The baseline standards are specific to technology and numbered as IS-BSTD-821 and 822, where BSTD stands for Baseline Standard. These two standards define the requirements for password management as they pertain to the Windows operating system and the UNIX operating system. In this example, the numbering follows the parent standard’s numbering, IS-CSTD-820.
TIP
Whatever numbering scheme you adopt, leave plenty of room for adding new documents. Think through a numbering scheme carefully before you decide to use it. Ask yourself how you would add new policies. How would you add new technology areas such as introducing mobility into the organization for the first time?
Procedures link to the baseline standards that they support. For example, IS-PROC-821 and 822 are directly mapped to the 821 and 822 baselines. In most cases, there is a one-to-one mapping of baselines and procedures in support of the control standard. FIGURE 7-4 shows a closeup of baseline standards and procedures in the policy and standards library tree.
FIGURE 7-4 Baseline standards and procedures provide additional branches of the library tree.
Guideline documents are most often tied to a specific control standard, as shown in FIGURE 7-5. Guideline documents (GUIDs) are useful where there may not be any technology for enforcing controls, but the guidelines provide useful information for process management or controls.
FIGURE 7-5 Guidelines provide additional branches of the library tree.
When people look for a specific document, the name of the document should tell them all they need to know. After they gain some experience with the taxonomy, they’ll know where to look.
Sample Templates
This section looks at some suggested document formats for policies and standards. You can use these as is or create a template that best reflects your organization’s needs.
Sample Policy Template
The following outline of a policy document helps you organize the content for your program-level policy and framework policies:
POLICY NAME AND IDENTIFYING INFORMATION
- PURPOSE
This document establishes a policy for . . . - BACKGROUND
This document was developed because . . . - SCOPE
This policy applies to the use of . . . - OPERATIONAL POLICY
4.1. Section 1
4.2. Section 2
4.3. Section 3
4.4. Section 4 - ROLES AND RESPONSIBILITIES
The following entities have responsibilities related to the implementation of this policy: - APPLICABLE LAWS/GUIDANCE
- EFFECTIVE DATES
This policy becomes effective on the date that [xxx], Chief Information Officer (CIO), signs it and remains in effect until officially superseded or canceled by the CIO. - INFORMATION AND ASSISTANCE
Contact the . . . for further information regarding this policy. - APPROVED
[Director of Information Security Policies] Date of Issuance - ASSOCIATED RESOURCES
This policy is augmented by . . .
TIP
Never use individual (personal) names in a policy or standard. For Role and Responsibilities, use the name of the department, unit, or specific role that is accountable. Individuals join and leave the company.
The following is a sample policy statement for access control that would appear in the “Operational Policy” section of a framework policy:
Personnel must be positively authenticated and authorized prior to being granted access to <Organization> information resources. Access based on an individual’s role must be limited to the minimum necessary to perform his or her job function.
Access to critical information resources must be controlled through a managed process that addresses authorizing, modifying, and revoking access, and periodic review of information system privileges.”
Sample Standard Template
The following outline of a standards document helps you organize the content for your control and baseline standards:
STANDARD NAME AND IDENTIFYING INFORMATION
- PURPOSE
This document establishes a standard for . . . - BACKGROUND
This document was developed to support . . . - SCOPE
This standard applies to the use of . . . - STANDARD STATEMENT(S)
4.1. Section 1
4.2. Section 2
4.3. Section 3
4.4. Section 4 - ROLES AND RESPONSIBILITIES
The following entities have responsibilities related to the implementation of this standard: - GUIDANCE
Links to guidance documentation for this standard . . . - EFFECTIVE DATES
This standard becomes effective on the date that [xxx], Chief Information Officer (CIO), signs it and remains in effect until officially superseded or canceled by the CIO. - INFORMATION AND ASSISTANCE
Contact the . . . for further information regarding this standard. - APPROVED
[Director of Information Security Policies] Date of Issuance - ASSOCIATED RESOURCES
This standard is augmented by . . .
The following are sample statements for access control that would appear in the “Standard Statement(s)” section of a control standard:
Access to all <Organization> information resources must be controlled by using user IDs and appropriate authentication methods as required by the Information Classification Standard and the Information Handling Standard.
Access to all <Organization> information resources connected to the <Organization> network must be controlled by using user IDs and appropriate authentication.
In order to ensure individual accountability, the use of any user ID must be associated with a specific individual. Passwords must never be shared between users.
The following is a sample statement for UNIX account management that would appear in the “Standard Statement(s)” section of a baseline standard:
Default system accounts must be locked (except root). The password field for the account must be set to an invalid string, and the shell field in the password file must contain an invalid shell. /dev/null is a good choice because it is not a valid logon shell.
Sample Procedure Template
The following outline of a procedures document helps you organize the content for any procedures needed to implement baseline standard controls:
PROCEDURE NAME AND IDENTIFYING INFORMATION
EFFECTIVE DATE
Date the procedure becomes effective. This can be the same as or later than the approval date in order to allow time for training and implementation if necessary.
- PROCEDURE
Insert procedural steps in the table . . .
1.1. Section 1.1
1.2. Section 1.2
1.3. Section 1.3
1.4. Section 1.4 - STANDARD
Indicate the name and number of the baseline standard to which this procedure relates. - FORMS
List any form numbers and names and their location if there are any needed to conduct this procedure. - PROCEDURE HISTORY
List all previous known versions (including obsolete procedure numbers or titles if known) and their effective dates. - INFORMATION AND ASSISTANCE
Contact the . . . for further information regarding this standard. - APPROVED
[Director of Information Security Policies] Date of Issuance - KEYWORDS
Indicate any cross references, aliases, phrases, or terms that describe the procedure. Define all acronyms and abbreviations. - ASSOCIATED RESOURCES
This standard is augmented by . . .
The following is a sample procedure snippet for data destruction on media that could appear in the “Procedure” section of a procedure document:
Disk sanitization involves securely erasing all the data from a disk so that the disk is, except for the previous wear, “new” and empty of any previous data. For example, a disk connected to a Linux system may be sanitized by repeating the following command three to seven times (or more):
dd if=/dev/random of=/dev/hdb && dd if=/dev/zero of=/dev/hdb
This command first writes a random pattern to disk /dev/hdb, then writes all zeros to it. Any disk that needs to be sanitized, including any flash memory device or former PC or Macintosh disk, may be attached to a Linux (or other UNIX) system and erased using the above command, replacing /dev/hdb with the appropriate disk device name.
Sample Guideline Template
Although there are generally no standard templates for guidelines, you can use or adapt the following:
GUIDELINE NAME AND IDENTIFYING INFORMATION
- PURPOSE
This document provides guidance and advice in helping to meet the control requirements from Standard(s) . . . - BACKGROUND
This document was developed to support . . . . - SCOPE
This guidance applies to the use of . . . . - GUIDANCE SECTION(S)
4.1. Section 1
4.2. Section 2
4.3. Section 3
4.4. Section 4 - ROLES AND RESPONSIBILITIES
The following entities have responsibilities related to the implementation of this standard: . . . - EFFECTIVE DATES (may or may not be needed)
- INFORMATION AND ASSISTANCE
Contact the . . . for further information regarding this document. - APPROVED
[Director of Information Security Policies] Date of Issuance - ASSOCIATED RESOURCES
This guideline is augmented by . . .
The following is a sample guideline snippet for the use of encryption within a university setting. This text could appear in the “Guidance Section” section of a guideline document:
University personnel and student organizations:
- Should use industry-standard encryption algorithms to protect their data.
- Should not attempt to develop their own proprietary encryption algorithms and should carefully scrutinize any claims made by vendors about the security of proprietary encryption algorithms.