Securing Windows 2000 Server

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 3: Understanding the Security Risk Management Discipline

Published: November 17, 2004 | Updated : May 31, 2006

Note: Welcome to the TechNet Archive. We've created this Archive area so that we can continue to make available older content that is still of interest to some of our users. This allows us to streamline the content offerings on the site and keep it focused on the newest, most relevant content.

This chapter draws upon proven practices from security analysis methodologies in use today that make the most of the Microsoft® Solutions Framework (MSF) and Microsoft Operations Framework (MOF). MSF offers guidance in the planning, building, stabilizing, and deploying phases of the project life cycle in the areas of enterprise architecture and infrastructure deployment. MOF provides advice on how to develop or improve management systems for information technology (IT) operations. For details on MSF or MOF, see the "More Information" section at the end of this chapter.

The chapter defines the three primary guidance processes, the Security Risk Management Discipline (SRMD), and the Security Risk Framework in terms of risk management activities that occur during the life cycle of a security project.

There are three primary processes that an organization can use to define what it needs to do to become secure and how to keep secure. The following defines these primary processes at a high level.

Assessment

This phase involves gathering relevant information from the company's environment to perform a security assessment. Enough data must be captured to effectively analyze the current state of the environment and then determine how well protected the organization’s information assets are from potential threats. In addition to the security assessment, a Security Action Plan will later be created to execute during the implementation process.
Development and Implementation

This phase focuses on executing a Security Action Plan to implement the recommended changes to the environment defined in the assessment. In addition to the Security Action Plan, the Security Risk Contingency Plan is developed.
Operation

This phase involves making modifications and updates to your environment as needed to keep it secure. Penetration testing and incident response strategies are carried out during operational processes, which help solidify the objectives of implementing a security project in your organization. Auditing and monitoring activities also are carried out within the operational processes to keep the infrastructure intact and secure.

Security Risk Management and Security Framework Practices

During the execution of the security plan, two types of risk management activities are ongoing during the life cycle of the project. The first is managing the risk inherent to the project itself, and the second is managing the risk associated with security components. The project risks are assessed during the project life cycle only, while the security risks must be assessed during the entire life cycle of the solution or computer system. The MSF Risk Management Discipline serves as the basis for managing risk for both projects and security assessments. Prescriptive examples for security risk management are described in more detail in Chapter 4, "Applying the Security Risk Management Discipline," of this guide.

In this solution guide, the Security Risk Management Discipline (SRMD), which is derived from the MSF Risk Management Discipline (RMD), is defined. To maintain a clear distinction between the two activities, RMD is mentioned in the context of project risk, while SRMD refers to the security risk assessment activity. The RMD is used as the primary tool for the development of the SRMD.

Both the RMD and the SRMD processes advocate a proactive approach, continuous risk assessment, and integration into decision-making throughout the project and operation of your environment.

Computer system security should be done proactively and continuously to ensure the security of information assets and to monitor for new threats and vulnerabilities. Information security should always be considered whenever you add new functionality to your organization’s technology infrastructure. In addition, some business process and procedures may have to be altered to operate in the modified environment and provide protection to these new information assets.

The nine steps in the Security Risk Management Discipline are:

Assessment

1. Asset assessment and valuation

2. Identifying security risks

3. Analyzing and prioritizing security risks

4. Security risk tracking, planning, and scheduling

Development and Implementation

5. Security remediation development

6. Security remediation testing

7. Capturing security knowledge

Operating

8. Reassessing new and changed assets and security risks

9. Stabilizing and deploying new or changed countermeasures

These steps are embodied within the SRMD as the three primary phases of: assessment, implementation, and operation.

Assessment

The following sections incorporate organizational assessment tasks into a foundation for the beginning of a security analysis. Asset assessment and validation are the first steps toward security analysis because it is necessary to know what you are starting with to evaluate risks moving forward. The security analysis process is a set of strategies aimed at enabling you to determine which assets are worth securing in your environment and in what order you want to prioritize securing them.

Asset Assessment and Valuation

Asset assessment is the value placed on information relative to the parties involved and what effort it took to develop this information. Valuation is how much it costs to maintain an asset, what it would cost if it were lost or destroyed, and what benefit would be gained if another party obtained this information. The value of an asset should reflect all identifiable costs that would arise if there were an actual impairment of the asset.

Security Risk Identification

Security risk identification allows for project team members to brainstorm and surface potential security risks. Information is collected on threats, vulnerabilities, exploits, and countermeasures.

Security Risk Analysis

Security risk analysis is used to analyze the potential attacks, tools, methods, and techniques that may be used to exploit a potential vulnerability. Security risk analysis is a method of identifying risks and assessing the possible damage that could be caused to justify security safeguards.

A security risk analysis has three main goals: Identify risks, quantify the impact of potential threats, and provide an economic balance between the impact of the risk and the cost of the countermeasure. Information is collected to estimate the level of risk so that the team can make educated decisions around which security risks should receive the most remediation effort.

This analysis is then used to prioritize security risks and enable your organization to commit resources to address the most critical security issues.

A risk analysis helps integrate the security program objectives with the company’s business objectives and requirements. The more your business and security objectives are in alignment, the more successful your organization will be at fully realizing both.

The analysis also helps your company draft a proper budget for a security program and the security components that make up that program. When you know how much your company's assets are worth and you understand the possible threats they are exposed to, you can make intelligent decisions on how much money to spend toward protecting those assets.

Security Risk Tracking, Planning, and Scheduling

Security risk tracking, planning, and scheduling takes the information obtained from the security risk analysis and uses it to formulate mitigation and contingency strategies and plans that encompass them. Security risk scheduling attempts to define a schedule for the various remediation strategies constructed during the building phase of a security project. This scheduling takes into consideration how the security plans are approved and incorporated into the information architecture, as well as the standard day-to-day operations procedures that have to be implemented.

Development and Implementation

The work you perform during the assessment process enables you to implement proper countermeasure development and implementation. The results of your assessment processes provide an easy transition into implementing effective countermeasure deployment and security learning strategies.

Security Risk Remediation Development

Security risk remediation development is the process of taking the plans that were created in the assessment phase and using them to create a new security strategy involving configuration management, patch management, monitoring and auditing, and operational policies and procedures. As various countermeasures are being developed, it is important to ensure thorough tracking and reporting on this progress.

Security Risk Remediation Testing

Security risk remediation testing occurs after the development of the remediation strategies and associated system management changes have taken place and the policies and procedures to determine their effectiveness have been written. The testing process enables the team to consider how these changes can be deployed into a production environment. During the testing process, the countermeasures are evaluated for effectiveness against how well the security risk is controlled.

Security Risk Learning

Security risk learning formalizes the process for capturing knowledge about how the team secured the assets and documents the vulnerabilities and the exploits that were discovered. As the IT department learns new security information, it must be captured and redeployed to continually optimize the effectiveness of the security countermeasures protecting company assets. In addition, security education needs to happen for the business communities through training or security awareness bulletins.

Note These steps are intended as a logical guide and do not need to be followed in sequence to address any given security risk. Security teams will often cycle through the identification, analysis, and planning steps as they develop experience on security issues, threats, and vulnerabilities for their particular information assets.

Your organization must define a formal risk management process that will define how security countermeasures are initiated and evaluated, and under what circumstances transitions between the steps should occur for individual or groups of security risks.

Operation

Strong and consistent operating cycles provide your security teams with a mechanism to deliver reliable and predictable results. By executing the assessment process early in the security project, teams have greater knowledge of how to reassess new and changed assets throughout your enterprise. Stabilizing and deploying new or changed countermeasure against the new and changed assets then becomes part of the day-to-day operation of your company.

Reassessing New and Changed Assets and Security Risks

These processes are essentially change management processes, but this cycle is also where security configuration management is executed. This cycle leads to release management when the new countermeasures and security policies are completed.

Stabilizing and Deploying New or Changed Countermeasures

In the operation phase, these processes are managed by system administration, security administration, and network administration teams. Service monitoring, service control, and job scheduling are additional processes in the operation phase in which security administrators execute new and improved countermeasures.

Security Service Desk, Incident Management, and Problem Management Learning

In the support phase, operational groups within the IT organization support the secure environment by strong security management from the security service desk and controlled incident and problem escalation management.

Service Level, Financial, and Availability Management

MSF and MOF are proven practices designed to help you develop, deploy, and maintain a strong security management program. Successfully utilizing these proven practices enables the creation of an environment that provides integrity, confidentiality, and availability of resources.

Security management is optimized by strong management in service-level managements, financial management, service community management, availability management, capacity management, and workforce management.

Security Risk Management Framework

Overview

The framework makes the most of the MSF Process Model and describes a high-level sequence of activities for building and deploying IT security solutions. Rather than prescribing a specific series of procedures, the framework is flexible enough to accommodate a broad range of IT processes. The process model covers the life cycle of a solution from project inception to live deployment.

Figure 3.1 Security Framework process model milestones by phase

The MSF Process Model may be used to develop software applications and to deploy infrastructure technology. The process model follows an iterative cycle designed to accommodate changing project requirements through short development cycles and incremental versions of the solution. Continuing risk management and testing cycles make it possible to accommodate such projects.

Many key questions about the project are asked and answered or discussed at each milestone of the process model, such as: Does the team agree on the project scope? Has the team planned enough to proceed? Has the team built what it said it would build? Is the solution working properly for the customers and partners of your organization?

The following six major processes of a security project associated with the Figure 3.1 are discussed briefly here.

Initiation of the project definition

The initiation phase of the project addresses one of the most fundamental needs for the success of the security project: unifying the project team and security program. The process of team initiation continues until refinement at the end of the initiation phase. All team members must have a clear vision of what they want to accomplish in a security solution and the needs of the business concerning security. This phase focuses on identifying the business problem or opportunity around security management. All parties involved in security management must define goals, assumptions, and constraints during these processes.
Security assessment and analyses

The assessment and analyses of security management are processes that take place within the planning phase of the MSF methodology. These processes include organization assessment, asset valuation, threat identification, vulnerability assessment, and security risk assessment. Together they form the planning involved in a successful countermeasure deployment.
Security remediation development

Inputs taken from the security assessment and analysis phases create a means for security remediation development. During these processes, developers are constantly working through the development, testing, and validation of countermeasures to remediate risks identified in earlier phases of the project. These security remediation development processes are unit tested by the development team and evaluated against quality criteria.
Security remediation testing and resource functionality testing

The security remediation testing and resource functionality testing processes contain less predictable results. Unforeseen results from the functional testing are tagged and managed during the stabilizing phase by the testing processes. Although the building phase builds on known plans and specifications, the number and severity of bugs that will be found is always unknown. The techniques of bug convergence and zero bug bounce are used by Microsoft to measure the quality state of the solution and predict the release date during this phase.
Security policies and countermeasure deployment

The security policies and countermeasure deployment processes continue throughout the deploying phase of the MSF methodology and are continued into the MOF process cycle. This process of countermeasure deployment organizes the types of countermeasures and security policies into two types, core and site, and their respective security components. Core-specific security components are located at a central or key location that involves the entire security solution. Site-specific components are located at individual locations that enable users to access and use the security solution.
Deployment complete

Security risk management knowledge is a process captured near the deployment complete milestone. Capturing the lessons learned near deployment move the solution into an operational state and hand the completed project off to the MOF process cycle.

For additional details about security project processes, see the Microsoft Solution for Security Services Guide.

Creating Your Security Program Team

During the assessment process of the MSF Process Model, a crucial step toward securing your environment occurs, which is the creation of a security program. The charter of this security program is to determine the objectives, scope, policies, priorities, standards, and strategies for total security within your organization. The members of the security program are senior executives within the company. The Security Administration Group is then comprised of middle-level managers and their reporting teams who implement and manage the policies governed by the security program.

A security program should be developed using a top-down approach, meaning that the initiation, support, and direction must come from top management, work down through middle management, and finally include staff members. Support however, may be a combination of top-down, bottom-up or middle-out development and championing of ideas in security management. Many companies today are use a bottom-up approach for development and support in which the IT department develops a security plan without proper management support and direction. Such situations can cause security programs to become out of alignment with the larger business objectives of the organization.

Senior management should begin creating the security program by assigning roles and responsibilities within the organization that are necessary to get it off the ground. The involvement of senior management keeps the program strong and evolving as the business and technical environments change. Creating roles within a security program validates that the organization recognizes security as a cohesive part of its business rather than just a concern.

In addition to a security program, management must establish a security administration group. The security administration group is directly responsible for monitoring the majority of the facets of a security program. The security program in an organization usually develops security policies, while the security administration group enforces and monitors security configurations.

Depending on the organization, its security needs, and the size of the environment, security administration can consist of one person or a group of individuals working in a central or decentralized manner.

Assessment

The security framework for threat assessment described in the process model is designed to help security professionals develop a strategy to protect the availability, integrity, and confidentiality of data in an organization's IT infrastructure. It may be of interest to information resource managers, computer security officials, and administrators, and of particular value to those trying to establish computer security policies. The framework offers a systematic approach to this important task and, as a final precaution, also involves establishing contingency plans in case of a disaster.

Confidentiality

The IT infrastructure of your organization may contain information that requires protection from unauthorized disclosure. Examples include timed dissemination of information, such as a crop report, personal information, or proprietary business information. Confidentiality ensures that the ability to provide the necessary level of secrecy is enforced at each junction of data processing and prevents unauthorized disclosure. A consistent level of confidentiality should be maintained while data resides on computers and devices within the network, as it is transmitted, and when it reaches its destination.

Integrity

The IT infrastructure contains information that must be protected from unauthorized, unanticipated, or unintentional modification. Examples include census information, economic indicators, or financial transactions systems. Integrity is upheld when the accuracy and reliability of information and computer systems is assured, and unauthorized modification of data is prevented.

Availability

The IT infrastructure contains information or provides services that must be available on a timely basis to meet mission requirements or to avoid substantial losses. Examples include services that are critical to safety, life support, and consistent network connectivity. Availability ensures the reliability and timely access to data and resources to authorized individuals.

Security administrators need to decide how much time, money, and effort must be spent to develop appropriate security policies and controls. Your organization should analyze its specific needs and then determine its resources, scheduling requirements, and constraints. Computer systems, environments, and organizational policies are different, making the strategy for securing groups of computers in your organization difficult.

Although a security strategy can save your organization valuable time and provide important reminders of what needs to be done, security is not a one-time activity. It is an integral part of the system life cycle for your environment. The activities described in this chapter generally require either periodic updating or appropriate revision. Such changes are made when configurations or other conditions change significantly, or when organizational regulations and policies require changes. It is an iterative process that is never finished and should be revised and tested periodically.

Organizational Assessment

Establishing an effective set of security policies and controls requires using a strategy to determine the vulnerabilities that exist in your computer systems and in the current security policies and controls that guard them. Your review should make note of areas in your environment in which policies are lacking, as well as examine policy documents that exist. In addition to policy reviews, the legal team of your organization should ensure that all security policies are in compliance with the company's legal policy. The current status of your computer security policies can be determined by reviewing the following list:

Physical computer security policies such as physical access controls
Network security policies (for example, e-mail and Internet policies)
Data security policies (access control and integrity controls)
Contingency and disaster recovery plans and tests
Computer security awareness and training
Computer security management and coordination policies
Other policy documents that contain sensitive information, including:
- Computer BIOS passwords
- Router configuration passwords
- Access control documents
- Other device management passwords

Threat Analysis

Creating a list of threats (most organizations can identify several) helps your security administrator to identify the various exploits that can be used in an attack. It is important that administrators update their knowledge of this area on a continual basis, because new methods, tools, and techniques for circumventing security measures are constantly being devised.

The threat analysis process is outlined in the planning phase of Figure 3.1 to determine the attacks that can be expected and then developing ways of defending against these attacks. It is impossible to prepare against all attacks; therefore, prepare for the most likely attacks that the organization can expect. It is always better to prevent or minimize attacks than to repair the damage after an attack has already occurred.

To minimize attacks, it is necessary to understand the various threats that cause risks to computers and networks, the corresponding techniques that can be used to compromise security controls, and the vulnerabilities that exist in your security policies. Understanding these three elements of attacks helps you to predict their occurrence, if not their timing or location. Predicting an attack is a matter of predicting its likelihood, which depends on understanding its various aspects. The various aspects of an attack can be expressed in the following equation:

Threat Motives + Exploit Methods + Asset Vulnerabilities = Attack

A malicious attacker can use different methods to launch the same attack. Therefore, the security strategy must be customized for each method that each type of threat agent may exploit.

Vulnerability Assessment

Assessing your organization's security needs must include determining its vulnerabilities in relation to known threats. This assessment entails recognizing the types of assets that your organization has and what kind of damage could be done to them.

Determining Possible Damage from an Attack

Possible damage to assets in your environment can range from minor computer glitches to catastrophic data loss. The damage will depend on the type of attack. If possible, use a test or lab environment to clarify damage resulting from different types of attacks. This approach will enable security personnel to accurately assess the physical damage. Not all attacks cause the same type or amount of damage. Tests that could be run include:

A simulation of an e-mail virus attack on a lab computer followed by an analysis to determine the damage caused and potential recovery procedures required.
A test to determine whether employees are susceptible to social engineering attacks by attempting to acquire a user name and password from an unsuspecting employee.
A drill or a simulation of a data center disaster. Measure the production time lost and the time taken to recover.
A simulation of a malicious virus attack. Measure the time required to recover one computer. This time factor can then be multiplied by the number of infected computers to ascertain the amount of downtime or loss of productivity.

It is also a good idea to involve an incident response team in this process, because a team is more likely than an individual to spot all of the different types of damage that have occurred. An incident response team manages the prioritization of security incidents and the escalations paths to resolve them.

Determining Vulnerabilities or Weaknesses That an Attack Can Exploit

If the vulnerabilities that a specific attack exploits can be discovered, current security policies and controls can be altered or new ones implemented to minimize the vulnerabilities. Determining the type of attack, threat, and method makes it easier to discover existing vulnerabilities, which can be proved by performing a penetration test.

Security Risk Planning and Scheduling

For each exploit method, your organization's security plan should include both proactive and reactive strategies.

A proactive, or pre-attack, strategy is a set of steps that helps to minimize existing security policy vulnerabilities and develop contingency plans. Determining the damage that an attack will cause and the weaknesses and vulnerabilities exploited during the attack helps in developing the proactive strategy.

A reactive, or post-attack, strategy helps security personnel to assess the damage caused by the attack, repair the damage or implement the contingency plan developed in the proactive strategy, document and learn from the experience, and get business functions back up and running as soon as possible.

Proactive Strategy

A proactive strategy is a set of predefined steps that should be taken to prevent attacks before they occur. The steps include looking at how an attack could possibly affect or damage your computer systems and the vulnerabilities that it exploits (steps 1 and 2). The knowledge gained in these assessments can help in implementing security policies that will control or minimize the attacks. The following are the four steps of a proactive strategy:

Determine the damage that the attack will cause
Determine the vulnerabilities and weaknesses that the attack will exploit
Minimize the vulnerabilities and weaknesses determined for this specific attack defined in the first two steps
Determine the appropriate level of countermeasures to implement

Following these steps to analyze each type of attack will produce a side benefit: a pattern will begin to emerge showing overlapping factors of different attacks. This pattern can be helpful in determining the areas of vulnerability that pose the greatest risk to the enterprise.

Note It is also necessary to balance the cost of losing data versus the cost of implementing security controls. Weighing these risks and costs is part of a system risk analysis.

Reactive Strategy

A reactive strategy is implemented when the proactive strategy for an attack has failed. The reactive strategy defines the steps that must be taken during or after an attack. It helps to identify the damage that was caused and the vulnerabilities that were exploited in the attack. A reactive strategy also determines why the attack took place, how to repair the damage that was caused by it, and how to implement a contingency plan.

Both the reactive and the proactive strategies work together to develop security policies and controls to minimize attacks and the damage they cause. The incident response team should be included in the steps taken during or after the attack to help assess, document, and learn from the event.

The following four steps are involved in a reactive strategy:

Limit the damage

Containing the damage that was caused during the attack enables limiting the amount of additional damage. For example, if a virus penetrates your environment, you try to limit the damage as soon as possible by disconnecting the servers from the network, even before you figure out how many servers may be affected. This containment should be done as swiftly as possible
Assess the damage

Determine the damage that was caused during the attack. This assessment should be done as swiftly as possible so that restoring your organization's operations can begin as soon as possible. If it is not possible to assess the damage in a timely manner, a contingency plan should be implemented so that normal business operations and productivity can continue.
Determine the cause of the damage

To determine the cause of the damage it is necessary to understand what resources the attack was aimed at and what vulnerabilities were exploited to gain access or disrupt services. Review system logs, audit logs, and audit trails. These reviews often help in discovering where the attack originated and what other resources were affected.
Repair the damage

It is very important that the damage be repaired as quickly as possible to restore normal business operations and any data lost during the attack. The organization's disaster recovery plans and procedures should cover the restore strategy. The incident response team should also be available to handle the restore and recovery process, and to provide guidance on the recovery process. During this process, contingency procedures are executed to limit the spread of the damage and isolate it.

Contingency Plan

A contingency plan is an alternative plan that is developed in case an attack penetrates your computer systems and damages data or other assets, resulting in a disruption of normal business operations or a slowdown in productivity. The contingency plan is followed if computers or the network cannot be restored in a timely manner. Ultimately, the goal is to maintain the availability, integrity, confidentiality, and availability of data—your contingency plan is equivalent to a "Plan B."

Contingency plans should be created to address each type of attack and threat. Each plan should contain a set of steps to be taken in the event of an attack. The contingency plans should consistently:

Address who must do what, when, and where to keep the organization running.
Be rehearsed periodically to keep staff up to date with current contingency steps.
Cover restoring information from backup servers.
Entail updating virus software, service packs, and hotfixes.
Cover procedures to move your production servers to another location. If funding is available, production server replications should be collected at strategic contingency locations.
Include a post mortem review of current security policies and contingency plans.

The following points outline the various evaluation tasks that should be conducted when developing your contingency plan:

Evaluate your organization's security policies and controls to take advantage of any opportunities to minimize vulnerabilities. The evaluation should address your organization's current emergency plan and procedures and their integration into the contingency plan.
Evaluate current emergency response procedures and their effect on business operations.
Develop planned responses to attacks and integrate them into the contingency plans, noting the extent to which they are adequate to limit damage and minimize the impact of an attack on data processing operations.
Evaluate backup procedures, including the most recent documentation and disaster recovery tests, to assess their adequacy and include the results from the evaluations in the contingency plans.
Evaluate disaster recovery plans to determine whether the steps they entail are adequate to provide a temporary or long-term operating environment. Disaster recovery plans should include testing your organization's required levels of security so that security personnel can determine whether they can continue to enforce security throughout the process of recovery, temporary operations, and the move back to your organization's original processing site or to a new one.
Draw up a detailed document outlining the various findings required to perform the preceding tasks. This document should list:
- Details on user scenarios to test the contingency plans.
- Details on the impact that dependencies, such as obtaining assistance from outside the organization and essential resources, will have on the contingency plans.
- A list of priorities observed in the recovery operations and the rationale used to establish them.
- Details on escalation paths so that when a contingency plan is executed, any issues that may arise from it will clearly escalate to the most effective IT or business operations personnel.

Implementation

Be careful not to implement controls that are too stringent, because the availability of information could then become a problem. There must be a careful balance between security controls and access to information.

Simulation Attack Testing

The last element of a security strategy, testing and reviewing the test outcomes, is carried out after the reactive and proactive strategies have been put into place. Performing simulation attacks on a test or lab network makes it possible to assess where the various vulnerabilities exist, and then adjust your organization's security policies and controls accordingly.

These tests should not be performed on a live production network, because the outcome could be disastrous. Yet, the absence of labs and test computers because of budget restrictions might preclude simulating attacks. To secure the necessary funds for testing, it is important that management is aware of the risks and consequences of an attack, as well as the security measures that may need to be taken to protect the network, including testing procedures. If possible, all attack scenarios should be physically tested and documented to determine the best possible security policies and controls to be implemented.

Certain attacks, such as natural disasters, cannot be tested, although a simulation will help. For example, a fire could be simulated in the server room resulting in all the servers within it being damaged and lost. This disaster scenario can be useful for testing the responsiveness of administrators and security personnel, and for ascertaining how long it will take to get the organization running again.

Adjusting security policies and controls based on the test results is an iterative process. The process is never finished and should be evaluated and revised periodically so that improvements can be implemented.

Operation

A clearly defined path of escalation and problem management are the essentials of an incident response program. By consistently executing an incident response plan early in the security project, teams have greater effectiveness at resolving problems throughout your enterprise. Documenting outcomes and learning from your security project are beneficial for everyone moving forward with new projects. Collecting these types of lessons learned in the operational processes makes the assessment, development, and implementation tasks for the next security project easier to complete.

Incident Response

If your organization wants to fully implement security planning best practices, an incident response team should be created. The incident response team should be involved in the proactive efforts to ensure computer system security, which include:

Developing incident handling guidelines
Preparing paths and procedures of escalation to law enforcement for computer crimes
Identifying software tools for responding to incidents and events
Researching and developing other computer security tools
Conducting training and awareness activities
Performing research on viruses
Conducting attack studies

These efforts will provide knowledge that the organization can use to address issues before and during incidents.

A security administrator should be in a position to monitor and manage security audits for the organization as needed. The security administrator should be the authority—a person or group of people—responsible for implementing the security policy for a security domain. After the security administrator and incident response team have completed these proactive functions, the administrator should turn over the responsibility for handling incidents to the incident response team.

However, the security administrator should continue to be involved as a part of the team. The security administrator may not always be available, though, so the incident response team should be able to handle incidents on its own. The team will be responsible for responding to incidents and should also be involved in analyzing any unusual events that may involve computer or network security.

Document and Learn

It is important that when an attack has taken place, it is documented. Documentation should cover all aspects of the attack that are known, including the damage the attack caused (hardware, software, data loss, loss in productivity), the vulnerabilities and weaknesses that were exploited during the attack, the amount of production time lost, the procedures taken to repair the damage, and the cost of repair efforts. Documentation will help to modify proactive strategies to prevent future attacks and minimize damages.

Implement Contingency Plans

If contingency plans already exist, they can be implemented to save time and to keep business operations running smoothly. If no contingency plan exists, develop an appropriate plan based on the documentation from the previous step.

Review Outcomes and Perform Simulations

After the attack or after defending against it, review the outcome and the proactive strategy for your organization. The review should include details on loss in productivity, data or hardware lost, and the time taken to recover from the attack. You should perform simulations in a test environment that is similar to the production environment to produce the best results.

Review and Adjust Policy Effectiveness

If policies exist for defending against an attack that has taken place, they should be reviewed and checked for effectiveness. If no policies exist, new ones must be drawn up to minimize or prevent future attacks.

When the effectiveness of existing policies is not up to standard, they should be adjusted accordingly. Updates to policies must be coordinated by the relevant managerial personnel, security administrator, IT administrators, and the incident response team. All policies should comply with the organization's general rules and guidelines. For example, your organization's standard working times might be from 8 A.M. to 6 P.M. A security policy could be updated or be created specifying that users may log on only during this time frame.

Security Risk Management Discipline

The following sections draw upon proven practices from security analysis methodologies in use today that make the most of MSF and MOF. MSF offers guidance in the planning, building, stabilizing, and deploying phases of the project life cycle in the areas of enterprise architecture and infrastructure deployment. MOF provides advice on how to develop or improve management systems for IT operations. The Security Risk Management Discipline (SRMD) is defined in detail here, to provide learning that can be applied in your environment. The SRMD is a detailed process that is useful in determining which threats and vulnerabilities have the most potential impact on a particular organization

Identifying Security Risks

Security risk identification is the first step in assessing your organization’s security. To effectively manage the security risk, it must be stated clearly so that the project team can come to a consensus and move on to analyzing the consequences and creating a plan of action to address the risk. Although the scope of security risk is limited to the technology that your project team is trying to secure, the team focus should be expansive enough to address all sources of security risks, including technology, process, environment, and people.

Brainstorming is one way to identify security risks, and there are many sources of information on security issues on the Internet. Your organization may also have an existing vulnerability assessment or penetration test that can be reviewed to attack surface security risks.

Goals

The goal of the security risk identification step is for the team to create a list of known security risks that place your organization’s assets in a vulnerable position. This list should be as comprehensive as possible, covering all views of the enterprise architecture including technology, business, people, and strategy.

Risk management is the process of identifying risks, analyzing the risks, and creating a plan to manage them. A security risk is defined as the expected loss due to, or as an impact of, anticipated threats in light of vulnerabilities and the strength and determination of relevant threat agents.

Inputs

The inputs for the security risk identification step include gathering available knowledge of threats; creating a list of current exploit methods and techniques; and analyzing vulnerabilities that can potentially be exploited to cause harm to your organization’s assets. Threats include any outside potential dangers to information and computer systems. Vulnerabilities are the software, hardware, or procedural weaknesses that provide the threat with a point of attack. These risks often stem from differing views of the enterprise environment, including business practices, applications, data, and infrastructure architecture.

The experience of your team; your organization's current approach to security planning in the form of policies, procedures, guidelines, and templates; and information on the current state of the organization's technology infrastructure will aid in determining the inputs for this step.

The security team may draw upon inputs obtained from the assets themselves or from the results of a tool used to conduct a vulnerability analysis or penetration test. Group brainstorming, facilitated sessions, and even formal security workshops to collect information on team and stakeholder perceptions of security issues will prove useful to obtain inputs.

Risk Identification Activities

During the security risk identification step, the team seeks to create an unambiguous statement or list of security issues by clearly articulating the risks that your organization faces. It is helpful to organize a series of security team workshops or brainstorming sessions to identify the risks associated with a new situation.

Because of the rapid change of technology and environments, it is important that security risk identification is not treated as a one-time activity—the process should be repeated at periodic intervals during the operations life cycle of your organization.

Structured Approach

The use of a structured approach toward security risk management is essential because it allows all team members to use a consistent mechanism for treating security issues. The use of threat classification during this step is a helpful way to provide a consistent, reproducible, and measurable approach.

Threat Classification

Threat classifications (also known as categories or taxonomies) serve multiple purposes for a security team. During risk identification, they can be used to stimulate thinking about security risks arising within different areas. During brainstorming sessions, classifications can also ease the complexities of working with large numbers of threats by providing a convenient way for grouping similar threats together. Threat classifications also may be used to provide a common terminology for the team to use to monitor and report risk status throughout the project.

Security Risk Statement

A security risk statement is a natural language expression of the causal relationship between the existing security state of the organization and a potential, unrealized security result.

The first part of the security risk statement is called "the condition," which provides the description of an existing state or potential threat that the team feels may cause some harm. The second part of the risk statement is called "the consequence," which describes the undesirable loss of confidentiality, integrity, and availability to an asset.

The two statements are linked by a term such as “then” or “may result in” that implies an uncertain (in other words, less than 100 percent) or causal relationship.

The following introduces the risk statement used in this guide:

IF a Threat Agent uses a tool, technique, or method to exploit a Vulnerability, THEN a loss of (confidentiality, integrity, or availability) to an Asset may result in an impact.

Security risk statements are developed through risk analysis. There are two types of risk analysis approach: qualitative and quantitative. Neither the qualitative nor the quantitative approach is superior to the other—they each provide a valuable tool for structuring your risk identification activities. The qualitative approach builds upon information collected in the quantitative process.

Figure 3.2 Security condition and consequence risk statement

The following steps detail each part of the process in the figure:

Define a condition and consequence risk statement for each threat.

If a threat agent gives rise to a threat and exploits a vulnerability, then the attack leads to a risk. The attack can damage the asset by degrading confidentiality, integrity, or availability. Therefore, the attack causes an exposure to company losses. However, these exposures can be counteracted by safeguards.
Assign a threat probability (TP) (0% lowest – 100% highest). The threat probability is the probability of a possible threat agent entering your environment.
Assign a criticality factor (CF) (1 lowest – 10 highest). The criticality factor is the level of potential exploit of the threat to an asset.
Rank the effort (E) (1 lowest – 10 highest). The effort represents the skills required for an attacker to take advantage of the exploit.
Determine the risk factor (RF). This factor is the criticality factor divided by effort.
Determine the threat frequency level using the equation (TP × RF).
Rank the vulnerability factor (VF) (1 lowest – 10 highest). Decide how big of a risk the vulnerability will be to an asset.
Determine the asset priority (AP) (1 lowest – 10 highest). Determine the asset priority ranking of each company asset based on the following criteria. Asset valuation is an involved process and can take time to perfect. For more information about asset valuation, see references on this subject at the end of this chapter. Prioritizing your organization's assets is crucial to determining how many assets can be secured with the available budget.

To help you formulate a list of prioritized assets, research answers to the following questions on each asset based on the environment in your organization:
- What is the value of the asset to the company?
- How much does the asset cost to maintain or protect?
- How much does the asset make in profits for the company?
- How much would the asset be worth to the competition?
- How much would the asset cost to recreate or recover?
- How much did the asset cost to acquire or develop?
Determine the impact factor (IF) using the equation (VF × AP).
Determine the exposure factor (EF) using the equation (Threat Frequency Level × Impact Factor ÷ 1,000). The exposure factor is expressed as a percentage to calculate single loss expectancy (SLE) in the steps that continue under Table 3.2.

The two-part formulation process to produce security risk statements has the advantage of coupling the potential consequences to an asset with the observable (and potentially controllable) conditions within your organization that currently exist. Alternative approaches in which the team focuses only on identifying security risk conditions may require the team to retrace the risk condition later in the security risk analysis process when security risk management planning strategies are created.

Note Security risk statements are not pure “if-then” statements; rather, they are statements of fact exploring the possible but unrealized consequences of a risk.

It may be helpful to consider hypothetical “if-then” statements to weigh alternatives and formulate plans using decision trees. However, your goal during the security risk identification phase is simply to identify as many security risks as possible. Defer how to analyze and manage them until later on in the process.

The security risk statement that you create must include conditions and consequences. As part of a thorough security risk analysis, team members should look for similarities and natural groupings of security issue conditions, and then retrace the relationships of each to seek a common underlying root cause. It is also valuable to retrace the relationships downstream from the root cause of the condition after it is known, and examine effects on the assets outside the organization. This information will provide an appreciation for the total losses or missed opportunities associated with the security threat.

During security risk identification, it is not uncommon for the same condition to have multiple consequences associated with it. However, the reverse also may be true—there may be several conditions that all produce the same consequence. Sometimes the consequence of a security risk identified in one area of the organization may become a risk condition in another. These situations should be recorded so that appropriate decisions can be made during security risk analysis and planning to take into account dependencies and relationships between the security risks.

Depending on the relationships of the security risks in your organization, mitigating one risk may result in mitigating an entire group of dependent risks and, in this way, change the overall risk profile for your organization. Documenting these relationships early during the security risk identification phase can provide useful information for guiding effective security risk planning that is flexible, comprehensive, and efficient at examining resources to address root or downstream causes. For the most important security risks, the benefits of capturing such additional information at the identification step should be balanced against rapidly moving through the subsequent analysis and prioritization, and then re-examining dependencies and root causes during the planning phase.

Valuing Assets in Your Organization

Determining the monetary value of an asset is an important part of risk management. Business managers often rely on the value of an asset to guide them in determining how much money and time should be spent securing it. Many organizations maintain a list of asset values as part of their disaster recovery plans. Using the following valuation model will help your organization to determine how to prioritize your assets as detailed in Step 8 of the quantitative analysis.

To assign a value to an asset appropriately, calculate the following three primary factors:

The overall value of the asset to your organization. Calculate or estimate the asset’s value in direct financial terms. For example, if you have an e-commerce Web site that typically runs seven days a week, 24 hours a day, and it generates an average of $2,000 per hour in revenue from customer orders, you can state with confidence that the annual value of the Web site in terms of sales revenue is $17,520,000.
The immediate financial impact of losing the asset. If the same Web site becomes unavailable for six hours, the calculated exposure is 0.0685 percent a year. By multiplying this exposure percentage by the annual value of the asset, you can predict that the directly attributable losses in this case would be $12,000.
The indirect business impact of losing the asset. In this example, the company estimates that it would spend $10,000 in advertising to counteract the negative publicity from such an incident. Additionally, the company also estimates a loss of 0.1 percent of annual sales, or $17,520. By combining the extra advertising expenses and the loss in annual sales revenue, you can predict a total of $27,520 in indirect losses in this case.

Table 3.1 Asset Valuation Example

Asset	Value	Exposure factor	Direct impact	Indirect impact
E-commerce Web site	$17,520,000 per year	Six hours per year, or 0.000685	$12,000	$27,520

Determine the single loss expectancy (SLE), which is the total amount of revenue that is lost from a single occurrence of the risk. The SLE is a dollar amount that is assigned to a single event that represents the company’s potential loss amount if a specific threat took place. Calculate the SLE by multiplying the asset value (AV) by the exposure factor (EF). The SLE is similar to the impact of a qualitative risk analysis.

Determine the SLE using the equation (AV × EF).

The exposure factor represents the percentage of loss that a realized threat could have on a certain asset. If a Web farm has an asset value of $150,000, and a fire results in damages worth an estimated 25 percent of its value, then the SLE in this case is $37,500. This figure is derived to be inserted into the ALE equation in step 3.
Determine the annual rate of occurrence (ARO). The ARO is the number of times that you reasonably expect the risk to occur during one year. To estimate the ARO, draw on your past experience and consult risk management experts, as well as security and business consultants. The ARO is similar to the probability of a qualitative risk analysis. The ARO range extends from 0 percent (never) to 100 percent (always).

For example, if a fire at the same company’s Web farm results in $37,500 in damages and the likelihood, or ARO, of a fire taking place has a ARO value of 0.1 (indicating once in ten years), then the ALE value in this case is $3,750 ($37,500 x 0.1 = $3,750).
Determine the annual loss expectancy (ALE). The ALE is the total amount of money that your organization will lose in one year if nothing is done to mitigate the risk. Calculate this value by multiplying the SLE and the ARO. The ALE is similar to the relative rank of a qualitative risk analysis. Determine the ALE using the equation (ARO × SLE).

The ALE provides a value that your company can work with to budget what it will cost to establish controls or safeguards to prevent this type of damage—in this case, $3,750 or less per year—and provide an adequate level of protection. It is important to quantify the real possibility of a risk and how much damage, in monetary terms, that the threat may cause to know how much can be spent to protect against the potential consequence of the threat.
Estimate the cost of countermeasures or safeguards using the following equation:

(ALE before countermeasure) – (ALE after countermeasure) – (annual cost of countermeasure) = value of safeguard to company (VSC)

For example, the ALE of the threat of an attacker bringing down a Web server is $12,000, and after the suggested safeguard is implemented the ALE is valued at $3,000. The annual cost of maintenance and operation of the safeguard is $650, so the value of this safeguard is $8,350 each year as expressed in the following equation: ($12,000 - $3,000 - $650 = $8,350).

The input items from the quantitative risk analyses provide clearly defined goals and results. The following short list defines what generally is derived from the results of the previous steps:

Assigned monetary values for assets
A comprehensive list of significant threats
The probability of each threat occurring
The loss potential for the company on a per-threat basis over 12 months
Recommended safeguards, countermeasures, and actions

Outputs

The minimum output from the security risk identification activities is a clear, unambiguous, consensus statement of the risks being faced by the security team that is documented as the security issues list. The security issues list, in tabular form, is the main input for the next phase of the Security Risk management process—analysis.

The security risk identification step frequently generates a large amount of other useful information, including the identification of root causes and downstream effects, affected parties, owners, and so forth.

It is considered a good practice to keep a tabular record of the security risk statements and the root cause and downstream effect information that the security team develops. Additional information for classifying the security risks by threat may also be helpful when using security risk information to build or use a security knowledge base if a well-defined taxonomy exists for your organization.

Other information that the security team may want to record during the risk identification process includes:

Constraints
Circumstances
Assumptions
Contributing factors
Dependencies among security risks
Related issues
Business asset owners
Team concerns

Analyzing and Prioritizing Security Risks

Security risk analysis and prioritization is the second large step in the security assessment process. Security risk analysis involves converting security risk data (threats, exploits, and vulnerabilities) into a form to facilitate decision-making. Security risk prioritization ensures that the security team members address the most important security risks first.

During this step, the security team examines the security issue list items produced in the security risk identification step to prioritize them and form a Security Action Plan.

In the Security Action Plan, your organization's security team can use the list of security issues to plan and commit resources to execute a specific strategy aimed at managing the issues in your environment.

The team can also identify which security issues, if any, are of such low priority for action that they may be dropped from the list. As this security implementation phase moves toward completion, and as the environment of your organization changes, security risk identification and security risk analysis must be repeated to validate the effectiveness of the Security Action Plan. New security risks may appear, and old security risks that no longer carry a sufficiently high priority may be removed, discounted, or “deactivated."

Goal

The primary goal of the security risk analysis step is to prioritize the security issues in the Security Action Plan to determine which ones warrant committing the organization’s resources to mitigate them.

Inputs

During the risk analysis process, the team will draw upon its own experience and information derived from other relevant sources regarding the security risk statements. Refer to your organization’s security policies and procedures, industry knowledge security databases, vulnerability analysis, security simulations, and the individual asset owners for information on how to transform the raw security risk statements into a prioritized master risk list.

Security Risk Analysis Activities

Many qualitative and quantitative techniques exist for accomplishing the prioritization in a Security Action Plan. An easy technique for security risk analysis is to use consensus team estimates derived from two widely accepted components of risk: probability and impact. These estimate values can then be multiplied together to calculate a single metric called risk exposure.

Security Risk Probability

Security risk probability is a measure of the likelihood that the state of affairs described in the risk condition portion of the security risk statement will actually occur. Your risk statement may include factors outside of time or money for your company, such as those described in the following portion of the risk statement:

"IF a Threat Agent uses a tool, technique, or method to exploit a Vulnerability..."

The threat using an exploit to take advantage of a vulnerability is the condition portion of the risk statement. For certain types of threats, there may not be an exploit or a known vulnerability, especially when the threat is a natural disaster.

Using a numerical value for risk probability is desirable for ranking risks. If the security risk probability is not greater than zero, then the threat does not pose an issue to security. If the probability is 100 percent, then the security risk is a certainty and may be a known issue.

Probabilities are notoriously difficult to estimate and apply, although industry or enterprise risk databases may be helpful in providing known probability estimates based on samples of large numbers of projects. However, because project teams can verbalize their experiences in natural language terms, it may be useful to map these terms back to numerical probability ranges as expressed in the following table.

Table 3.2 Risk Probability

Range	Calculation value	Expression	Score
1% through 14%	7%	Extremely unlikely	1
15% though 28%	21%	Low	2
28% through 42%	35%	Unlikely	3
43% through 57%	50%	50 – 50	4
58% through 72%	65%	Probable	5
73% through 86%	79%	Highly likely	6
87% through 99%	93%	Almost certain	7

The probability value used for calculation represents the midpoint of a range. With the aid of these mapping tables, an alternative method for quantifying probability is to map the probability range or natural language expression agreed upon by the team to a numerical score. When using a numerical score to represent security risk, it is necessary to use the same numerical score for all security risks for the prioritization process to work effectively.

No matter what technique is used for quantifying uncertainty, the team will also need to develop an approach for deriving a single value for risk probability that represents its consensus view regarding each risk.

Security Risk Impact

Risk impact is an estimate of the severity of the loss due to the adverse effects on the assets, or the magnitude of a loss resulting in an asset losing confidentiality, integrity, or availability. It should be a direct measure of the security consequence as defined in the second half of the security risk statement:

"...THEN a loss of (confidentiality, integrity, or availability) to an Asset may result in an impact."

Loss can be measured either in financial terms or with a subjective measurement scale with respect to the asset. If all security risk impacts can be expressed in financial terms, the use of financial value to quantify the magnitude of loss or opportunity cost has the advantage of being familiar to business sponsors. The financial impact might be long-term costs in operations and support, loss of market share, short-term costs in additional work, or opportunity cost.

In other situations, a subjective scale from 1 to 5 or 1 to 10 is more appropriate for measuring security risk impact. An example of when a subjective scale might be used would be a situation in which the appropriate net worth of the assets cannot be quickly determined. As long as all security risks within a Security Action Plan use the same units of measurement, simple prioritization techniques usually are good enough.

Table 3.3 Asset Loss Scoring System Example

Score	Monetary loss
1	Under $100
2	$100–$1,000
3	$1,000–$10,000
4	$10,000–$100,000
5	$100,000–$1,000,000
6	$1,000,000–$10 million
7	$10 million–$100 million
8	$100 million–$1 billion
9	$1 billion–$10 billion
10	Over $10 billion

The scoring system for estimating impact will vary among organizations and should reflect your organization’s values and policies. For example, a $10,000 monetary loss that is tolerable for one team or organization may be unacceptable for another. Scoring a catastrophic impact with an artificially high value such as 100 will ensure that a risk with even a very low probability will rise to the top of the risk list and remain there.

Security Risk Exposure

Risk exposure measures the overall security risk to the assets, combining information expressing the likelihood of actual loss with information expressing the magnitude of the potential loss into a single numerical estimate. The security team can then use the magnitude of risk exposure to rank security issues. In the simplest form of quantitative risk analysis, risk exposure is calculated by multiplying risk probability and impact.

When scores are used to quantify probability and impact, it is sometimes convenient to create a matrix that considers the possible combinations of scores and assigns them to low, medium, and high risk categories. Using a tripartite probability score, where 1 is low and 3 is high, and a tripartite impact score, where 1 is low and 3 is high, the results can be expressed in the form of a table where each cell is a possible value for risk exposure.

In this arrangement, it is easy to classify risks as low, medium, and high depending on their position within the diagonal bands of increasing score.

Table 3.4 Risk Scoring Matrix

Probability impact	Low = 1	Medium = 2	High = 3
High = 3	3	6	9
Medium = 2	2	4	6
Low = 1	1	2	3
Exposure ranges: Low =1 – 2; Medium =3 – 4; High = 6 – 9	Exposure ranges: Low =1 – 2; Medium =3 – 4; High = 6 – 9	Exposure ranges: Low =1 – 2; Medium =3 – 4; High = 6 – 9	Exposure ranges: Low =1 – 2; Medium =3 – 4; High = 6 – 9

The advantage of this tabular format is that it allows security risk levels to be included within status reports for sponsors and stakeholders using colors (red for the high risk zone in the upper right corner, green for low risk in the lower left corner, and yellow for medium levels of risk along the diagonal). An easy-to-understand, yet well-defined terminology improves communicating these values in that “high risk” is easier to comprehend than “high exposure.”

Additional Quantitative Techniques

Because the goals of security risk analysis are to prioritize security risks, drive a Security Action Plan, and drive decision-making regarding commitment of resources toward security management, your security team should select a method for prioritizing risks that is appropriate to the project, team, and stakeholders.

Some organizations benefit from the use of weighted, multiattribute techniques to factor in other components that the team wants to consider in the ranking process, such as required time frame, magnitude of potential opportunity gain, reliability of probability estimates, and physical or information asset valuation.

Selecting the “right” security risk analysis method or combination of methods depends on making the right tradeoff between the effort to perform the security risk analysis and making an incorrect or indefensible (to stakeholders) prioritization choice in the Security Action Plan. Security risk analysis should be undertaken to support prioritization that drives decision-making and should never become analysis for the sake of analysis.

The results from quantitative or semi-quantitative approaches to security risk prioritization should be evaluated within the context of business guidelines, policies and procedures, data, and technology infrastructures. A semi-quantitative approach begins with some sort of qualitative measures to enable companies to come up with quantifiable security measures.

Outputs

Security risk analysis provides your team with a prioritized security action list to guide you in security risk planning activities. Detailed security risk information, including conditions, conFtext, root causes, and the metrics used for prioritization (probability, impact, exposure), are often recorded for each risk in the risk statement form, which is described in detail later in this chapter.

Master Security Risk List

The list of key security risks for which an action plan must be created is defined in your Security Action Plan. The Security Action Plan identifies the condition causing the security risk, the potential adverse effect (consequence), and the criteria or information used for ranking the risk, such as its probability, impact, and exposure. An example master risk list using the two-factor (probability and impact) estimate approach is shown here.

Table 3.5 Master Risk List and Prioritization Example

Priority	Condition	Consequence	Probability	Impact	Exposure
1	Virus infecting e-commerce Web site	Six hours to rebuild server.	80%	3	2.4
2	No coding standards for new programming language	Ship with potentially more security vulnerabilities.	45%	2	0.9
3	No written specification	Some product security features not implemented	30%	2	0.6

Exposure is calculated as probability x impact. Low impact = 1, medium impact = 2, and high impact = 3.

The master security risk list is the compilation of all security risk assessment information. It is a living document that forms the basis for the ongoing security risk management process and should be kept up to date throughout the IT life cycle, which includes evaluating, planning, building, deploying, and operating.

The security master risk list is the fundamental document for supporting proactive or reactive risk management. It enables team decision-making by providing a basis for:

Prioritizing effort
Identifying critical actions
Highlighting dependencies

The method that is used to calculate the exposure rendered by a risk should be documented carefully in the risk management plan, and care should be taken to ensure that the calculations accurately capture the intentions of the team, weighing the importance of the different factors.

To identify threats to assets, you perform risk analyses. For each threat that you identify, create a risk statement. Risk statements combine information about a threat with information about the impact of the threat, should it occur.

Table 3.6 Master Security Risk List Contents

Item	Purpose	Status
Security risk statement	Clearly articulate risk	Required
Probability	Quantify likelihood of threat occurrence	Required
Impact	Quantify severity of loss or magnitude of opportunity cost	Required
Ranking criterion	Single measure of importance	Required
Priority (rank)	Prioritize actions	Required
Owner	Ensure follow through on risk action plans	Required
Mitigation plan	Describe preventative measures	Required
Contingency plan and triggers	Describe corrective measures	Required
Root causes	Guide effective intervention planning	Required
Downstream effects	Ensure appropriate impact estimates	Optional
Context	Document background information to capture intent of team in surfacing risk	Optional
Time to implementation	Capture importance that risk controls are implemented within a certain time frame	Optional

Risk Statement Form

When analyzing each individual security risk, or during security planning activities related to a specific threat, exploit, or vulnerability, it is convenient to view all of the information on that security risk in a document view, called the security risk statement form. For more details on the processes of a security project, see the Microsoft Solution for Security Services Guide.

A list of security risk statements typically contains the fields from the master security risk list created during the identification and assessment phases and may be augmented with additional information needed by the team during the security risk management process. It may be easier to treat the list of security risk statements as a separate document from the master risk list if the risks will be assigned to the security team for follow-up actions. Some of the information that the team should consider when developing a risk statement form is listed in the following table.

Table 3.7 Risk Statement Form

Item	Purpose
Security risk identifier	The name that the team uses to identify risk uniquely for reporting and tracking purposes.
Security risk source	A broad classification of the underlying area from which the security risk originates. Used to identify areas where recurrent root causes of the security risk should be sought.
Security risk condition (threat/exploit)	A phrase describing the existing condition that might lead to a loss. This phrase forms the first part of a security risk statement.
Risk consequences (vulnerability/impact to asset)	A phrase describing the loss that would occur if a risk produces a consequence. This phrase forms the second part of a security risk statement.
Security risk probability	A probability greater than zero and less than 100 percent that represents the likelihood that a risk condition will actually occur, resulting in a loss.
Asset impact classification	A broad classification of the type of impact that a risk might produce.
Asset exposure	The overall threat of the risk, balancing the likelihood of actual loss with the magnitude of the potential loss. The team uses risk exposure to rate and rank risks. Exposure is calculated by multiplying risk probability and impact.
Risk context	A paragraph containing additional background information that helps to clarify the security risk situation.
Related security risks	A list of risk identifiers that the team uses to track interdependent risks.

Top Security Risks List

Security risk analysis weighs the threat of each security risk to help the security team decide which of the issues merit action. Because managing security and the planning associated with it takes time and effort away from other activities, it is important for the security team to do what is absolutely necessary to protect the most valuable assets.

A simple but effective technique for monitoring the security risks is to create a top security risks list of the major security issues. The top security risks list may then be made externally visible to all stakeholders for use in other active IT projects where security may be affected.

Your organization has to determine what goes on the top security risks list based on several factors, including time, resources, and assets. After you have selected a number of major security risks that must be managed, you must allocate team resources to develop plans around them.

After ranking the security risks, the team should focus on a security risk management strategy and how to incorporate the security action plans into the overall security assessment plan.

Deactivating Security Risks

Security risks may be deactivated or classified as inactive so that the team can concentrate on other issues that require more proactive management. Classifying a security risk as inactive means that the assessment team has decided that it is not worth the effort needed to track that particular threat at this particular time. The decision to deactivate a security risk is taken during the security risk analysis.

Some security risks are deactivated because their threat probability is effectively zero and likely to remain so because they have extremely unlikely conditions. Other security risks are deactivated because their impact to the assets is below the threshold where it is worth the effort to plan a proactive mitigation or reactive contingency strategy. In these cases, it is simply more cost-effective to suffer the potential consequences of these security risks.

It may not be advisable to deactivate security risks above this asset impact threshold even if their exposure is low, unless the security team is confident that the probability (and hence the exposure) will remain low in all foreseeable circumstances. Remember that deactivating a security risk is not the same as resolving one. A deactivated security risk may reappear under certain conditions, and the security team may choose to reclassify the risk as active and reinitiate security risk assessment activities.

Security Risk Tracking, Planning, Scheduling, and Reporting

Tracking the security risks that have been identified in the Security Action Plan and then implementing a plan, a schedule, and a reporting process to remediate them are the next steps in the process. Based on the priorities identified in the previous step, the team will make changes proactively by modifying the technology infrastructure and implementing new security procedures and processes.

When a risk exists that cannot be proactively managed, a reactive plan is generated that is executed when an event is triggered. After the plans are created, an implementation schedule for the proposed modifications is produced. Finally, team members are assigned various remediation tasks to address.

Scheduling involves the integration of the tasks required to implement the security action plans into the assessment project schedule by assigning them to individuals and actively tracking their status.

Reporting consists of redefining risks that have changed because the project and processes have changed in scope or definition. This type of reporting is also known as risk change management. Reporting also consists of closing security risks from the top number of managed risks within a project. The following figure depicts the overall process of risk tracking, planning, scheduling, and reporting.

Figure 3.3 Risk tracking , planning , scheduling , and reporting

Goals

The main goal of the security risk planning and scheduling step is to develop detailed action plans for controlling the top security risks identified during the security risk analysis, and then to integrate them with the standard project management processes to ensure that they are completed.

Inputs

Security risk planning should be tightly integrated into the standard project planning processes and infrastructure. It is important to note that there are risks associated with the security assessment project itself, but these risks are different from the actual security risks themselves. The implementation of security action plans carries risk to the overall project and should be managed using the methodology of the MSF Risk Management Discipline. Project risks to implementing security action plans usually include time, money, and resources.

Inputs to the security risk planning process include not only the master security risk list, top security risks list, and information from the security knowledge base, but also the security action plans and security implementation schedules.

Planning Activities

When developing plans to reduce asset exposure, you should:

Focus on high-exposure security risks
Address the threat condition (threat, exploits) to reduce the probability
Look for root causes of the security issue as opposed to symptoms
Address the asset consequences (vulnerability and asset) to minimize the asset impact
Determine the root cause of the security issue, and then look for similar situations arising from the same cause that may affect the same or other assets
Be aware of dependencies and interactions from threats, exploits, and vulnerabilities among security risks

There are several planning approaches to reducing different project risk conditions:

For project risks that the team can control, apply the team resources needed to reduce the probability of the threat condition. This approach is proactive security risk management.
For project risks outside the control of the team, find a potential workaround or transfer (escalate) the security risk to individuals who have the authority to intervene.
For project risks outside the control of the team that cannot be transferred or proactively managed, the team should develop plans to minimize the impact to or the loss of the asset. This approach is reactive security risk management.

Security Action Planning

There are six primary approaches to security action planning. Your team should consider the questions associated with each approach, listed here in brief, when formulating your security risk action plan. Each approach is defined in greater detail in the following subsections.

Research. Does the security team know enough about this security risk? Do you need to further study the threat, exploit, vulnerability, or assets to better determine the characteristics of these components before deciding on an action?
Accept. Are you willing to accept the risk and do nothing proactive, with the exception of making contingency plans? You might consider accepting a risk if the ALE value for the asset is less than the value of the asset, and if the impact on business is low. Can your organization live with the consequences if the security risk actually occurs?
Avoid. Is there a way to avoid risk by eliminating the source of the risk or an asset’s exposure to the risk? This approach is an extreme reaction to risk and should only be done when the impact of the risk outweighs the benefit that is gained from the asset. Can your organization avoid risks by changing the scope of the implementation project?
Transfer. Is it possible for you to transfer risk by partially shifting the responsibility for the risk to another party, such as an insurance or managed services company? Transferring risk is becoming an increasingly important strategy for security. Can your organization avoid the security risk by transferring it to another group, team, individual, or external organization?
Mitigation. Can you mitigate risk by proactively changing the asset’s exposure to the risk or changing your organization’s reliance on the asset? Consider a risk mitigation strategy if the ALE is less than the value of the asset and you can take proactive actions in advance. Mitigation is the primary risk management strategy. Can you do anything to reduce the threat probability or asset impact of the security risk?
Contingency planning. Can the impact be reduced through a planned incident response? Properly constructed contingency plans will diminish the impact when a risk becomes an issue or an incident. After the security incident, a trigger can be used to properly execute a contingency plan.

Research

Much of the risk in security projects is related to uncertainties surrounding incomplete information. Security risks that are related to a lack of knowledge may often be resolved or managed effectively by learning more about the threat, exploit, vulnerabilities, or the asset itself before proceeding.

For example, a team may choose to pursue a vulnerability assessment or conduct a security drill to learn more about the environment or the team’s skills in reacting to a security breach before completing the security implementation plan. If the decision by the team is to perform research, then the Security Action Plan should include an appropriate research proposal, including the areas to be tested and the issues to be answered, such as staffing and any required equipment.

Accept

Some security risks, specifically threats that are related to natural disasters, are such that it is simply not feasible to intervene with effective preventative or corrective measures. Therefore, the security team may elect to simply accept the security issue. However, proactive mitigation or reactive contingency plans should still be developed. An ongoing commitment to monitoring a security risk should have appropriate resources and tracking metrics established.

Note Acceptance is not a “do-nothing” strategy. Your organization's Security Action Plan should include a documented rationale for why the team has elected to accept the risk.

Avoid

A security risk may be identified as one that can most easily be controlled by changing the scope of the assessment. Changing the scope of the assessment in such a fashion to “eliminate” the security risk all together is called the avoidance technique. In these cases, the Security Action Plan should include documentation of the rationale for such decisions, and the security implementation plan should be updated with any needed design changes or scope change processes.

Transfer

Sometimes it is possible for a security risk to be transferred to another entity outside of the organization for management. Examples in which a security risk is transferred include:

Insurance
Using external consultants with greater expertise
Outsourcing services

Transferring the security risk does not mean that a risk has been eliminated. In general, a transfer strategy will generate new security risks that still require proactive management, but transferring the risk will reduce the threat to a more acceptable level. For instance, outsourcing the IT infrastructure may transfer security risks outside of the security team but may introduce new security risks with respect to confidentiality of the assets that your organization is trying to protect.

Mitigation

Security risk mitigation involves taking proactive action to either prevent a security risk from occurring or reduce the impact or consequences to an acceptable level. Proactively managing security risk through mitigation differs from the avoidance approach because mitigation focuses on prevention and minimization of threats to acceptable levels, whereas security risk avoidance changes the scope of the assessment to prevent activities that involve unacceptable risk from taking place.

The main goal of security risk mitigation is to reduce the probability of threat occurrence. For example, using a strong password policy will reduce the probability of an external user's finding out a password to access the payroll system.

Contingency Planning

Security risk contingency planning involves creation of one or more incident response plans that can be activated in case efforts to prevent an attack fail. It is good practice to create contingency plans for all security risks, including those that have mitigation plans. The reason for this approach is simple: No matter how well the organization develops proactive security plans, an unknown threat, exploit, or vulnerability that can harm an asset may still exist.

Security contingency planning must address what to do if the threat occurs, and it must focus on the consequence and how to minimize the asset impact. Your team should create incident response plans and business resumption plans to ensure that you can react effectively during and after an attack.

You can establish trigger values for contingency plans based on the type of threat, exploit, or vulnerability that may be encountered. For security, a trigger is usually an event, and there has to be a way of capturing that event and notifying the appropriate response team to put the contingency plans into action.

There are two types of contingency plan triggers:

Point-in-time triggers. Point-in-time triggers are built around dates, generally the latest date by which something has to take place. Dates may be set according to organizational or legal guidelines that prescribe when certain security measures must occur.
Threshold triggers. Threshold triggers rely on things that can be measured or counted. For example, an audited event that is captured by an intrusion detection system may warrant some examination and the possible activation of a contingency plan.

It is important for your security team to agree with other teams in your organization on contingency plan triggers and their associated metrics so that there is no delay in executing the contingency plans.

Scheduling Activities

Scheduling security risk management and control activities does not differ from the standard approach recommended by MSF to scheduling project activities in general. It is important that the security team understand that security remediation or control activities are an expected part of security risk assessment and management.

Outputs

The output from producing the Security Action Plan should include both proactive and reactive security management plans using one of the six approaches discussed earlier: research, acceptance, avoidance, transfer, mitigation, or the development of contingency plans. The specific tasks to implement these security plans should be integrated into the standard security implementation schedules. If there are any changes to the technical environment, they should be documented in a functional specification.

Your Security Action Plan and schedule should account for adjustments in committed resources and scope, resulting in a set of security action items that specify the individual tasks to be completed by security team members. The master security risk list should be updated to reflect the additional information included in the proactive (mitigation) and reactive contingency plans. It is convenient to summarize the security risk management plans into a single document view in the security risk action form.

Updating the Security Implementation Schedule and Security Implementation Plan

Your security implementation plan must include both proactive and reactive plans. When updating your security implementation plan, consider the following:

The risk conditions, including the probability of risk occurrence and impact

Changing conditions, such as increased probability of a risk occurring or a decreased financial impact of a risk, will require the team to update the risk management plan
The effectiveness of the mitigation effort

The team may find that some of its mitigation efforts are ineffective. Such efforts are often ineffective because a technical policy that conflicts with business processes is implemented. Employees sometimes subvert the technical policy by working around it to achieve their business goals.
The effectiveness of contingency plans and triggers

Over time, security risks that are identified in the risk management plan will occur. After the security incident, determine how effective the contingency plans were, and whether the triggers for initiating responses were effective.

Your team should monitor security risks in the following three time frames:

Real-time. Use applications such as intrusion detection software to continuously monitor computers and network devices, and to make predetermined decisions based on the risk.
Periodic. Evaluate risk on a regularly scheduled basis, such as bimonthly or quarterly.
Ad hoc. Evaluate risk at nonscheduled intervals. Ad hoc monitoring is often done in response to a major security incident or change to the network.

Security Risk Remediation Development

The development of countermeasures and operational procedures are essential to the security strategy for your organization. Security risks can be proactively managed either through a technology hardening process or by developing organization-wide policies.

Often a default installation of an operating system, application, or database has security settings relaxed to simplify matters for the IT administrator or software developer. Prior to a production deployment of these technologies, the technology being deployed must be a part of a “hardening process.” For details on hardening member servers and specific server roles, see Chapter 6, "Hardening the Base Windows 2000 Server," and Chapter 7, "Hardening Specific Server Roles," in this guide.

The server hardening process may involve the removal of default security settings and unnecessary software components. IT personnel should also stay current on known technology vulnerabilities and current exploits to install the latest releases of software and security hotfixes.

The security strategy development process also includes the development of systems, policies, and procedures for the tracking and reporting of unrealized security risks. These efforts will help ensure that the preventative measures in the technology infrastructure are working, as well as validate the effectiveness of any new policies and procedures.

There also should be a reporting system in place to capture suspicious events or potential threats that require immediate attention. In addition to an automated system for security risk tracking, a manual process can also be used. Tracking security risks allows the project team to make adjustments to plans to accommodate new security risks.

Tracking is the monitoring function of the risk action plan. Tracking is essential to implementing security action plans effectively. Tracking ensures that preventative measures or contingency plans are completed in a timely fashion and within project resource constraints. During risk tracking, the principal activity performed by the team is monitoring risk metrics and ensuring that events are triggered so that planned risk actions go into effect.

Goals

The goal of the remediation development process is to document necessary architectural changes as well as any new processes or changes in procedure.

Inputs

The principal inputs to the security risk remediation development process are the security risk plans that contain the specific security mitigation and contingency plans that specify the threats, exploits, and vulnerabilities for your organization's security risks. Remediation development also requires that systems and processes are developed to monitor the identified triggers for the contingency plans that may be executed.

Development Activities

The development activities in the security risk remediation process are similar to the development activities in a typical infrastructure deployment project—for example, the development of methods for change management for computer system patches. Design changes to the infrastructure must be documented in a functional specification, and policies and procedures may have to be modified to accommodate the new security requirements. During this process, if new monitoring and auditing systems are implemented, the design and management of those systems should be specified, as well.

Examples of project metrics that might be assigned point-in-time trigger metrics and continuously tracked include:

Unresolved open security bulletins for an application, service, or operating system
Average overtime hours logged per week by infrastructure engineers
The number of requirement revisions or change management requests per week

Risk status reporting procedures should also be developed at this phase. Risk reporting should operate on two levels: for the team itself and for external reporting to the project board.

For the security team, regular risk status reports should consider the following four possible risk management situations that may apply to each risk:

A risk is resolved, completing the risk action plan. All resolved risk should be documented as closed and archived in the Security Action Plan.
Risk actions are consistent and on schedule with the risk management plan.
Some risk actions are at variance to the risk management plan, in which case corrective measures should be defined and implemented.
The risk situation has changed significantly with respect to one or more risks, and therefore the risk action plan should be reformulated.

For external reporting to the project board and other project stakeholders, the team should report the top risks and then summarize the status of risk management actions. It is also useful to show the previous ranking of risks, and the number of times that each risk has been in the top risk list.

As the project team takes actions to manage risks, the total risk exposure for the project should begin to approach acceptable levels.

Outputs

The output of the remediation phase is the specification of any security changes that must be updated in the following places:

Functional specification
Operational policies and procedures
Updated security implementation plans
Updated security implementation schedules

Security Remediation Testing

The security remediation testing step is designed to ensure that the effectiveness of the security plans are tested. The team should actively perform activities related to the testing of both the proactive and reactive strategies (countermeasures and procedures) to determine the effectiveness of the Security Action Plan.

To measure the effectiveness of newly developed countermeasures, policies, and procedures, you should examine each risk that they are designed to address, and then test the associated strategy for each risk with respect to threats, exploits, vulnerabilities, and assets in your organization.

It may be necessary, based on security risk remediation testing, to modify your Security Action Plan to improve its effectiveness, validity, and responsiveness to security trigger events.

The results and lessons learned from the execution of the security test plans are then incorporated into a testing document to become part of the organization’s security knowledge base. It is important to capture as much information as possible during testing to determine the efficacy of these plans.

Goals

The goal of the security remediation testing process is to test the effectiveness of the various security plans that the project team has created for the top security risks. The Security Action Plan should evaluate and test the following:

Contingency and mitigation plan effectiveness.
Security metrics associated with contingency plan triggers or events.
Technology countermeasures. These countermeasures may require a second vulnerability assessment to determine whether they have been implemented correctly.

Inputs

The inputs to the security risk control process are the security action forms that detail the activities to be carried out by project team members to help address each security issue. Testing results should document the effectiveness of the proactive and reactive plans to determine whether they are appropriate to your organization’s security requirements.

Testing Activities

Security remediation testing activities should measure the effectiveness of each countermeasure and incident plan developed. It is important to maintain continuous security risk remediation testing to detect any new secondary security risks that may appear because of new countermeasures.

Outputs

The output from the security remediation testing step is a result document or “issue database” that can help document progress toward completing the implementation of the security plans for your organization. It is helpful for the testing team to also summarize which security strategies worked, which did not work, and the effectiveness of newly created polices and procedures.

Capturing Security Knowledge

The knowledge obtained during the security assessment and implementation process should be captured for future use. This phase is the sixth and final phase of the security risk assessment process, and one that adds a strategic, enterprise, or organizational perspective to the security risk management activities.

Of primary importance is that the countermeasures, policies, and procedures that were developed during this security assessment are captured for reuse by future project teams. As your organization embarks on future IT initiatives, those projects can use the knowledge gained from the assessment to ensure that the new solutions that are implemented are secure.

The learning from your security risk assessment should be captured in a timely format to provide the most up to date and current information. Capturing security knowledge focuses on three key objectives:

Capturing lessons learned, especially concerning security risk identification and successful mitigation strategies, for the benefit of other teams, thus contributing to the security knowledge base.
Increasing the effectiveness of operational readiness in terms of the ability of your organization to execute incident response plans and reuse them in other areas.
Improving the security risk assessment process by capturing feedback from the team.

Capturing Security Risk Learning

Security risk classification is a powerful means of ensuring that lessons learned from previous experience are made available to teams performing future security risk assessments. Three key aspects of learning are often recorded using the following risk classifications:

New risks. If a team encounters an issue that had not been identified previously as a security risk, it should review whether any signs (threats, exploits, vulnerabilities, or other indicators) may have predicted the security risk. It may be that the existing security risk lists need to be updated to help with future identification of the security risk condition. Alternatively, the team may have identified a new security risk that should be added to the existing security knowledge base.
Successful mitigation strategies. Capture the experience of both successful and unsuccessful strategies to mitigate security risks. The use of a standard security risk classification provides a meaningful way to group related risks so that teams can easily find details of security risk management strategies that have been applied successfully in the past.
Successful contingency strategies. If a contingency plan works by protecting against a specific type of vulnerability for one asset, it may be useful in protecting another asset.

Managing Security Risk Learning

Organizations using security risk management techniques often find that they need to create a structured approach to managing security risk. To facilitate this need successfully, the following three conditions should be met:

Share responsibility with individuals on your security team by giving ownership of specific security risk classification areas with approval to make changes. The decision regarding who should be given ownership is related to the type of asset and the classification of the asset.
Balance your security risk classifications and the need for comprehensive countermeasures against complexity and usability. Sometimes creating different risk classifications for different project types can improve usability dramatically.
Maintain your security knowledge base to account for security risk classifications, definitions, testing, monitoring effectiveness criteria, and metrics to capture user and operational experience of the new security measures.

Context-Specific Security Risk Classifications

Security risk identification can be refined by developing risk classifications for specific solutions implementations. For example, in an application development project there may be specific security risk classifications for that project versus the security risk classifications for an infrastructure deployment project. As more experience is gained within the security context, security policies and procedures can be made more specific and associated with successful mitigation strategies.

Security Knowledge Base

The security knowledge base is either a formal or an informal mechanism used to archive lessons and assist in future security risk assessment. Without some form of a knowledge base, your organization may have difficulty adopting a proactive approach to security management.

If there is a known set of threats, exploits, and vulnerabilities captured in this knowledge base, it will be easier to develop a mitigation plan against them because of the captured research. The security knowledge base differs from the security risk management database, which is used to store and track individual security risk items, plans, and status.

Developing Knowledge Management for Security Risks

The security risk knowledge base is the key driver of continual improvement in security risk management.

At first, your organization's security project and process teams will likely not have a knowledge base. Teams must start fresh every time they undertake a security risk assessment. In this environment, the approach to security risk management is typically reactive, after a breach or some event that triggers a project. In this situation, the goal is for your organization to transition to the next higher level of active security risk management.

Later, your organization may have developed an informal security knowledge base, using the implicit learning gained by more experienced members who are either familiar with or have subject matter expertise on the security issues with respect to people, process, and technology. The development of such a knowledge base is often achieved by implementing a security board. This approach encourages active security risk assessment management and might lead to proactive management through the introduction of security policies.

Reaching the first development level of the knowledge base comes through providing a more structured approach to security risk identification. With the formal capturing and indexing of security issues, your organization will be capable of much more proactive management as the underlying causes of security risks start to be identified.

Finally, mature organizations record not only the indicators likely to lead to security risks, but also the strategies adopted to manage those security risks and their success rates. With this form of knowledge base, the security identification and planning steps of the security risk process can be based on the shared experience of many teams, and your organization can start to optimize the costs of security risk management.

When contemplating how to implement a security risk knowledge base for your organization, experience has shown that:

The value of the security risk knowledge base increases as more of the work becomes repetitive (such as focusing on other projects that affect security or ongoing operational processes).
When your organization is performing a similar security review, a less complex knowledge base is easier to maintain.
Security risk management should not become an automatic process that obviates the need for the team to think about security risks. Even in repetitive situations, the business environment, the skills of attackers, and the technology are always changing. The security team must assess the appropriate security risk management strategies for its environment based on the people, processes, and technology that are in place.

Summary

This chapter explained proven practices derived from security analysis methods and processes formulated in MSF and MOF. It detailed the processes used in the SRMD to determine the cost of protecting the assets in your organization. Finally, it recommended steps for forming a security team to create and execute security action plans to prevent and react to attacks against your organization's environment.

More Information

For information about MSF, see the Microsoft Solutions Framework Web site at www.microsoft.com/technet/itsolutions/msf/default.mspx.

For information about MOF, see the Microsoft Operations Framework Web site at www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Securing Windows 2000 Server

Chapter 3: Understanding the Security Risk Management Discipline

On This Page

Security Risk Management and Security Framework Practices

Assessment

Asset Assessment and Valuation

Security Risk Identification

Security Risk Analysis

Security Risk Tracking, Planning, and Scheduling

Development and Implementation

Security Risk Remediation Development

Security Risk Remediation Testing

Security Risk Learning

Operation

Reassessing New and Changed Assets and Security Risks

Stabilizing and Deploying New or Changed Countermeasures

Security Service Desk, Incident Management, and Problem Management Learning

Service Level, Financial, and Availability Management

Security Risk Management Framework

Overview

Creating Your Security Program Team

Assessment

Confidentiality

Integrity

Availability

Organizational Assessment

Threat Analysis

Vulnerability Assessment

Determining Possible Damage from an Attack

Determining Vulnerabilities or Weaknesses That an Attack Can Exploit

Security Risk Planning and Scheduling

Proactive Strategy

Reactive Strategy

Contingency Plan

Implementation

Simulation Attack Testing

Operation

Incident Response

Document and Learn

Implement Contingency Plans

Review Outcomes and Perform Simulations

Review and Adjust Policy Effectiveness

Security Risk Management Discipline

Identifying Security Risks

Goals

Inputs

Risk Identification Activities

Structured Approach

Threat Classification

Security Risk Statement

Valuing Assets in Your Organization

Outputs

Analyzing and Prioritizing Security Risks

Goal

Inputs

Security Risk Analysis Activities

Security Risk Probability

Security Risk Impact

Security Risk Exposure

Additional Quantitative Techniques

Outputs

Master Security Risk List

Risk Statement Form

Top Security Risks List

Deactivating Security Risks

Security Risk Tracking, Planning, Scheduling, and Reporting

Goals

Inputs

Planning Activities

Security Action Planning

Research

Accept

Avoid

Transfer

Mitigation

Contingency Planning

Scheduling Activities

Outputs

Updating the Security Implementation Schedule and Security Implementation Plan

Security Risk Remediation Development