Introduction to Threat modelling
2/11/202511 min read



When most people working with tech hears the word “Threat model”, they often nods slightly confused as they have heard the term before, but probably not used it yet. It is quite self-explanatory to the degree that they can imagine what it is, but hard to visualize without a concrete example.
Threat modelling is not a process that is set in stone, but something that can be tweaked to your own needs. We are going to explore how you can use threat modelling in the perspective from an Application Security Engineer to perform a gap analysis on applications or on a broader infrastructure to find the unknown risks and security gaps that no one is aware of.
As with most things, hosting a good Threat modelling session is something that comes with experience. If you are new to threat modelling, I highly recommend making your own flow diagram of a fictional application and practice mapping Assets, Risks and Threat Actors. I will make a another blog post where we go through a fictional flow diagram in detail.
A short disclaimer, but I am still in the process of learning and optimizing the use of threat modelling. This is based on my current understanding after having performed a handful of threat modelling sessions that has been followed up by "smoke tests".

Why do threat modelling
The goal with a threat modelling session is to map out all the knowns and unknowns. To let a developer share their solution to a problem on an easy-to-understand diagram, so everyone can understand the design and how it fits into in the larger picture. Other developers and architects should be able to understands what is going on and enrich the diagram with their solutions and understanding. Doing so leads to knowledge sharing, which often results in unexpected findings.
A flow diagram should be made to map everything. Draw the logic, add details and make it easy to understand for everyone attending. This flow will be the main value coming out of the session, so it is worth spending plenty of time making it as this will be the baseline for the next steps. I recommend creating it on a physical whiteboard so less time will be spent choosing icons, and more time spent learning and sharing. When everyone has drawn what they have worked on and shared their knowledge on the board, everyone should have a common understanding of what is going on.
Once a common ground is found and everyone agrees on the flow diagram, then Security minded people can start to challenging the design. The one API endpoint that does not require a bearer token to authenticate, or the backend server that is for some unknown reason exposed to the internet because one architect 10 years ago wanted to heartbeat checks from his laptop at home, is all this necessary? what is the risk of all this?
Gap analysis
Knowledge sharing
The diagram is a way of knowledge sharing using visual media. When teams work with an application, complexity blows up quickly when multiple specialized individuals start working on solutions to problems that appear during development. This often leads to these people making new solutions that only they know about and understand. This is often not intentional, as they might mention it in a meeting and even show someone the solution, but as the other architects and developers focuses on their own solutions, this information often becomes an unknown to them.
A small side note, but I have noticed that some developers get very nervous about sharing knowledge, as they are aware of things that is not secure. It is very important to have a positive attitude and have a “Lets fix this together “ mindset and avoid the "blame game", or else we risk losing these security gaps as information is kept back.
In the ideal world, every solution is neatly documented somewhere that can be revised later, but this is not always the case. Besides, having 14 different documents about solutions that work together make it difficult for anyone to fully understand the final solution.







What is in a threat model?
In the final documentation, it should be clearly stated who is in the session and what their roles are. This is good information to have in the because if a threat modelling session do not include a key person, that person could have information that is not shared on the final diagram. When planning the session, it is a good idea to reflect on why you want to bring certain people into the meeting and what value they give. Let us take a look at different roles and what they might bring to the table.
Note: These are assumptions coming from your friendly AppSec Engineer, so take this with a grain of salt!
Product and Application Owners often have a good idea of the use case and has a high-level overview of the solution. They can be smart to bring as they can spot unesecarry functions and risks. They are often curious about the security and is the often the person that needs to answer if the solution in a security context, their insight could bring value, and their deeper understanding of the solutions state of risk gives them plenty of value when continuing development or maintaining the existing solution.
Developers and Architects are good at finding solutions and make things work. I have seen very complex challenges that was solved with the creativity of a good architect and developer. But these creative solutions can also bring unintended risks into the picture. Risks they do not know exist, (Unaware risks) or that they know about, but see no other way of fixing the problem having the risk (Aware risk). Documenting this and eventually finding risk mitigation solutions to monitor or reduce the impact will, if anyone from Security is in the session as well, this help them with being aware of the risk.
Having a risk acceptance is fine, since nothing can be 100% secure. And this is way better than having risks no one is aware of.
Security people often have a different view on architecture than architects and developers. They often have insight on how threat actors operate. Having a Security minded person in the Threat modelling session is a good idea in general, as the insight gained from joining the creation of this model make them understand the diagram in detail. This enables them to potentially see and challenge solutions that could lead to unintentional (Or intentional) risks. They can ask the questions no one thought about, both to document potential risks and implemented Security controls. It is important to not only document the “scary”, but also the “good” of what has been done to remediate risks. As this document can be used in the future if an external security test or revision needs to be done on the application later.
Insight and roles
Mapping
When the flow diagram is drawn and everyone agrees on what is known, and eventually what is not known, then the mapping can begin. The mapping is done in 3 phases, and it is important to go through each phase in order, as it is very easy to jump to the last phase, leaving plenty of unknowns unaddressed. Architects and developers are specialized at finding solutions and might jump down rabbit holes to early, that is why it is important to take one step at the time and assure them that they will be able to use their problem solving skills.
Phase 1: Mapping the assets
Assets is anything that is of value to the company and what can cause harm to the company if stolen, manipulated or encrypted. In a financial organization, it can be stock information, personal information or customer tokens with wide access. It can be authentication tokens to Aure, secrets to a highly privileged user in a platform or a whole database with logs that reveals too much information. It can be a lot and all potential assets that could cause harm to the organization and is used, accessed or revealed in the solution must be documented. If there are too many assets in the model, they can also be prioritized between high, medium and low importance, which will make it easier when mapping risks and security controls to make a prioritization list.
Phase 2: Mapping risks and Threat Actors
The risks are anything that can potentially cause harm to the assets mapped in phase one. In security we follow the CIA triad, and this a good opportunity to bring that into the discussion. If you have a connection string with credentials in source code, and the connection is being used to access a database with customer information, what would happen if a threat actor got their hands on it? Could they access the data with the connection string alone? Is it reachable from internet? Could they easily share it and gain persistence? Does the use connected to the connection string have full CRUD (Create, read, update and delete) rights so they could break the integrity? What will break the availability. Can it be held ransom somehow? Could they delete the information? Or somehow block all access to it? And in the end, map the threat actor. Can the source code somehow be reached from the internet without any authentication, then that in our example, it would be a "T1", if it is an inside threat that could do it, it would be a "T3". This is to understand the probability of the risk happening.
In this phase everyone needs to be creative and think worst case. Treat it as a mind map of “what could go wrong” and make sure to add all actual risks and all potential risks. Especially if a Smoketest or Security/Pentest will be performed afterwards, as this can be used to test the risks.
Phase 3: Mapping the Security controls
Finally, the phase everyone is itching to talk about... Security controls and risk remediation!! Here the goal is to find existing solutions for the known risks and potential solutions for the risks that have not been discovered yet. This is important to note down as it adds to the value of Security documentation and a security test can check if the Security controls actually works as intended.
Make sure to only note down controls that is in use, and document what could be done in the documentation so they do not get mixed up!
If we use the connection string example, it could be; The connection string can be used from the internet, when it is actually just an internal server that needs to connect to it, we should remove the internet access. We can also reduce the impact if the risk actually happens. For example that it only have read rights, as it does not need any other permission. And of course check if it has backups or not, just in case.







Perform a Smoketest
When the model is done and all assets, risks, threat actors and security controls is documented, a Smoketest should be performed by a Security specialist. This requires ressources and time, so this part can be skipped. But if it is a critical solution, it should be done.
So, what is a Smoketest exactly? A Smoketest is a light security test done by someone with experience around offensive Security. I recommend setting of 1 – 5 days of security testing, depending on the size of the solution. During this test, a list of risks is already made and should be explored. These should be tested to confirm that the risk is real or false. But a good security tester should not get tunnel vision on these risks, but also test anything else that appear during the test.
Maybe there is secrets being leaked in some sort of logging? Maybe unexpected tokens can be found and abused? This is why it is smart to perform such a test. You make sure that no other unknowns are left, and that even the risks that is there because a developer that left the company 8 years ago is not present (Because of obvious reasons) is found, addressed and brought into highlight during the last meeting.





The result
After the diagram is made, assets, risks and security controls are mapped and a smoke test is performed (Or not), then it is time to for everyone’s favorite part... Documentation!(This is not meant to be ironic, but that really depends on you 👀)
If you are doing this from as an external resource, then this is the final documentation you will give the team before wrapping up the project. This should be done in a handover meeting. If you are in the team, then this is your final documentation. A final meeting to discuss what was found.
I recommend making the following before starting the last meeting with the developers:
- A master ticket with Action points with the help of a ticket managing system
- Sub tickets for each risk that needs to be addressed
- Documentation to note down everything that is learned and host the threat model
- If a smoke test was performed, the report should be visible in the documentation as well
With all this made, the last meeting can start. If you are the external security part In this meeting, you hand over the documentation and action points to the developers. They must implement the documentation into their own and follow the security findings. You cannot manage and follow up this later, as you probably have other things to test and perform threat modelling on, so it is important that you are clear about this when handing over the documents and tasks. If you are in the team, then simply discussing the findings and planning on how the risks can be mitigated or removed is a good idea, as that is gold to document later and shows high security maturity in your team.

End notes
This reflects my current understanding of how to host a threat modelling session. I am going to learn more about this throughout this year, since it is my main method to learn, test and secure applications.
In the future I am planning to write a blog post with some practical examples of a simulated threat model and add more smaller posts about what I am learning around this.
I hope you learned something from this, and if you are a Threat model expert already and see ways I can improve this methodology, feel free to reach out! I am always eager to learn more! :]
I also want to give a shout out to my mentor Håkon Nikolai Stange Sørum from O3C for teaching and drilling a lot of the base knowledge into my head. He is very skilled with this subject and if you want deeper dives into this topic, I recommend checking him out.
References and resources:
https://www.slideegg.com/fantasy-google-slides-theme
https://www.o3c.no/services/threat-modeling