The goal of a threat modeling activity is to identify and rate threats (potential weaknesses or vulnerabilities) in IT systems including of course web or mobile applications and services to derive suitable countermeasures very early in the development process. Some advantages of this assessment technique are:
- Early identification of threats and countermeasures (within design or requirements phase)
- Very good cost-benifit ratio
- Can reduce pentest findings
- Active participation (and high acceptance) of dev teams
- Updating by dev teams possible
- Works good with agile development
- Works good with agile development (please have a look at our latest blog post on agile thrat modeling).
In contrast, classic pentest approaches have a much more limited scope and are only executable late in the development process. Threat modeling is, however, not a replacement for pentests but should be seen as an additional assessment, especially valuable for critical applications.
Therefore, threat assessment has now become a separate business function in the new version of OWASP SAMM.
The following steps outline our usual approach:
Before a threat assessment can start, a few preparations are necessary:
- Definition of scope and applied assessment techniques
- Planing of workshop
- Evaluation of existing documentation (optional)
Usually, a very limited preparation effort is required.
The next step is usually a workshop with relevant stakeholders (developers, architects, product owner) in which the application is firstly explained from a technical and business point of view and then relevant data flows, trust boundaries, and existing security controls (e.g. authentication, authorization, cryptography) are identified and discussed at a whiteboard, whereby the focus always lays on sensitive data and how it is accessed by whom.
One result of this activity is usually a diagram outlining the security-relevant data flows of the applications which may look like the following after it has been reconstructed with a diagram tool:
This diagram will then be extended by relevant security controls and threats.
3. Threat Identification
In the next step, processes and data flows will be analyzed for potential security problems – e.g. by using the STRIDE methodology to assess data flows or other methodologies such as Abuse Cases to assess business logic.
As a result, threats will be rated, in respect of their criticality or risk.
4. Identication of Coutermeasures
Lastly, countermeasures for relevant threats will be identified and defined (e.g. as JIRA tickets).
The threat model may from now on be updated by the dev team, e.g. in case of security-relevant changes such as architectural ones.
Integration of threat modeling activities into the software development usually requires a set of rules and a threat catalog (threat intelligence) that can be improved with every threat modeling activity conducted. One great possibility for this is the use of Wikis such as Atlassian Confluence which allows you to set up different kinds of individual threat modeling templates and threats.
Besides the implementation of threat intelligence, we can also help you to select and customize threat modeling tools that are suitable for different roles.