A few posts back, we begun a series on Threat Modeling. As we begun writing the second installment in this series, it occurred to me that I’m using a lot of threat modeling vocabulary. When I speak on threat modeling I always warn my audience that ambiguity exists in some of the (even fundamental or common) terms used here.

To address this concern in conversations conducted as part of the OWASP Threat Modeling project, I worked with Sammy Migues to construct a Glossary of Threat Modeling Terms. Sammy has long been a proponent of such approaches to glossaries: sticking firmly to nouns as nodes and relating those nodes with action verb edges. See figure below:

As you consider the terms and their relationships in this diagram, you may wonder about how/why we sourced what we did when defining terms. We used the following heuristics:

Favor the earliest definition known

Allow a more recent definition to update or color a previous definition, especially with respect to application security context

Do not allow a more recent definition to change direction without having been journal (or similarly peer-review) accepted

Favor software development and especially architecture sources over security sources

The definitions provided by the OWASP wiki, in particular, fail that third heuristic a fair amount, while often providing the second’s benefit.

As for “why”, perhaps it’s Sammy’s pedigree combined with my years in research and doing both magazine and journal review for IEEE. You’re instructed for better or worse, that there must be a good reason to replace an existing definition. Comparing the published result with our internal docs, source material differs considerably. A lot of our internal material on threat modeling relies on work from decades ago. ISACA material, most commonly used in the diagram above, applies more directly to a context of web-applications (remember, the glossary was done for an OWASP project) than ours, which must face a much broader assessment context. Additionally favoring existing externally available documentation, especially from an architecture context such as ISACA, serves to create a better chance for engaging those who we most want in a application security threat modeling discussion: architects, development teams, and development-centric organizations.

The biggest complaint with the glossary thus far has been with regard to its handling of “risk”. Basically, risk management remains largely out of scope of this glossary of terms, which instead chooses to focus on threat, attack surface, and vulnerability enumeration. Yes, analysis of likelihood (whatever that means) and impact are vitally important aspects of threat modeling. These two concepts, however, tend to be organization-/philosophy-specific. As such, they remain out of scope of this series of blog entries as well.

All that having been said, I meant the glossary to be a “worksheet” rather than “the 10 Commandments”. So, I think we have something to start with, improve, and evolve. Feel free to refer back to this either in your own work or as you read coming entries.

-jOHN

(*1) – If you’d like OS X or Windows “source code” to this diagram, simply email me.

Threat modeling services