Threat modelling: architecture, attack scenarios and controls

Product version and deployment

A threat model applies to a particular product version and deployment. An internet-connected gateway and the same gateway on an isolated maintenance network may have different entry points and operating assumptions.

Invite the people who know the architecture, development, product use and security. Before the session, collect enough material to explain a normal operation from beginning to end.

• The release, supported deployment and intended users.
• The architecture, external interfaces and data exchanged.
• The privileges of each user, service and local process.
• The sensitive data, credentials and product functions to protect.
• The existing controls and any assumptions that still need confirmation.

Data flows and trust boundaries

A data flow diagram (DFD) shows external entities, processes, data stores and the movement of data. A trust boundary marks a change in trust or authority. It can exist between a browser and an API, between two operating-system accounts, or between a device and a remote service.

Give each flow a direction, data description and protection mechanism. A box labelled “cloud” hides too much if several services have different identities and permissions. Split the box when that difference changes the analysis.

For the industrial gateway example, begin with the operator browser, gateway management API, local configuration store, local controller, telemetry service and update service. Show management and telemetry as TLS connections. Treat update signature verification as a proposed control until its implementation is established.

From STRIDE categories to attack scenarios

STRIDE groups threats into spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Use these categories to prompt questions about each relevant process and flow. A category name alone does not describe an attack.

For example: a user with read-only access sends a configuration-change request directly to the management API. If the API checks the login but not the action permission, the user can change the gateway configuration. This identifies an actor, an entry point, a missing control and an impact.

Link each scenario to the relevant interface, process or flow in the diagram. Scenarios with different attack conditions or controls need separate analysis. If a condition is unknown, such as authentication on the controller interface, record what needs to be confirmed.

Risk priorities and security controls

Risk priorities depend on the access and capability an attacker needs, the likelihood of success and the consequences for the product. An agreed risk method makes these judgements consistent. The reasoning behind a score lets others review it.

Choose a response the team can implement. For the configuration-change scenario, require the API to enforce the caller’s permission on every write operation. Assign an owner, a target release and a check that shows whether the control works.

Existing TLS protects a transport connection; it does not establish that a logged-in user may change configuration. Review the control against the exact attack step it is meant to stop. If the team accepts a remaining risk, retain the reason and the person authorised to make that decision.

Verification and model updates

A proposed control and a verified control are different states. Link an implemented control to the relevant change and its verification result. For the API example, send a write request as a read-only user and confirm both the rejection and the absence of a configuration change.

Review the model when an interface, permission, component, deployment or update mechanism changes. New vulnerability information can also invalidate an earlier assumption. Preserve the previous model so the team can explain which releases a decision applied to.

Further reading

• Industrial gateway STRIDE example
• Threat model records and reports
• Threat modelling in Sytance