The actual format (layout) of a policy will depend on what policies look like within a specific organization. It is very important that any policy developed look like published policies from the organization. Some members of the review panel will be unable to read and critique the new policy if it does not look like a policy.
Policy Development 29
Policies are generally brief (in comparison to procedures and practices), usually not much more than a page or two of material.
Information is an asset and the property of the organization. All employ- ees are responsible for protecting that asset from unauthorized access, modification, disclosure, or destruction.
When creating policies, it is helpful to understand that there are generally three types of policies that will be used during the development of a security document:
1. General policy — This is used to create the overall information security vision of an organization.
2. Topic-specific policies — These address specific topics of concern. There will normally be a topic-specific policy for each section of an informa- tion security document.
3. Application-specific policies — These focus on decisions taken by management to protect particular applications or systems.
3.6.1 Program Policy
Senior management is responsible for issuing a program policy to establish the information security policy of the organization and its basic construction.
This high-level policy defines the intent of the information security program and its scope within the organization. It also assigns responsibilities for implementation and compliance with the policy.
The components of a program policy should include:
Topic — The topic portion of the policy normally defines the goals of the program. When discussing information, most program policies concentrate on protecting the confidentiality, integrity, availability, and authenticity of the information resources. Additionally, it will attempt to establish that information is an item of value to the enterprise and, as such, must be protected from unauthorized access, modification, disclosure, and destruction, whether accidental or deliberate.
Scope— The scope is a way to broaden or narrow the topic, such as
“all information wherever stored and however generated.” This could expand the topic on information security, whereas a statement like
“computer-generated data only” would sharply narrow the topic scope.
The scope statement can also broaden or narrow the audience affected by the policy. For example, the statement, “the policy is intended for all employees,” pretty much takes in all of the people working for the enterprise, whereas, “that personnel with access to top-secret informa- tion” would limit the audience.
Responsibilities — Typically, this section of the policy identifies three or more specific roles and their responsibilities. The first role discussed is that of management and it is typically charged with implementing
30 Information Security Policies, Procedures, and Standards
and supporting the program. Employees are responsible for adhering to the policy and reporting any suspected problems to management.
The policy could also establish an office responsible for day-to-day administration of the policy.
Compliance — The policy will generally discuss two issues regarding compliance:
a. Who is responsible for ensuring compliance to the policy objectives.
Two specific groups are usually identified:
i. First-line supervision and its role in monitoring employee activ- ities
ii. The internal audit staff and its responsibility to conduct formal reviews
b. What happens when the policy is violated. When developing and implementing the policy, keep in mind that violations of the policy may be unintentional. The violation could be a result of lack of training and awareness. Therefore, it will be necessary to establish a review process for each violation case-by-case, as opposed to creating mandatory sanctions. Allow management some leeway when reviewing problems.
3.6.2 Topic-Specific Policy
In each section of the procedure document, the material begins with the policy statement of the organization. Unlike the program policy, the topic-specific policy narrows the focus to one issue at a time. Hence, we discuss creating a procedure document to support the policy statement. It will be in this document or, in some cases, in stand-alone policies where this approach will be used.
The basic components of a topic-specific policy include the following:
Thesis statement — To establish a policy on a specific topic, the writer must interview management and determine the relevant issues to be addressed. As in the Intent section of the program policy, the goals and objectives of the policy should be identified.
Relevance— The topic-specific policy also needs to establish to whom the policy applies. In addition to whom, the policy will want to clarify where, how, and when the policy is applicable. Is the policy only enforced when employees are in the work-site campus or will it extend to off-site activities?
Responsibilities — The establishment of roles and responsibilities is usually included in the topic-specific policy. When responsibilities are documented in a policy or procedure, it is always best to identify the position or job title rather than an individual by name. Job functions are usually more permanent than people.
Compliance — Here it may be appropriate to describe in some detail the behavior that is unacceptable and the consequences of that behavior.
The responsibility for monitoring compliance should also be identified.
Policy Development 31 Additional information — For a topic-specific policy, a list that iden- tifies individuals (by job title) and departments that the user can contact for additional information should be made available. Where to obtain copies of associated procedures should also be included.
3.6.3 Application-Specific Policy
Program-level and topic-specific policy both address policy from a broad level; they usually encompass the entire enterprise. The application-specific policy focuses on one specific system or application. As the construction of security architecture for an organization takes shape, the final element will be the translation of program and topic-specific policies to the application and system levels.
Many security issue decisions apply only at the application or system level.
Some examples include:
Who has the authority to read or modify application data?
Under what circumstances can data be read or modified?
How is remote access to be controlled?
To develop a comprehensive set of system security policies, use a process that determines security rules (policy) based on business and mission objectives.
Define the business objectives; then establish which security tools will support those objectives.
Establish the rules for operating the application or system. Determine who has access to what resources and when.
Determine if automated security tools can help administer the policy.