Information Security Policy Revision Project

The balance of this chapter on information security policy projects assumes that information security policies are being rearchitected or created from scratch. In fact, most information security policy

projects do involve rearchitecting the policy framework or start-ing from scratch so a complete project plan discussion is generally applicable. Even when initially seeking to simply revise an existing information security policy set, many projects end up rearchitecting the policy set because it is easier. There are several reasons why an information security policy project may be easier to rearchitect than to revise:

• Old policy set. Information security policy sets are typically designed to be revised on an annual basis. Those sets that fail to have routine maintenance are typically so far behind changes in technology, the organizational needs, and regulations that a simple revision is no longer the easy route. Generally, a set of information security policies that have not been revised for 3 or more years should be rewritten from scratch.

• Lack of framework. No matter how often an information secu-rity policy set is maintained and expanded, if it was built on an as-needed basis or otherwise built without regard to a clear structure and framework, then attempted revisions will soon become too complex. When attempting to expand an information security policy set that is created without a clear framework, it is not clear where additional policy statements belong. Lacking a clear place for the proposed new statements, organizations typically will simply create another policy title to house a small set of policy statements. This results in the

“yet another policy” syndrome where users become so weary of the myriad of information security policies and keeping track of what is required that they simply give up on attempt-ing to understand the rules of the organization.

• Too many policies already. Generally, organizations with 50 or more information security policies have been suffering from this syndrome for a while. It would be best to rearchitect the whole mess and provide a clear and consistent information security policy set.

However, occasionally, an information security policy project may only seek to revise or even add to an existing well-organized informa-tion security policy set. In this case, the informainforma-tion security project is one of revision and not rearchitecting, so the process is much simpler

to discuss. There are four general reasons to revise an existing infor-mation security policy. Each of these is discussed below:

• Audit findings. When revising the information security policy set to address specific audit findings, the findings themselves are the driver of the project. If the audit findings indicate that the information security policies are nonexistent, out of date, or do not provide the details necessary to address informa-tion security requirements, then this is not a revision project but a rearchitect (or creation) project. However, if the audit findings are specific, simply track each finding to a missing, ambiguous, or incorrect policy statement and revise.

• Policy currency review. For information security policies that are being reviewed (within a few years) of the last policy review, this type of project involves SMEs to identify cur-rent issues, new threats, and additional controls that may need to be required by the policy set. A well-organized infor-mation security policy set will allow the project to focus on specific information security policies instead of the entire set. For example, if an organization feels the need for a cur-rency review on its information security policy set due to the increased demand and use of consumer electronics in the workplace and at home utilizing organizational data, then a policy review may be limited to the Acceptable Use Policy, Media Protection Policy, and the System and Communication Protection Policy.

• Policy consistency review. As the set of information security policies grows and expands to include overlapping areas of concern, there is a threat of inconsistency within the policy set. This can happen when more than one information secu-rity policy addresses a specific secusecu-rity control. For example, the Acceptable Use Policy, the Email Policy, and the Security Awareness Training all provide the user with requirements or guidance on selecting a strong password. If each of these pol-icies (and training) provides specifics on password strength (e.g., number of characters, selection of upper and lower case, and inclusion of a special character), then there is a danger that each may require (or suggest) something different. Such

an inconsistency in a policy set leads to users dismissing poli-cies and a degraded security posture.

A policy consistency review is best performed using a tech-nique known as an expected elements review. In an expected elements review, a list of security controls (e.g., expected ele-ments of the security policies) is used as a place holder to map the policy statement of each policy to a specific security con-trol. This approach was originally presented in The Security Risk Assessment Handbook (2006).

• Policy requirements review. In a project that involves reviewing existing information security policies for compliance with a set of requirements (e.g., industry regulations or standards, customer requirements, and organizational requirements), the set of requirements is first reviewed to identify the require-ments. Each requirement is then mapped to an existing policy statement in the information security policy set or the requirement is mapped to a target policy for inclusion. At the conclusion of the mapping, each existing information security policy will have an associated list of candidate requirements for inclusion. Working on the policies one after the other, the candidate requirements are then written into the exist-ing policies. Again, if the existexist-ing information security policy set is well organized and based on an information security policy framework, the identification of the appropriate policy for each candidate requirement will be obvious. If it is dif-ficult to perform this mapping, then a policy rearchitecting may be in order.