Threat Modeling

Foreword

For the past 15 years, when I’ve talked to engineers about security in the development life cycle, they’ve asked one question again and again: “Out of everything you security professionals prescribe, what is the one most critical activity we should do?” I have been amused, frustrated, and often jaded by this question because, frankly, no one critical activity will guarantee security in the development life cycle. It is a process—and, many times, even when every part of the process is followed, the application still can be vulnerable and get exploited in production. There is no silver bullet to security done right, just as there is no perfect bug-free software.

But one activity continues to deliver tremendous value, when done right, and that is threat modeling. Threat modeling is certainly not a replacement for all the other security activities we prescribe, and it comes with some baggage over what is meant by “doing it right.” It has a reputation for being onerous, never-ending, and dependent on the security expertise of the individual or teams doing the exercise. But, let me share with you my experience of why this is a high-value activity every development team should incorporate.

When I was leading Security at EMC and we had a few years of data from having our secure software development program in place, we decided to do a deep dive into the vulnerabilities that external researchers reported to our Product Security Response Center (PSRC). The objective of this exercise ...