Shifting Left for Speed: Threat Modeling in the Agile SDLC

The Strategic Shift Left: Threat Modeling as a Proactive Design Practice

For content on these topics check out my book on Application Security and Threat Modeling

You’ve probably heard the well-worn phrase “shifting left”. This term has become a cringe-inducing or eye-rolling phrase in cybersecurity and specifically in application/product security largely because (as the complaints go) focusing on the left most part of the design lifecycle means we’re not focusing elsewhere. But the principle still remains valid even as we try to “shift-everywhere”.

So what does shifting left still mean in a modern development lifecycle where new releases happen before we can pull up the design artifacts from the previous release? It comes down to moving the security analysis to the beginning of the development process. Where we can have the largest impact on risk reduction.

Is Software Threat Modeling Different?

Threat modeling as a practice can be applied to various scenarios such as the supply chain, AI systems, and critical infrastructure. But software threat modeling brings about different challenges as the release cycles are fast. Sometimes multiple times a week. Sometimes multiple times a day. That can make the heavy, documentation driven threat modeling process ineffective. It may produce a more thorough picture of the system, but modern development teams can move from requirements to production in a matter of days, we need something better.

This is where we can get creative on threat modeling. We still need to identify, evaluate, and address threats during the design phase but at a molecular level where we can gain some time efficiencies. Instead of modeling the entire system, we can focus on smaller more manageable parts of the overall system. To over-use a term, we need to shift left. Way left, where we can ensure that security is addressed from the start, allowing us to guide architectural decisions before they are made and secure coding practices before code is written.

Employing a Lightweight Methodology for Speed

Within fast-paced environments, lightweight and rapid threat modeling techniques need to align closely with development artifacts, such as user stories and requirements. Here is how teams can focus their efforts on user story-level threat modeling and maintain speed with an eye toward avoiding the interruptions to the flow of development.

The Shostack Four-Question Framework

The core of rapid threat modeling relies on the simple Shostack Four-Question Framework:

1. What are we building? This question helps organizations focus on their goals and get the various teams on the same page. The phrasing “we are working on” aligns well with Agile development, encouraging analysis of the specific part (feature, user story, etc) being addressed right now, rather than an analysis of the entire system. Answering this question often involves having documentation of the system such as data flow and architecture diagrams. Or at least having the right mix of people that can speak to the design and architecture.

2. What can go wrong? This question should trigger creativity in the team as they search for potential problems. Phrasing it this way expands the space of possible answers by avoiding using specific terms like threat, risk, and vulnerability. Additionally, asking this question should allow more people to get involved. We can all paint worst case scenarios in our mind. This doesn’t require technical or security acumen.

3. What are we going to do about it? This question focuses on the technical and business activities that should be taken in response to an identified problem. Here is where we begin to apply our strategic techniques of risk management: mitigation, acceptance, elimination, or transfer. The “going to do” phrasing implies a future action, which often results in items being added to the development backlog or the current sprint depending on risk level.

4. Did we do a good job? This question encourages reflection on the work completed. Are we seeing less re-work, or fewer issues from security tests? Are we improving the overall threat modeling practice over time? While not immediately impactful to the threat modeling activity for a given scenario, this question is used in the spirit of continued improvement where the definition of a “good job” extends beyond just finding threats and looks to ensure that problems are tracked and subsequently fixed.

Example with PicShare

These questions should be asked when a new feature is being proposed from the product or engineering teams. Let’s take an example using PicShare, a fictional cloud-based photo-sharing social media platform designed to mimic the core functionality of apps like Instagram or Flickr. PicShare defines a user story requirement during the analysis phase like this:

Requirement: Users must be able to upload photos from their devices, and the system must extract and store metadata such as location, device type, and timestamp.

During requirements gathering and prioritization the product team along with the development stakeholders use the Shostack questions to determine whether there are security requirements that would need to be created.

What are we working on? Here we know that the team is working on the functionality that allows a user to send a file from their device to the PicShare platform. This involves accepting the file, processing it to extract metadata, and storing it.

What can go wrong? Here the team to works to identify potential threats without getting caught up in technical jargon. Below we’ll identify a single threat scenario (for brevity). You can find more in “Threat Modeling Best Practices.” Chapter 4:

Threat Scenario (TS01): A Threat Actor (TA01) uploads a file disguised as an image that contains malware or malicious scripts, anticipating that it will be executed by other users or by PicShare’s internal systems.

Specific Threat Vector: This scenario involves exploiting weak or missing validation, such as uploading .exe, .js, or .php files with spoofed MIME types, excessively large files, or using image metadata (EXIF) to inject malicious payloads.

What are we going to do about it? Now that we know the potential threat scenario, we can focus on developing the path to remediation in the form of security controls (C01) allowing us to integrate early in the design lifecycle:

Security Controls Devised (C01): The team determines that they need to implement strict, server-side validation of file types and MIME headers, and restrict uploads to safe image formats (e.g., .jpg and .png) and size constraints. This creates a specific requirement that is implemented with the feature:

Input Validation: The system must validate MIME type and file extension on the server side, require a MIME type allow list to block potentially dangerous file types, and perform deep content inspection to verify that actual file contents match the declared type.

Secure Handling: The system must generate random IDs for filenames and enforce secure file permissions to mitigate risks like path traversal and command injection.

Through this exercise in a requirements gathering/review meeting, the team is able to create security requirements, which are treated no differently than other functional requirements, and open them in the development defect tracking system for tracking and implementation.

While this does not look like the formal process of threat modeling with tools, documentation gathering, and meetings, this process is done in a just-in-time manner when the design is in its infancy and security controls can be developed more cost-effectively.

Misuse and Abuse Cases for Validation

One of the other benefits of threat modeling at this stage is that abuse and misuse cases can be created to ensure that what was identified in the threat model has truly been resolved. These test cases should be derived from practical scenarios that simulate how attackers or misuse can occur to weaken the system. These cases should cover both expected attack patterns and edge cases where possible and will require some creativity. However, creating test cases that directly map to identified threats allows teams to not only verify the effectiveness of their security controls but also confirm the validity of the threat model. In other words, your abuse case should identify both that the threat is a realistic scenario, such as being able to upload a file with a size exceeding the limits or using a file type that is disallowed, as well as verifying that the application blocks such requests. Below is a quick example of a Selenium test case that can be written to ensure that the application blocks files exceeding a threshold.

from selenium import webdriver
from selenium.webdriver.common.by import By

# Setup WebDriver
driver = webdriver.Chrome()
driver.get(”https://mydomain.com/upload”)

# Select oversized file (> limit, e.g. 15 MB)
file_input = driver.find_element(By.ID, “fileUpload”)
file_input.send_keys(”/path/to/oversized_test_file.zip”)

# Submit upload
driver.find_element(By.ID, “submitButton”).click()

# Verify rejection message
error = driver.find_element(By.ID, “errorMessage”)
assert “File exceeds maximum size limit” in error.text
driver.quit()

Through this threat modeling exercise, we have our requirements, our identified threats, our defined security controls, and test cases that ensure that our controls are working. All set in motion from a single requirements conversation with stakeholders. While this process is lightweight and may not identify every potential threat to the overall system, new features are analyzed and secured from the start by asking basic questions.

The Path Forward

My preference in threat modeling is to utilize a more thorough process that enables better documentation, communication, and clarity of the overall system. However, that process can weigh down development teams that require speed with their security. The basic steps outlined here, including the Shostack Four Questions, show how we don’t need to include the full weight of a formal threat modeling process in order to integrate security into our software. We just need to ask some basic questions and integrate with the existing process.

Happy threat modeling!

For content on these topics check out my book on Application Security and Threat Modeling