My presentation for this year is Threat Modeling. My first stop is the 2024 Palmetto Cybersecurity Summit Feb 21-22, 2024, in Columbia SC. I’ll also be speaking at BSides Nashville May 11, 2024, and ShowMeCon May 13-14, 2024.

The basics of threat modeling starts with the understanding that it’s simply doing a data flow discussion. In fact, when I do these I name the meeting data flow discussion instead of threat modeling discussion. This allows people to come to the meeting with the mindset that it’s just a discussion about how data flows through an application or business process. And then we’re going to do naughty things to it.

The session itself is broken up into five parts:

• Identifying assets and data flows

• Establishing the security profile

• Identifying potential threats

• Assessing vulnerabilities

• Prioritizing risks

We’ll explore each part in more detail below.

Identifying assets and data flows

This is scoping what will be part of the threat modeling session. This could be an application or a business process. It sets the boundaries to keep everyone in the meeting on track. Scope creep is something that can and will most likely happen. Setting the scope more easily helps identify when the discussion is getting off track. If someone goes out of scope then we can call it out and setup a separate session or cover it later in the meeting if time is available.

A diagram is drawn as part of the session if one is not already provided. When I’m asked for how to make the meeting run smoother I ask for an existing data flow diagram or for one to be created. This doesn’t need to be anything elaborate just something to get started. Everyone that can speak to the application or business process needs to be in the meeting. This may be just the development team or it may also include people from infrastructure, compliance, or other areas.

When there is no diagram a whiteboard and markers will do for an in-person meeting. If virtual most video conferencing tools have a whiteboard feature. There’s also many third-party options online. A favorite of a lot of development teams is draw.io. Infrastructure teams usually prefer a licensed version of Microsoft Visio. We’ll get more into tools in the next blog post.

Diagram is simply using arrows, squared, and circles to draw the diagram. OWASP has examples of shapes to use for the diagram. I would typically use a square for an application and then a circle for a database. The big thing is to use a standard shape for each thing within the diagram. Once the diagram is drawn we can move to establishing the security profile.

Establish the security profile

This is the part where the group identifies what security is currently in place. This deals with items like if HTTPS or HTTP are in place (lots of backend things may use HTTP) or how do users access the application or process. Thoroughness is good but new security measures may be discovered as the application is attacked. Compliance requirements also need to be understood for the application. Healthcare, financial, and personal data all have different requirements and security protections than data that is expected to be public. Once the security profile is established we get to be bad boys.

Identify potential threats

This part we get to play the bad guys and think about how we can break the application or process. When just introducing this activity to departments you’ll need to keep in mind that they’re builders, not breakers. We have to unlock that mindset within them. Once the ball get’s rolling though people can come up with some pretty creative ways to attack their own application or process.

One of the important techniques someone facilitating the session will need is being silent. People can’t stand silence so learning to stay silent will help with getting people in the room to participate. Having a pentester in the room may help the juices flowing but don’t let them only provide more than one or two examples. They can quickly takeover and then it’s just the pentester talking about how they’re going to test the application. The underlying objective here is getting people into a better security mindset. To do that they need to start learning how to think like an attacker.

Anything is on the table from simple attacks to elaborate Mission Impossible style attacks. One of my favorite attacks to use to get people thinking is to talk about bribe scenarios or insider threat, “What if I give you a million dollars for your access?” The response is usually, “but you can’t do that….ohhhhh!” It happens. In 2021 news broke that Russian man offered a Tesla employee to put ransomware on the company’s network. Insider threat is a huge attack vector and a massive risk and is something that should be discussed.

There are different methodologies for attacks in a threat model session. I like using STRIDE which is mnemonic for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Elevation of Privilege. Simply walk through each on of these types of attacks as part of the session. Once that’s done we assess the attacks we found.

Assessing attacks

When coming up with attacks make sure to document the attack. They should still be visible to everyone to discuss mitigating controls. Again, this is where the group needs to speak up about how to mitigate controls. As a facilitator I’ve often had the answer but I want the group to provide that answer so they can start exercising those security thought muscles. Often, I’ve found that the group will come up with creative solutions for mitigating controls. Once all attacks have mitigating controls we move onto prioritization.

Prioritizing risks

I use DREAD, which is another mnemonic for evaluating and prioritizing risk. It stands for Damage Potential, Reproducibility, Exploitability, Affected Users, and Discoverability. I write each of these out to the side of the attacks so we can rate them. I use a 1-3 scale with one being low, two being medium, and three being high. I like to keep things simple but something like a 1-10 scale can also be used. Once a score is given for each of the items you add it up. The higher the number the higher the priority. This allows teams to focus on the attacks that have the most risk and can do the most damage. Make sure to identify and assign action items for addressing the necessary attacks.

Documenting the threat model

From there it’s documenting the outcomes of the meeting. I will take notes during the session (another reason to stay silent) and type those out in a follow up email to the group. I also take a picture or screenshot of the diagram and provide that in the meeting notes as well. I would recommend storing those in a repository that’s available to everyone involved in the discussion. As part of the meeting notes I include action items at the top and have the agreed upon name of the person that will make sure the item is addressed.

Summary

Threat modeling is simply a data flow discussion. I’ve used data flow discussion to make the meeting less intimidating. Sessions can be from one to several hours long it depends on the application or business process and how deep you may need to go. One long session or multiple sessions can be setup. Having a diagram ahead of time will significantly reduce the time needed for a threat modeling session.

The session itself is building the diagram, adding the security profile, attacking the application, identifying the mitigating controls, and prioritizing the risk. Finally, document the session and assign action items. Someone will need to follow up on each item to make sure they get addressed properly.

Next, we’ll dive deeper into methodologies and approaches that can be used as part of a threat modeling session.