5.4.2 SafeGate-X1 example

You use the guidance on threat modelling to define the product scope, assumptions and security objectives.

control for SafeGate-X1.

touchscreen.

Out of scope: corporate network infrastructure, physical lock mechanics.

2. Physical access to the cabinet is restricted but possible (tampering must be detected).

Availability: ensure the gate is operable during emergencies.

Safety: ensure fail-safe logic is never overridden by software.

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

This section maps the threats to specific principles and verification methods.

The SafeGate-X1 example can be read across the three layers as follows.

• Control layer
  • Records the strategic objectives and their relationship to the identified threat scenarios (T1–T5), for example: ‘Unauthorised gate operation must be prevented.’
• Implementation layer
  • Identifies relevant principles and controls, for example: ‘We apply least privilege and attack surface minimisation.’
  • Describes the technical settings used to implement them, for example: ‘We run as UID 1001 , use Linux capabilities and close all ports except 443.’
• Assessment and verification layer
  • Records the checks performed, release gates and SBOM hashes, for example: ‘ Nmap and Lynis confirm these settings; we provide the cryptographic hashes of the evidence.’

Attack surface minimisation (T1/T3)

• Logic. If the threat is an external compromise (RCE), we remove the tools an attacker needs to escalate (sh, curl, etc.).
• Implementation. We use a Distroless (38) base image.
• Gate. An automated Nmap scan runs against the deployed release candidate. It compares the active ports against the ports_allowed list in the JSON. If a mismatch is found, the release fails and the firmware is rejected.

The JSON fragment presented as Figure 5 illustrates how information from the three layers could be expressed in a machine-processable form. The field names and structure are illustrative only and do not define a specific schema or implementation format. In practice, this information may be represented using existing standards and specifications, like those described in Section 5.3.

Figure 5: Example of machine-processable security information

Least privilege (T2)

• Logic. If the web service is compromised, it should not have permission to modify the system.
• Implementation. The application is assigned UID 1001 with no entry in the sudoers file.
• Gate. A Systemd audit script parses the service unit files. It verifies that CapabilityBoundingSet is restricted to only necessary network calls, ensuring that the principle of least privilege is hard-coded into the operating system execution.

Strong identity (T4)

• Logic. Credential stuffing and brute-force attacks rely on passwords.
• Implementation. We disable password logins entirely at the configuration level.
• Gate. Before the gold image of the firmware is generated, a linter checks sshd_config to ensure PasswordAuthentication is set to no .

Vulnerability and patch management (T5)

• Logic. Even following a compromise, the attacker should not be able to achieve persistence by modifying system files.
• Implementation. The root file system is mounted as read-only .
• Gate. A CI test runs a script inside a staging environment that attempts to touch /usr/bin/test_file . If the file is successfully created, the release gate fails, as it has been proved that the secure by default setting was not correctly applied.

The following table shows how machine-processable security information may be consumed by third-party assessors to identify relevant claims, locate supporting evidence and perform targeted verification activities.

gate (how it

was tested)