Risk Management

The National Institute of Standards and Technology (NIST) says that risk management is “a complex, multifaceted activity that requires the involvement of the entire organization.”² Risk management (RM) helps an organization identify the risks that it faces. It also makes sure that organizations respond to risk in a cost-effective manner. Organizations use RM to support their business goals.

One of the main goals of RM is to protect the organization’s bottom line. When risk is realized, it negatively affects an organization’s profits. RM helps an organization align its information security practices to its business goals. It makes sure that an organization spends its limited resources wisely and in ways that enhance business goals. An organization uses RM to plan and prioritize its information security activities.

For example, suppose an organization has a database that holds customer data. The database is critical to the organization’s business. It uses the information in the database to develop products for its customers. The database also holds marketing information. The organization would be harmed if it did not have access to this resource. Its development and marketing activities would be negatively impacted. The organization must protect this database.

A risk analysis shows that the database is at risk because system administrators share a single administrator account with a weak password to access the database. This is a vulnerability. Therefore, the database is open to attack. If it is attacked, the confidentiality and availability of data on the resource are compromised. Attackers could steal this data. They also could harm the database so that the organization could not use it. The risk analysis shows that the vulnerability (a single administrator account with a weak password), together with the threat (attackers) is very critical given the organization’s business.

As part of its RM function, the organization must review the potential impact of this risk. The cost of a data breach could be quite high given the type of data in the customer database. The organization might have to notify its customers about the breach. It also might have to report the breach to its regulatory authorities. Those agencies could fine the organization for failing to secure its data. Its customers could sue it as well. The organization could lose current and future customers. It also faces its own operational issues if that database is not available for a certain period.

Once the organization identifies the risk and potential impact, it can take steps to mitigate it. In this example, the organization must reduce the risk posed by a single shared account with a weak password. It can require its system administrators to use different accounts, with multifactor authentication, to access this critical resource. It also can configure its systems to enforce authentication requirements technically. Finally, it can make sure that it backs up its customer data properly. In this short example, the RM process identified a risk to a resource. It offered different options for addressing the risk. In addressing the risk the organization was able to secure an important resource. Therefore, it was able to protect its business operations and bottom line.

FYI

Each step in the RM process supports an organization’s business goals. The most basic RM process includes the following steps:

• Risk assessment—Identify the threats and vulnerabilities to the organization’s IT resources. Determine the impact of those threats and vulnerabilities.
• Risk response—Use policies and controls to respond to risk. An organization responds to risk according to its business strategy.
• Employee training—Train employees on known threats and vulnerabilities. Training can help avoid risk.
• Continuous monitoring—Monitor the organization’s policies and controls for continued effectiveness. Update policies and controls that are not effective.

FIGURE 14-1 shows this basic RM process.

The RM process and information learned during that process can form the basis for an organization’s contingency plans. In a basic sense, contingency plans are an organization’s response to very narrow risk assessments. For example, BC and DR plans are detailed contingency plans that respond to the risks of natural or man-made disasters. These risks are discovered during the RM process.

Risk Assessment Process

A risk assessment (RA) identifies the threats and vulnerabilities to IT resources. It reviews the probability of those threats and vulnerabilities actually happening. This is called a realized risk. Then the RA reviews the potential harm from a realized risk. Finally, the RA identifies policies and controls that could respond to the potential risk. Risk response is the action taken by an organization to reduce realized risk to an acceptable level. The amount of risk that is left over after realized risk is reduced is called residual risk.

The RA is a tool in the risk management process that provides executive management with the data that it needs to make smart decisions about information security controls. Without an RA, the executive management team has no way to know if the controls and policies that it implements are needed or cost effective. For example, an organization could spend a lot of money implementing a control to respond to a perceived threat. Without an RA, the organization does not know whether the cost of the control is reasonable given the probability and potential of the underlying risk. The organization may be making a poor decision if it spends more money to respond to a risk than the actual cost of the realized risk itself. An RA helps the organization know where to spend money to respond to and mitigate information security risk.

There are several different methods for conducting a risk assessment. Some of them will be discussed in this chapter. In general, all methodologies have similar basic steps. The basic steps in a RA are:

• Inventory the assets included in the assessment
• Identify threats and vulnerabilities to those assets
• Categorize likelihood of occurrence and potential loss
• Document where controls are needed

Risk Assessment Team

An RA team must include people in several different roles throughout an organization. Even though the RA focuses on risks to IT systems, it is not sufficient to only include IT personnel on the team. IT personnel may not know about all of the organization’s critical business processes. For the same reason, it is not enough to include only business personnel on an RA team. Business personnel may not appreciate the technology processes that support business operations. The RA team members should represent all areas involved in a business process workflow.

FYI

RA team members should include:

• Business personnel—These people are responsible for business process operations. They know the steps that must be completed in each business process. They also can describe how they use IT systems to accomplish their job duties.
• IT personnel—These people run the organization’s various IT systems. This group also might include the IT system owner. These personnel understand how their IT systems work and are responsible for maintaining those resources. They also would be responsible for implementing any changes to IT systems.
• Information security managers—These people run the organization’s information security program. They have knowledge about information security threats and vulnerabilities. They also know how threats and vulnerabilities can be mitigated.
• Human resources personnel—These people understand how to deal with people issues. They can offer advice and input on how to address human-based threats and vulnerabilities. They also will be able to assist with awareness training after the RA is complete.
• Executive management—These people make sure that the RA team has the support and resources that it needs to complete the assessment. They can hold business units accountable for participating in the assessment. They also can make sure that the RA remains properly scoped to its original goal.

Members of the team must be objective. They must be willing to take a hard look at an organization’s business objectives and processes for risk potential. They must do the same thing for IT resources. Members of the team must avoid conflicts of interest. In the RA context, a conflict of interest is a situation where a member’s responsibilities as part of the RA team might conflict with his or her job responsibilities. A conflict of interest prevents the team member from meeting his or her RA responsibilities.

In many cases, team members are picked because they work in a certain area that is being reviewed as part of an assessment. These members are helpful in making sure that the whole RA team understands how these areas work. However, these members may not be as objective in assessing vulnerabilities, threats, and risks in their areas. These team members will have to work hard to be objective throughout the whole RA process. An organization must remove members from the RA team if they are unable to be objective.

Some organizations hire consultants to help with an RA. Consultants are not employees of the organization. They help in a risk analysis by bringing objectivity to the team. They also help by bringing risk analysis expertise to the process. They can hurt the team if they do not quickly learn how an organization’s business processes and IT systems work. They also can hurt the team if they are not respectful of an organization’s culture.

An RA team is responsible for collecting information about assets and risks. It is also responsible for reporting the assessment results to an organization’s executive management.

Identifying Assets, Vulnerabilities, and Threats

An RA must be narrowly scoped. Otherwise, it can grow too large for the RA team to manage. If it is too large, the team will have a hard time determining the risks that the organization must address. A good practice is to conduct a focused RA. Rather than doing an assessment of the organization’s whole IT infrastructure, the RA team should review one infrastructure component at a time. This way the team can better manage the RA and produce better overall results.

The scope of the RA must be clearly stated in an RA project plan. RA team members can refer back to the project plan anytime they are asked to consider a new system or process as part of the RA. If the new system or process is not within the scope of the project plan, then the team should not consider it. Executive management must approve the project plan before the RA team begins to work.

After the organization approves the scope of the RA, the RA team must identify all the assets that are within the scope of the assessment. This inventory must include the IT resources. The inventory also must include a listing of the personnel who run business processes that are in the scope of the RA. It also must contain the data included in those processes. For instance, an organization decides to conduct a RA of its email infrastructure. For this assessment, the RA team must consider not only the operation of the organization’s email servers, but also whether employees are sending confidential data via email. Depending upon how the RA team defines the project, mobile devices that send and receive email could be outside of the scope of the assessment.

The RA team should consider many assets for the inventory. Assets to be considered include:

• Personnel
• Data
• Hardware and software
• Physical facilities
• Business process workflows
• Current controls that help safeguard any assets

It is important to identify all assets that are associated with the RA project. The RA team must list assets that are critical to business functions because they also must identify threats and vulnerabilities to those assets. The RA team must identify vulnerabilities and threats in order to determine the risk to the organization’s assets. For IT resources, the organization needs to know how vulnerabilities and threats might affect confidentiality, integrity, and availability.

A vulnerability is a weakness or flaw in an IT system. Information security is compromised when vulnerabilities are exploited. An exploit is a successful attack against a vulnerability. There are many different kinds of vulnerabilities, but they fall into four broad categories: people, process, facility, and technology vulnerabilities. Vulnerabilities can be design mistakes. They also can be configuration mistakes.

Threats are anything that can cause harm to an information system. They are successful exploits against vulnerabilities. A threat source carries out a threat or causes it to take place against a vulnerability. A threat source can be a person or a circumstance. Similar to vulnerabilities, threats also fall into four broad categories: human, natural, technology and operational, and physical and environmental. Threats can be deliberate or accidental.

Threat sources act upon vulnerabilities. TABLE 14-1 shows examples of vulnerabilities and threats.

TABLE 14-1 Examples of Vulnerabilities and Threats

The RA team must put forth a good-faith effort to identify as many vulnerabilities and threats as possible. It can do this in several ways. For vulnerabilities that are internal to the organization, the team could interview employees in areas that are part of the assessment. The team also could send a questionnaire to a sampling of employees to ask questions that are relevant to the assessment. The RA team also should review the organization’s policies and procedures. The team could use automated scanning tools to look for vulnerabilities in its IT systems.

The RA team also must learn about vulnerabilities and threats that are external to the organization. They can review industry guides and can use NIST guidance to learn more about information security issues and controls. The RA team can review information from the U.S. government and other industry experts. The SANS Institute has one of the largest collections of information security resources in the world. (See www.sans.org for more information.) The team also can review known system problems listed in the National Vulnerability Database (NVD). (See https://nvd.nist.gov/home.)

It is not possible for the RA team to identify every security vulnerability or threat. This is because technology changes so rapidly. For example, zero-day exploits are a type of exploit that is hard for an organization to prepare for. An organization can only prepare for zero-day exploits generally. It is hard to prepare for or assess specific zero-day exploits because they are exploited so quickly after they are discovered.

Likelihood and Potential Loss

A risk is the likelihood that a threat will exploit a vulnerability and cause harm. The RA team is responsible for determining how likely it is that identified risks will occur. The team also must determine the potential loss or harm that the organization could have if the risk is realized. Likelihood and potential loss can be stated as either a qualitative measure or a quantitative measure. It depends on the risk methodology that the RA team uses.

Quantitative Risk Analysis. Quantitative risk analysis attempts to use real numbers to calculate risk and potential loss. The organization assigns real numbers to the value of its assets. It also assigns real values to the cost of countermeasures and controls. One of the greatest advantages of a quantitative RA is that it provides an objective and monetary-based assessment of cost. It helps an organization understand both the cost of risk and the cost of controls. This type of RA allows management to directly compare the cost and benefits with recommended controls. One of the greatest disadvantages of quantitative risk assessments is that they are very difficult to administer.

In a quantitative risk analysis, the RA team must assign a value amount to each of the organization’s assets. Several factors shape the cost of an asset, such as the cost of developing it and then the ongoing cost of maintaining the asset each year. The asset might have value that is hard to measure. For example, it might be hard to value the intellectual property that goes into creating and developing an asset. It is also hard to place a value on an asset that provides an organization with its competitive edge. Although quantitative risk analysis does give an organization actual money amounts for its assets, there is a subjective element to these values that is hard to measure. This is particularly true if an asset has intangible value.

After the RA team determines the organization’s vulnerabilities and threats, it must determine exposure factor. The exposure factor is the percentage of asset loss that is likely to be caused by an identified threat. For example, an RA team determines that an organization’s data center is vulnerable to tornadoes. This is because the data center is located in the part of the midwestern United States known as “tornado alley.”³ The RA team estimates that if a tornado struck the data center, it would be destroyed and the data center’s value would be reduced to zero. The exposure factor is 100 percent.

The RA team determines that the same data center is also subject to a threat of fire. The RA team determines that if a fire were to occur, only 50 percent of the data center would be destroyed. (This is because the data center has a fire suppression system.) In this scenario, the exposure factor is 50 percent. Exposure factor also is called likelihood.

Once the RA team determines the exposure factor, it must determine single loss expectancy (SLE). The SLE is the amount of money that an organization will lose if a risk is realized. In other words, it is the loss that an organization will suffer every time that risk occurs. SLE is often expressed as an equation:

SLE = Asset value × Exposure factor

In our data center example, suppose that the data center is relatively small and is worth $2 million. The SLE for the data center being struck by a tornado is $2 million, whereas the SLE for the data center experiencing a fire is $1 million.

The RA team also must figure out how many times a specific risk might occur during a 1-year time frame. This is called the annual rate of occurrence (ARO). An RA team can use historical data to determine this number, as well as perform research to understand the likelihood of risks within a certain area. For instance, police departments can provide information about crime statistics. Insurance companies can provide information about how often organizations are likely to experience a serious fire or other devastating incident. ARO is expressed as a number. It can range from zero (a threat will never take place) to any number greater than zero. A risk that will happen only once a year has an ARO of one.

In our example, the RA team estimates that a fire might strike its data center once every 20 years. The ARO for that event is 1/20, or .05. The RA team estimates that a tornado might strike its data center once every 15 years. The ARO for that event is 1/15 or .067.

ARO is used to calculate annualized loss expectancy (ALE). The ALE is the amount of loss that an organization can expect to have each year because of a particular risk. In a quantitative risk analysis, the ALE is the end-result number. An organization can use this number to determine how much money it should invest each year in controls to mitigate a particular risk. As a matter of good business practice, an organization should not spend more than the ALE amount each year on particular risks. ALE is often expressed as an equation:

ALE = SLE × ARO

In our example, the ALE for the tornado risk is $134,000 ($2 million × .067). The ALE tells the organization that it can afford to spend up to $134,000 per year to mitigate the potential loss caused by a tornado. The ALE for the fire risk is $50,000 ($1 million × .05). The organization can spend up to $50,000 per year to mitigate potential fire loss. Spending more on controls than the ALE amount might be unwise from a business standpoint because the cost of the controls is then more than the cost of the risk. It does not make sense to spend more money on controls than the cost of the risk.

Organizations also can use these formulas to determine the value of a control. The value of a safeguard to the organization can be determined by comparing the ALE before implementing a control to the ALE after implementing the control. This also can be expressed as an equation:

Value of control = (ALE before safeguard) – (ALE after safeguard) – Cost of control

These equations are used in quantitative risk analysis. Many vendors have created software products that can help RA teams perform these equations.

Organizations often choose to do a quantitative RA because it computes risk in terms of money value. Sometimes executive management finds this information very helpful. It gives them concrete values upon which to measure the costs of risks and the effectiveness of controls. A quantitative risk analysis speaks the language of business: money.

Qualitative Risk Analysis. Qualitative risk analysis uses scenarios and ratings systems to calculate risk and potential harm. Qualitative risk analysis does not assign money value to assets and risk. Instead, it uses descriptive categories to express asset criticality, risk exposure (likelihood), and risk impact.

One of the greatest advantages of this method is that it is relatively easy to use. It does not require RA team members to have specialized financial knowledge. It also does not require them to deduce the costs of assets, controls, and potential harm. One of the biggest disadvantages of qualitative risk assessments is that they are very subjective. The opinions of members of the RA team can highly influence the results of the RA.

Qualitative risk analysis is scenario-based. In this type of assessment, the RA team considers a specific vulnerability or threat. The team then considers a scenario based on it. As team members walk through the scenario, they think about how the scenario will affect business operations and resources. The team members will use their own experiences to determine threat likelihood. They can also use industry resources.

The RA team will create likelihood and impact categories to help them classify and compare different risks. These categories are usually based on either a numeric rating system (scale of 1 to 10) or a low-medium-high standard.

Risk exposure categories classify the likelihood of certain risks. An RA team might use the following categories to determine risk exposure:

• Low—Events that are unlikely to happen within a year
• Medium—Events that are somewhat likely to happen within a year
• High—Events that are likely to happen within a year

Risk impact is determined the same way. Impact categories classify the harm to an organization if a risk is realized. The RA team might use the following impact categories:

• Low—A realized risk will have little or no effect on the organization. The organization will experience light disruption to its business processes. It will incur only low costs related to lost productivity and data and will not experience reputational loss.
• Medium—A realized risk will have a moderate effect on the organization. The organization may experience moderate disruption to its business processes. It will incur moderate costs related to loss productivity and data and a moderate reputational loss.
• High—A realized risk will have a severe effect on the organization. The organization may experience severe disruption to its business processes. It will experience high costs related to loss productivity and data, and its reputational loss will be significant.

The RA team also will need a way to compare likelihood and impact levels to determine overall risk level. The RA team will use the overall risk level to determine where the organization should apply controls. An organization will not want to implement costly controls on a system that has low exposure and impact results. However, it will want to implement controls where there is a high likelihood rating and a high impact rating. It must create a method to analyze likelihood and impact rating levels. It uses this analysis to determine the priority of issues that the organization must address. TABLE 14-2 shows a generic risk level matrix.

TABLE 14-2 Risk Level Matrix

Organizations use their risk level matrix to determine the priority of the risks that they must address. TABLE 14-3 shows how the results of a qualitative risk analysis might look. It uses the vulnerabilities and threats from Table 14-1. In this example, the RA team would first recommend that the organization implement controls to remove user accounts for terminated employees in a timely manner. This is because the risk level for that vulnerability is higher than the others listed in the table.

TABLE 14-3 Risk Level Outcomes

The problem with qualitative risk assessments is that the organization has no way to determine the amount of money to spend on controls. It also has no way of knowing if it is spending too much on a control relative to the actual loss that it could have because of a realized risk. For some organizations, this is a significant failure of a qualitative risk analysis. This is one reason why an organization might prefer to complete a quantitative risk analysis. TABLE 14-4 compares the features of qualitative and quantitative risk assessments.

TABLE 14-4 Qualitative and Quantitative Risk Assessment Comparison

Document Needed Controls

The final part of an RA is to document where security controls are needed. The RA team does this by reviewing the results of its assessment. In a quantitative risk analysis, the RA team has a list of risks that it can prioritize by ALE and ARO. The RA team should review risks with high ALEs and high AROs to recommend controls.

Through a qualitative risk analysis process, the RA team has a list of risks organized by potential harm. The risk level is based on the classifications that the RA team used for risk likelihood and impact. The RA team should look at high and medium risk levels to recommend controls.

An RA team needs to suggest controls to executive management. It must identify risks that are high priorities. It also should identify controls that can mitigate or eliminate those risks. If the RA team performed a quantitative analysis, it should include a cost-benefit analysis for each of its suggested controls. If the team performed a qualitative analysis, it should show how the suggested control affects the overall risk level for a specific threat or vulnerability.

Executive management reviews the RA team’s report as it makes business decisions. It will use the report as part of its information security governance (ISG) activities. The organization must make sure that its response to the risks identified in the RA team’s report supports its business objectives. The executive management team shows due care and due diligence when it responds to issues that are raised in a risk assessment.

Risk Response

Executive management must decide how an organization responds to risk. Risk response is the actions taken by executive management to reduce risk to an acceptable level. Executive management must apply the most appropriate controls to decrease its risk. The organization’s risk response must be cost-effective. It also should have a limited impact on the organization’s business.

Executive management must prioritize how it will respond to risks. It should respond quickly to the risks that have the greatest potential to harm business goals. Executive management must assess each risk individually, as an organization will not handle all risks in the same manner.

Executive management can use several approaches to respond to risk. They are:

• Risk avoidance—The organization applies controls or takes other action to completely avoid a particular risk. This strategy removes all risk caused by a particular vulnerability or threat. For example, executive management could decide that the risks posed by a function in an IT system outweigh the benefit of that function. It could instruct system owners to disable that function in order to avoid the risk. The risk caused by that function is completely eliminated.
• Risk mitigation—The organization applies controls or takes other action to reduce a particular risk. This strategy does not eliminate all harm that could be caused by that risk. Instead, it reduces the risk to an acceptable level. The risk that is left over is called residual risk. For example, executive management could decide that the risks posed by a function in an IT system could be lessened if access to that function was limited. The organization could use access controls to limit access to that function to only a few trusted employees. The risk caused by that function is reduced because fewer people have access to it.
• Risk transfer—The organization takes no action against a particular risk. Instead, it passes its risk to another entity that bears the risk of loss. Usually an organization transfers risk of loss to an insurance company. It can purchase a cyberliability insurance policy to insure against specific risks. For example, the organization could purchase insurance to cover losses because of unauthorized access to IT systems. These types of policies are called technology errors and omissions policies.
• Risk acceptance—The organization takes no action against the potential risk. It makes an intentional decision to do nothing. Executive management may choose this strategy if the cost of the risk is less than the cost to avoid, mitigate, or transfer the risk.

Training Employees

The RM process includes educating employees about risk and how to avoid it. Often employees contribute to an organization’s risk by engaging in behavior that puts the organization and its data at risk. Risk can be reduced if employees understand why certain behaviors are not allowed or acceptable. The organization can use policies to help direct employee behavior. Risk is reduced when employees behave according to company policy.

Security awareness training is an important part of any information security program. It is required to keep employees aware of their security responsibilities. An organization must include security education in its day-to-day routine.

Continuous Monitoring

Organizations must always monitor their information security risk. They also must monitor the controls that they put in place to respond to that risk. This is an ongoing process. Because technology changes quickly, executive management must be diligent reviewing its risk and response to that risk.

Many laws require organizations to continually assess their risk. For example, the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule requires covered financial institutions to conduct RAs to identify risks to customer information as part of their information security program. Covered financial institutions must apply controls to respond to identified risks. They also must assess their current controls to make sure that they are effective. Financial institutions also must review their information security programs on a regular basis.

The Health Insurance Portability and Accountability Act (HIPAA), FISMA, and SOX also require covered organizations to conduct regular risk assessments.