Update Clause 5.2/6.2 Appropriate cybersecurity to revised structure (was 5.2.2) (5b59a8fe) · Commits · STAN4CRA / EN 304 625 Network Interfaces

EN-304-625.md

+94 −138

Original line number	Diff line number	Diff line
		@@ -236,6 +236,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`
		@@ -827,7 +828,33 @@ The term "cybersecurity-relevant" is intended to allow the assessor to exclude s

		<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.1 ER-NKEV: No known exploitable vulnerabilities at first use
		## 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-FZ95, MI-BTIN) Resilience to potentially untrusted inputs

		#### 5.2.2.1 Requirement

		All cybersecurity-relevant parts of the product shall implement methods to validate untrusted inputs and mitigate the effects thereof.

		#### 5.2.2.2 Applicability

		TODO

		## 5.3 No known exploitable vulnerabilities

		#### 5.2.1.1 Cybersecurity requirement

		@@ -909,143 +936,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
		@@ -1964,6 +1854,72 @@ Some sources for compliling these lists may include, where available:
		* manual testing
		* custom test programs

		## 6.2 Appropriate level of cybersecurity

		### 6.2.1 Overview

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

		### 6.2.2 REQ-ALC-01 (MI-FZ95, MI-BTIN) Resilience to potentially untrusted inputs

		#### 6.2.2.1 Objective

		Secure design and development.

		#### 6.2.2.2 Preparation

		Identify all sources of untrusted input to the product. For each source of untrusted input, review for fields in the format, values, or input sequences that could affect:

		* calculation of memory accesses (length, index, hash table lookup values, packet reassembly, etc.)
		* availability of product resources (buffer length, number of packet descriptors, fragmented packets, CPU-intensive operations, etc.)
		* incrementing or decrementing of internal counters (packet counters, event counters, etc.)
		* consistency or validity of internal data structures

		For each input, construct a series of inputs that tests, if technically possible:

		* maximum and minimum valid input values and the next above and below
		* maximum and minimum possible input values and next possible above and below
		* a representative selection of other valid and invalid values
		* potential overflow or underflow of internal counters
		* values that are inconsistent with other values in the input
		* indexes that are inconsistent or invalid with the data indexed
		* values that, if used, would harm product availability

		Identify the acceptable behavior(s) of the product in response to the input that would protect its cybersecurity. Identify a method of sending these inputs to the product and recording the responses. Set up this testing environment.

		#### 6.2.2.3 Activities

		For every input, send the input to the product and record its response.

		#### 6.2.2.4 Verdict

		PASS if for every identified input, the product responds in a manner consistent with the identified acceptable behavior.

		Otherwise FAIL

		#### 6.2.2.5 Evidence

		* List of sources of untrusted input
		* Analysis of sources of untrusted input for specified inputs
		* Sufficiency analysis of analysis of untrusted inputs
		* List of test inputs
		* Logs of testing inputs and recording behavior
		* Sufficiency analysis of testing logs

		#### 6.2.2.6 Guidance

		Assessment can often be done with minimal effort using commonly available fuzzer or security testing tools. A common approach is writing a simple shell script (that becomes a more complicated shell script until one day you realized that you should just use an existing tool). It can also be done by hand.

		Acceptable behaviors might include:

		* Crashing and restarting
		* Terminating a thread
		* Rejection of input and returning an error
		* Silent discard of input
		* Correction of input
		* Dropping a packet and incrementing an error counter
		* Emitting a notification when a counter rolls over

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