Overview

Showing the benefits of threat modeling to management less invested in cyber security topics is notoriously hard as the added value of security, in general, is hard to communicate unless an incident happens. However, the situation can be significantly improved by regularly relating the threat model outcomes to the risk concepts business understands and feels accountable for. The trick is to show that the threat modeling findings are not abstract or hypothetical technical scenarios but rather factors that contribute to high-level business risks and thus increase the chance of failing to meet the defined business goals. Budget is, after all, tied to reaching these goals. This is especially true when factoring in the resources needed to scale the process or to conduct it as a regular activity by a single team. 

One efficient way of creating stakeholder engagement in such a situation is to embed threat modeling in the organization’s risk management (RM) process. Risk management is fundamentally about systematically assessing risks that jeopardize management goals and priorities. Embedding threat modeling in the risk management process is your possibility to re-frame management perception about the process and highlight how it adds significant value to upper management:

• establishing a connection between the business risks and the technical risks 

• capturing the contribution of various technical threats to the business risks  

• creating transparency on the amount of risk that was accepted implicitly before performing threat modeling

• show the ROI of threat modeling by tying it to risk concepts that are expressed quantitatively

With re-positioning TM as an essential and in the broader RM process integrated activity, you reframe the perspective on threat modeling to something the business side appreciates for its added value in reaching their own goals instead of merely accepting the importance of security. This appreciation can make the difference between getting adequate resources for maintaining and scaling the TM process or being (constantly) under-prioritized in favor of, say, feature stories – even though nobody would openly debate the importance of security. 

In Part I, we start with a quick overview of a general risk management (RM) process and give a strategic perspective on some of the considerations about embedding threat modeling in the RM process as a regular activity. 

In Part II, we demonstrate the basic idea of embedding an example set of STRIDE (Shostack, 2009) findings to a reasonably traditional RM process using standard RM techniques like the FIRM (Hopkin, 2017, pp. 135-138) framework for identifying business risks and risk matrices to measure (changing) risk levels. Whether you use STRIDE in your organization is of minor relevance. We primarily use it as a relatively lightweight method, and we do not want to get lost in threat modeling details for this article, our goal being mostly to demonstrate the core ideas with rudimentary – and to be improved – models.

Part III addresses some of the shortcomings of the initial models by introducing more advanced quantitative risk models. 

Part IV finishes this journey with possible approaches to scale by incorporating quantitative risk models with modern threat model representations like the Open Threat Model format.

Why bother about risk management

Unfortunately, the communicated strategic business goals are often too high-level to directly relate to them the potential benefits of threat modeling. Doing so, you would end up with arguments like “TM helps to create an improved customer experience by incorporating security into the user journey and thus contributes to reaching the strategic goal of increased customer satisfaction.” Such statements might be accurate, but most probably will not be enough to get your case organizational support (i.e., budget & other resources). Instead, it would help if you could wave the TM activities into how your organization breaks down these strategic goals internally and identifies the risks associated with them from a management perspective. Once you achieve this, the strategic goals management efficacy is measured against, becoming your leverage in positioning TM as a crucial effort in reaching business goals. As it turns out, one effective way to implement this strategy is to follow the risk management process the organization already uses and create connections with the established steps. 

Since, on a high level, risk management processes look pretty similar, we will adapt the ISO 31000 terminology for the sake of this article. The high-level illustration of ISO 31000 presented in Figure I, borrowed from (Hopkin, 2017, p. 79), gives us just enough understanding of a typical risk management process for our purposes. ISO 31000 is a general enough framework, so you might find similarities when reviewing the RM methods implemented in your company, even if it is formally not ISO 31000 compliant. 

Figure 1, an illustration of the ISO process as presented in (Hopkin, 2017, p. 79)

Review of the risk management process 

Now that we have motivated why one should think about threat modeling in a broader risk management context let’s review the steps an RM process uses to achieve this on a high level to create a bit of understanding of the process we would like to embed threat modeling into. 

Establishing the context

A typical risk management process starts with a step that ISO 31000 calls “establishing the context.” This or its equivalent section describes the internal and external factors your management considers relevant. The external context mainly considers the local and global market situation, political landscape, and regulatory requirements. In comparison, the internal context addresses considerations like financial goals and limitations or various effects of strategic decisions like adopting a cloud-first strategy. 

This is where management states what they care about from the context they operate in. Aspects that are recognized here will guide the subsequent steps in the process. 

Risk assessment 

This is the part of an RM process where we need to concentrate most of our efforts on establishing threat modeling as an integral part of the risk management process. It comprises essential risk identification, analysis, and evaluation activities. Our goal is to show that threat modeling has not only similarities with these steps but can also be used as an implementation of these activities in a software development context. 

Risk identification

Building upon the factors listed in the previous step establishing the context, the risk identification part of the risk management process deals with systematically enumerating the business risks derived from the elements of the external and internal context. 

It could feel tempting to position threat modeling as the developer team’s equivalent risk identification activity. The one identifies business risks, the other technical threats. Aren’t these just the same thing under a different name? Well, not exactly. There is plenty of discussion on the subtle differences between threats vs. risks we can not cover here. However, there is one aspect that has some significance from the point of view of the question of how to embed threat modeling into risk management: the external and internal context based on which an RM process derives the business risks is relatively static compared to the typical 2 - 4 weeks long development cycle. Admittedly, threats are most probably present during the product lifetime, likely those derived from core architecture and business features. Nevertheless, there is still an inherent difference in the dynamics by which threats are potentially uncovered by the threat modeling activities vs. the relevance of business risks which are usually reassessed during the yearly business planning activities. 

Even though the list of any initially identified threats based on planned core features and architecture will likely not change heavily during iterations, a new threat will likely be uncovered during the TM of a new feature, which contributes to risk, thus changing the overall risk profile. This observation has two practical implications for us:

• business risks are not the equivalent concepts to the technical threats TM deals with

• there is potentially a significant difference in the dynamics of the process used to identify risks vs. those that are supposed to identify threats

We must find ways to account for these aspects when mapping business risks and threats later on, but let’s note that the mapping is not straightforward and probably should happen elsewhere in the process.

Many companies use the finance, infrastructure, reputation, and marketplace (FIRM) classification for risk identification (Hopkin, 2017, p. 165). Since we need a simple RM process example to demonstrate how to embed TM, this will do perfectly. Using this methodology, a company could arrive at a list of risks like the below one following:

Reputational risks:

1. customer acquisition roadmap jeopardized by brand damage 
2. compliance risk
3. concerns over the quality of the product

Marketplace risks:

We consider this category out of scope. Typically, product teams would perform threat modeling and focus on cyber security threats.

The financial risk of the internal context to be addressed by the team:

4. fraud risk

Infrastructure risks of the internal context to be addressed by the team:

5. insufficient resilience of the system

6. insufficient data protection 

As you can see, this list does not focus on technical issues but emphasizes business priorities. This is common in for general RM process’s list of identified risks. Their job is, after all, to guide management. Ours is to show how the threat modeling process contributes to the efforts devoted to mitigating these business risks and that the technical threats TM uncovers are not somehow confined to a business realm: the connection is there, and the contribution can be made visible with the very same tools the RM team uses otherwise to express and measure risk levels.

Risk analysis

Most risk management process implementations have a section that breaks down the identified risks. Consequences are enumerated, and likelihoods and magnitude criteria are outlined for various risk levels in case of qualitative risk representations and probability and some quantitative measure (loss in dollars, for example) in case a quantitative model is preferred. The function with which you assign your risks and assign a specific value to them will be referred to as the risk function. As this section naturally deals with the technicalities of analyzing risks identified earlier, this is the suitable part of the RM process to introduce TM by establishing the mapping between business risks and technical threats. 

As mentioned previously, our preferred strategy is establishing a mapping hierarchy between business risks and technical threats, where possibly several threats contribute to one business risk. Mapping a set of threats to given risks allows the group to change over time; see the consideration above regarding risk vs. threat dynamics. Also, it provides us with a conceptual bridge from risk levels through a set of threats that contribute to that risk down to vulnerabilities (for the sake of this discussion, let’s treat vulnerabilities simply as concrete manifestations of a threat). In practical terms, this means that the risk function will be applied to risk and its associated threats and evaluated to the value of that risk associated given those threats. The effect of implementing mitigations is expressed simply by a reduced risk value. This will be at the heart of many design considerations in the example approaches and their evaluation presented in subsequent articles (Part II and Part IV). 

Risk evaluation

The risk evaluation step takes risks identified earlier. It evaluates them against the function used to calculate the magnitude and likelihood values of the risk (or any other representation of the risk values). These risk values are then displayed in a format adequate to the model chosen earlier: a risk matrix is a common choice for visualizing qualitative data, and a loss exceedance curve is a popular choice (Hubbard & Seiersen, 2016) to visualize and evaluate probabilistic representations.

Different risk values are calculated for each risk with other mitigations applied to them to account for the effect of various mitigation options. The risk level without any mitigations is usually referred to as inherent risk, while the reduced risk level after applying specific mitigations is the projected risk. The differences between the projected risk values can be compared to give one way to guide the process of selecting the most appropriate mitigation.

An exciting aspect of the activities in the evaluation step is when or rather how often they would happen: would the risk values be calculated and overall representations updated during (or rather tied to) the threat modeling sessions (again more dynamic in nature) or rather less frequently as part of a more strategic evaluation process? After all, a team does not necessarily need to take into account the effect of changes in the global risk landscape when deciding the order of local work units (implementing countermeasures)

Risk Treatment and Reporting

The threat modeling equivalent of the risk treatment step of a general RM framework would be the implementation of the defined countermeasures and mitigations. One could argue that to work down your list of countermeasures, total risk evaluation is not necessarily needed; the decision could be guided by engineering input on resources, urgency, or other factors. You could see risk value changes captured in risk matrices or loss exceedance curves as information to drive more strategic decisions. It would be, for example, perfectly relevant input at budgeting discussions when one would consider what budget and comprehensive resources to allocate for the next budgeting period, given the contribution of cyber security threats to the overall business risk landscape. In other organizational contexts, the risk value changes could be used to guide the team locally, make more tactical decisions, and thus directly influence, for example, work prioritization.

To what extent risk evaluation outcomes are used as input for risk treatment - guiding prioritization and scheduling of the implementation of countermeasures - or management reporting processes essentially is a choice of how tightly an organization wants to tie tactical decisions to the overall strategy. Irrespective of the preferred option, the direction taken would naturally affect how the monitoring and review functions, along with the management communication and consultation, would consume the calculated risk values and updates in the aggregated representation (risk matrices, loss exceedance curves, or other models).

Closing remarks

This overview shall help you to appreciate the potential of embedding threat modeling formally into the risk management process. The following article will use a simple concrete example to showcase the main ideas. We will start with one possible example of how to break down the above business risks to STRIDE threats. We will then review the primary considerations around constructing a risk evaluation function mapping to categorical likelihood and magnitude values represented in an aggregate form by risk matrices. 
 

References

Hopkin, P. (2017). Fundamentals of Risk Management - Understanding, evaluating and implementing effective risk management. London: Kogan Page.

Hubbard, D. W., & Seiersen, R. (2016). How to Measure Anything in Cybersecurity Risk. Hoboken, New Jersey: John Wiley & Sons Inc.

Shostack, A. (2009, August 27). Microsoft SDL Blog. Retrieved from The threats to our products.