Threat Modeling as Code
If you know what threat modeling is and have read the threat modeling manifesto, this article will be your next step. Otherwise, I strongly recommend you to read my first article where I explained some of the values and principles of the threat modeling manifesto and their alignment with our IKEA values.
Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.
According to the previous definition, threat modeling is adapting our products to the real world from a security and privacy perspective. However, this up-to-date approach can be a daunting task for security engineers due to the current state of their threat modeling tools.
According to the 0-day tracking project, at least 66 zero-days have been found in use in this year, almost double the total for 2020, and more than in any other year on record. For that reason, providing a new threat modeling approach is more important than ever.
Stop drawing, Start coding
For a while now, security engineers have been using drawing tools like draw.io or similar ones to conduct threat modeling. However, the usage of these static tools has some implications to have into account:
Styling is one of the rocks in this journey. As you can imagine, the variety of threat modelings can be exponentially growing in big companies due to the wide range of products, systems, and business needs. Even with strong design guidelines, it is a hard task to maintain and reduces the options from product teams to start their own threat modeling diagrams.
In order to create this baseline for all products, our approach is based on C4 model that uses a really simple notation based on old-school UML (Unified Modeling Language) and four abstractions levels (system context, containers, components, and code) to reflect the behavior of the product.
Tooling is the next step to fall to the ground this new diagram model and C4 has a wide range of tools to support it. In our case, we will use a PlantUML extension in Visual Studio Code. Prior to installing the extension, we will need to have the following installed:
Once installed the extension, we can start coding our threat modeling and previewing in Visual Studio Code with Option + D (Alt + D)
In this example, we have used C4 Container level with the following entities:
- Person: Developers, end-users or attackers.
- System: External platforms.
- System Boundary: Cloud environments.
- Container: Our backend/frontend application.
- ContainerDb: Databases.
Now, we can start pushing our code into our preferred SCM like Github or Gitlab, define a proper code reviewing and branch strategy between product teams and security engineers. At IKEA, it was a step to start empowering cross-collaboration between teams and bringing autonomy to product teams.
Threat modeling and beyond
Another benefit of adopting threat modeling as code is its extensibility. For example, we can use STRIDE for classic threat modeling, LINDDUN for privacy-based threat modeling, or even combine both for a global perspective.
By using this approach, we are extending trust boundaries from classic threat modeling to any type of system representation. However, we are not providing a clear way to represent the trust and value for each component in the model so we need to create one, trust:value ratio. Before defining both concepts, I would want to reference this approach to Daniel Spilsbury. Thanks again for your time and patience :)
Trust is a scoring schema for confidence, integrity, and availability from 1 to 5 but the lower and upper bounds can be defined by you. For example, a perimeter might be 1, DMZ maybe a 3, and a backend service a 5.
Value represents a way to determine how sensitive data is in terms of storing, forwarding, and processing. The bounds of your scoring schema should be the same as that in the trust ratio.
Now, we can quickly identify and prioritize anomalies with high-value assets in low-trust environments.
What’s next…
Congratulations! We have reached a 1.0 version of our threat modeling as code approach. According to some reference articles, threat modeling from code uses DSL (domain-specific languages) to identify threats and risks in a product. However, we should iterate into a threat modeling with code to interpret and process information to identify threats and risks and automate them into our CICD pipeline. As the threat modeling manifesto states, this is a journey of understanding (and continuous learning) over snapshots.
Our next version will focus on removing some integration barriers from DSL and implementing pipeline automation through individual policies, particularly important in big companies. Once again, stay tuned!
