Chapter 72. Attack Models in SSDLC

Vinay Venkatesh

For a long time—at least since the start of my product security career—Secure Systems Development Lifecycle (SSDLC) has followed a four-step process:

  1. Define product security requirements at the beginning of the project.

  2. Threat model the product and identify security controls.

  3. Configure scanners to identify vulnerabilities in code as well as in open source packages it uses.

  4. Perform pen testing to confirm that the product is free of vulnerabilities or to identify and address security weaknesses before deployment.

While this process provides a lot of feedback, it is missing one key ingredient—there is no mechanism between threat modeling and code scanning to perform a security analysis of the detailed design. Some have addressed this by expanding the threat model to include component-level details. The usefulness of this approach is limited because threat modeling, by nature, is an architectural exercise where we model independent, interacting processes and data flows between them to identify security gaps. Detailed analysis involves a closer look at how the system should behave in every possible situation and for all possible inputs. I’ve found attack modeling to be a better fit here.

Attack modeling is not a new concept. It was first introduced by Bruce Schneier in his 1999 paper, “Attack Trees.”1 Since then it has been ...

Get 97 Things Every Application Security Professional Should Know now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.