Tools and resources for effective Threat Modeling

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.

Getting Started

We’re going back to kindergarten people! We’ll get to draw shapes and lines and use different colored markers! To get started all one needs is a whiteboard and markers. Building out a diagram is the first step. As I mentioned in the Basics of Threat Modeling blog post having one prepared prior to the session will help expedite the process. Unfortunately, if there isn’t an existing diagram one will have to be done during the session. Adam Shostack has a description of the symbols and elements to use in a threat model on his GitHub page. They’re very simple and that’s the intention because threat modeling an application or process can get very complex.

Adam Shostack - DFD3 - https://github.com/adamshostack/DFD3

If the session is virtual and not in person the same principles applies. All popular video conferencing has a whiteboard feature on it that can be used for threat modeling. There are third-party options as well including:

• Microsoft Whiteboard (Usually free with corporate account)

• Microsoft Visio (License required)

• Microsoft Threat Modeling Tool (Free)

• OWASP Threat Dragon (Free)

• Draw.io (Free)

• Miro (Free version)

• Lucidchart (Free version)

• MURAL (Free version)

• Whimsical (Free version)

The tools I’ve had experience with are Microsoft’s Whiteboard, Visio, and Threat Modeling Tool. Visio and the Threat Modeling Tool get into a lot of detail and can feel complex if you’re just getting started. The more important thing is learning the methodology and approach to threat modeling. Threat Dragon has a lot more simplicity. It is open-source so doesn’t have all the bells and whistles of other tools. It can take a little to get used to using. I’ve seen developers create diagrams with Draw.IO. It’s simple and easy to use but be mindful that if they build it on a third-party website they may be putting internal organization information on the internet. I have not used Miro, Lucidchart, MURAL, or Whimsical but they look similar to Draw.IO. Leave a comment below with your favorite white boarding tool.

Automated threat modeling tools

I have only used Microsoft Threat Modeling Tool and OWASP Threat Dragon for automating parts of the threat model process. Microsoft’s Threat Modeling Tool get’s very granular and tries to be exhaustive on attack scenarios. If you like digging into a lot of details it can be a very useful tool. OWASP Threat Dragon is a much lighter version of that which is why I used it a lot more. For me I wanted the group to come up with their own attack scenarios because it allowed them to exercise their security muscles and build a stronger security mindset. This impacts the other areas of their day-to-day work. As their working they’ll be thinking about security.

There are other commercial and open-source tools that promise one-click threat modeling. I have not had an opportunity to use them. Here are some popular ones I found:

• IrisusRisk

• Threat Modeler

• SecuriCAD

• SD Elements

If you have used one of these or another leave a comment below.

Educational Resources

The book I always recommend is Threat Modeling: Designing for Security by Adam Shostack. It is “THE” book on threat modeling. What I love about the book is that after the first chapter it says to just start threat modeling. It’s more of a companion book for learning and maturing the threat modeling program.

OWASP is another resource for threat modeling. They have an entire project on everything you need to know about Threat Modeling. The OWASP Cheat Sheet is also a great place to start and a good reference point while maturing the threat modeling practice. Finally, an exhaustive list of threat modeling resources can be found at Awesome Threat Modeling on GitHub.

Leave a comment below with resources or tools you recommend. If you’re interested in seeing a version of this talk check out the ColaSec Meetup page as I will be presenting on threat modeling at the February 20th, 2024, meetup. A virtual option for attending is available.

Methodologies and Approaches for Threat Modeling

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.

There are a variety of ways to do threat modeling. Deciding which one to use will depend on the organization and what is being threat modeled. I started with STRIDE which is a standard methodology for getting started. We’ll touch on the other ones but I’ve not had experience with them. The basic concept should be the same. The methodologies are used to help guide a threat modeling session through attacking and mitigating the threats discussed.

MethodologieS

STRIDE

Developed by Microsoft, STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. This model helps in identifying threats in these six categories, making it easier to systematically address potential security issues.

Repudiation is the one that always get’s me. It’s attackers getting in and performing illegal operations without leaving any sort of evidence. This is usually due to a lack of logging. The others are fairly straight forward.

LINDDUN

This is a privacy-focused threat modeling methodology designed to help identify and address privacy threats in information systems. The acronym LINDDUN stands for the seven types of privacy threats it aims to uncover: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance.

PASTA

The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-step, risk-centric methodology. It focuses on aligning business objectives and technical requirements, taking into account the attacker's perspective and potential attack vectors. It is thorough and integrates well with risk management.

OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) is a suite of tools, techniques, and methods for risk-based information security strategic assessment and planning. It focuses on organizational risk and security practices, making it more suited for strategic, rather than technical, threat analysis.

Attack Trees

Attack Trees provide a methodical way of describing the security of systems, based on varying attacks. It's a graphical representation of potential attacks, organized in a tree structure, showing how an overall goal (root) can be broken down into sub-goals (leaves). This is an example of an attack tree.

Example of using STRIDE

Created with the help of ChatGPT

A threat modeling tweet by @thegrugq that highlights attack surface.

Below are some examples I’ve seen discussed in a threat modeling session. The skies the limit and will be different depending on the application or process. At the very least it’s a thought exercise that helps people think about security and discuss mitigating controls. Some of these attacks are more likely than others. Within healthcare insider threat and errors are a lot higher than other industries. They’re still susceptible to external attacks but the bigger concern may already be inside the organization. Each organization will have it’s own attack surface.

Spoofing

Threat: A healthcare provider uses another users logged in session when they walk away form their computer.

Mitigation: Ensure session timeout is set to what is needed for the business use case of the application. If a user has several activities that require waiting for something to finish in the application or they need to login into other applications and then come back then the timeout may need to be longer.

Tampering

Threat: A healthcare provider accidentally modifies the wrong record for two different patients.

Mitigation: Add a, “are you sure?” pop-up. Logging and recovery will need to be in place for identification and recovery.

Repudiation

Threat: A user (patient or provider) denies sending a message or making changes to records.

Mitigation: Implement detailed logging and audit trails to track user actions and changes within the application.

Information Disclosure

Threat: S3 bucket with patient information is accidentally made available on the internet.

Mitigation: Use access controls to enforce the principle of least privilege, ensuring users can only access information necessary for their role, and encrypt data.

Denial of Service (DoS)

Threat: A ransomware attack encrypts the web server.

Mitigation: Web server and all needed systems have good backups and can be restored to get the service back online for users.

Elevation of Privilege

Threat: A user is bribed to give up their credentials to the application.

Mitigation: User IP logging to help identify when a user logs in from an abnormal location.

Approaches

At my organization I was the person doing the threat model. I was training up some of the other people on my team so they could do it and not create a bottle neck with my department. Some organizations an individual or team may not be the best approach. In this case a decentralized approach could be more beneficial where the teams are trained up on doing their own threat models.

As far as automated tooling I haven’t used a lot of it other than as a substitute for a whiteboard. I have seen the use of Microsoft’s Threat Modeling tool which will help with attacks but will require a lot more interaction. There’s not really a wrong or right answer. I’ve shown a lot of value and made projects run more smoothly and with less threat introduced by using just a whiteboard and markers. Haven’t explore the automated threat modeling space but I do believe that you can’t replace a human. A one-push threat model would be nice it’s just not that easy and as I’ve learned in the industry there is no easy button.

Threat modeling should be done as early in the process as possible. However, it is very useful for legacy applications or applications with minimal documentation. I’ve used it a lot for getting a better understanding of how an existing application or process works, especially if there’s very little documentation. These sessions usually require multiple because as unanswered questions comes up and people are tasked with doing some discovery work. Once that discovery has been made the threat model continues.

Summary

STRIDE is a good place to start with threat modeling. There are other methodologies that could be more applicable to the organization. I’ve only ever used STRIDE because it was effective for what I was doing with threat models. Walk through the chosen methodology to get an idea on the attacks possible within the application. These attacks can be simple or they can be a bit more elaborate. A few simple examples will help with getting people to think about how to attack an application or process.

Approaches to threat modeling will differ between organizations. A group of security experts can make an effective threat model but it may not be scaleable. The other option is to train people within the projects to perform the threat model. Thinking about what could go wrong will get people into the mindset of looking for problems before they happen. The earlier a problem is discovered the less costly it is to fix. Threat modeling can also be used for discovery on existing applications or processes.

There are tools available for threat modeling. The simplest and often the most effective is a whiteboard and markers. Threat modeling is like any other security program. Get it started and then mature it over time. Try new things and evaluate if it’s useful or not. Just get started.

Next we’ll go over risk management and rating the discovered threats.

Basics of Threat Modeling

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.

Will Smith and Martin Lawrence singing Bad Boys in the movie 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.

What is Threat Modeling?

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.

Here’s what ChatGPT said:

Threat modeling is a structured approach used in cybersecurity to identify, prioritize, and address potential threats to a system. It involves a series of steps to assess the security of an application or system by identifying what needs to be protected, determining potential threats and vulnerabilities, and then devising strategies to mitigate or prevent the identified risks. The primary goal of threat modeling is to enhance the security posture of a system by focusing on protection measures from the early stages of design and development through to deployment and maintenance.

Within the context of the cybersecurity field this is true but it’s more general than that. Threat modeling is something we all do in daily life. Driving, planning a trip, planning a birthday party, talking about who’s going to win the Super Bowl, etc. It’s talking about what might happen and then putting things in place to help mitigate those potential scenarios. I use the analogy of driving a lot. While on the road I am constantly thinking about some of the following things:

• “What happens if this person get’s into my lane?”

• “The onramp coming up is usually pretty busy”

• “I have X amount of gas and this far to go”

This is threat modeling and we all already do this on a daily basis. This is why I find implementing threat modeling into a project to be super easy.

Threat modeling is a step-by-step process for identifying all the things that could go wrong. It’s meant to find solutions to problems before they happen. It can also be a lot of fun to come up with Mission Impossible level types of attack scenarios. Here are the steps to go through a threat model.

• Scope the application or project

• Build out a diagram of the application or project

• Identify what security measures are already in place

• Attack the diagram by using simple and elaborate attack techniques

• Identify mitigating controls for the attack scenarios

• Rate the attack techniques for prioritization

• Assign action items

• Document the session and follow up items

Sometimes these sessions can take an hour sometimes multiple hours are needed. Having a diagram before hand helps speed up the process.

Benefits of Threat Modeling

Doing threat modeling early in the development cycle can help get everyone on the same page and identify potential risks before development even begins. This allows developers to think through issues and put mitigating controls in place. This actually reduces the cost of finding a security issue later in the process because it’s addressed early on.

Another benefit I’ve found is in exploring legacy applications and applications that join the organization as part of a merger or acquisition. Often, applications don’t have any documentation in place. This can make it difficult if people who have helped build or maintain the application have left the organization. Threat modeling is a way to better understand and document those applications. Any security issues or risks identified can be added to the backlog for getting addressed.

Next we’ll dive deeper into the basics of threat modeling.

Why Threat Modeling is important

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.

But Why? meme from Harold and Kumar go to White Castle

Why this talk?

I’ve done 10 different topics publicly. Six of those talks had threat modeling in them. It’s something I bring up in over half of my talks. It’s low cost, easy to implement, easy to get started, and provides a tremendous amount of value. It’s main purpose is to talk through all the things that can go wrong but it also does a really good job of getting everyone on the same page.

One of my first sessions doing threat modeling one of the developers said, “I thought we were doing this in the cloud.” “Nope, we’re doing it in the data center.” That’s a pretty big difference in development and infrastructure efforts. The other thing threat modeling does is it get’s people into a security mindset. Thinking like a hacker isn’t a mindset a lot of people utilize. They’re builders; not breakers. To have an effective session and to start building that security mindset we have to show them the ways of the darkside.

Providing developers with a security mindset is the farthest left we can shift security into the software development lifecycle (SDLC). We can’t go any further than while they’re coding. They like to build things and don’t often think about how things can go wrong. Doing threat modeling at the design phase allows security to be thought about before development begins. This streamlines security into the SDLC and prevents security issues from popping up later in the process and in production.

A lack of threat modeling in the real-world

NotPetya

NotPetya leveraged a vulnerability in Microsoft Windows, EternalBlue and was further propelled by a compromised update mechanism of a widely used Ukrainian accounting software called M.E.Doc. Once a system was infected, NotPetya would encrypt the master boot record, rendering the computer unable to boot.

The impact of NotPetya was massive and far-reaching, affecting businesses, government entities, and infrastructure worldwide. Major multinational companies, including Maersk, Merck, FedEx's TNT Express, and many others, reported significant disruptions to their operations and financial losses. The total damages from the NotPetya attack are estimated to be in the billions of dollars, making it one of the costliest cyber incidents to date.

From a threat modeling standpoint this was an attack that unintentionally crossed network boundaries in the Ukraine and made it’s way to the United States. Network segmentation is an important talking point for projects that involve multiple countries and sensitive data.

SolarWinds Supply Chain Attack

Malicious actors compromised the software build system of SolarWinds, a company that produces network and infrastructure monitoring solutions. The attackers inserted a vulnerability into the software update mechanism, which was then distributed to thousands of SolarWinds' customers, including government agencies and Fortune 500 companies. This sophisticated attack highlighted the need for comprehensive threat modeling that includes supply chain risks and third-party dependencies.

Insider threat is an important talking point with internal processes that aren’t exposed to the internet. To kick start the conversation with developers and others new to threat modeling I often bring up insider threat to get the attack ideas flowing.

23andMe Hack

A credential stuffing attack was used by attackers to gain access to 14,000 accounts. 6.9 million users were ultimately impacted due to sharing permissions within the platform. While bad passwords are a problem, development teams via threat modeling can come up with solutions to a credential stuff attack. Multifactor Authentication (MFA), password strength, and detection for these types of attacks are all mitigating controls that can be put in place. Sharing permissions can also be discussed as part of a threat modeling session to ensure proper authorization mechanisms are in place and personal information isn’t exposed to a broader audience.

In the next blog post we’ll cover what is threat modeling?

Examples created with the help of ChatGPT

Converge and BSides Detroit talks and slides

I had a great time at Converge and BSides Detroit.

This was my third attempt at going and I'm happy I finally got the opportunity to do so. The last two years I've had to cancel my plans due to life reasons. I did two talks this year. One at Converge and one at BSides. Both are linked below along with the slides for both talks.

How to kick start an application security program - Converge Detroit

I've given this talk at three other BSides prior to Converge. I feel like this is my best presentation of the talk so far. I will be giving it again at ShowMeCon in June.

Slides

The AppSec Starter Kit - BSides Detroit

This was my first time giving this talk. I thought it went well for it's first attempt. It still needs polish. It will probably be a while before I give this talk again at a security conference. I made this talk to present at developer conferences. It hasn't been picked up, yet. I'm hopeful it will for some talks later this year.

Slides

This blog post first appeared on Exploring Information Security.

Trends 2015 presented by IT-ology wrap-up

Trends 2015 presented by IT-ology was today and I am exhausted.

Every year in the fall IT-ology selects a technology topic to hold a conference on. This year was security, so naturally ColaSec was involved in providing speakers, volunteers, and marketing for the conference. Four keynote speakers filled the morning track and 12 speakers filled the afternoon tracks, which were split into technologist, civilian, and business. I presented a talk titled, "Low cost tools for security challenges" in the technologist track.

For those coming to my site who were in that talk, here are my slides and here are my videos (from previous conferences) of the talk. I got some good feedback from in regards to the talk, which was very much appreciated.

Trends 2015 was the last time I intended to give this particular talk. The recordings are out, my slides are out there, and I'd like to move onto some fresh content. What that is, I don't know yet, but I have some ideas. Before I move onto some fresh content, I want to compliment the video and slides of my talk with some blog posts that go a little more in-depth with the tools I presented. Over the next several weeks I intend to have a post a week, with step-by-step instructions on how to use each of the tools in my talk.

Thank you to everyone that made it to my talk and any feedback is still welcome.

This post first appeared on Exploring Information Security.