Applying STRIDE Methodology to Threat Model a New Component
Applying STRIDE Methodology to Threat Model a New Component
IriusRisk approaches threat modeling, by following the threat modeling manifesto and answering Shostacks' 4 question framework.
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
What we are working on is answered by creating an architectural diagram, with a commonly used diagramming tool, draw.io, embedded, users can quickly and easily represent the system or service that they are working on.
But with all the will in the world, not every component or combination of components can be pre-defined, and how do we deal with components that are bespoke to our system? What about developing application software and creating new features and functions that bring our business value to our customers?
Risk patterns need to be defined, we need to threat model these “new things” and the most common approach to threat modeling is to use the STRIDE methodology. In 2022 IriusRisk published an article, along with an example library to help. This provides an out of the box capability to categorize the type of threats that may affect a particular component within an architectural diagram.
- Spoofing
- Tampering
- Repudiation
- Information disclosure (privacy breach or data leak)
- Denial of service
- Elevation of privilege
The STRIDE Categories are mapped to particular CAPEC threats, which in turn lead you to define your own countermeasures/controls (or reuse those defined within the other IriusRisk libraries) to mitigate each threat.
So, how best to leverage the STRIDE CAPEC mapping library. The library is implemented with a series of Risk Patterns and Use Cases to group threats. In this case we use the STRIDE categories as both Risk Pattern and Use Case. This then provides a reference to the CAPEC threat, which in turn is mapped to one or more weaknesses (CWE).
Mitigations (in IriusRisk, countermeasures) need to be added based on each individual use case in the context of the system that you are working on. But you can add your own countermeasures or re-use existing countermeasures from other IriusRisk libraries.
So, how do we use this? The content is exposed to the end user via a component questionnaire.
Questionnaires in IriusRisk are implemented through a series of rules; and in this case the primary rule which defines where the questionnaire is used, is named stride.
By default this rule has no condition, and therefore applies to all components. This may not be desirable, as most of the components within the IriusRisk platform come with one or more pre-defined risk pattern.
And as we are interested in Threat Modelling new components within our system, then we need to associate the questionnaire with relevant components, out of the box IriusRisk has the General Category, which includes the components, Binary File, Empty and the Out of Scope components.
The empty component would be an ideal candidate to represent new components within the architectural diagram. Alternatively you could create your own component, or define a series of components within a category, describing content across a broad range of component types.
Using a category would allow the questionnaire to be targeted against one or more component.
In order to target the STRIDE questionnaire against the component or series of components that we want to use to represent components not available within IriusRisk is a matter of simply adjusting the condition for the primary rule, stride.
In this example we use the custom component, Empty Function.
When we deploy that component within a diagram, the questionnaire is rendered, and we can explore the threats that CAPEC identifies based on the STRIDE categories.
