Intro
Today I wanted to write a bit about threat modelling. Unfortunately, in our local information security culture, terms such as penetration testing, red teaming exercises overshadow threat modelling if you have had a proper introduction to cyber security. You will have heard about the famous CIA(Confidentiality, Integrity and Availability) triad and the notion of a threat violating these values. But how often do we use this information we learned during practice?
This is where threat modelling comes in.
“Experience shows that nearly 50% of security flaws will be discovered from Threat Modeling because it finds different threats than those found through other assessment techniques.”
- Michael Howard
Security Architect, Microsoft
What is threat modelling ?
Threat modelling can be defined as “Threat modelling is a process by which potential threats such as structural vulnerabilities or the absence of appropriate safeguards can be identified, enumerated and mitigations can be prioritized.” There are multiple definitions for threat modelling but I like this one the most so I will use it here.
Threat model gives the security architect a great overview of the overall state of security within the project or the organization. It helps answer questions within an information security context such as “What are our goals?”, “What should we do to achieve our goals?” , “Where should we prioritize?”, “What is the state of our progress?”.
Some organizations without opt for a threat model-less approach within their information security policy. This tends to be more guided towards a vulnerability based approach. It is just hunting vulnerabilities with each change, not focusing on the reason behind these vulnerabilities thus not actually taking steps to reduce their numbers. This sort of policy fancies itself with the number of vulnerability discoveries it makes instead instead of actually ensuring the security of systems. It looks something like the below image.
How to threat model
Hopefully I have gotten you somewhat interested in threat modelling by now. So let’s now talk about how to actually threat model.
Overall we can break up threat modelling to 5 different steps. But let’s not get ahead of ourselves, in preparation to threat model we need to consider the following.
Preparation
Initially, we need to determine what will be the elements of our threat model. Threat models can be different in types, it may focus on web applications, their features, it may focus on the security of companies IT assets or anything else required, whatever the target is we need to determine our scope to avoid getting lost as threat modelling can be a long process.
Secondly, you need to ensure you have all the relevant information available to you. Putting together a threat model requires extensive information about the architecture. This ranges from web application documentations, to network architecture diagrams to firewall configurations. As can be seen threat modelling also helps solve problems regarding lack of documentation within the organization. In the end without proper information, how can its security be assured? Therefore any place in the architecture without proper documentation is a “dark place” and can not be safely entered into a threat model.
There are a good amount of tools which can be used for threat modelling. Two main aspects to consider while choosing a tool to model with are customization and repeated use. With a good tool you should be able to create a good replica of your architecture without much hassle and be able to make many modifications to this model as time goes by and your architecture changes. Tools such as Cairis, Microsoft Threat Modelling Tool, OWAP Threat Dragon and Irius Risk are worth considering.
My preference for now is with Microsoft Threat Modelling Tool as it allows for me to customize my nodes, flows, add custom properties to my nodes, whilst being able to create custom threats for each node based on scenarios. Although it has a bit of a getting used to period and requires some amount of manual labor.
Steps of Threat Modelling
Values and Assets
Now let’s start with the first step of threat modelling, which is defining our values and assets. This step addresses the question of what we need to achieve. Obviously what we wish to achieve is a secure system. However in this step we need to define what is secure. To achieve this we define values and ensure that our system lives up to the properties we set. Example for these properties maybe the CIA triad, or the 6 property defined in the STRIDE methodology (Authenticity, Integrity, Non-repudiability, Confidentiality, Availability, Authorization). These properties need to be defined carefully as in later stages any event which contradicts our values will be considered a threat.
Next we need to define what a system is. Which is basically defining our assets, what are the things that we are protecting. These can be our, web applications, source codes, databases, workstations and anything else valuable to our organization. It is a good practice to think of these assets as nodes in our threat model diagrams.
Diagram
Once we have defined our goals, we need to start diagramming our architecture. We can divide this into two steps.
We need to gather information about our asset and add it to our diagram. This information should consist of what technologies are used, what is the scope of access to our asset(publicly available or restricted access) and we need to list the functionalities and the features of our asset. Here is a small example from a web application in the Microsoft TMT.
Once we have information about our assets internal functionalities our next step is to put our node somewhere in the application. To be able to place our assets in proper positions we need to find out their data flows with other parts of the system.
A data flow is any possible entry or exit points, in an application level overview these flows may be allowed HTTP, FTP or SMB connections from or to our node and etc. On a network level overview these may be firewall configurations visualized to display any potential data flows that may happen from and to this node.
Doing this for the entire system will require a lot of information gathering and maybe a tedious process. However it is very important in terms of ensuring security of the system. Think about it, if the security specialist does not know about an SMB share running on a server or a commonly used jump node how can they actually assure the security of that server? Same thing, if they do not know a direct network access from a web server in the DMZ to a random workstation how they can assure safety.
A network admin may assure that this is not the case but you shouldn’t just take their word for it either, next time if an attacker jumps from a web server directly to random workstation by passing your heavily monitored jump server in the middle due to a rogue direct access… if you were lucky maybe you can show a document from a net admin or someone saying this connection shouldn’t have existed. If not you are in for a bunch meetings full of headaches.
After identifying exit and entry points, if appropriate we may choose to highlight the different processes these flows allow for and the the different privilege levels required for them. As in if you have HTTP flow to your web application, what can your users do with this flow, create posts, reset passwords etc. Other point is to map any privileged functionalities, are there pages where only users with certain privileges may access or access only from internal IP addresses are allowed etc.
This process will help you in later stages to draft specific threats for each functionality, however in an active corporate environment these functionalities tend to change very rapidly so keeping this model updated will take some extra effort.
Last stage in our diagram step would be identifying the trust zones. Trust zones indicate a group of nodes with similar trust levels to each other. For example, all workstations within the accounting department, can be considered to be in the same trust zone as compromising any of them would result in the same information of data being exfiltrated. Same idea goes for development, staging and production trust zones.
Identifying trust zones will help us focus on strengthening the flows between two different trust zones instead of focusing the flows between two similar nodes of a same trust zone. It will also help us identify an unnecessary connections between two trust zones.
Identifying Threats
Next stage would be identifying threats based on our diagram we created above. This step is connected to our first step “Values and Assets”, as a threat is defined as an event which is in violation of at least one of our values and concerns at least one of our assets.
We can manually enumerate threats using a 4 step process.
Initially we can create basic threats based on our initial properties. For example if we have chosen STRIDE models 6 properties as our values, we can coin a threat such as “An adversary may spoof their identity in the system.” or “An adversary may forge logs to claim repudiation.”. These basic threat can be enumerated as a starting point.
Next we may choose to focus on the threats which may be affecting our data flows and/or functionalities we have mapped on our diagram. For example, if we have an HTTP flow we can add “An attacker may execute HTTP smuggling attacks against the system.” or if we have file upload functionalities we can add “An adversary may upload malicious files to the system to achieve [something].”
Lastly we can focus on the technologies used inside our system. If we use Java applications we may add a threat regarding serialization vulnerabilities, if we use NoSQL databases we can add NoSQL injections as threat events.
We can also use threats defined in other sources in our threat model to ease our manual labor.
Microsoft Threat Modeling Tool comes with its own default threats based on the STRIDE framework. We can use these threats within our threat model.
For web application based threat models we can reference OWASP as it is the main source such inquiries. OWASP Cornucopia can help us derive some threats for our own applications.
Irius Risk automatically applies auto generated threat to your diagram if you use their services. The threats they generate may be worth a while to look at to see if there are any threat events you may have missed.
You can also derive threat events from viewing regular news and conferences regarding what is going on in the industry and adding any new types of attacks and vulnerabilities as threats.
Last but probably the most important is the MITRE website. Here you can find the Att&ck framework which we can use to derive the redteaming threats but most importantly here resides CAPEC - a great list for our current purposes. It contains a large list of threat which we can apply to our model. It is a little bit dated and at times incomplete but with a little bit of dusting off it can help us tremendously.
Hopefully using the methods above by now we are able to create a proper list of threats. We can map these threat manually to our diagram but these take a great amount of manual labor. Instead we can use tools to automatically map these threats, one option is the use Microsoft TMT and while defining threats give each of them a query. This will automatically apply this threat to all systems matching the query.
Identifying and Mitigating Vulnerabilities
Once we have a list of threats and a list of systems. We can now confidently start the process of identifying vulnerabilities, knowing that we know what we are looking for why we are looking for and where we are in the overall picture of things. This step here is what we all love and know pentesting and other similar assessments. Aim of this step is to determine whether any of the previously defined threats are a reality within our infrastructure.
Often in regular assessments vulnerabilities and their risks etc are referenced in generalized sources such as OWASP and/or CVSS scores. However assessments based on threat models allow us to reference our own customized documents to create better understanding for each finding. Instead of using just CVSS score we add the importance of the system this vulnerability affects based on information on our diagram. (Trust zone it belongs to, trust zones it borders etc) Instead referencing general sources we can reference the threats defined in our previous step, and addressing these issues once it for all.
By working on a threat by threat by basis instead of a vulnerability basis we can be more clear in our documentation. If we do consider an SQL injection threat in a target database. We can check for the existence of a vulnerability, if we do not find the vulnerability, we can take note of this non-existence and address the threat as not a risk due to lack of vulnerability. Now,. if we ever have a leak from the target database we can rule out SQL injection as a potential cause by referencing our threat model and confidently be able to consider other threat options such as infected workstations, social engineering, or internal threats. Whereas on a vulnerability based approach this would not be as clear.
By forming a systematic approach all of the threats are checked for existing vulnerabilities and if any is fund they are mitigated. All of these events should be kept track of in a threat’s and vulnerability’s event log.
Documenting
This step is not entirely in sequential order, but is here to signify proper documentation of each step in a threat modelling process. Values and assets that define the core of the organization’s information security policy, diagrams and their previous versions, threats and their vulnerabilities. This document all together signifies the whole essence of cyber security within an infrastructure.
Once all these steps are executed and finished, they are repeated again ! And again and again… Threat modelling is a continuous process by which a an organization always improves and evaluates it information security stance.
Once enough cycles are passed and simplistic issues are effectively mitigated eventually an in-house cyber security team will turn into cyber security researchers looking for zero-day type vulnerabilities add to threats and mitigate.
Hopefully with this post I was able to increase your interest towards threat modelling ! Thanks for your time !