Security Risk Management Guide

This chapter is the first in this guide to provide a full summary of the Microsoft security risk management process. After this overview, the chapter discusses several topics that will assist readers as they implement the process. These topics help provide a solid foundation for a successful security risk management program and include:

It is also important to note that risk management is only one part of a larger governance program for corporate leadership to monitor the business and make informed decisions. While governance programs vary widely, all programs require a structured security risk management component to prioritize and mitigate security risks. The Microsoft security risk management process concepts may be applied to any governance program to help define and manage risks to acceptable levels.

On This Page

	The Four Phases of the Microsoft Security Risk Management Process
	Summary

The Four Phases of the Microsoft Security Risk Management Process

Chapter 2, "Survey of Risk Management Practices," introduced the Microsoft security risk management process and defined risk management as an ongoing process with four primary phases:

This four-part risk management cycle summarizes the Microsoft security risk management process and is also used to organize content throughout this guide.

Before defining specific practices within the Microsoft security risk management process, however, it is important to understand the larger risk management process and its components. Each phase of the cycle contains multiple, detailed steps. The following list outlines each step to help you understand the importance of each one in the guide as a whole:

The following figure illustrates each phase and its associated steps.

Figure 3.1: The Microsoft Security Risk Management Process
See full-sized image

Subsequent chapters in this guide describe, in sequence, each phase in the Microsoft security risk management process. There are several preliminary things to consider, however, before beginning your execution of this process.

Level of Effort

If your organization is relatively new to risk management, it may be helpful to consider which steps in the Microsoft security risk management process typically require the most effort from the Security Risk Management Team. The following figure, based on risk management activities conducted within Microsoft IT, shows relative degrees of effort throughout the process. This perspective may be helpful when describing the overall process and time commitment to organizations that are new to risk management. The relative levels of effort may also be helpful as a guide to avoid spending too much time in one point of the overall process. To summarize the level of effort throughout the process, the figure demonstrates a moderate level of effort to gather data, a lower level for summary analysis, followed by high levels of effort to build detailed lists of risks and conduct the decision support process. For an additional view of tasks and associated effort, refer to the sample project schedule in the Tools folder, SRMGTool4-Sample Project Schedule.xls. The remaining chapters in this guide further describe each step shown below.

Figure 3.2: Relative Level of Effort During the Microsoft Security Risk Management Process
See full-sized image

Laying the Foundation for the Microsoft Security Risk Management Process

Before beginning a security risk management effort, it is important to have a solid understanding of the foundational, prerequisite knowledge and tasks of the Microsoft security risk management process, which include:

Risk Management vs. Risk Assessment

As Chapter 2 discussed, the terms risk management and risk assessment are not interchangeable. The Microsoft security risk management process defines risk management as the overall process to manage risk to an acceptable level across the business. Risk assessment is defined as the process to identify and prioritize risks to the business. As outlined in the previous diagram, risk management is comprised of four primary phases: Assessing Risk, Conducting Decision Support, Implementing Controls, and Measuring Program Effectiveness. Risk assessment, in the context of the Microsoft security risk management process, refers only to the Assessing Risk phase within the larger risk management cycle.

Another distinction between risk management and risk assessment is the frequency of initiation of each process. Risk management is defined as an ongoing cycle, but it is typically re-started at regular intervals to refresh the data in each stage of the management process. The risk management process is normally aligned with an organization's fiscal accounting cycle to align budget requests for controls with normal business processes. An annual interval is most common for the risk management process to align new control solutions with annual budgeting cycles.

Although risk assessment is a required, discrete phase of the risk management process, the Information Security Group may conduct multiple risk assessments independent of the current risk management phase or budgeting cycle. The Information Security Group may initiate them anytime a potentially security-related change occurs within the business, such as the introduction of new business practices, or discovered vulnerabilities, changes to the infrastructure. These frequent risk assessments are often referred to as ad-hoc risk assessments, or limited scope risk assessments, and should be viewed as complementary to the formal risk management process. Ad-hoc assessments usually focus on one area of risk within the business and do not require the same amount of resources as the risk management process as a whole. Appendix A, "Ad-Hoc Assessments," outlines and provides an example template of an ad-hoc risk assessment.

Table 3.1: Risk Management vs. Risk Assessment

Communicating Risk

Various people involved in the risk management process often define the term risk differently. In order to ensure consistency across all stages of the risk management cycle, the Microsoft security risk management process requires that everyone involved understand and agree upon a single definition of the term risk. As defined in Chapter 1, "Introduction to the Security Risk Management Guide," risk is the probability of an impact occurring to the business. This definition requires the inclusion of both an impact statement and a prediction of when the impact may occur, or, in other words, probability of impact. When both elements of risk (probability and impact) are included in a risk statement, the process refers to this as a well-formed risk statement. Use the term to help ensure consistent understanding of the compound nature of risk. The following diagram depicts risk at this most basic level.

Figure 3.3: Well-Formed Risk Statement
See full-sized image

It is important that everyone involved in the risk management process understand the complexity within each element of the risk definition. Only with a thorough understanding of risk will the business be able to take specific action when managing it. For example, defining impact to the business requires information about which asset is affected, what kind of damage may occur, and the extent of damage to the asset. Next, to determine the probability of the impact occurring, you must understand how each impact may occur and how effective the current control environment will be at reducing the probability of the risk.

Using terms defined in Chapter 1, "Introduction to the Security Risk Management Guide," the following risk statement provides guidance in demonstrating both elements of impact and the probability of impact:

Risk is the probability of a vulnerability being exploited in the current environment, leading to a degree of loss of confidentiality, integrity, or availability, of an asset.

The Microsoft security risk management process provides the tools to consistently communicate and measure the probability and degree of loss for each risk. The chapters in this guide walk through the process to establish each component of the well-formed risk statement to identify and prioritize risks across the business. The following diagram builds upon the basic risk statement discussed previously to show the relationships of each element of risk.

Figure 3.4: Components of the Well-Formed Risk Statement
See full-sized image

To help communicate the extent of impact and the degree of probability in the risk statement, the Microsoft security risk management process begins prioritizing risk by using relative terms such as high, moderate, and low. Although this basic terminology simplifies the selection of risk levels, it does not provide sufficient details when you conduct a cost-benefit analysis to select the most efficient mitigation option. To address this weakness of the basic qualitative approach, the process provides tools to generate a detailed level comparison of risks. The process also incorporates quantitative attributes to further aid the cost-benefit analysis for selecting controls.

A common pitfall of risk management disciplines is that they often do not consider the qualitative definitions such as high, moderate, and low risks to the business. Many risks will be identified in your security risk management program. Although the Microsoft security risk management process provides guidance to consistently apply qualitative and quantifiable risk estimates, it is the Security Risk Management Team's responsibility to define the meaning of each value in specific business terms. For example, a high risk to your business may mean a vulnerability occurring within one year, leading to the loss of integrity of your organization's most important intellectual property. The Security Risk Management Team must populate the definitions of each element of the well-formed risk statement. The next chapter provides prescriptive guidance on defining risk levels. It should assist you in defining risk levels for your unique business. The process simply facilitates the exercise, helping to achieve consistency and visibility throughout the process.  

Determining Your Organization's Risk Management Maturity Level

Before an organization attempts to implement the Microsoft security risk management process, it is important that it examines its level of maturity with regard to security risk management. An organization that has no formal policies or processes relating to security risk management will find it extremely difficult to put all aspects of the process into practice at once. Even organizations with some formal policies and guidelines that most employees follow fairly well may find the process a bit overwhelming. For these reasons, it is important that you make an estimate of your own organization's maturity level. If you find that your organization is still relatively immature, than you may want to introduce the process in incremental stages over several months, perhaps by piloting it in a single business unit until the cycle has been completed several times. Having demonstrated the effectiveness of the Microsoft security risk management process through this pilot program, the Security Risk Management Team could then slowly introduce it to other business units until the entire organization is using it.

How do you determine the maturity level of your organization? As part of Control Objectives for Information and Related Technology (CobiT), the IT Governance Institute (ITGI) includes an IT Governance Maturity Model. You may want to acquire and review CobiT for a detailed method for determining your organization's level of maturity. The Microsoft security risk management process summarizes elements used in CobiT and presents a simplified approach based on models also developed by Microsoft Services. The maturity level definitions presented here are based on the International Standards Organization (ISO) Information technology—Code of practice for information security management, also known as ISO 17799.

You can estimate your organization's level of maturity by comparing it to the definitions presented in the following table.

Table 3.2: Security Risk Management Maturity Levels

Organizational Risk Management Maturity Level Self Assessment

The following list of assessments offers a more rigorous way to measure your organizational maturity level. The topics elicit subjective responses, but by honestly considering each of them you should be able to determine how well prepared your organization is for implementation of the Microsoft security risk management process. Score your organization on a scale of 0 to 5, using the previous maturity level definitions as a guide.

Calculate your organization's score by adding the scores of all of the previous items. Theoretically, scores could range from 0 to 85; however, few organizations will approach either extreme.

A score of 51 or above suggests that the organization is well prepared to introduce and use the Microsoft security risk management process to its fullest extent. A score of 34 to 50 indicates that the organization has taken many significant steps to control security risks and is ready to gradually introduce the process. Organizations in this range should consider rolling out the process to a few business units over a few months before exposing the entire organization to the process. Organizations scoring below 34 should consider starting very slowly with the Microsoft security risk management process by creating the core Security Risk Management Team and applying the process to a single business unit for the first few months. After such organizations demonstrate the value of the process by using it to successfully reduce risks for that business unit, they should expand it to two or three additional business units as feasible. Continue to move slowly, though, because the changes introduced by the process can be significant. You do not want to disrupt the organization to such a degree that you interfere with its ability to effectively achieve its mission. Use your best judgment in this regard—every system that you leave unprotected is a potential security and liability risk, and your own knowledge of your own systems is best. If you think that it is urgent to move quickly and to disregard the suggestion to move slowly, do that.

You should carefully consider which business unit to use for the pilot programs. Questions to consider relate to how important security is to that business unit, where security is defined in terms of the availability, integrity, and confidentiality of information and services. Examples include:

You should consider these same questions when selecting business units for expansion of the program.

Note   The (U.S.) National Institute for Standards and Technology (NIST) provides a Security Self Assessment Guide for Information Technology Systems that may be useful to help determine your maturity level; see http://csrc.nist.gov/groups/SMA/fisma/documents/Status-of-NIST-SP-800-26_v2.pdf.

Defining Roles and Responsibilities

The establishment of clear roles and responsibilities is a critical success factor for any risk management program due to the requirement for cross-group interaction and segregated responsibilities. The following table describes the primary roles and responsibilities used throughout the Microsoft security risk management process.

Table 3.3: Primary Roles and Responsibilities in the Microsoft Security Risk Management Process

The Security Risk Management Team will encounter first-time participants in the risk management process who may not fully understand their roles. Always take the opportunity to provide an overview of the process and its participants. The objective is to build consensus and highlight the fact that every participant has ownership in managing risk. The following diagram, which summarizes key participants and shows their high-level relationships, can be helpful in communicating the previously-defined roles and responsibilities and should provide an overview of the risk management program.

To summarize, the Executive Sponsor is ultimately accountable for defining acceptable risk and provides guidance to the Security Risk Management Team in terms of ranking risks to the business. The Security Risk Management Team is responsible for assessing risk and defining functional requirements to mitigate risk to an acceptable level. The Security Risk Management Team then collaborates with the IT groups who own mitigation selection, implementation, and operations. The final relationship defined below is the Security Risk Management Team's oversight of measuring control effectiveness. This usually occurs in the form of audit reports, which are also communicated to the Executive Sponsor.

Figure 3.5: Overview of Roles and Responsibilities Used Throughout the Microsoft Security Risk Management Process
See full-sized image

Building the Security Risk Management Team

Before starting the risk assessment process, do not overlook the need to clearly define roles within the Security Risk Management Team. Because the risk management scope includes the entire business, non-Information Security Group members may request to be part of the team. If this occurs, outline clear roles for each member and align with the roles and responsibilities defined in the overall risk management program above. Investing in role definition early reduces confusion and assists decision making throughout the process. All members on the team must understand that the Information Security Group owns the overall process. Ownership is important to define because Information Security is the only group that is a key stakeholder in every stage of the process, including executive reporting.

Security Risk Management Team Roles and Responsibilities

After assembling the Security Risk Management Team, it is important to create specific roles and to maintain them throughout the entire process. The primary roles of the Risk Assessment Facilitator and the Risk Assessment Note Taker are described below.

The Risk Assessment Facilitator must have extensive knowledge of the entire risk management process and a thorough understanding of the business, as well as an understanding of the technical security risks that underlie the business functions. He or she must be able to translate business scenarios into technical risks while conducting the risk discussions. As an example, the Risk Assessment Facilitator needs to understand both the technical threats to and vulnerabilities of mobile workers and the business value of such workers. For example, customer payments will not be processed if a mobile worker cannot access the corporate network. The Risk Assessment Facilitator must understand scenarios such as these and be able to identify the technical risks and potential control requirements, such as mobile device configuration and authentication requirements. If possible, select a Risk Assessment Facilitator who has performed risk assessments in the past and who understands the overall priorities of the business.

If a facilitator with risk assessment experience is unavailable, enlist the assistance of a qualified partner or consultant. However, be sure to include an Information Security Group member who understands the business and the stakeholders involved.

Note   Outsourcing the risk assessment facilitation role may be attractive, but beware of losing the stakeholder relationship, business, and security knowledge when the consultants leave. Do not underestimate the value that a risk management process brings to the stakeholders as well as the Information Security Group.

The Risk Assessment Note Taker is responsible for capturing notes and documenting the planning and data gathering activities. This responsibility may seem too informal for role definition at this stage; however, solid note taking skills pay off in the prioritization and decision support processes later in the process. One of the most important aspects of managing risk is communicating risk in terms that stakeholders understand and can apply to their business. A thorough note taker makes this process easier by providing written documentation when needed.

Top of page

Summary

Chapters 1-3 provide an overview of risk management and define the goals and approach to begin building the foundation for a successful implementation of the Microsoft security risk management process. The next chapter covers the first phase, Assessing Risk, in detail. Subsequent chapters follow each phase of the risk management process, Conducting Decision Support, Implementing Controls, and Measuring Program Effectiveness.

Top of page

4 of 12