Chapter 5: Conducting Decision Support

Published: October 15, 2004   |   Updated: March 15, 2006

Overview

Your organization should now have completed the Assessing Risk phase and developed a prioritized list of risks to its most valuable assets. Now you must address the most significant risks by determining appropriate actions to mitigate them. This phase is known as Conducting Decision Support. During the previous phase, the Security Risk Management Team identified assets, threats to those assets, vulnerabilities that those threats could exploit to potentially impact assets, and the controls already established to help protect the assets. The Security Risk Management Team then created a prioritized list of risks.

The decision support process includes a formal cost-benefit analysis with defined roles and responsibilities across organizational boundaries. The cost-benefit analysis provides a consistent, comprehensive structure for identifying, scoping, and selecting the most effective and cost efficient mitigation solution to reduce risk to an acceptable level. Similar to the risk assessment process, the cost-benefit analysis requires strict role definitions in order to operate effectively. Also, before conducting the cost-benefit analysis, the Security Risk Management Team must ensure that all stakeholders, including the Executive Sponsor, have acknowledged and agreed to the process.

During the Conducting Decision Support phase, the Security Risk Management Team must determine how to address the key risks in the most effective and cost efficient manner. The end result will be clear plans to control, accept, transfer, or avoid each of the top risks identified in the risk assessment process. The six steps of the Conducting Decision Support phase are:

1. Define functional requirements.
2. Select control solutions.
3. Review solutions against the requirements.
4. Estimate the degree of risk reduction that each control provides.
5. Estimate costs of each solution.
6. Select the risk mitigation strategy.

The following figure illustrates these six steps and how the Conducting Decision Support phase relates to the overall Microsoft security risk management process.

When comparing the value of a particular control to that of another, there are no simple formulas. The process can be challenging for a variety of reasons. For example, some controls impact multiple assets. The Security Risk Management Team must agree on how to compare the values of controls that impact different combinations of assets. Additionally, there are costs associated with controls that extend beyond the implementation of those controls. Related questions to consider include:

• How long will the control be effective?
• How many person hours per year will be required to monitor and maintain the control?
• How much inconvenience will the control impose on users?
• How much training will be needed for those responsible for implementing, monitoring, and maintaining the control?
• Is the cost of the control reasonable, relative to the value of the asset?

The remainder of this chapter will discuss answers to these questions.

You will attain success during the decision support process if you follow a clear path and if participants understand their respective roles at each step. The following diagram illustrates how the Security Risk Management Team conducts the decision support process. Mitigation Owners are responsible for proposing controls that will lessen the risk and then determining the cost of each control. For each proposed control, the Security Risk Management Team estimates the degree of risk reduction that the control can be expected to provide. With these pieces of information, the team can then conduct an effective cost-benefit analysis for the control to determine whether to recommend it for implementation. The Security Steering Committee then decides which controls will be implemented.

Clear role definitions reduce delays partly because only one group is accountable for the decision. However, experience shows that the overall effectiveness of the risk management program increases if each owner collaborates with the other stakeholders.

Note   Managing risk is a perpetual cycle, so maintaining a cooperative spirit increases stakeholder morale and may actually reduce risk to the business by enabling stakeholders to recognize the benefit of their contributions and act in a timely manner to reduce risk. Obviously, you should strive to maintain and promote this attitude throughout the entire risk management and decision support processes.

Required Input for the Conducting Decision Support Phase

There is only one input from the Assessing Risk phase that is required for the Conducting Decision Support phase: the prioritized list of risks that need to be mitigated. If you followed the procedures described in Chapter 4, "Assessing Risk," then you recorded this information in the Detail Risk worksheet in the SRMGTool3-Detailed Level Risk Prioritization.xls Microsoft® Excel® workbook located in the Tools and Templates folder that was created when you unpacked the archive containing this guide and the related files. You will continue to use this same worksheet during this phase of the process.

Participants in the Conducting Decision Support Phase

Participants in the Conducting Decision Support phase are similar to those in the Assessing Risk phase; in fact, most if not all of the team members will have participated in the earlier phase. The cost-benefit analysis informs the majority of tasks in the decision support process. Before you start the cost-benefit analysis, though, be sure that all stakeholders understand their respective roles.

The following table summarizes the roles and primary responsibilities for each group in the decision support process.

Table 5.1: Roles and Responsibilities in the Risk Management Program

The Security Risk Management Team should assign a security technologist to each identified risk. A single point-of-contact reduces the risk of the Security Risk Management Team producing inconsistent messages and provides a clean engagement model throughout the cost-benefit analysis.

Tools Provided for the Conducting Decision Support Phase

Information gathered in this phase of the process should be recorded in the Detail Risk worksheet in the SRMGTool3-Detailed Level Risk Prioritization.xls Excel workbook, which is located in the Tools and Templates folder that was created when you unpacked the archive containing this guide and the related files.

Required Outputs for the Decision Support Phase

During this phase of the Microsoft security risk management process, you will define and select several key pieces of information about each of the top risks identified during the Assessing Risk phase. The following table summarizes these key elements; they are described in detail in subsequent sections of this chapter.

Table 5.2: Required Outputs for Decision Support Phase

Considering the Decision Support Options

Organizations have two basic tactics in terms of the way that they handle risk: They can accept a risk, or they can implement controls to reduce the risk. If they choose to accept a risk, they can then decide to transfer the risk or a portion of it to a third party such as an insurance company or a managed services company. The following two sections examine these two approaches to risk—acceptance, or implementation of controls to facilitate risk reduction.

Note   Many security risk management practitioners believe that there is another option for handling each risk: avoidance. But it is important to keep in mind that when you choose to avoid a risk you decide that you will stop doing whatever activity presents the risk. With regard to security risk management, in order to avoid a risk organizations must stop using the information system that includes the risk. For example, if the risk is that "within a year, unpatched servers may become compromised via malware, which would lead to compromised integrity of financial data," the only way to avoid this risk is to stop using servers—which is probably not a realistic option. The Microsoft security risk management process assumes that organizations are only interested in examining assets that provide business value and will remain in service. Therefore, this guidance does not discuss avoidance as an option.

Accepting the Current Risk

The Security Steering Committee should choose to accept a current risk if it determines that there are no cost effective controls to productively reduce the risk. This does not mean that the organization cannot effectively address the risk by implementing one or more controls; instead, it means that the cost of implementing the control or controls, or the impact of those controls on the organization's ability to do business, is too high relative to the value of the asset needing protection. For example, consider the following scenario:

A Security Risk Management Team determines that one of the most important risks to the organization's key assets is the reliance on passwords for user authentication when logging onto the corporate network. The team identifies that deploying two-factor authentication technology such as smart cards would be the most effective way to reduce and ultimately eliminate the use of passwords for authentication. The Mitigation Owner then calculates the cost of smart card deployment throughout the organization and the impact on the organization's existing operating systems and applications. The cost of deployment is quite high but could be justified; however, the team finds that many of the organization's internally developed business applications rely on password-based authentication and rewriting or replacing these applications would be exceedingly expensive and would take several years. Ultimately, then, for the immediate future the team decides not to recommend to the Security Steering Committee the use of smart cards for all employees. But it may in fact come to realize that a compromise would work: Users of particularly powerful or sensitive accounts such as domain administrators and key executives could be required to authenticate with smart cards. The Security Steering Committee makes the final decision to follow the recommendation of the Security Risk Management Team: Smart cards will not be required for all employees.

A variation on risk acceptance is transferal of the risk to a third party. Insurance policies for IT assets are beginning to become available. Alternatively, organizations can contract other firms that specialize in managed security services; the outsourcer may assume some or all responsibility for protecting the organization's IT assets.

Implementing Controls to Reduce Risk

Controls, sometimes described as countermeasures or safeguards, are organizational, procedural, or technological means of managing risks. The Mitigation Owners, with support from the Security Risk Management Team, identify all possible controls; calculate the cost of implementing each control; determine the other costs related to the control, such as user inconvenience or ongoing maintenance cost of the control; and assess the degree of risk reduction possible with each control. All of this information allows the team to effectively conduct a cost-benefit analysis for each proposed control. The controls that most effectively reduce risk to key assets at a reasonable cost to the organization are the controls that the team will most enthusiastically recommend for implementation.

Keys to Success

Similar to the Assessing Risk phase, setting reasonable expectations is critical if the decision support phase is to be successful. Decision support requires significant contributions from different groups representing the entire business. If even one of these groups does not understand or actively participate in the process, the effectiveness of the entire program may be compromised. Be certain to clearly explain what will be expected from each participant during the Conducting Decision Support phase, including roles, responsibilities, and degree of participation.

Building Consensus

It is important that the entire Security Risk Management Team reaches decisions by consensus whenever possible; without it, dissenting members' comments may undermine recommendations after the team presents them to the Security Steering Committee. Even if the committee endorses the recommended controls, the underlying dissention may cause the follow-up control implementation projects to fail. For the entire risk management process to succeed, all team members should agree to and support the recommended controls.

Avoiding Filibusters

Because one of the goals of this phase is to create—through consensus—a list of controls, any stakeholder involved could slow or stop progress by imposing a filibuster. That is, anyone participating in the decision support phase could decide that he or she refuses to agree to recommend a particular control. Conversely, someone could try to impose his or her minority view on the majority if a particular control's recommendation is threatened. It is very important that the Risk Assessment Facilitator resolve filibuster situations when they arise. It is beyond the scope of this guidance to provide extensive advice on managing this type of challenge, but some effective tactics include determining the key reasons for the person's point of view and then working with the team to try to find effective alternatives or compromises that the entire team deems acceptable.

Identifying and Comparing Controls

This section explains how the Mitigation Owner will identify potential control solutions and determine the types of costs associated with implementing each proposed control, and how the Security Risk Management Team will estimate the level of risk reduction that each proposed control provides. The Mitigation Owners and Security Risk Management Team will present their findings and recommended solutions to the Security Steering Committee so that a final list of control solutions can be selected for implementation.

The following diagram is an excerpt from the Detail Risk worksheet in the Excel workbook used to perform the detailed risk assessment in the previous chapter. This worksheet, SRMGTool3-Detailed Level Risk Prioritization.xls, is included with this guide and is located in the Tools and Templates folder. The diagram shows all of the elements used during the cost-benefit analysis. Individual columns are described in the following steps.

Note   The worksheet focuses on reducing the probability of impact when determining the level of risk reduction. It assumes that the value of the asset does not change within the time period of the risk assessment. Typically, the exposure level (extent of damage to the asset) remains constant. Experience shows that exposure levels usually remain unchanged if the threat and vulnerability descriptions are specified at a sufficient level of detail.

Step One: Defining Functional Requirements

Functional security requirements are statements describing the controls necessary to mitigate risk. The term "functional" is significant: Controls should be expressed in terms of the desired functions as opposed to the stated technologies. Alternative technical solutions may be possible, and any resolution is acceptable if it meets the functional security requirement(s). The Security Risk Management Team is responsible for defining the functional requirements, the first deliverable in the cost-benefit analysis process. To properly identify potential controls, the Security Risk Management Team must define what the controls must accomplish in order to reduce risk to the business. Although the team retains ownership, collaboration with the mitigation solution owner is highly encouraged.

Functional requirements must be defined for each risk discussed in the decision support process; the deliverable produced is called "Functional Requirement Definitions." The definition and ownership of the functional requirement is very important to the cost-benefit process. The document defines what needs to occur to reduce the identified risk but does not specify how the risk should be reduced or define specific controls. This distinction gives the Security Risk Management Team responsibility in its area of expertise while also allowing the Mitigation Owner, who implements the mitigation solution, to own decisions related to running and supporting the business. Responses for each risk are documented in the column labeled "Functional Security Requirement" in SRMG3-Detailed Level Risk Prioritization.xls. Functional requirements should be reviewed at least once per year to determine whether they are still necessary or should be modified.

The work completed in the previous phase enables organizations to understand their risk positions and to rationally determine what controls should be implemented to reduce the most significant risks. The executive sponsor and business owners want to know what the Information Security Group believes the organization should do about each risk. The Information Security Group answers this by creating functional security requirements. For each risk, the Information Security Group composes a clear statement of what type of functionality or process needs to be introduced in order to mitigate the risk.

Woodgrove Example   Building on the Woodgrove Bank example used in the previous chapter, a useful functional requirement for the risk of theft of credentials off a managed local area network (LAN) client via an outdated configuration of antivirus signatures, host configurations, or outdated security updates:

The ability MUST exist to authenticate the identity of users through two or more factors when they log on to the local network.

An example of a requirement that is not functional is:

The solution MUST utilize smart cards for authenticating users.

The second statement is not functional because it describes the use of a specific technology. It is up to the Mitigation Owners to provide a list specific control solutions that meet the functional requirements; it is they who translate the functional requirements into technical control solutions and/or administrative controls (policy, standards, guidelines, and so on).

The functional requirement for the second risk examined during the detailed level risk prioritization step, the risk of theft of credentials off of remote mobile hosts as a result of an outdated security configuration:

The ability MUST exist to authenticate the identity of users through two or more factors when they log on to the network remotely.

Record the functional requirements for each risk in the Functional Security Requirements column in SRMGTool3-Detailed Level Risk Prioritization.xls.

Internet Engineering Task Force (IETF) Request for Comments (RFC) 2119, available at www.ietf.org/rfc/rfc2119.txt, provides guidance on key words and phrases to be used in requirements statements. These terms, which are often capitalized, are "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL." Microsoft recommends that you use these key phrases in your functional requirement statements by following the definitions provided in RFC 2119:

• MUST. This word, or the terms "REQUIRED" or "SHALL," means that the definition is an absolute requirement of the specification. For example, if the risk assessment identifies a high risk scenario, the word "MUST" is probably the best keyword descriptor for the requirement that addresses that scenario.
• MUST NOT. This phrase, or the phrase "SHALL NOT," means that the definition is an absolute prohibition of the specification.
• SHOULD. This word, or the adjective "RECOMMENDED," means that valid reasons may exist in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. For example, if the risk assessment identifies a low risk scenario, the word "SHOULD" may be the best keyword descriptor for the requirement that addresses that scenario.
• SHOULD NOT. This phrase, or the phrase "NOT RECOMMENDED," means that valid reasons may exist in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
• MAY. This word, or the adjective "OPTIONAL," means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product, while another vendor may omit the same item. An implementation that does not include a particular option MUST be prepared to interoperate with another implementation that does include the option, although perhaps with reduced functionality. In the same vein, an implementation that does include a particular option MUST be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature that the option provides).

After functional requirements have been defined and documented for each risk, you are ready to move on to the next step of the Conducting Decision Support phase.

Step Two: Identifying Control Solutions

The next step in this phase is for the Mitigation Owners to come up with a list of potential new controls for each risk that address the functional requirements of that risk. For many organizations, members of the Information Security Group will be able to assist by identifying a range of potential controls for each risk that was identified and characterized during the preceding phase. Organizations that do not have sufficient expertise in-house for this purpose can consider supplementing the Mitigation Owners with consultants.

The process of identifying potential controls may seem daunting, especially if few or none of the Mitigation Owners have done it before. There are two approaches that can help teams to think of new ideas; many organizations find it most effective to use both. The first is an informal brainstorming approach; the second is more organized and is based on how controls can be classified and organized. The Security Risk Management team should use a hybrid of these two approaches.

In the brainstorming approach, for each risk the Risk Assessment Facilitator poses the following series of questions to the team. The Risk Assessment Note Taker documents all responses in column labeled "Proposed Control" in the Detailed worksheet of SRMGTool3-Detailed Level Risk Prioritization.xls. This continues until all of the top risks have been examined and the team moves on to determining costs associated with each control.

• What steps could the organization undertake to resist or prevent the risk's occurrence? For example, implement multi-factor authentication to lower the risk of password compromise or deploy an automated patch management infrastructure to lower the risk of systems becoming compromised by malicious mobile code.
• What could the organization do to recover from the risk once it has taken place? For example, establish, fund, and train a robust incident response team or implement and test backup and restore processes for all computers running a server-class operating system. Going even further, an organization can establish redundant computing resources at remote locations that it can put into service should disaster strike at the primary site.
• What measures can the organization take to detect the risk occurring? For example, install a network-based intrusion detection system at the network perimeter and at key locations within the internal network, or install a distributed, host-based intrusion detection system on all computers in the organization.
• How can the control be audited and monitored to ensure that it continues to be in place? For example, install and diligently observe the appropriate management tools from the product's vendor.
• How can the organization validate the effectiveness of the control? For example, have an expert familiar with the vulnerability attempt to bypass the control.
• Are there any other actions that could be taken to manage it? For example: transfer risk by purchasing insurance to indemnify against losses relating to it.

The second method for identifying potential new controls organizes the controls into three broad categories: organizational, operational, and technological. These are further subdivided into controls that provide prevention, detection recovery, and management. Preventative controls are implemented to keep a risk from being realized, for example, they stop breaches before they transpire. Detection and recovery controls help an organization to determine when a security event has occurred and to resume normal operations afterwards. Management controls do not necessarily provide protection in and of themselves, but they are necessary for implementing other controls. These categories are discussed in more detail below.

Organizational Controls

Organizational controls are procedures and processes that define how people in the organization should perform their duties.

Preventative controls in this category include:

• Clear roles and responsibilities. These must be clearly defined and documented so that management and staff clearly understand who is responsible for ensuring that an appropriate level of security is implemented for the most important IT assets.
• Separation of duties and least privileges. When properly implemented, these ensure that people have only enough access to IT systems to effectively perform their job duties and no more.
• Documented security plans and procedures. These are developed to explain how controls have been implemented and how they are to be maintained.
• Security training and ongoing awareness campaigns. This is necessary for all members of the organization so that users and members of the IT team understand their responsibilities and how to properly utilize the computing resources while protecting the organization's data.
• Systems and processes for provisioning and de-provisioning users. These controls are necessary so that new members of the organization are able to become productive quickly, while leaving personnel lose access immediately upon departure. Processes for provisioning should also include employee transfers from groups within the company where privileges and access change from one level to another. For example, consider government personnel changing jobs and security classifications form Secret to Top Secret, or vice versa.
• Established processes for granting access to contractors, vendors, partners, and customers. This is often a variation on user provisioning, mentioned previously, but in many cases it is very distinct. Sharing some data with one group of external users while sharing a different collection of data with a different group can be challenging. Legal and regulatory requirements often impact the choices, for example when health or financial data is involved.

Detection controls in this category include:

• Performing continuing risk management programs to assess and control risks to the organization's key assets.
• Executing recurrent reviews of controls to verify the controls' efficacy.
• Periodic undertaking of system audits to ensure that systems have not been compromised or misconfigured.
• Performing background investigations of prospective candidates for employment; You should contemplate implementing additional background investigations for employees when they are being considered for promotions to positions with a significantly higher level of access to the organization's IT assets.
• Establishing a rotation of duties, which is an effective way to uncover nefarious activities by members of the IT team or users with access to sensitive information.

Management controls in this category include:

• Incident response planning, which provides an organization with the ability to quickly react to and recover from security violations while minimizing their impact and preventing the spread of the incident to other systems.
• Business continuity planning, which enables an organization to recover from catastrophic events that impact a large fraction of the IT infrastructure.

Operational Controls

Operational controls define how people in the organization should handle data, software and hardware. They also include environmental and physical protections as described below.

Preventative controls in this category include:

• Protection of computing facilities by physical means such as guards, electronic badges and locks, biometric locks, and fences.
• Physical protection for end-user systems, including devices such as mobile computer locks and alarms and encryption of files stored on mobile devices.
• Emergency backup power, which can save sensitive electrical systems from harm during power brownouts and blackouts; they can also ensure that applications and operating systems are shut down gracefully manner to preserve data and transactions.
• Fire protection systems such as automated fire suppression systems and fire extinguishers, which are essential tools for guarding the organization's key assets.
• Temperature and humidity control systems that extend the life of sensitive electrical equipment and help to protect the data stored on them.
• Media access control and disposal procedures to ensure that only authorized personnel have access to sensitive information and that media used for storing such data is rendered unreadable by degaussing or other methods before disposal.
• Backup systems and provisions for offsite backup storage to facilitate the restoration of lost or corrupted data. In the event of a catastrophic incident, backup media stored offsite makes it possible to store critical business data on replacement systems.

Detection and recovery controls in this category include:

• Physical security, which shields the organization from attackers attempting to gain access to its premises; examples include sensors, alarms, cameras, and motion detectors.
• Environmental security, which safeguards the organization from environmental threats such as floods and fires; examples include smoke and fire detectors, alarms, sensors, and flood detectors.

Technological Controls

Technological controls vary considerably in complexity. They include system architecture design, engineering, hardware, software, and firmware. They are all of the technological components used to build an organization's information systems.

Preventative controls in this category include:

• Authentication. The process of validating the credentials of a person, computer, process, or device. Authentication requires that the person, process, or device making the request provide a credential that proves it is what or who it says it is. Common forms of credentials are digital signatures, smart cards, biometric data, and a combination of user names and passwords.
• Authorization. The process of granting a person, computer process, or device access to certain information, services, or functionality. Authorization is derived from the identity of the person, computer process, or device requesting access, which is verified through authentication.
• Nonrepudiation. The technique used to ensure that someone performing an action on a computer cannot falsely deny that he or she performed that action. Nonrepudiation provides undeniable proof that a user took a specific action such as transferring money, authorizing a purchase, or sending a message.
• Access control. The mechanism for limiting access to certain information based on a user's identity and membership in various predefined groups. Access control can be mandatory, discretionary, or role-based.
• Protected communications. These controls use encryption to protect the integrity and confidentiality of information transmitted over networks.

Detection and recovery controls in this category include:

• Audit systems. Make it possible to monitor and track system behavior that deviates from expected norms. They are a fundamental tool for detecting, understanding, and recovering from security breaches.
• Antivirus programs. Designed to detect and respond to malicious software, such as viruses and worms. Responses may include blocking user access to infected files, cleaning infected files or systems, or informing the user that an infected program was detected.
• System integrity tools. Make it possible for IT staff to determine whether unauthorized changes have been made to a system. For example, some system integrity tools calculate a checksum for all files present on the system's storage volumes and store the information in a database on a separate computer. Comparisons between a system's current state and its previously-known good configuration can be completed in a reliable and automated fashion with such a tool.

Management controls in this category include:

• Security administration tools included with many computer operating systems and business applications as well as security oriented hardware and software products. These tools are needed in order to effectively maintain, support, and troubleshoot security features in all of these products.
• Cryptography, which is the foundation for many other security controls. The secure creation, storage, and distribution of cryptographic keys make possible such technologies as virtual private networks (VPNs), secure user authentication, and encryption of data on various types of storage media.
• Identification, which supplies the ability to identify unique users and processes. With this capability, systems can include features such as accountability, discretionary access control, role-based access control, and mandatory access control.
• Protections inherent in the system, which are features designed into the system to provide protection of information processed or stored on that system. Safely reusing objects, supporting no-execute (NX) memory, and process separation all demonstrate system protection features.

When you consider control solutions you may also find it helpful to review the "Organizing the Control Solutions" section in Chapter 6, "Implementing Controls and Measuring Program Effectiveness." This section includes links to a variety of prescriptive guidance that was written to help organizations increase the security of their information systems.

Woodgrove Example   The first risk, the risk that financial adviser user credentials could be stolen while logging on to the LAN, might be addressed by requiring users to authenticate using smart cards when connecting locally to the corporate network.

The second risk, the risk that financial adviser user credentials could be stolen while logging on to the network remotely, might be addressed by requiring all users to authenticate using smart cards when connecting remotely to the corporate network. Record each of the proposed controls for each risk in the "Proposed Control" column in SRMGTool3-Detailed Level Risk Prioritization.xls.

Step Three: Reviewing the Solution Against Requirements

The Security Risk Management Team must approve the control solution in order to ensure that the control meets the defined functional requirements. Another benefit of collaborating throughout the cost-benefit processes is the ability to anticipate the checks and balances inherent to the process, for example, if the Mitigation Owner is included in the security requirements definition, the solution will usually fit the requirements. Controls that do not meet the functional requirements for a specific risk are removed from the Detail Risk worksheet.

Woodgrove Example   The Security Risk Management Team compared the use of smart cards for user authentication to determine whether its implementation would meet the functional requirements. In this case, smart cards would indeed meet the functional requirements of both the first and second risk used in this ongoing example. Mark each of the proposed controls that are rejected by distinctively formatting them in SRMGTool3-Detailed Level Risk Prioritization.xls.

Step Four: Estimating Risk Reduction

After the Security Risk Management Team approves the potential mitigation, it must recalculate the overall risk reduction to the business. The amount of risk reduction will be compared to the cost of the mitigation solution. This is the first step in which the quantitative dollar amount may provide value in the cost-benefit analysis. Experience shows that risk reduction is usually estimated by extending the probability of the impact occurring to the business. Recall that each probability rating of high, medium, or low has a predicted time frame when the impact is likely to occur.

Extending the estimate of when the impact may occur from one year to greater than three years provides significant value to the Security Risk Management Team and Security Steering Committee. Although the financial loss estimate may not decrease, the loss is less likely to occur in the near future. It is important to keep in mind that the goal is not to reduce the impact to zero but to define an acceptable level of risk to the business.

Another benefit of reducing the risk in the near term relates to the common trend of technical control costs decreasing over time and increasing in effectiveness. For example, an improvement in the current patch management strategy may significantly reduce the probability of host compromises today. However, the cost of deploying patches and security updates may decrease as new guidance and tools become available to effectively manage these operations. The reduction of costs using two-factor authentication provides another example of this trend.

When determining the relative degree of risk reduction for a control, be sure to consider all the ways in which the control may impact risk. Some questions to consider include:

• Does the control prevent a specific attack or a collection of attacks?
• Does it minimize the risk of a certain class of attacks?
• Does the control recognize an exploit while it is occurring?
• If it does recognize an exploit, is it then able to resist or track the attack?
• Does the control help to recover assets that have suffered an attack?
• What other benefits does it provide?
• What is the total cost of the control relative to the value of the asset?

These questions can become complex when a particular control affects multiple vulnerabilities and assets. Ultimately, the goal of this step is to make estimates for how much each control lowers the levels of risk. Record the new values for Impact Rating, Probability Rating, and Risk Rating in the columns labeled "Impact Rating with New Control," "Probability Rating with New Control," and "New Risk Rating" in SRMGTool3-Detailed Level Risk Prioritization.xls for each risk.

Woodgrove Example   Regarding the first risk, the risk of financial advisers having their passwords compromised while using LAN clients, the Security Risk Management Team might conclude that the impact rating after implementing smart cards for local authentication would be 8, the probability rating would drop to 1, and the new risk rating would therefore be 8. For the second risk, the risk of financial advisers having their passwords compromised when accessing the network remotely, the Security Risk Management Team would find similar values. Record the new impact, probability, and risk ratings for each proposed control in the "Impact Rating with New Control," "Probability Rating with New Control," and "New Risk Rating" columns in the Detailed Risk worksheet of SRMGTool3-Detailed Level Risk Prioritization.xls.

Step Five: Estimating Solution Cost

The next task in this phase is for the Mitigation Owner to estimate the relative cost of each proposed control. The IT Engineering team should be able to determine how to implement each control and to provide reasonably accurate estimates on how much acquiring, implementing, and maintaining each one would cost. Because the Microsoft security risk management process entails a hybrid risk management process, precise costs do not need to be calculated; estimates should suffice. During the cost-benefit analysis, the relative values and costs of each control will be compared rather than absolute financial figures. When the team creates these estimates, it should consider all of the following direct and indirect expenditures that might be associated with a control. Record the costs for each control in the column labeled "Cost of Control Description" in SRMGTool3-Detailed Level Risk Prioritization.xls.

Acquisition Costs

These costs comprise the software, hardware, or services related to a proposed new control. Some controls may have no acquisition costs — for example, implementing a new control may merely involve enabling a previously unused feature on a piece of network hardware that the organization is already using. Other controls may require the purchase of new technologies such as distributed firewall software or dedicated firewall hardware with application layer filtering capabilities. Some controls may not require the purchase of anything but rather the hiring of a third-party organization. For example, an organization might hire another firm to provide it with a block list of known spammers that is updated daily so that it can tie the list into its spam filters already installed on mail servers in the organization. There may be other controls that the organization chooses to develop itself; all of the costs relating to designing, developing, and testing the controls would be part of an organization's acquisition costs.

Implementation Costs

These expenditures relate to staff or consultants who will install and configure the proposed new control. Some controls may require a large team to specify, design, test, and deploy properly. Alternatively, a knowledgeable systems administrator could disable a few unused system services on all desktop and mobile computers in only a few minutes if the organization already has enterprise management tools deployed.

Ongoing Costs

These costs relate to continuing activities associated with the new control, such as management, monitoring, and maintenance. They may seem particularly hard to estimate, so try to think of them in terms how many people will need to be involved and how much time each week (or month or year) will need to be spent on these tasks. Consider a robust, distributed network-based intrusion detection system for a large corporation with offices on four continents. Such a system would require people to monitor the system 24 hours a day, every day, and those people would have to be able to interpret and effectively respond to alerts. It might require eight or ten or even more full-time employees for the organization to fully realize the potential of this complex control.

Communication Costs

This expenditure is related to communicating new policies or procedures to users. For an organization with a few hundred employees that is installing electronic locks for its server room, a few e-mails sent to the IT staff and senior managers might be sufficient. But any organization deploying smart cards, for example, will require a lot of communication before, during, and after the distribution of smart cards and readers, because users will have to learn a whole new way of logging on to their computers and will undoubtedly encounter a wide range of new or unexpected situations.

Training Costs for IT Staff

These costs are associated with the IT staff that would need to implement, manage, monitor, and maintain the new control. Consider the previous example of an organization that has decided to deploy smart cards. Various teams within the IT organization will have different responsibilities and, therefore, require different types of training. Help desk staff will have to know how to help end users overcome common problems such as damaged cards or readers and forgotten PINs. Desktop support staff will have to know how to install, troubleshoot, diagnose, and replace the smart card readers. A team within the IT organization, one within the human resources department, or perhaps one within the organization's physical security department will have to be responsible for provisioning new and replacement cards and retrieving cards from departing employees.

Training Costs for Users

This expenditure is related to users who would have to incorporate new behavior in order to work with the new control. In the smart card scenario referenced previously, all users will have to understand how to use the smart cards and readers, and they will also have to understand how to properly care for the cards, because most designs are more sensitive to physical extremes than credit cards or bank cards.

Costs to Productivity and Convenience

These expenditures are associated with users whose work would be impacted by the new control. In the smart card scenario, you might assume that things would be easier for an organization after the early weeks and months of deploying the cards and readers and helping users overcome their initial problems. But for most organizations, that would not be the case. Many will find that their existing applications are not compatible with smart cards, for example. In some cases this may not matter, but what about the tools that the human resources department uses to manage confidential employee information? Or the customer relationship management software used throughout the organization to track important data for all customers?

If critical business applications like these are not compatible with smart cards and are configured to require user authentication, the organization may be faced with some difficult choices. It could upgrade the software, which would require even more costs in terms of new licenses, deployment, and training. Or it could disable the authentication features, but that would lower security significantly. It could, alternatively, require users to enter user names and passwords when accessing these applications, but then users would once again have to remember passwords, undermining one of the key benefits of smart cards.

Costs for Auditing and Verifying Effectiveness

An organization would incur these expenditures after implementing the proposed new control. Examples of questions that you can ask to further define these costs include:

• How will it ensure that the control is actually doing what it was supposed to do?
• Will some members of the IT organization perform penetration testing?
• Will they try running samples of malicious code against the asset that the control is supposed to protect?
• After the effectiveness of the control has been validated, how will the organization verify that the control is still in place, on an ongoing basis?

The organization must be able to prove that nobody has accidentally or maliciously modified or disable the control, and it must determine who will be charged with the verification of this. For extremely sensitive assets it may be necessary to have more than one person validate the results.

Woodgrove Example   In Tables 5.3 and 5.4, the Mitigation Owners determined costs for the risks. Record the cost estimates for each proposed control in the "Cost of Control Description" column in SRMGTool3_Detailed Level Risk Prioritization.xls.

Table 5.3: Costs for Implementing Smart Cards for VPN and Admin Access

Table 5.4: Costs for Implementing Smart Cards for Local Access

Step Six: Selecting the Risk Mitigation Solution

The last step in the cost-benefit analysis is to compare the level of risk after the mitigation solution to the cost of the mitigation solution itself. Both the risk and the cost contain subjective values that are difficult to measure in exact financial terms. Use the quantitative values as a sensible test of comparison. Avoid the temptation to dismiss the intangible costs of the risk occurring. Ask the asset owner what would happen if the risk became realized. Ask the owner to document his or her response to help evaluate the importance of the mitigation solution. This tactic can be just as persuasive as an arithmetic comparison of quantitative values.

A common pitfall in the cost-benefit analysis is to focus on the amount of risk reduction versus the amount of risk after the mitigation solution. This is often referred to as residual risk. As a simple example using quantitative terms, if the risk is represented as $1000 today, and the proposed control reduces the risk by $400, the business owner must accept the $600 after-mitigation-solution risk. Even if the mitigation solution is less than $400, there will still be a $600 residual risk.

Woodgrove Example   It is likely that the bank would choose to implement smart cards only for remote access, because the cost for requiring them for all user authentications is quite high. Document which of the recommended security solutions are selected for implementation before moving on to the next phase of the Microsoft security risk management process.

Summary

During the Conducting Decision Support phase, the Security Risk Management Team gathers several key pieces of additional information about each of the top risks identified during the Assessing Risk phase. For each risk, it determines whether the organization should choose to control, accept, transfer, or avoid it. The team then defines functional requirements for each risk. Next, the Mitigation Owners, coordinating with the Security Risk Management Team, create a list of potential control solutions. The team then estimates the degree of risk reduction that each control solution provides and the costs associated with each. Finally, the Security Steering Committee selects which control solutions the Mitigation Owners should implement in the next phase, Implementing Controls, which the following chapter describes.