If the deliverable contains or requires an operating system the operating system is expected to be regularly updated and maintained.
Depending on the chosen delivery method, the maintenance of the operating system can be provided by the customer of the product.
Note that a container has always an operating system.
If automateable vulnerability scanners are available the product shall satisfy the following with respect to the most comprehensive of such scanners.
-**[REQ-EXPLOIT-0a]** The product shall have no known exploitable vulnerabilities discovered by scans.
-**[REQ-EXPLOIT-0c]** For each identified exploitable vulnerability, the product shall have the risk mitigated.
-**[REQ-EXPLOIT-0d]** The used vulnerability scanner shall be fit for the purpose in detail, method and depth.
Recognising that there may be vulnerabilities discovered between the time that a product is placed on the market and the time of that product's first use, and that the product should be free from known exploitable vulnerabilities both when first made available and when first used by the system user.
-**[REQ-EXPLOIT-1]** The product shall be securely updated.
-**[REQ-EXPLOIT-2]** The product shall have divorserd OS and Application update procedures which makes it possible to obtain the set High Availability targets when the operational environment makes this possible.
-**[REQ-EXPLOIT-3]** The product shall ensure that the product can be updated at the time of first use to address all known exploitable vulnerabilities which were discovered after the product's placement on the market and before that first use.
More about [High Availability](#53x-high-availability) in its dedicated chapter.
This section contains technical cybersecurity requirements for the product. Each general technical requirement is objectively verifiable on an instance of a product.
@@ -563,118 +545,6 @@ DDoS mitigations:
### 6.1.1 No known exploited vulnerabilities tests
#### 6.1.1.0 REQ-EXPLOIT-0
**Objective:**
Verify that:
1. Known exploitable vulnerabilities affecting the product are identified.
2. For each identified known exploitable vulnerability, one of the following applies:
* the vulnerability assessment demonstrates that the vulnerability is not exploitable in the product; or
* specific user guidance is provided to prevent exploitation.
3. No known exploitable vulnerability remains in the product without one of the above justifications.
**Preparation:**
* [DESIGN] Product documentation identifying elements contained in the product (elements may include software, firmware, or hardware elements, as applicable).
* [INVENTORY] component inventory, bill of materials, or equivalent software identification information, including version and patch-level information where available.
* Access to the product, or to relevant components such as binaries, packages, images, firmware, containers, or file systems, sufficient to perform vulnerability scanning where technically feasible.
* Vulnerability scanning tools and associated vulnerability databases suitable for identifying candidate vulnerabilities in the product.
* Access to recognized public vulnerability sources:
* Public databases e.g. EUVD, CISA Known Exploited Vulnerabilities (KEV) Catalog, the CVE List, the NIST National Vulnerability Database (NVD) and relevant vendor advisories;
* Complementary sources that may support identification of relevant vulnerabilities, where relevant, for example technical research papers, conference papers and other publicly available security research.
**Activities:**
1. Review the product documentation, component inventory, bill of materials, or equivalent information to identify the elements contained in the product (which may include software, firmware, or hardware elements, as applicable) and their relevant versions or patch levels, where available.
2. Perform vulnerability scanning, where technically feasible, on the product or relevant components to identify candidate vulnerabilities affecting elements contained in the product.
3. Assess, in accordance with prEN 40000-1-3 [X], the vulnerabilities identified through correlation of scanning results, product identification information, vendor advisories, and recognized public vulnerability sources.
4. For each identified known exploitable vulnerability, review the vulnerability assessment and verify whether it demonstrates that the vulnerability is not exploitable in the product:
5. Where the treatment of an identified known exploitable vulnerability relies on user guidance, review the user guidance and verify that it specifically addresses the conditions to prevent exploitation.
6. Verify that no identified known exploitable vulnerability affecting the product remains without:
* a vulnerability assessment demonstrating non-exploitability in the product; or
* specific required user guidance to prevent exploitation.
**Verdict:**
* Pass: Known exploitable vulnerabilities affecting the product are identified, and each such vulnerability is covered either by a vulnerability assessment demonstrating non-exploitability in the product, or by specific user guidance preventing exploitation.
* Fail otherwise.
**Supporting Evidence:**
* [SCAN] Vulnerability scanning results, including the tools and vulnerability databases used with snapshot date information.
* [ADVISORY] Recognized public vulnerability sources, vendor advisories, and product identification information used in the assessment.
* [ANALYSIS] Vulnerability assessment records and conclusions produced in accordance with prEN 40000-1-3 [X].
* [GUIDANCE] Product user guidance relied upon to prevent exploitation, where applicable.
#### 6.1.1.1 REQ-EXPLOIT-1
**Objective:** Prevent exploitation of known exploited vulnerabilities<br/>
**Preparation:**
1. Examine public or private vulnerability information sources and select a recently fixed vulnerability (preferably the most recently fixed).
**Activities:**
1. On a new product, carry out the initial secure update, scan the product to see if a recently fixed vulnerability has been fixed on the product, and examine the documentation for the required info.
**Verdict:**
1. Pass if the secure update completes successfully
2. and the most recently fixed vulnerability is fixed
3. and the documentation includes all the required information
4. and the instructions are noting the custom requirements of the application, if any
5. and the interfaces connected during the update procedure are known
6. and the integrity of the content is ensured during the update procedure.
7. Fail otherwise.
**Supporting Evidence:**
1. Documentation of vulnerability handling
1. Documentation of how to securely update the product
1. The report for the selected vulnerability
1. Description of how to scan for the vulnerability
1. Log of vulnerability scan results
#### 6.1.1.1 REQ-EXPLOIT-1ish from Uli
**Preparation:** Program a test source providing an authentic and integrity correct update package.<br/>
**Activities:**
* Operate the test update server.
* Study the technical documentation.
* If needed activate the update mechanism and check whether the mechanism is configurable.
* Check if the update mechanisms can be configured to check itself for updates, conduct the update on trigger, or runs at first use.
* Configure the update mechanisms with respect to point in time of conduct.
**Verdict:**
* The technical documentation describes the update mechanism in sufficient practical detail to conduct the update.
* The test update is operated as configured on action, prior, or as part of the first use.
* The test update was operated as configured with respect to the point of time of conduct.
**Supporting Evidence:**
* References to document sections.
* Screenshots from the update configurations and of the corresponding conducts.
#### 6.1.1.2 REQ-EXPLOIT-2
**Objective:** Responsibility of OS level updgrades can be elsewhere outside of the system control.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
**Verdict:**
1. Pass if cross referencing OS and Application update instructions makes it possible to maintain High Availability requirements defined in the technical documentation.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
## 6.2 Technical cybersecurity requirement tests and assessments
@@ -1047,8 +1047,8 @@ High requirement level shall implement all requirements in the defined set of re
| Use-case | Requirement set | required level |
| :------- | :-------------- | -------------- |
| all | CYB_* | all |
| all | CYB_GENERAL | all |
| all | KEV_EXPLOIT | all |
## 5.2 Appropriate level of cybersecurity
@@ -1075,9 +1075,16 @@ On operative environment:
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a).
<mark>_Proposed ESR code: KEV_</mark>
If the deliverable contains or requires an operating system the operating system is expected to be regularly updated and maintained.
Depending on the chosen delivery method, the maintenance of the operating system can be provided by the customer of the product.
Note that a container has always an operating system.
***KEV_EXPLOIT-1** If automateable vulnerability scanners are available the product shall satisfy the following with respect to the most comprehensive of such scanners.
* The product shall have no known exploitable vulnerabilities discovered by scans.
* For each identified exploitable vulnerability, the product shall have the risk mitigated.
* The used vulnerability scanner shall be fit for the purpose in detail, method and depth.
<mark>Editor’s Note: This is also a requirement on the product. Thus, a reference to prEN 40000-1-3 is not sufficient to fulfil it. Example of requirement: “The product shall be exempt from vulnerabilities present in xxx section of the EUVD”.</mark>
Recognising that there may be vulnerabilities discovered between the time that a product is placed on the market and the time of that product's first use, and that the product should be free from known exploitable vulnerabilities both when first made available and when first used by the system user.
## 5.4 Secure by default configuration
@@ -1091,10 +1098,12 @@ This technical requirement may be accompanied by the following note:
## 5.5 Security updates
<mark>_Proposed ESR code: SU_</mark>
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c).
***SU_UPDATE-1** The product shall be securely updated.
***SU_UPDATE-2** The product shall have divorserd OS and Application update procedures which makes it possible to obtain the set High Availability targets when the operational environment makes this possible.
***SU_UPDATE-3** The product shall ensure that the product can be updated at the time of first use to address all known exploitable vulnerabilities which were discovered after the product's placement on the market and before that first use.
## 5.6 Authentication and access control
<mark>_Proposed ESR code: AAC_</mark>
@@ -1296,10 +1305,126 @@ NNNNN - Incremental and unique sequence of numbers and letters - could be the sa
## 6.3 No known exploitable vulnerabilities
### 6.3.1 KEV_EXPLOIT-1
**Objective:**
Verify that:
1. Known exploitable vulnerabilities affecting the product are identified.
2. For each identified known exploitable vulnerability, one of the following applies:
* the vulnerability assessment demonstrates that the vulnerability is not exploitable in the product; or
* specific user guidance is provided to prevent exploitation.
3. No known exploitable vulnerability remains in the product without one of the above justifications.
**Preparation:**
* [DESIGN] Product documentation identifying elements contained in the product (elements may include software, firmware, or hardware elements, as applicable).
* [INVENTORY] component inventory, bill of materials, or equivalent software identification information, including version and patch-level information where available.
* Access to the product, or to relevant components such as binaries, packages, images, firmware, containers, or file systems, sufficient to perform vulnerability scanning where technically feasible.
* Vulnerability scanning tools and associated vulnerability databases suitable for identifying candidate vulnerabilities in the product.
* Access to recognized public vulnerability sources:
* Public databases e.g. EUVD, CISA Known Exploited Vulnerabilities (KEV) Catalog, the CVE List, the NIST National Vulnerability Database (NVD) and relevant vendor advisories;
* Complementary sources that may support identification of relevant vulnerabilities, where relevant, for example technical research papers, conference papers and other publicly available security research.
**Activities:**
1. Review the product documentation, component inventory, bill of materials, or equivalent information to identify the elements contained in the product (which may include software, firmware, or hardware elements, as applicable) and their relevant versions or patch levels, where available.
2. Perform vulnerability scanning, where technically feasible, on the product or relevant components to identify candidate vulnerabilities affecting elements contained in the product.
3. Assess, in accordance with prEN 40000-1-3 [X], the vulnerabilities identified through correlation of scanning results, product identification information, vendor advisories, and recognized public vulnerability sources.
4. For each identified known exploitable vulnerability, review the vulnerability assessment and verify whether it demonstrates that the vulnerability is not exploitable in the product:
5. Where the treatment of an identified known exploitable vulnerability relies on user guidance, review the user guidance and verify that it specifically addresses the conditions to prevent exploitation.
6. Verify that no identified known exploitable vulnerability affecting the product remains without:
* a vulnerability assessment demonstrating non-exploitability in the product; or
* specific required user guidance to prevent exploitation.
**Verdict:**
* Pass: Known exploitable vulnerabilities affecting the product are identified, and each such vulnerability is covered either by a vulnerability assessment demonstrating non-exploitability in the product, or by specific user guidance preventing exploitation.
* Fail otherwise.
**Supporting Evidence:**
* [SCAN] Vulnerability scanning results, including the tools and vulnerability databases used with snapshot date information.
* [ADVISORY] Recognized public vulnerability sources, vendor advisories, and product identification information used in the assessment.
* [ANALYSIS] Vulnerability assessment records and conclusions produced in accordance with prEN 40000-1-3 [X].
* [GUIDANCE] Product user guidance relied upon to prevent exploitation, where applicable.
## 6.4 Secure by default configuration
## 6.5 Security updates
### 6.5.1 SU_UPDATE-1
**Objective:** Prevent exploitation of known exploitable vulnerability<br/>
**Preparation:**
1. Examine public or private vulnerability information sources and select a recently fixed vulnerability (preferably the most recently fixed).
**Activities:**
1. On a new product, carry out the initial secure update.
2. Scan the product to see if a recently fixed vulnerability has been fixed on the product.
3. Examine the documentation for the required info.
**Verdict:**
1. Pass if the secure update completes successfully
2. and the most recently fixed vulnerability is fixed
3. and the documentation includes all the required information
4. and the instructions are noting the custom requirements of the application, if any
5. and the interfaces connected during the update procedure are known
6. and the integrity of the content is ensured during the update procedure.
7. Fail otherwise.
**Supporting Evidence:**
1. Documentation of vulnerability handling
1. Documentation of how to securely update the product
1. The report for the selected vulnerability
1. Description of how to scan for the vulnerability
1. Log of vulnerability scan results
### 6.5.2 SU_UPDATE-2
**Objective:** Responsibility of OS level updgrades can be elsewhere outside of the system control.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
**Verdict:**
1. Pass if cross referencing OS and Application update instructions makes it possible to maintain High Availability requirements defined in the technical documentation.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.5.3 SU_UPDATE-3
<mark>Weak text</mark>
**Preparation:** Program a test source providing an authentic and integrity correct update package.<br/>
**Activities:**
* Operate the test update server.
* Study the technical documentation.
* If needed activate the update mechanism and check whether the mechanism is configurable.
* Check if the update mechanisms can be configured to check itself for updates, conduct the update on trigger, or runs at first use.
* Configure the update mechanisms with respect to point in time of conduct.
**Verdict:**
* The technical documentation describes the update mechanism in sufficient practical detail to conduct the update.
* The test update is operated as configured on action, prior, or as part of the first use.
* The test update was operated as configured with respect to the point of time of conduct.
**Supporting Evidence:**
* References to document sections.
* Screenshots from the update configurations and of the corresponding conducts.
