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.
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.
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.
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.
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.
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.
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.
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.
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
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.”
The following outline of a standards document helps you organize the content for your control and baseline standards:
STANDARD NAME AND IDENTIFYING INFORMATION
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.
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.
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.
Although there are generally no standard templates for guidelines, you can use or adapt the following:
GUIDELINE NAME AND IDENTIFYING INFORMATION
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: