5.4.2.1 Threat model
You use the guidance on threat modelling to define the product scope, assumptions and security objectives. | Category | Details | | Purpose | | Drive engineering decisions for binary hardening, port configuration and user access |
control for SafeGate-X1. | Scope boundaries | In scope: SafeGate-X1 firmware, local API (HTTPS), maintenance SSH, local |
touchscreen. Out of scope: corporate network infrastructure, physical lock mechanics. | Assumptions | 1. The local network is untrusted (hostile actors may have plugged into the switch). |
2. Physical access to the cabinet is restricted but possible (tampering must be detected). | Security objectives | Integrity: prevent unauthorised gate triggers. |
Availability: ensure the gate is operable during emergencies. Safety: ensure fail-safe logic is never overridden by software. | Crown jewels | Gate actuator control (GPIO), cryptographic signing keys, audit logs. |
SafeGate-X1 is modelled as a set of interacting processes with varying trust levels. - Trust Boundary A (External/Network): Separates the untrusted factory LAN from the device’s listening services (HTTPS/SSH).
- Trust Boundary B (User/System): Separates the non-privileged gate-service user from the restricted root system functions.
- Privileged Path (The Update Channel): A high-integrity path from the Update Server to the internal flash storage.
- Privileged Path (Admin Maintenance): A short-lived, certificate-signed path for the Maintenance Engineer to access the OS shell.
Figure 4: Trust boundaries diagram Source: Built with https://mermaid.live . Note that Figure 4 provides an illustrative system representation for this simplified example. It is not intended to prescribe a standard notation or a particular tool. Other suitable approaches, including dedicated threat-modelling tools, may be used. The threats in this example are specific to the illustrated product and should be adapted to the product’s functionality and deployment context. The example below uses likelihood/impact ratings for prioritisation as an example | ID | | Threat scenarios | | Boundary | | Likelihood | | Impact | | Priority | | T1 | | RCE via web API: attacker exploits a buffer overflow in the web server to gain shell access | | Trust Boundary A (HTTPS) | | Medium | | High | | Top | | | T2 | | Privilege escalation: attacker uses a compromised web service to gain root privilege and disable logs | | Trust Boundary B (system) | | High | | High | | Top | | | T3 | | Port scanning/discovery: attacker identifies legacy services (e.g. Telnet) left on by mistake | | Trust Boundary A (network) | | High | | Medium | | High | | | T4 | | Credential stuffing: attacker attempts to log in via SSH using common default passwords | | Trust Boundary A (SSH) | | High | | High | | High | | | T5 | | Binary tampering: attacker replaces the gate-logic binary with a version that keeps the gate open | | Local storage | | Low | | High | | Medium | |
1. Oversigt
1.1 Referencer
1.2 Identificerede krav
1.3 Relaterede reguleringer
2. Identificerede krav
3. Relaterede reguleringer
Reguleringer
| Kilde |
Regulering |
|