CyberAdeptness Blog

Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level. This guide provides a foundation for the development of an effective risk management program, containing both the definitions and the practical guidance necessary for assessing and mitigating risks identified within IT systems. The ultimate goal is to help organizations to better manage IT-related mission risks.

The initial series issued on risk management and replaced by this publication include the FIPS 31: Guidelines for Automatic Data Processing Physical Security and Risk Management issued in 1974 and the FIPS 65: Guideline for Automatic Data Processing Risk Analysis issued in 1979.

This blog focus specifically on how the NIST 800-30 has evolved since it was first issued in 2002 and how it integrates with the NIST 800-37 Series Enterprise Risk Management (ERM) Tiers to clearly delineate an Enterprise Level Security Program Blueprint and Architecture.

First Iteration- July 2002

Link: https://csrc.nist.gov/publications/detail/sp/800-30/archive/2002-07-01

The first iteration on this series was titled “Risk Management Guide for Information Technology Systems: Recommendations of the National Institute of Standards and Technology (NIST) and was issued in July 2002 as part of the FISMA Act.

It emphasizes the importance of integrating the Risk Management process into the Systems’ Development Life Cycle (SDLC) process and incorporates five (5) phases. These phases are summarized as follow:

SDLC Phase	Characteristic	Support from Risk MGMT Activities
Phase 1- Initiation	The need for an IT system is expressed and the purpose and scope of the IT system is documented	Identified risks are used to support the development of the system requirements, including security requirements, and security concept of operations (strategy).
Phase 2- Development and Acquisition	The IT system is designed, purchased, programmed, developed, or otherwise constructed	The risk identified during this phase can be used to support the security analysis of the IT system that may lead to architecture and design trade-offs during system development.
Phase 3- Implementation	The system security features should be configured, enabled, tested, and verified	This risk mgmt. process supports the assessment of the system implementation against its requirements and within its modeled operational environment. Decisions regarding risks identified must be made prior to system operation.
Phase 4- Operation or Maintenance	The system performs its functions. Typically the system is being modified on an ongoing basis through the addition of hardware and software and by changes to organizational processes, policies, and procedures	Risk management activities are performed for periodic system reauthorization (or reaccreditation) or whenever major changes are made to an IT system in its operational, production environment (e.g., new system interfaces).
Phase 5- Disposal	This phase may involve the disposition of information, hardware, and software. Activities may include moving, archiving, discarding, or destroying information and sanitizing the hardware and software	Risk management activities are performed for system components that will be disposed of or replaced to ensure that the hardware and software are properly disposed of, that residual data is appropriately handled, and that system migration is conducted in a secure and systematic manner.

 

During the integration process, the first step that must take place is the Risk Assessment. This risk assessment is key to determine the extent of the potential threat and the risk associated with an IT system throughout its SDLC. The Risk Assessment Methodology includes a total of nine (9) steps. These steps are:

Step	Description	Output
STEP 1: System Categorization	In this step, the boundaries of the IT system are identified, along with the resources and the information that constitute the system. Characterizing an IT system establishes the scope of the risk assessment effort, delineates the operational authorization (or accreditation) boundaries, and provides information (e.g., hardware, software, system connectivity, and responsible division or support personnel) essential to defining the risk.	System Boundary System Function Data Type Criticality Data Type Sensitivity
STEP 2: Threat Identification	In this step, the assessor must identify the potential threat-sources and compile a threat statement listing potential threat-sources that are applicable to the IT system being evaluated.	Threat Statement
STEP 3: Vulnerability Identification	In this step, the assessor develops a list of system vulnerabilities (flaws or weaknesses) that could be exploited by the potential threat-sources.	List of Potential Vulnerabilities
STEP 4: Control Analysis	In this step, the assessor analyzes the controls that have been implemented, or are planned for implementation, by the organization to minimize or eliminate the likelihood (or probability) of a threat's exercising a system vulnerability.	List of current and planned controls
STEP 5: Likelihood Determination	In this step, the assessor derives an overall likelihood rating that indicates the probability that a potential vulnerability may be exercised within the construct of the associated threat environment.	Likelihood Rating
STEP 6: Impact Analysis	In this step, the assessor measures the level of risk to determine the adverse impact resulting from a successful threat exercise of a vulnerability.	Impact Rating
STEP 7: Risk Determination	In this step, the assessor assesses the level of risk to the IT system.	Risks and Associated Risks Levels
STEP 8: Control Recommendations	During this step of the process, controls that could mitigate or eliminate the identified risks, as appropriate to the organization's operations, are provided. The goal of the recommended controls is to reduce the level of risk to the IT system and its data to an acceptable level.	Recommended Controls
STEP 9: Results Documentation	Once the risk assessment has been completed (threat-sources and vulnerabilities identified, risks assessed, and recommended controls provided), the results should be documented in an official report or briefing.	Risk Assessment Report

 

Once all of the steps above are completed and the final report is ready, the executive management team would then be able to determine how the threats are to be addressed in order for the organization to meet the organizations approved and acceptable risk appetite and risk level. This will lead to a risk strategy that is viable for the organization to address in a timely manner and determine the best approach- whether it is to assume the risk, avoid the risk, limit the risk, plan on mitigation steps to lower the risk, or transfer the risk.

NOTE: At the time of this publication, the NIST 800-37 didn’t break the process into ERM tiers, but if one was to apply this to a tier, it would be Tier 3. 

Revision One- September 2012- Current

Link: https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final

This first revision that is currently in effect was issued in 2012 and it was renamed to “Guide for Conducting Risk Assessments”.  This version reinforces CyberAdeptness view on performing an Enterprise Risk Assessment for each individual ERM Tier as part of an Enterprise-wide assessment, which then delineates the best approach to implement and/or re-adjust an existing process in order to be more efficient and cost effective. It goes hand-in hand with the latest NIST 800-37 Enterprise Risk Management guidance.

In this guide, the emphasis on conducting a Risk assessments in each of the tiers is clearly stated.

§  At Tiers 1 and 2, organizations use risk assessments to evaluate, for example, systemic information security-related risks associated with organizational governance and management activities, mission/business processes, enterprise architecture, or the funding of information security programs.

§  At Tier 3, organizations use risk assessments to more effectively support the implementation of the Risk Management Framework (i.e., security categorization; security control selection, implementation, and assessment; information system and common control authorization; and security control monitoring).

Traditional risk assessments generally focus at the Tier 3 level (i.e., information system level) and as a result, tend to overlook other significant risk factors that may be more appropriately assessed at the Tier 1 or Tier 2 levels (e.g., exposure of a core mission/business function to an adversarial threat based on information system interconnections). 

Risk assessments support risk response decisions at the different tiers of the risk management hierarchy.

Tier 1 Assessment

At Tier 1, risk assessments can affect, for example:

(i)      organization-wide information security programs, policies, procedures, and guidance;

(ii)    the types of appropriate risk responses (i.e., risk acceptance, avoidance, mitigation, sharing, or transfer);

(iii)   investment decisions for information technologies/systems;

(iv)  procurements;

(v)    minimum organization-wide security controls;

(vi)  conformance to enterprise/security architectures; and

(vii)monitoring strategies and ongoing authorizations of information systems and common controls.

In this tier, the 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:

(i)      the specific types of threats directed at organizations that may be different from other organizations and how those threats affect policy decisions;

(ii)    systemic weaknesses or deficiencies discovered in multiple organizational information systems capable of being exploited by adversaries;

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

(iv)  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.

Organization-wide assessments of risk can be based solely on the assumptions, constraints, risk tolerances, priorities, and trade-offs established in the risk framing step (i.e., derived primarily from Tier 1 activities). However, more realistic and meaningful risk assessments are based on assessments conducted across multiple mission/business lines (i.e., derived primarily from Tier 2 activities).

Tier 2 Assessment

At Tier 2, risk assessments can affect, for example:

(i)      enterprise architecture/security architecture design decisions;

(ii)    the selection of common controls;

(iii)   the selection of suppliers, services, and contractors to support organizational missions/business functions;

(iv)  the development of risk-aware mission/business processes; and

(v)    the interpretation of information security policies with respect to organizational information systems and environments in which those systems operate.

In this tier, the 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). 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.

Risk management and associated risk assessment activities at Tier 2 are closely aligned with:

§  The development of Business Continuity Plans (BCPs).

§  A focus on mission/business segments, which typically include multiple information systems, with varying degrees of criticality and/or sensitivity with regard to core organizational missions/business functions.

§  Developing an Information security architecture as a critical component of enterprise architecture to help organizations select common controls inherited by organizational information systems at Tier 3.

§  The security and risk posture of organizational mission/business processes, which inform assessments of organizational risks at Tier 1. Thus, risk assessment results at Tier 2 are routinely communicated to organizational entities at Tier 1 and Tier 3.

Risk assessment results produced at Tier 2 are communicated to and shared with organizational entities at Tier 3 to help inform and guide the allocation of security controls to information systems and environments in which those systems operate.

Tier 3 Assessment

Finally, at Tier 3, risk assessments can affect, for example:

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

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

(iii)   operational decisions (including the requisite level of monitoring activity, the frequency of ongoing information system authorizations, and system maintenance decisions).

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 (i.e., risk assessments performed for the first time, rather than updating prior risk assessments) can be performed at any phase in the system development life cycle, ideally these assessments should be performed in the Initiation phase.

 In the Initiation phase, risk assessments evaluate the anticipated vulnerabilities and predisposing conditions affecting the confidentiality, integrity, and availability of information systems in the context of the planned environments of operation. Such assessments inform risk response, enabling information system owners/program managers, together with mission/business owners to make the final decisions about the security controls necessary based on the security categorization and the environment of operation. Risk assessments are also conducted at later phases in the system development life cycle, updating risk assessment results from earlier phases.

Risk Assessment Process

There’s a few variations pertaining the risk assessment process within this iteration that differ from the initial guidance provided in 2002; however, they won’t be addressed as part of this blog given that the emphasis is on the importance of performing an assessment at each individual tier for the process to function properly. Integration of the assessments across each tier is essential to have a clear view on the organization’s risk and to ensure the security program is applied correctly along with the integration of the Cybersecurity Framework, which encompasses the last two (2) components of an assessment for validating the organization’s security from an external/internal perspective once approved systems are operational.

 

Conclusion

The final iteration clearly emphasizes the importance of performing assessments at all tiers. This is why CyberAdeptness will continue to enforce the importance of performing an Enterprise Risk Assessment at Tier 1 and Tier 2 prior to implementing a Security Program and/or to validate an existing program within an organization. This is the only way for an organization to limit Cyber-attacks and lower the risk to what truly matters, those lowering the overall cost associated with security compliance.

We have a set methodology already in place that will lower cost across the enterprise to 50% or more, depending on the organization’s infrastructure and Enterprise Security Architecture. Interested on learning more? Send us a request via our Contact Us form to schedule a 30 minutes consultation.