Culture and Org. -> Design: Conduction of simple threat modelling on technical level
Risk and Opportunity
Risk: Technical related threats are discovered too late in the development and deployment process.
Opportunity: Threat modelling of technical features is performed during the product sprint planning.
Required knowledge: Low (one discipline)
Required time: Medium
Required resources (systems): Very Low
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.
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.
Last, if the organisation 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
OWASP SAMM 1 Mapping: TA1-A
ISO27001:2017 Controls Mapping:
- not explicitly covered by ISO 27001
- may be part of risk assessment