Introduction
This document presents comments on Draft ETSI EN 304 636 V1.0.0, which specifies cybersecurity requirements for firewalls, intrusion detection and/or prevention systems.
This standard is very similar to the routers one. Our comments are also similar.
Disclaimer: 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 products intended for use in the industrial Operational Technology (OT) domain and refers to prEN 50770-1. However, general-purpose equipment is frequently deployed in OT environments even when it was not designed specifically for OT.
Such deployment should 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 product within the scope of this standard can reasonably be deployed in an OT environment, even if it was not originally designed for that purpose.
- Comment 2 – Clause 4.7.2 – Missing SME and personal use cases
Firewalls are not always administered by professional security engineers. In SMEs and personal use cases, they may be operated by users with limited security and networking knowledge, or with access to a qualified administrator only for limited periods.
These use cases have different requirements, including ease of configuration, secure defaults and documentation of typical configurations. Some later requirements already partially address these situations, but they are not represented in the use cases.
=> Proposed change:
Extend the existing use cases or add a use case covering SMEs and personal use, where the product is not continuously administered by a qualified security or networking professional.
- Comment 3 – Clause 5.3.1.2 – REQ-KEV-1-03 – Vulnerability checks limited to third-party components
REQ-KEV-1-03 requires vulnerability checks “for each third-party component”. This excludes components developed or maintained by the product manufacturer.
The status of originally third-party components, especially open-source components, that have been modified and maintained by the manufacturer is also unclear.
=> Proposed change:
Require vulnerability checks for all components.
For modified third-party components, the vulnerability assessment shall take into account both the upstream component and the modifications maintained by the manufacturer.
- Comment 4 – Clause 5.3.1.2 – REQ-KEV-1-03 – “Known vulnerability databases” is ambiguous
The term “known vulnerability databases” does not specify which sources need to be used for vulnerability checks. Different databases can contain different vulnerability information.
=> Proposed change:
Require the manufacturer to document which vulnerability databases are used for vulnerability checks.
- Comment 5 – 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 6 – Clause 5.10.1.2 – REQ-INTEGRITY-1-01 – Boot integrity terminology is ambiguous
REQ-INTEGRITY-1-01 is ambiguous. It is unclear what “state of the art cryptography” requires in this context and, in particular, whether cryptographic signatures are required.
Terms describing boot integrity mechanisms should also be defined consistently. For example, the current draft of the Boot Managers standard uses “Secure Boot” specifically for UEFI Secure Boot. If here the meaning is different, it might be confusing to readers.
=> Proposed change:
Define the required security property and cryptographic mechanisms explicitly, including whether digital signatures are required. Define terms such as “secure boot” where they are used, and distinguish them from more general cryptographic verification of the boot chain.
