Commit 77369e71 authored by Valerie Aurora's avatar Valerie Aurora
Browse files

Update Clause 5.3/6.3 No known exploitable vulnerabilites to revised structure (was 5.2.1) 

Updated with simplified requirements adapted from VPN, add guidance on
the meaning of the terms as defined by the CRA and draft CRA guidance.

closes #82, closed #83, closes #85, closes #92, closes #112, closes #129
closes #141
parent c6c36d79

EN-304-625.md

+64 −61
Original line number Diff line number Diff line
@@ -927,87 +927,51 @@ TODO 


TODO



### 5.2.1 ER-NKEV: No known exploitable vulnerabilities at first use

## 5.3 No known exploitable vulnerabilities



#### 5.2.1.1 Cybersecurity requirement

### 5.3.1 Overview



Recognizing 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 vulnerabilities both when first made available and when first used by a consumer, the product shall be able to be updated at the time of first use to address all known exploited vulnerabilities which were discovered after the product's placement on the market and before that first use.

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a).



#### 5.2.1.2 MI-KEVD: Documentation for secure update before or during first use

<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>



The product shall be accompanied by documentation describing how the product can be securely updated, including the instructions to update the product, for instance through the system bus interface, prior to or as part of its first use. 

That documentation includes protocols and command to use.

### 5.3.2 REQ-KEV-01 (MI-KEVT) No known exploitable vulnerabilities



  * Applicability: Product design is capable to perform firmware update

  * Reference: ER-NKEV

  * Objective: Prevent exploitation of known exploited vulnerabilities at first use

  * Preparation: 

    1. Examine public or private vulnerability information sources and select a representative sample of recently fixed vulnerabilities for the product and for its dependencies

    2. Examine manufacturer's product update information

  * Activities: On a new product, scan the product to see if a recently fixed vulnerabilities has been fixed on the product, and examine the documentation for the required info

  * Verdict: The secure update completes successfully, the sample set of vulnerabilities is fixed, and the documentation includes all the required information => PASS, otherwise FAIL

  * Evidence: Documentation of vulnerability handling, documentation of how to securely update the product, the report for the selected vulnerabilities, description of how to scan for the vulnerabilities, log of vulnerability scan results

#### 5.3.2.1 Requirement



#### 5.2.1.3 MI-KEVA: Automatic secure update before or during first use

**REQ-KEV-01 (MI-KEVT)** The product shall have no known exploitable vulnerabilities at the time of placement on the market, with the exception of known exploitable vulnerabilities that satisfy at least one of the following criteria:



The product shall implement automatic secure update by default before or during first use.

 * the vulnerability became known to the manufacturer within the 14 days prior to placement on the market, or

 * the vulnerability became known to the manufacturer within the time period permitted before addressing and remediation of the vulnerability as described in the vulnerability handling procedure for the product prior to placement on the market, or

 * the vulnerability became known to the manufacturer within the time period permitted before public disclosure as described in the vulnerability handling procedure for the product prior to placement on the market, or

 * the vulnerability has associated publicly-available documentation explaining the risk and how that risk has been mitigated



  * Applicability: Product design is capable to perform automatic firmware update

  * Reference: ER-NKEV

  * Objective: Prevent exploitation of known exploited vulnerabilities at first use

  * Preparation: Examine public or private vulnerability information sources and select a representative sample of recently fixed vulnerabilities for the product and for its dependencies

  * Activities: Follow the instructions to install and use the product for the first time, scan the product to see if a recently fixed vulnerabilities has been fixed on the product, and examine the documentation for the required info

  * Verdict: The secure update completes successfully, the sample set of vulnerabilities is fixed, and the documentation includes all the required information => PASS, otherwise FAIL

  * Evidence: Documentation of vulnerability handling, documentation of how to securely update the product, the report for the selected vulnerabilities, description of how to scan for the vulnerabilities, log of vulnerability scan results

#### 5.3.2.2 Applicability



#### 5.2.1.4 MI-KEVM: Documentation of mitigation of known exploitable vulnerabilities



The product\'s development and release process shall include a process to document known exploitable vulnerabilities in the product and their fixes or mitigations. The documentation for this process shall be compliant with the process described in prEN 40000-1-3 [\[3\]](#_ref_3). The product shall be compliant with this cybersecurity requirement if it:



1. has no known exploitable vulnerabilities

1. has known exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

1. for each detected vulnerability, has documentation of how the risk has been mitigated

TODO



  * Reference: ER-NKEV

  * Objective: Prevent exploitation of known exploited vulnerabilities at first use

  * Preparation: Compile a list of known exploitable vulnerabilities in the product and its components

  * Activities: Compare the generated list of known exploitable vulnerabilities with the documentation of the known exploitable vulnerabilities that have been fixed or mitigated in the product

  * Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or documentation cybersecurity requirement => PASS, otherwise FAIL

  * Evidence: Documented vulnerability handling policy, list of vulnerabilities, documentation of mitigations or age of vulnerability, correlation of list of vulnerabilities with documentation of mitigations or age of vulnerability

#### 5.3.2.3 Guidance



#### 5.2.1.5 MI-KEVT: Testing for known exploitable vulnerabilities

To demonstrate compliance, the manufacturer may rely on manual security testing (e.g., penetration testing), automated vulnerability scanners, or a combination of both, depending on what is most comprehensive and technically feasible for the product.



The product shall be tested for all known exploitable vulnerabilities to demonstrate that each has been mitigated. The product shall be compliant with this cybersecurity requirement if it:

A vulnerability may become known but be determined to be unexploitable, then later discovered to be exploitable. Thus the "exploitable" part of "known exploitable vulnerability" should be based on the determination of its exploitability at the time of placement on the market.



1. has no known exploitable vulnerabilities

1. has known exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

1. for each tested vulnerability, the test result shows that the vulnerability has been mitigated

<mark>Editor's note:



  * Reference: ER-NKEV

  * Objective: Prevent exploitation of known exploited vulnerabilities at first use

  * Preparation: Compile a list of known exploitable vulnerabilities in the product and its components, compile a list of known exploitable vulnerabilities that will be tested, collect tests for each one

  * Activities: On a new product, carry out a secure update, run the tests, and compare the results with the generated list of known exploitable vulnerabilities

  * Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or mitigation cybersecurity requirement => PASS, otherwise FAIL

  * Evidence: Documented vulnerability handling policy, list of vulnerabilities, test results for each vulnerability or documentation of age of vulnerability, correlation of list of vulnerabilities with test results or documentation of age of vulnerability

CRA [\[i.1\]](#_ref_i.1) Article 3 (41) defines an exploitable vulnerability as a "vulnerability that has the potential to be effectively used by an adversary under practical operational conditions." A manufacturer may use its cybersecurity risk assessment of the product for its intended purpose and use case to assist in making the determination whether a vulnerability is exploitable.



#### 5.2.1.6 MI-SCAN: No easily scannable known exploitable vulnerabilities

CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a) requires that products are free from known exploitable vulnerabilities at the time of placement on the market. CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 2 (2) specifies that manufacturers address and

remediate vulnerabilities without delay.



If automatable and freely-usable vulnerability scanners are available for the product, then the product shall satisfy the following with respect to the three (or fewer, if fewer than three are available) most comprehensive of such scanners:

CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 2 (5) specifies that manufacturers put in place and enforce a policy on coordinated vulnerability disclosure.



1. has no vulnerabilities discovered by scans

1. has discoverable exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

1. for each detected vulnerability, has publicly available documentation explaining how the risk has been mitigated

The CRA Draft Guidance 9.2.2 says:



  * Reference: ER-NKEV

  * Objective: Prevent exploitation of known vulnerabilities at first use

  * Preparation: Select a set of tools meeting the cybersecurity requirements

  * Activities: On a new product, carry out a secure update, run the tools on the product, and examine the documentation for any reported vulnerabilities

  * Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or documentation cybersecurity requirement => PASS, otherwise FAIL

  * Evidence: Documented vulnerability handling policy, list of vulnerability scanners selected, reports from each scanner, correlation of reports of discovered vulnerabilities with documentation of mitigations

> \214. Furthermore, the obligation for manufacturers to comply with then essential cybersecurity requirements set out in Part I of Annex I applies at the moment of placement on the market, in accordance with Article 13(1). In practice, it may be the case that new potentially exploitable vulnerabilities are discovered during the final stages of the product development lifecycle, including shortly before it enters the distribution chain (and is therefore placed on the market).



#### 5.2.1.7 Mapping of mitigations to risk factors and security profiles

> \215. As the obligation to place products on the market without known exploitable vulnerabilities is a risk-based obligation, it falls upon the manufacturer to determine whether, on the basis of the cybersecurity risk assessment, the product can be securely placed on the market, in compliance with the CRA. Alternatively, the manufacturer may determine that a new vulnerability that may have become known needs to be fixed before the product can be placed on the market. In making that determination, manufacturers should take into account the severity, exploitability and potential impact of the vulnerability, as well as the risks arising for the product itself once in use. In any case, once a product is placed on the market, the manufacturer remains subject to the obligation to handle vulnerabilities effectively and in accordance with the vulnerability handling requirements set out in Part II of Annex I.



See clause 5.3 for which mitigations are necessary for which security profiles and clause C.4 for the rationale.

</mark>



### 5.2.4 ER-MINI: Minimize impact on other devices and services
@@ -2031,6 +1995,45 @@ Method 4: 


The test scope should be selected based on a risk-based approach. This includes considering the product's intended use and prioritising functions and interfaces that process untrusted inputs, provide access to security-relevant assets, or execute critical operations, since memory access errors in such areas may have a greater cybersecurity impact.



## 6.3 No known exploitable vulnerabilities



### 6.3.1 Overview



This clause provides assessment for the requirements in 5.14 relating to CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a).



### 6.3.2 REQ-KEV-01 (MI-KEVT) No known exploitable vulnerabilities



#### 6.3.2.1 Objective



Prevent exploitation of known exploitable vulnerabilities.



#### 6.3.2.2 Preparation



Using the product's SBOM and relevant publicly accessible vulnerability databases (e.g. [GCVE](https://gcve.eu), [EUVD](http://euvd.enisa.europa.eu)), compile a list of target components and potential known exploitable vulnerabilities. Select the appropriate testing methodology (e.g., the most comprehensive automated scanners available, or a manual penetration test plan) to verify the mitigation of these vulnerabilities.



#### 6.3.2.3 Activities



On a new product, carry out a security update, run the tests, and compare the results with the generated list of known exploitable vulnerabilities.



#### 6.3.2.4 Verdict



PASS if **any** of the following are fulfilled:



* No vulnerabilities found, or

* all reported vulnerabilities satisfy either the elapsed time since discovery or mitigation requirements.



Otherwise FAIL



#### 6.3.2.5 Evidence



* Documented vulnerability handling policy

* Product SBOM

* List of testing tools used or manual test plan

* Test reports/scan results

* Correlation of discovered vulnerabilities with:

  * documentation of mitigation, or

  * elapsed time since discovery of vulnerability.



### 6.2.13.4 MI-FDRP assessment



**[MI-FDRP]** Verify the product performs ordered validity checks on incoming packets and drops invalid packets before further processing.