STRIDE example: an industrial gateway
Sytance · Updated
STRIDE uses six threat categories to examine how a system could be attacked. The fictional industrial gateway below illustrates one scenario for each category, with a proposed control and a test criterion. These examples describe possible attacks and planned tests.
The gateway and its trust boundaries
An operator uses a browser to call the gateway management API. The API reads and writes a local configuration store. A local controller sends operational data to the gateway, which forwards telemetry to a remote service. A separate update service supplies firmware packages.
Management and telemetry connections use TLS in this example. The authentication of the controller interface and the update trust mechanism remain open design questions. A local network location does not itself establish the identity or authority of a sender.
- Browser → management API: sessions, status requests and configuration changes.
- Management API → configuration store: stored settings and access to secrets.
- Local controller → gateway: operational input from the site network.
- Gateway → telemetry service: device identity and telemetry data.
- Update service → gateway: package metadata and firmware content.
Identity spoofing on the controller interface
An attacker on the site network sends messages that claim to come from the local controller. If the gateway trusts only a source address, forged operational data may enter the telemetry stream.
Proposed control: establish a device identity and verify it before accepting messages. If the controller cannot support authentication, assess other ways to protect the interface and the attacks that remain possible. A network segment alone does not prove message origin.
Verification criterion: messages from an unrecognised test identity are rejected, while messages from the approved controller still work. Capture the rejection and confirm that the forged value did not reach the telemetry service.
Firmware tampering before installation
An attacker replaces a package obtained through a compromised distribution point. Transport encryption to that point would not prove that the package was authorised by the manufacturer.
Proposed control: verify the package signature against an authorised trust anchor before installation. Bind the verification to the bytes being installed and the permitted product. Decide separately how to handle older signed versions and revoked signing keys.
Verification criterion: an altered package and a package signed by an untrusted key are rejected before installation. After rejection, the gateway must remain in its specified operating or recovery state.
Untraceable configuration changes
An authorised operator changes the telemetry destination, but the record contains no individual identity or result. The team cannot reliably attribute the change or distinguish a successful write from a rejected request.
Proposed control: log the authenticated identity, action, target, time and outcome. Protect log access and define behaviour when storage is full. Avoid putting passwords or access tokens in the log.
Verification criterion: a controlled change produces a corresponding record, an unauthorised user cannot edit it, and the audit behaviour under full storage matches the documented policy.
Secrets exposed through configuration reads
A status endpoint returns the full configuration object, including the telemetry credential. A user who is allowed to view status receives information that their role does not need.
Proposed control: return a purpose-specific response with secret fields omitted, and enforce permissions on configuration reads. Encryption in transit does not remove an excessive-data response.
Verification criterion: inspect responses for each supported role and confirm that secret values do not appear in the response, errors or logs.
Input processing exhausts the gateway
A sender delivers oversized or repeated controller messages. Parsing and buffering consume resources that the gateway also needs for management and telemetry.
Proposed control: bound message sizes and queues, validate input before expensive work, and isolate critical processing. Set limits using measured capacity and the product’s required behaviour during overload.
Verification criterion: in an authorised test environment, exercise the agreed overload cases and observe memory, queue depth, service availability and recovery. The acceptance limits come from this product’s requirements; no universal rate is assumed.
A read-only user reaches a write operation
A user can sign in and view status. They call a configuration-write API directly, bypassing the interface. If the API checks only authentication, the user gains a capability reserved for administrators.
Proposed control: enforce action and resource permissions on the server for every write path. Keep the same rule for normal requests, bulk operations and maintenance endpoints.
Verification criterion: direct write requests from a read-only account fail and the stored configuration remains unchanged. Repeat with an authorised account to verify the intended operation still succeeds.
Coverage and remaining risks
The six categories follow Microsoft’s STRIDE definitions. The attack scenarios and controls depend on the gateway architecture described above.
A real product may have several attack scenarios within one category, and one attack may fit several categories. The analysis also needs to cover manufacturing, maintenance and recovery interfaces if the product includes them.
After implementing and testing a control, assess the attacks that remain possible against the agreed risk criteria. The resulting decision applies to the product release that was analysed.