Threats are those things that we can not control. What I mean by this is that threats, when it comes to security, are mainly driven (when there is a human behind the actions) by motivation and skills/capabilities.
To give an analogy on Threats, in traffic example, when you drive a car there are different kinds of threats. And the threats shift in form depending on the situation and context. In a city environment, other car drivers may be the most obvious ones. When driving at night on a country road it might be animals that may jump or walk in front of the car. We don’t have control over these things. (Motivation and skills/capabilities are less a thing in these situations though).
What about Threat modeling?
Threat modeling helps us as security professionals to better understand Threats targeted toward our systems, organizations, infrastructure, and so forth. And this is what I will speak about today. What Threat modeling is and why it is a powerful discipline.
I see Threat modeling as a discipline, not as a tool. I know others think otherwise and mainly go with a more tool and methodology-specific approach. I do not say that is wrong or the other way around or that my approach is the right one. Those of you who have read my article about risk management, What is Risk Management, will find similarities between this article and my viewpoint on Threat modeling.
What is Threat modeling?
Threat modeling is a structured process and methodology that has the purpose to identify potential security flaws, reducing vulnerabilities, and increasing resilience. Threat modeling also helps to visualize and develop an understanding of the interrelationship between threats, vulnerabilities, assets, and risks for the context in which the threat modeling is conducted.
I have in this article, What is Risk? Modeled and explained, described what a vulnerability, threat, asset, and, risk are and how they interrelate to each other.
The results of conducting a threat modeling for an existing or new application, system, or infrastructure, will also provide:
- Increased quality
- Security awareness
- Understanding of attack surface
- Understanding of threat actors
- Business impact
- Organizational understanding
Threat modeling is a risk assessment methodology that is conducted from a threat perspective, i.e. threat centric.
It is a method to be used by those who intend to increase defensive capabilities and resilience.
Why is Threat modeling important?
As organizations transform more and more into the digital ecosystem, and the attacks become more sophisticated and advanced, resilience must be maintained. The security landscape is highly asymmetric between the defending organizations and attacking parties, i.e. threat actors (cyber criminals). And security threats are real. They are not something that organizations, IT people, media, security g33ks etcetera have fantasized together and come up with.
Threat modeling is a tool for organizations to increase their resilience. To reduce potential flaws and vulnerabilities that adversarial could target and exploit.
The impact of a cyber-attack can in the worst case lead to bankruptcy. I do not need to do it, but it can lead to it. Will threat modeling prevent that from happening? I say no. Threat modeling is one tool of many. It still has its place though and is highly effective if applied correctly and adequately.
Threat modeling is one discipline security professionals should learn to use and apply when needed. And the discipline is, as I see it, a part of a bigger ecosystem. It is a discipline that is closely related to risk management. As I said earlier in this article:
“Threat modeling is
a risk assessment methodology
that is conducted from a
threat perspective, i.e. threat centric.“
P.s there is no vaccine against cyber threats and attacks. And vulnerabilities and weaknesses will remain a thing in the security realm. For this reason, use Threat modeling.
Example
If threat modeling is conducted on a cloud application for example the goal is to identify the potential threats, vulnerabilities, assets, and risks involved within the scope of the cloud application and the context in which it operates within. Simple as that.
If threat modeling is conducted for a system implemented in on-prem-ville, for example, a web application with a front-end that is communicating to a back-end database, the threat modeling scenario will look a little bit different. The purpose is the same though. To identify the potential threats, vulnerabilities, assets, and risks involved within this scenario.
As the scenario, scope and context may not always look the same when threat modeling is conducted means that the threats, vulnerabilities, and risks will shift in form.
Threat modeling is recommended to be conducted in the earliest phases of a project, i.e. when a system, infrastructure, or software is designed. In the best case, it should be conducted when the architecture is crafted. The sooner it is done the better. Security should be something that is considered and built-in and not applied afterward.
Security is not an “appliance” that can come along when the stuff is completed. It is not something that can be put as a cherry on the cake.
“[…] now we are in the testing phase, let’s pull out the security dudes and see what they think!”
“Henrik, can you look at this <insert thing> and tell me what you think about the security? We are going to production tomorrow!”
“We bought this cloud SaaS and have migrated our <Line-of-Business-Application-Data> to it. Now we just need to assess the security of it.”
I still see and hear this kind of thinking, action, and reasoning take place. It is sad though. Security is so much more than just technology and blinking boxes, radio buttons, and control panels. I often simplify security down to Humans, Processes, and Technologies. But this model is not totally representable in every situation. But more on that in another article, let us get back to Threat modeling.
The main reason why security, and Threat modeling, shall be an integral part of each project from the beginning is to reduce and mitigate potential vulnerabilities. Security and resilience are and shall be an integrated part, not something that is “added upon” or conducted as the final thing.
And the sooner the identified vulnerabilities or issues are identified, in general, the cost will be lower to mitigate them. The longer a project is running more complexity is built up, dependencies increase, stakeholder pressure increases, deadline approaches, and so forth.
But this is the ideal scenario though, that threat modeling is something that is launched at the beginning of new projects before things end up in the organization’s IT production environment.
The thing is that threat modeling also has its place as a discipline for systems already in production. Sounds contradicting maybe but let me explain.
For example, systems in the organization that are crown jewels (ERP, HR, Finance, Production etcetera) are strong candidates for threat modeling. And a good situation where a threat modeling of these types of systems fits in is when there is a change made to them. When for example the production system is going to be upgraded or the HR system is going to be shifted to the cloud. Or if the code stack in that system or software is to be updated.
Threat modeling is also a good methodology to apply when new code, modules, and functions are to be implemented in existing software, systems, infrastructure, and so forth. Threat modeling is and shall be a part of the system development life cycle process (SDLC)…but this is not always the case. All too often I see that there is no threat modeling conducted. Or in the worst case, no SDLC in place at all. In these cases, the starting point is to implement SDLC and alongside include threat modeling.
Offensive tooling
But the discipline does not only have a place in the defensive security landscape, but it is also present in OffSec-land. Threat modeling has its place in penetration tests, red team engagements, and other forms of ethical hacking. The purpose is still to increase defensive capabilities and resiliency by identifying adequate mitigating recommendations.
Threat modeling is a tool that provides a methodology (in terms of risk assessment) helping organizations to gain better insight and understanding of the offensive side as well. It can be used as a tool to structure threat profiles and attack paths. It can be used to better understand adversarial tactics, techniques, and procedures utilized by the bad guys.
Think about it, isn’t it a very good tool that also creates good awareness around Offensive Security and how an external threat actor operates? Yes! It helps an organization to learn to think, visualize, develop, and conceptualize how the bad guys operate. To gain an understanding of what types of tactics, technologies, and procedures they use in their attacks. How those attack chains may look like? Who the threat actor is? Why and what they may target.
If you want to read more about Offensive Security, i.e. Ethical Hacking, and my thoughts on the subject you may want to check out these two articles:
Frameworks and models
There are several different threat models out there. A few examples of well-known threat models are:
- MITRE ATT&CK*
- Microsoft SDL
- OWASP Top 10*
- STRIDE
- PASTA
- TRIKE
- VAST
- OCTAVE
What almost all threat models have in common is that they contain a step where the assets and scope are identified, i.e. data flows, architecture, assets, and components. The other one is Threat analysis, i.e. ideation and identification of threats and potential vulnerabilities.
Some call MITRE ATT&CK and OWASP Top 10 threat modeling frameworks others don’t, therefore that asterisk (*). Others call them Attack Libraries. For me it is not a debate of it is a threat model framework or not. They both have a great place and usage. Why not use it for that? Or use parts of it in combination with another framework? Or if there are other models or frameworks better suited, choose those instead. Pick the one that suits you best, your situation, and your organization.
In any case, any form of threat modeling is better than none. Just ignoring or neglecting Threat modeling as a discipline is the absolute least optimal way of doing it. Every organization has threats against them. Internal and external. And every organization will benefit from gaining a better understanding of its own threat landscape.
EPILOGUE
I often see that threat modeling becomes an exercise where the dreaded rabbit-hole-syndrome for security professionals has a tendency to kick in. This happens to me as well, I am not immune to it. I think it is a good thing as well and has to do with the paranoia gene we security professionals carry around <*joking*>.
What I mean by this is that it is easy to get stuck in thinking about trying to find and solve every piece of the puzzle when conducting a threat modeling exercise. It is a good ambition to try to turn around as many stones as possible but some stones might be hard to identify or very hard to turn on your own. Take help from others around you. Do it as a team. And doing it as a team reduces the chances to get stuck in the rabbit hole.
And take this one with you. The MOST important thing when it comes to threat modeling, according to personal opinions, is to make sure actions are taken on those flaws, vulnerabilities, weaknesses, threats, risks etcetera that is found. Things are not solved in reality if they remain identified in abstract models or in our brains. Identifying a security flaw is only one part of the job, this is the beginning of the job. Now actions needed to be taken to mitigate the things.
Make it a habit to go from the models to action and execution. If a formal process for threat modeling is in place or incorporated in the SDLC this will, or should, make the go-to action and execution pretty much a straightforward procedure.
P.s it is ok to rabbit-hole. We all do it. And it can be fun. But we shall not strive for it. And it is not fun to be stuck in those holes. Not at least if you are alone. But that is a part of the learning journey as I see it. Do not be too hard on yourself if you rabbit hole here and there. Punching yourself in the face is not the solution to getting unstuck. Asking for help is.
Security is a team sport. Help each other. Learn from each other. Do it together.
Henrik Parkkinen
Henrik Parkkinen 