Practical Threat Modeling series, part 3 - Taxonomies and frameworks

Keeping in mind the big picture of the Threat Modeling flow, there are obviously many ways to identify the vulnerabilities a specific design may presents.

Among them:

•  Attack Trees, 
• PASTA, 
• STRIDE
• CIA
• ... and others

Considering the "practical" nature of this article series I'm going to focus on those more (de facto) standard methodologies: STRIDE and CIA. Having a taxonomy helps to consider a wider and more complete range of potential threats. Not basing a TM on a taxonomy lead to a higher probability of "missing" something when conducting the TM (we'll that considering ONLY the taxonomy, limiting lateral thinking will lead to potentially "missing" something else).

Personally, I prefer STRIDE over CIA taxonomy as it helps to find more potential vulnerabilities. For people approaching for the first time TM, although, CIA results in an easier understanding of the main concepts, and hot to map assets (and dataflows) to threats. So when I'm training teams, or in general, when I'm introducing TM methodologies for the first time, depending on the level of understanding and experience, it may be advisable to iterate over the simpler, positive, CIA: we want for every asset and interaction in the system to maintain Confidentiality of sensitive data, Integrity of the data, and availability; easy. Of course, separate authorization issue from authentication ones, consider repudiation (non-repudiation) issues and so on is a more complete exercise. It is also possible to link the two main taxonomies and use both as a learning path.

From: http://download.microsoft.com/download/9/3/5/935520EC-D9E2-413E-BEA7-0B865A79B18C/Introduction_to_Threat_Modeling.ppsx

Also a "corrected" version:

From: https://github.com/geoffrey-hill-tutamantic/rapid-threat-model-prototyping-docs/blob/master/18q08.aug.Rapid%20Threat%20Model%20Prototyping.pptx

My personal view for the "property we want" for Repudiation threat is "accountability". And, always for the repudiation threat, among the questions, are: Are we logging enough? Are we avoiding log injection (probably not!)? Are we lacking in authentication? think about how little accountable people are when booking a table at a restaurant by phone. In transaction and payment system integration with federates identities (OAuth systems), this is a huge design-level topic.

In the next posts, we are going to explore how to apply those taxonomies to "in-scope" asset and dataflows.