Protect Your Software through Threat Modeling
With the rise of cybersecurity threats around the globe, many software organizations are overwhelmed with a laundry list of vulnerabilities. They often have no idea where to start, how to determine prioritization, and whether or not those vulnerabilities accurately represent the threats to our applications, users, and data. Threat modeling is a simple yet effective solution to addressing this concern.
Threat modeling works to identify and understand the threats and mitigations to our applications within the context of protecting the data or resources in use. It can be done at any stage of development, but an earlier introduction allows the identification of findings to better inform the design of the application or system. This can reduce costly rework by resolving architectural deficiencies sooner. However, even if your application is mature, it’s better late than never.
During the modeling exercise, the full team—including product owners, testers, engineers, architects, and so on—meets to discuss the system, threats, and mitigations. Unlike a requirements review, where a team would review what the system should do, a threat modeling exercise asks you to think about ways things could go wrong, work backward to understand how your current controls would help, then identify gaps in your system.
While threat models can vary in implementation, most include:
- A high-level description of the app and what you’re most worried about protecting
- An architectural design or model of the application
- A list of assumptions that can be validated as the threat landscape changes
- A list of potential threats to the users, data, or system
- A list of mitigations to potential threats and actions to be taken
- A plan to validate whether the model and threat mitigations were successful—this includes the identification of security test cases and scenarios
By bringing everyone together to include threat modeling in the software development lifecycle, the team can not only build a more secure design, but also collaborate on a shared understanding of the threats, security controls, and how to balance the risks with usability. In addition, it focuses the team (and security engineers) to address the most likely security threats instead of exhausting efforts on uncommon scenarios that are unlikely to realistically affect the system.
It’s impossible to protect and defend your software against everything bad that could happen. But the most important thing you can do is educate yourself and your team about how to effectively model threats against your system and determine which ones are of the highest impact and likelihood. These are the things we should prioritize and do something about.
