Applying Threat Intelligence to Operational Resilience and Risk Management Frameworks
In leveraging threat intelligence, the operational resilience practitioner need not create a competing process independent of other frameworks the organization is leveraging. In fact, the use of intelligence products in managing operational resilience is not only compatible with many existing frameworks but is, in many cases, inherent. While it is beyond the scope of this blog to provide an in-depth discussion of some of the more widely used operational resilience measurement and decision-making best practices--including the CERT® Resilience Management Model (CERT-RMM), Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Allegro methodology, the NIST Risk Management Framework (RMF), Agile, and the Project Management Body of Knowledge (PMBOK)-- this blog post, the second in a series, provides a discussion of how to operationalize intelligence products to build operational resilience of organizational assets and services.
In the previous post in this series, we discussed a process in which we
- identified the information available and needed regarding an organization, its mission, strategic objectives, and the assets and services that it must defend. We called this information the "Voice of the Organization."
- identified the information available and needed regarding the technological, socio-political, business, and legal environment that impacts the organization's ability to defend its assets and services. We called this information the "Voice of the Environment."
- identified the information available and needed regarding the capabilities, intentions, and prevailing attack patterns of a set of threat actor categories that could impact organizational assets and services. We called this information the "Voice of the Threat."
This post takes the results of this analysis and create actionable risk mitigations using standard resilience, risk, and project-management frameworks.
CERT Resilience Management Model (CERT-RMM)
CERT-RMM is a capability model for managing and improving operational resilience. The model's goals and practices are grouped into 26 process areas. Organizations that use CERT-RMM can leverage results of the intelligence process to satisfy three goals in two process areas to improve operational resilience. Like the Capability Maturity Model Integration (CMMI) framework, CERT-RMM uses a tagging system to identify process areas, goals and practices. Specific and generic practices are tagged and numbered as follows: SP refers to a specific practice; GP refers to a generic practice. These are appended to the CERT-RMM process area tags and the specific goal and generic goal tags respectively and are numbered. For example, "ADM:SG1.SP1" is specific practice 1 in specific goal 1 in the Asset Definition and Management (ADM) process area, and "ADM:GG2.GP3" is generic practice 3 in generic goal 2 in ADM. We provide these tags in this blog to enable CERT-RMM users to identify which process areas, goals and practices can be supported by effective threat-actor intelligence.
When performing functions as part of the Vulnerability Analysis and Resolution (VAR) process area, the specific practice Analyze Vulnerabilities (VAR:SG2:SP3) requires "understanding the threat and exposure" of the vulnerability. To perform this analysis, up-to-date, consumable information must be on hand. More holistic and precise intelligence enables the organization to analyze with greater accuracy its own vulnerabilities and therefore the threat and risks they engender.
The Risk Management (RISK) process area enables agencies to "identify, analyze, and mitigate risks to organizational assets that could adversely affect the operation and delivery of services." CERT-RMM defines operational risk as "the potential impact on assets and their related services that could result from inadequate or failed internal processes, failures of systems or technology, the deliberate or inadvertent actions of people, or external events." The output of the VAR process area, and the underlying intelligence, is key to successful risk management. An effective intelligence process enables the operational resilience practitioner to
- determine risk sources and categories (RISK:SG1:SP1)
- identify risk (RISK:SG3)
- evaluate risk (RISK:SG4)
By continuously reassessing and reevaluating the Voice of the Threat, the Voice of the Environment, and the Voice of the Organization, facts and assumptions underpinning risk analysis remain timely and relevant. By institutionalizing the intelligence-preparation process by performing generic practices such as establishing a governance process (RISK:GG2:GP1), planning the intelligence preparation process (RISK:GG2:GP2), and providing dedicated resources to the analysis and use of intelligence products (RISK:GG2:GP3) as part of a risk management program, organizations can develop a more mature program that is more effective, repeatable, and responsive to stresses to organizational services and assets. Maturing the interaction with intelligence sources aids in this institutionalization.
Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Allegro methodology
OCTAVE Allegro contains a number of activities, steps, worksheets, and questionnaires that help to formalize the capture of many elements of the Voice of the Organization, Voice of the Environment, and Voice of the Threat. One such worksheet that enables the capture of information gleaned through intelligence analysis is the Information Asset Risk Worksheet. This form enables the organization to identify
- the information asset
- area of concern
- threat actor
- security requirements
- risk mitigation
Use of OCTAVE Allegro in a robust cyber intelligence program could create a continuous cycle of understanding defended assets and services and understanding the threat environment that exposes those assets and services to operational risk.
National Institute of Standards and Technology (NIST) Risk Management Framework (RMF)
The NIST RMF is a framework described in NIST Special Publication (SP) 800-37 for federal systems. The framework consists of six steps:
1) Categorize the information system and the information processed, stored, and transmitted by that system based on an impact analysis.
2) Select an initial set of baseline security controls for the information system based on the security categorization, tailoring and supplementing the security control baseline as needed based on an organizational assessment of risk and local conditions.
3) Implement the security controls and describe how the controls are employed within the information system and its environment of operation.
4) Assess the security controls, using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.
5) Authorize information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this risk is acceptable.
6) Monitor the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.
A common fallacy is that an organization should select and apply only the controls designated for the impact level of their system exactly as they are prescribed in NIST SP 800-53. The truth is that these controls represent the minimum baseline of controls. The NIST RMF also discusses the tailoring of controls "if necessary, with additional controls and/or control enhancements to address unique organizational needs based on...specific threat information". The framework is, after all, a risk-management framework, not merely a controls-management framework. Task 5-3 of the NIST RMF recommends that organizations employ formal or informal risk assessments "at the discretion of the organization to provide needed information on threats, vulnerabilities, and potential impacts as well as the analyses for the risk mitigation recommendations". This cycle of assessing risks and tailoring controls carries an up-front investment of time that would pay long-term dividends were a potential incident to be avoided.
Application to Project Management Frameworks
Once the risk management process has been initiated based on threat intelligence, mitigations can be directly managed through common project management methodologies. While an in-depth discussion of the following frameworks is beyond the scope of this blog, this section provides a brief discussion of how to operationalize intelligence products to support effective project management.
The Agile methodology is a project management methodology based upon the Plan-Do-Check-Act cycle, emphasizing continuous delivery of functionality. Functionality is delivered in sprints of approximately one to four weeks. During the planning phase, requirements are documented in user stories that are then identified from the project backlog for inclusion in the next sprint. By coupling intelligence with an effective risk management program (such as one based on CERT-RMM's RISK process area, OCTAVE Allegro, or the NIST RMF), mitigation strategies can be operationalized in short bursts. A continuous process of intelligence analysis, coupled with the short-time-cycle nature of the Agile methodology, enables risk management that can evolve and adapt to changes in threat intelligence but be implemented in a controlled, deliberate fashion.
Project Management Body of Knowledge (PMBOK)
The Project Management Institute's PMBOK consists of six project management process groups and 10 knowledge areas. When initiating a project that supports the organization's operational resilience, one of the inputs to Process 4.1, "Develop Project Charter," is the business case. When initiating a project that will improve the operational resilience of organizational assets and services, a robust intelligence program can aid in developing a business case that is impactful and descriptive. Process 5.2 describes the collection of requirements for the project. For system projects, this can include the identification of quality attributes for the system's architecture, covering matters such as performance, reliability, and modifiability based on stakeholder requirements. A robust intelligence process, as discussed regarding the planning phase of Agile, also supports this process in PMBOK. A requirements traceability matrix can show the connection between requirements and the intelligence products that support those requirements. Such a matrix can also facilitate the reevaluation of those requirements to ensure the underlying threat information is still valid. Likewise, an intelligence-supported risk management problem statement facilitates scope definition in Process 5.1 by prioritizing operational resilience requirements and ensuring the most pressing risks are addressed, and decisions to accept risks are based on a sound logical foundation.
Operational resilience practitioners must recognize the effect of potential adversary intentions, capabilities, and attack patterns in their day-to-day resilience, risk, and project management. A robust, collaborative relationship of trust with cyber intelligence sources facilitates the analysis that ensures that planning decisions are made based on the best, most current threat information. This process need not conflict with the use of popular resilience, risk, and project-management frameworks, but can be accomplished in a complementary fashion. Frameworks such as CERT-RMM, OCTAVE Allegro, the NIST RMF, Agile, and PMBOK contain touchpoints where effective intelligence analysis and dissemination can improve outcomes and therefore the operational resilience of the organization.
We welcome your feedback on this series in the comments section below.
For more information about the CERT-RMM Framework, please visit
For more information about CERT's OCTAVE Allegro Framework, please visit