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.

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

• https://owasp.org/www-community/Threat_Modeling

• https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

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