Introduction
This document presents comments on Draft ETSI EN 304 627 V1.0.1, which specifies cybersecurity requirements for routers, modems intended for connection to the Internet, and switches.
The comments focus on clarifying the scope of the standard, for cases that were not done duing the development of the standard.
One of the important points is the fact that there’s another standard for OT (operating technology) routers, switches and modems. As more and more OT uses standard products, scope of those two standards should be clear. In my opinion, the general standard should also cover OT cases, as generic equipment will be found in OT configurations.
Another thing to clarify: I’ve heard people assuming that this one requires secure boot. What it does, Clause 5.9.1.4 indicates that the boot chain should be verified. Hashes may be used as one possible verification mechanism, but the clause does not require the use of digital signatures.
Disclaimer: I have participated in the elaboration of this standard. The work and the review was made possible thanks to a grant from the CYBERSTAND programme.
Implementation
- Comment 1 – Scope – Use of general-purpose equipment in OT environments
The standard excludes routers, modems and switches intended for use in the industrial Operational Technology (OT) domain and refers to prEN 50770-5 [i.14]. However, general-purpose networking equipment is frequently deployed in OT environments even when it was not designed specifically for OT.
Such deployment should therefore be considered as a reasonably foreseeable use or misuse for products within the scope of this standard.
=> Proposed change:
Clarify that OT use cases shall be considered when a device within the scope of this standard can possibly be deployed in an OT environment, even if it was not originally designed for that purpose.
- Comment 2 – Clause 4.4.2 – Number of persons with access
Clause 4.4.2 assumes access by a limited number of persons. This does not reflect the exposure of many routers, modems and switches.
Network interfaces may be directly exposed to the Internet. Wireless interfaces may also be accessible to anyone within a larger physical area, including persons in public spaces without physical access to the device.
=> Proposed change:
Clarify that network interfaces may be accessible to an unrestricted number of persons when exposed to the Internet, and that wireless interfaces may be accessible to persons within the wireless coverage area without physical access to the device.
- Comment 3 – Clause 5.4.1.2 – REQ-DEFAULT-1-8 – “State of the art cryptography”
REQ-DEFAULT-1-8 requires “state of the art cryptography” but does not establish a correspondence between this term and the cryptographic recommendations in Annex K.
=> Proposed change:
Define “state of the art cryptography” for this requirement by reference to the applicable provisions of Annex K.
- Comment 4 – Clause 5.4.1.2 – REQ-DEFAULT-1-13 – Persistence of audit events
REQ-DEFAULT-1-13 does not make clear that generated audit events need to survive a reboot.
=> Proposed replacement:
“[REQ-DEFAULT-1-13] The product shall store generated audit events in persistent memory that survives a reboot.”
- Comment 5 – Clause 5.6.1.2 – REQ-AUTH-1-02 – Device-unique default credentials
REQ-AUTH-1-02 does not make clear that credentials generated during production need to be unique for each device.
=> Proposed change:
Modify:
“(i) generating device-unique credentials during secure production;”
- Comment 6 – Clause 6.2.1.1 – Vulnerability applicability and VEX
Clause 6.2.1.1 does not take into account that a vulnerability database may report vulnerabilities that do not apply to the product because of its configuration, use of the affected code, existing mitigations or other factors.
Manufacturers can document these assessments using VEX. Such information is more useful than only recording that a vulnerability check was performed.
=> Proposed change:
Allow the manufacturer to provide documented vulnerability assessments, including information that a vulnerability does not affect the product or has been mitigated. Such assessments may be provided using a standardized VEX format.
- Comment 7 – Clause 6.2.1.1 – Modified third-party components
Clause 6.2.1.1 assumes that each component, including third-party components, can be identified by a well-defined version. This does not cover products using modified or patched versions of upstream components.
The upstream version alone may then be insufficient to identify the actual component or determine its vulnerability status.
=> Proposed change:
For modified third-party components, allow the manufacturer to identify the upstream version together with the applied modifications or patches, or provide a provenance location from which the modified version can be identified.
