Introduction
Regardless of tooling or what methodology you employ, a frequent and expected challenge threat modeling practitioners wrestle with is ‘how does one define scope?’. Threat modeling, at least to begin with, can be an overwhelming activity – the question alone of ‘what can go wrong?’ is enough to send one down a rabbit hole of what-if scenarios, especially when software is increasing in complexity exponentially. So how does one dip their toes into an ocean of hypotheticals, let alone swim in it? This article takes a pragmatic view towards how to define scope, so that fundamentally the practice of threat modeling yields value. There are too many schools of thought to break down the technical implementations for each methodology, and so this article is deliberately abstract and agnostic at times, but I hope it provides valuable insights into how to refine scope over time, and how threat modeling shouldn’t be a herculean task because of it.
Delivering Value
Ultimately, threat modeling is often viewed as a cost center, tasked with reducing the risk of the legal and financial ramifications a poor security posture exposes. Security budgets are finite, and so pragmatic decisions must be made when committing resources and tooling costs to any cyber activity. When done right, threat modeling/shifting security to the left of the Secure Software Development Life Cycle (SSDLC), decreases the security burden and overhead felt by development, operations, GRC, and security teams throughout, eventually showing a compelling return on investment. However, when done wrong, threat modeling creates all noise and no substance, is obstructive, and finds itself stuck in limbo, sometimes being revived here and there where the situation commands its necessity, but occasionally, despite the very best of intentions, it ceases to exist altogether. A pragmatic approach to scope, and then baking it into a standardized process is imperative to removing this risk.
So, how do we deliver value to all arms of the SSDLC? Introducing a new activity into an existing system is likely to be received with some skepticism, so we should first consider the motivation for the threat model. We need to consider who we are threat modeling for; is our threat model entirely operational, or is it built for development teams? If we’re taking a comprehensive look at the risk surface of a system, we’re likely to be targeting both personas, and so we need to ensure we have a hook into their workflows – this might be as simple as a transactional spreadsheet with enumerated threats and mitigations, or it could be a comprehensive and automated ticketing workflow facilitated by tooling. This article won’t dive deeply into the political challenges and tactics vital for homogenizing threat modeling across the different functions and/or bridging the chasm between security and engineering, but in essence, transparency and collaboration are paramount. Curating a healthy mindset surrounding threat modeling and the value-add it offers, ensures constant discourse, positive feedback loops, and coalescence of efforts – all of which are invaluable when refining scope. Once that political prerequisite is in place, and ownership of the different steps of the threat model creation has been decided, we can commence the threat model creation.
Assessing Risk
Humans instinctively scale-out and scale-in scope every day; much like the digital systems we are tasked with threat modeling, our day-to-day systems we live in and interact with vary significantly in unpredictability, complexity, and criticality. Consider the following example, albeit crude, as a helpful metaphor for scope: when walking to your local convenience store, one performs a cursory assessment of risk, perhaps considering the weather and what clothing to wear, the potential for delay, and possibly the safety of certain routes at certain times. However, now imagine you’re walking a similar route, but you’re chaperoning a group of exchange children to/from a school. Suddenly, you’re considering all manner of hazards you would otherwise dismiss: intruders, crossing the road, illness, etc.
As you can see, the scope of the risk assessment drastically changes now that you’re safeguarding critical assets – you’re considering the potential for things to go wrong that you would typically overlook, and not only that, but you’re also having to provide mitigations. It’s considerably more difficult to apply the same rationale to multi-dimensional digital systems, as they’re rarely this simple – there’s often an assortment of assets in play – but it’s important to acknowledge that scope is rarely one-size-fits-all, and the criticality of a system, often informed by mission-criticality of availability or the handling of critical information assets, is significant when defining scope.
Criticality Framework
So, how can we integrate criticality into defining the scope of a threat model? What would the business impact of a compromise/outage of said system/function be? … It’s important to pause and contemplate this question for a moment … over-analysing and quantifying every asset to a high degree of precision puts you at risk of finding yourself in threat modeling purgatory. To avoid this analysis paralysis trap, focus instead on prioritization of known assets over precision of risk quantification, unless, of course, you already have a robust methodology in place … in which case, another team is likely to make these decisions for you! If you’re threat modeling a system that’s already in production, then your asset assessment will likely be achieved to a higher degree of resolution. The goal here is to produce a framework for rating your threat model, perhaps mission-critical, vital, important, minor, or P1-P5, but whatever classifications you or your organization use, remember you’re attempting to capture at a high level the criticality of the system to be threat modeled. Consider how the criticality will then inform what’s invested for each threat model, such as the frequency of revisiting the threat model, the triaging of actions and time invested, or perhaps the formality of a review process.
What are you Threat Modeling?
So, we’ve established our criticality framework for threat modeling, and we have the relevant hooks into the team(s) we’re threat modeling for. We can now consider what we are working on, which is to say, what are we threat modeling? Perhaps we’re threat modeling an entire system devised of multiple components, or all features pertaining to a single sprint and/or epic. Regardless of the threat modeling methodologies you employ, whether automatic detection facilitated by a platform or manual enumerative approaches, we need to represent the system in compatibility with the threat modeling methodology, and we need to rank it in accordance with our aforementioned framework so that we can commit proportionate resources to the system’s criticality.
Einstein infamously said, “if you can't explain it simply, you don't understand it well enough” – a quote pertinent to threat modeling – if those producing and/or contributing to a threat model are finding themselves entangled with questions and technical hurdles when attempting to produce a boiled-down deconstruction of their system, then there’s a strong chance you either don’t have the right people in the room so-to-speak and/or the system needs more comprehension. Without getting into the technical specifics due to the variability in diagrammatic representations amongst different methodologies, the aim is to have a high-level diagram(s), often a flow diagram, to provide a springboard for threat and countermeasure identification. There may be areas of the system which are out-of-scope, perhaps it’s a segment of shared infrastructure belonging to a team outside this project, or it's a segment to be spliced out as its own threat model for another team’s remit.
Aligning Teams and Processes
When the right stakeholders are engaged, and we’re armed with the right artifacts and/or knowledge, such as Software Analysis & Design documents, unobstructive and efficient generation of the threat model is attainable. Each organization is different, each SDLC has variances in maturity and methods, so do spend time aligning with your teams on what artifacts are readily available already, or what would be desirable for streamlining the threat model creation – this will allow you to square your threat modeling methodology/process without rocking the political boat too much; it might also result in you having to completely reconsider the threat modeling methodology chosen, but it’s better to have these conversations earlier than when it’s too late, and the damage is done. With this practical approach to defining processes early on, it ensures threat modeling begins as a well-oiled cog in the SSDLC, and it also accelerates the formulation of a standardized process, whilst underpinning a healthy discourse for future refinement of all things threat modeling, including refining scope!
‘Perfection is the enemy of progress’
Scope isn’t all about the system and describing it, but also about asking the critical threat modeling questions of what can go wrong, and what are we going to do about it? Identifying the threats and countermeasures may be entirely manual, automatic, or hybrid, but it’s helpful to aim for accuracy first, and enhance precision over time. Your centralized risk intelligence will evolve as more threat models are produced, and more contributors are involved, as will accuracy and precision as your threat model is iterated over; your threat modeling process will also evolve organically over time with each iteration, eventually reaching a sweet spot of input versus output. Churchill proclaimed, “perfection is the enemy of progress”, and this couldn’t be more relevant for threat modeling – the threat model can lose all impetus, and ultimately value, if perfection is the threshold before any of the countermeasures identified are distributed to the appropriate teams for implementation. Threat modeling ought to be agile in as many ways as possible, and so aspire for incremental and iterative outputs.
Echoing what’s been said before, every organization is different, thus every organization will size their threat modeling yardstick differently, but with this iterative and logical approach, it’s possible to detect when your threat model is in the territory of diminishing returns, and therefore a benchmark can be set and standardized for the threat modeling practice. It might be that more breadth and less depth for threats and countermeasures identified is desirable, it could be that your organization is comfortable focusing on only OWASP Top 10, CWE/SANS Top 25, MITRE ATT&CK techniques, or a combination of different frameworks, guidelines or standards. This is very relevant to ‘what is your motivation for threat modeling?’ When security is done right, compliance should be a fortunate by-product, however, your organization might want you to specifically target a single standard due to compliance obligations or concerns, and so this may be a preliminary positioning for the creation of the threat model.
Conclusion
Scope shouldn’t have to be a terrifying beast to wrangle, and it doesn’t have to be, so long as it’s approached with a pragmatic mindset. The Threat Modeling Manifesto asserts a core principle of “admiration for the problem: go beyond just analyzing the problem; reach for practical and relevant solutions”(1). It is important to reorientate ourselves towards the purpose of threat modeling from time to time: in its simplest definition, it’s to identify threats before they occur, and so layer-by-layer, with each iteration, with discourse and collaboration, with some trial and error, the precision and accuracy of the threats and corresponding countermeasures identified will increase, and the benchmark for scope will reveal itself.
Reference
1. Threat Modeling Manifesto. [Online] https://www.threatmodelingmanifesto.org/.