Challenge of the Month:
By now, many of us are familiar with the Four-Question Framework for threat modeling. However, how it’s applied can look very different across organizations and teams—and you might even use a different framework altogether.
This month, we challenge you to describe your threat modeling process to someone who may not be as familiar with threat modeling, using no more than three sentences while including as many details as possible.
How to participate:
Reply to this post with your response.
When to enter:
Now through March 31, 2025
Recognition:
Everyone who completes this challenge will earn a Community Maven badge. Members who collect seven Community Maven badges will receive a special award!
Start with information classification, defining the scope /demarc the target of evaluation, decomposition of application and create a Data flow diagram, questioning the secure design principles against the application process, data flow, components, business use cases, etc. Rate the identified risks based on the impact, and provide cost-effective, development friendly suggestions to reduce the risks and recommend security best practices to reduce overall attack surface by applying secure by design and default to the SDLC.
Populate template with all components that team creates, owns or operates (these are in-scope), and authn/z for identities that use these components, then also add (out-of-scope) components that ingress/egress to/from the in-scope components. Populate template with business and technical assets that team cares who can read or write to, and which in-scope components they are stored in. Capture threats and any existing controls for every asset storage location, authn/z issue, or other relevant threat.
Start with an analogy, such as securing a house and its assets against a burglar that aims to steal family assets.
Then, systematically understand everything that can possibly go wrong with the house, and write up how the burglar would aim to achieve their objectives.
Lastly, use our threat model to then design defences/solutions/mitigations to stop the burglar from being able to achieve their desired outcomes.
Yes! This nails it in easy to understand terms. My team approaches it in a very similar way. Using your analogy, we would invite the Developer, homeowner, the builder, the engineers, and other interested parties who will be part of building the home to weigh in on threats and mitigations.
Threat modeling involves identifying and assessing potential security risks to a system by first understanding its architecture and identifying valuable assets, followed by pinpointing possible threats and vulnerabilities that could be exploited by adversaries. We then evaluate the potential impact and likelihood of these threats, prioritize them, and develop mitigation strategies to reduce or eliminate the risks. This proactive approach helps ensure the system’s security throughout its lifecycle.
Threat modeling is a systematic process to identify, evaluate, and mitigate security risks in a system by analyzing potential threats, vulnerabilities, and possible attack vectors. It typically follows a framework to assess security weaknesses and prioritize remediation efforts. The process involves creating data flow diagrams that define system components, identify threats, evaluate risks, and prescribe security controls at each layer to minimize potential impact.
Identify target assets (applications, systems, and components) within scope and analyze their interactions, then classify their criticality based on factors like confidentiality, integrity, availability, privacy, and safety. Identify security issues, research vulnerabilities, brainstorm potential threats for these assets, and then recommend appropriate security controls. Prioritize and implement security controls, focusing on critical assets and quick wins first, then continue until an acceptable risk posture is achieved.
Identify and Understand scope of the model, Identify and highlight threats against the model, Provide controls to highlighted threats. Test controls against discovered threats.
After the scope is determined and diagramed, identify all the common, known threats and countermeasures (input validation, etc.) using some form of automation. After that, and most importantly, identify all the threats that are specific to the solution based on the requirements, the intended architecture and design and the proposed implementation.
Understand the scope using a whiteboard exercise with the team to draw a data flow diagram.
Then start with identifying threads, this last is best for me to perform using cards such as Elevation of privilege, Linddun GO or OWASP Cornucopia, but in some cases people are not into cards and then reverting to something as Mapping Attack Patterns to your Threat Model.
After this to document all found threats and check mitigations.
Start because we “threat model every story” or because we want to investigate something, define what’s in/out of scope, gather info and draw diagrams, fill threat table inspired by STRIDE at least + more repertoire that fits, apply custom risk rating scheme and sane judgement to see what’s inaccaptable, propose different mitigations openly, choose what’s best based on protection and feasibility, review, retro.
Implement, always. ( “Es gibt nichts Gutes, es sei denn, man tut es!”)
Start because we “threat model every story” or because we want to investigate something, define what’s in/out of scope, gather info and draw diagrams, fill threat table inspired by STRIDE at least + more repertoire that fits, apply custom risk rating scheme and sane judgement to see what’s inaccaptable, propose different mitigations openly, choose what’s best based on protection and feasibility, review, retro. 
“Es gibt nichts Gutes, es sei denn, man tut es!”)
Love to read all the things…)