HCISSP Study Guide (2015)

Chapter 6. Information Risk Assessment

Abstract

This chapter discusses the importance and purpose of conducting information risk assessments. This includes identifying assessment control procedures, the process for conducting a risk assessment, and the process to respond and remediate risk.

Keywords

Information governance

Risk management

Security

Privacy

Risk assessment

Life cycle

Risk management activities

This chapter will help candidates

Understand risk assessment

Identify and use assessment control procedures

Understand the risk assessment process

Understand the risk response and remediation process

Introduction

Healthcare organizations have an increasing reliance on information technology and information systems to carry out their mission. These technologies and systems are subject to serious threats that can have an adverse impact on the confidentiality, integrity, and availability of organizational operations and assets. As a result, it is important that organizations implement risk assessment processes as part of an overall governance program to assist with continuously monitoring the effectiveness of administrative, physical, and technical safeguards.

Knowledge Areas

After reviewing this chapter and supporting reference materials, HCISPP candidates should comprehend the importance and purpose of conducting information risk assessments. This includes identifying assessment control procedures, the process for conducting a risk assessment, and the process to respond and remediate risk.

Understanding risk assessment

Risk assessments are a core component of any information risk management program, can be qualitative and/or quantitative in nature, and are designed to identify, estimate, and prioritize risk associated with the operation and use of information systems.

Key Terms

Let us briefly review key terms associated with information risk assessment:

Risk: Measure of the extent to which an organization is threatened by a particular event.

Information life cycle: Continuous life cycle beginning from the point information is created and ending when information is disposed or destroyed.

Threat: Any event with the potential to adversely impact the confidentiality, integrity, or availability of information systems through unauthorized access, destruction, disclosure, or modification of information, or denial of service.

Vulnerability: Sometimes referred to as exposure, any weakness in an information system such as servers, networks, and infrastructure that could be intentionally or unintentionally exploited by a threat.

Controls: Sometimes referred to as safeguards, they are techniques, methods, policies, standards, processes, procedures, guidelines, and physical devices designed to reduce the vulnerability of an information asset or likelihood of successful vulnerability exploitation by a threat.

Likelihood: Estimate of the likelihood (or probability) a threat will be motivated and capable of exploiting a vulnerability.

Impact: Expected harm or damage to an organization resulting from the successful exploitation of a vulnerability.

Risk acceptance: Decision to accept a particular risk and its associated losses assuming it falls within an organization’s risk tolerance.

Risk transfer: Decision to fully or partially transfer a particular risk and its associated losses to a third party such as vendor or insurance company.

Risk mitigation: Decision to reduce vulnerabilities through implementation of additional administrative, physical, and/or technical safeguards.

Risk avoidance: Decision to avoid taking actions or activities that would create new risk for the organization.

Life Cycle and Continuous Monitoring

As discussed in Chapter 5, the information life cycle begins when information is first created and continues until such time as the information is disposed of or destroyed. As a result, risk assessments cannot be simply one-time activities with the hope of providing long-term and definitive information, but must be performed periodically throughout the information life cycle to:

Protect the confidentiality, integrity, and availability of information; and

Guide and inform decision makers in their response to risks.

In addition to periodic risk assessments, information and systems should be continuously monitored to ensure control effectiveness and identify potential threats, events, or changes warranting risk analysis.

Tools, Resources, and Techniques

While various tools, resources, and techniques exist to assist healthcare organizations with the performance and maintenance of information risk assessments, all share similar principles and objectives. However, selection will vary based on a number of factors including, but not limited to, cost and an organization’s requirements, culture, and size.

NIST Guide for Conducting Risk Assessments

NIST’s Special Publication 800-30 provides guidance for conducting risk assessments of federal information systems and organizations. It is intended to serve a diverse group of risk management professionals including:

Individuals with oversight responsibilities for risk management (e.g., heads of agencies, chief executive officers, chief operating officers, risk executives);

Individuals with responsibilities for conducting organizational missions/business functions (e.g., mission/business owners, information owners/stewards, authorizing officials);

Individuals with responsibilities for acquiring information technology products, services, or information systems (e.g., acquisition officials, procurement officers, contracting officers);

Individuals with information system/security design, development, and implementation responsibilities (e.g., program managers, enterprise architects, information security architects, information system/security engineers, information systems integrators);

Individuals with information security oversight, management, and operational responsibilities (e.g., chief information officers, senior information security officers, information security managers, information system owners, common control providers); and

Individuals with information security/risk assessment and monitoring responsibilities (e.g., system evaluators, penetration testers, security control assessors, risk assessors, independent verifiers/validators, inspectors general, auditors).

ISO/IEC 27005:2011

The ISO/IEC 27005:2011 standard provides guidance for information security risk management including the performance of risk assessments. As described by ISO, “it supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information security based on a risk management approach.”

Desired Outcomes

The purpose of a risk assessment in terms of the information it is intended to produce and the decisions it is intended to support must be defined to achieve a desired outcome. Their intent is to inform decision makers and support risk responses by identifying:

Relevant threats to an organization;

Internal and external vulnerabilities;

Potential impact resulting from a threat exploiting a vulnerability; and

Likelihood that impact will occur or be realized.

Role of Internal and External Audit

Internal and external audit provide organizations with an independent perspective regarding information security program and control effectiveness in protecting the confidentiality, integrity, and availability of information. While internal audit departments typically review various security controls on a periodic basis, organizations should understand the Health Information Technology for Economic and Clinical Health Act (HITECH) also requires Health and Human Services (HHS) to perform periodic external audits of covered entity and business associate compliance with HIPAA Privacy, Security, and Breach Notification Rules.

Assessment procedures

As defined by NIST Special Publication 800-53A Revision 1, an assessment procedure consists of a set of assessment objectives, each with an associated set of potential assessment methods and assessment objects.

Assessment Objective

An assessment objective includes a set of determination statements related to the security control under assessment. The determination statements are linked to the content of the security control (i.e., the security control functionality) to ensure traceability of assessment results back to the fundamental control requirements. The application of an assessment procedure to a security control produces assessment findings. These assessment findings reflect, or are subsequently used, to help determine the overall effectiveness of the security control.

Assessment Object

Assessment objects identify the specific items being assessed and include specifications, mechanisms, activities, and individuals:

Specifications are the document-based artifacts (e.g., policies, procedures, plans, system security requirements, functional specifications, and architectural designs) associated with an information system.

Mechanisms are the specific hardware, software, or firmware safeguards and countermeasures employed within an information system.

Activities are the specific protection-related pursuits or actions supporting an information system that involve people (e.g., conducting system backup operations, monitoring network traffic, exercising a contingency plan).

Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described earlier.

Assessment Methods

Assessment methods define the nature of the assessor actions and include:

Examine method: The process of reviewing, inspecting, observing, studying, or analyzing one or more assessment objects (i.e., specifications, mechanisms, or activities). The purpose of the examine method is to facilitate assessor understanding, achieve clarification, or obtain evidence.

Interview method: The process of holding discussions with individuals or groups of individuals within an organization to, once again, facilitate assessor understanding, achieve clarification, or obtain evidence.

Test method: The process of exercising one or more assessment objects (i.e., activities or mechanisms) under specified conditions to compare actual with expected behavior.

In all three methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.

NIST Example

The first assessment objective for CP-2 is derived from the basic control statement (Figure 6.1). Potential assessment methods and objects are added to the assessment procedure (Figure 6.2).

FIGURE 6.1 NIST example contingency plan security control.

FIGURE 6.2 NIST example assessment procedure.

In a similar manner, the second assessment objective and potential assessment methods and objects for CP-2 are established (Figure 6.3).

FIGURE 6.3 NIST example assessment procedure (continued).

Risk assessment process

In Chapter 5 we reviewed roles and responsibilities and four key components associated with a holistic risk management process that include risk framing, assessment, response, and monitoring as outlined by NIST SP 800-30. This section focuses on the assessment component and the four-step process of assessing information security risk:

Prepare for the assessment.

Conduct the assessment.

Communicate assessment results.

Maintain the assessment.

Figure 6.4 illustrates the relationship between these steps and their supporting set of tasks discussed later in this chapter.

FIGURE 6.4 NIST risk assessment process.

Risk Assessment Hierarchy

Risk assessments can be conducted at all three tiers in the risk management hierarchy:

Tier 1 (organization level);

Tier 2 (mission/business process level); and

Tier 3 (information system level).

At Tiers 1 and 2, organizations use risk assessments to evaluate areas such as systemic information security-related risks associated with organizational governance and management activities, mission/business processes, enterprise architecture, or funding of information security programs. At Tier 3, organizations use risk assessments to more effectively support implementation of the information risk management life cycle processes and activities described in Chapter 5. Figure 6.5 illustrates the risk management hierarchy defined in NIST SP 800-39, which provides multiple risk perspectives from a strategic to tactical level. Traditional risk assessments have generally focused on Tier 3, which can result in overlooking other significant risk factors more appropriately assessed at Tiers 1 or 2. Risk assessments also support risk response decisions at different tiers of the risk management hierarchy.

FIGURE 6.5 NIST risk management hierarchy.

Tier 1: Organizational Level

At Tier 1, risk assessments support organizational strategies, policies, guidance, and processes for managing risk. Risk assessments conducted at Tier 1 focus on organizational operations, assets, and individuals – comprehensive assessments across mission/business lines. For example, Tier 1 risk assessments may address:

The specific types of threats directed at an organization and how those threats affect policy decisions;

Systemic weaknesses or deficiencies discovered in multiple organizational information systems capable of being exploited by threats;

The potential adverse impact on organizations from the loss or compromise of organizational information (either intentionally or unintentionally); and

The use of new information and computing technologies such as mobile and cloud and the potential effect on the ability of organizations to successfully carry out their missions/business operations while using those technologies.

Tier 1 risk assessments can also affect:

Organization-wide information security programs, policies, procedures, and guidance;

Risk management organizational structure;

The types of appropriate risk responses or treatments;

Investment and procurement decisions for information technologies/systems;

Minimum organization-wide security controls;

Conformance to enterprise/security architectures; and

Monitoring strategies and ongoing authorizations of information systems and common controls.

Tier 2: Mission/Business Process

At Tier 2, risk assessments support the determination of mission/business process protection and resiliency requirements. They also support the allocation of these requirements to enterprise architecture. This allocation is accomplished through an information security architecture embedded within the enterprise architecture. Tier 2 risk assessments also inform and guide decisions on whether, how, and when to use information systems for specific mission/business processes, in particular for alternative mission/business processing in the face of compromised information systems. Tier 2 risk assessments can also affect:

Enterprise architecture/security architecture design decisions;

The selection of common controls and suppliers, services, and contractors to support organizational missions/business functions;

The development of risk-aware mission/business processes; and

The interpretation of information security policies with respect to organizational information systems and environments in which those systems operate.

Tier 3: Information System

The Tier 2 context and the system development life cycle determine the purpose and define the scope of risk assessment activities at Tier 3. While initial risk assessments (those performed for the first time vs. updating prior risk assessments) can be performed at any phase in the system development life cycle, they should be performed ideally during the initiation phase. In the initiation phase, risk assessments evaluate the anticipated vulnerabilities and presumed conditions affecting the confidentiality, integrity, and availability of information systems in the context of the planned operational environment. Such assessments inform risk response, enabling information system owners/program managers and mission/business owners to make the final decisions about the necessary security controls based on the security categorization and environment of operation. Risk assessments are also conducted at later phases in the system development life cycle and update risk assessment results from earlier phases. These risk assessment results for as-built or as-deployed information systems typically include descriptions of vulnerabilities in the systems, an assessment of the risks associated with each vulnerability (thereby updating the assessment of vulnerability severity), and corrective actions that can be taken to mitigate the risks. Tier 3 risk assessments can also affect:

Design decisions (including the selection, tailoring, and supplementation of security controls and the selection of information technology products for organizational information systems);

Implementation decisions (including whether specific information technology products or product configurations meet security control requirements); and

Operational decisions (including the requisite level of monitoring activity, the frequency of ongoing information system authorizations, system maintenance decisions, and possibly addition of controls to address coverage gaps).

Step 1: Prepare

The first step in the process is assessment preparation and involves five supporting tasks:

Identify purpose.

Identify scope.

Identify assumptions and constraints.

Identify information sources.

Identify risk model and analytic approach.

Task 1-1: Identify Purpose

Identify the purpose of the risk assessment in terms of the information that the assessment is intended to produce and the decisions the assessment is intended to support. The purpose should be explicitly stated in sufficient detail to ensure the assessment produces the appropriate information and supports the intended decisions. Each organization can determine how best to capture and present information produced during the risk assessment.

At Tier 1, risk assessments:

Support the risk executive (function); and

Serve as a key input to the risk management strategy.

At Tier 2, risk assessments enable organizations to:

Understand dependencies and ways in which risks are treated among information systems that support organizational mission/business processes;

Support architectural and operational decisions for organizational risk responses;

Identify trends to enable proactive risk response strategies and courses of action for mission/business processes to be defined; and

Support reciprocity, particularly to enable information sharing.

At Tier 3, risk assessments support:

Authorization-related decisions throughout the system development life cycle;

Reciprocity, particularly for reuse of assessment information;

Risk management activities at Tier 2; and

Programmatic risk management activities throughout the system development life cycle.

Risk assessments can also have a very specific purpose such as answering a question (e.g., What are the risk implications of a newly discovered vulnerability or class of vulnerabilities, allowing new connectivity, outsourcing a specific function, or adopting a new technology?). The purpose of a risk assessment is influenced by whether it is an initial assessment (first time) or a subsequent assessment initiated from the risk response or monitoring steps in the risk management process.

For initial assessments, the purpose can include:

Establishing a baseline assessment of risk; or

Identifying threats and vulnerabilities, impacts to organizational operations and assets, individuals, and other organizations, and other risk factors to be tracked over time as part of risk monitoring.

For reassessments, the purpose can include:

Providing a comparative analysis of alternative risk responses or answering a specific question;

Updating the risk assessment based on:

• Ongoing determinations of the effectiveness of security controls in organizational information systems or operational environments;

• Changes to information systems or operational environments (e.g., changes to hardware, firmware, software; changes to system-specific, hybrid, or common controls; changes to mission/business processes, common infrastructure and support services, threats, vulnerabilities, or facilities); and

• Results from compliance verification activities.

Reassessments may also be initiated by organizations due to incidents that have occurred (e.g., cyber attacks compromising organizational information or information systems).

Task 1-2: Identify Scope

Identify the scope of the risk assessment in terms of organizational applicability, time frame supported, and architectural/technology considerations. The scope determines what will be considered in the assessment, affects the range of information available to make risk-based decisions, and is determined by the organizational official requesting the assessment and the risk management strategy. Establishing the scope of the risk assessment helps organizations to determine:

What tiers are addressed in the assessment;

What parts of organizations are affected by the assessment and how they are affected;

What decisions the assessment results support;

How long assessment results are relevant; and

What influences the need to update the assessment.

Establishing the scope of the risk assessment also helps to determine the form and content of the risk assessment report, as well as the information to be shared as a result of conducting the assessment. At Tier 3, the scope of a risk assessment can depend on the authorization boundary for the information system.

Organizational Applicability

Organizational applicability describes which parts of the organization or suborganizations are affected by the risk assessment and resulting risk-based decisions. For example, the risk assessment can inform decisions regarding information systems supporting a particular organizational mission/business function or process. This can include decisions regarding the selection, tailoring, or supplementation of security controls for specific information systems or the selection of common controls. Alternatively, the risk assessment can inform decisions regarding a set of closely related missions/business functions or processes. The scope of the risk assessment may include not only the missions/business functions, mission/business processes, common infrastructure, or shared services on which the organization currently depends but also those which the organization might use under specific operational conditions.

Effectiveness Time Frame

Organizations determine how long the results of particular risk assessments can be used to legitimately inform risk-based decisions, which is usually related to assessment purpose. For example, a risk assessment to inform Tier 1 policy-related decisions needs to be relevant for an extended period of time since the governance process for policy changes can be time-consuming in many organizations. On the other hand, a risk assessment conducted to inform a Tier 3 decision regarding the use of a compensating security control for an information system may be relevant only until the next release of the information technology product providing the required security capability. Organizations determine the useful life of risk assessment results and under what conditions the current assessment results become ineffective or irrelevant. Risk monitoring can also be used to help determine the effectiveness of time frames for risk assessments and the need to refresh existing controls to address a changing threat landscape.

Architectural/Technology Considerations

Organizations use architectural and technology considerations to clarify the scope of the risk assessment. At Tier 2, for example, the scope of the risk assessment can be defined in terms of the mission/business segment architecture (e.g., including all systems, services, and infrastructures that support a specific mission/function). For a targeted risk assessment at any tier, the specific question to be answered can restrict the scope to a specific technology. At Tier 3, for example, the scope of the risk assessment can be an organizational information system in its operational environment. This entails placing the information system in its architectural context, so that vulnerabilities within inherited controls can be taken into consideration. Alternately, the scope of the assessment can be limited solely to the information system, without consideration of inherited vulnerabilities.

Task 1-3: Identify Assumptions and Constraints

Identify the specific assumptions and constraints under which the risk assessment is conducted. As part of the risk framing step in the risk management process, organizations make explicit the specific assumptions, constraints, risk tolerance, and priorities/trade-offs used within organizations to make investment and operational decisions, which guides and informs organizational risk assessments. When an organizational risk management strategy cannot be cited, risk assessments identify and document assumptions and constraints. Assumptions and constraints identified by organizations during the risk framing step and included as part of the organizational risk management strategy need not be repeated in each individual risk assessment. By making assumptions and constraints explicit, there is greater clarity in the risk model selected for the risk assessment, increased reproducibility/repeatability of assessment results, and an increased opportunity for reciprocity among organizations. Organizations identify assumptions in key areas relevant to the risk assessment including, for example:

Threat sources and events;

Vulnerabilities and predisposing conditions;

Potential impacts;

Assessment and analysis approaches; and

Which missions/business functions are primary.

Organizations also identify constraints in key areas relevant to the risk assessment including, for example:

Resources available for the assessment;

Skills and expertise required for the assessment; and

Operational considerations related to mission/business activities.

Finally, organizations consider the uncertainty with regard to assumptions made or other information used in the risk assessment, as uncertainty can affect organizational risk tolerance. For example, assumptions based on a lack of specific or credible information may reduce an organization’s risk tolerance because of the uncertainty influencing the assumptions. The following are examples of areas where assumptions/constraints for risk assessments may be identified.

Threat Sources

Organizations need to determine which types of threat sources are to be considered during risk assessments. Organizations make explicit the process used to identify threats and any assumptions related to the threat identification process. If such information is identified during the risk framing step and included as part of the organizational risk management strategy, the information need not be repeated in each individual risk assessment. Risk assessments can address all types of threat sources, a single broad threat source (e.g., adversarial) or a specific threat source (e.g., trusted insider).

Threat Events

Organizations need to determine which type of threat events are to be considered during risk assessments and the level of detail needed to describe such events. Descriptions of threat events can be expressed in highly general terms (e.g., phishing, distributed denial-of-service), in more descriptive terms using tactics, techniques, and procedures, or in highly specific terms (e.g., the names of specific information systems, technologies, organizations, roles, or locations). In addition, organizations consider what representative set of threat events can serve as a starting point for the identification of the specific threat events in the risk assessment and what degree of confirmation is needed for threat events to be considered relevant for purposes of the risk assessment. For example, organizations may consider only those threat events that have been observed (either internally or by organizations that are peers/partners) or all probable threat events.

Vulnerabilities and Predisposing Conditions

Organizations need to determine the types of vulnerabilities that are to be considered during risk assessments and the level of detail provided in the vulnerability descriptions. Organizations make explicit the process used to identify vulnerabilities and any assumptions related to the vulnerability identification process. If such information is identified during the risk framing step and included as part of the organizational risk management strategy, the information need not be repeated in each individual risk assessment. Vulnerabilities can be associated with organizational information systems (e.g., hardware, software, firmware, internal controls, and security procedures) or the environments in which those systems operate (e.g., organizational governance, external relationships, mission/business processes, enterprise architectures, information security architectures). Organizations also determine the types of conditions that are to be considered during risk assessments including, for example, architectures and technologies employed, operational environments, and personnel.

Likelihood

Organizations need to make explicit the process used to conduct likelihood determinations and any assumptions related to the likelihood determination process. If such information is identified during the risk framing step and included as part of the organizational risk management strategy, the information need not be repeated in each individual risk assessment.

Impacts

Organizations need to determine potential adverse impacts in terms of organizational operations (i.e., missions, functions, image, and reputation), organizational assets, individuals, and other organizations. Organizations make explicit the process used to conduct impact determinations and any assumptions related to the impact determination process. If such information is identified during the risk framing step and included as part of the organizational risk management strategy, the information need not be repeated in each individual risk assessment. Organizations address impacts at a level of detail that includes, for example, specific mission/business processes or information resources (e.g., information, personnel, equipment, funds, and information technology). Organizations may include information from an impact analysis with regard to providing impact information for risk assessments.

Risk Tolerance and Uncertainty

Organizations need to determine the levels and types of risk that are acceptable. Risk tolerance is determined as part of the organizational risk management strategy to ensure consistency across the organization. Organizations also provide guidance on how to identify reasons for uncertainty when risk factors are assessed, since uncertainty in one or more factors will propagate to the resulting evaluation of level of risk, and how to compensate for incomplete, imperfect, or assumption-dependent estimates. Consideration of uncertainty is especially important when organizations consider advanced persistent threats (APTs) since assessments of the likelihood of threat event occurrence can have a great degree of uncertainty. To compensate, organizations can take a variety of approaches to determine likelihood, ranging from assuming the worst-case likelihood (certain to happen sometime in the foreseeable future) to assuming that if an event has not been observed, it is unlikely to happen. In determining likelihood, they should also consider the probability of an attack being attempted and its probability of success. Organizations also determine what levels of risk (combination of likelihood and impact) indicate that no further analysis of any risk factors is needed.

Analytic Approach

Risk assessments include both assessment approaches (i.e., quantitative, qualitative) and analysis approaches (i.e., threat-oriented, asset/impact-oriented, vulnerability-oriented). Together, the assessment and analysis approaches form the analytic approach for the risk assessment. Organizations determine the level of detail and the form in which threats are analyzed including the level of granularity to describe threat events or threat scenarios. Different analysis approaches can lead to different levels of detail in characterizing adverse events for which likelihoods are determined. For example, an adverse event could be characterized in several ways (with increasing levels of detail):

A threat event (for which the likelihood is determined by taking the maximum overall threat sources);

A pairing of a threat event and a threat source; or

A detailed threat scenario/attack tree.

In general, organizations can be expected to require more detail for highly critical missions/business functions, common infrastructures, or shared services on which multiple missions or business functions depend (as common points of failure), and information systems with high criticality or sensitivity. Mission/business owners may also amplify this guidance for risk hot spots (e.g., information systems, services, or critical infrastructure components of particular concern) in mission/business segments.

Task 1-4: Identify Information Sources

Identify the sources of descriptive, threat, vulnerability, and impact information to be used in the risk assessment. Descriptive information enables organizations to be able to determine the relevance of threat and vulnerability information.

At Tier 1, descriptive information can include:

The type of risk management and information security governance structures in place within organizations; and

How the organization identifies and prioritizes critical missions/business functions.

At Tier 2, descriptive information can include information about:

Organizational mission/business processes, functional management processes, and information flows;

Enterprise architecture, information security architecture, and the technical/process flow architectures of the systems, common infrastructures, and shared services that fall within the scope of the risk assessment; and

The external environments in which organizations operate including the relationships and dependencies with external providers.

Such information is typically found in architectural documentation (particularly documentation of high-level operational views), business continuity plans, and risk assessment reports for organizational information systems, common infrastructures, and shared services that fall within the scope of the risk assessment.

At Tier 3, descriptive information can include information about:

The design of and technologies used in organizational information systems;

The environment in which the systems operate;

Connectivity to and dependency on other information systems; and

Dependencies on common infrastructures or shared services.

Such information is found in system documentation, contingency plans, and risk assessment reports for other information systems, infrastructures, and services. Sources of information can be either internal or external to organizations. Internal sources of information that can provide insights into both threats and vulnerabilities can include risk assessment reports, incident reports, security logs, trouble tickets, and monitoring results. Note that internally, information from risk assessment reports at one tier can serve as input to risk assessments at other tiers. Mission/business owners are encouraged to identify not only common infrastructure and/or support services they depend on but also those they might use under specific operational circumstances. External sources of threat information can include cross-community organizations [e.g., US Computer Emergency Readiness Team (US-CERT), Information Sharing and Analysis Centers (ISACs) for critical infrastructure sectors], research and nongovernmental organizations (e.g., Carnegie Mellon University, Software Engineering Institute – CERT), and security service providers. Organizations using external sources should consider the timeliness, specificity, and relevance of threat information. Similar to sources of threat information, sources of vulnerability information can also be either internal or external to organizations. Information about predisposing conditions can be found in a variety of sources including descriptions of information systems, operational environments, shared services, common infrastructures, and enterprise architecture. Sources of impact information can include mission/business impact analyses, information system component inventories, and security categorizations. Security categorization constitutes a determination of the potential impacts should certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned missions, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals. Security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to organizational operations and assets, individuals, and other organizations. Security categories constitute an initial summary of impact in terms of failures to meet the security objectives of confidentiality, integrity, and availability, and are informed by types of harm.

Task 1-5: Identify Risk Model and Analytic Approach

Identify the risk model and analytic approach to be used in the risk assessment. Organizations need to define one or more risk models for use in conducting risk assessments and identify which model is to be used for the risk assessment. To facilitate reciprocity of assessment results, organization-specific risk models include, or can be translated into, the risk factors (i.e., threat, vulnerability, impact, likelihood, and predisposing condition). Organizations also identify the specific analytic approach to be used for the risk assessment including the assessment approach (i.e., quantitative, qualitative) and the analysis approach (i.e., threat-oriented, asset/impact-oriented, vulnerability-oriented). Organizations typically define the assessment scales to be used in their risk assessments and can identify different assessment scales to be used in different circumstances. For example, for low-impact information systems, organizations could use qualitative values, while for moderate- and high-impact systems, the most granular semiquantitative values (0–100) could be used. As discussed in NIST Special Publication 800-39, Task 1-1, Risk Assumptions, organizations vary in the relative weights applied to risk factors. Therefore, this guideline does not specify algorithms for combining semiquantitative values. Organization-specific risk models include algorithms (e.g., formulas, tables, rules) for combining risk factors. If an organization-specific risk model is not provided in the risk management strategy as part of the risk framing step, then part of this task is to specify the algorithms for combining values. Algorithms for combining risk factors reflect organizational risk tolerance. Organization-specific risk models are refined as part of preparation for a risk assessment by:

Identifying the risk model and the rationale for using it (when multiple organization-specific risk models are provided);

Providing additional examples for values of risk factors; and

Identifying any assessment-specific algorithms.

In the absence of preexisting organization-specific risk models or analytic approaches defined in the organizational risk management strategy, the risk model and analytic approaches to be used in the risk assessment are defined and documented as part of this task (Figure 6.6).

FIGURE 6.6 NIST key activities – assessment preparation.

Step 2: Conduct the Assessment

The second step in the risk assessment process is to conduct the assessment with the objective of producing a list of information security risks that can be prioritized by risk level and used to inform risk response decisions. To accomplish this objective, organizations analyze threats and vulnerabilities, impacts and likelihood, and the uncertainty associated with the risk assessment process. This step also involves the gathering of essential information as a part of each task and is conducted in accordance with the assessment context established in the Prepare step of the risk assessment process. The expectation for risk assessments is to adequately cover the entire threat space in accordance with the specific definitions, guidance, and direction established during the Prepare step. However, in practice, adequate coverage within available resources may dictate generalizing threat sources, threat events, and vulnerabilities to ensure full coverage and assessing specific, detailed sources, events, and vulnerabilities only as necessary to accomplish risk assessment objectives. Conducting a risk assessment includes:

Identifying threat sources relevant to the organization;

Identifying threat events that could be produced by threat sources;

Identifying vulnerabilities that could be exploited by threat sources through specific threat events;

Determining likelihood that threat sources would initiate specific threat events and the likelihood that the threat events would be successful;

Determining adverse impacts resulting from vulnerability exploitation; and

Determining information security risks as a combination of likelihood of threat exploitation of vulnerabilities and its associated impact.

Task 2-1: Identify Threat Sources

Identify and characterize threat sources of concern, including capability, intent, and targeting characteristics for adversarial and nonadversarial threats and the range of effects for nonadversarial threats. Organizations need to identify threat sources of concern and determine the characteristics associated with those threat sources. For adversarial threat sources, assess the capabilities, intentions, and targeting associated with the threat sources. For nonadversarial threat sources, assess the potential range of effects from the threat sources. The risk management strategy and the results of the Prepare step provide organizational direction and guidance for conducting threat source identification and characterization including:

Sources for obtaining threat information;

Threat sources to consider (by type/name);

Threat taxonomy to be used; and

The process for identifying threat sources of concern for the risk assessment.

As identified in Task 1-3, organizations make explicit any assumptions concerning threat sources including decisions regarding the identification of threat sources when specific and credible threat information is unavailable. Organizations can also view adversarial threat sources from a broad-based perspective, considering the time such threat sources may have to exploit identified organizational vulnerabilities, the scale of the attack, and the potential use of multiple attack vectors. The identification and characterization of APTs can involve considerable uncertainty, so organizations should annotate such threat sources with appropriate rationale and references.

Task 2-2: Identify Threat Events

Identify potential threat events, relevance of the events, and the threat sources that could initiate the events. Threat events are characterized by the threat sources that could initiate the events, and, for adversarial events, the procedures used to carry out attacks. Organizations define these threat events with sufficient detail to accomplish the purpose of the risk assessment. At Tier 1, threat events that could affect the organizational level are of particular interest. At Tier 2, threat events that cross or span information system boundaries, exploit functional dependencies or connectivity among systems, or affect mission/business owners are of particular interest. At Tier 3, threat events that can be described in terms of specific information systems, technologies, or operational environments are of particular interest. While multiple threat sources can initiate a single threat event, conversely a single threat source can potentially initiate any of multiple threat events. As a result, there can be a many-to-many relationship among threat events and threat sources that can potentially increase the complexity of the risk assessment. To enable effective use and communication of risk assessment results, organizations tailor the general descriptions of threat events to identify how each event could potentially harm organizational operations (including mission, functions, image, or reputation) and assets, individuals, or other organizations. For each threat event identified, organizations determine the relevance of the event using a range of values. These values have a direct linkage to organizational risk tolerance. The more risk averse, the greater the range of values considered. Organizations accepting greater risk or having a greater risk tolerance are more likely to require substantive evidence before giving serious consideration to threat events. If a threat event is deemed to be irrelevant, no further consideration is given. For relevant threat events, organizations identify all potential threat sources that could initiate the events. For use in Task 2-4, organizations can identify each pairing of threat source and threat event separately since the likelihood of threat initiation and success could be different for each pairing. Alternatively, organizations can identify the set of all possible threat sources that could potentially initiate a threat event.

Task 2-3: Identify Vulnerabilities and Conditions

Identify vulnerabilities and conditions that affect the likelihood that threat events of concern result in adverse impacts. The primary purpose of vulnerability assessments is to understand the nature and degree to which organizations, mission/business processes, and information systems are vulnerable to threat sources identified in Task 2-1 and the threat events identified in Task 2-2 that can be initiated by those threat sources. Vulnerabilities at Tier 1 can be pervasive across organizations and can have wide-ranging adverse impacts if exploited by threat events. For example, organizational failure to consider supply chain activities can result in organizations acquiring subverted components that adversaries could exploit to disrupt organizational missions/business functions or to obtain sensitive organizational information. Vulnerabilities at Tier 2 can be described in terms of organizational mission/business processes, enterprise architecture, the use of multiple information systems, or common infrastructures/shared services. At Tier 2, vulnerabilities typically cross or span information system boundaries. Vulnerabilities at Tier 3 can be described in terms of the information technologies employed within organizational information systems, the environments in which those systems operate, and/or the lack of or weaknesses in system-specific security controls. There is potentially a many-to-many relationship between threat events and vulnerabilities. While multiple threat events can exploit a single vulnerability, conversely multiple vulnerabilities can be exploited by a single threat event. The severity of a vulnerability is based on an assessment of the relative importance of mitigating such a vulnerability. Initially, the extent to which mitigation is unplanned can serve as a surrogate for vulnerability severity. Once the risks associated with a particular vulnerability have been assessed, a gap assessment can be performed to understand the impact severity and exposure of the vulnerability given the security controls implemented and other vulnerabilities can be taken into consideration in assessing vulnerability severity. Assessments of vulnerability severity support risk response. Vulnerabilities can be identified at varying degrees of granularity and specificity. The level of detail provided in any particular vulnerability assessment is consistent with the purpose of the risk assessment and the type of inputs needed to support follow-on likelihood and impact determinations. Due to the ever-increasing size and complexity of organizations, mission/business processes, and the information systems supporting those processes, the number of vulnerabilities tends to be large and can increase the overall complexity of the analysis. Therefore, organizations have the option of using the vulnerability identification task to understand the general nature of the vulnerabilities (including scope, number, and type) relevant to the assessment (see Task 1-3) and performing a cataloging of specific vulnerabilities as necessary to do so. Organizations determine which vulnerabilities are relevant to which threat events in order to reduce the space of potential risks to be assessed. In addition to identifying vulnerabilities, organizations also identify any predisposing conditions that may affect susceptibility to certain vulnerabilities. Predisposing conditions that exist within organizations (including mission/business processes, information systems, and environments of operation) can contribute to (i.e., increase or decrease) the likelihood that one or more threat events, once initiated by threat sources, result in adverse impacts to organizational operations, organizational assets, individuals, or other organizations. Organizations determine which predisposing conditions are relevant to which threat events in order to reduce the space of potential risks to be assessed. Organizations also assess the pervasiveness of predisposing conditions to support determination of the tier(s) at which risk response could be most effective.

Task 2-4: Determine Likelihood

Determine the likelihood that threat events of concern result in adverse impacts, considering:

The characteristics of the threat sources that could initiate the events;

The vulnerabilities/predisposing conditions identified; and

The organizational susceptibility reflecting the safeguards/countermeasures planned or implemented to impede such events.

Organizations employ a three-step process to determine the overall likelihood of threat events. First, organizations assess the likelihood that threat events will be initiated (for adversarial threat events) or will occur (for nonadversarial threat events). Second, organizations assess the likelihood that threat events once initiated or occurring will result in adverse impacts to organizational operations and assets, individuals, or other organizations. Finally, organizations assess the overall likelihood as a combination of likelihood of initiation/occurrence and likelihood of resulting in adverse impact. Organizations assess the likelihood of threat event initiation by taking into consideration the characteristics of the threat sources of concern including capability, intent, and targeting. If threat events require more capability than adversaries possess (and adversaries are cognizant of this fact), then the adversaries are not expected to initiate the events. If adversaries do not expect to achieve intended objectives by executing threat events, then the adversaries are not expected to initiate the events. And finally, if adversaries are not actively targeting specific organizations or their missions/business functions, adversaries are not expected to initiate threat events. Organizations can use the assessment scale inFigure 6.7 and provide a rationale for the assessment allowing explicit consideration of deterrence and threat shifting.

FIGURE 6.7 NIST assessment scale – likelihood of threat event initiation (adversarial).

Organizations can also assess the likelihood of threat event occurrence (nonadversarial) using Figure 6.8 and provide a similar rationale for the assessment.

FIGURE 6.8 NIST assessment scale – likelihood of threat event occurrence (nonadversarial).

Organizations assess the likelihood that threat events result in adverse impacts by taking into consideration the set of identified vulnerabilities and predisposing conditions (see Task 2-3). For threat events initiated by adversaries, organizations consider characteristics of associated threat sources. For nonadversarial threat events, organizations take into account the anticipated severity and duration of the event. Organizations can use the assessment scale in Figure 6.9 and provide a rationale for the assessment allowing explicit consideration as stated previously.

FIGURE 6.9 NIST assessment scale – likelihood of threat event resulting in adverse impacts.

Threat events for which no vulnerabilities or predisposing conditions are identified have a very low likelihood of resulting in adverse impacts. The overall likelihood of a threat event is a combination of:

The likelihood that the event will occur (e.g., due to human error or natural disaster) or be initiated by an adversary; and

The likelihood that the initiation/occurrence will result in adverse impacts.

Task 2-5: Determine Impact

Determine the adverse impacts from threat events of concern considering:

The characteristics of the threat sources that could initiate the events;

The vulnerabilities/predisposing conditions identified; and

The susceptibility reflecting the safeguards/countermeasures planned or implemented to impede such events.

Organizations describe adverse impacts in terms of the potential harm caused to organizational operations and assets, individuals, or other organizations. Where the threat event occurs and whether the effects of the event are contained or spread influence the severity of the impact. Assessing impact can involve identifying assets or potential targets of threat sources, including information resources (e.g., information, data repositories, information systems, applications, information technologies, communications links), people, and physical resources (e.g., buildings, power supplies), which could be affected by threat events. Organizational impacts are defined and prioritized at Tiers 1 and 2, and communicated to Tier 3 as part of risk framing. At Tier 3, impacts are associated with information system capabilities (e.g., processing, display, communications, storage, and retrieval) and resources (e.g., databases, services, components) that could be compromised.

Task 2-6: Determine Risk

Determine the risk to the organization from threat events of concern considering:

The impact that would result from the events; and

The likelihood of the events occurring.

Organizations assess the risks from threat events as a combination of likelihood and impact. Figure 6.10 illustrates this relationship.

FIGURE 6.10 Likelihood and impact relationship.

The level of risk associated with identified threat events represents a determination of the degree to which organizations are threatened by such events. Organizations make explicit the uncertainty in the risk determinations, including, for example, organizational assumptions and subjective judgments/decisions. Organizations can order the list of threat events of concern by the level of risk determined during the risk assessment – with the greatest attention going to high-risk events. Organizations can further prioritize risks at the same level or with similar scores. Each risk corresponds to a specific threat event with a level of impact if that event occurs. In general, the risk level is typically not higher than the impact level, and likelihood can serve to reduce risk below that impact level. However, when addressing organization-wide risk management issues with a large number of missions/business functions, mission/business processes, and supporting information systems, impact as an upper bound on risk may not hold. For example, when multiple risks materialize, even if each risk is at the moderate (or medium) level, the set of those moderate-level risks could aggregate to a higher level of risk for organizations. To address situations where harm occurs multiple times, organizations can define a threat event as multiple occurrences of harm and an impact level associated with the cumulative degree of harm. During the execution of Tasks 2-1 to 2-5, organizations capture key information related to uncertainties in risk assessments. These uncertainties arise from sources such as missing information, subjective determinations, and assumptions made. The effectiveness of risk assessment results is in part determined by the ability of decision makers to be able to determine the continued applicability of assumptions made as part of the assessment. Information related to uncertainty is compiled and presented in a manner that readily supports informed risk management decisions. Additionally, guidance should be provided to decision makers for each risk level regarding the estimated time frame (e.g., immediate; 30, 60, 90 days) to select a treatment option (e.g., acceptance, transfer, mitigate, avoid) and implement an appropriate corrective action (or remediation) plan (Figure 6.11).

FIGURE 6.11 NIST key activities – conducting the assessment.

Step 3: Communicating Risk Assessment Information

The third step in the risk assessment process is to communicate the assessment results and share risk-related information. The objective of this step is to ensure that decision makers across the organization have the appropriate risk-related information needed to inform and guide risk decisions. Communicate risk assessment results to organizational decision makers (e.g., Board, CEO, CIO, CISO/CSO, ISO) to support risk responses. Organizations can communicate risk assessment results in a variety of ways (e.g., executive briefings, risk assessment reports, dashboards, heat maps). Such communications can be formal or informal with the content and format aligning with the organizations’ existing risk management reporting process or examples provided within NIST Special Publication 800-30 (Figure 6.12).

FIGURE 6.12 NIST key activities – communicating risk assessment information.

Step 4: Maintaining the Assessment

The fourth and final step in the risk assessment process is to maintain the assessment. The objective of this step is to keep current the specific knowledge of the risk organizations incur. The results of risk assessments inform risk management decisions and guide risk responses. To support the ongoing review of risk management decisions (e.g., acquisition decisions, authorization decisions for information systems and common controls, connection decisions), organizations maintain risk assessments to incorporate any changes detected through risk monitoring. Risk monitoring provides organizations with the means to, on an ongoing basis:

Determine the effectiveness of risk responses;

Identify risk-impacting changes to organizational information systems and the environments in which those systems operate; and

Verify compliance.

Maintaining risk assessments includes the following specific tasks:

Monitor risk factors identified in risk assessments on an ongoing basis and understand subsequent changes to those factors;

Update the components of risk assessments reflecting the monitoring activities carried out by organizations.

Task 4-1: Monitor Risk Factors

Conduct ongoing monitoring of the risk factors that contribute to changes in risk to organizational operations and assets, individuals, or other organizations. Organizations monitor risk factors of importance on an ongoing basis to ensure that the information needed to make credible, risk-based decisions continues to be available over time. Monitoring risk factors (e.g., threat sources and threat events, vulnerabilities and predisposing conditions, capabilities and intent of adversaries, targeting of organizational operations, assets, or individuals) can provide critical information on changing conditions that could potentially affect the ability of organizations to conduct core missions and business functions. Information derived from the ongoing monitoring of risk factors can be used to refresh risk assessments at whatever frequency deemed appropriate. Organizations can also attempt to capture changes in the effectiveness of risk response measures in order to maintain the currency of risk assessments. The objective is to maintain an ongoing situational awareness of the organizational governance structures and activities, mission/business processes, information systems, and environments of operation, and thereby all of the risk factors that may affect the risk being incurred by organizations. Therefore, in applying the risk assessment context or risk frame (i.e., scope, purpose, assumptions, constraints, risk tolerances, priorities, and trade-offs), organizations consider the part risk factors play in the risk response plan executed. For example, it is expected to be quite common for the security posture of information systems (i.e., the risk factors measured within those systems) to reflect only a part of the organizational risk response, with response actions at the organization level or mission/business process level providing a significant portion of that response. In such situations, monitoring only the security posture of information systems would likely not provide sufficient information to determine the overall risk being incurred by organizations. Highly capable, well-resourced, and purpose-driven threat sources can be expected to defeat commonly available protection mechanisms (e.g., by bypassing or tampering with such mechanisms). Thus, process-level risk response measures such as reengineering mission/business processes, wise use of information technology, or the use of alternate execution processes, in the event of compromised information systems, can be major elements of organizational risk response plans.

Task 4-2: Update Risk Assessment

Update existing risk assessment using the results from ongoing monitoring of risk factors. Organizations determine the frequency and the circumstances under which risk assessments are updated. Such determinations can include, for example, the current level of risk to, and/or the importance of, core organizational missions/business functions. If significant changes (as defined by organizational policies, direction, or guidance) have occurred since the risk assessment was conducted, organizations can revisit the purpose, scope, assumptions, and constraints of the assessment to determine whether all tasks in the risk assessment process need to be repeated. Otherwise, the updates constitute subsequent risk assessments, identifying and assessing only how selected risk factors have changed, for example:

The identification of new threat events, vulnerabilities, predisposing conditions, undesirable consequences and/or affected assets; and

The assessments of threat source characteristics (e.g., capability, intent, targeting, range of effects), likelihoods, and impacts.

Organizations communicate the results of subsequent risk assessments to entities across all risk management tiers to ensure that responsible organizational officials have access to critical information needed to make ongoing risk-based decisions (Figure 6.13).

FIGURE 6.13 NIST key activities – maintaining the assessment.

Risk response and remediation

Risk response identifies, evaluates, decides on, and implements appropriate courses of corrective action to accept, avoid, mitigate, or transfer risk to organizational operations and assets, individuals, and other organizations, resulting from the operation and use of information systems. Identifying and analyzing alternative courses of action typically occurs at Tier 1 or 2. This is due to the fact that alternative courses of action (i.e., potential risk responses) are evaluated in terms of anticipated organization-wide impacts and the ability of organizations to continue to successfully carry out organizational missions and business functions. Decisions to employ risk response measures organization-wide are typically made at Tier 1, although the decisions are informed by risk-related information from the lower tiers. At Tier 2, alternative courses of corrective action are evaluated in terms of anticipated impacts on organizational missions/business functions, the associated mission/business processes supporting the missions/business functions, and resource requirements. At Tier 3, alternative courses of corrective action tend to be evaluated in terms of the system development life cycle or the maximum amount of time available for implementing the selected course(s) of action. The breadth of potential risk responses is a major factor for whether the activity is carried out at Tier 1, 2, or 3. Risk decisions are influenced by organizational risk tolerance developed as part of risk framing activities at Tier 1. Organizations can implement risk decisions at any of the risk management tiers with different objectives and utility of information produced.

Risk Response Identification

Identify alternative courses of action to respond to risk determined during the risk assessment. Organizations can respond to or treat risk in a variety of ways including risk acceptance, avoidance, mitigation, or transfer. A course of action is a time-phased or situation-dependent combination of risk response measures. For example, in an emergency situation, organizations might accept the risk associated with unfiltered connection to an external communications provider for a limited time, and then avoid risk by cutting the connection, mitigate risk in the near term by applying security controls to search for malware or evidence of unauthorized access to information that occurred during the period of unfiltered connection, and finally mitigate risk in the long term by applying controls to handle such connections more securely.

Evaluation of Alternatives

Evaluate alternative courses of action for responding to risk. The evaluation of alternative courses of action can include the expected effectiveness in achieving desired risk response (and how effectiveness is measured and monitored) and anticipated feasibility of implementation, including, for example, mission/business impact, political, legal, social, financial, technical, and economic considerations. Economic considerations include costs throughout the expected period of time during which the course of action is followed (e.g., cost of procurement, integration into organizational processes at Tier 1 and/or 2, information systems at Tier 3, training, and maintenance). During the evaluation of alternative courses of action, trade-offs can be made explicit between near-term gains in mission/business effectiveness or efficiency and long-term risk of mission/business harm due to compromise of information or information systems that are providing this near-term benefit.

Risk Response Decision

Decide on the appropriate course of action for responding to risk. Decisions on the most appropriate course of action include some form of prioritization. Some risks may be of greater concern than other risks. In that case, more resources may need to be directed at addressing higher-priority risks than at other lower-priority risks. This does not necessarily mean that the lower-priority risks would not be addressed. Rather, it could mean that fewer resources might be directed at the lower-priority risks (at least initially), or that the lower-priority risks would be addressed at a later time. A key part of the risk decision process is the recognition that regardless of the decision, there still remains a degree of residual risk that must be addressed. Organizations determine acceptable degrees of residual risk based on organizational risk tolerance and the specific risk tolerances of particular decision makers. Impacting the decision process are some of the more intangible risk-related concepts (e.g., risk tolerance, trust, and culture). The specific beliefs and approaches that organizations embrace with respect to these risk-related concepts affect the course of action selected by decision makers.

Risk Response Implementation

Implement the course of action selected to respond to risk. Once a course of action is selected, organizations implement the associated risk response. Given the size and complexity of some organizations, the actual implementation of risk response measures may be challenging. Some risk response measures are tactical in nature (e.g., applying patches to identified vulnerabilities in organizational information systems) and may be implemented rather quickly. Other risk response measures may be more strategic in nature and reflect solutions that take much longer to implement. Therefore, organizations apply, and tailor as appropriate to a specific risk response course of action, the risk response implementation considerations in the risk response strategies (part of the risk management strategy developed during the risk framing step).

Types of Controls

As reviewed in Chapter 5, there are three categories of controls (or safeguards):

Administrative: Actions, policies, and procedures involved in the selection, development, implementation, and maintenance of security measures. These measures support the protection of information and assist with managing the conduct of the workforce in relation to the protection of information.

Physical: Physical measures to protect the organization’s electronic information systems, buildings, and equipment from natural and environmental hazards and unauthorized intrusion.

Technical: Technology and associated policy and procedures for its use to protect and control access to information.

Controls Related to Time

Controls related to time generally fall into three categories:

Preventative

Detective

Corrective

Preventative

Preventative controls are designed to be implemented prior to a threat event and reduce and/or avoid the likelihood and potential impact of a successful threat event. Examples of preventative controls include policies, standards, processes, procedures, encryption, firewalls, and physical barriers.

Detective

Detective controls are designed to detect a threat event while it is occurring and provide assistance during investigations and audits after the event has occurred. Examples of detective controls include security event log monitoring, host and network intrusion detection of threat events, and antivirus identification of malicious code.

Corrective

Corrective controls are designed to mitigate or limit the potential impact of a threat event once it has occurred and recover to normal operations. Examples of corrective controls include automatic removal of malicious code by antivirus software, business continuity and recovery plans, and host and network intrusion preven tion of threat events.

Key terms

Practice Exam

1. Risk assessments are not:

a. One-time activities with the hope of providing long-term and definitive information

b. Performed periodically throughout the information life cycle

c. Designed to protect the confidentiality, integrity, and availability of information

d. Designed to guide and inform decision makers in their response to risks

2. NIST’s Special Publication 800-30:

a. Provides guidance for assessing the security controls in federal information systems and organizations and building effective security assessment plans

b. Provides guidance for conducting risk assessments of healthcare information systems and organizations

c. Provides guidance for interconnecting information technology systems

d. Provides guidance for conducting risk assessments of federal information systems and organizations

3. The intent of a risk assessment is to inform decision makers and support risk responses by identifying all of the following except:

a. Relevant threats to an organization

b. Internal and external vulnerabilities

c. Potential impact resulting from a vulnerability exploiting a threat

d. Likelihood that impact will occur or be realized

4. An assessment procedure consists of:

a. A set of assessment objectives

b. An associated set of potential assessment methods

c. An associated set of assessment objects

d. All of the above

5. Assessment methods define the nature of the assessor actions and include all of the following methods except:

a. Interview

b. Evaluate

c. Examine

d. Test

6. The four steps to assessing information security risk include all of the following except:

a. Prepare for the assessment.

b. Conduct the assessment.

c. Remediate assessment findings.

d. Maintain the assessment.

7. Which of the following is correct?

a. The Tier 1 context and the system development life cycle determine the purpose and define the scope of risk assessment activities at Tier 2.

b. At Tier 1, risk assessments support organizational strategies, policies, guidance, and processes for managing risk.

c. At Tier 3, risk assessments support the determination of mission/business process protection and resiliency requirements, and the allocation of those requirements to the enterprise architecture as part of mission/business segments (that support mission/business processes).

d. At Tier 3, risk assessments support organizational strategies, policies, guidance, and processes for managing risk.

8. Risk assessments include:

a. Assessment approaches (i.e., quantitative, qualitative)

b. Analysis approaches (i.e., threat-oriented, asset/impact-oriented, vulnerability-oriented)

c. All of the above

d. None of the above

9. Step 2 of the risk assessment process includes all of the following except:

a. Identifying threat sources relevant to the organization

b. Identifying risk model and analytic approach

c. Identifying vulnerabilities that could be exploited by threat sources through specific threat events

d. Determining adverse impacts resulting from vulnerability exploitation

10. Step 1 of the risk assessment process includes all of the following except:

a. Identifying threat sources relevant to the organization

b. Identifying purpose

c. Identifying risk model and analytic approach

d. Identifying scope

11. Risk monitoring provides organizations with the means to, on an ongoing basis:

a. Identify risk-impacting changes to organizational information systems and the environments in which those systems operate

b. Verify compliance

c. Determine the effectiveness of risk responses

d. All of the above

12. Three types of controls (or safeguards) include all of the following except:

a. Physical

b. Tactical

c. Administrative

d. Technical

13. Controls related to time generally fall into which of the following categories?

a. Corrective

b. Detective

c. Preventative

d. All of the above

14. The examine method of assessment is:

a. The process of exercising one or more assessment objects (i.e., activities or mechanisms) under specified conditions to compare actual with expected behavior

b. The process of reviewing, inspecting, observing, studying, or analyzing one or more assessment objects (i.e., specifications, mechanisms, or activities)

c. The process of holding discussions with individuals or groups of individuals within an organization to, once again, facilitate assessor understanding, achieve clarification, or obtain evidence

d. a and b

15. The interview method of assessment is:

a. The process of reviewing, inspecting, observing, studying, or analyzing one or more assessment objects (i.e., specifications, mechanisms, or activities)

b. The process of holding discussions with individuals or groups of individuals within an organization to, once again, facilitate assessor understanding, achieve clarification, or obtain evidence

c. The process of exercising one or more assessment objects (i.e., activities or mechanisms) under specified conditions to compare actual with expected behavior

d. None of the above

16. The test method of assessment is:

a. The process of holding discussions with individuals or groups of individuals within an organization to, once again, facilitate assessor understanding, achieve clarification, or obtain evidence

b. The process of reviewing, inspecting, observing, studying, or analyzing one or more assessment objects (i.e., specifications, mechanisms, or activities)

c. The process of exercising one or more assessment objects (i.e., activities or mechanisms) under specified conditions to compare actual with expected behavior

d. a, b, and c

Practice Exam Answers

1. a

2. d

3. c

4. d

5. b

6. c

7. a

8. c

9. b

10. a

11. d

12. b

13. d

14. d

15. b

16. c

References

National Institute of Standards and Technology, n.d. Guide for Conducting Risk Assessments. NIST Computer Security Publications – NIST Special Publications (SPs). Version SP 800-30 rev1. Web. June 29, 2014. <http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf>.

International Organization for Standardization, n.d. Home. ISO/IEC 27005:2011. Web. July 1, 2014. <http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber(56742>.

Health Information Trust Alliance, n.d. Common Security Framework – HITRUST. HITRUST. Web. July 1, 2014. <http://hitrustalliance.net/common-security-framework/>.

National Institute of Standards and Technology, n.d. Managing Information Security Risk. N.p., web. July 1, 2014. <http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf>.

National Institute of Standards and Technology, n.d. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. N.p., web. July 1, 2014. <http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-800-66-Revision1.pdf>.

Department of Health and Human Services, n.d. Security Standards: Administrative Safeguards. HIPAA Security Series. Web. July 1, 2014. <http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/adminsafeguards.pdf>.

HIPAA Privacy, Security, and Breach Notification Audit Program, n.d. HIPAA Privacy, Security, and Breach Notification Audit Program. N.p., web. July 31, 2014. <http://www.hhs.gov/ocr/privacy/hipaa/enforcement/audit/>.

National Institute of Standards and Technology, n.d. Guide for Assessing the Security Controls in Federal Information Systems and Organizations. N.p., web. July 1, 2014. <http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf>.