Method descriptions remain abstract until you see them applied to a real device. So here is a worked analysis of a concrete object of study: a PROFINET® circuit breaker platform — a communication module with a safety-related switching function via PROFIsafe, built around an STM32 as the control MCU and a LAN9354 as the network chip.
What makes this device special: it switches power, and it does so under a safety function. A security incident here does not remain an IT problem.
A note on scope: what follows is a compact working example, not a complete TRA. A full analysis for a real product is considerably more extensive — the point here is to make the approach traceable on a real device.
Step 1: Name the Attack Surface
Before any assessment comes the question of where an attacker can even begin. For this device, there are six entry points:
| ID | Interface | Why it matters |
|---|---|---|
| IF-01 | PROFINET RT | DCP, LLDP, cyclic real-time frames — unauthenticated by default |
| IF-02 | PROFIsafe | F-parameters, CRC, sequence number, watchdog over the black channel |
| IF-03 | STM32 — firmware & debug | Boot chain, JTAG/SWD, flash readout protection (RDP), secure boot |
| IF-04 | Firmware update path | How new firmware is installed — with or without signature verification |
| IF-05 | Diagnostics & management | Web UI, SNMP via the LAN9354, serial service console |
| IF-06 | Supply chain & toolchain | Third-party stack, build environment, handling of signing keys |
This list is already a result. It forces you to name interfaces that are often missing from architecture diagrams — the debug port and the supply chain, for example.
Step 2: STRIDE — the Most Relevant Scenario per Category
STRIDE walks through the six threat categories and asks for each: what is the most realistic scenario here, which interface does it affect, and how severe is it?
| Category | IF | Scenario | Risk |
|---|---|---|---|
| Spoofing | 01 | DCP identity spoofing: attacker poses as a legitimate field device and takes over the communication relationship | Medium |
| Tampering | 01/02 | Manipulation of cyclic RT frames or F-parameters → falsified switching commands | High |
| Repudiation | 05 | Missing security logging: configuration changes cannot be traced | Low |
| Information Disclosure | 03/05 | Flash readout without RDP; plaintext diagnostics and SNMP reveal the topology | Medium |
| Denial of Service | 01/02 | PROFINET flooding / DCP storm overloads the stack → PROFIsafe goes to the safe state | High |
| Elevation of Privilege | 04/05 | Unsigned firmware or open service access → persistent full control | High |
Two observations are worth a second look.
Missing device identity makes trust topological. Without a cryptographic device identity — for example according to IEEE 802.1AR — trust between participants rests solely on who is physically connected to the network. Anyone with network access is thus implicitly trustworthy. That is the underlying assumption that makes spoofing possible in the first place.
Availability is a safety problem here, not a convenience problem. PROFIsafe reacts to disturbances correctly — it goes to the safe state. But that is exactly what means an unplanned plant shutdown. An attacker does not even need to break integrity to cause damage; they only need to disrupt.
The Coupling That Makes This Device Special
The central finding of this analysis is not a single row of the table but their sum: a successful attack on IF-01, IF-02 or IF-04 can override the safety-related function. For this product, a loss of integrity is a potential violation of functional safety.
That shifts the discussion. As long as security is negotiated as the protection of data, it competes with other requirements for budget. As soon as it is understood as a prerequisite for the protective function, it stands alongside the safety argument — and that is non-negotiable in this market segment.
Step 3: Attack Tree — From Scenario to Paths
The most severe scenario from the STRIDE table is decomposed: Trigger an unauthorized hazardous switching action. Three paths lead to the goal, and one is enough:
- Branch A — via the network (IF-01/02). Either RT frame manipulation, which requires both conditions at once: network access and missing integrity protection. Or a PROFIsafe bypass via manipulated F-parameters.
- Branch B — via the firmware (IF-03/04). Either unsigned firmware via the update path, or an open debug port (JTAG/SWD without readout protection enabled).
- Branch C — via the configuration (IF-05). Service access without authentication, via the web UI or serial console, and changing the parameters through it.
The difference between OR and AND is the whole point of the method. An OR node means: any sub-path is sufficient, the chain is only as strong as its weakest link. An AND node means: all conditions must come together — and breaking one of them is enough to close the path.
The hardening rule follows directly: First interrupt the easiest complete path. Not the most spectacular one, not the technically most interesting one. Each leaf is rated by required access, effort, prior knowledge and likelihood of detection — the same logic that underlies the attack potential rating.
Step 4: Measures That Cut Branches
A measure is justified precisely when you can show which branch it interrupts. That is the difference between a mitigation plan and a wish list:
| Measure | Effect in the attack tree |
|---|---|
| Secure boot + signed firmware updates | Cuts branch B completely — unsigned firmware and debug persistence |
| Disable debug ports in production, readout protection active | Cuts the debug leaf in branch B, prevents flash readout |
| Cryptographic device identity (IEEE 802.1AR) | Removes the spoofing prerequisite from branch A |
| Authentication for web UI and service access | Cuts branch C |
| Network segmentation and rate limiting | Increases the effort for network access, mitigates DoS |
| Secure security logging | Addresses repudiation, makes attacks detectable in the first place |
Each of these measures can be mapped to requirements from IEC 62443-4-2 and to Annex I of the Cyber Resilience Act. That is no coincidence but the actual benefit of a cleanly maintained analysis: the requirement of the standard is then no longer a checklist imposed from outside, but the justification of a decision you have made anyway.
What This Example Shows
The analysis covers six interfaces, six threat categories, one decomposed attack path and six measures. That is manageable — and yet it is enough to answer the three questions an audit hinges on: What can happen, how likely is it, and why is what we do against it sufficient?
The effort does not lie in creating it. It lies in keeping this state current when the next firmware version arrives, an interface is added or a product variant branches off.
Sources
- Alsensio, Threat analysis of a PROFINET circuit breaker platform (STRIDE + attack tree, v1)
- Cyber Resilience Act — Summary of the legislation (European Commission)
- IEC 62443-4-2 — Technical security requirements for IACS components
This article was originally published in German on the Alsensio Cybersecurity Hub.
