Threat Modeling is the systematic approach to analyzing security risks for a system in an organization or environment.
But what does this actually entail?
It is a methodical approach to identifying attack surface. Juxtaposed against Penetration Testing, a technical and hands-on strategy, Threat Modeling provides a more theoretical approach to finding and mapping vulnerabilities. In Threat Modeling, the goal is to assess, identify, and prioritize the remediation of risks in a given system or make note of and accepting risk that is present. However, the overall goal is to provide education on the system and the current attack surface within the given environment.
Threat Modeling in Three Key Steps
Assess the security of a system in a given environment.
Identify risks present in the system.
Prioritize and develop a plan to mitigate risk.
Lets break it down.
Assess
Threat Modeling begins by gaining an understanding of an application from a top-down perspective. It will not always be the case that the applications you will be threat modeling are the ones you use on a daily basis. As a matter of fact, it’s likely that a majority of applications you will be threat modeling will be applications you’re not familiar with - such as sales tools, finance software, or HR applications. That’s why it’s important to understand the use cases behind the system before you deep dive into them.
First, you should be asking: What is it?
What does this software do? Does this software have a specific business case that it is solving? At this step, you can be taking steps such as scouring their marketing site, browsing their social media, and digging into their blogs. Learn as much as you can about the application at it’s highest level, but don’t spend too much time - just enough to get familiar.
Once you have a basic understanding, it’s time to keep digging. You should now be asking: What is the intended use case of the application?
What problems are the users in my organization solving every day with this system? This deeper understanding of the application could come from speaking with users, but you’ll most likely get all of the answers you’re searching for in the documentation. It’s here that you can begin to dig into different application features and learn more about what business operations look like with the system. It’s important to learn how to prioritize different docs during this phase - deep dive into use cases that are likely to have the largest impact and graze features with lower severity. You don’t want to spend all of your time reading through the entirety of the documentation.
Identify
Now that you have gained a basic understanding of the application from a holistic perspective, the next step is to identify risk. Identifying risks present in the application first starts with understanding the use cases of your specific organization and your environment.
It’s important to answer the following question to help drive this process: What are my Business Objectives around the Threat Model of this particular service?
In essence, what are the high level objectives of the threat modeling exercise? This will change from application to application, but some general objectives could revolve around the Confidentiality, Integrity, and Accessibility (CIA) of a system.
Declaring business objectives for the Threat Model will likely be an iterative process as you make your way through the system. But after you’ve declared some objectives to start with, you’ll next want to ask: How does my organization utilize this system?
This can be determined in a variety of different ways, but some general places you can begin to assess are:
System Architecture: Determine how the system is configured, deployed, and managed.
Integrations: Assess the security of any third-party integrations, components, and libraries.
Authentication and Authorization: Evaluate how users and systems authenticate and authorize to access resources in the system. Identify weak mechanisms and insufficient controls.
Data Security: Identify potential vulnerabilities in how sensitive data is stored, transmitted, and processed within the system.
Network Security: Examine network configurations and rules, searching for potential entry points in the infrastructure.
Documentation: Search for any documentation available for the general system, and within your own organization’s archives.
Secure Coding Practices: Evaluate any applicable codebase and promote secure practices such as code reviews and static analysis.
Vulnerability Management: Assess any current systems in place for identifying and prioritizing any known vulnerabilities in the software. Search for any known CVEs.
Detection and Incident Response: Are there proper detection and response capabilities built around this system?
Once you’ve dug into these concepts on a system, you should now have extensive knowledge on how the system is configured in your environment. It’s possible that as you’ve gained a greater understanding of how the system functions, more business objectives have become apparent - which is generally expected. While you hope that everything is set up securely, it’s not likely that this is always the case - so it’s important to make note of things as you go.
The last stage of the Identification phase is to now deep dive into the application yourself as a user would. Approach the application from a security mindset, fostering both the perspective of a hacker, but also the perspective of a blue teamer. Don’t just move through it as a user of the application or a developer who configured it, approach it as a detective looking for holes in a case: Where would an attacker look first? What kinds of things should we be weary of? What can go wrong? As you are answering these questions, begin to identify what kinds of threat actors would want to target a system like this. Is it an internal threat actor, like a disgruntled employee, who may want to leak some data? Maybe a nation state looking to target one of your clients?
While this is not always necessary for every system being threat modeled, it can provide value for some systems that require some creativity when considering what kinds of threats you are working to mitigate in the Threat Model.
Prioritize
Now that you’ve done a deep dive into the system, it’s time to begin to map the threat surface that you’ve identified. These will draft into your Initial Areas of Concern. This part of the Threat Modeling exercise will help to build an initial list of action items to drive prioritization to mitigate these identified risks.
As you begin to sketch an initial attack surface, make sure to also take into consideration any logging and monitoring controls you have in place. Assuming you’ve found a source of risk, are there any controls you have in place to monitor the presence of these threats? Make note of these compensating controls that may stand in for any accepted risks identified.
The last piece to the Prioritization Puzzle, and arguably the most important piece of the entire Threat Model, is the Collaborative Threat Model. This is a meeting where you’ll want to bring in one or two Subject Matter Experts (SMEs) on the system that you’ve been conducting this review on. This could come in the form of a user who uses the software on a daily basis, the system administrator, or even the engineer who assisted in the configuration in your environment. As the leader of this meeting, your goal is to identify where your main gaps in knowledge lie beforehand, and draw in the correct personnel to fill those gaps.
In this meeting, it will be the Threat Modelers (yours) responsibility to guide the conversation and pick the brains of the SMEs, identifying hidden attack surfaces that need attention drawn to it. Ensure that the information you’ve gathered on your own threat hunt is accurate. Use this conversation to begin drawing ideas on Incident Response plans: If this thing happens, what kind of procedures need to be in place?
A meeting with SMEs is valuable time, and the biproduct of this final step should be to leave the meeting with prioritized, actionable steps in order to reduce the attack surface. These are going to be the steps you take to mitigate threats, or accept risk wherever present.
Threat Model to Win
Threat Modeling is an important process for analyzing security risks of an application, and a valuable exercise to help security engineers become more familiar with the systems that they are protecting against cyber attacks. It’s imperative to remember that threat modeling, like many other security processes, is an iterative process that requires revisiting - especially after action items have been completed to reduce the attack surface. Threat Modeling can be incredibly valuable, especially for systems that handle critical data, and it should be a process that every Blue Team out there implements into their efforts to secure their organization.
If you're here for everything Cybersecurity, make sure to check me out on Twitter/X for daily insights into the industry!
Kommentarer