MCSE Boot Camp

Defining Threats and Vulnerabilities

Information on threats and vulnerabilities provides the technical evidence used to prioritize risks across an enterprise. Because many non – technical stakeholders may not be familiar with the detailed exposures affecting their business, the Risk Assessment Facilitator may need to provide examples to help start the discussion. This is one area in which prior research is valuable in terms of helping Business Owners discover and understand risk in their own environments. For reference, ISO 17799 defines threats as a cause of potential impact to the organization. NIST defines a threat as an event or entity with potential to harm the system. Impact resulting from a threat is commonly defined through concepts such as confidentiality, integrity, and availability. Referencing industry standards is especially useful when researching threats and vulnerabilities.

For purposes of the facilitated risk discussion it may be helpful to translate threats and vulnerabilities into familiar terms for non – technical stakeholders. For example, what are you trying to avoid, or what are you afraid will happen to the asset? Most impacts to business can be categorized in terms of confidentiality of the asset, integrity, or availability of the asset to conduct business. Try using this approach if stakeholders are having difficulty understanding the meaning of threats to organizational assets. A common example of a threat to the organization is a breach in the integrity of financial data. After you have articulated what you are trying to avoid, the next task is to determine how threats may occur in your organization.

A vulnerability is a weakness of an asset or group of assets that a threat may exploit. In simplified terms, vulnerabilities provide the mechanism or the how threats may occur. For additional reference, NIST defines vulnerability as a condition or weakness in (or absence of) security procedures, technical controls, physical controls, or other controls that could be exploited by a threat. As an example, a common vulnerability for hosts is the absence of security updates. Incorporating the threat and vulnerability examples previously given produces the following statement: "Unpatched hosts may lead to a breach of the integrity of financial information residing on those hosts."

A common pitfall in performing a risk assessment is a focus on technology vulnerabilities. Experience shows that the most significant vulnerabilities often occur due to lack of defined process or inadequate accountability for information security. Do not overlook the organizational and leadership aspects of security during the data gathering process. For example, expanding on the security update vulnerability above, the inability to enforce updates on managed systems may lead to a breach of the integrity of financial information residing on those systems. Clear accountability and enforcement of information security policies is often an organizational issue in many businesses.

Note   Throughout the data gathering process, you may recognize common groups of threats and vulnerabilities. Keep track of these groups to determine whether similar controls may reduce the probability of multiple risks.

Estimating Asset Exposure

After the Risk Assessment Facilitator leads the discussion through asset, threat, and vulnerability identification, the next task is to gather stakeholder estimates on the extent of the potential damage to the asset, regardless of the asset class definition. The extent of potential damage is defined as asset exposure.

As discussed previously, the Business Owner is responsible for both identifying assets and estimating potential loss to asset or the organization. As a review, the asset class, exposure, and the combination of threat and vulnerability define the overall impact to the organization. The impact is then combined with probability to complete the well-formed risk statement, as defined in Chapter 3.

The Risk Assessment Facilitator starts the discussion by using the following examples of qualitative categories of potential exposure for each threat and vulnerability combination associated with an asset:

• Competitive advantage
• Legal/regulatory
• Operational availability
• Market reputation

For each category, assist stakeholders in placing estimates within the following three groups:

• High exposure — Severe or complete loss of the asset
• Moderate exposure — Limited or moderate loss
• Low exposure — Minor or no loss

The prioritization section of this chapter provides guidance for adding detail to the exposure categories above. As with the task of quantifying assets, the Microsoft security risk management process recommends waiting until the risk prioritization step to further define exposure levels.

Note   If stakeholders have difficulty selecting exposure levels during the facilitated discussions, expand on the threat and vulnerability details to help communicate the potential level of damage or loss to the asset. Public examples of security breaches are another useful tool. If additional help is needed, introduce the more detailed levels of exposure as defined in the detailed prioritization section later in this chapter.

Estimating Probability of Threats

After stakeholders have provided estimates for the potential impact to organizational assets, the Risk Assessment Facilitator collects the stakeholders' opinions on the probability of the impacts occurring. This brings closure to the risk discussion and helps the stakeholder to understand the thought process of identifying security risks. Recall that the Information Security Group owns the eventual decision on estimating the probability of impacts occurring to the organization. This discussion can be viewed as a courtesy and a stakeholder goodwill builder.

Use the following guidelines to estimate probability for each threat and vulnerability identified in the discussion:

• High — Likely, one or more impacts expected within one year
• Medium — Probable, impact expected within two to three years
• Low — Not probable, impact not expected to occur within three years

Often this includes reviewing incidents that have occurred in the recent past. As appropriate, discuss these in order to help stakeholders understand the importance of security and the overall risk management process.

The Microsoft security risk management process associates a one-year timeframe to the high probability category because information security controls often take long periods to deploy. Selecting a probability within one year calls attention to the risk and encourages a mitigation decision within the next budgeting cycle. A high probability, combined with a high impact, forces a risk discussion across the stakeholders and the Security Risk Management Team. The Information Security Group must be aware of this responsibility when estimating the probability of impacts.

The next task is to gather stakeholder opinions on potential controls that may reduce the probability of identified impacts. Treat this discussion as a brainstorming session, and do not criticize or dismiss any ideas. Again, the primary purpose of this discussion is to demonstrate all components of risk to facilitate understanding. Actual mitigation selection occurs in the Conducting Decision Support phase. For each potential control identified, revisit the probability discussion to estimate the level of reduced occurrence using the same qualitative categories described previously. Point out to stakeholders that the concept of reducing the probability of risk is the primary variable for managing risk to an acceptable level.