Worked example / Threat modelling

Industrial gateway threat model

Follow a firmware package, a configuration request and a telemetry connection. See how each interface leads to a threat, a security requirement and a verification activity.

Explore the analysis

03Threat scenarios

05Data flows

1.0.0Example product

Industrial gateway / Threat modellingPublic example

Dashed line: site trust boundary. F1 management · F2 configuration · F3 telemetry · F4 firmware · F5 controller data.

01 / Context

A boundary worth examining.

The gateway operates in a managed industrial network. Operator requests, remote telemetry and software updates cross interfaces with different trust assumptions.

This example focuses on three interfaces. Controller protocols, physical access and operational safety constraints need further analysis for the specific product.

02 / Threats and linked records

From an attack scenario to a testable requirement.

Select a threat to read its conditions, risk considerations and proposed response. Each requirement continues into a design decision and a planned verification record.

T-01 / F4Tampering

An untrusted update is installed

An attacker replaces a firmware package before the gateway installs it. Transport protection alone does not establish who produced the package.

Affected assetUpdate client

Attack condition

The gateway accepts a package without verifying a trusted signature and the intended product identity.

Consequence

Attacker-controlled firmware can change device behaviour and expose credentials.

Establish the risk

Review who can supply a package, how the trust anchor is protected, and what altered firmware could do to this installation. Define likelihood and impact using the product’s risk methodology.

Risk rating: to be assessed for the actual product.

Follow the linked records

SR-01

Security requirement

Before installation, the gateway shall authenticate the package publisher, confirm the target product and reject versions outside the permitted update policy.

SD-01 · Design decision

SD-01

Security design

Place signature, product-identity and version checks in the update client before installation. Keep the trust anchor in protected storage and preserve the current image when a check fails.

V-01 · Verification activity

V-01

Verification

Planned

Try a modified package, an untrusted signing key and a package for another product. Record the rejection and recovery behaviour.

Acceptance criteria: Each invalid package is rejected before installation. The current image remains usable and the rejection reason is recorded.
Evidence to retain: Package identity and hash; signing key used; gateway build and configuration; installation and recovery logs.

T-02 / F1Elevation of privilege

A user changes another role’s settings

A low-privilege user sends a configuration request directly to the management API. Hiding an action in the browser does not restrict the API.

Affected assetManagement API

Attack condition

The API authenticates the user but does not authorise the requested configuration change.

Consequence

An unauthorised change can disrupt controller communications or redirect telemetry.

Establish the risk

Establish which roles can reach the API and which settings affect controller communications or telemetry destinations. Assess the consequences of each unauthorised change.

Risk rating: to be assessed for the actual product.

Follow the linked records

SR-02

Security requirement

The management API shall authorise every protected configuration change against the authenticated user’s assigned permissions and record security-relevant changes.

SD-02 · Design decision

SD-02

Security design

Apply a server-side permission check before the configuration write. Use the same check for browser and direct API requests; include actor, operation and outcome in the audit record.

V-02 · Verification activity

V-02

Verification

Planned

Send configuration changes using each defined role. Check both allowed and denied requests and their audit records.

Acceptance criteria: Permitted operations succeed. Disallowed operations leave the configuration unchanged and produce the expected denial and audit record.
Evidence to retain: Role and permission matrix; request and response pairs; configuration before and after; audit records.

T-03 / F3Spoofing

Telemetry is sent to an impersonated service

An attacker redirects the gateway to a service under their control. Encryption does not help if the gateway accepts the wrong server identity.

Affected assetTelemetry connection

Attack condition

The gateway fails to validate the server certificate chain or hostname.

Consequence

Operational data can be disclosed and false service responses may influence the gateway.

Establish the risk

Identify the telemetry data sent, who can alter the network path, and whether service responses affect the gateway. Assess disclosure and operational consequences separately.

Risk rating: to be assessed for the actual product.

Follow the linked records

SR-03

Security requirement

The gateway shall validate the telemetry service’s certificate chain and hostname before sending data, and shall reject connections whose identity cannot be established.

SD-03 · Design decision

SD-03

Security design

Use the configured trust store and hostname validation in the TLS client. On validation failure, stop transmission and record the cause; renew certificates through the controlled service configuration.

V-03 · Verification activity

V-03

Verification

Planned

Test an untrusted certificate, wrong hostname and expired certificate. Confirm the gateway rejects the connection without leaking telemetry.

Acceptance criteria: Untrusted, mismatched and expired certificates are rejected before telemetry is sent. A valid service remains reachable under the intended configuration.
Evidence to retain: Certificate chain and hostname; trust-store configuration; connection logs; traffic capture showing the absence of telemetry on rejected connections.

03 / Documentation

The report keeps the reasoning connected.

The architecture defines the scope. Threat records explain the attack. Linked requirements, design decisions and verification records show how the team responds.

In Sytance, the documentation area assembles these workspace records for HTML preview and available PDF or DOCX outputs.

Start with your product

SYTANCE / CONTENT OUTLINETM · 1.0.0

Product threat model report

Industrial gateway · public example

01Product scope and assumptions
02Architecture, assets and data flows
03Threat scenarios and risk assessment
04Requirements, design and verification

Example traceability

T-01 SR-01 SD-01 V-01

T-02 SR-02 SD-02 V-02

T-03 SR-03 SD-03 V-03

Verification planned

Content outline of this example. A product report is generated from its own workspace records and document configuration.

Apply the method

Start with the facts you can verify.

Establish the architecture

Describe the deployment, components, stored data and interfaces. Associate each threat with the affected component or data flow.

Review the proposed response

Assess risk using your product methodology. Select requirements and record the design decisions needed to implement them.

Complete the evidence

Define the test configuration and acceptance criteria. After execution, retain the results and review the document preview.

Methods, examples and practical questions

Threat modelling in Sytance Threat model records and report structure Explore the gateway’s software inventory

Start with your product architecture, software inventory and existing analysis, then develop the security records you need.

Create a product