Appendix A: Ad-Hoc Risk Assessments

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

The Microsoft security risk management process describes the Assessing Risk phase as a scheduled activity within the larger risk management program. The Assessing Risk phase defines the steps to identify and prioritize risk scenarios known to the organization. The result is a prioritized list of risks at both a summary level and a detail level. The scheduled risk assessment also provides the input to the remaining phases of the risk management program. While the scheduled risk assessment delivers great value, risks to the enterprise change and evolve continually as a normal part of business. Therefore, the Security Risk Management Team needs a defined process to identify and analyze risks regardless of the phase of the risk management cycle. Waiting to analyze new risks until the next scheduled round of risk assessment is not a sensible practice.  

Immediate needs to understand risk may occur at any time. For example it may become apparent that there is a lack of consensus around the degree of risk surrounding a potential, or not well understood, threat. When this happens, different stakeholders may offer contradictory opinions and mitigation solutions. The Security Risk Management Team needs to document a position about the risk and help drive the decision support process, similar to the formal risk management program. It is likely that the Security Risk Management Team will be asked to create functional requirements for a given scenario that cannot and should not be derived without understanding all of the risk elements. This signals that an immediate, ad-hoc risk assessment is required. Be cautious of requests for risk assessments that attempt to misuse the risk assessment process as a means of justifying preconceived solutions or deployments. The risk assessment should result in an unbiased statement about the actual risks associated with a given issue.

In the Microsoft security risk management process, multiple risk scenarios were assessed and then prioritized. In the ad-hoc risk assessment, risks are analyzed on a case-by-case basis. An ad-hoc risk assessment focuses on a single risk issue, for example, "What are the risks associated with providing business guests wireless network access?" or "What risks are incurred by permitting mobile devices to connect to enterprise resources?" The ad-hoc risk assessment uses the methodology discussed in the process; however, prioritizing the risk and solution against other enterprise risks is not mandatory. A formal prioritization may only be necessary if the mitigation solution is costly. Often a comparison to similar risks provides sufficient perspective for the ad-hoc risk assessment to be prioritized. Of course, the ad-hoc results will be incorporated into the formal process as appropriate.

The risk discussion template included in the Tools section of this guidance can also be used for ad-hoc risk assessments. However, it is possible that data gathering may simply require research rather than a meeting with stakeholders. The Security Risk Management Team still needs to answer the key questions in the template, but the team itself may be the source of those answers. For example, if the team is trying to understand the risks associated with mobile devices, investigating the rate of device loss may be required information. This information may also be discovered by external research or through other IT teams responsible for running the service area.

The ad-hoc risk assessment can be communicated in a document structured with the following sections:

• Executive Summary. This summary should be an encapsulation of the entire assessment and should be able to be extracted from the risk assessment as a stand alone document.
• List of assumptions relating the scope and objectives of the ad-hoc risk assessment.
• A description of the asset being protected and its value to the business.
• A well-formed risk statement as described in the Microsoft security risk management process, addressing the following questions:
  • What do you want to avoid happening to the asset?
  • How might loss or exposure occur?
  • What is the extent of potential exposure to the asset?
  • What is being done today to minimize the probability of the risk occurring or minimize the impact if protective measures fail?
  • What is the overall risk? Include a statement such as "The probability is high that the attack would successfully compromise the integrity of medium-impact-value digital assets, representing high risk to the organization."
  • What are some actions that could possibly reduce the probability in the future?
  • What is the overall risk if the potential controls are implemented?

A single risk assessment may contain multiple threat scenarios. In the example of a wireless guest access solution, one scenario may be the risk of one guest attacking another guest; a second scenario may be an external attack on one of the guests; a third scenario could be a guest misusing the access to attack a target over the Internet. You should develop a risk statement for all applicable scenarios.

When the risks are understood, it may be sufficient to simply communicate them. It is also possible that the desired outcome is a statement of functional requirements from the Security Risk Management Team. If functional requirements are generated, they should be mapped to the specific risks that they address. A risk assessment document with functional security requirements is an effective tool to help the business understand risk and decide on the best mitigation solution.