Practical Threat Modeling series, part 2 - The big picture

Or horribly wrong...
Creating a software system is also an act of creativity and imagination. Somehow you need to be creative in forecasting what can go wrong in the system being built. We already talked about the adversarial mindset. Adam Shostak emphasizes this approach.

Having always in mind the question "What can go wrong?" is necessary to make sense of the threat modeling in the first place. Based on experience I can say that TM quickly becomes a procedural activity in dev teams and lose the sight of the big picture. "TM is making the matrix of CIA or STRIDE on the assets", once done it, they feel relief that TM is sone and they can go on, or similar interpretations tend to lose the main point TM goal is not compliance, is making systems more secure and communicate better the risks with stakeholders. TM is understanding, better at an early stage, what can go wrong, then decide what you do about it. Put this in practice, one of the first push backs on this reasoning is "there are a billion things that can go wrong", and that's sadly true. That's why you need to ask one another question before that: "What are we building?". Sometimes called scope of boundary analysis, answering to this questions is an exercise od de-scoping as much as possible to then focus on what really matters to your portion of the bigger system. One good example of de-scoping what's you need to care about to then answer "What can go wrong?" is the shared responsibility model of AWS cloud, of course, as a user of the infrastructure, you need to care about the security "of" the systems you write "in" the AWS cloud, not the security "of" AWS Cloud itself.

from: https://aws.amazon.com/compliance/shared-responsibility-model/

The Big picture:

The 4 questions in the TM lifecycle

The four questions in the previous schema summarize the big picture to keep in mind when approaching TM so get the best value of it.