It is possible to eat meals without vegetables and still function, many people do, just as it is possible to create and deploy software solutions without threat modeling. The outcomes in both these cases is usually a functional system that may serve their primary purpose under controlled conditions but are prone to catastrophic failures when attacked by undesirable entities – such as diseases and hackers!
Threat modeling is an essential activity for reducing the overall risk to software solutions. If done correctly, it can do more to reduce overall risk to a software solution than any other security activity. Put simply, Threat Modeling is for identifying threats from undesirable agents and their impact on the assets that software solutions manage.
A secure software solution starts with understanding the threats posed by various actors on the system. Remember, threats are not actual vulnerabilities or weaknesses in the software solution – threats are imagined negative consequences that may occur if adequate mitigations are not implemented. On the other hand, an attacker tries to find unmitigated weaknesses via attack vectors to turn threats into actual vulnerabilities. The concept is pretty simple: Identify and quantify threats to your solution, then devise appropriate defenses.
In a general sense, most people do threat modeling in their day to day lives and just don’t realize it. Whether it’s deciding if you should buy life insurance, lock the front door of your house when you leave, or share your location via your smartphone.
Threat modeling can occur during planning, design, or feature implementation phases. It is also frequently used for deployed applications. Below is a simplified approach to threat modeling that will get you on the right path by thinking about threats, how they can be realized, and how to best mitigate them.
Step 1: Identify security objectives
Understand security requirements and identify possible threats in business flows to achieve objectives. Consider if there are any specific compliance or security-related requirements that are a part of the business objectives. For example, during auditing, sensitive information (e.g. SSN number, age, etc.) should not be logged and the log file should only be accessible to a specific set of users.
Step 2: Identify assets and external dependencies
Unauthorized access to assets such as data, code, and system information is the primary reason why threats are realized. As a result, architects need to:
- identify a list of assets to be protected from potential attackers
- identify external dependencies that may pose a threat to the system, e.g., 3rd-party libraries
- consider how the application will be accessed on the production environment or the web server
- consider how database communication will take place on a private or public network.
Step 3: Identify trust zones
Architects must identify a trust zone and corresponding entry-exit points. This information should be documented and used to develop data flow diagrams with privilege boundaries. This helps define the approach to user authentication, input data validation, and error handling. An example is an e-commerce website where the order processing system can be identified as a trust zone that will need a price validation check against the ordered item ID.
Step 4: Identify potential threats and vulnerabilities
Besides running a wide search for threats under a predefined approach like STRIDE, consider threats that would generally impact your system: SQL injection, broken authentication, and session management vulnerabilities. Identify risk-prone areas like poor input validations, over privilege accounts, weak password policies, custom encryption, inadequate auditing or logging, displaying error, or exception messages to end-users.
Step 5: Document the threat model
Threat modeling is an iterative process, and documentation forms an important aspect of the team’s responsibilities. It can be used to ensure your biggest threats are being considered and mitigated with every role:
- Architects can use documentation to create secure design/architecture and mitigate architecture-related security threats.
- Developers can use documentation as security guidelines to mitigate security risks, and
- Testers can use it to build test cases to find vulnerabilities in the system. It helps the tester create security-related test cases and validation test cases for the trust zone.
- InfoSec and penetration testing teams can use thread models to test for security holes in production and/or fine-tune vulnerability scanners.
What Threat Models are and are not
In addition to ensuring your teams focus on the most critical threats, threat modeling offers the following benefits:
- Helps identify, enumerate, communicate and understand threats and mitigations
- Protect application assets
- Prioritize security improvements
- Provide a deep understanding of product and components
- Enables informed functionality vs. security trade-off decisions
It’s just as important knowing what threat models are not:
- A representation of how an attacker approaches a system - it represents total system security, not an attacker model
- A test plan - a test plan is driven by a threat model, but threat models offer a lot more than just test planning
- A formal proof of system security
- A design review - threat models are the foundation of it, but a design review needs to cover more implementation details and considerations beyond security
Threat Modeling reinforces the notion that security efforts should be focused on those areas that can cause the most harm. It is not role- or technology-specific, but rather a way of thinking about managing technology risk.
Threat modeling and other principle-based approaches are critical to getting back to basics as tech stacks become more complex and their ecosystem more hostile.
It may not be fun initially but will help strengthen your software solutions from within. With practice, and as you start to see the benefits, you may even start to enjoy eating these veggies, many people do!
We’ve been threat modeling software solutions since 2002. Download our white paper The Art of Threat Modeling for IT Risk Management. It outlines two approaches to threat modeling—both needed for a proven methodology for effectiveness.
