Practical Threat Modeling series, part 1 - Introduction

Adversarial mindset is key to design and to implement more secure software and systems in general. Of course, is not the only requirement to achieve better security. Experience and traversal technical knowledge is key too. The question is also: how to ensure we applied an adversarial mindset in software design and creation? and: How can we assess that that reasoning was complete or at least enough? Threat Modeling is a practice that tries to address those questions: providing both frameworks and methodologies.
Hoping in the competence of single engineers is not enough. Complex systems don't fit in the head on any one single individual. Having the best individuals, also with an adversarial mindset and cyber security knowledge/experience is a rarity and, even in that case, you need a defined practice to guide the activity of Threat Modeling.
We're not in the early 2000s and we are lucky enough to "stand on the shoulders" of great individuals that developed several ways of doing Threat Modeling. Few of those methodologies "survived", are proven to have good efficiency for the effort applies (80/20 concept) and became de-facto standards. On the other hand, there is still room, a lot of it,  for improvements and customizations. Adam Shostack and others at Microsoft started this journey, I use those methodologies and personally agree with the big picture.
Threat modeling is central when adopting a Secure Development Lifecycle (SDL)  but is also usually a completely new activity for developers teams. To make it works (I mean: to have more secure software out of this and not mere process compliance) many practical, down to hearth aspects of the practice need to be taken into account, among them:

1) Having a good plan

Progressive, maturity based, measurable programme of SDL practices.

2) Gaining acceptance from dev teams

Train them properly: define a good technique framework
Show the value
Mentor and work together with them

3) Managing outcomes and communication

Don't let your TM be stored in some random page inside your intranet, make it an everyday tool, reference documentation, useful!
It can (should!) be shared with key stakeholders, including customers, to agree on boundaries of responsibility and residual risks.

In a series of posts, I want to cover crucial practical aspects, including:

• The basics: 4 questions of Threat Modeling 
• Methodologies: Taxonomy based frameworks, CIA vs STRIDE and how not to be "limited" by a methodology
• Key points: level of abstraction: Design vs reduced scope/in-sprint TM 
• To do and don'ts
• Follow the data: advantages ad Data Flow Definitions analysis
• Tools, the Rapid TM methodology and Tool-assisted Thread Modeling from Geoffrey Hill: Tutamantic

So, see you soon...