Imagine a thousand eggs. They’re scattered across different buildings (departments), watched over by different guards (teams) who don’t speak the same language, and you’re not even sure where all the eggs are. Some are in high-tech incubators; others are balanced precariously on shelves. This is the reality of protecting information in a large, fragmented organisation. How do you even begin to protect them all? The answer is by taking a consistent approach to Threat Modelling.

What is Threat Modelling?

To solve our thousand egg problem, let’s first understand how to protect just one. You want to protect it at all costs. Now, imagine that egg is sitting on a table, and in the room with it are a snake and a kitten. We need to understand what can go wrong. This is the basic idea of threat modelling.

• Asset – The egg. This is the valuable thing you want to protect.
• Vulnerability – The fragile shell. This is a weakness that could allow the asset to be harmed.
• Threat Actors – The snake and the kitten. These are the agents that could cause harm.
• Threat – The specific action a threat actor might take. For example, the snake might eat the egg, or the kitten might knock the egg off the table.
• Risk – The likelihood of a threat happening, combined with its impact. The risk is that the egg breaks, and we lose our asset.

A Deeper Look: Asking the Right Questions

A first pass seems simple. But to properly model the threats, we need to dig deeper. Good threat modelling is about asking detailed questions to truly understand the situation.

• Is the egg raw or hard-boiled? (A hard-boiled egg is more resilient).
• Is it in an egg cup? Is the cup stable and the right size? (This is a control that reduces risk).
• What is the table made of? How high is it? (These are environmental conditions).
• What is the floor made of? Carpet or concrete? (This affects the impact of a fall).

Notice that the table and the floor are not threats themselves; they are inanimate objects. They are part of the environment that can influence the success or impact of a threat. The snake, however, is an active threat actor with clear intent (to eat). The kitten is also a threat actor, even if its intent is playful rather than malicious.

Protecting one egg is straightforward. Protecting a thousand requires a system. Without a consistent process, each team will protect their egg differently, leading to gaps and overlaps. This is where frameworks become essential for creating a common language and a repeatable process across an entire organisation

Frameworks

NCSC gives some great information about Threat Modelling including using Attack Trees, they break down the fundamentals of threat modelling in to four steps which are also echoed in the threat modelling manifesto:

• What are you building?
• What can go wrong?
• What should you do about it?
• Did we do a good job?

The Threat Modelling Manifesto describes these steps and the purposes of threat modelling – it also dives values and principals of threat modelling. I highly recommend you have a read of the Threat Modelling Manifesto.

There are several popular frameworks which can help answer those questions and give a good starting point, their outputs all slightly different.

STRIDE is a threat modeling framework used to identify and categorise potential security threats. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege, each representing a different type of security risk. These can be scored if you wish, though the output of this framework will allow you to see where your assets are vulnerable and how they could be exploited by a threat. Based on this output, you can build mitigations and controls to prevent the exploitation coming to fruition.

DREAD – The DREAD threat model is a framework used to assess potential security threats and prioritise them – it’s based on: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. Each category is scored, and the total score helps determine the severity of the threat and guides mitigation efforts. If this works for you, great. My personal opinion is to steer clear of risk scoring if you are looking for consistency as they can be subjective. This is because two analysts may score the ‘Damage potential’ or ‘Exploitability’ very differently without a strict rubric.

PASTA – Process for Attack Simulation and Threat Analysis – This is lesser used in my experience but can produce a very detailed and holistic view of an asset, it takes the business contexts and an attacker mindset into the equation. It’s a seven step approach. A data flow diagram (DFD) is typically used to perform the third stage of PASTA which is application decomposition and analysis. DFDs allow for the simplification of complex systems and a better understanding of the data flow.

A Blueprint for Fragmented Organisations

In a large, fragmented organisation, knowing where to start is the biggest challenge.

1. Start with Leadership: Your first conversation should be with the person in charge of information security—typically the CISO. They can provide a Business Impact Assessment (BIA), which will illuminate the most critical areas of the business. This allows you to focus your efforts where they matter most.
2. Define a Common Language: Before reviewing a single diagram, you must agree on terminology. Work with the CISO and key stakeholders to define:

• What constitutes a “threat” in your organisation.
• The purpose and goals of the threat modelling function.
• The specific framework and process you will use.
• The minimum information required to start a threat model.
• The expected outputs and how they will be used.

Getting this alignment is important. Otherwise, you risk wasting hours of work and potentially allowing the snake to eat the egg.

1. Dig into the Details: Once you have a prioritised area to focus on, use a “question file” (a superb Business Analyst technique) to track your questions, the answers, and whether those answers are facts or assumptions. This structured approach is the best way to gain an in-depth knowledge of each component, its configuration, and the environment it runs in.
2. Bypassing those that obstruct your progress:  There is a likelihood that you will engage with Delivery Managers or Project Leads – They can be helpful but they can also be a big time blocker. Ask them to arrange a call with the admins of the systems to answer any questions. Don’t be afraid to reach out to the admins directly if you can, or to escalate your request up the chain of command. If you don’t, it can take a while to remember why you were asking those questions in the first place so you will end up retracing your steps which isn’t efficient. So, in short, if you can – bypass the non-technical and go straight for the admins.

The Outcome – From Analysis to Action:

The output of your threat model is not just a document, it’s a list of actionable risks. The chaos of a fragmented organisation (the thousand eggs), the clarity of a simple model (one egg), the necessity of a system (frameworks), and the practical blueprint to make it happen. The method for which you document your findings is your decision, the chosen framework may offer some options though the key is consistency. The outputs should grant you a holistic vision of your threats and an idea of how an exploitation may occur. Your threat model can be used to drive defensive actions, such as onboarding logs into a SIEM, writing detection rules, and informing threat hunting.

Experience

Working for a consultancy like Hippo, the experience of working closely within threat modelling teams within Cyber Security Operation Centres allows us to provide industry insights and hands-on experience to our clients. We help them make educated decisions on how to build and manage their Threat Operations to elevate their maturity and expertise in the fight to keep their infrastructures protected. We have been there from inception building a SIEM, building the teams, building the processes and procedures that will carry them into efficient and successful  detections. Threat modelling in one form or another has been a crucial step in deciding what logs to ingest and what detections we can build from the logs. The approach to threat model before ingestion ensure you are not ingesting data unnecessarily as throwing all your data in to a SIEM and hoping for the best is way to ensure your SIEM just becomes a very expensive cloud storage for data you are not using which could impact the return on investment negatively upon being on the receiving end of an attack.