Chapter 6: Implementing Controls and Measuring Program Effectiveness

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

Overview

This chapter explains the last two phases of the Microsoft security risk management process: Implementing Controls and Measuring Program Effectiveness. The Implementing Controls phase is self-explanatory: The Mitigation Owners create and execute plans based on the list of control solutions that emerged during the decision support process to mitigate the risks identified in the Assessing Risk phase. The chapter provides links to prescriptive guidance that your organization's Mitigation Owners may find helpful for addressing a variety of risks.

The Measuring Program Effectiveness phase is an ongoing one in which the Security Risk Management Team periodically verifies that the controls implemented during the preceding phase are actually providing the expected degree of protection. Another step of this phase is estimating the overall progress that the organization is making with regard to security risk management as a whole. The chapter introduces the concept of a "Security Risk Scorecard" that you can use to track how your organization is performing. Finally, the chapter explains the importance of watching for changes in the computing environment such as the addition or removal of systems and applications or the appearance of new threats and vulnerabilities. These types of changes may require the organization to take prompt action to protect itself from new or changing risks.

Implementing Controls

During this phase, the Mitigation Owners employ the controls that were specified during the previous phase. A key success factor in this phase of the Microsoft security risk management process is that the Mitigation Owners seek a holistic approach when implementing the control solutions. They should consider the entire Information Technology (IT) system, the entire business unit, or even the entire enterprise when they create their plans for acquiring and deploying mitigation solutions. The "Organizing Controls" section of this chapter provides links to prescriptive guidance that your organization may find helpful when creating plans for implementing the control solutions. This section is organized on a defense-in-depth model to make it easier for you to find guidance to address particular types of problems.

Required Input for the Implementing Controls Phase

There is only one input from the Conducting Decision Support phase required for the Implementing Controls phase: the prioritized list of control solutions that need to be implemented. If you followed the procedures described in Chapter 5, "Conducting Decision Support," the Security Risk Management Team recorded this information while presenting their findings to the Security Steering Committee.

Participants in the Implementing Controls Phase

Participants in this phase are primarily the Mitigation Owners; however, they may be able to use some assistance from the Security Risk Management Team. The Implementing Controls phase includes the following roles, which were defined in Chapter 3, "Security Risk Management Overview:"

• Security Risk Management Team (Information Security Group, the Risk Assessment Facilitator, and the Risk Assessment Note Taker)
• Mitigation Owners (IT Architecture, IT Engineering, and IT Operations)

The following list summarizes specific responsibilities:

• IT Engineering. Determines how to implement control solutions
• IT Architecture. Specifies how control solutions will be implemented in a manner compatible with existing computing systems
• IT Operations. Implements technical control solutions
• Information Security. Helps to resolve issues that may arise during testing and deployment
• Finance. Ensures that spending levels stay within approved budgets

As a best practice, 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 deployment process.

Tools Provided for the Implementing Controls Phase

There are no tools included with this guide related to the Implementing Controls phase.

Required Outputs for the Implementing Controls Phase

During this phase of the Microsoft security risk management process, you will create plans to implement the control solutions specified during the Conducting Decision Support phase. The following table summarizes these key elements; subsequent sections of this chapter also summarize them.

Table 6.1: Required Outputs for the Implementing Controls Phase

Organizing the Control Solutions

The previous chapter focused on conducting the decision support process. The result of the analysis in that phase were decisions that the Security Steering Committee related to how the organization would respond to the security risks identified during the Assessing Risk phase that preceded it. Some risks may have been accepted or transferred to third parties; for risks that were to be countered, a prioritized list of control solutions was created.

The next step is to craft action plans for implementing the controls in an explicit timeframe. These plans should be clear and precise, and each should be assigned to the appropriate person or team for execution. Use effective project management practices to track progress and ensure timely completion of project goals.

Note   The Microsoft Solutions Framework (MSF) may help you successfully execute the action plans created during this phase. Designed to help organizations deliver high quality technology solutions on time and on budget, MSF is a deliberate and disciplined approach to technology projects and is based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft. For more information about MSF, see www.microsoft.com/technet/itsolutions/msf/default.mspx.

There are several critical success determinants in this phase of the project:

• The executives sponsoring the risk management project must unambiguously communicate the fact that staff members are authorized to implement the controls. Without this explicit statement in place, some employees may object to or even resist efforts to implement the new controls.
• Staff responsible for helping to implement the new controls must be allowed to reprioritize their existing duties. It must be clear to the people working on the controls and their managers that this work is a high priority initiative. If adequate resources and time are not budgeted, it is possible that the controls will not be effectively implemented. In addition, inadequate allocation of resources could lead to problems that could be unfairly attributed to the technology or control.
• The staff responsible for implementing the controls must be given adequate financial support, training, equipment, and other resources required to effectively implement each control.

The staff that implements the controls should record their progress in a report or series of reports that are subsequently submitted to the Security Risk Management Team and the Security Steering Committee.

The Microsoft Security Center, at www.microsoft.com/security/guidance/default.mspx, has an exhaustive and well-organized collection of documentation addressing a wide range of security topics. Guidance on the site may help your organization to implement selected controls from your prioritized list.

Note   Much of this section is drawn from the Microsoft Security Content Overview at https://www.microsoft.com/technet/archive/security/bestprac/overview.mspx. Refer to this site for the latest prescriptive security guidance from Microsoft.

The remainder of this section is organized around the Microsoft defense-in-depth model (illustrated below). Similar to publicly available models that other organizations use, the Microsoft multi-layer model organizes controls into several broad categories. The information in each section comprises recommendations of and links to prescriptive guidance and white papers describing controls for protecting every layer of a network. Prescriptive guidance provides step-by-step help for planning and deploying an end-to-end solution. This guidance has been comprehensively tested and validated in customer environments. White papers and articles generally provide good technical references for product features or pieces of an overall solution; they may not provide the breadth of information found in prescriptive guidance.

Note   The "Physical Security" item in the following graphic does not have a corresponding section in this chapter recommending resources on the topic; Microsoft has not yet published detailed guidance on this subject.

Network Defenses

A well designed and properly implemented network architecture provides highly available, secure, scalable, manageable, and reliable services. You may have multiple networks in your organization and should evaluate each individually to ensure that they are appropriately secured or that the high value networks are protected from unsecured networks. Implementing internal network defenses includes paying attention to proper network design, wireless network security, and, potentially, using Internet Protocol security (IPSec) to ensure that only trusted computers have access to critical network resources.

Prescriptive Guidance

For prescriptive guidance on securing networks with firewalls, see the "Enterprise Design for Firewalls" section of the Firewall Services part of the Windows Server System Reference Architecture at www.microsoft.com/technet/itsolutions/wssra/raguide/FirewallServices/default.mspx.

For additional prescriptive guidance, see Chapter 15, "Securing Your Network," in Improving Web Application Security: Threats and Countermeasures, at https://msdn2.microsoft.com/en-us/library/ms994921.

For prescriptive guidance on implementing secure wireless LANs (WLANs) using EAP and digital certificates, see Securing Wireless LANs with Certificate Services at https://go.microsoft.com/fwlink/?LinkId=14843.

For prescriptive guidance on implementing secure WLANs using PEAP and passwords, see Securing Wireless LANs with PEAP and Passwords at https://go.microsoft.com/fwlink/?LinkId=23459.

For prescriptive guidance on using network segmentation to improve security and performance, see the "Enterprise Design" section of the Network Architecture Blueprint part of the Windows Server System Reference Architecture, at https://www.microsoft.com/technet/itsolutions/wssra/raguide/ArchitectureBlueprints/rbabna.mspx.

White Papers and Articles

Information about IPSec deployment is available in the "Overview of IPSec Deployment" section of the Deploying Network Services volume of the Microsoft® Windows Server™ 2003 Deployment Kit, at https://technet2.microsoft.com/WindowsServer/en/Library/119050c9-7c4d-4cbf-8f38-97c45e4d01ef1033.mspx.

Additional information about using IPSec is available in the "Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server" white paper, at www.microsoft.com/downloads/details.aspx?FamilyID=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&DisplayLang=en.

For a more extensive discussion of network segmentation and the issues that a solid network design can address, see the "Enterprise Design for Switches and Routers" section of the Network Devices part of the Windows Server System Reference Architecture, at www.microsoft.com/technet/itsolutions/techguide/wssra/raguide/Network_Devices_SB_1.mspx.

For an overview of the different types of firewalls available and how they are commonly used see "Firewalls" topic at www.microsoft.com/technet/security/guidance/networksecurity/firewall.mspx.

More information about network access quarantine control can be found in the following white papers:

• The "Network Access Quarantine Control in Windows Server 2003" white paper, at www.microsoft.com/windowsserver2003/techinfo/overview/quarantine.mspx.
• The "Virtual Private Networking with Windows Server 2003: Overview" white paper, at www.microsoft.com/windowsserver2003/techinfo/overview/vpnover.mspx.

Host Defenses

Hosts come in two types: clients and servers. Securing both effectively requires striking a balance between the degree of hardening and the level of usability. Although exceptions exist, the security of a computer typically increases as its usability decreases. Host defenses may include the disabling of services, removing specific user rights, keeping the operating system up to date, as well as using antivirus and distributed firewall products.

Prescriptive Guidance

The Patch Management Web site on Microsoft TechNet includes tools and guides to help organizations more effectively test, deploy, and support software updates. See: www.microsoft.com/technet/security/guidance/patch/default.mspx.

For prescriptive guidance on securing Windows XP Professional, see the Step-by-Step Guide to Securing Windows XP Professional with Service Pack 2 in Small and Medium Businesses at https://go.microsoft.com/fwlink/?linkid=19453.

For prescriptive guidance on securing Windows XP, see the Windows XP Security Guide, at https://go.microsoft.com/fwlink/?LinkId=14839.

For prescriptive guidance on securing Windows Server 2003, see the Windows Server 2003 Security Guide, at https://go.microsoft.com/fwlink/?LinkId=14845.

The Threats and Countermeasures Guide is a reference for the major security settings and features included with Windows Server 2003 and Windows XP. It provides detailed background information for use with the Windows Server 2003 Security Guide. It is available at https://go.microsoft.com/fwlink/?LinkId=15159.

For prescriptive guidance on securing Windows 2000 servers, see the Windows 2000 Security Hardening Guide, at www.microsoft.com/downloads/details.aspx?FamilyID=15E83186-A2C8-4C8F-A9D0-A0201F639A56&DisplayLang=en.

White Papers and Articles

Microsoft server-class operating systems and applications use a variety of network protocols to communicate with one another and the client computers that are accessing them, including many Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports. Many of these are documented Knowledge Base (KB) article 832017, "Service Overview and Network Port Requirements for the Windows Server System," at https://support.microsoft.com/?kbid=832017.

"Antivirus Software: Frequently Asked Questions," a brief article that provides a high-level overview of antivirus software and advice on how to acquire, install, and maintain these types of products, is available at www.microsoft.com/athome/security/protect/antivirus.mspx.

"Internet Firewalls: Frequently Asked Questions," an article that describes the importance of using firewalls, when it is appropriate to install firewall software on user computers, and how to resolve a few of the most common problems related to using this type of software, is available at www.microsoft.com/athome/security/protect/firewall.mspx.

Application Defenses

Application defenses are essential to the security model. Applications exist within the context of the overall system, so you should consider the security of the entire environment when evaluating application security. Each application should be thoroughly tested for security compliance before running it in a production environment. The implementation of application defenses includes proper application architecture including ensuring that the application is running with the least amount of privilege with the most minimally-exposed attack surface possible.

Prescriptive Guidance

The Exchange 2003 Hardening Guide, which provides information about securing Microsoft Exchange 2003 Server, is available at www.microsoft.com/downloads/details.aspx?FamilyID=6a80711f-e5c9-4aef-9a44-504db09b9065&displaylang=en.

The Security Operations Guide for Exchange 2000, which provides guidance on securing Microsoft Exchange 2000 Server, is available at www.microsoft.com/technet/security/prodtech/mailexch/opsguide/default.mspx.

The Improving Web Application Security: Threats and Countermeasures solution guide, which provides a solid foundation for designing, building, and configuring secure ASP.NET Web applications, is available at https://msdn2.microsoft.com/en-us/library/ms994921.

Chapter 18, "Securing Your Database Server," of the Improving Web Application Security: Threats and Countermeasures solution guide, which includes prescriptive information about securing Microsoft SQL Server™, is available at https://msdn2.microsoft.com/en-us/library/Aa302434.

The Building Secure ASP .NET Applications: Authentication, Authorization, and Secure Communication guide, which presents a practical, scenario-driven approach to designing and building secure ASP.NET applications for Windows 2000 and version 1.0 of the Microsoft .NET Framework, is available at https://msdn2.microsoft.com/en-us/library/Aa302415.

White Papers and Articles

The "Building and Configuring More Secure Web Sites" white paper has detailed information about the lessons that the Microsoft security team learned during the 2002 OpenHack 4 online security contest sponsored by eWeek. The solution deployed for the contest included the.NET Framework, Microsoft Windows® 2000 Advanced Server, Internet Information Services (IIS) version 5.0, and SQL Server 2000. It successfully withstood over 82,500 attempted attacks to emerge from the competition unscathed. The paper is available at https://msdn2.microsoft.com/en-us/library/Aa302370.

Data Defenses

Data is the most organizations' most valuable resource. At the client level, data is often stored locally and may be particularly vulnerable to attack. Data can be protected in a number of ways, including the use of the Encrypting File Service (EFS) and frequent, secure backups.

Prescriptive Guidance

For information about backing up data on Windows 2000–based networks, see the Windows 2000 Server Backup and Restore Solution at www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/backuprest/default.mspx.

Measuring Program Effectiveness

The Measuring Program Effectiveness phase allows the Security Risk Management Team to formally document the current state of risk to the organization. As the business continues along the risk management cycle, this phase also helps demonstrate the progress of managing risk to an acceptable level over time. To help communicate progress, this section introduces the concept of a Security Risk Scorecard as a high level indicator of risk across an organization. The scorecard helps demonstrate that risk management is truly integrated into IT operations. The concept of "integrated risk management" is also a key attribute in determining your organizations risk maturity level, as Chapter 3, "Security Risk Management Overview," described.

Required Inputs for the Measuring Program Effectiveness Phase

The following list summarizes the few inputs from the previous phases that are required for the Measuring Program Effectiveness phase:

• The prioritized list of risks that need to be mitigated. If you followed the procedures described in Chapter 4, "Assessing Risk," you recorded this information in the Microsoft Excel® worksheet called SRMGTool3-Detailed Level Risk Prioritization.xls, located in the Tools and Templates folder that was created when you unpacked the archive containing this guide and the related files.
• The prioritized list of control solutions that the Security Steering Committee selected. If you followed the procedures described in Chapter 5, "Conducting Decision Support," the Security Risk Management Team recorded this information while presenting its findings to the Security Steering Committee.
• Reports on deployment of controls that the Mitigation Owners created during the Implementing Controls phase that describe their progress with deploying the selected control solutions.

Participants in the Measuring Program Effectiveness Phase

The primary participants in the Measuring Program Effectiveness phase are members of the Information Security Group. They are responsible for developing the Security Risk Scorecard (explained below), verifying that the controls have been implemented and are effectively mitigating the risks as expected, and monitoring for changes to the information systems environment that may alter the organization's risk profile. The Information Security Group provides ongoing reports to the Security Steering Committee. Additionally, the Mitigation Owners assist the team by communicating major changes to the computing infrastructure and details about any security events that transpired. To reiterate, the measuring program effectiveness process includes the following roles, which were defined in Chapter 3, "Security Risk Management Overview:"

• Security Risk Management Team (Information Security Group, the Risk Assessment Facilitator, and the Risk Assessment Note Taker)
• Mitigation Owners (IT Architecture, IT Engineering, and IT Operations)
• Security Steering Committee (Executive Sponsor, Business Owners, Architecture, and IT Engineering)

These responsibilities are summarized in the following list:

• Information Security. Creates summary reports for the Security Steering Committee regarding effectiveness of control solutions that have been deployed and about changes to the organization's risk profile. Additionally, creates and maintains the organization's Security Risk Scorecard.
• Internal Audit. Validates control solution effectiveness.
• IT Engineering. Communicates impending changes to the Security Risk Management Team.
• IT Architecture. Communicates planned changes to the Security Risk Management Team.
• IT Operations. Communicates details regarding security events to the Security Risk Management Team.

Tools Provided for the Measuring Program Effectiveness Phase

There are no tools included with this guide related to the Measuring Program Effectiveness phase.

Required Outputs for the Measuring Program Effectiveness Phase

During this phase, the Security Risk Management Team creates reports on the organization's ongoing security risk profile. The following table summarizes these key elements; subsequent sections of this chapter describe them in detail.

Table 6.2: Required Outputs for the Conducting Decision Support Phase

Developing Your Organization's Security Risk Scorecard

The Security Risk Scorecard is an important tool to help communicate the current risk posture of the organization. It also helps demonstrate the progress of managing risk over time and can be an essential communication device to demonstrate the importance of risk management and its value to the organization. The scorecard should provide a summary level of risk to executive management. It is not designed to summarize the tactical view of the detailed risks identified during the Assessing Risk phase.

Note   Be certain that you do not confuse the concept of the Security Risk Scorecard with IT Scorecards that are discussed in other guidance from Microsoft. Developing an IT Scorecard can be an effective way to measure an organization's progress regarding its overall information systems environment. The Security Risk Scorecard can also be valuable to that end, but it is focused on a specific part of the information systems environment: security.

The Security Risk Scorecard helps the Security Risk Management Team drive to an acceptable level of risk across the organization by highlighting problem areas and focusing future IT investments on them. Even if elements on the scorecard are ranked as High Risk, depending on your organization you may choose to accept the risk. The scorecard can then be used to help track these decisions at a high level and aids in revisiting risk decisions in future cycles of the risk management process.

The following figure represents a simple Security Risk Scorecard organized by the defense-in-depth layers as described in Chapter 4, "Assessing Risk." Customize the scorecard as needed for your organization. For example, some organizations may decide to organize risk by business units or unique IT environments. (An IT environment is a collection of IT assets that share a common business purpose and owner.) You may also want to have multiple Security Risk Scorecards if your business is quite decentralized.

The Security Risk Scorecard can also be part of a larger IT "dashboard" that shows key metrics across IT Operations. The practice of measuring and communicating IT metrics in a dashboard is also a best practice at Microsoft.

Measuring Control Effectiveness

After controls have been deployed, it is important to ensure that they are providing the expected protection and that they continue to remain in place. For example, it would be an unpleasant surprise to discover that the root cause of a major security breach was that the virtual private networking (VPN) authentication mechanism allowed unauthenticated users to access the corporate network because it had been misconfigured during deployment. It would be an even more unwelcome discovery that intruders had gained access to internal resources because a network engineer had reconfigured a firewall to allow additional protocols without getting prerequisite approval through the organization's change control process.

According to the U.S. Government Accountability Office's study of information security management at leading, nonfederal organizations (GAO/AIMD-98-68), direct testing was the most frequently noted method for effectively checking the degree of risk reduction achieved by controls. There are various approaches to undertaking these types of tests including automated vulnerability assessment tools, manual assessments, and penetration testing.

In a manual assessment, a member of the IT team verifies that each control is in place and appears to be functioning correctly. This can be very time consuming, tedious, and prone to error when you are checking more than a few systems. Microsoft has released a free, automated, vulnerability assessment tool called the Microsoft Baseline Security Analyzer (MBSA). MBSA can scan local and remote systems to determine which critical security hotfixes are missing, if any, as well as a variety of other important security settings. More information about MBSA is available at www.microsoft.com/technet/security/tools/mbsahome.mspx. Although MBSA is free and very useful, other automated assessment tools are available from a variety of vendors.

The other approach mentioned previously was penetration testing, often shortened to pen testing. In a pen test, one or more people are authorized to perform automated and manual tests to see whether they can break into an organization's network in a wide variety of ways. Some organizations perform pen tests using their own in-house security experts, while others hire outside experts who specialize in conducting these tests. Regardless of who performs the pen tests, the Information Security Group should be responsible for managing the process and tracking the results. While pen testing is an effective approach, it usually does not reveal as wide a range of vulnerabilities, because it is not as exhaustive as a properly-implemented vulnerability assessment. Therefore, it is recommended that you supplement any pen tests with other methodologies.

Note   For more information about penetration testing, see the book Assessing Network Security, written by members of the Microsoft security team—Ben Smith, David LeBlanc, and Kevin Lam (Microsoft Press, 2004).

You can also verify compliance through other means. The Information Security Group should encourage anyone in the organization to submit feedback. Or (or additionally), the team could institute a more formal process in which each business unit is required to submit periodic compliance reports. As part of its security incident response process, the Information Security Group should create its own reports that document the symptoms that originally brought the issue to the surface, what data was exposed, what systems were compromised, and how the attack proceeded. Many things could be the cause of a security incident, including malicious code such as worms or viruses; internal users who accidentally violate policy; internal users who deliberately expose sensitive information; external attackers working for organizations such as competitors or foreign governments; and natural disasters. The steps that the Information Security Group took to contain the incident should also be documented.

The Information Security Group's effectiveness can also be tracked in several other ways, such as:

• Number of widespread security incidents that affected similar organizations but were mitigated by controls that the Security team recommended.
• Time required before computing services are fully restored after security incidents.
• Quantity and quality of user contacts.
• Number of briefings presented internally.
• Number of training classes provided internally.
• Number of assessments completed.
• Number of computer security conferences attended.
• Number and quality of public speaking engagements.
• Professional certifications achieved and maintained.

Reassessing New and Changed Assets and Security Risks

To be effective, security risk management needs to be a continuous and ongoing process within an organization rather than a temporary project. Reassessing the environment periodically by following the process described in Chapter 4, "Assessing Risk," is the first step of starting the cycle anew. It may seem obvious, but the Security Risk Management Team should reuse and update the lists of assets, vulnerabilities, controls, and other intellectual property developed during the initial risk management project.

The team can use its resources most efficiently by focusing on changes to the organization's operational environment. If there has been no change to an asset since it was last reviewed, there is no point in reviewing it in minute detail once again. The team can determine where to focus its attention by collecting timely, accurate, and relevant information about changes that impact the organization's information systems. Internal events that should draw close scrutiny include installation of new computer software or hardware; new internally developed applications; corporate reorganizations; corporate mergers and acquisitions; and divestures of parts of the organization. It would also be prudent to review the existing list of risks to determine whether any changes have occurred. Additionally, examining the security audit logs may provide insight on new areas to investigate.

The team should also stay alert for changes that might impact information security that take place outside of the organization. Some examples include:

• Reviewing vendor Web sites and mailing lists for new security updates and new security documentation.
• Monitoring third-party Web sites and mailing lists for information about new security research and new announcements regarding security vulnerabilities.
• Attending conferences and symposiums that include discussion of information security topics.
• Undertaking information security training.
• Staying current by reading books on computer and network security.
• Monitoring for announcements of new attack tools and methods.

Summary

During the Implementing Controls phase, the Mitigation Owners deployed the control solutions that the Security Steering Committee had chosen during the Conducting Decision Support phase. The Mitigation Owners also provided the Security Risk Management Team with reports on their progress regarding deployment of the control solutions. The fourth phase of the Microsoft security risk management process is dominated by ongoing activities that will continue to be performed until the Security Risk Management Team launches the next cycle by beginning a new security assessment. These ongoing activities include detailed reports explaining changes to the information systems environment that are in the planning stage; documenting changes to the information systems environment that are about to commence; and explaining unplanned security events that affected the information systems environment.

This phase also includes reports from the Security Risk Management Team that summarize the degree to which the control solutions are mitigating risk and a report showing how previously identified threats have changed due to new threats, new vulnerabilities, or changes to the organization's information systems environment. Finally, this phase includes creating and maintaining a Security Risk Scorecard that demonstrates the organization's current risk profile.

Conclusion to the Guide

This guide has presented the Microsoft approach to security risk management. It is a proactive approach that can assist organizations of all sizes with their response to security risks that may challenge the success of their business. A formal security risk management process enables enterprises to operate in the most cost efficient manner with a known and acceptable level of business risk and gives organizations a consistent, clear path to organize and prioritize limited resources in order to manage risk. You will realize the benefits of using security risk management when you put into place cost-effective controls that lower risk to an acceptable level.

The definition of acceptable risk, and the approach to manage risk, varies for every organization. There is no right or wrong answer; there are many risk management models in use today. Each model has tradeoffs that balance accuracy, resources, time, complexity, and subjectivity. Investing in a risk management process—with a solid framework and clearly defined roles and responsibilities—prepares the organization to articulate priorities, plan to mitigate threats, and address the next threat or vulnerability to the business.

The Microsoft security risk management process uses industry standards to deliver a hybrid of established risk management models in an iterative four-phase process that seeks to balance cost and effectiveness. During a risk assessment process, qualitative steps identify the most important risks quickly. A quantitative process follows that is based on carefully defined roles and responsibilities. This approach offers a fine degree of detail and leads to a thorough understanding of the most important risks. Together, the qualitative and quantitative steps in the risk assessment process provide the basis on which you can make solid decisions about risk and mitigation, following an intelligent business process. Now that you have read the entire guide you are ready to start the process; return to Chapter 4, "Assessing Risk," to begin.