Commit ce41c8c7 authored by Miguel Fornés's avatar Miguel Fornés Committed by Aki Braun
Browse files

Resolve "[HAS 62] 5.2.2 Unclear relationship between tool-assisted (5.2.2.6)...

Resolve "[HAS 62] 5.2.2 Unclear relationship between tool-assisted (5.2.2.6) and manual vulnerability testing (5.2.2.5). "
parent d8f2c684
Loading
Loading
Loading
Loading
+18 −32
Original line number Diff line number Diff line
@@ -67,36 +67,22 @@ The product shall implement secure update by via administrator actions before or

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

The product shall be tested for all known exploitable vulnerabilities to demonstrate that each has been mitigated. The product shall be considered conformant with this requirement if it:
In accordance with the requirement to apply effective and regular tests to the security of the product, the product shall be tested to demonstrate the absence or mitigation of known exploitable vulnerabilities. Testing shall specifically target known exploitable vulnerabilities that impact the product's architecture, platform, and the specific software components identified in the product's Software Bill of Materials (SBOM).

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
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's technology stack.

* Reference: TR-NKEV
* Objective: Prevent exploitation of known exploitable vulnerabilities at first use
* Preparation: Using the product's SBOM, relevant publically accessible vulnerability databases, private disclosures, and internal testing, compile a list of known exploitable vulnerabilities in the product and its components that will be tested. Collect tests for each one.

> NOTE: Some examples of publically accessible vulnerability databases are [GCVE](https://gcve.eu), [EUVD](http://euvd.enisa.europa.eu), and the Common Vulnerability and Exposures (CVE) List maintained by the MITRE Corporation. 

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

#### 5.2.2.6 MI-SCAN: No easily scannable known exploitable vulnerabilities
The product shall be considered conformant with this requirement if it:

If automatable 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:

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
1. has no known exploitable vulnerabilities discovered during testing,
1. has discoverable 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, or
1. for each detected vulnerability, has publicly available documentation explaining how the risk has been mitigated.

* Reference: TR-NKEV
* Objective: Prevent exploitation of known vulnerabilities at first use
* Preparation: Select a set of tools meeting the 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 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
* Objective: Prevent exploitation of known exploitable vulnerabilities
* 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.
* 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.
* Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or mitigation requirement => PASS, otherwise FAIL
* 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 age of vulnerability.

### 5.2.3 TR-SSDD: Secure software design and development

@@ -1113,7 +1099,7 @@ This clause lists all the mitigations necessary to meet requirements for each se
### 5.3.2 SP-1 Individual consumer required mitigations

  1. (KEVD or KEVA)
  1. (KEVT or SCAN)
  1. KEVT
  1. (SUVP or SUAP or SUOE or SUAO)
  1. AUTH-6
  1. CDST
@@ -1124,7 +1110,7 @@ This clause lists all the mitigations necessary to meet requirements for each se

### 5.3.3 SP-2 Privacy conscious household required mitigations

  1. (KEVT or SCAN)
  1. KEVT
  1. (SUAP or SUAO)
  1. (TRAF-1 or (TRAF-2 and TRAF-3 and TRAF-4))
  1. AUTH-1
@@ -1171,7 +1157,7 @@ This clause lists all the mitigations necessary to meet requirements for each se
### 5.3.4 SP-3 Journalist or activist required mitigations

  1. (FZ95 or BTIN or IMSL)
  1. (KEVT or SCAN)
  1. KEVT
  1. (RSET or INST or DELE)
  1. (SUAP or SUAO)
  1. AUTH-1
@@ -1235,7 +1221,7 @@ This clause lists all the mitigations necessary to meet requirements for each se
### 5.3.5 SP-4 Small organization required mitigations

  1. (FZ95 or BTIN or IMSL)
  1. (KEVT or SCAN)
  1. KEVT
  1. (NUTI-1 or TRAF-1 or (TRAF-2 and TRAF-3 and TRAF-4))
  1. (RSET or INST or DELE)
  1. (SUAP or SUAO)
@@ -1293,7 +1279,7 @@ This clause lists all the mitigations necessary to meet requirements for each se
### 5.3.5 SP-5 Large enterprise required mitigations

  1. (FZ95 or BTIN or IMSL)
  1. (KEVT or SCAN)
  1. KEVT
  1. (RSET or INST or DELE)
  1. (SUAP or SUAO)
  1. AUTH-1
@@ -1352,7 +1338,7 @@ This clause lists all the mitigations necessary to meet requirements for each se
TODO: update security analysis to better allow for this security profile's needs be met (without overprescribing)

  1. (FZ95 or BTIN or IMSL)
  1. (KEVT or SCAN)
  1. KEVT
  1. TRAF-1 or (TRAF-2 and TRAF-4)
  1. (RSET or INST or DELE)
  1. SUDC
@@ -1387,7 +1373,7 @@ TODO: update security analysis to better allow for this security profile's needs
## 5.3.X SP-7 Mesh VPN required mitigations

1. (FZ95 or BTIN or IMSL)
1. (KEVT or SCAN)
1. KEVT
1. (RSET or INST or DELE)
1. (SUAP or SUAO)
1. AUTH-1