Designing the documentation set

Following the discussion of the last section, it is clear that a well-designed documentation set that is kept up to date to reflect reality is an extremely valuable asset. On the contrary, poorly designed documentation or docu-mentation that is out of date can prove to be more a liability than an asset and can result in a lot of unnecessary work. The problem is that the terms well designed and poorly designed only have meaning when the criteria for separating one from the other are clear, and these criteria are likely to differ from organization to organization.

Despite this fact, it is not too difficult to define a set of criteria that should apply to most organizations. For our purposes, a good documentation set has the following characteristics:

◗ Easy to use;

◗ Easy to maintain;

◗ Accurate and up-to-date information;

◗ Appropriate for target audience;

◗ Only relevant and essential information.

At The Secure Bank, we undertake the task of designing the documenta-tion set as the first task of the informadocumenta-tion-security policy initiative. This decision is motivated by the fact that the content of the policy will be influ-enced by the structure of our documentation set, so we need to have the structure of the documentation set in the back of our minds as we write the policy document.

Given the existing company culture, where actions are judged as being important and documents considerably less so, we will aim to limit the docu-mentation in the short term and to build up the document set gradually.

For similar reasons, the design and implementation of document-control

procedures will initially be carried out as an internal activity. Documents des-tined for other departments, or for the organization as a whole, will ulti-mately be published on the information-security Web site. Consequently, the details of the document-management system and the structure of the entire documentation set will be transparent to staff members outside the information-security department. This approach enables us to impose a cer-tain level of rigor without running the risk of being seen as too theoretical.

The design of the documentation set is illustrated in Figure 6.1.

According to this schema, all documents owned by the information-security department will be classified as being internal or external. Any document that is published to staff outside the department is automatically an external document.

Internal documentation consists of all documents that are necessary for the correct functioning of the department, but are not for an external audi-ence. Internal documentation also includes a range of documentation that is used by, but not owned by the information-security department.

Referring to the examples presented in Section 6.1:

◗ Management documentation includes contracts, plans, reports, and documents relating to budgets and financial plans. Nondisclosure agreements are also considered management documentation, as they are under the control of the department manager.

6.2 Designing the documentation set 133

Security documentation

Internal documentation

External documentation

Management documentation

Internal procedures

Policies

Working papers Project

documentation

Technical documentation

Other

documentation

Guidelines Standards

Figure 6.1 The information-security documentation set.

◗ Internal procedures cover aspects such as internal reporting and local administration procedures. In particular, the procedures managing the documentation set itself (such as change-control procedures) are con-tained here.

◗ Project documentation includes all documentation produced within the scope of internal projects (i.e., projects that are exclusively under the control of the information-security department and have minimal external impact—an example might be the implementation of a secu-rity scanner).

◗ Technical documentation includes vendor-supplied documentation, technical reports, and similar material.

◗ Other documentation includes any other documents of interest, organized by subject, including legal and regulatory documentation, training material, and conference proceedings.

Note that legal and regulatory documents are not typically owned by the information-security department and are therefore stored underother docu-mentation. User guides appear nowhere in this list because they are destined for end users and are therefore an example of external documentation.

External documents produced by the information-security department are organized into a hierarchy to help staff appreciate the type of informa-tion they contain. This hierarchy represents the organizainforma-tion’s view of pub-lished information and is illustrated in Figure 6.2.

As far as published documents are concerned, the most authoritative document is the information-security policy (ISP) document; other policy documents, such as the IT security policy, are required to be consistent with the requirements of this policy. Standards are authoritative in a particular well-defined area and translate policy requirements within a specific con-text. Finally, guidelines and working papers have no authority whatsoever, but are produced as a useful aid to implementing security requirements.

In the rest of this chapter, we will look at the documentation produced by the information-security department from this latter perspective.

Guidelines and working papers Standards

Other policies ISP

Increasingauthority Increasingpracticalvalue

Figure 6.2 Hierarchy of published documentation.

6.3 Policy

6.3.1 The purpose of policy statements

Policy statements describe in very high-level terms how an organization has chosen to deal with a particular issue. As such, they essentially distinguish what is acceptable or appropriate from what is unacceptable or inappropri-ate. In Section 6.3.3, we define what we mean by the termsacceptableand appropriatevery carefully, as this ultimately leads to a useful way of intro-ducing a certain degree of flexibility into policy statements. There exists a wealth of material on policy statements and how to create them (for exam-ple, [1–4]). The purpose of this section is not to summarize this material, but to supplement it by illustrating the role of policy statements within the approach outlined in Chapter 4.

Policy statements are important for several reasons:

◗ They provide guidance.

◗ They form the foundations of the control framework.

◗ They define roles and responsibilities.

◗ They document the organization’s stance with respect to the issues addressed.

First and foremost, albeit at a high level, policy statements provide guid-ance by stating how things should be or how things should be done. In order to achieve this, policy statements are designed by taking a number of different factors into consideration, including known risks, legal and regula-tory requirements, and cultural values.

Policies must be unambiguous and easy to understand, as they form the foundations of the control framework (i.e., the procedures and security mechanisms that are put in place to ensure that the organization is appro-priately secured in its day-to-day activities). The supposition underlying most control frameworks is that the policy requirements upon which they rest will not change substantially with time. Indeed, it is common practice to avoid placing volatile information (i.e., information that is likely to change quickly) in policy statements. Control frameworks are a recognition of the fact that we cannot analyze the consequence of routine actions every time we undertake them. They provide a solution by standardizing the way to carry out the action based on an initial analysis.

In contrast, risk-analysis techniques are used to measure risk at a given moment in time. A risk analysis is one of the inputs into the policy design process and can be used at any moment to check that policy requirements make sense in particular circumstances. For this reason, risk-analysis tech-niques provide a useful mechanism for checking that policy requirements are reasonable in a given context and for overriding policy when this obvi-ously makes sense.

Policy statements are a particularly efficient method for defining roles and responsibilities within a given area and are frequently used for this

6.3 Policy 135

purpose. The use of roles is particularly advantageous, as the concept of a role is independent of the organizational structure. This allows roles to be mapped to management positions in a flexible manner. This is particularly useful when reorganizations take place. In this area, it is critical that over-laps or dependencies between policy statements are correctly controlled and that the resulting roles and responsibilities are coherent.

Policies also document an organization’s way of handling a particular issue. This may be required for a number of reasons, including compliance with regulatory requirements, supporting disciplinary measures in the case of misconduct, and reducing liability. The availability of a coherent set of policies is also likely to prove to be an asset for organizations seeking com-pliance with external standards, such as ISO 17799/BS 7799 in the field of information security or ISO 9000 where quality systems are concerned.

6.3.2 Identifying required policy statements

Within the information-security domain, there are no hard and fast rules for defining the scope of policies, and sample policy statements are available on the Internet for addressing a wide variety of issues. Examples of sites offer-ing sample policy statements free of charge include the SANS organization [5] and the NIST [6]. Commercial sources of sample policy statements include [7–10]. In addition, many institutions publish their own policy statements on the Internet, and these can be useful sources of inspiration (be aware, however, that these policy statements are invariably protected by copyright laws).

In order to get the most out of this material, it is necessary to give some thought to how policies will be structured, and this will most likely depend on the size and culture of the organization. For smaller organizations, a sin-gle policy might be preferable, but larger organizations may find this approach too restrictive and opt for a series of more targeted policy state-ments. In general, publishing a series of policy documents has the advantage of keeping individual policies short and focused, but it may prove to be diffi-cult to avoid some degree of overlap in scope. Managing these overlaps and the redundant information they give rise to may prove to be difficult. On the other hand, where larger organizations are concerned, publishing all policy statements relative to information security in a single policy tends to produce a forbiddingly large document, different sections of which will be aimed at different groups within the enterprise. It is therefore clear that one of the key decisions to be made when designing policy documents is how such documents should be organized.

At The Secure Bank, we will aim to produce two core policy statements in the first strategic-planning cycle. The first core policy, the information-security policy, will be a relatively short document, summarizing the essen-tial policy statements in a nontechnical manner. The audience for this document is the entire organization. The second policy, the IT security pol-icy, is focused on more technical issues and addresses a number of subjects that are of little interest to the majority of staff members, but which are

critically important for technical staff. It is important to realize, however, that the IT security policy does not enter into technical details. The purpose of this policy is to provide high-level policy statements in specialist areas, such as application development or use of cryptography.

Other policy statements will be created if they are really required, but the goal will be to limit the number of policies at this stage in order to con-centrate on what is essential. This approach is appropriate for this planning cycle, as it is in line with the company culture and also minimizes adminis-trative overhead. In fact, we have already identified the need for at least one additional policy statement—the requirement for a privacy policy to support the activities of the marketing department was identified during the consoli-dation period. This document was agreed on by the information-security steering committee in month seven. Consequently, we need to ensure that the core policies are aligned with this existing policy and issue a revised ver-sion of the latter if required. In reality, changing the privacy policy will be a solution of last resort, as this has a direct impact on customers.

6.3.3 Design and implementation

Once the decision has been made on how to structure policy statements, work can begin on producing individual policies. As we saw in the last sec-tion, it is sometimes necessary to produce policy statements before the structure has been thought out. Under these circumstances, it is best to be proactive and to sketch out a rough model of how policies will be structured before writing the policy. Normally, this will be sufficient to ensure that the final structure is coherent, even if minor modifications to the original rough design are necessary.

Policy statements are likely to be influenced by a variety of factors. All policy statements in the area of information security will need to take into account all legal and regulatory requirements, the threats to which the enterprise is exposed, and the corporate culture. Some policies will also be affected by other factors. As an example, policy statements related to the use of software will probably need to take account of the current state of the art and predicted evolution of security functionality in order to be credible. Pur-suing this example, it is of no use to mandate the use of secure crypto-graphic protection mechanisms if the software to implement them is not available. This is particularly important for international organizations, where it may be relatively easy to satisfy a particular requirement in the country where the parent company resides, but extremely difficult in other countries. Again, this example is pertinent, as the use of cryptography is restricted in many countries.

The most important point to bear in mind when developing policy state-ments is that it is vital to involve those concerned in the process. Involving people in the development of a policy greatly reduces the chances that it will be rejected during the approval process. This doesn’t mean that it is neces-sary to start with a blank page, either, and most organizations will need strong guidance in producing policies. For organizations that have existing

6.3 Policy 137

policies in place, even unsuccessful ones, it is worth analyzing these policies to identify those elements that are appropriate. These can then be used as a possible starting point for creating new policies.

One way to involve people is to identify any groups that are likely to be impacted by a policy statement before beginning to develop it and to invite a representative from each group to participate in an ongoing review process.

For this type of exercise, it is useful to include a mixture of experience, including management and the staff that actually carry out the work. The latter group can be further split into staff performing business tasks, techni-cal staff, and administration staff, thus ensuring that potential policy state-ments are reviewed from a variety of different perspectives. The policy can then be developed by regularly circulating incomplete versions of the docu-ment for review and taking account of the feedback. Ideally, this process starts with the distribution of a skeleton document, consisting of a list of titles and a brief description of the content of each section. Subsequent ver-sions might be distributed on a weekly basis until the document is com-pleted. Interim meetings can be used to resolve punctual issues, which also helps resolve issues when a participant has particularly strong views.

Identifying the target audience and securing its participation in the development activity helps to ensure that we will receive quality feedback during the policy-development process. The next goal is to ensure that the policy is realistic. In the author’s experience, groups producing policies tend to err on the cautious side and produce over-restrictive policies. Over-restrictive policies do not survive because the work has to be done, and staff will always find a way to circumvent something that is obviously unreason-able. Workable policy statements achieve an acceptable balance between efficiency and control.

At the beginning of this section, we emphasized the difference between acceptable and appropriate behavior. This distinction is important, as it leads us naturally to a corresponding distinction between mandatory require-ments and requirerequire-ments that are to be satisfied on a best-effort basis. For our purposes, we therefore define unacceptable as some state of affairs or some behavior that will not be tolerated by the organization. The adjective inappropriateon the other hand is used to describe a situation or behavior that is undesirable but may prove to be unavoidable. As a result of these definitions, policy statements aimed at preventing unacceptable situations will be mandatory, whereas those aimed at preventing inappropriate situa-tions will be satisfied on a best-effort basis. This simple convention provides us with a way of introducing limited flexibility within policy statements, which in turn enables large organizations to fine tune these policies to par-ticular situations.

In the policy statements we will create at The Secure Bank, we will employ a convention often adopted within RFC documents [11], as pub-lished by the IETF, to distinguish between mandatory and best-effort requirements. According to this convention, the wordmustis used in stating mandatory requirements and the wordshouldis used for requirements that are to be met on a best-effort basis.

6.3.4 The Secure Bank—Policy statements

At The Secure Bank, the strategic initiative to define and agree on core pol-icy statements began at the end of month six as planned. In order to simplify management of the resulting documents, policy statements were produced in line with a standard template, based on the structure defined for the pri-vacy policy. This template consisted of a document-management section containing change-control information, a section identifying the target audience, an initial introduction, a description of the structure and scope of the policy, a section containing policy objectives, and a glossary. In addition, the final page was reserved for sign off by approvers. This common structure is illustrated in Table 6.1 and is assumed throughout the rest of this section.

The information-security policy was produced and agreed on within the agreed timeframe. The structure and content of the information-security policy are summarized in Table 6.2.

The last section of this policy deserves a special comment. Given that we have deliberately introduced flexibility into the policy framework by distin-guishing between mandatory and best-effort requirements, the policy waiver process will be deliberately dissuasive. Obtaining a policy waiver will require a detailed justification and will be signed off at the executive-management level.

The production of the IT security policy took longer than expected, largely due to discussions related to the level of security that should be applied to development environments. The final decision was to segregate development environments from production environments and to allow a more flexible approach to security for development teams. It was agreed that risk would be mitigated by enforcing technical controls at the

The production of the IT security policy took longer than expected, largely due to discussions related to the level of security that should be applied to development environments. The final decision was to segregate development environments from production environments and to allow a more flexible approach to security for development teams. It was agreed that risk would be mitigated by enforcing technical controls at the