Tell us if you’ve heard this one: “We recommend taking steps to perform threat modeling on the controls in your environment.” This is something cyber security professionals across the globe constantly tell their clients or IT departments but seems to be rarely implemented. This is especially true for organizations with small or no cyber security teams to help facilitate this task.

So, what is threat modeling? Most online resources (or security professionals if you ask them in the hallway) will tell you something along the lines of, “Threat modeling is a structured process that helps organizations identify, evaluate, and address potential security risks within their systems and processes.” This tells you basically nothing about it since it sounds like every other security control in the world.

What we’ll do in this blog post is explain what threat modeling is in a practical way. Not only that, but we will do so with the expectation that you don’t have some super team of security professionals ready to roll out a full threat modeling program that could rival a leading Silicon Valley tech company’s process. We’ll also be laying out a potential phased approach for slowly maturing a threat modeling program over time, if that is what your organization needs. This last part should be emphasized, as many over-zealous IT and/or security teams can over-engineer right out of the gate and suddenly be moving glacially slow, trying to twist the business’ arm to follow their 200-page process. Needless to say, it will get little adoption and eventually be dropped altogether.

Why Do Threat Modeling?

Before we get into the phases, we should discuss why it is you should threat model. After all, why even read the rest of this post if you’re not going to need it in the end anyway? Here are some high-level reasons you should seriously consider adopting at least a rudimentary threat modeling process:

Proactive risk management – Modeling threats on a particular system can help you identify what it is you have and how it might be vulnerable. Additionally, security fixes will be cheaper to implement the closer they are to the design process.

Resource optimization – We’ve all seen vulnerability scanner reports with tens or hundreds of thousands of findings. Threat modeling can help you identify your most critical threats up front so that you can map those findings to things that matter most.

Regulatory compliance – While most compliance standards don’t explicitly require you to threat model, doing so can actually help you with auditing processes. Knowing that a particular control has been indirectly secured in an upstream process can save you time and grief in some cases.

The Beginning of Threat Modeling

Getting started with threat modeling doesn’t have to be overwhelming. But it will be if you jump right into adopting a complicated threat modeling framework or advanced modeling tool without even knowing the fundamentals. The first thing you should do is create a threat model for a simple system or process using a simple diagram. That’s it. And that’s what we’re going to do next.

To start at a high level, there is a commonly referenced set of instructions called the Threat Modeling Manifesto that seems to be the defacto standard for modeling threats. This document states that threat modeling approaches should answer four basic questions:

What are we working on?

What can go wrong?

What are we going to do about it?

Did we do a good job?

This is then followed by a series of values and principles that boil down to things like “doing threat modeling over talking about it” and “value collaboration for over processes”.

While we at Helios appreciate simplicity when it comes to security, this kind of ambiguous instruction doesn’t help novices get going with threat modeling. This is akin to teaching someone to drive a car by telling them to move the wheel with their hands and the pedals with their feet. There’s a lot of nuance to these complex processes and not having that information can lead to disappointment or disaster.

Instead, let’s take a practical approach.

Example Phased Approach

In this example, we will walk through a threat modeling exercise for a basic appointment scheduling application, focusing on identifying potential threats and implementing strategies to mitigate them. The target system runs IIS on Windows Server and is hosted on-prem in a production environment with SQL Server as the database management system (DBMS). These critical assets and their architecture present various entry points for potential attackers.

Phase 1a: Identify Assets and Entry Points

Before diving into specific threats, it's important to first catalog the key assets and understand how data moves through the system.

The assets include the database server itself, which stores customer information, business transaction data, and potentially sensitive records. Also crucial are the admin and user credentials that control access to the system, as well as the network infrastructure—routers and firewalls that enable communication.

In terms of entry points, the system has several ways that data and control flow in and out. Some examples include:

Network interfaces - An IIS web server listens on specific ports (e.g. port 433) and communicates with a SQL Server on other ports (e.g. port 1433). Administrators may use Remote Desktop Protocol (port 3389) for management.

Hypervisor interfaces - VMware vCenter must also be secured, as it provides direct access to a virtualized server.

Application interfaces - APIs and other services that communicate with a system must be considered.

Physical access - If a server is on-prem, the physical security of the server room is another aspect to consider.

Phase 1b: Creating a System Diagram

While creating a diagram is technically a separate thing than just identifying assets and entry points, it really should be part of the same step. As you’re identifying these things, you should be creating a diagram that helps you and others participating in this visualize the system and its components.

So, what kind of diagram should this be? Are there rules to this? That depends on who you ask. Every resource on the matter tends to have an opinion on it. However, here at Helios, the type we recommend is simply the one that is useful to you and your team for what you’re trying to achieve on your specific threat model. More importantly, we recommend using the diagram type(s) that you and your team will actually use.

Here are some of the most popular diagram types:

Dataflow Diagrams (DFDs) – These are the most popular diagrams in the threat modeling world and are likely the ones you’ll see if reading up on the subject. The primary advantage to using this diagram type is that it allows you to describe the flow of data among components of the system, as well as properties of each component and data flow.

Process Flow Diagrams (PFDs) – An alternative to DFDs that is preferred by some popular threat model shops (e.g. Threat Modeler) that highlights the operational flow through actions among the components of a system, rather than showing the generic data flow between the components themselves.

Attack Trees – Instead of visualizing how a system operates, this diagram type puts you in the shoes of an attacker and maps out the steps it would take for an attacker to reach a goal (e.g. data exfiltration of payment data).

Sequence Diagrams – This is a UML diagram that describes how components interact in order. This type of diagram is really good at showing how a system and its components change state over time.

Fishbone Diagrams (aka Ishikawa diagrams) – These diagrams show cause and effect by helping you visualize the root causes of certain outcomes.

For this post, we’ll use a DFD, as it’s likely the one you’ll see most in your threat modeling journey. We will start simple and add some process elements for the appointment app:

Here we introduce our first element shapes (don’t worry, there aren’t that many). The circles here represent running code in some form, whether that be compiled binaries, scripts, stored procedures, etc. These are a bit of a focal point for the diagram as they are typically the things that allow the most behavior and can therefore tend to be the things most often attacked. It should also be noted that some threat modelers prefer to use rounded rectangle shapes to represent processes instead of circles. The reason for this is functional only – you can fit more text inside a rectangle shape.

Next, we have our arrow shapes that represent data flows. These are used to represent all the ways that processes and other entities can communicate. When an arrow points in both directions, it shows bidirectional flow. One arrow means it is a unidirectional flow. More information can be included to give better context to the flow, but we’ll get into that later.

Let’s go a little further.

We’ve added some more element types here. The first is a rectangle shape to the left labelled “User”. Rectangle shapes with solid lines represent external entities. In other words, the things that are outside of your control, or at least outside the scope of the system you’re modeling. This can be people or systems. It could be a regular user, an attacker, an API, etc.

The other type of shape you’ll have noticed is a rectangle with a dotted line. In DFDs, dotted lines (which can be either curved lines or rectangles) show what are called trust boundaries. Everything contained within a trust boundary is “trusted” by each other. This doesn’t mean that data flowing within a trust boundary is unauthenticated or unencrypted, it just means that objects and entities within that boundary operate at the same trust level. This is important to note because it assumes that everything specified in the trust boundary uses similar access controls and is treated the same by security controls. If this isn’t true, you need to make note of that or use more trust boundary divisions!

Before we add more to the diagram, we should also mention the added text to the data flow lines. Adding this context can really help understand the purpose of data flows. Sometimes, like in this case, a port number should suffice to show what type of communication is happening. Other times, more text might be needed, or metadata needs to be added (more on this later).

Next, we’ll add some persistent storage:

We’ve now included the database where all the appointment data is stored. Additionally, we’ve added persistent log storage for the Appointment Logger to ship logs. Both of these new additions use a different shape using parallel lines. This shape signifies data stores or persistent storage, which is crucial for understanding where data is held at rest within your system.

You’ll also notice a new trust boundary (PROD DB) surrounding these two data stores. This shows that the data flows leaving the DMZ trust boundary surrounding the previous three elements have to cross another boundary that requires some different trust level (e.g. database authentication, firewall).

Obviously, we could take this much further, modeling every last little detail of our pretend system. However, one should be wary of taking this too far, as there can be diminishing returns. If the information you’re recording no longer helps you spot potential threats, you’ll just be making the model too busy and reducing its effectiveness.

For now, we’ll move on to the next phase.

Phase 1c: Adding Metadata to the Diagram

As you're fleshing out your diagram, it's essential to consider adding metadata to your DFD shapes. You might be thinking, "Great, more details to worry about," but trust us, this step is worth its weight in gold.

Adding metadata to your diagram elements enriches the information you have about each component, data flow, or data store. It helps you and your team understand not just what each element is but also how it operates, what data it handles, and what security measures are (or aren't) in place. This additional layer of detail becomes incredibly useful when you move on to identifying and prioritizing threats.

Example metadata attributes to include:

Data Classification - Label the sensitivity level of the data being processed or stored (e.g., Public, Internal, Confidential, Restricted). Knowing the classification helps prioritize security efforts, especially concerning information disclosure threats.

Authentication Requirements - Note whether a process or data flow requires authentication and what type (e.g., none, password, multi-factor authentication). This is crucial for assessing spoofing and elevation of privilege risks.

Data Formats and Protocols - Specify the data formats (e.g., JSON, XML) and communication protocols (e.g., HTTP, HTTPS, TCP) used. This information can highlight potential vulnerabilities in data parsing or insecure communication channels.

Technology Stack - Document the technologies and versions used in each component (e.g., Windows Server 2019, IIS 10, SQL Server 2019). This helps in identifying known vulnerabilities and ensures that you're aware of any end-of-life software that needs upgrading.

Interfaces and Ports - List the network interfaces and ports each component uses (e.g., TCP 443 for HTTPS, TCP 1433 for SQL Server). This is vital for understanding the attack surface and configuring firewalls or other security controls appropriately.

Security Controls - Note any existing security measures applied to components or data flows, such as encryption (e.g., TLS 1.2), firewalls, input validation, or access controls. This helps evaluate the effectiveness of current defenses and identify gaps.

Owner/Custodian - Identify who is responsible for each component or data store. Knowing the owner can expedite decision-making and remediation efforts when addressing identified threats.

Let’s add some metadata to our Appointment DB.

By incorporating this metadata, your diagram becomes more than just a visual representation—it transforms into a comprehensive map of your system's security posture. It allows everyone involved to quickly grasp the nuances of each component, making the subsequent phases of threat modeling more efficient and effective.

Phase 2: Identify Potential Threats

Now that we've got a detailed diagram enriched with metadata, it's time to ask, "What can go wrong?"

This is where we dive into identifying potential threats using the information we've gathered. We'll use the STRIDE model to systematically assess each component and data flow in our diagram. STRIDE was created to be a mnemonic for categorizing six different threat types. The following will define each type, as well as provide an example using our scenario.

SPOOFING – threats involving an adversary mimicking the identity of an element of the system, which could be another user, system, process, etc.

Possible Threat: An unauthorized user impersonates a legitimate user to access the "Appointment Editor" process.
Metadata Insight: The "Appointment Editor" requires only password authentication, which might be susceptible to brute-force attacks.
Mitigation: Implement multi-factor authentication (MFA) to enhance security.

TAMPERING – threats where an adversary can directly impact the data or functionality of a system by causing arbitrary changes

Possible Threat: Data is altered maliciously while in transit between the "Appointment Creator" and "Appointment Logger."
Metadata Insight: The data flow uses HTTP over TCP port 80, which is unencrypted.
Mitigation: Switch to HTTPS using TLS 1.2 or higher to encrypt data in transit.

REPUDIATION – threats that can inhibit the recording of proof that an event happened within the system, including the when/who/what

Possible Threat: A user denies modifying an appointment, and there's no way to prove otherwise.
Metadata Insight: Logging details are insufficient to prove what action was committed and what exactly changed.
Mitigation: Ensure detailed logging is implemented that shows when/who/what (old value vs new value).

INFORMATION DISCLOSURE – threats regarding the exposure of information to unauthorized entities

Possible Threat: Sensitive appointment data is exposed to unauthorized parties.
Metadata Insight: The "Appointment Database" contains confidential data but isn't encrypted at rest.
Mitigation: Encrypt the database and restrict access based on the principle of least privilege.

DENIAL OF SERVICE – threats to the availability of the system, which can include performance impacts or rendering a system completely unavailable

Possible Threat: An attacker overwhelms the "Appointment Creator" process, causing system downtime.
Metadata Insight: There's no rate limit on incoming requests.
Mitigation: Implement rate limiting and input validation to mitigate DoS attacks.

ELEVATION OF PRIVILEGE – threats allowing an adversary to commit actions outside of their intended access

Possible Threat: A user exploits a vulnerability to gain admin access.
Metadata Insight: The system is running an outdated version of IIS with known vulnerabilities.
Mitigation: Update IIS to the latest version and apply all security patches.

Even though we demonstrate a single threat example under each category, it should be made clear that your system may have multiple threats (or none) for each letter in the mnemonic. For instance, you could have two Spoofing and one Repudiation threats, but none of the others.

While the STRIDE model is a popular and valuable tool for identifying potential threats, it's important to acknowledge that it isn't without its shortcomings. The threat landscape is vast and continuously evolving, and STRIDE doesn't cover every possible type of threat with an appropriate threat category. To make matters worse, it doesn’t do a great job guiding non-security folks on what is a realistic threat and how it can become an exploited vulnerability.

Understanding these limitations is crucial for creating a more comprehensive threat modeling process, when your team is ready for it. When that time comes, it can be a good idea to either supplement STRIDE with another framework, replace STRIDE completely, or even create your own methodology and categorizations (though be careful with this, as implementing proprietary methodologies can inhibit onboarding).

Phase 3: Prioritize and Address Threats

With the threats identified, we need to prioritize them based on their potential impact and the likelihood of occurrence. Metadata plays a crucial role here by providing the context needed to make informed decisions.

For instance, if the metadata reveals that the "Appointment Database" holds highly confidential data and isn't encrypted, information disclosure becomes a high-priority threat. Similarly, if critical components are running outdated software, addressing elevation of privilege vulnerabilities should be a top priority.

Once issues are addressed or risks have been accepted, update your diagram accordingly. Make references to any decisions made or external artifacts that can help further enrich your diagram.

Phase 4: Review and Iterate

Threat modeling is not a set-it-and-forget-it activity. Regularly revisit your threat model, especially when there are changes to the system architecture, technologies used, or the data processed.

Stay Updated - Keep an eye on new vulnerabilities related to your technology stack.

Continuous Improvement - Use security incidents as learning opportunities to enhance your threat model.

Team Collaboration - Encourage open communication among team members to share insights and updates.

Wrapping Up

As a final thought, we’d like to warn against over-engineering this process. It's easy to get carried away with the level of detail, especially when adding metadata. Remember, the goal is to be thorough but practical. Include metadata attributes that provide meaningful value to your threat assessment. If certain details don't aid in identifying or mitigating threats, they might be unnecessary for your model.

By taking a practical approach to threat modeling and avoiding the pitfalls of over-complication, you can significantly enhance your organization's ability to defend against cyber threats. Creating a threat modeling diagram for a given system or process, and being able to reference that diagram, serves as a powerful tool for understanding a system's vulnerabilities and prioritizing defense mechanisms.

Remember, security is a journey, not a destination. Keep iterating, stay informed, and be sure to involve the appropriate parties every step of the way. Start simple and don’t get too complicated, too fast. Before you know it, you’ll have empowered your team to think more critically about security and turn threat modeling from a daunting task into a valuable asset.

If you need help getting started with threat modeling, or any other cyber security endeavor, reach out to Helios and we’ll set up a scoping call.

A Primer on Threat Modeling