The Art & Science of Software-Centric Threat Modeling

A New Take on an Age-Old Security Principle

Security is integral to software development, and threat modeling remains one of its cornerstones. The recent conversation between Chris Romeo and Farshad Abasi illuminates the value of adopting an engineering-led, asset-based threat modeling approach. Both agree that the key to effective threat modeling is to keep it as specific and actionable as possible, focusing on assets, data, and user stories.

Asset-Based Modeling: Beyond Traditional Threat Assessment

Asset-based threat modeling is a straightforward approach to the discipline. It’s simple and uncomplicated. In this method, the asset is the focal point—whether it's user data, computational resources, or other elements that may have a direct financial impact on the organization. Abasi argues for a dual assessment that focuses not only on the Confidentiality, Integrity, and Availability (CIA) of the data but also considers the resource impact on the infrastructure. By anchoring threat models to assets, organizations can prioritize their security measures more efficiently.

The application’s assets are not just limited to customer data like balances and names, but also extend to computational resources running the application. Abasi highlights the dual risk—firstly, the potential compromise, deletion, or exposure of sensitive financial data, and secondly, the misuse of computational resources, such as attackers deploying crypto-mining processes that would financially burden the owning department. The idea is to consider both data and infrastructure as assets and assess how they could be adversely affected in terms of Confidentiality, Integrity, and Availability (CIA). This approach serves as a comprehensive lens for evaluating threats, thereby aiding in creating robust security measures.

The Importance of a Robust Process

Repeatability is crucial in threat modeling, and Farshad has a specific take on this. He likens the approach to securing a house, identifying various entry points like windows, doors, and chimneys, and assessing their vulnerabilities. A malicious actor will find whatever entry point they can to get at the assets. And, the more valuable the assets, the more the malicious actor will do to get the data – a guiding principle for how theoretical you get when building the model. This analogy helps to conceptually break down the steps for software engineers, making threat modeling more approachable and effective.

Threat Model Every User Story

Emphasis must be placed on considering user stories in threat modeling. We advocate threat modeling every user story, including what a malicious actor would want to do.

Farshad adds a valuable tool for turning a user story into a threat scenario—just append a "comma, but" to the user story. For example, if the user story is "As a user, I should be able to view my transactions," adding "comma, but" turns it into "As a user, I should be able to view my transactions, but I should not be able to see other people's transactions." This approach helps developers to consider what the "evil user" might do, and to add controls accordingly.

Augmenting Pull Requests for Enhanced Security

One practical tip that emerged from the conversation is the use of pull request templates in Git to remind developers of security best practices. These templates can include prompts about access control, input validation, and other cross-cutting concerns that ought to be considered in the context of the threat model.

Striking the Balance

Finally, the discussion underscored the importance of considering threat modeling at both the user story level and the high-level architecture level. Farshad suggests doing architectural threat modeling initially and revisiting it at certain intervals, such as quarterly or annually.

Timing is pivotal when incorporating threat modeling into the DevOps—or DevSecOps—process. Architectural threat modeling should be done at the very inception of your project, as your architectural framework begins to coalesce. This stage is critical; it lays down the security blueprint that for future development sprints. Revisiting this model is advised, perhaps quarterly or annually, especially if there are significant changes in architectural elements, interfaces, or new third-party interactions and data stores.

When you're deeply embedded in the development cycle, functional threat modeling becomes more challenging to implement retroactively. Here, DevSecOps integrates security measures by routinely reviewing user stories within the sprints. Otherwise, retroactive threat modeling necessitates a narrowed focus—zeroing in on core functionalities rather than a granular examination of each user story. The objective then shifts to identifying potential vulnerabilities within those key business functionalities.

So, to distill, architectural threat modeling is not a day-to-day developer task but rather a foundational exercise carried out at the onset and revisited periodically. If you're initiating a DevOps or Agile project, the product inception stage is where you lay down your architectural roadmap. At this juncture, it's advisable to involve a security Subject Matter Expert (SME) to assist with traditional architecture-level threat modeling, ensuring that security considerations are deeply ingrained from the get-go.

Threat modeling doesn't have to be a daunting task. Developers can anticipate and mitigate security threats by integrating a well-defined, asset-based approach seamlessly into the development lifecycle. When security is deeply rooted in the engineering process, everyone can have more confidence in the resulting solutions.

This post is based on an episode of The Threat Modeling Podcast. Listen to the full episode here: Software-Centric Threat Modeling