The Open Threat Model (OTM) standard is a generic and tool agnostic way of describing a threat model in a simple to use and understand format. It has been designed to allow greater connectivity and interoperability between threat modeling and other parts of the Software Development Lifecycle (SDLC) and cybersecurity ecosystem. Released under Create Commons, anyone can contribute or use the standard.
Threat modeling as a practice is evolving, and so must the technology that surrounds the practice. If you look at what happened with DevOps, the key to scaling the creation and management of infrastructure was a combination of culture changes as well as the commoditisation of infrastructure such as through cloud and Infrastructure as Code (IaC). Threat modeling will inevitably go through a similar shift, and this standard has been to facilitate that evolution. By leveraging existing design artefacts such as IaC, we can automate the threat modeling process, increasing the scalability and maturity of threat modeling as a result.
Key use cases for an open threat modeling standard include:
- Easily supporting new sources of application and system design. Anyone can write and share parsers or other tools that take source formats such as CloudFormation, Visio, or Docker Compose files.
- Exchange threat model data within the SDLC and cyber security ecosystem. Having threat models represented in a common format means being able to use that data through integrations.
- Exchange between organisations. It would be a great outcome if open source projects or even commercial vendors were sharing threat models of their systems in a way that could be ingested and used by organisations adopting those systems.
In this article we’re going to take a close look at the specification and how IriusRisk implements and uses it to automatically create threat models from CloudFormation templates. For the full specification see the Open Threat Model project repository. To learn how to create a simple parser that generates OTM see How to create an OTM parser.
An overview of the OTM specification
It makes sense to start by looking at some key elements and features of the specification. The specification is written as YAML (or JSON) and is broken up into a number of high level objects:
- otmVersion - The version of the specification used in the file
- Project metadata - Name, identifier, description, owner of the thing you’re threat modeling
- Representations - E.g. diagram, code, JIRA story, user interface
- Assets - Things you care about, sensitive information. E.g. PCI or PII data
- Components - Bits that make up the representation such as an EC2 instance or an API
- Trustzones - The differing levels of security and trust. Internet vs Web vs App vs Data tier
- Dataflows - How information and assets move around between components
- Threats - The bad stuff, the things that can go wrong
- Mitigations - The good stuff, probably requires you to do some work
There are few other interesting things to note about the specification:
- Objects can have arbitrary “attributes”, use them however you like. E.g. custom IDs
- It provides basic properties to capture essential risk information (CIA triad, trustzone ratings, CWEs, likelihood and impact)
- Tags to help you classify or group different components etc.
- X and Y positions can be provided for diagrammatic representations
- Components and Trustzones can be arbitrarily nested
Project
The project object contains metadata about the thing being threat modelled. The name and id fields are required, but other useful fields include a description, owner, and owner contact. You can use the attributes field to link your project to documentation hosted elsewhere or to the relevant asset in something like a CMDB.
project:
name: Test project
id: test-project
description: This is a test project for the OTM development
owner: John Doe
ownerContact: john.doe@example.com
attributes:
documentation: “http://mydocs/my-app-123”
cmdbId: MyApp123
Representations
Any given system can be threat modeled in a number of different ways, and from a number of different perspectives. For example, you can threat model as system based on the cloud infrastructure, or you can threat model the functional elements of the application itself such as login, shopping cart, user comments etc. The OTM specification refers to these different perspectives as representations, and an OTM file can include one or more representations. An architecture diagram representation may have diagrammatic elements such as width and height, where as a code-based representation may have a source code repository and file line numbers.
Here we can see an example of an architecture diagram representation.
representations:
- name: Architecture Diagram
id: architecture-diagram
description: This is a diagram of the project's architecture
type: diagram
size:
width: 1000
height: 1000
attributes:
platform: drawio
unit: pixel
...This is what a code representation might look like.
...
- name: Application Code
id: application-code
type: code
repository:
url: https://github.com/my-project
attributes:
language: java
platform: github
vcs: git
Because an OTM file can include multiple representations, that means you can include the full threat model of a given application or system, from each of the different perspectives.
Trustzones
Trustzones are a core part of any threat model. They provide key context about how components within a threat model are expected to behave and where threats are going to have the biggest impact. If you’ve got a completely untrusted zone such as the Internet connected directly to a highly trusted zone such as a data tier, you may find that a simple configuration error could easily expose the sensitive data to the world. The OTM specification uses a trustRating property to describe the expected level of trust and security of the trustzones.
trustZones:
- name: Internet
id: internet
description: This is the internet trust zone
risk:
trustRating: 20
representations:
representation: architecture-diagram
id: internet-box-shapeComponents
Components are the building blocks of a threat model. They can include the architectural elements within system such as web servers, data bases, and firewalls. They can also include the functional elements with in a system such as the login page, a shopping cart, or an email sender.
Each component has a human readable name field, but also a type field. This type field helps to describe what type of object it is. For example, in a threat model you could have two different web services Web1 and Web2, both of the same web-service type. While they are different entities in the threat model itself, because they are the same type, we can expect similar threats and controls to apply to them.
Components also have a parent field. Typically this will be a trustzone, but a component can also be nested inside another component. For example, you may have a Rest API component inside an AWS EC2 instance component.
Tags are especially useful for components because they allow you to provide additional values that further describe the components in an arbitrary way. This can be useful for group or filtering.
components:
- name: Web Service
id: web-service
type: web-service
description: Runs our web application
parent:
trustZone: private
tags:
- tomcatDataflows
Finally we’ll look at dataflows. These are the literal flows of data between components within a threat model. They can be network-level flows such as HTTP or DNS, or they can be higher level flows such as “user login” or “product search”. Of course, a data flow needs a source and a destination component. It can be unidirectional or bidirectional. And similar to components, tags can be used to provide additional context useful for grouping and filtering.
dataflows:
- name: Dataflow between webservice and mongo
id: cc-store-in-db
description: Credit card information being exchanged in between the web app and the database
bidirectional: true
source: web-service
destination: customer-database
tags:
- http
- https
Using OTM with IriusRisk
IriusRisk has released an OTM API in version 4.1 of the product. This API allows you to provide an OTM file and IriusRisk will automatically build a full threat model using the rules engine an extensive library of components and risk patterns. The first release of the API supports trustzones, components, and dataflows. Threats and mitigations are already in the specification, and support for them in IriusRisk will be coming soon.
The rest of this article will focus on building a threat model in IriusRisk using OTM. We’ll start off with a simple HelloWorld OTM file created by hand in an IDE, and then we’ll build one from a CloudFormation template using the open source Startleft tool. For both of these examples, we’ll need to set a couple of environment variables used to connect with the API:
$ env | grep IRIUS
IRIUS_API_TOKEN=abc-123
IRIUS_SERVER=https://dev.iriusrisk.com
HelloWorld
Here’s a very simple OTM file created by hand in an IDE. Yes, it’s that easy.
otmVersion: 0.1.0
project:
id: helloworld
name: Hello World
trustZones:
- name: Public
id: 6376d53e-6461-412b-8e04-7b3fe2b397de
risk:
trustRating: 10
- name: Private Secured
id: 2ab4effa-40b7-4cd2-ba81-8247d29a6f2d
risk:
trustRating: 90
components:
- name: Client
id: client
type: generic-client
parent:
trustZone: 6376d53e-6461-412b-8e04-7b3fe2b397de
- name: REST Service
id: rest-service
type: rest-full-web-service
parent:
trustZone: 2ab4effa-40b7-4cd2-ba81-8247d29a6f2d
dataflows:
- name: Client to REST service
id: client-to-rest
source: client
destination: rest-service
tags:
- HTTPS
It has two trustzones, two components, and a dataflow. This file can be sent straight to the IriusRisk OTM API using a simple curl command:
curl -XPOST -H "api-token: $IRIUS_API_TOKEN" -F 'otmFile=@helloworld.otm' 'https://dev.iriusrisk.com/api/v1/products/otm'
{ "ref":"helloworld",
"name":"Hello World",
"revision":"1",
"type":"STANDARD",
"status":"OPEN",
"priority":"0",
"tags":null,
"workflowState":"wsa",
"udts":[],
"groups":null,
"users":null
}
Here is the threat model created by IriusRisk:
As you can see, because the rules engine has executed, it has automatically pulled in threats and countermeasures that would apply to this threat model:
CloudFormation
Now let’s build a more complete threat model from a CloudFormation template. We will use the open source Startleft tool to parse the CloudFormation template into an OTM file, then we’ll upload that OTM file to the IriusRisk API. Finally we’ll look at the threat model created by IriusRisk as a result.
This code snippet shows a section of the CloudFormation template we’ll be using. As you can see, the file uses Amazon's Elastic Container Service as well as a number of other resources such as CloudWatch alarms.
service:
Type: 'AWS::ECS::Service'
DependsOn: ALBListener
Properties:
Cluster:
Ref: ECSCluster
DesiredCount: '1'
NetworkConfiguration:
AwsvpcConfiguration:
Subnets:
- Ref: PrivateSubnet
SecurityGroups:
- Ref: EcsSecurityGroup
LoadBalancers:
- ContainerName: simple-app
ContainerPort: '80'
TargetGroupArn:
Ref: ECSTG
Role:
Ref: ECSServiceRole
TaskDefinition:
Ref: taskdefinitionUsing the Startleft project we can parse it into OTM with a single command.
$ startleft parse --type CloudFormation --map default-cloudformation-mapping.yaml --name "ECS Example" --id ecs-example --otm ecs-otm.yaml ecs.yaml
Writing threat model to 'ecs-otm.yaml'The mapping file provided describes how to find resources in a CloudFormation Template, and how to map them into an OTM threat model. This gives us an OTM file which look something like:
{
"otmVersion": "0.1.0",
"project": {
"name": "ECS Example",
"id": "ecs-example"
},
...
"components": [
{
"id": "1926dedc-c0e8-4539-b304-4fa359d9eeb9",
"name": "service",
"type": "elastic-container-service",
"parent": {
"component": "36f7c768-b05d-48b8-880f-da9bdaf41258"
},
"tags": [
"AWS::ECS::Service"
]
},
{
"id": "4ec0399f-8594-4bb3-9ee8-965153c07d33",
"name": "taskdefinition",
"type": "docker-container",
"parent": {
"component": "1926dedc-c0e8-4539-b304-4fa359d9eeb9"
},
"tags": [
"AWS::ECS::TaskDefinition"
]
},
We can now upload this OTM to IriusRisk using Startleft.
$ startleft threatmodel ecs-otm.yaml
Uploading OTM files and generating the IriusRisk threat model
Validating OTM file
OTM file is valid
OTM file has consistent IDsLogging in to IriusRisk we can see it has built a full threat model. This isn’t just a visualisation of all of the resources in a CloudFormation template. What we can see here is an architectural view of the cloud infrastructure.
Conclusion
The Open Threat Model standard gives us a flexible way to describe threat models which can be used throughout the SDLC and cybersecurity ecosystem. It’s simple enough to be able to create threat models by hand, and powerful enough to represent full threat models generated from Infrastructure as Code.
