IT Risk Management Life Cycle

As with most methodologies, risk management, when applied properly, takes on the characteristics of a life cycle (Figure 15-1). It can be broken out into several phases beginning with identification of information assets and culminating with management of residual risk. The specific phases are as follows:

Figure 15-1: Risk-management life cycle.

• Phase 1: Identify information assets

• Phase 2: Quantify and qualify threats

• Phase 3: Assess vulnerabilities

• Phase 4: Remediate control gaps

• Phase 5: Manage ongoing risk

Phase 1-Identifying Information Assets

The first phase in the risk-management life cycle is to identify the organization's information assets. There are several tasks that must be completed in order to be successful. These steps include the following:

• Define information criticality values

• Identify business functions

• Map information processes

• Identify information assets

• Assign criticality values to information assets

The goal of this phase is to identify all information assets and assign each information asset a criticality value of high, medium, or low for its confidentiality, integrity, and availability requirements. For example, we may identify credit card information as an information asset that is processed by our retail system. This information asset is governed by the Payment Card Industry (PCI) data security standard and is valuable to thieves if disclosed in an unauthorized manner. We also know that if altered, this information is useless to us but that in most cases a temporary loss of access to this information is tolerable. As a result, we would assign credit card information values of high for both confidentiality and integrity and medium for availability.

The best way to identify information assets is to take a top-down approach beginning with organization functions, identifying the processes that support those business functions, and drilling down to the information assets that are processed. Figure 15-2 represents this approach to information asset identification using business function decomposition.

Figure 15-2: Business function decomposition.

Defining Information Criticality Values

Okay, so before we begin to identify information assets, shouldn't we know what information criticality values of high, medium, and low mean to our business? This is why the first step in the process is to define each value in terms of how severe the impact would be in the event of a breach of an asset with a given value. For example, we may define the high value to mean a potential monetary loss of $500,000 or more in the event of a security violation. This definition would be consistent with the confidentiality, integrity, and availability of any information asset we identify.

In order to be successful, it is important to gain consensus from major organizational stakeholders regarding the definitions and to document those definitions. If a criticality value of high means something different to the CEO, CFO, and vice president of operations, we will want to gain a level set with these individuals and obtain their buy-in on the definition. We surely will need it later in the process. Clearly documenting these definitions is critical once a consensus is gained.

Identifying Business Functions

One of the most difficult aspects of risk management is identifying where information assets reside and then which assets are most critical to the business. Fortunately, most businesses are organized by function. As a result, most critical business functions can be identified using the organization chart. Of course, it is still necessary to verify that all the business functions are represented accurately.

Once the business functions are identified, we can assign criticality values to each. For example, we may determine that the retail operations business function requires a high level of confidentiality because of use of credit card information. It may require a high degree of information integrity because transactions are financial in nature and a medium degree of information availability because a short delay in processing the transactions would have only a moderate impact on the organization.

Mapping Information Processes

Since the nature of IT is to process information, IT risk (as opposed to other types of risk) has the added complexity of touching several points in a process. Identifying these process flows is absolutely critical for a few reasons:

• It helps us to identify which information assets are used by each process.

• It helps us to identity process points (steps) that require manual input (which tend to be more vulnerable than fully automated processes).

• It helps us to understand which information systems need protection.

Once we have identified our organization's critical business functions, we can begin to identify the processes that support those business functions and the information assets that flow though the processes. It is important to note that we are not concerned with the technology used to process the information at this point but rather with the process flow itself.

We had identified the retail operations business function earlier. We know that the retail operations business function is responsible for processing credit card transactions that feed all the company's cash flow and are regulated by PCI. Thus, we can identify credit card processing as a critical process. From here we will need to determine the steps or systems (process points) that are included in the process. For our example, we may determine that credit cards are processed in the following manner (Figure 15-3):

1. Associate swipes a credit card during a retail sale.

2. Transactions are aggregated to a system within each retail store.

3. Aggregated transactions are transmitted to the main office during the night over the Internet via site-to-site virtual private networks (VPNs).

4. Store transactions are aggregated with transactions from all the other stores.

5. All transactions are sent to the credit-card processing house over a dedicated telecom data link in a batch file the following day.

6. The credit card processing house deposits funds into a corporate bank account 2 days later.

Assigning Information Criticality Values to Information Assets

Once we have mapped out the information process, we can identify the information asset(s) and assign them criticality values. When identifying information assets that traverse a process, it is important to consider all the potential assets. For example, it is obvious that credit card data are an information asset, but we also may want to consider system management or monitoring information used for the systems that aggregate the credit cards transactions in the preceding illustration. These types of information assets often are overlooked but can be critical.

When assigning criticality values, we need consider the asset's requirements for confidentiality, integrity, and availability. This relationship is represented well using the information criticality matrix employed by the National Security Agency (NSA) INFOSEC Assessment Methodology. An example of this matrix is given in Table 15-1.

Table 15-1: Information Criticality Matrix

Information Asset	Confidentiality	Integrity	Availability
Credit card data	H	H	M
System configurations	M	H	M
System monitoring information	L	H	H

Phase 2-Quantifying and Qualifying Threats

Information threats impact organizations due to lost business, lost resources and recovery costs, and legal and regulatory actions. When threats are realized, these costs often are unaccounted for because they are not identified properly. For example, let's say that our organization is attacked by a malicious worm that causes a temporary loss of processing capacity and several hundred hours of recovery time. The cost may be calculated by quantifying the hours required for recovery and estimating the losses associated with the processing delays. However, has the company's reputation been adversely affected because it was not able to service customers? Were there any lost sales? Were some employees unable to work? What is the organization's legal exposure due to the security breach? As you can see, identifying all the areas within an organization that may be affected requires a fair amount of thought. Therefore, we will help break down the process of analyzing of these threats.

The next step in the risk-management life cycle is to quantify and qualify threats (Figure 15-4). We'll also take a top-down approach as we identify threats, starting with business threats and moving on to technical threats that may give rise to the identified business threats. We'll explain this in more detail later. This phase of the risk-management life cycle requires the following steps:

Figure 15-4: Risk-management process.

• Assess business threats

• Identify technical, physical, and administrative threats

• Identify process-component threats

• Quantify threats

Note 

In order to identify threats to our information effectively, we need to complete the first phase of the risk-management process: identifying information assets. This is so because properly identified threats are associated with an information asset or a group of information assets. Threats associated with systems flow through to the information assets that they process.

Assessing Business Threats

There are several ways that threats can be accounted for, but at a high level, business threats to information can be broken out into three categories: financial threats, legal threats, and regulatory threats. All business threats will fall into one of these categories.

Financial Threats One could argue that all information threats are financial in nature because they all boil down to a monetary loss, if realized. Although this may be true, we will break out regulatory and legal threats because of their prevalence. For our purposes, a financial threat will be defined as a threat that, if realized, would cause a loss of actual funds, reputation, operational effectiveness, or competitive advantage, ultimately resulting in a monetary impact. Financial threats may include the following:

• Financial fraud

• Loss of proprietary information

• Loss of productivity

Once the information assets are identified, these types of threats become more evident. For example, the credit card-information asset we identified earlier has exposure to all three of these threats. The next question becomes, "If realized, how would this threat affect operational effectiveness, company reputation, competitive advantage, or the company's cash position?"

Legal Threats Now that we've identified some of the financial threats, what is the potential legal exposure associated with realization of a threat. With new privacy laws being enacted on almost a monthly basis, if an individual's private information such as his or her name and associated address, Social Security Number, health information, or credit information is disclosed in an unauthorized manner, you can bet that there will be some legal exposure. Additionally, if service levels are affected or another organization's confidential information is disclosed, there could be a breach of contract. Needless to say, legal expenses can be very expensive, even if a court finds in your organization's favor.

In order to get an accurate business-threat assessment, it is necessary to identify potential legal exposure in the event of an information security violation.

Regulatory Threats Along with financial and legal threats, it is important to consider regulatory threats. A regulatory infraction resulting from an information security incident could lead to fines or other penalties (including imprisonment of company officers), as well as temporary or permanent suspension of company operations. Financial institutions generally take the laws governing their operation very seriously because of the severe consequences of noncompliance, but health care entities and public companies are also heavily regulated.

The key to identifying regulatory threats is understanding the laws or mandatory industry standards governing the information your organization is processing. Given our earlier example, we know that the PCI data security standard will govern protection of the credit card information our organization processes. See Chapter 14 for additional information regarding regulations affecting U.S. companies.

Identifying Technical, Physical, and Administrative Threats

Once all the business threats pertaining to our information assets are identified, we can begin identifying the technical, physical, and administrative threats. These threats, if realized, will give rise to one of the business threats that we have identified. For example, a system malfunction will give rise to a loss of organizational productivity.

Technical Threats Technical threats generally are system-related, affecting electronically stored or transmitted information. Given our previous credit card processing example, one technical threat might be system intrusion. This threat then could give rise to the theft of proprietary information, regulatory or legal business threats. Some examples of technical threats include

• System intrusion

• Worms, viruses, and spyware

• System failures

• Logical access control failures

Physical Threats Physical threats normally are facility-related and often can be tied to natural events or mechanical breakdowns. Some physical threats include

• Natural or man-made disasters

• Physical intrusion

• Fire

• Water seepage from burst pipes or weather-related flooding

• Excessive heat or humidity

• Electrical disruptions or black-outs

Although physical in nature, these threats can cause significant information loss. Business continuity/disaster recovery plans and data center controls aim to address these threats. See Chapter 4 for information on auditing data centers and business continuity plans.

Administrative Threats It is common knowledge in information security circles that the "human factor" is the cause of most security violations. Administrative threats are people-related. They may include

• Unintentional disclosure of sensitive information

• Social engineering

• Industrial espionage

• Malicious destruction of information

• Accidental deletion or corruption of information

• Inappropriate use of computing resources (e.g., pornography in the office)

Administrative threats are often overlooked because they tend to be more nebulous and imply an inherent mistrust of employees. Nonetheless, people within an organization introduce quite a few threats to information assets.

Note 

The Great Wall of China was built to defend China from northern armies, but what many people don't realize is that it was rendered useless by a trusting Chinese general who allowed the Manchu army through the gate at the Shanhai Pass. Once China was conquered by the Manchus, the wall was of little strategic value because Manchu-controlled lands extended far north of the wall. Similarly, a single employee could introduce a world of peril to your organization.

Identifying Process Component Threats

Now that we understand our business and high-level technical threats, we can examine the processes that we mapped out when we identified our information assets. We will specifically analyze the threats to different process components such as systems and manual input steps or outputs. Figure 15-3 outlines six steps in a credit card payment process:

Figure 15-3: Credit card process diagram.

1. Associate swipes a credit card during a retail sale.

2. Transactions are aggregated to a system within each retail store.

3. Aggregated transactions are transmitted to the main office during the night over the Internet via site-to-site virtual private networks (VPNs).

4. Store transactions are aggregated with transactions from all the other stores.

5. All transactions are sent to the credit card processing house over a dedicated telecom data link in a batch file the following day.

6. The credit card processing house deposits funds into a corporate bank account 2 days later.

Our goal is to identify the threats associated with each step in the process. For example, we might identify a threat of employees keeping credit cards or credit card numbers of store customers for step 1. For step 2, we might identify a risk of system failure or system intrusion. We should be able to identify several threats for each process component. When combined, they represent all the threats associated with the processing of an information asset.

Quantifying Threats

Now that we've identified our threats, we need to understand their potential impact and the probability that they will occur if not mitigated. As we discussed in the risk analysis section earlier, two factors play into estimating the severity of a threat:

• Degree of asset loss

• Likelihood of occurrence

As we outlined earlier, we can use the exposure factor (EF) to represent the degree of loss and the annual rate of occurrence (ARO) to represent the likelihood of an occurrence. A threat then can be quantified by multiplying EF × ARO. If we look at our credit card processing example, we may estimate that a hard-disk failure would cause the loss of one day's worth of a store's sales and would fail in the store-side systems once every 2 years. We would calculate the threat by multiplying 1/365 (0.00274) by 0.5. The result would be approximately 0.00137. We then would multiply this by each store's annual sales to quantify the threat.

Phase 3-Assessing Vulnerabilities

We now have identified our information assets and the threats to each asset. In this phase, we will assess vulnerabilities. In examining threats, the common denominator is the information asset because each threat is tied to an information asset. When assessing vulnerabilities, on the other hand, the common denominator is the information process. We will first identify process-component vulnerabilities and then combine them to determine our process vulnerabilities. Process vulnerabilities then will be combined to determine business function vulnerabilities. Instead of working from the top down (from business function to process component), we will work from the bottom up in assessing vulnerabilities. We will use the following steps in analyzing vulnerabilities:

• Identify existing controls in relation to threats.

• Determine process component control gaps.

• Combine control gaps into processes and then business functions.

• Categorize control gaps by severity.

• Assign risk ratings.

Note 

Prior to World War II, France recognized Germany, its neighbor to the east, as a growing threat. Therefore, the French government built a line of walls, tank defenses, and bunkers called the Maginot Line to defend against invasion. The country decided to end the wall on the north side at the Ardennes Forest, which was believed to be impassable as a result of its dense nature. When the Germans invaded in 1940, they bypassed the Maginot Line fortifications in favor of the dense forest. History shows that the French certainly understood the threat, but miscalculated their vulnerabilities.

Identifying Existing Controls

The initial step in examining vulnerabilities is to review threats and inventory existing controls that mitigate each threat. In our credit card processing example we identified the threat of a hard-disk failure. We also may determine that there are systems that back up disk information nightly and a RAID level 5 disk array providing hard-disk redundancy.

To get an accurate understanding of an organization's risk, it is important to identify all the controls that have been applied. Like threats, controls can be technical, physical, or administrative in nature. Table 15-2 provides a partial list of each type of control.

Table 15-2: Types of Controls

Types of Control	Examples
Technical	Access control systems, two-factor authentication, firewalls, encryption systems, uninterruptible power supplies, intrusion detection systems, antivirus software, redundant systems or system components, backup systems, audit and logging systems, system hardening
Physical	Security guard, key-card physical access systems, alarm systems, safes, fire suppression systems, HVAC systems, fences, lighting, security cameras
Administrative	Acceptable-use policy, business continuity plan, password policy, incident response plan, system baseline configurations, remote access policy, file recovery procedures, information classification, information security training and awareness, audits, and assessments

Determining Process Component Control Gaps

Once we've identified the existing controls that have been employed, we can begin to see areas where controls are either ineffective or simply do not exist. In the preceding example, we identified two controls that are mitigating the threat of a hard-disk failure: Nightly backups and RAID level 5 disk redundancy. Each store closes at 9:00 PM, and the store-side system transmits the transactions beginning at midnight. A full system backup occurs at 3:00 AM at the main office. A system failure anytime during the day would result in loss of the entire day's transactions. The system backup strategy therefore is not as effective as a RAID level 5 disk array that provides real-time redundancy. In this step, it is important not only to identify control gaps but also to measure the effectiveness of existing controls.

Combining Control Gaps

Once we have identified all the control gaps for process components, we can combine them to begin to see a risk posture for the information process. We then can combine the processes supporting each business function to begin to see the risk posture for each of the business functions. The combined business-function risk postures give us the organizational risk posture.

Categorizing Control Gaps by Severity

Now, once we have a good view of organizational risk, some of the underlying risks naturally will begin to emerge as more critical than others because they affect valuable information assets or are unmitigated. At this point, you should be able to assign business functions, information processes, and process components qualitative risk ratings of high, medium, or low. We will want to focus our attention on the risks to which we assigned high risk ratings. The more severe risks can be analyzed further to determine their quantitative value to justify additional investments in controls.

Phase 4-Control Gap Remediation

By now our risks should be categorized as high, medium, or low. Initially, we will focus on mitigating the most severe risks because we most likely will see the highest return on our investment. In essence, we are likely to mitigate more risk with less money. We will use the following steps in control gap remediation:

• Choose controls

• Implement controls

• Validate new controls

• Recalculate risk ratings

Choosing Controls

Too often organizations implement controls because of their use of advanced technologies or a slick interface. More often than not the controls that mitigate the most risk do not fit into either of these categories. Choosing controls should be purely a business decision that takes into account the level of risk to be mitigated, the cost, and the ease of use of the controls.

Identifying Potential Controls There are almost always several ways to mitigate a risk. The methods will range the cost spectrum from very inexpensive to prohibitively expensive and can be technical, physical, or administrative in nature. Organizations often overlook administrative controls such as security policy, security awareness training, and agreements. These controls, when implemented properly, can be extremely effective and affordable.

Rating Controls by Cost and Effectiveness Once controls are identified, they can be compared in three ways: cost, effectiveness, and ease of use. The cost of a control is very quantifiable and often is the only attribute considered. In choosing controls properly, however, it is important to consider the effectiveness of the control. For example, to mitigate the threat of network intrusion, an organization may upgrade its existing firewall to a $100,000 firewall appliance that has advanced network inspection technologies. However, since the existing firewall mitigated all but a fraction of the risk, was this the best use of company funds? Equally important is a control's ease of use. Many organizations have purchased intrusion detection systems only to find out that they require a high degree technical of expertise and a large amount of analysis time to operate properly.

One method of choosing controls is to list them in a spreadsheet and rate each of the three attributes in separate columns on a scale of 1 to 10. The attributes even can be weighted if you want to get fancy. Either way, this is a tool that can be used to make more informed decisions.

Implementing Controls

Now that we've selected our controls, we must implement them properly. When companies are subjects of IT audits or assessments, most findings are related to misconfigu-rations or improperly implemented controls, not the absence of controls. Therefore, it is important to implement new controls properly.

Validating New Controls

To take it one step further, new controls should be tested by an organization's IT audit department to validate their effectiveness. This will provide assurances to management that its investment has been well spent. The results of this audit or assessment also will feed calculation of the organization's new risk posture.

Recalculating Risk Ratings

If we've done our job correctly, our overall organizational risk and business-function risk now should be reduced from its original level. The information process where we implemented the controls also will be affected. Therefore, it is necessary to recalculate risk in these areas to reflect the addition of the new controls. Our risk ratings will be based on the residual risk, which is the risk that remains after mitigation. Instead of having a high risk rating, our process may be assigned a medium or low risk rating.

Phase 5-Managing Ongoing Risk

Risk is inherently dynamic in nature, especially the threat component of risk. As a result, we will need to measure risk continually and invest in new controls to respond to emerging threats. There are basically two steps in this phase:

• Create a risk baseline

• Reassess risk

Creating a Risk Baseline

Since we now have the recalculated risk ratings, we can aggregate them to create a risk baseline. We will use this baseline to measure changes in our risk posture and identify trends as we cycle through the risk management process in the future. The risk baseline should include overall organizational, business-function, and process risk ratings, as well as narratives describing the reasoning used in the decision to implement controls or accepted risk.

Reassessing Risk

Now that the process is complete, we will need to plan on reassessing risk periodically. Because of the ever-changing nature of IT, organizations should complete the risk-management life cycle at least once per year. Risk assessments, however, should be triggered by certain events, such as

• Corporate mergers or acquisitions

• New system installations

• Business-function changes

• The enactment of new laws or regulations that mandate the addition of new controls (or require risk analysis)