Team LiB   Previous Section   Next Section

14.3 Implementing Information Security Risk Management

The information security risk management framework provides guidance about the operations that organizations can implement to identify and address their information security risks. This section presents a common implementation of the framework. At the heart of this implementation is the information security risk evaluation.

Time Line Between Evaluations

Figure 14-5 illustrates a time line between two successive evaluations. Notice that after the organization completes Evaluation A, it has set its baseline with respect to its information security risks (i.e., the organization has taken its "snapshot" of its current risks). The organization must then address, or manage, the highest-priority risks that were identified during the evaluation, using these to galvanize mitigation and improvement activities. During the time between evaluations, people in the organization implement action plans designed to improve the organization's security posture. Assuming that those people effectively manage implementation of the action plans, the organization's security posture will indeed change.

Figure 14-5. Evaluation-Based Information Security Risk Management

graphics/14fig05.gif

Because the organization's security posture changes over time, it must periodically "reset" its baseline by conducting another evaluation. This creates another cycle of implementing and managing action plans from that evaluation, followed by another evaluation. The time between evaluations is generally predetermined (e.g., every one or two years). Therefore, it can take an organization a couple of years (or even longer) to complete each cycle.

Section 14.2.5 introduced the idea that an organization needs to monitor risk indicators for significant changes to its operational environment, indicating the existence of new risks or changes to existing risks. A "significant" change to an organization's operational environment would be one that alters the nature of the organization's information security risks and potentially affects its protection strategy and mitigation priorities. Because the organization's protection strategy and mitigation priorities may both be affected, the organization might decide to conduct another evaluation before its scheduled interval.

For example, a significant change to the organization's operational environment could be the acquisition of a former rival company. Such an acquisition might trigger an evaluation before the scheduled interval, setting a new baseline just before the acquisition. This step would establish an updated view of the organization's security posture going into the acquisition and could identify risks that must be addressed before the merger.

An organization's staff typically expends a lot of time and effort conducting an information security risk evaluation. Thus, an organization's management needs to be selective about which changes in its operational environment are significant enough to warrant another evaluation. The vast majority of changes do not meet this threshold.

Addressing Small Changes Between Evaluations

So how do organizations handle small changes between evaluations? Typically, they rely upon established security practices and procedures to address small changes. (Appendix C provides a catalog of security practices.) If there are no established procedures in place for a given situation, staff members are likely to handle it in an ad hoc fashion.

For example, consider how an organization handles a newly discovered vulnerability. New vulnerabilities are identified quite frequently and generally neither change the nature of the risks that the organization is managing nor affect the organization's mitigation priorities. The information technology staff could use established vulnerability management procedures to address the new vulnerability.

Likewise, if an organization acquires or develops a new business system, the nature of the risks to that system are likely to be similar to those affecting other systems and not affect the organization's mitigation priorities. The staff would apply existing security policies and procedures to designing, configuring, maintaining, and using the new system.

    Team LiB   Previous Section   Next Section