Threat Modeling Designing For Security by Adam Shostack

Anyone can learn to Threat Model. Threat Modelling is as fundamental as version control. Threat Modelling helps you look at the big picture. You can threat model almost anything from a piece of software to a business and all the way to a country's economy.
Threat Modeling Designing For Security by Adam Shostack
Threat Modelling Designing for Security by Adam Shostack

On this page

๐Ÿ’ก
This summary is a work in progress. Every time I pick up the book, I find some insight that I haven't pondered on previously and was hiding in plain sight.

My goal is to keep updating this summary as I continue to uncover valuable insights in this book.

Summary

  • Anyone can learn to Threat Model. Threat Modelling is as fundamental as version control.
  • Threat Modelling helps you look at the big picture. You can threat model almost anything from a piece of software to a business and all the way to a country's economy.
  • The book is a comprehensive guide to threat modeling, a proactive strategy for improving security by identifying and mitigating potential threats and vulnerabilities in software, systems, networks, or business processes.
  • The book explains what threat modeling is, why it is important, how to do it, and what tools and techniques can help.
  • The book covers various threat modeling approaches, such as asset-centric, attacker-centric, and software-centric, and provides a framework for structured thinking about what can go wrong and how to prevent or reduce it.
  • The book also offers practical advice on how to test designs against threats, how to address threats that have been validated at Microsoft and other top companies, and how to communicate and document threat models.
  • The book is aimed at security and software developers who need to design secure products and systems and test their designs, as well as security professionals who want to learn how to discern changing threats and adopt a structured approach to threat modeling.
  • The book is based on the authorโ€™s extensive experience as a threat modeling expert at Microsoft and elsewhere and includes real-world examples and case studies.
  • The book is not tied to any specific software, operating system, or programming language but rather provides general principles and best practices that can be applied to any context.
  • The book is one of the most prominent and authoritative books on threat modeling and has been chosen as a Dr. Dobbs Jolt Award Finalist.

Chapter 1 - Dive and Threat Model

  • ๐Ÿง  Threat modeling helps to find and fix security problems before they occur by abstracting away details and focusing on the bigger picture.
  • ๐Ÿ’ก A four-step process for threat modeling includes understanding what you are building, determining potential issues, addressing those issues, and assessing the effectiveness of your analysis.
  • ๐Ÿ“Š A diagram of your software system helps to visualize and communicate its structure and data flow during threat modeling.
  • ๐ŸŽฏ Focusing on trust boundaries, or areas where control transitions between different entities, can help identify critical threats.
  • ๐Ÿƒ The Elevation of Privilege game is a playful method of learning to threat model by identifying potential security flaws in your software system.
  • ๐Ÿ“ The STRIDE mnemonic (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) helps to identify various types of security threats.
  • ๐Ÿ”„ Continually updating and refining your threat model throughout the software development process ensures that potential vulnerabilities are accounted for and addressed effectively.

Chapter 2: Strategies for Threat Modeling

Chapter 2 of "Threat Modeling: Designing for Security" discusses strategies for threat modeling during the early stages of the development or design process.

Threat modeling methods are adaptable, like Lego building blocks, and can range from basic strategies such as "What's your threat model?" to brainstorming about threats.

Three strategies for threat modeling are presented: focusing on assets, attackers, or software, each with its strengths and potential issues. Various techniques for brainstorming threats are also discussed, including scenario analysis, pre-mortems, and movie-plotting.

The chapter concludes with suggestions for structured approaches to threat modeling.

  • ๐Ÿง  Brainstorming in a safe environment can help generate ideas to address possible threats in the system.
  • ๐ŸŽฏ Focusing on assets, attackers, or the software during threat modeling can provide more structured and targeted methods to address threats.
  • ๐ŸŽฌ Movie plotting can provoke outrageous and creative ideas by implementing components from various and often unconnected fields.
  • ๐Ÿ’ป Reviewing threats to similar systems and researching competitors' security issues can help reveal potential vulnerabilities.
  • ๐Ÿšง Setting clear boundaries and exit criteria during brainstorming can help ensure the session's effectiveness and prevent exhaustion.

Favorite Quote from Chapter 2

Writing Secure Code, author David LeBlanc notes that โ€œA process without input is a miracle, while one without output is a black hole. Either you're missing something, or have mistaken a process for people, who are allowed to be black holes or miracles.โ€

Chapter 3: STRIDE

Chapter 3 in Threat Modelling: Designing for Security discusses the STRIDE approach to threat modeling. STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

The technique assists software developers in identifying potential attacks their software may be susceptible to.

It also introduces methods and terminologies related to threat discovery.

This chapter elaborates on what STRIDE is, why it is valuable, and the six components of the mnemonic.

It also discusses variations of STRIDE, such as STRIDE-per-element, STRIDE-per-interaction, and DESIST.

The chapter explains each component in detail, providing examples and discussions to help understand how to use STRIDE in threat discovery.

  • ๐ŸŽฏ STRIDE is a framework used in threat modeling to identify potential attacks that software could face.
  • ๐Ÿ› ๏ธ The technique includes six elements: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
  • ๐Ÿ“š The book discusses finding threats, covering various perspectives on whether threats exist in the software or the minds of the analysts.
  • ๐Ÿ™‹ STRIDE requires users to understand the framework and know how to use it, and provides examples and tables for educational purposes.
  • ๐Ÿ”„ Variations of STRIDE include STRIDE-per-element, STRIDE-per-interaction, and DESIST.
  • โš™๏ธ STRIDE was not designed for the categorization of threats but rather as an aid to identify potential attacks.
  • โœ… Each component of STRIDE, along with definitions, examples, and typical victims, is explained in detail in this chapter.

Chapter 4: Attack Trees

Chapter 4 of "Threat Modelling: Designing for Security" focuses on attack trees, a structured way to describe the security of systems based on possible attacks.

Attack trees can serve to find threats and organize found threats. It illustrates how to use an existing attack tree, build a new one, and examine several example attack trees.

The chapter encapsulates the concept of structured representations of attack trees, the use of attack trees to enumerate threats, the process of developing a new attack tree, and ways to improve their quality and presentation.

  • ๐Ÿ“š Attack trees provide a structured way to understand the security of systems by representing potential attacks in a tree structure, with the goal as the root node and various ways to achieve that goal as leaf nodes.
  • ๐Ÿงฑ Attack trees can be used as an alternative approach to STRIDE or used to organize threats found with other building blocks.
  • ๐Ÿ•ต๏ธโ€โ™‚๏ธ Attack trees can be employed to find threats if they are relevant to the system being built and can be used to analyze a system.
  • ๐ŸŽจ Attack trees can be created from scratch to help think through threats for a specific project; the process of creating includes deciding a representation, creating a root node, and subnodes, considering completeness, pruning the tree, and finally checking its presentation.
  • ๐ŸŒณ Attack trees can be presented in two forms: free-form (human-viewable) models without a technical structure, or a structured representation with variable types and/or metadata to facilitate programmatic analysis.
  • ๐Ÿงช The quality of an attack tree can be checked by iterating over the nodes, looking for additional ways to reach the goal, and mitigating duplicative or prevented actions.
  • ๐Ÿ‘๏ธ The presentation of attack trees is vital, the tree should be easy to track, and each node label should focus on active terms, and it should also be drawn on a grid.
  • ๐Ÿ’ป Several software packages can create and manage complex trees by treating the tree as a data structure, applying logic to the tree and the associated system.

Chapter 5: Attack Libraries

The text discusses the concept of attack libraries, which can be crucial in identifying threats against a system from an Attacker centric perspective.

Bibliothecae can be created in numerous ways, and understanding the potential threats can be aided by sets of attack tools.

The text also examines the properties of attack libraries, the correlation of libraries with checklists & literature reviews, and examples of structured attack pattern classification. Different libraries serve various objectives, and choosing an appropriate one involves compromises.

Finally, the challenges of using CAPEC (Common Attack Pattern Enumeration and Classification) and the usefulness of OWASP (The Open Web Application Security Project) Top Ten list are discussed.

  • ๐Ÿ“š Attack libraries can be a helpful tool in identifying threats against a system being built.
  • ๐Ÿงฐ Such libraries can be created using various attack tools, including concept code or fully developed exploit code.
  • ๐ŸŽฏ Libraries address different goals, and selection involves trade-offs such as audience target, detail vs abstraction, and scope.
  • ๐Ÿ“‹ Attack libraries can be closely tied to checklists and literature reviews.
  • ๐Ÿ“ˆ The Common Attack Pattern Enumeration and Classification (CAPEC), a highly structured set of 476 attack patterns, can be used for threat modeling.
  • ๐Ÿ‘ฅ The Open Web Application Security Project (OWASP) releases a list of top ten risks each year, which can be an excellent addition to STRIDE for web projects.
  • ๐ŸŽฉ Constructing a new library requires a significant time investment, with a lack of prescriptive advice being a potential reason for their paucity.

Chapter 6: Privacy Tools

The chapter discusses threat modeling techniques for privacy threats.

It elaborates on the challenges involved in defining privacy requirements, given the varying perspectives and subjective nature of privacy.

The chapter also explains different tools and frameworks used for finding privacy threats, such as Solove's taxonomy of privacy harms, the IETF's Privacy Considerations for Internet Protocols, Privacy Impact Assessments (PIAs), the nymity slider, as well as contextual integrity.

  • ๐Ÿ“š Threat modeling for privacy is important despite the varying perspectives and ambivalence about what defines a privacy threat.
  • ๐Ÿง  People often pay for privacy when they understand the threat and the mitigation, emphasizing the need for privacy-enhancing technologies.
  • ๐Ÿ› ๏ธ The chapter describes several tools for finding privacy threats, including Solove's taxonomy, the IETF's Privacy Considerations for Internet Protocols, PIAs, the nymity slider, contextual integrity, and the LINDDUN approach.
  • ๐Ÿ“˜ Solove's taxonomy of privacy harms offers a list of harms similar to threats that can be applied during system development to ensure privacy protection.
  • ๐ŸŒ The IETF refers to a set of security-privacy threats and pure privacy threats and provides guidelines for protocol designers to address these threats.
  • ๐Ÿ” Privacy Impact Assessments (PIAs) serve as a systematic process to evaluate potential effects on privacy, identifying issues and mitigating them.
  • ๐Ÿ“ The Nymity Slider and Privacy Ratchet measure how much information a protocol, system, or design exposes or gathers, enabling comparison with other systems for privacy-threatening aspects.
  • ๐Ÿ’ก Contextual integrity maintains that many privacy issues revolve around the appropriateness of data flows within particular social contexts.
๐Ÿง 
Food for Thought  ๐Ÿค”

the Tug war between non-repudiation and repudiation presents an intriguing paradox in the realm of cybersecurity and privacy.

๐Ÿซฒ On one hand, non-repudiation makes it more challenging for malicious parties to deny actions, reducing the risk of fraud. Many jurisdictions require non-repudiation for legal validity, especially in financial and governmental sectors.

๐Ÿซฑ On the other hand, Non-repudiation requires collecting, and storing personal information, potentially exposing users to privacy risks. 

Chapter 7: Processing & Managing Threats

This chapter discusses various aspects of threat processing and management in a project. It provides advice for handling threats faced during the inception of a project, development of features, and prior to delivery. It also shares steps for the threat modeling project and managing time effectively. It emphasizes the importance of clear-cut diagrams and bug filing. Lastly, it provides scenario-specific guidelines on trust boundaries, handling new technologies, and APIs.

Facts

  • ๐Ÿ“˜The chapter provides methods for threat processing and management.
  • ๐Ÿ’ก It describes how to start looking for threats, where and when to start, and how to iterate through a diagram.
  • ๐Ÿ’ป Advocates using the "draw a diagram and use the Elevation of Privilege game to find threats" as a functional method to start a threat modeling project.
  • ๐Ÿš€ Threat modeling should occur at the start of a project, throughout feature development, and before delivery.
  • ๐Ÿ“‘ The act of drawing trust boundaries early on can improve project architecture.
  • ๐Ÿ• The time taken for threat modeling varies based on factors such as system size, complexity, participant familiarity, and organizational meeting culture.
  • ๐Ÿ•น The chapter advises starting threat modeling top-down and then working breadth-first rather than in a detailed manner.
  • ๐Ÿง  Threat modeling also involves anticipating how an attacker might try to bypass your mitigation measures.
  • ๐Ÿ—‚ Advocates using tables and lists to manage the wealth of information threat modeling can generate.
  • โ•Discusses how to handle assuming bugs and tracking them.
  • ๐ŸŒ Covers a variety of scenarios, such as customer/vendor trust boundary issues, threat modeling new technologies, and APIs.
  • ๐ŸŽฏ Threat modeling tools and techniques should be used at the start of a project, during its progression, and near its completion.
  • ๐Ÿ“ Threat modeling begins with creating or updating a software diagram, describing the broadest aspects first and then detailing further.
  • ๐Ÿž The process ends with the identification and filing of security bugs for management within normal development procedures.
  • ๐ŸŽฑ Mitigations should anticipate potential bypass attempts by attackers, focusing on "first order" threats before considering how to mitigate attacks against the mitigations.
  • ๐ŸŽฎ Threats and mitigations are considered as a dynamic, interactive environment, similar to a game in which attackers can make moves and potentially cheat.
  • ๐Ÿ“Š Ongoing analyses during the process should keep track of discoveries, including threats, assumptions, and customer-centric information.
  • ๐Ÿค It's crucial to respect the customer/vendor security boundary, and new technologies also need to undergo threat modeling.
  • ๐Ÿ’ผ All APIs are expected to have similar threat models but unique characteristics of a new API may lead to distinctive security properties.
  • ๐Ÿ” Review the security changes of similar or competitive APIs that might be helpful for your own project.
  • ๐Ÿ•ต๏ธโ€โ™€๏ธ Employ the "rogue insider" model where needed to anticipate potential misuse of a system.

Chapter 8: Defensive Tactics and Technologies

Chapter 9: Trade-Offs When Addressing Threats

Chapter 10: Validating That Threats Are Addressed

Chapter 11: Threat Modeling Tools

Chapter 12: Requirements Cookbook

Chapter 13: Web and Cloud Threats

Chapter 14: Accounts & Identity

Chapter 15: Human Factors and Usability

Chapter 16: Threats to Cryptosystems

Chapter 17: Bringing Threat Modeling to Your Organization

Chapter 18: Experimental Approaches

Chapter 19: Architecting for Success

About the Author

Adam Shostack (Looking at the camera)

Adam Shostack is a leading expert on threat modeling, a consultant, an expert witness, an author, and a game designer.

  • He has decades of experience in delivering security, ranging from founding startups to working at Microsoft.
  • He helped create the CVE (Common Vulnerabilities and Exposures) and fixed autorun for hundreds of millions of systems.
  • He led the design and delivery of the Microsoft SDL Threat Modeling Tool and created the Elevation of Privilege threat modeling game.
  • He wrote Threat Modeling: Designing for Security and Threats: What Every Engineer Should Learn from Star Wars.
  • He co-authored The New School of Information Security.
  • He is an affiliate professor at the University of Washington and a member of the Blackhat Review Board.
  • He also serves as an advisor to various companies and academic institutions.

Resources

The Ultimate Beginnerโ€™s Guide to Threat Modeling
Threat modeling is a family of structured, repeatable processes that allows you to make rational decisions to secure applications, software, and systems.

Adam Shostack offers comprehensive courses in various depths, which are available here.

Shostack + Associates offers a variety of threat modeling courses, with options ranging from Linkedin Learning through highly customized live instruction experiences.

Join Our Community!

18+ hours of ๐Ÿ“š reading and ๐Ÿง analysis distilled in a 10-minute crisp summary every ๐Ÿ—“๏ธ month. โ€“ straight to your inbox.

Unsubscribe at any time!
Great! Check your inbox and click the link to confirm your subscription.
Error! Please enter a valid email address!