Fork me on GitHub

CultureAndOrganization -> Design: Conduction of simple threat modeling on technical level

Risk and Opportunity

Risk: Technical related threats are discovered too late in the development and deployment process.
Opportunity: Threat modeling of technical features is performed during the product sprint planning.

Usefulness and Requirements of this Activitiy

Usefullness: Medium
Required knowledge: Low (one discipline)
Required time: Medium
Required resources (systems): Very Low

Additional Information

OWASP SAMM Description

Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment.

Threat modeling is a team exercise, including product owners, architects, security champions, and security testers. At this maturity level, expose teams and stakeholders to threat modeling to increase security awareness and to create a shared vision on the security of the system.

At maturity level 1, you perform threat modeling ad-hoc for high-risk applications and use simple threat checklists, such as STRIDE. Avoid lengthy workshops and overly detailed lists of low-relevant threats. Perform threat modeling iteratively to align to more iterative development paradigms. If you add new functionality to an existing application, look only into the newly added functions instead of trying to cover the entire scope. A good starting point is the existing diagrams that you annotate during discussion workshops. Always make sure to persist the outcome of a threat modeling discussion for later use.

Your most important tool to start threat modeling is a whiteboard, smartboard, or a piece of paper. Aim for security awareness, a simple process, and actionable outcomes that you agree upon with your team. Once requirements are gathered and analysis is performed, implementation specifics need to be defined. The outcome of this stage is usually a diagram outlining data flows and a general system architecture. This presents an opportunity for both threat modeling and attaching security considerations to every ticket and epic that is the outcome of this stage.


OWASP Project Integration Description

There is some great advice on threat modeling out there e.g. this article or this one.

A bite sized primer by Adam Shostack himself can be found here.

OWASP includes a short article on Threat Modeling along with a relevant Cheatsheet. Moreover, if you're following OWASP SAMM, it has a short section on Threat Assessment.

There's a few projects that can help with creating Threat Models at this stage, PyTM is one, ThreatSpec is another.

Note: A threat model can be as simple as a data flow diagram with attack vectors on every flow and asset and equivalent remediations. An example can be found below.

Threat Model

Last, if the organizations maps Features to Epics, the Security Knowledge Framework (SKF) can be used to facilitate this process by leveraging it's questionnaire function.


This practice has the side effect that it trains non-security specialists to think like attackers.

The outcomes of this stage should help lay the foundation of secure design and considerations.

Example Low Maturity Scenario:

Following vague feature requirements the design includes caching data to a local unencrypted database with a hardcoded password.

Remote data store access secrets are hardcoded in the configuration files. All communication between backend systems is plaintext.

Frontend serves data over GraphQL as a thin layer between caching system and end user.

GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to 1234:1234 for development purposes.

Source: OWASP Project Integration Project

Implementation hints:


ISO27001 2017