Commit c6c36d79 authored by Valerie Aurora's avatar Valerie Aurora
Browse files

Update Clause 5.2/6.2 Appropriate cybersecurity to revised structure (was 5.2.2) 

Update memory safety requirements based on VPN with extensive
modifications. Remove the more advanced memory safety requirements.
Combine the memory error detection mitigations into one requirement.
Incorporate resolutions to many comments.

closes #86, closes #126, closes #130, closes #132, closes #134
closes #144, closes #152
parent 7fa7d1f4

EN-304-625.md

+178 −138
Original line number Diff line number Diff line
@@ -237,6 +237,7 @@ For the purposes of the present document, the following abbreviations apply: 
`ADM   Availability and Skill of Administration`  

`API   Application Programming Interface`  

`AHHS  Harm to Host System Via Unauthorized Access Through the Network`  

`ALC   Appropriate level of cybersecurity`  

`AS    Assumption`  

`AUTH  Authentication`  

`AVAI  Availability`
@@ -324,7 +325,6 @@ For the purposes of the present document, the following abbreviations apply: 
`SDTR  Secure Data Read and Transfer`  

`SFT   Sensitivity of Data Stored`  

`SSCA  Static Source Code Analysis`  

`SSDD  Secure Design and Development`  

`SUAP  Automatic Secure Update Via Product`  

`SUAO  Automatic Secure Update Provided by Operational Environment`  

`SUDC  Documentation of Secure Update`
@@ -880,6 +880,53 @@ The term "cybersecurity-relevant" is used to allow the assessor to exclude some 


<mark>Editor's Note: If there is a matrix mapping the use cases to the technical requirements of the standard, it should be inserted in this clause. Alternatively, there can be such a matrix/mapping in each subclause below.</mark>



## 5.2 Appropriate level of cybersecurity



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



<mark>Editor’s Note: Please refer to point 7.2 of the Commission CRA draft legal guidance for this essential requirement.</mark>



<mark>Editor’s Note: It is not adequate to normatively reference prEN 40000-1-2 (PT1) to fulfil this requirement.</mark>



### 5.2.1 Overview



#### 5.2.1.1 CRA Relevance



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



In alignment with the Cyber Resilience Act Annex I Part I (1), this section addresses overarching risks and mitigations regarding the secure design and development of the product that are not specifically treated by other categorical essential requirements (such as confidentiality, access control, or security updates). The requirements herein ensure the final product itself embodies security by design.



### 5.2.2 REQ-ALC-01 (MI-SSCA) Static source code analysis for memory errors



#### 5.2.2.1 Requirement



1. **REQ-ALC-01 (MI-SSCA)-1** All cybersecurity-relevant parts of the product shall be checked for known code patterns that produce _common memory errors_, and

2. **REQ-ALC-01 (MI-SSCA)-2** any identified memory errors or suppression of warnings shall be documented with a rationale for why it does not constitute an unacceptable risk.



> NOTE: Examples of _common memory errors_ include:

>

> * buffer overflow

> * out-of-bounds

> * use after free

> * double free

> * use of uninitialized variables

> * dereference of invalid pointer



#### 5.2.2.2 Applicability



TODO



### 5.2.3 REQ-ALC-02 (MI-FZ95, MI-BTIN, MI-IMSL) Prevent or mitigate memory errors



#### 5.2.3.1 Requirement



1. **REQ-ALC-02 (MI-FZ95)-1** The product shall prevent or mitigate _common memory errors_, and

2. **REQ-ALC-02 (MI-FZ95)-2** the product technical documentation shall record all memory errors detected with a rationale for how each error does not constitute an unacceptable risk.



#### 5.2.3.2 Applicability



TODO



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



#### 5.2.1.1 Cybersecurity requirement
@@ -962,143 +1009,6 @@ If automatable and freely-usable vulnerability scanners are available for the pr 


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



### 5.2.2 ER-SSDD: Secure design and development



#### 5.2.2.1 Cybersecurity requirement



The product shall be designed and developed in a secure manner as defined in CRA Essential Requirement 1 in Annex I. 

This section defines what additional measures needs to be taken which are not fit under other essential requirements.



#### 5.2.2.2 MI-SSCA: Static source code analysis for memory errors



All security-relevant parts of the product shall be checked for memory errors using a source code analysis tool that detects code that may produce common memory errors, such as:



* buffer overflow

* out-of-bounds

* use after free

* double free

* use of uninitialized variables

* dereference of invalid pointer



The sufficiency of the source code analysis tool and the selected manner of running it shall be documented.



All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be documented with a rationale for why it does not constitute an unacceptable risk.



  * Reference: ER-SSDD



  * Objective: Prevent unauthorized memory access



  * Preparation: None



  * Activities: Review the documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings



  * Verdict: Sufficiency documentation is acceptable, the method of running the tool is consistent with rationale, the output of source code analysis tool is consistent with the source code, all warnings or suppression of warnings have convincing documentation for why they are an acceptable risk => PASS, otherwise FAIL



  * Evidence: The documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings



#### 5.2.2.3 MI-FZ95 Runtime code coverage checking with memory access error detection



The product shall be checked for memory errors by running a tool that exercises the functions of the product in an environment that permits measuring code coverage and detecting memory access errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.



  * Reference: ER-SSDD

  * Objective: Prevent unauthorized memory access

  * Preparation: None

  * Activities: Run the tool while measuring code coverage and monitoring for memory access errors until 95% code coverage has been reached

  * Verdict: Code coverage was at least 95%, all reported memory errors are documented and justified => PASS, otherwise FAIL

  * Evidence: Logs of code coverage tool, memory error report, documentation of any memory errors



#### 5.2.2.4 MI-IMSL Implement in a memory-safe language



The product's firmware and/or software shall be implemented in a memory-safe language. Any use of unsafe memory features shall be documented to explain why they are necessary and do not present a security risk.



  * Reference: ER-SSDD, ER-MSAF

  * Objective: Prevent unauthorized memory access

  * Preparation: None

  * Activities: Review source code to determine its language and what exceptions to memory safety exist

  * Verdict: Source code is in a memory-safe language and the documentation of all uses of unsafe memory features convincingly demonstrates that each one of them does not present a security risk => PASS, otherwise FAIL

  * Evidence: Source code, documentation of unsafe memory features



#### 5.2.2.5 MI-BTIN Boundary testing of inputs that may cause memory errors



The input fields of the product that may produce memory errors in the firmware or device driver shall be identified. The product shall be boundary tested for all such inputs while monitoring for memory errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.



  * Reference: ER-SSDD, ER-MSAF

  * Objective: Prevent unauthorized memory access

  * Preparation: Identify input fields in the product that may produce memory errors

  * Activities: Run a tool that tests the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors

  * Verdict: All boundary values tested and all memory errors detected are documented and justified => PASS, otherwise FAIL

  * Evidence: Logs of boundary testing tool, memory error report, documentation of any memory errors



#### 5.2.2.6 MI-SCFS: Secure compilation flags



All security-relevant firmware and software shall be compiled with secure compilation flags and options appropriate to the target platform and language. All compilation flags used shall be documented as to their rationale, along with any exceptions or limitations. Any exceptions to the flags or warnings shall be documented as to why they do not create an unacceptable risk.



  * Applicability: Product implemented in a compiled language

  * Reference: ER-SSDD

  * Objective: Secure design and development

  * Preparation: Document which flags should be used

  * Activities: Review compilation flags, warnings, and documentation for exceptions

  * Verdict: Documentation of flags exists, all warnings and exceptions are documented => PASS, otherwise FAIL

  * Evidence: Documentation of flags, build system files, documentation of warnings and exceptions



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



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



#### 5.2.2.8 MI-MSAF-1: Stack exhaustion detection



The product shall reject writes beyond the end of the stack.



* Reference: ER-SSDD

* Objective: Prevent thread from writing beyond end of stack

* Activities: Write beyond the end of the stack

* Verdict: each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL

* Evidence: error messages, log message, or the product reboots or halts



Guidance: Two methods of exhausting stack memory include allocating a very large object on the stack, and performing an unbounded recursive function call.



#### 5.2.2.9 MI-MSAF-2: Stack linear buffer overflow detection



The product shall reject stack buffer writes that go beyond the end of the stack frame.



* Reference: ER-SSDD

* Objective: Prevent thread from writing beyond end of stack

* Activities: Write beyond the end of the stack frame

* Verdict: each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL

* Evidence: error messages, log message, or the product reboots or halts



#### 5.2.2.10 MI-MSAF-3: Array bounds checking



The product shall reject writes to fixed-size arrays that are beyond the end of the array.



* Reference: ER-SSDD

* Objective: Prevent thread from writing beyond the end of a fixed-size array

* Activities: Write beyond the end of a fixed-size array

* Verdict: each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL

* Evidence: error messages, log message, or the product reboots or halts



#### 5.2.2.11 MI-MZRO-1: Stack memory initializing



The product shall initialize all stack memory before use.



* Reference: ER-SSDD

* Objective: Prevent attacker from exploiting erroneous use of uninitialized stack memory

* Preparation: Define initialization value to be zero or one

* Activities: Sequentially call 2 functions that allocate the same amount of memory, fill the first with non-initialization values and return, and during second function call, read the stack contents back

* Verdict: Stack contents are all set to initialization value on second call => PASS, otherwise FAIL

* Evidence: Contents of stack before the first function return, contents of stack during the second function call



#### 5.2.2.12 MI-MZRO-2: Heap memory initializing



The product shall initialize all heap memory before use.



* Reference: ER-SSDD

* Objective: Prevent attacker from exploiting erroneous use of uninitialized heap memory

* Preparation: Define initialization value to be zero or one

* Activities: Allocate heap memory, fill with a non-initialization value, free it, allocate it again in a deterministic way to get the same heap region, and read back the contents

* Verdict: Memory contents are all initialization value on second call => PASS, otherwise FAIL

* Evidence: Contents of allocated memory before the free, contents of allocated memory after second allocation



### 5.2.4 ER-MINI: Minimize impact on other devices and services



#### 5.2.4.1 Cybersecurity requirement
@@ -1991,6 +1901,136 @@ Use cases, as described in clause 4.7 above, are mapped to appropriate security 


This clause details the assessment process for compliance with the cybersecurity requirements specified in clause 5 of the present document. Each assessment corresponds to a mitigation defined in clause 5 and specifies the activities, verdict criteria, and supporting evidence required to determine conformity.



## 6.2 Appropriate level of cybersecurity



### 6.2.1 Overview



The assessments contained herein seek to cover cybersecurity risks inherent in VPNs, but which are not covered by the more specifically scoped Essential Cybersecurity Requirements of Annex I Part I (2).



### 6.2.2 REQ-ALC-01 (MI-SSCA) Static source code analysis for memory errors



#### 6.2.2.1 Objective



Prevent unauthorized memory access.



#### 6.2.2.2 Preparation



Determine the appropriate static source code analysis tool and the manner of running it to verify the absence of the listed errors.



#### 6.2.2.3 Activities



* Review the source code for the product by running the selected source code analysis tool.

* Review the documentation for any warnings or suppression of warnings.



#### 6.2.2.4 Verdict



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



* The output of the source code analysis tool confirms the absence of the listed memory errors, or

* the documentation for why all warnings and suppressions constitute an acceptable risk is deemed sufficient.



Otherwise FAIL



#### 6.2.2.5 Evidence



* The source code for the product

* The output of the source code analysis tool

* Sufficiency analysis for documentation of any warnings or suppressions of warnings



### 6.2.3 REQ-ALC-02 (MI-FZ95, MI-BTIN, MI-IMSL) Prevent or mitigate memory errors



#### 6.2.3.0 Overview



This requirement can be satisfied by using one of several methods identified by unique numbers. After selecting one method, carry out the corresponding numbered step within each section of this assessment. Only one method is necessary to complete the assessment.



#### 6.2.3.1 Objective



Prevent unauthorized memory access.



#### 6.2.3.2 Preparation



None.



#### 6.2.3.3 Activities



Carry out one of the following methods. Only one method is necessary to complete the assessment.



Method 1: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product's interfaces that are normally accessible in the product's intended use. Use the code coverage tool to determine which lines of code have been exercised. Continue this process until each line of code that can reasonably be exercised deterministically by providing specific input values has been executed. For each memory error detected, document why it does not constitute an unacceptable risk.



Method 2: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product's interfaces that are normally accessible in the product's intended use. Use the code coverage tool to determine which lines of code have been exercised. Use a risk-based approach and the output of the code coverage measurements to decide when testing is complete. For each memory error detected, document why it does not constitute an unacceptable risk.



Method 3: Run a tool that tests the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors. For each memory error detected, document why it does not constitute an unacceptable risk.



Method 4: Review source code to determine its language and what exceptions to memory safety exist. For each use of memory-unsafe features or code, document why it does not constitute an unacceptable risk.



#### 6.2.3.4 Verdict



Choose the method with the same number as the method used to carry out the Activities. Only one method is necessary to complete the assessment.



Method 1: PASS if **all** of the following are fulfilled:



* all code that could be deterministically exercised by varying the inputs has been executed, and

* all reported memory errors are documented and justified.



Otherwise FAIL



Method 2: PASS if **all** of the following are fulfilled:



* the interfaces have been properly covered from a risk perspective, and

* all reported memory errors are documented and justified.



Otherwise FAIL



Method 3:



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



* All boundary values tested, and

* all memory errors detected are documented and justified.



Otherwise FAIL



Method 4:



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



* Source code is in a memory-safe language, and

* the documentation of all uses of unsafe memory features convincingly demonstrates that each one does not present a cybersecurity risk.



Otherwise FAIL



#### 6.2.3.5 Evidence



Choose the method with the same number as the method used to carry out the Activities. Only one method is necessary to complete the assessment.



Method 1:



* Logs of code coverage tool

* Memory error report

* Documentation of any memory errors



Method 2:



* Documentation of decision on how much to test using a risk-based approach

* Logs of code coverage tool

* Memory error report

* Documentation of any memory errors



Method 3:



* Logs of boundary testing tool

* Memory error report

* Documentation of any memory errors



Method 4:



* Source code

* Documentation of unsafe memory features



#### 6.2.3.6 Guidance for "risk-based approach"



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