With years of experience developing threat models for systems large and small, from apps to communication systems to global networks, if you’re running a service in a hostile environment we can help you make sense of those threats and decide how best to protect against them. Reach out to info@midnightcat.ie for a consultation and an estimate.

What is a Threat Model?⌗

A threat model is a living document that helps an organisation, or those responsible for a system, to assess and mitigate risks. But what risks should you even care about?

Before you can build a threat model, you need a description of the system, and a frank assessment of what the system is trying to achieve. The actions of threat actors only really impact the system if they make it harder to achieve its goals. So a list of system goals is essential - it sets the scope for everything that follows.

Knowing what the system is, and what it is trying to do, we decompose the system into components and the links between them, being particularly careful to indentify the trust boundaries. Primarily because threat actors will try to find their way into one of these components, and pivot from there to others via the links. Also because each of the system goals will break down into corresponding goals for each of the components - many of which can be considered as sub-systems in their own right. Knowing how each component contributes to achieving the overall purpose of the system is good engineering practice, and if that information isn’t already available, the process of building a threat model will often force you to retrofit the necessary documentation.

Now we can get to the core of a threat model - a list of threats that the system must address:

With some Likelihood, ThreatActor performs Action on Systems because Reasons, which has Impacts

If you don’t have specific threat actors in mind, it is usually sufficient to use a set of threat actor categories, each with a common set of motivations and similar budgets - ransomware groups may use different malware but they all shut down services in order to extract money; nation states are likely to leave your services running but sneakily extract or modify user data. Both may wish to target your systems, or use you to target your customers’ systems. At this stage of threat modeling, it is critical to get feedback and prioritisation not just from system developers and operators, but from those responsible for customer relations and the organisation’s direction.

Mitigation⌗

The list of threats, each with likelihood and impact, tells us the operating environment that the system needs to be designed to work in. Each threat should be mitigated somehow, typically with a combination of internal policies and procedures alongside technical security mechanisms - whether built into the system, or provided by external partners. So we must assess how well the system as designed can withstand those threats. This starts as a theoretical activity: for each threat relevant to a component or link, does it have a security mechanism, policy or procedure that would mitigate that threat? Following on from this, we can also ask: is that mitigation actually turned on, and does it work as intended?

When the threat model is first developed, many if the identified threats will be completely unmitigated; other unimportant threats will have excess protection. For example, secure document repositories often have great confidentiality protection, but are weak against an authorised user presenting modified documents as authoritative. Knowing where all the gaps are, and the priority for addressing those gaps, naturally turns into an action plan. As you work through the action plan, it is critical that the threat model becomes a living document you can update as the system develops, so that you can always at a glance see the priorities for future security activities.

Threat Modeling Tools⌗

As people have become more aware of the need for threat models, more and more software packages have been developed to help with or automate the process. These packages are only as good as they allow ingestion of your existing system designs, and integration into your existing systems for coordinating and prioritising work. If you have a threat model that just sits on the shelf, outside of your normal work processes, you will never actually get to work on its prioritsed action list, much less update it as the system develops. A threat model that evolves with your system is much more valuable in the long run than one that is all polished and shiny but goes unused. These days there are also LLM or “Gen AI” tools that will claim to automate the whole process. Such tools know nothing about your internal priorities but will happily blather on about specific threats and mitigations that may or may not apply to your system - if you decide to use one of these, always double check what it’s telling you.

What About Risk Management?⌗

There are have been, and continue to be, many risk management frameworks and checklist approaches to system security - and if you’re operating in a regulated space, you’ll be obliged to follow one of these - but they are largely paperwork exercises. Proponents for such frameworks point out that they raise the bar, preventing many threat actors from gaining access to systems. In practice, a bigger impact is that they limit the amount of competition in regulated spaces to those companies sufficiently funded to jump through the necessary hoops.

A typical approach to system security is to have an assessment, revisit it every year, and do nothing to address the problems in between. They will identify dozens of relatively meaningless problems that apparently need fixing, and will do little to help you prioritise the work. But you’ll still pass audit with many supposedly stringent frameworks, so long as you’ve documented the risk, and have a plan to address it - regardless of whether you ever follow through on those plans.

Where do I Get Started?⌗

This page serves as a recipe for development of a threat model, so that you can get started on one in-house. The first steps in that recipe are system artifacts that you should already have but probably don’t - develop those in house, and you’ll make the threat modeling process go much more smoothly. When you get to the threat list, you will almost certainly need advice from someone who has done this before, and who has familiarity with the threat landscape. You’ll find many companies offering threat modeling services, at varying price points. Feel free to reach out to info@midnightcat.ie for an estimate.