Threat Intelligence within the Risk Management Process

How Threat Intelligence fits within Risk Management

This is the second post in a series exploring the relationship of threat intelligence and risk management. If you missed the previous one, wherein I briefly explained why these two should get together, read that first. If you’re wondering what qualifies me to pontificate about managing risk, don’t worry; it’s on my resume. With the introductions out of the way, conditions are perfect to get down to business, and we’re going to kick it off by examining how threat intelligence fits within the risk management process.

To do this, we’ll leverage two common cyber risk management guidelines referenced by the recent Cybersecurity Framework – NIST SP 800-39 and ISO/IEC 27005. I draw most heavily from NIST 800-39 for this post, mainly because it’s free and easily accessible in case you want to follow along. They’re both widely used, similar in many ways, and more than adequate to serve our purposes here.

The NIST SP 800-39 Risk Management Process

NIST Special Publication 800-39 was developed to “provide guidance for an integrated, organization-wide program for managing information security risk to organizational operations, organizational assets, individuals, other organizations, and the Nation resulting from the operation and use of federal information systems.” Note that it’s a program for managing risk, not a specific process. Furthermore, NIST SP 800-39 isn’t an island to itself; SP 800-37 and 800-30 offer supporting guidance on applying the risk management framework in an ongoing process.

800-39 presents risk management as a comprehensive process requiring organizations to frame, assess, respond, and monitor risk on an ongoing basis using effective communications and feedback for continuous improvement of security activities. These process components are depicted in the figure below (clipped from 800-39), and I will examine the role of threat intelligence within each following that.

Frame establishes the context for risk-based decisions and strategy for execution in the areas of assessment, monitoring, and response. Part of this requires that organizations identify assumptions about threats, likelihood of occurrence, vulnerabilities, and consequences. Describing the sources and methods for acquiring threat information is specifically stated (ch. 2, pg. 8, par. 2) as a main output of risk framing and a main input to risk assessment (depicted by the information/communication flows in the figure). This corresponds well to the direction phase of the intelligence cycle, and gives a starting point for collaboration between risk and intel teams. Risk management should communicate what they need to know about threats to properly frame risk and how they need to receive that info to properly assess risk. Intel ops should create a plan for collecting that information and disseminating it in a format useful for risk assessments.

Assess encompasses everything done to analyze and determine the level of risk (likelihood of harm occurring and degree of harm when it occurs) to the organization. Threat intelligence has a clear and critical role here in helping risk management to identify, assess, and track threats as well as evaluate existing vulnerabilities in light of those threats. I plan to do an entire post on the role of intelligence specific to risk assessment/analysis, so I’m not going to go much deeper than that for now. Suffice it to say that intel ops can help risk management conduct meaningful threat assessments rather than defaulting to the prevailing finger-in-the-wind or what-scares-me-most techniques.

Respond addresses what organizations choose to do once risk has been assessed and determined. They identify and evaluate various courses of action, determine which are best, and implement the chosen course(s) of action. While not as obvious the previous two components, intelligence does offer value here. Evaluating the effectiveness of proposed courses of action is very difficult without a good understanding of the motives, means, and methods of the threat being addressed. I’d venture to say that many of our problems in security stem from failing to consider the adaptive nature of adversaries, which results in implementing controls that only temporarily or partially mitigate the threat. Intelligence can also offer insight into implementing and configuring selected courses of action for maximum effectiveness. The Kill Chain and/or Diamond Model approach is particularly useful here as a foundation for conversations between intel ops and risk managers.

Monitor involves verifying proper implementation, measuring ongoing effectiveness, tracking changes that impact effectiveness or risk, etc. Note that this is not synonymous with network threat monitoring, where there is an obvious intelligence aspect. I view the role of intelligence here to be an extension and continuation of the previous response component. In other words, it’s not intel’s job to monitor internal system/control changes directly, but they certainly should be monitoring external threat changes that may necessitate internal system/control changes. Additionally, monitoring risk over time may warrant shifts in the intelligence process to better support security decisions and practice.

The tl;dr of the preceding paragraphs is captured in this annotated version of NIST’s original figure.

While 800-39 is the flagship document in the series, the specific detail of managing risk is provided by other supporting NIST security standards and guidelines. 800-37 is the one that contains guidance on applying the risk management framework, and is depicted below.

Rather than going through each step (many of which mimic what was already covered for SP 800-39), I’ll just highlight some key integration points for threat intelligence. Before doing so, however, it’s important to know that NIST takes what I would call an asset and control-focused approach to risk management in SP 800-37. Notice how step 1 starts with categorizing the system, then selecting and implementing controls, etc. From that view, there’s no *obvious* point at which a threat assessment drives the selection and implementation of controls. This is a weakness of NIST’s risk management framework in my opinion – or at least in the way it is presented. Asset and control-centered approaches almost inevitably adapt and evolve slower than threat-centric approaches. However, purely threat-centric approaches have weaknesses too; they tend to miss the critical context of the environment to which they’re applied.

To be clear, SP 800-37 does make mention of threat information; it’s just buried in the details. Intelligence isn’t referenced in the document except in relation to the framework being used within the intelligence community. The word “threat” isn’t used at all in the guidance for categorizing information systems, but I’ll go ahead and make the recommendation that you should hook intel ops into this step if you’re using SP 800-37. Your categorization of the system will be more effective if you conduct it in light of what you know about adversaries that might try to exploit it. Inviting intelligence ops to the party early will also help during the next few steps, where the concept of threat knowledge is actually mentioned in the guidance. That basically boils down to selecting, implementing, tracking, and updating controls based on the current knowledge of the threat environment that only an intelligence capability (whether internal or external) can provide. I’m in full agreement with NIST there.

The ISO/IEC 27005 Risk Management Process

ISO/IEC 27005 “provides guidelines for information security risk management in an organization, supporting in particular the requirements of an information security management system according to ISO/IEC 27001.” I actually prefer ISO 27005 to NIST 800-39 from a pure presentation/organization perspective, but that’s probably just because I have more practical experience working with it. Both processes are very helpful and share many similarities once you learn the basic lingo of each.

The ISO 27005 risk management process is presented in the figure above. “Context Establishment” in ISO lines up well with “Frame” in NIST. Both include an “Assessment” phase consisting of similar components. ISO’s “Treatment” more or less equals NIST’s “Respond.” “Monitoring” is used in both, as is the notion of communication paths among the various phases. Thus, everything said above in reference to NIST 800-39 can pretty much be copy/pasted into the appropriate slot here. I’m going to spare you that drudgery, though; I mainly wanted to include the ISO 27005 diagram for comparison’s sake. It also reinforces that what we learned above regarding the role of threat intelligence within risk management isn’t just a NIST thing. All that to say – you can apply lessons here to wherever you’re at with whatever you use.

What about risk assessment?

Risk assessment is a sub-component of the overall risk management process. NIST 800-39 and ISO 27005 both include it and emphasize its importance. There are quite a few points of contact between threat intelligence and risk assessment – so much so, in fact, that I think it deserves separate treatment. We’ll pick this up in the next post to make sure we give it due justice. Until then, I wish you all well on your journey toward intelligence-driven risk management.

---

 

All posts in this series:

• Threat Intelligence and Risk Management: An Introduction
• Threat Intelligence within the Risk Management Process
• Threat Intelligence-Driven Risk Analysis
• Threat Intelligence in 3rd Party Risk Management