When a building is to be constructed, the strength of the components used for the construction is calculated before the actual and practical building phase takes place.

The material used, for example, for the fundament, beams, floors, walls etcetera of the building is not something that is thrown in without contemplation or calculation. The same thinking needs to and shall apply when processes, information systems, software, and infrastructures are designed and built within an organization. This is not always the case though.

The analogy in the ingress to this article serves as a somewhat good metaphor for today’s subject. The principles are the same. Today’s subject is Threat modeling.

As I mentioned in my previous article, What is Threat Modeling, I describe that I see Threat modeling as a discipline that is something supported by tools and methodologies. Threat modeling is a discipline that is built on skills. You can train those skills to become better at it. The muscle you need to train to become good at Threat modeling is your brain. And the training is conducted by doing those reps in the gym and then going out on the field and applying what you have learned. This means doing Threat modeling. Simple as that.

In this article, I will make Threat modeling simple. by providing an agnostic methodology built on a simple process. I will keep the language simple. Low on acronyms. And approach the subject of Threat modeling with a pragmatic mindset.

HOW TO THREAT MODEL

I do not see any need to make things more complicated or advanced than they actually need to be. So the question is, how advanced or complicated do you need to make Threat modeling? Well, the answer is “It depends”. But in general, I think that it can be made simple. More advanced situations, scopes, systems, and contexts might need more advanced things to be done. But this is not always the case.

I have many times achieved very good results with simple models that conceptualize the attack patterns, threats, vulnerabilities, and context.

As I mentioned in the ingress of this article, the brain is the primary tool that we as security professionals need to use when conducting Threat modeling. Yes, it is as simple as that. We as security professionals are those that need to do the thinking. No tool, methodology, or process will do the thinking for us.

Tools, methodologies, and processes will though be helpful for us to make our thoughts more effective and to better narrow down our threats, vulnerabilities, risks, assets, and other elements within a threat model. Automating Threat modeling is absolutely one way to go but this might not be the path for every organization to take. There are of course arguments that if resources are limited in the organization automation is the way to do it. Ot that automation will simplify the process even further.

I think though that it is also good to keep in mind that before things are automated, like for example Threat modeling, it is very wise to have a strong fundamental understanding and knowledge of the discipline. This way of thinking does not apply to only Threat modeling. I like to apply this mindset as a general principle.

And if automating things, make sure to construct well-crafted documentation of the solution. One day there might be someone else taking over the things you have automated and I can promise you that this person and you will greatly benefit from it.

AGNOSTIC PROCESS

The process for conducting Threat Modeling with the help of an agnostic and simple process consists of the following steps:

Identification of assets
Analyze and investigate architecture
Identify threats and vulnerabilities
Record, document, and rate
Prioritize and mitigate
Monitor

When starting out the process, I recommend starting out with the bigger picture. Start with analyzing the architecture. Do not get stuck in nitty-gritty details right the way. Stay on a macro perspective, and keep you and your team zoomed out. Draw up the data-flows, where authentication and authorization take place. Which parts of the architecture are exposed externally. How is the digital supply chain constructed? Start from a high-level perspective.

When there is a need, as the processes advance, deep dive into those situations. Ok, if the Threat modeling is about breaking down a component on a low level then there is no other way. But usually, there are strong incentives to start from a more holistic perspective. If for example certain part of the solution is exposed externally, it makes perfect sense for you to understand this attack vector first before moving on to how things are built up inside the architecture of the system, application, infrastructure etcetera.

The reason why I recommend to be starting from a more holistic perspective is that in general if those threats targeted from a macro perspective are not managed the attack surface usually remains larger. If for example a fundamental security design mistake is made on an architectural level, the nitty gritty things will be less interesting.

An adversarial will not approach an attack on a system as a penetration test. They will take the path of least resistance. Like water. When they find a way in, there is no need for a bad guy to deep dive if there is no further need to escalate privileges, gain a further foothold, move laterally or vertically, and so forth. I.e. advance in the attack chain to reach the goal of the attack.

Threats are dynamic, they change over time. And if the architecture changes, the threats will (to a certain extent) also change. I recommend you conduct Threat modeling as a discipline and follow a systematic process when changes to a system, architecture, function, infrastructure etcetera are made. And make sure to monitor for those threats you identified to understand how they relate to the context, scope, and asset to which they apply. Without monitoring it becomes impossible to understand the interaction of the threats and if those changes you made were effective.

TOOLS

I have mentioned the most important tool that is needed when conducting Threat modeling. The brain. But the models we conduct need to be visualized. It is not of much value if you or I hold on to the models as abstract thought experiments within our own brains. So, we need tools for visualizing the models we create.

A good tool that I like to use to craft threat models is <*drum roll*> PowerPoint. Yes, it is absolutely enough to start with. It is simple and a good tool for quickly drawing up logical diagrams and abstracts with the help of symbols and icons. The symbols and icons can be used as universal patterns, i.e. objects within your organization.

A strong benefit of using PowerPoint as an initial tool for Threat modeling is that almost everyone has access to it. The diagrams are easy to share and for others to modify or further develop.

This might not be what I would recommend for an organization that is on a more advanced scale or have a System development life cycle process (SDLC) implemented where certain tools and methods are more or less required to be used.

And as said before. Keep in mind that PowerPoint or other tools are not “the solution” for Threat modeling. The tool will not do the Threat modeling for you. The tool will not do the “critical thinking”. The tool will not ask all of those questions about the context, scope, systems, architecture, or infrastructure within your scope. It can for sure assist but the tooling does not replace the thinking or how certain threats apply to our organization.

We are not at a point yet where we just push the red “Execute Threat Modeling” button and voila. Magic sh*t happens. Like in the old The Great Balthazar cartoon. Would be cool though, if there was a machine that did all these threat-things for us. In one way we are heading in that direction though as AI, ML, quantum, and other technologies advance. But I still believe that we as Humans and security professionals at least for some time will need to be those who ask those intelligent questions to AI, ML, quantum, <insert technology> to be possible to help us.

And a general rule that I like to recommend is that the more advanced you become, in any form of a discipline, the more advanced equipment you may be in need to use. This goes often hand in hand and the requirements usually become more demanding as knowledge and skill increase. When PowerPoint is not enough, move towards something that fulfills those needs. But the message is to start from somewhere. A whiteboard is another good tool for Threat modeling and it is also something that most of us know how to use.

HOW DOES A THREAT MODEL LOOK LIKE?

One might ask what a threat model can look like. It depends. The context that the Threat modeling is conducted within will dictate how the modeling (the visual abstraction) will look like. If it is done in the context of a software component it will look a bit different compared to if a threat model is constructed for an infrastructure project.

But the models from a visual perspective can more or less look the same if s -called patterns are used. Patterns are defined objects they represent for example devices, vulnerabilities, threats, databases, systems, and so forth.

Also keep in mind that Threat modeling can be conducted for a specific part of a system, software, or infrastructure or for the whole. As the architectures are different and for this reason, the visual abstraction may lead to them looking a bit different, more or less complex, detailed, holistic, and so forth.

For each threat, I still think it is strongly recommended to write down the scenario in text format alongside the conceptualized threat model. Explaining how the threat potentially can be actualized. The visual abstraction is one part of the Threat modeling, the “story” for the scenario is another thing. Both are needed, in my opinion.

Documentation in written format will also provide strong benefits to easier explain the threat scenario from an objective perspective to others instead of just providing a visual architectural drawing. And if the scenario is complex why not add a written story to the drawing that outlines the thought process? And if the scenario is written in text format there is a great carry-over to writing a risk scenario if a risk assessment is to be conducted.

The ultimate rule is to be as specific as possible. Describe and illustrate the threat model as specific as possible. I will give two examples that are on a high level just to exemplify what I mean with very simple patterns.

This is a less good example:

An external Threat actor compromises an employee’s client by phishing username and password.

This is a bit better:

An external threat actor targets employees within <Business Process Name>. With the help of phishing gains access to the username and password. The stolen credentials are used to gain initial access to the employee’s assets. The threat actor has gained an initial foothold inside the internal network from where the lateral movement to the critical assets and information systems <Business Process Name> is gained. The threat actor exfiltrates critical and sensitive data/information from the organization’s information systems within <Business Process Name>.

A bit more better threat modeling example

WHERE DO WE START?

If you already have drawings of the systems, software, and infrastructure in your organization these are good starting points to be used for Threat modeling. Adjustments might be needed here and there but start from those existing drawings. And all organizations have a whiteboard today. Gather the teammates around that whiteboard and draw the architecture and from there start to discuss the potential threat actors.

Start with brainstorming around high-level perspectives, such as for example:

Are the threats appearing from inside the organization or from the outside?
Is a supply chain involved?
Are there other external factors that need to be contemplated?
How are the data flows organized?
Where are the identities stored?
Where do authentication and authorization take place?

When those high-level perspectives and questions are brainstormed, dig a bit deeper. Now you might want to look into the details a bit further. To understand what form of technologies are used. What are the potential vulnerabilities? Are there any known vulnerabilities? Have similar systems, software, or components in our organization been targeted before?

Iterate the process. Go back to those five steps, found earlier in this article, and go through each of them. Discuss them together and form a common view of the situation. Help each other. It is not a one-man show. It is a team effort. And in most cases, the Threat modeling may involve persons from several teams. Invite them to the table. Do not do it as a secret society meeting that only involves those who know “security” or work with “security”.

The exercise might involve business stakeholders as well. In general, it is a technical discipline but if help is needed from the business organization they shall be involved. Maybe they have different perspectives that are unique but crucial to take into consideration. And if a broader audience is contributing the effects of security awareness are increased. In the long run, Threat modeling, if conducted systematically and periodically will increase the overall security posture of the organization.

And if there is a need to logically illustrate the threat model, I personally like attack trees. They provide a holistic and simple view of the threat. They tend to seem a bit old-fashion and simple though. But keeping things simple usually have its merits.

And if things can be drawn simply that generally also results in a broader audience can understand the drawing. So why not develop one more detailed and technically oriented view and one logical and simple view? The logical and simple can be used to describe the scenario and threat to decision-makers, business leaders, executives etcetera with less technical understanding. The technical view is used to communicate with subject matters and technical experts.

WHAT CAN BE ACHIEVED?

Threat modeling can be used as a separate discipline or together with other defensive or offensive security disciplines and methodologies. A scenario that I find tasteful is where Threat modeling meets threat intelligence and threat hunting similar to the illustration below.

CTI, Threat hunting. MITE ATT&CK with threat modeling

In the model, l have illustrated and simplified the gathering of Cyber Threat Intelligence (CTI) from external sources. Threat Hunting data is pulled from the organization’s SIEM and SOAR solutions (given that such solutions are in place). Information from MITRE ATT&CK is combined with the organization’s Threat Hunting data and Cyber Threat Intelligence which is modeled to craft a Threat model relevant to the situation and scenario.

The Threat intel needs to be structured and condensed into applicable and actionable items. What I mean by this is that, as also described earlier, Threats are in many cases unique for the specific organization, business, or industry. It is not enough to provide large chunks of data sets of threat intel. That is and will not provide much intel or value for an organization. It needs to be processed into actionable and understandable items. And so does the Threat Model. Make the model understandable and applicable to the scenario, context, and situation for which it is crafted.

This scenario may not be something that is the first thing an organization will do when implementing or starting out with Threat modeling though. But if these capabilities, visualized above, are implemented within an organization why not combine the disciplines together? Why not use that actual data, in the organization and from external sources, that is applicable and relevant to your organization? The more relevant the threat model can be constructed the better. But start simple. Advance as you progress. Be pragmatic.

RECOMMENDATIONS

Threat modeling can be used in the following situations and places:

Software development life cycle
Upgrades and changes to software, systems, infrastructure
Shift or investments to/of cloud services
Ethical hacking engagement (Red team, Pentests etcetera)
Risk assessments
Emerging threats and risks
And the list goes on…

The benefit of picking a well know threat model is that you do not need to start from scratch. A well-known threat model also provides interoperability, the models created can be shared with others who use the same model. A well-known threat model can appear to be a bit complex or hard to understand at a first sight. If this situation arises, I recommend falling back to the whiteboard+PowerPoint methodology until you and your organization feel ready to take on a well know framework.

And I also think that there are strong merits to picking and choosing those things from the different methodologies out there that suit the purpose. Choose what fills the needs of you and your organization. Cherry-pick. Be pragmatic. If MITRE ATT&CK makes it for you, go with that. If it is something else, go with that something else.

The key message is to start somewhere and from where you are, and your organization is right now. It is better to do something instead of doing nothing.

Threat modeling can be turned into something complex, as with everything. I do not think it needs to be a complex subject or discipline. And as said before, there are even tools available that help out with automating parts of the Threat modeling to make it more efficient, usable, and sustainable.

But a tool will not replace the minds of a human or teach you how to think as an attacker. From my point of view, this is for me a very good effect of what Threat modeling learns you. It teaches you to better view the system, context, architecture etcetera for which the Threat modeling is conducted from the eyes of an attacker. It trains you in security awareness, from both a defensive and an offensive viewpoint.

Another way to better learn how those bad guys operate is to learn about Ethical Hacking. I have written about Ethical Hacking in a couple of articles.

There is more than just one way to learn how to look at things from an attacker’s viewpoint. Ethical Hacking, Threat modeling, Red & Blue Team exercises, and the list goes on.

Threat modeling is one of those ways and it is not rocket science, it is a discipline and skill. Skills and discipline can be learned but one must do the work, putting that brain into action and building up those models. Threat modeling is a skill. Infrastructure, network, and cloud are skills. Software development is a skill. One might master them all but I strongly encourage you to collaborate with others in these exercises. The more brains, the more perspectives, and creativity. And almost certainly, a better result from the Threat modeling exercise.

Keep things simple in the beginning and advance as you progress. Do not get stuck in choosing or searching for the perfect tool or the most accomplished technique. I think the time is better spent pulling up your sleeves and trying something out and seeing what works for you and your organization. Perfect is great but pragmatism is better. And while searching for perfect, I can promise you that the bad guys do not put their jobs on pause. “Hey let’s wait for these dudes, they are searching for the perfect way to do threat modeling!”. Not so likely.

Security needs to be operated and conducted in a continuum. Strive for a positive progression. Work like a team. Security is a team sport.

Henrik Parkkinen