The Unexpected Benefits of Threat Modeling
“He that breaks a thing to find out what it is has left the path of wisdom." - Gandalf the Gray
Gandalf rarely got it wrong, but in this case he may not have been exactly right. To truly understand a product’s utility and ways to secure it, we must consider it not only from the perspective of it purpose but also from its attributes when maliciously repurposed—breaking it, as it were. Modifying or breaking a thing in order to improve it is the distillation of the hacker mindset; not simply being concerned with what a thing is but more so with what it can be made to do, either constructively or maliciously.
Threat modeling is a disciplined approach to technology design that identifies security threats and design constraints to prevent security flaws before they manifest in your platform. Integrating a threat model into project planning and design may seem like extra work tacked on to an already arduous endeavor. This effort, however, is far outweighed by benefits such as early accounting for design flaws, compliance requirement planning, and improved understanding of the underlying architecture.
Why threat model?
It has been my experience that anything can benefit from a threat model: A simple threat-based mental model can assist in even mundane tasks. Consider, for example, the threat model of a knife slicing a tomato. The biggest threat is cutting your hand. Whether you’re implementing input validation or building an addition on a home, planning for what can go wrong is key.
The goal of threat modeling is not to stop attacks on existing vulnerabilities but to prevent the attacks from being possible in the first place. This is accomplished by extending the design process to include identifying possible security threats, requirements, and vulnerabilities, and then tracking said items. This simplifies the process of implementing the design securely because identified threats can be accounted for within each feature, functionality, or section of a product.
When is threat modeling most beneficial?
A threat model provides maximum benefit when it’s conducted as early as possible in the project planning and development phase. Identifying threats before making the architected idea reality avoids the elevated effort necessary to modify an existing structure. The more developers understand about a product’s security posture, the better they can prevent threats originating from its design, be they abstract concerns arising from architecture or actual flaws in functionality. Creating a threat model is invaluable in security-conscious planning and development.
Using threat models in red teaming and pentesting
A good threat model can enhance other security practices as well (see Appendix for examples). Existing models are particularly useful in red teaming and pentesting.
Red teaming is a wonderful (and fun) practice wherein authorized security experts attempt to attack an organization’s resources from the perspective of a malicious actor. These exercises allow organizations (or entities) to evaluate the efficacy of their existing security controls and mitigations. A red team with access to existing threat models can more easily evaluate model failures and expose areas in an organization that need further hardening. Red teamers also use threat models to focus and expedite testing efforts, thereby improving accuracy and reducing costs.
Pentesting is typically conducted against logical systems such as software, servers, and networks, wherein experts conduct and evaluate test cases for security concerns.
A good threat model provides testers with an easily discernable roadmap for their evaluation.
Detailed models may explain the overall architecture of the item under test and enumerate the required security concerns. Ideally, associated acceptance criteria, mitigations, and remediations are also documented. Existing models can inform testers about control evaluations and areas of security concern, giving them a more solid foundation from which to begin their efforts.
This is not to say that a threat model is intended to enforce restrictions on a security expert’s efforts. But using information from a good model can result in a more informed security engagement from the start. Engagements with no focus, with no identified areas of concern, can leave a test open-ended to the deficit of the customer. From my pentesting experience, I’ve learned that going into an engagement with more context is always a benefit. Access to previously identified and prioritized security risks and concerns expedites engagements and elevates the quality of results.
Who am I?
I've been working as a security consultant for LSG for just shy of three years, and before that I was the lead application security team member of a fortune 100 ECM software development company. These experiences have given me a deep understanding of the benefits, available methodologies and tooling, and potential deficits present in well-established threat modeling methodologies (I’ll be talking about this more in future posts).
Closing thoughts
Using a threat model early in the design process is essential to building security into your technology. Yes, it’s extra effort and planning, but the payoff is staying ahead of your adversaries. Why not do the work up front instead of creating separate tasks with their own overhead and validation?
I’ll be following this post with a collection of posts that dig into threat modeling and the related discipline of attack surface analysis. I hope my writing efforts will, at the least, improve the reader’s understanding of threat modeling and help expand the practice to any who are interested.
Some resources to get started with threat modeling
Appendix – Example security safety planning scenarios
Software design requirements and security considerations
Authentication and authorization
Functionality limitations
Error handling
Code execution protection
Data type protections
REGEX implementation
Database connections
Network topography requirements
Redundancy
Connectivity
Port configurations
Logical security mechanisms
Denial-of-service mechanisms (think Cloudflare)
Network hardware appliances
Intrusion prevention systems (IPS)
Intrusion detection systems (IDS)
Uninterruptible Power Supplies (UPS)
Load balancers
Physical and on-premises security requirements
Fencing
ID badges
Door locks
Security cameras
Alarms
Fire suppression systems
Emergency medical equipment
Disaster and Emergency evacuation drills and routes
Toxic gas detection systems
Transportation safety planning
Airbags
Crumble zones
Collision detection mechanisms
Lidar
Dash cams
Reverse cameras
Seatbelts
Collision-resistant glass materials
Disaster Relief Scenarios
Resource allocation
Evacuation routes
Personnel requirements
Clean and accessible food, water, and clothing (as part of resource allocation)
Disaster prevention
Flood valves
Evacuation routes
Fire suppression systems
Credits
Written by Juliette Moss - Security Consultant at Leviathan Security Group
With special thanks to:
Barbara Gray
Tom Overbey
Frank Heidt
