Discussion

CHAPTER 4

Risk Assessment and Analysis

In this chapter, you will:

•  Review the processes of risk identification, evaluation, and assessment

•  Learn about qualitative and quantitative risk assessment techniques

•  Understand how to evaluate existing controls for effectiveness

•  Assess gaps between current and target states of risk in the IT environment

•  Consider risk ownership and accountability during risk analysis

•  Be able to report risk results to appropriate levels of management

This chapter covers Domain 2 of the Certified in Risk and Information Systems Control (CRISC) exam objectives and knowledge statements and focuses on the risk evaluation, assessment, and analysis processes. We will cover the overall process for evaluating likelihood and impact for risk, examining both qualitative and quantitative assessment methods. We will also cover how control effectiveness is examined and how you might identify gaps between how effective controls are in the existing risk state and the desired level of effectiveness at which controls need to be functioning. Finally, we’ll discuss how the results of the risk analysis are communicated to upper management and risk owners and reported on the risk register.

The CRISC exam objectives covered during this chapter include the following task statements:

•  2.2 Identify the current state of existing controls and evaluate their effectiveness for IT risk mitigation

•  2.3 Review the results of risk and control analysis to assess any gaps between current and desired states of the IT risk environment

•  2.4 Ensure that risk ownership is assigned at the appropriate level to establish clear lines of accountability

•  2.5 Communicate the results of risk assessments to senior management and appropriate stakeholders to enable risk-based decision making

•  2.6 Update the risk register with the results of the risk assessment

As indicated in previous chapters, these objectives and knowledge statements are shown in order of how they are listed in the CRISC Job Practice areas, not necessarily how they are presented in the chapter.

Risk Assessment Processes

As we’ve mentioned, many of the terms you’ll encounter on the exam are generic and may have different definitions based upon the different frameworks or standards you are using in practice. The term  assessment is one such term that may confuse you. For the purposes of taking the exam, and in this book, an assessment refers to the overall combination of steps of identifying, evaluating, and analyzing risk. Remember that risk identification involves identifying the threats, vulnerabilities, assets, and existing controls. Evaluation, on the other hand, focuses on determining the likelihood and impact if the vulnerabilities are exploited by the threats, resulting in damage to the asset. Risk analysis puts everything together and informs the organization about the realistic risk involved and helps determine how effective existing controls are and what gaps exist between current and desired states of risk.

Risk assessment processes sometimes include the risk identification piece of the process but are often separate from this part, depending upon the framework or standard you are using. In general, this process includes threat source and event identification, vulnerability identification, control analysis, likelihood determination, impact analysis, risk determination, control recommendations, and results documentation; these steps follow the same pattern and path as we’re describing here for you in terms of identifying risk and then evaluating it. We’ll describe some of these generic processes here in this chapter.

NOTE    Different risk assessment methodologies and frameworks use varying terms that may have the same or different definitions. You should always look at a term in view of its context and particular framework or methodology.

Some organizations see risk assessment as one large monolithic process, but many frameworks and standards break it down into different steps. We’ll take another look at several important frameworks we briefly touched on in  Chapter 1 , including the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF), the ISACA Risk IT Framework, and others. In this chapter, however, we will go into more detail and examine them from a risk assessment perspective.

NIST RMF

The NIST RMF, found in Special Publication 800-37, describes an overall risk management process that covers all aspects of the risk life cycle. For the assessment piece of the RMF, NIST uses a four-step risk assessment process found in Special Publication 800-30, “Guide for Conducting Risk Assessments.” You’ll see that these four steps are broken down into nine distinctive processes and are listed here:

Step 1: Prepare for assessment.

Step 2: Conduct assessment.

a. Identify threat sources and events.

b. Identify vulnerabilities and predisposing conditions.

c. Determine likelihood of occurrence.

d. Determine magnitude of impact.

e. Determine risk.

Step 3: Communicate results.

Step 4: Maintain assessment.

While we won’t go through every step of this process like NIST does, the process is similar to what we’ve been describing all along in this book, and it is similar to the other frameworks we discuss in the next section. The NIST assessment process is a subset of the integrated RMF, which includes not only assessments but categorizing assets according to criticality and protection (a necessary first step in the process), as well as managing and monitoring risk throughout the entire life cycle of a system or asset. The NIST RMF also includes a control framework and methods for assessing the various controls, which we will cover in upcoming chapters.  Appendix A  of this book covers the overall RMF and its supporting publications in detail.

OCTAVE Methodology

As part of a U.S. government contract with Carnegie Mellon University, the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) methodology was developed to assist organizations in identifying and assessing information security risk. The methodology was originally developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in 1999 and has been updated over the years to its current version, OCTAVE Allegro, in 2007. OCTAVE uses a concept called  workshops, made up of members of an organization, sometimes including outside facilitators with risk management and assessment expertise. The methodology has prescribed procedures, which include worksheets and information catalogs to assist organizational members, drawn from all functional areas of an organization, to frame and assess risk based upon internal organizational context (infrastructure, governance, business environment, and so on). OCTAVE has three iterations: the original OCTAVE, OCTAVE-S, and OCTAVE Allegro.

OCTAVE and OCTAVE-S

The original OCTAVE methodology was released in 1999 and was designed for organizations with at least 300 employees. The assumptions for using OCTAVE included that the organization operate and maintain its own multitiered information infrastructure and be able to perform vulnerability assessments. While OCTAVE is flexible and allows an organization to tailor its use based upon its own assessment needs, the methodology is performed as three sequential phases. The first phase covers identifying assets, threats, protection practices, vulnerabilities, and security requirements. You can see where this maps to the practices we’ve described throughout this chapter as determining threats, identifying assets and their vulnerabilities, and evaluating existing controls. In the second phase, the members of the workshop perform assessment activities and evaluate the infrastructure. In the third phase, the workshop members develop response strategies for the identified risks.

OCTAVE-S is fundamentally the same as the original OCTAVE, with a few minor differences. First, OCTAVE-S was designed to assess smaller organizations, usually with fewer than 100 people. Second, this iteration relies more on internal personnel with extensive knowledge of the organization and its infrastructure and less on outside risk experts or facilitators. The number of workshop members will also be considerably less; the team may rely on fewer than ten key experts in the organization. OCTAVE-S processes and procedure documents were also written to include more detailed security-related information since this approach does not rely on outside security experts or risk facilitators to assist the team.

OCTAVE Allegro

The OCTAVE Allegro methodology, introduced in 2007, expands the previous two iterations but does not necessarily replace them. It includes a more business-centered and operational risk approach to the assessment. It is also asset-centered in its approach; it focuses on assets and their use or misuse, the environment they are used in, and how threats and vulnerabilities specifically target and affect the assets. Allegro can be used on a scaled basis; either individuals or workshop teams can use this method without the need for a high degree of risk management or assessment knowledge and experience. OCTAVE Allegro is divided into four phases, which include eight steps. These phases and steps are described next.

Phase 1: Establish Drivers

Step 1: Establish risk measurement criteria. This step serves to develop and establish the organization’s methodology and measurement criteria used to assess risk. OCTAVE uses a qualitative assessment methodology and measurements but can use quantitative methods for certain aspects of the overall process, such as determining likelihood and impact.

Phase 2: Profile Assets

Step 2: Develop an information asset profile. In this step, the organization develops an asset profile, which is really a collection of information that describes the asset, including its characteristics, priority, impact to the organization, and value. This profile also contains security requirements the asset may have.

Step 3: Identify information asset containers. The information asset container describes how data is stored, where it is processed, and how it is transported. Containers are usually networks and systems, including those that the organization directly operates, as well as those that it outsources.

Phase 3: Identify Threats

Step 4: Identify areas of concern. In this step, potential risk factors are identified and are used to develop threat scenarios.

Step 5: Identify threat scenarios. Threat scenarios, in the context of OCTAVE, describe categories of actors and the relevant threats in each category. The scenarios are typically identified by the use of a threat tree, which simply maps actors and scenarios.

Phase 4: Identify and Mitigate Risks

Step 6: Identify risks. In this step, consequences such as impact and likelihood are identified and measured, which inform risk.

Step 7: Analyze risks. Once impact and likelihood have been identified and measured, risks are analyzed. During this step, risk scores are developed. These come from developing impact and likelihood values, with an emphasis on impact in particular, since this is an asset-driven assessment.

Step 8: Select mitigation approach. In this step, risk response strategies are developed, analyzed, and recommended.

EXAM TIP    OCTAVE is designed for larger organizations, while OCTAVE-S is intended for use by smaller organizations. OCTAVE Allegro is scalable for use by individuals or larger teams working in organizations of various sizes.

ISO/IEC Standards

ISO stands for the International Organization for Standardization, and IEC stands for the International Electrotechnical Commission. Together, these two organizations are responsible for a plethora of information technology standards that are used worldwide, including several that apply to information security and risk management. We briefly mentioned risk-related ISO/IEC standards in  Chapter 1 ; in this chapter, we will go into a bit more depth on these standards, focusing mainly on those that cover risk management and assessment.

ISO/IEC 27005:2011

Standards in the ISO/IEC 27000 series are all about information security, and the 27005:2011 standard supports the common ideas promulgated in both ISO/IEC 27001 and 27002. The standard applies to risk management, providing a unified risk management approach to organizational security. The standard doesn’t necessarily offer a specific risk management or assessment methodology, but it does serve to describe a formalized, structured process of risk management, such as developing context, scope, methods, and so on. It also describes the two primary types of assessment methodologies, qualitative and quantitative. Additionally, it describes processes used to develop risk response strategies, communication with stakeholders, and continuous risk monitoring.

ISO 31000:2009

ISO/IEC 31000:2009, “Risk Management—Principles and Guidelines,” covers a broader range of risk management and is not specific to IT or IT security. It generally focuses on business risk and can be used by organizations of any size, regardless of which business area or sector the organization occupies. It is useful for assisting organizations in developing sound risk management frameworks, processes, and strategies. It replaced a previous comprehensive standard on risk management, the AS/NZS 4360:2004 standard. ISO/IEC 31000:2009 is the governing document for other risk-related documents in the 31000 series, such as the assessment document we’ll cover next.

IEC 31010:2009

IEC 31010:2009 is where the meat of information regarding risk assessments is located for the ISO/IEC standards. This document, “Risk Management—Risk Assessment Techniques,” articulates with and extends the risk management principles of ISO/IEC 31000:2009 and provides a concrete overview of the risk assessment process. This standard describes risk assessment as the combination of risk identification, analysis, and evaluation, with a precursor step of establishing the risk context within the organization. The standard also addresses communication and consultation with various stakeholders and management, risk treatment (response), and monitoring risk.

EXAM TIP    Of the ISO/IEC standards, IEC 31010:2009 is an important one to know for the exam because it covers risk assessments in detail.

ISACA’s Risk IT Framework

ISACA (formerly known as the Information Systems Audit and Control Association, but now known only by its acronym) developed the Risk IT Framework to align with its COBIT framework. While COBIT is used to manage other aspects of business infrastructure and risk, the Risk IT Framework specifically is used to allow organizations to identify and manage IT risk. The framework is broken down into three major process areas: Risk Governance (RG), Risk Evaluation (RE), and Risk Response (RR). We discussed this framework briefly in  Chapter 1 , but the focus of this chapter is on the assessment process, so we will cover the Risk Evaluation portion in more depth here.

The Risk Evaluation processes in the ISACA framework don’t cover only assessment; they actually overlap with the risk identification areas. In RE processes, business impact is framed and described, and risk scenarios are also developed. Risks are assessed and analyzed, as well as presented to the organization’s management. The RE processes are further broken down into three areas (numbered RE1–RE3), which we will describe in more detail.

Collect Data (RE1)

The data collection process aligns with some of the risk identification processes we’ve previously described. During this process, risk management personnel develop a model for data collection, which provides for standardized data formats, measurements, and common data definitions. Data is collected on the various aspects of the organization and risk scenarios, including the business’s operating environment, risk factors, threat sources and events, vulnerability data, and asset data. Data is also collected on the effectiveness of existing controls in the organization.

Analyze Risk (RE2)

In this part of the Risk IT Framework, the organization begins to look at assessing and analyzing risk. First, it defines the risk analysis scope. The scope determines how broad and deep the risk analysis efforts will be, what areas the risk analysis will cover, and which assets will be examined for risk. To complete this part of the process, you’ll need to consider all the documentation assembled up to this point: risk scenarios, asset inventories, breakdowns of business processes, prioritization of assets, and so on. This will help frame the risk analysis as well as determine scope.

During this step, IT risk is also estimated. This involves determining likelihood and impact values associated with the developed risk scenarios. You will also take into account existing controls and how effective they are as they are currently installed and functioning. Likelihood and impact values are taken into account after existing controls are considered.

Although risk response is the subject of the next domain and chapter in this book, during this step of the ISACA process, you also identify and consider possible risk response options. The person assessing the risk may recommend several different response options, based upon the identified risk. What risk options an organization will actually make use of is determined later in the process and typically with the input and approval of senior management. Risk response options should be recommended that reduce risk to an acceptable level directly based upon the risk appetite and tolerance of the organization. Finally, risk analyses should be reviewed by knowledgeable peers to verify that the analysis process is sound and to validate the results.

Maintain Risk Profile (RE3)

A  risk profile is a collection of detailed data on identified IT risks. Risk profiles can certainly cover a single system or asset but are also often seen as describing risks on an organizational-wide basis. During this step of risk evaluation, a comprehensive document of identified risks and their characteristics, such as details regarding impact, likelihood, and contributing factors, is developed and maintained throughout the asset or system’s life cycle. Keep in mind that system or asset risk profiles are usually rolled up into a more comprehensive risk document that covers systems, assets, and business processes across the entire organization.

IT assets are also mapped to the business and organizational processes they support during this step; this helps translate IT risk to corresponding business risk and allows management to see how the organization would be affected if IT risk were realized on specific assets. This also allows the organization to develop criticality estimates of IT resources from a business perspective. It’s worth noting that this is similar to the same process followed during a business impact assessment (BIA). The key to understanding how IT risk affects business operations at this point, is in understanding how the capabilities of IT are provided to the business processes in question and how critical IT is to a particular business process or operation. Maintaining a risk profile also means monitoring risk and updating risk scenarios and risk analysis as conditions and risk factors change. This involves keeping the risk register up to date as well. Finally, the organization should develop key risk indicators (KRIs) during this step, specifically focusing on IT resources. While key risk indicators are discussed in upcoming chapters, for now you should know that they allow the organization to monitor changes in risk for given scenarios, enabling the organization to modify its risk profiles as these indicators change.  Table 4-1  summarizes some of the different risk assessment methodologies available to you.

Table 4-1    Summary of Available Risk Assessment Methods and Frameworks

EXAM TIP    Because this is an ISACA-sponsored exam, it is a good idea to understand risk assessment terms and process from the perspective of the ISACA framework more so than any other. The ISACA Risk IT Framework directly aligns with ISO/IEC standards as well.

Performing a Risk Assessment

Now that we have discussed different frameworks that prescribe risk assessment processes, in this section we’ll go through some of these processes in a little bit more detail. By and large these processes are common to the different risk frameworks we’ve discussed, although the steps and names may be slightly different between frameworks. Nevertheless, these steps are accomplished during risk assessment and analysis, and it’s more important that you know the general order and activities that occur during risk assessment and analysis than how they are described in any one particular framework or another.

Collecting Data for the Assessment

One of the challenges for a risk assessor is collecting and managing all the data for an assessment. On one end of the spectrum, the assessor may find it difficult to get the bare minimum of relevant data for a particular asset, threats and threat actors, and vulnerabilities, as well as protective controls. On the other end of that same spectrum, the assessor may gather so much data that it is overwhelming to analyze and gauge its relevancy to the assessment effort.

Another challenge is the source of the data. While the best data comes from authoritative sources that have expertise in various areas, such as the asset or system in question, current threats, and so on, the assessor has to be able to separate fact from opinion and collect truly objective data versus subjective data. Objective data is evidence that supports an assertion about an asset or risk, which can be proven or verified through independent means. Subjective data, on the other hand, is data whose validity is subject to opinion. For example, auditing normally produces objective data, in the form of audit logs (assuming they are secured) that detail events that occur on a system and trace those events back to individuals, ensuring accountability. Events in question can be verified through the audit logs. System administrators, however, who assert that they regularly audit system activities but have no audit logs to prove this can’t have their claims verified. Additionally, if there are no policies or procedures that require auditing or show how to perform those tasks, these events can’t be independently verified either.

Data can come in various forms, including performance data, statistical analysis, historical data, trends, or narrative form. The relevance of data should be established by the assessor as it is collected and depends on how it answers relevant risk questions that relate to threats, vulnerabilities, likelihood, impact, assets, and controls. Overwhelming amounts of data can be reduced to relevant summaries and analyzed, sometimes in aggregate, using various automated statistical analysis and database tools.

Data collection typically uses a combination of four methods, designed to collect various types of qualitative and quantitative data from different sources. These collection methods serve to complement and support one another, filling in gaps from one method and verifying information collected from another. The four main methods of data collection are conducting interviews, reviewing documentation, observing systems and assets in operation, and performing technical testing on assets. They are described in more detail in the following sections.

Conducting Interviews    One of the best methods to start collecting data involves interviewing key personnel, such as asset owners, system administrators, security personnel, and other people with direct knowledge of important aspects of the asset, relevant threats and vulnerabilities, and controls. Interviews should be scheduled with key personnel and consist of relevant questions that answer questions relating to security posture, processes and procedures, asset characteristics, and implemented security controls. The assessor should carefully record interview results through concise meeting notes or recording devices, for later reference. Keep in mind that while interview data should usually be considered subjective in nature, it can be used as a starting point to gather knowledge and facts about a system that can be later verified using other means, such as documentation, system observation, and testing.

Documentation Reviews    Documentation is a mainstay during a risk assessment. A well-documented system indicates what its characteristics are, what security requirements it has, and whether the people responsible for the system have defined processes in place to fulfill system security responsibilities. Documentation gives an assessor a wide variety of information on how the system is routinely used, whether a security patch program is in place, who has access to systems and data, what policies exist to define security requirements, and how the system is securely configured. Documentation can be either paper-based or electronic; it can come from spreadsheets, databases, network devices, systems, written procedures, physical access logs, and so on. Examples of documentation include organizational policies, backup and restore procedures, security officer appointment letters, and so on. While not strictly documentation (unless printed), audit logs and configuration files could also be considered in this category since they provide documentary evidence that supports an assertion of how events were recorded or how a system was configured. Documentation also serves to verify data collected from other sources, such as interviews. Remember, in the security assessor world, if you don’t document it, then you can’t prove that you do it.

System Observation and Verification    Sometimes it’s not enough to interview personnel and review documentation. Unfortunately, people can lie or be mistaken in interviews, and documentation can be falsified. Observing a system in operation can verify whether it is secure and whether its security functions and controls are actually working as intended to protect systems and data. The same is true for physical security controls. An assessor can easily determine whether a control is functioning by observing a system operator perform a security function or by visually inspecting a control to make sure it is in place and implemented properly. Examples requiring the observation method include gates, guards, and locks; other examples are watching a system through the boot process, observing a screen lock go into effect, having a system administrator show you various security features, and so on.

System Testing    Obviously, not all data can come from talking to people, reading system architecture documents, and watching the system administrator assign permissions to shared folders and files. Some data must come from looking at the configuration of the system itself, as well as getting relevant data that pertains to patching, vulnerabilities, user accounts, configuration files, registry settings, and other technical data. This data is used to determine not only if a system is configured properly and securely but also what potential vulnerabilities might exist on a system. This is where the technical assessment portion of data collection comes into play. Since technical data can be overwhelming in size and volume, automated tools are typically used to perform system security testing. These tools include vulnerability scanners, sniffers, and other hardware and software tools, some of which are described in  Chapter 6 .

During system security testing, various types of host-based and network scans may be performed, along with in-depth examination of patches and updates that have been applied to the system, configuration settings, user accounts, and other security settings. Rights, permissions, and privileges on the system and its resources are examined and compared against security requirements and control functions to ensure they match. Network protocols and connections are studied, and the network architecture may be examined to ensure a sound network design has been implemented. Application software code reviews and testing, including fuzzing, may be performed. Authentication and encryption mechanisms are examined in-depth to ensure they are strong and effective and meet governance and best-practice requirements where applicable. Physical access controls may be tested to ensure that physical separation away from systems for unauthorized users is maintained.

The results of system security assessments (usually in the form of vulnerability assessments or penetration testing, discussed further in  Chapter 6 ) are consolidated with the results from interviews, documentation reviews, and system observations to form a comprehensive data picture of the system or asset; these results further inform the controls analysis and impact determination aspects of risk.  Table 4-2  summarizes the different data collection methods you can use during an assessment.

Table 4-2    Summary of Data Collection Methods During a Risk Assessment, with Examples

NOTE    While you may not be directly tested on data collection methods, it is a good idea to understand these methods, as in actual practice, you will likely use them extensively.

Asset Identification and Categorization

As you’ll recall from the discussions in  Chapter 3 , identifying the different elements of risk is a necessary precursor to assessing risk. One of the goals of the identification process is the development of risk scenarios. Risk scenarios require that you identify assets, vulnerabilities, and potential threat events.

Asset identification not only requires you to inventory all of your assets; you should also determine how critical they are to your business, decide how sensitive the data they process or produce is, and characterize the system or asset in terms of confidentiality, integrity, and availability. Determining criticality is an important aspect of the overall risk management process and typically is done before any assessment takes place. The NIST RMF process, in fact, requires that you perform a system categorization on assets in the first step of that framework. This system categorization later helps you to assign controls to the asset based upon its criticality factors. The set of controls that you assign to each asset, based upon its criticality, is what is actually assessed, for effectiveness in both mitigating risk and compliance.  Chapter 6  will also go into more detail on controls and assessing them.

Threat and Vulnerability Identification

Once you have categorized each of your key assets, you must determine the vulnerabilities inherent to that asset and the threat events that could exploit those vulnerabilities. A vulnerability assessment can give you information about the weaknesses inherent to an asset. The vulnerability assessment might include examining all aspects of an asset or capability to determine any vulnerability it has, including the physical, technical, and operational vulnerabilities inherent to the asset. For example, there can be technical vulnerabilities related to configuration issues or lack of hardening on a network device. Physical vulnerabilities could relate to the lack of physical protection for the network device. Operational vulnerabilities might include the lack of backup processes or configuration control exercised for the device.

You will need to do a threat assessment to determine what threats and threat agents exist that could exploit those vulnerabilities. These threats can be internal or external, can be human-made or natural, and should match up with a discovered vulnerability. To complete the development of a given risk scenario, you should consider time and location characteristics of a potential scenario as well. Remember that you are developing scenarios down to the most practical level of detail possible; you will have developed many different possible scenarios for an asset, each covering a particular threat–vulnerability pairing by the time you are done. You should then look at the existing controls you have in place to determine how effective they are in protecting an asset.

TIP    Threat and vulnerability assessments are discussed a great deal in this and other chapters of this book. These two assessment processes are critical to understanding the elements that formulate the risk for an asset.

Control Analysis

After you’ve accomplished asset categorization and determined threats and vulnerabilities associated with those assets, then you must take stock of what existing controls or mitigations you’ve implemented to determine the level of protection an asset currently has. Based upon this existing level of protection, you should be able to determine the impact to the asset if a particular vulnerability is exercised by a specified threat and how likely that event is, given the protections you have in place. All of this information helps to identify the basic risk involved.  Chapters 5  and  6  go into much more detail on how controls are managed, as well as on responding to risk after a risk assessment.

Likelihood Determination and Impact Analysis

Evaluation is the next step of the process, where you must determine the likelihood of a given threat agent initiating a threat or of an identified threat exploiting a given vulnerability, as well as the level of impact or harm to the asset if a vulnerability were successfully exploited by a threat. While threats and vulnerabilities in assets are necessary ingredients to determine risk, they are static ingredients; in other words, threats, vulnerabilities, and assets don’t change much. Likelihood and impact, on the other hand, are variable and are the primary factors in measuring risk. People who don’t understand how risk is framed often mistakenly state risk as a result of only one individual element. You could say that the risk to an asset is high, for example, simply because the likelihood of the negative event occurring is high. You could also say that risk is high because the level of impact if a negative event were to occur would be high as well. But neither of these statements alone really captures the sense of risk. This is because individually they do not convey the other dimension of risk since risk is a product of  both likelihood and impact. Additionally, you can’t make these determinations without the background knowledge of the threat, the vulnerability, and the asset.

CAUTION    Make sure you consider controls and their effectiveness when analyzing risk since controls can help decrease likelihood or reduce impact, thereby decreasing the assessed risk for an asset and the organization.

Evaluation involves the measurement of these two primary factors, likelihood and impact. We’ve already discussed how there can be different ways to measure these factors, based upon subjectivity or concrete values. This is where the discussion on qualitative and quantitative techniques comes into play. We’ll go into depth on those assessment techniques next.

EXAM TIP    Remember that risk assessments are comprised of the steps of risk identification, evaluation, and analysis. Identification produces threat-vulnerability pairs, asset inventories, and risk scenarios. Evaluation covers likelihood and impact calculations, resulting in risk values. Analysis looks at the overall application of these factors, as well as control analysis, to produce a comprehensive picture of risk.

Quantitative and Qualitative Techniques

You could take two different security professionals, both trained in the latest standards and practices associated with risk management, and have them both do an assessment on the same system, and, chances are, they would produce similar reports, but they would not be exactly the same. Why is that? It’s because there are so many different methods of conducting risk assessment and analysis, depending on what governance the organization falls under, how the organization has framed its risk, and so on, that the risk would never be assessed exactly the same; there are too many variables involved. Add to that complexity the natural subjectivity of human beings, and you may have very different risk reports. However, most risk assessment methodologies are still based fundamentally on the two primary ways to assess risk: qualitative and quantitative. Both of these methods have value, depending upon the context of the situation, and often both methods can be combined. We will discuss these techniques at length in the upcoming sections, as well as how they can be used together.

Quantitative

A  quantitative risk analysis uses concrete (nonsubjective) numerical values and statistical analysis to calculate the likelihood and impact of risk. Quantitative methods use numerical values such as dollar figures, statistical numbers, and any other hard-core numerical assignments. Quantitative risk assessments follow the same general pattern described previously; you must first list your assets (along with their replacement costs and exposure factors), calculate the impact of a full or partial loss of the asset, determine the likelihood of the negative event, and come up with the overall risk to the organization. This might be calculated in terms of dollars, for example. The following is a scenario that will help you to better understand quantitative risk analysis, as well as some of the factors that can actually be quantified and how.

Quantitative Risk Analysis: A Scenario

Let’s say you are a new employee in a small family-owned business that has no other security professionals employed. You’ve been tasked with developing a risk management strategy and program for the business. Suppose the business had a small server farm that was located in an older building on your small campus, with wooden walls, older wiring, no backup electrical power, and reasonably good fire detection and suppression systems. The server farm contains four servers, each performing a specific data-processing function. The data is backed up weekly, but it takes time to restore, and there is a good likelihood that some of the data would be lost because of the weekly backup schedule. Let’s also say (just for the sake of illustration) that each of these servers costs $10,000 to replace with a new server (since they don’t make your model any longer, unless you were lucky enough to find a cheaper one on eBay). You’ve attempted to quantify factors for the owners, such as recovery time objective (RTO) and recovery point objective (RPO). These factors tell you how much data you could afford to lose if a disaster happened (such as a fire burning down that small wooden building) and how fast you would need to recover data in order to resume business operations in order to avoid suffering a significant loss of business.

Let’s assume that the small business is located in an area prone to thunderstorms, tornadoes, and hurricanes. One of the natural incidents that could occur in these areas is a lightning strike during a thunderstorm, where lightning strikes the metal roof of the building and one of the servers suffers a power surge that completely renders it inoperable. If, after such an event, an assessment determines that the server can’t be repaired, you decide to buy another one. The replacement cost of this server is $10,000. Let’s do some simple quantitative analysis on this scenario:

Asset value (AV) = $10,000 Exposure factor (EF) = 1 (in this case, a 100 percent loss of the server and its data) Single loss expectancy (SLE) = Asset value (AV) × Exposure factor (EF) = $10,000

With an SLE of $10,000, you have to hope this scenario never happens. However, based upon analysis of historical weather patterns in the area, and given the shoddy construction and limited electrical protections of the building the server farm sits in, this seems to be a likely possibility. So, you should determine how much the organization is likely to lose, per year, on such a scenario. You can calculate this if you know a couple of other pieces of information. First, you need to know about how often to expect a severe storm in the area, say on an annual basis. This annualized rate of occurrence (ARO) could be used with the SLE value given earlier to determine your loss expectancy for one year.

SLE × ARO = Annual loss expectancy (ALE)

So, given that severe thunderstorms are historically shown to occur 15 times per year in your area (likelihood), you could conclude the following:

$10,000 (SLE) × 15 (ARO) = $150,000 in  potential loss per year (ALE)

Obviously, this is a bit of a stretch. Even if there are 15 severe lightning-producing storms per year, it’s not likely that each and every one would produce a lightning strike on your server building every time. Even if that  could happen, it’s likely that after it happens the first time, your small business owners would invest in a new facility or relocate its servers, thus reducing the possibility of the other events. So, you might also do some statistical analysis to find out what really is the likelihood of one or more of those 15 severe thunderstorms causing a lightning strike on the server farm building. This analysis might significantly reduce the likely number of events from 15, to say, 3. Now your ALE would be a potential loss of only $30,000 per year. Keep in mind that the numbers are there to show you the  potential risk to the organization, which in this case is expressed as lost dollars, in terms of revenue and assets. Note that these formulas are based upon standard basic risk analysis concepts taught in information security certification programs, such as CompTIA’s Security+ and (ISC) 2’s CISSP program.

Again, the previous scenario is a simplistic (but not too terribly unrealistic) example. Other factors could come into play that are not considered in the previous simple analysis. For example, suppose the business is losing $1,000 dollars per day in revenue for every day this server is out of commission, which the previous calculations do not take into account. This consideration not only is related to the SLE value (since it increases the SLE over time) but also influences your RTO and RPO values. You should also realize that this scenario takes into account only one of the servers; a better risk assessment should include the possibility of all the assets being partially or completely lost. Additionally, it’s possible that a total loss of a server may not occur; let’s say it’s only a partial loss (say, 40 percent, or an EF of 0.4), which would reduce the SLE for that single asset ($10,000 [AV] × 0.4 [EF] = $4,000). So, you must take all of this into account when performing a quantitative risk analysis. There are so many other factors that we haven’t mentioned here that could figure into your SLE values (asset depreciation, lost labor hours to repair or replace the server, and so on), but you can see the basics based upon this simple example.

EXAM TIP    Be familiar with the elements of quantitative risk assessment techniques, such as asset value, exposure factor, single loss expectancy, annual rate of occurrence, and annualized loss expectancy.

The final piece of this puzzle is how much it would cost the organization to reduce this risk. Let’s examine all of the factors that the organization could influence. First, it could not influence the weather, so the threat agent and threat can’t be reduced or eliminated. The organization could, however, address the vulnerability (the server building with its ineffective protections against bad weather, in this case), reducing it somewhat by relocating the server farm or even moving its applications and data to the cloud, for example. The organization could also reduce the likelihood for that particular threat-vulnerability pairing if it removed or changed the nature of the vulnerability itself, as described earlier.

The organization could also reduce the impact of this specific event in several ways. It could create a real-time failover cluster for the servers in another location that would instantly be available if said servers got struck by lightning, or it could at least have a hot spare server and a recent backup, if nothing else. The organization can affect the risk factors, but there is a cost for doing this. What is important in developing risk responses is that the organization must balance the cost of mitigations (for example, acquiring another facility, moving to the cloud, server clusters, or at least hot spares and better backups) with how much it loses in terms of SLE and ALE and the added impact of lost revenue per day, as in this example. The bottom line is that you must find a solution that isn’t more expensive or impacts the organization to a degree worse than the risk event itself. Risk responses are covered in more detail in  Chapter 5 .

Qualitative

A  qualitative risk analysis, on the other hand, involves using subjective scales. These scales could be a numerical scale from one to ten or have subjective values of High, Medium, and Low, for instance. Qualitative risk analysis can come from historical trend analysis, experience, expert opinion, existing internal and external environmental factors, governance, and other inputs that are not always necessarily quantifiable but exist and are important nonetheless. Qualitative risk analysis is appropriate when you must evaluate risk based upon factors that can be hard to quantify, such as those that are not typically measured with concrete, repeatable values. For example, what numerical value could you assign to a potential impact of loss of consumer confidence or damage to reputation? You may attempt to frame it in terms of lost revenue (an educated guess at best) or loss of business. You could also survey a sample population to determine how many people would or would not do business with the organization after a data breach, for example, but even that would be subjective and would offer only a small statistical insight into a hard-to-define measurement.

That’s not to say you couldn’t assign numerical values to different risk factors, however. Instead of values such as Low, Medium, and High, you might assign numerical values that roughly correspond to those levels. For example, you might use a type of Likert scale, which may have values such as 1 (Very Low), 2 (Low), 3 (Medium), 4 (High), and 5 (Very High). This might characterize the subjective level of impact or likelihood the organization wants to assign to a particular risk event. In assigning these subjective values, you must also decide how they relate to each other, yielding an overall risk calculation. In other words, given likelihood values of 1 (Very Low), 2 (Low), 3 (Medium), 4 (High), and 5 (Very High), and identical values for impact, what would the overall risk level be when these two dimensions of risk are viewed together? How do their values affect each other? NIST Special Publication 800-30 offers a good example of how risk is calculated using qualitative analysis.

NOTE    NIST SP 800-30 refers to numerical scales as semiquantitative values since they are numerical values that can be used in calculations but are still subjective in nature (in other words, they cannot be independently derived or repeated and are based upon informed opinion).

In  Figure 4-1 , taken from NIST SP 800-30, you can see how the relationships of likelihood and impact affect different risk levels. The values of each are correlated, and a qualitative risk determination results. For example, according to this figure, a  moderate level of likelihood combined with a  very high level of impact results in a level of risk determined as  high. The determination of what constitutes a likelihood of moderate and what is required for an impact level of very high is subjective but should be defined within the organization for consistency and standardization.

Figure 4-1    Qualitative assessment of risk (courtesy of NIST SP 800-30)

Combining Quantitative and Qualitative Techniques

If you are thinking that a qualitative or quantitative assessment alone may not be enough to adequately capture the different elements of risk and develop an overall risk determination, you’re absolutely right. While there are instances where each of these techniques can be used alone, in a majority of situations they are used together, to varying degrees. Each technique is good at producing a valuable piece of the puzzle, but sometimes you need both a quantitative perspective and a qualitative perspective on risk. For example, in the scenario we described earlier for quantitative risk, say you have numerical values for AV, EF, SLE, and ALE. These values account primarily for impact. However, suppose you don’t have enough solid information for a calculation of likelihood. You might have to give it a “best guess” that comes from a reasonably well-thought-out analysis, using anecdotal data or another type of data that can’t necessarily be quantified, but is a fairly accurate predictor. You may have to assign likelihood values that are semiquantitative or the subjective High, Medium, and Low values. There also might be other subjective factors that contribute to these values, so you would not have a purely quantitative assessment. Suppose you added “customer confidence” or “reputation” into the discussion on impact or loss to the company, for instance. Those would almost have to be qualitative values, so the assessment couldn’t always be expressed in exact numerical terms that are easily repeatable or defendable.

In practice, most risk assessments are usually qualitative with some quantitative elements to them, or vice versa. There are usually few purely quantitative or entirely qualitative assessments performed. You should understand the elements and characteristics of both, however, for the exam and your profession.

Exercise 4-1: Performing Qualitative and Quantitative Assessments

Using the quantitative and qualitative techniques described earlier, go through the basic process of performing assessments with each technique. Use realistic assets and values from your organization or fictitious values and assets. What additional factors should you include that may affect these values? Do you find that some values can’t be quantified using numerical values?

Other Analysis Techniques

Now that you know the basics of qualitative and quantitative techniques, there are a few specific techniques, based upon both of these methods, which we will discuss here so you are familiar with them for the exam. Note that there are dozens of different techniques that professionals have developed over the years to assess risk; you’ll find that a majority of them fall into either the qualitative or quantitative methodology. The ISO/IEC 31010:2009 standard we briefly described earlier lists more than 30 such techniques in its appendixes. Some of them approach assessments from different directions, but most of them have several things in common. We’ll discuss just a few of these in the next sections.

Fault- and Event-Tree Analysis

A fault-tree analysis is a method where the analyst starts with a risk event and looks for all possible causes of the event. This is diagrammed as a tree, with the risk event at the root and the causes extending away as branches. This analysis is used to discover all of the potential causes of the event (threats and threat actors in this case) so that they can be further analyzed for likelihood. Similar to the fault tree, the event-tree analysis is also diagrammed as a tree structure but takes the opposite approach (bottom-up as opposed to top-down). In event-tree analysis, an initiating event is at the root of the tree, with all possible consequences (impacts) diagrammed from the root as branches (as opposed to causes of the event in fault-tree analysis). Both fault tree and event tree are predictive analysis tools; in other words, they seek to predict relationships between causes, events, and consequences.  Figures 4-2  and  4-3  show examples of both fault-tree and event-tree analysis diagrams, respectively.

Figure 4-2    An example of a fault-tree analysis diagram

Figure 4-3    An example of an event-tree analysis diagram

In  Figure 4-2 , a risk event (in this case, a firewall failure) is shown, with the potential causes shown as no rule configured, a firewall appliance failure, and unknown or unusual traffic. Note that the risk event itself is the root of the tree. Conversely, in  Figure 4-3 , an event-tree diagram, the risk event (in this case, a break-in to a corporate facility) is also at the root, but the branches leading away are the potential consequences, not the causes.

Bow-Tie Analysis

A bow-tie analysis uses diagrams to analyze and explain relationships between various elements of risk, from causes (threats) to events and then to impacts (consequences). It is similar to both the fault-tree analysis and the event-tree analysis since it looks at the various causes of a risk event (fault tree) and also analyzes the consequences of the event (event tree). The difference, however, is that the bow-tie analysis looks at the intervening characteristics of the events and causes, such as the path by which the cause leads to the event and then the consequences.  Figure 4-4  illustrates a bow-tie diagram. In this figure, the negative event is shown as the center of the bow tie, with potential causes on the left and possible consequences on the right.

Figure 4-4    An example of a bow-tie analysis diagram

Other Methods

As mentioned, there are too numerous other methods that exist to perform the different types of assessments to mention here. Some of these methods focus on data collection, while others emphasize different group analysis techniques. All are, again, some variation of either the qualitative or quantitative method and may require looking at specific aspects of data to determine various elements of risk. Other examples of these techniques include the Delphi method, which centers on expert opinion from questionnaires; the Bayesian analysis method, which uses data distribution and statistical inference to determine risk probability values, checklists, scenario analysis, and business impact assessment (briefly described in  Chapter 2 ); root-cause analysis (discussed further in  Chapter 6 ); and various collaborative techniques, such as brainstorming. You won’t be expected to know all of these methods for the exam, but you should be familiar at least with the concepts of qualitative and quantitative analysis and some of the techniques that use each. For further knowledge on various assessment and analysis techniques, consult with ISO/IEC 31010:2009.

EXAM TIP    You will not have to know any particular risk assessment method in detail for the exam, but you should understand how the qualitative and quantitative methods work.

Risk Analysis

Now that you’ve assessed impact and likelihood (using any of several qualitative or quantitative methods), it’s time to perform the risk analysis. Risk analysis is just an extension of what you’ve been doing all along so far; a risk analysis looks at impact and likelihood values and determines what the level of risk is for a particular system, an asset, or even the entire organization. Part of risk analysis involves discussing findings with risk and control owners, as well as senior managers in the organization. During this discussion, you may discover other factors that influence the levels of likelihood and impact or even affect threats, vulnerabilities, and assets. You’ll also look at the existing controls and determine how effective they really are in meeting risk, as well as recommend additional controls. Finally, after this process is complete, you will report risk analysis results to senior managers and generate a risk report. We’ll discuss all of these topics in more detail in this section.  Figure 4-5  shows a familiar variation of the 5×5 likelihood and impact table, demonstrating how different levels of likelihood and impact are evaluated together to produce a qualitative risk level.

Figure 4-5    Likelihood and impact are evaluated together to produce a risk level.

Control Analysis

In this section, we will discuss control analysis in detail. You’ll also receive some more in-depth information on controls in the next three chapters, focusing on different aspects of how controls are designed, implemented, and used to respond to risk. It’s important to understand how controls fit into the overall risk analysis process; you perform a control analysis before actually determining risk since existing controls that are already in place may be effective to varying degrees in mitigating risk. Simply examining threats, vulnerabilities, assets, impact, and likelihood without taking into account existing controls and protections in place doesn’t do justice to the risk analysis process. Not accounting for existing controls would dramatically skew risk assessments and render an unrealistic risk determination. The goal here is to examine existing controls, determine how effective they are, and use that determination in analyzing the impact to assets if threats exploit vulnerabilities, as well as the likelihood of that exploitation. Typically, results of your documentation, observation, interviews, and testing will likely also be part of your control analysis. We’ll look at different aspects of control analysis in the next few sections.

Evaluating Existing Control Effectiveness

As we stated earlier, part of risk analysis involves evaluating the effectiveness of existing controls. The reason for this is that risk doesn’t exist in a vacuum filled with only threats, vulnerabilities, and assets. Almost all assets have some type of controls that serve to protect them from harm. These controls may not be sufficient enough to protect against certain threats. In some cases, however, a control may be implemented that significantly lowers the risk to an asset by decreasing the likelihood of a threat exploiting a vulnerability or by protecting the asset sufficiently enough to reduce the impact in the event a threat is realized. This is part of the risk assessment and analysis process, which involves not only identifying and prioritizing assets and performing threat and vulnerability assessments but also determining what controls exist and how effective they are in protecting against identified risk.

As previously described, controls fall into three broad categories: administrative, technical, and physical or operational controls. We’ve also described how controls can be categorized based upon function, classifying them as preventive, deterrent, detective, and other critical control functions. When identifying controls that apply to a given resource, process, asset, or system, you should look at all of these different categories to determine exactly what controls exist. Administrative controls will be in the form of policies or procedures and can serve to protect an asset by detailing requirements that users must abide by. Technical controls can serve to protect assets by providing logical protections, which might include strong authentication, restrictive permissions, and other access controls. Physical and operational controls can provide asset protection in the form of operational procedures and physical barriers, which separate unauthorized persons from the asset and prevent them from physically accessing the asset. Consider all these different categories of controls when attempting to identify any controls that may be providing protection for assets.

Once you have identified all the different controls that are protecting a given asset, you should determine what functions they are required to serve and how well they’re performing that function. Controls are designed to perform different security functions (in some cases only one but often many different functions). Economy of use is one important aspect of applying controls to assets; organizations that are able to use fewer controls to cover more security functions are able to reduce costs and more effectively use the resources they have.

Just as threats and vulnerabilities are often paired together, controls are often identified that match up with specific threats or vulnerabilities. While we discuss the value of performing threat and vulnerability assessments, seemingly as separate activities, often they are conducted simultaneously, along with control analysis, to get a better idea of how these three elements balance with each other. Threats exploit vulnerabilities; however, controls can reduce the likelihood of threat exploitation, as well as mitigate the weaknesses that vulnerabilities provide. So, there is a relationship between these three elements, making it valuable to sometimes look at all three of them simultaneously in a concerted effort.

In assessing control effectiveness, you should examine how well a particular control protects against a given threat or reduces a particular vulnerability. This can be a subjective process but can be more objective if performed as part of an in-depth penetration test (discussed in  Chapter 6 ). For example, a threat assessment may give you only the potential threat events that could affect a given asset, and a vulnerability assessment may tell you only what potential vulnerabilities exist on the system. Neither tells you how effective a control may actually be in reducing the effects of the threat or vulnerability, unless you actually attempt to exploit the vulnerability during penetration testing. Only then will you truly know how effective the control really is; if a given vulnerability isn’t easily exploitable, then realistically the control may be more effective than a cursory review would indicate. Likewise, a penetration test may indicate that a control is not as effective as you might have originally thought. Remember that vulnerability assessments describe theoretical weaknesses, whereas penetration tests actually attempt to exploit vulnerabilities and can give more realistic estimates of how effective controls really are.

When evaluating controls, you may report them as part of a risk analysis as ineffective, partially effective, or effective in reducing impact or likelihood. You also might use a semiquantitative scale that indicates control effectiveness from a range of numerical values. Often, different control frameworks also provide guidance on assessing the effectiveness of the controls in that particular framework. For example, the catalog of controls found in NIST’s Special Publication 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations,” is supplemented by an assessment methodology found in its companion volume, Special Publication 800-53A, “Assessing Security and Privacy Controls in Federal Information Systems and Organizations,” which describes how to assess and report the effectiveness of each control.  Figure 4-6  shows an example of a NIST control, from SP 800-53, and  Figure 4-7  shows the corresponding assessment guidance for the same control in SP 800-53A.

Figure 4-6    The AC-5 control from NIST SP 800-53

Figure 4-7    Assessing the AC-5 control, from NIST SP 800-53A

EXAM TIP    Control analysis includes identifying controls, determining their required function, determining whether they are effective in meeting that function, and identifying gaps between the desired and end states of how well controls protect assets.

Control Gaps

A control gap is a situation where existing controls are not sufficient to provide adequate protection for an asset, reducing either impact or likelihood (and thereby risk) to an acceptable level. In this situation, after the lack of effectiveness of the control is established, the organization has to look at remediating the situation. We won’t go too much in-depth on remediation here; that’s really the subject of the Risk Response domain that you’ll read about in the next chapter. However, during your analysis, you must identify control gaps and may even make recommendations as to possible response options that would close those gaps. You may identify gaps in physical, technical, or administrative controls, even when there are other types of controls present that perform some security and protection functions. For example, if an organization is implementing account management processes, such as creating accounts in a standardized fashion, verifying identities before user accounts are created, and so on, then it has operational and technical controls in place that help provide secure account management. However, if the organization has no written policy in place that actually requires this process and dictates that it be performed in a consistent manner, how can the organization be assured that these procedures will always be followed uniformly and in a secure manner? If there is no policy, then the organization leaves it up to individual account operators to perform this function as they want, regardless of how “most people do it.” In this case, a control gap would be that although the organization is applying some level of control over this process, there is no written policy ensuring that it is standardized.

Control Recommendations

Once you’ve identified existing controls, determined how effective they are, and identified gaps between the current and desired end states of controls, you should be in a position to make sound, risk-based recommendations to senior managers on how controls should be supplemented, added, or changed. Recommending controls is in itself a risk-based process; remember that there is risk that you are trying to minimize, but you must balance this between control functionality and economy of resources. There are several considerations to keep in mind when making control recommendations.

•  What more could be done to supplement or change existing controls to close the gap between current and desired end states of risk?

•  Should new or different controls be applied to replace existing ones?

•  What are the costs involved in applying additional controls, and do they exceed the value of the asset or the costs to replace it?

•  Would additional controls require retooling or significantly changing the infrastructure, processes, or asset itself?

•  Would additional controls require new personnel or training for current personnel?

•  Can additional controls be implemented that also reduce risks in other areas (economy of use)?

The answers to these questions, at least some of them, will determine how you make the recommendations to management about closing the “control gap.” Both the cost of implementation and the return on investment received from implementing new controls or strengthening existing ones are going to affect management’s acceptance of the recommendations. The asset value, or impact if it were significantly damaged or lost, will also affect how well the recommendation is received. Implementing a costly control to protect an asset that is worth less in terms of impact is not usually an economically sound decision. Organizational levels of risk appetite and tolerance will also affect control recommendations since any new or additional controls must reduce risk enough to fall within those levels. In general, when recommending ways to close the control gap, whether it is by introducing new controls, modifying existing ones, or modifying the infrastructure to reduce likelihood or impact, you should do the following:

•  Try to leverage existing controls that can be used across the board to include additional assets.

•  Look for “quick wins” first—controls that are easily and inexpensively implemented (such as policies, training, procedure changes, and so on).

•  Prioritize control recommendations with risk; the greater the risk, the more attention that should be paid to those particular control gaps.

•  Be realistic in your recommendations: You can’t reduce risk to absolute zero, you don’t have all of the resources you would like at your disposal, and you don’t have to offer a 100 percent solution. Sometimes a 70 percent solution is better than a 0 percent solution.

•  Provide alternatives to your primary recommendation for each control gap. Give management alternatives based on cost, level of risk reduction, and effectiveness.

Considering Risk and Control Ownership

Risk and control ownership are issues that must be taken into account during a risk analysis. Depending upon how the organization is structured and how the risk management strategy has been developed, risk ownership may be assigned to one or several different managers, spanning multiple functional areas. This is because the risk that affects one area likely affects other areas as well, so many different people may have responsibility over affected areas and be required to deal with and respond to risk. Control ownership is also something that should be examined; often controls that provide protections for a given asset or a number of systems may not fall under the operational purview of the risk owner. Some controls span the entire organization and protect multiple assets, rather than only a specific system. These are referred to as  common controls, and the responsible entity for these controls is the  common controls provider. For example, consider physical security controls. There may be a physical security officer for the organization that is in charge of guards, personnel security, and access to secured areas. They may also be responsible for locks, closed-circuit televisions (CCTVs), and physical intrusion detection systems and alarms. All of these controls serve to protect information systems and data assets that might be in a secure data center. Risks may be presented to the person who is responsible for information systems in the data center, but the controls that serve to protect them may belong to the physical security functional area. This will require some coordination between the different functional areas if controls managed by one functional area are insufficient to protect assets managed by another area. This may also affect organizational structures, budget, and allocation of resources.

CAUTION    Risk, asset, and control owners are not always the same person, functional area, or even organization. It’s important that you identify these particular owners early in the assessment process and maintain careful coordination and communication between these and other relevant stakeholders, within the boundaries of your authority and assessment scope. Different types of owners can result in politically sensitive issues that revolve around resourcing, responsibility, accountability, and, sometimes, blame.

Reporting Risk Assessment Results

After the risk assessment is performed, the results are reported to the key managers in the organization. Most organizations have their own methods for generating formal reports, which may include detailed reports that describe technical deficiencies or simply high-level reports or briefings that describe risk on a generalized basis. Some risk reports may also map IT risk to business processes in order to communicate exactly how IT risk affects business operations. In any case, determining risk and framing it in such a manner that senior executives and managers can understand, particularly in terms of business cases, is a key part of communicating the results of risk assessment. We discuss communicating the results of the risk analysis, as well as documenting risk and updating the risk register in the next few sections.

Risk Determination

How risk is determined and defined largely depends upon the organization’s risk management strategy, on the methodology used, and, to an extent, on the organization’s risk culture, appetite, and tolerance. Some organizations may want to see risk expressed as bottom-dollar figures relating to the cost of remediation; the risk assessor’s job is also to determine and express risk as an impact on business processes. More often than not, the risk determination will be reported as both qualitative and quantitative values since cost is only one of the measurements of risk.

Risk should be determined based upon impact and likelihood values after existing controls are taken into account. The risk that is calculated at this point must be responded to by accepting it, mitigating it, transferring it, or avoiding it. After a viable risk response option is selected, there will still be risk left over; remember that this is called  residual risk and will always exist. The organization must determine whether the residual risk falls within the organization’s ranges for risk tolerance and appetite. Risk determination, and the processes that support it, should be communicated to management as well, to give them a better understanding of the scope and scale of risk.

Communicating Risk Analysis

Communicating risk results can be one of the most difficult parts of the entire process. Frequently, the risk assessor is charged with briefing not only their own managers but also managers and executives within the entire organization. This can be challenging simply because, unless their daily duties involve risk management, many of the people receiving this information won’t quite understand the purpose for the assessment, the methodology used, and how significant the findings really are. They also likely won’t understand how risk is determined. What they should understand, however, is how IT risk relates to any impact on their business processes and operations. That’s part of what should be communicated to the different stakeholders in the organization since IT risk is a subset of, and directly impacts, business risk. IT risk should be communicated in such a way that the different asset, risk, and control owners are made aware of how it affects the confidentiality, integrity, and availability of the information systems and data to support their business processes. This may require a bit of education for the stakeholders on the part of the risk assessor. While everyone may not agree with the risk assessment or like the fact that it will cost them resources to respond to it, they should be able to completely understand it and not make decisions based upon ignorance. Stakeholders should also be educated on the different risk response options available since often they will be responsible for resourcing these options from their own budgets and implementing them.

NOTE    Most organizations have formal risk reporting and communication procedures, and sometimes these also require restricting access to risk results and other information. Understand your communication requirements and restrictions before the risk assessment begins so you will know with whom, how, and how much you may communicate about these subjects.

Results Documentation

Documenting the results of a risk assessment involves carefully and accurately recording the process of assessing risk for the organization, as well as the results of that process. Documentation includes presenting an executive summary and briefly describes the risk of analysis results, as well as the general aspects of the assessment itself, including scope, limitations, delimitations, assets assessed, information owners, risk owners, and control owners. The general aspects of the assessment may also discuss timeframes and the methodology involved in the assessment. The key of this part of the assessment is that you are trying to communicate supporting information to the right people so that they have the information they need to make risk-based decisions supporting risk response. Documentation could also produce detailed technical findings, such as those that might result from threat or vulnerability assessments. Normally these are included as appendixes to the risk assessment report. In some reports, risks and findings are also mapped to controls as part of a formal risk management or compliance monitoring effort.

Documentation also involves updating the risk profile for the organization, which usually details characteristics of risk at the organizational level, as well as at the lower levels involving processes, systems, and other resources or assets. Normally, all of this documentation is reviewed by senior management, as well as the appropriate risk or control owners. Note that documentation should be carefully controlled; only appropriate people within the organization who have a valid need to know should be able to access this information, and it should be considered sensitive information for the organization.

Updating the Risk Register

Because the risk register is a living document, it should be periodically updated as risk conditions change. Obviously, risk assessments will provide updated information that should be included in the risk register, as well as information about ongoing risk response actions applied to the risk. Whether the risk register is in the form of an electronic database, spreadsheet, or other type of document, it should be easy to read and readily accessible by managers or risk owners so they can stay updated on the current risk posture of the organization. As mentioned previously, it also should be considered a sensitive, access-controlled document.  Table 4-3  shows a risk register and some sample entries.

Table 4-3    Sample Entries in a Risk Register

Exercise 4-2: Assessing Risk

Using one of the risk assessment frameworks or standards described previously, go through the basics of a mock risk management process for your organization, using all of the steps outlined in the supporting framework’s publications. Since this is only a paper-based exercise, notionally go through the different steps for characterizing systems, identifying threats, identifying vulnerabilities, and so on. Record your responses. After you have finished, review the process and your responses. Were you able to complete all steps?

Chapter Review

Risk assessments include risk identification, evaluation, and assessment. While identification involves developing risk scenarios by identifying threat agents, threat and vulnerability pairs, and the affected assets, risk evaluation looks at the likelihood and impact variables, which indicate how likely a threat and vulnerability pair is to occur, causing a significant impact to an asset. Analysis also looks at controls and rolls the assessment up into a comprehensive risk determination for the organization. In this chapter, we also further reviewed different risk management and assessment frameworks and standards, including NIST RMF, OCTAVE, the ISACA Risk IT Framework, and the ISO/IEC standards.

We also reviewed the basic generic steps of conducting a risk assessment, including risk identification, threat and vulnerability assessments, asset identification, categorization and prioritization, and control analysis. We discussed key aspects of assessment that include evaluating likelihood and impact and their relationships to the other risk elements.

We discussed the value of both qualitative and quantitative assessment methods. Quantitative techniques primarily use quantifiable numerical values, such as cost and statistical analysis, as factors in assessing likelihood and impact. Qualitative values are subjective and are not easily definable or repeatable. Qualitative values might include a range of values or designations such as High, Medium, and Low. Most risk assessments use a combination of these techniques.

Finally, we looked at other aspects of risk analysis, including control evaluation and gaps, as well as recommending additional controls for risk response. We discussed risk and control ownership and communicating risk to these stakeholders. Reporting risk and updating the risk register are also key parts of the assessment process, as are maintaining risk profiles and monitoring risk on a continual basis.