.webp)
IriusRisk Functional Components
Not all threat models are built the same way
If you try to explore some reference threat models from the Internet across different scopes to better understand the problem space, you'll find several alternatives. Some of them try to provide a holistic view of the system and include threats and mitigations from different angles, for example: operations, networking, compliance, privacy, development and so on. Others try to focus on only one of the above mentioned aspects and give a greater level of granularity. You can also choose to base your threat modeling activities on attackers, on assets or on technology.
There are no good or bad threat models, only useful or not depending on your definition of done for your threat modeling process.
To make threat modeling more developer-friendly, we've learned that it's often better to focus on technical threats rather than broad ones. Developers have the best understanding of their technical work, so we've designed IriusRisk to provide a wide range of architectural components. These components serve as the fundamental building blocks of the system's architecture, such as web services, databases, or file systems. We organize threats to these components based on the underlying technology stack and relevant configurations that can impact their security.
While this forms a strong foundation, it's important to remember that applications are more than just their architecture. Many aspects are still relevant to threat modeling, especially as technology evolves. For instance, emerging technologies like serverless have minimal application architecture from a developer's perspective.
As systems evolve, new user stories will bring in fresh software features to the application's backlog, and not all of them will need alterations to the underlying architecture. This is where functional components can prove to be quite useful.
What are functional components and where can you find them?
To enhance the developer experience during the iterative threat modeling process, we've introduced a new developer-oriented library within IriusRisk. This library features a catalog of native functional components. Functional components in IriusRisk are essentially containers that group threats associated with a particular function of a system or application. One of our primary objectives with this approach is to empower developers to concentrate their threat discovery efforts on the functions tied to the specific user stories they need to implement.
We have 51 functional components as per IriusRisk version 4.21 (October 2023). All of these functional components are stored under the Functional - IriusRisk section of the diagram components:
Functional components category inside the IriusRisk's diagram view
How To Use Functional Components
To make use of these new components, all you need to do is position the Functions within a Trust Zone. Keep in mind that the Trust Zone is a critical aspect of the diagramming process since everything has a designated location.
Some example functional components available in IriusRisk
The essential aspect for deriving value from these components lies in context. We establish this context by responding to the component questionnaires. If you want to know more about how component questionnaires work for functional components, you can take a look at the following support article:
Below, you can find a set of example user stories that could be modeled using the functional components:
Specific application example
Let's consider a simple Java web application as an example to further delve in the implementation details. This is a summarized layout of the architecture:
Java web application example
We have a three-tier architecture deployed in an AWS cloud environment. We can use at least two different approaches to threat model this web application.
The divide and conquer way
In this approach, we use a project component to encapsulate the application's business logic. This project component with the functional aspects will be seen as a nested component of the Apache Tomcat servlet container.
Project component settings
This way we can better split responsibilities during the threat model progress:
- Security and DevOps teams will take care of the architectural threats.
- Developers can take ownership of the project component and focus on the security implications of the features they are working on.
Project component (Web application features) as part of the overall architecture
Imagining that the development team is working in a new registration workflow for users. Some of the relevant functional components that may be handy in this case can be seen in the following figure:
Functional components included in the Project component diagram view
With this approach development teams can focus their efforts on the risk associated with the new business functions they are working for this sprint. Having the functional side on a separate threat model allows developers to invest their limited resources in the threats that they are able to mitigate.
Using functional components is also an opportunity to go beyond just the technology in the threat modeling process. This is a crucial aspect, because failing to involve all of the business’s key stakeholders leads teams to incorrectly assess the business impact of each of the detected threats.
Project component as a nested component in the threats view for the global architecture
Project component threats (functional threats for the web application)
Project component countermeasures
The unified way
If DevOps, architecture, security and development teams want to collaborate in a single threat model, they can also do it. This approach works better when you really have DevSecOps teams that can work as a whole.
Diagram view for the unified architecture including functional components
Threats view for the global architecture
Conclusion
We've explored two approaches to threat modeling a three-tier web application in IriusRisk using functional components. In the first approach, business logic threats within the developer domain are compartmentalized using a project component, creating a separate threat model. The second approach integrates architectural and functional components into a single threat model, offering a unified perspective. While there is no one-size-fits-all solution, it's crucial to customize threat models according to the project's specific requirements. Additionally, it's essential to stay mindful of emerging technologies and evolving functional components as applications progress.
References
- A Guide to Threat Modelling for Developers
- Threat Modeling Software Features vs Architecture
- Functional Components - What They Are and How To Use Them – IriusRisk Support
- IriusRisk | Functional Components
