Threat modeling

In Chapter 2, Vulnerabilities, Attacks, and Countermeasures, we walked through a threat modeling process for a smart parking system. Here, we talk more about the threat modeling process and discuss a tool that can be used to model the threats to your unique systems.

The best defense against attacks aimed at your products and systems is to design security in from the beginning. But not all systems are alike, and nor do they each face the same threats. Design teams must arm themselves with the information needed to understand the unique threats faced by their systems. This requires starting out with a threat model of your system.

The outputs of your threat model will allow you to derive security requirements/user stories that can be included in your backlog, and traced to completion as the system matures. 

There is an initial investment to be made in conducting these threat modeling activities, but the upfront costs of these actions pale in comparison to the costs associated with seeing your product or organization pilloried in the news, battered on social media, or fined by a government regulator for gross negligence that resulted in a major compromise.

Chapter 2, Vulnerabilities, Attacks, and Countermeasures, provided an in-depth review of the threat modeling process, and examined attack trees and other artefacts to accompany it.

There are many threat modeling approaches to choose from. Review the approaches here, and decide on a process that is right for your organization:

• SAFECode Tactical Threat Modeling: https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TM_Whitepaper.pdf
• Carnegie Mellon's OCTAVE Allegro Guidebook: https://www.cert.org/resilience/products-services/octave/
• OWASP's Threat Modeling Cheat Sheet: https://www.owasp.org/index.php/Threat_Modeling_Cheat_Sheet
• Getting Started with Microsoft's Threat Modeling Tool: https://docs.microsoft.com/en-us/azure/security/azure-security-threat-modeling-tool-getting-started

Whichever approach your team chooses, the starting point always involves getting better visibility on the components, interfaces, and data flows of your product. Use data flow diagrams and create architectural views of your product to gain and retain this visibility.

You can use open source tools to help guide you throughout the creation of these diagrams. For example, Microsoft and OWASP both make threat modeling tools available. The OWASP tool, known as Threat Dragon is in prerelease as of the writing of this book, but offers useful features to help you get started with your threat modeling activities.

We'll walk through some of the functionality of Threat Dragon next. You can download the Threat Dragon executable or source code from GitHub at https://github.com/mike-goodwin/owasp-threat-dragon-desktop/releases and follow along.

The tool's splash page allows you to define your project. Enter a title for your project, an owner/reviewer, and a high-level system description. You can then create one or more data flow diagrams that you will use to document product interfaces, and data flows, and then identify threats to each.

The following screenshot shows the OWASP Threat Dragon splash page:

Your data flow diagrams should cover the data processed by the system. If we take a simple IoT use case—for example, a smart light bulb—we can draw a data flow diagram that shows the smart light bulb connecting to a device hub and a smartphone application.

We can then label data flows to the smart light bulb as configuration commands and pairing requests. We can label data flows coming from the smart light bulb as device status messages. 

You can also document security attributes associated with your data flows—for example, defining within the tool whether data sources are authenticated, and whether data flows are protected with encryption.

The following screenshot shows a data flow diagram created using Threat Dragon:

Once you have your system documented, you can then begin assigning threats. Associate these threats to actors or data flows. Invest time in defining your threats, and use a systematic approach to doing so. The STRIDE model described in Chapter 2, Vulnerabilities, Attacks, and Countermeasures, provides a framework for thinking through the different threats that your specific product might face, and Threat Dragon uses the STRIDE model to categorize the threats you define.

In the following figure, you can see a new threat defined—Unauthorized User is able to Pair Smart Phone with Device Hub—and this is assigned to the STRIDE category of Spoofing:

As shown, you can rate the Severity of the threat as High, Medium, or Low. This will become important as you prioritize your risks later in the process. Assign the threat status as either Open or Mitigated, and provide a narrative description of the threat. If already known, you can detail your mitigation approach as well.

Continue to enter threats to your system. Use the tool to catalog and prioritize your threats, and consider your mitigations. The mitigations that you define will be used as a starting point for your product security backlog.

Allocate the user stories/requirements to various sprints within your development based on their priorities, and track these stories to closure as development progresses.