Threat modelling a data flow with STRIDE

A threat model starts with a drawing: the people and systems, the data that flows between them, and the boundaries the data crosses. This post draws ACME's data flow in OWASP Threat Dragon, a free threat modelling tool, and then goes through the elements and flows one at a time with STRIDE. The result is a list of threats with a control for each, which developers, testers and auditors all work from.

· By Marius-Florin Cristian

Part 1 of the series Building a security program for a growing company: Introduction.
  1. Leading security at two startups in a row, both acquired about two years after I joined
  2. ACME, the company this series follows
  3. One set of security records for customers, auditors and regulators
  4. Proactive, application and detective security in a growing company

The story on why it is important: Proactive, application and detective security in a growing company.

ACME at its third stage: a Django dashboard in an EU cloud account, a Go gateway inside customers' buildings, and GitHub Actions building and deploying both.

The tool

The work is drawing boxes and arrows, then thinking about each one in turn. Any tool that draws them will do, including a whiteboard. OWASP Threat Dragon is a good fit for a small team: it is free, it runs as a desktop application or in the browser, and it has the shapes a threat model needs, with a list of threats attached to each element. It saves the model as a JSON file, which ACME keeps in the repository next to the code, so a change to the model is reviewed like any other change. The report it prints is what testers and auditors receive.

Drawing ACME's model

The drawing has five kinds of shape, and ACME's model uses all of them:

  1. actors, the people and systems outside the team's control: the business user, the developer and the meters;
  2. processes, the code ACME runs: the dashboard API, the gateway and the build pipeline;
  3. stores, where data rests: Postgres, the repository and the container registry;
  4. data flows, the arrows, each labelled with the data it carries;
  5. trust boundaries, the dashed boxes around ACME's cloud account, GitHub, the developer laptops and the customer's building.
ACME data flow at stage 3, grouped by owner Three parts. Delivery inside ACME: a developer sends code to the GitHub repository, the build pipeline turns reviewed commits into images in the container registry, and they are deployed to the dashboard API in ACME's EU cloud account, which keeps readings and accounts in Postgres. Ingestion from the customer building: the gateway reads the meters over Modbus and sends readings over mutual TLS to the dashboard API. Use over the public internet: business users sign in, read and export, and the dashboard sends alerts to an email supplier. Each dashed box is a trust boundary. Public internet ACME Developer laptops GitHub (supplier) Cloud account (EU) Other suppliers Customer building code reviewed commits images deploy readings, accounts sign-in, readings, exports alerts Modbus readings over mutual TLS Business user Developer Repository Build pipeline Container registry Dashboard API (public endpoint) Postgres Email service Meters Gateway
ACME's model at its third stage. In Threat Dragon the same model uses the tool's own shapes, and every arrow that crosses a dashed box gets the questions below. Open the diagram full size

STRIDE, element by element

STRIDE is a list of six questions to ask about the elements and flows of a model, one for each kind of threat:

Spoofing
Can someone pretend to be the sender, the receiver or a user?
Tampering
Can data or code be changed without permission?
Repudiation
Could someone deny an action because nothing records it?
Information disclosure
Can the data reach someone who should not see it?
Denial of service
Can the flow be stopped or flooded?
Elevation of privilege
Can someone gain rights they should not have?

Not every question applies to every element, and a threat that does not apply is left out. The boxes below are ACME's model, one per element or flow, with the boundary it crosses, the data it carries, and each threat with the control that answers it.

Business user to dashboard API

Boundary: the public internet into ACME's cloud account · Data: passwords and sessions, site readings, exports
  • S
    Spoofing. A stolen password is used to sign in. Control: multi-factor sign-in, and an alert on sign-ins from new countries.
  • T
    Tampering. A request is changed on its way. Control: TLS on every connection.
  • R
    Repudiation. A user denies having exported the data. Control: an audit log entry for every export, with the user and the time.
  • I
    Information disclosure. One customer reads another customer's sites. Control: a check on every request that the site belongs to the user's customer, tested in CI.
  • D
    Denial of service. A flood of requests takes the dashboard down. Control: rate limits, and the cloud provider's protection against floods.
  • E
    Elevation of privilege. A normal user reaches the administrator functions. Control: separate administrator roles, checked on the server for every request.

Gateway to dashboard API

Boundary: the customer's building into ACME's cloud account · Data: meter readings, the gateway's identity
  • S
    Spoofing. A copied gateway key sends false readings. Control: one certificate per gateway, which ACME can revoke.
  • T
    Tampering. Readings are changed in transit. Control: mutual TLS between the gateway and the API.
  • R
    Repudiation. A site disputes its readings. Control: every reading is stored with the gateway's identity and the time.
  • I
    Information disclosure. Readings are read on the way. Control: the same mutual TLS.
  • D
    Denial of service. A broken gateway floods the API. Control: a rate limit per gateway.
  • E
    Elevation of privilege. A gateway calls endpoints meant for users. Control: gateway certificates are accepted on the ingestion endpoint only.

Meters to gateway

Boundary: inside the customer's building network · Data: raw readings over Modbus
  • S
    Spoofing. A device on the building network pretends to be a meter. Control: the gateway reads only the meter addresses it was configured with, and reports new devices.
  • T
    Tampering. Anyone on the building network can change a reading, because Modbus has no authentication. Control: the gateway flags impossible jumps, and the customer separates the meter network from the office network, a duty ACME writes into the installation guide.
  • D
    Denial of service. The network is flooded and readings stop. Control: the gateway buffers readings and sends them when the network is back.

Developer to repository, pipeline and registry

Boundary: ACME's laptops into GitHub, then into ACME's cloud account · Data: code, build secrets, container images
  • S
    Spoofing. A stolen developer token pushes code. Control: sign-in through the company identity provider with multi-factor sign-in, and short-lived tokens.
  • T
    Tampering. A change that nobody reviewed reaches the main branch, or an image the pipeline did not build gets deployed. Control: branch protection with a required review, and signed images checked before deployment (chapter 2.8).
  • R
    Repudiation. Nobody can say who approved a release. Control: the approvals are kept with each build's evidence (the engineering companion to chapter 1.3).
  • I
    Information disclosure. Secrets leak in the code or the build logs. Control: secret scanning on every change (chapter 2.3).
  • E
    Elevation of privilege. Text from a pull request runs as a command in the pipeline. Control: workflow inputs pass through environment variables, never straight into a script (chapter 2.2).

Dashboard API to Postgres

Boundary: inside ACME's cloud account · Data: readings, accounts, invoices
  • T
    Tampering. SQL injection changes or deletes data. Control: parameterised queries everywhere (chapter 2.4).
  • I
    Information disclosure. A copy of the database or a backup leaks. Control: encryption at rest, with the keys in the cloud key vault.
  • E
    Elevation of privilege. The application's database user can drop tables. Control: a database user with only the rights the application needs.

Dashboard API to the email service

Boundary: ACME's cloud account into a supplier · Data: alert texts with site names
  • I
    Information disclosure. The supplier stores customer site names. Control: alerts carry no personal data, and a data processing agreement covers the rest (chapter 3.6).

Keeping it current

ACME updates the model on the same weekly rhythm as the rest of its work. On Monday, when the week's tasks go out, the team checks whether a task adds an element, a flow or a boundary, and adds its threats to the model. On Friday, when the tasks are done, the security lead checks that the controls were built and marks the threats as mitigated. At Omnio I kept our Threat Dragon model on exactly this rhythm.

Use by testers and auditors

Penetration testers take their scope from the model. Each arrow that crosses a boundary is a place to test, and the threats show which attack chains to try first (chapter 4.4). Auditors use it as the starting point of the risk assessment (chapter 3.2). New engineers read it on their first day to see where the data goes.

Cost

These are estimates. They depend on the team, the size of the system and how it runs.

First model
Half a day to a day for someone who knows the systems, for the drawing and the first pass through STRIDE.
Each week
About thirty minutes on Monday and Friday together.
Money
None for the tool. Threat Dragon is free.

Keeping the model current also takes attention away from product work, and that cost does not show in the hours.

Limits

STRIDE prompts the questions, and the answers come from the people who know the system. The model shows where data goes and leaves out the order of events, which a sequence diagram shows for a protocol. Threats from insiders, from the physical world and from suppliers' own systems need the chapters on people, physical security and suppliers as well.

Previous: Producing audit evidence from the build pipeline TBA All chapters Next: A first CI pipeline for a small team TBA