@@ -1379,22 +1379,21 @@ In this case, the managed device is responsible for authorizing the product base
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (f).
***INT_CONF-1** The product shall interface only through a [5.7.2 Secure channel](#572-secure-channel).
### 5.8.1 Configuration integrity
***INT_CONF-1** The product shall interface only through a [5.2.1 Secure channel].
***INT_CONF-2** Where the product distributes or makes available configuration to managed devices
* The product shall ensure that the configuration is protected against unauthorized modification and disclosure;
* The product shall ensure that only the intended managed device can obtain and apply the relevant configuration;
* The prodcut shall ensure that the device can verify the integrity of the configuration.
***INT_CONF-3** The configuration interfacing design shall enable the managed device to verify the authenticity of the product.
***INT_CONF-2** Where the product distributes or makes available configuration to managed devices the product shall ensure that
* the configuration is protected against unauthorized modification and disclosure;
* only the intended managed device can obtain the relevant configuration;
* the device can verify the integrity of the configuration.
***INT_CONF-3** The configuration interfacing design shall enable the managed device to cryptographically verify the authenticity of the product.
### 5.8.2 Cryptographic key intialisation and rotation
***INT_ROTATE-1** The product shall support and implement a on-demand rotation of cryptographic keys.
***INT_ROTATE-2** The product shall support the initialisation of trust.
***INT_ROTATE-3** The product shall support cryptographic mechanisms used to accept managed elements to the network.
***INT_ROTATE-4** The product shall support a method to replace or update the cryptographic keys in the system and in the managed elements the product has control over.
***INT_ROTATE-5** The prodcut shall not trust expired keys.
***INT_ROTATE-2** The product shall support the initialisation of trust with the managed elements.
***INT_ROTATE-3** The prodcut shall not trust expired keys.
Trust is inherited from a parenting system or from an existing entity.
Rollout automation and zero touch configuration approaches rely on concepts, which are not nessesarily well established, and vendor specific.
@@ -1447,30 +1446,24 @@ These are example data for which public statistics are available [i.17].
For **low** risk:
***AP_HA-0** The expected availability shall be defined for each relevant product component.
***AP_HA-1** System updates and changes shall not be considered as exceptions in the product general availability definition.
***AP_HA-6** The product shall emit security events about detected issues that affects the high availability.
***AP_HA-2** The product shall emit security events about detected issues that affects the availability of the product and its provided services.
For **medium** risk:
***AP_HA-2** The product shall tolerate loss of resources within the limits of the defined availability.
***AP_HA-6** The product shall minimise the impact to other systems when anomalies occur.
***AP_HA-3** Recovery capabilities shall be sufficiently implemented to match the expected availability targets.
<mark>REQ-HA-3 needs documentation trick for: "made available in the technical documentation"</mark>
***AP_HA-3** The product shall tolerate loss of resources within the limits of the defined availability.
***AP_HA-4** The product shall minimise the impact to other systems when anomalies occur.
For **high** risk:
DDoS mitigations:
***AP_HA-5** The product shall implement coordinated brute‑force and overload protection mechanisms that not only detect excessive authentication attempts or inbound traffic surges but also enforce active mitigation actions including, but not limited to connection throttling, temporary IP blocking, message buffering, QoS parameterisation.
***AP_HA-6** The product shall implement recovery or failover mechanisms.
***AP_HA-7** If the product can be exposed to DDoS, the product shall implement DDoS mitigations like:
* port switching
* traffic redirections
* service termination for a recommended and configurable time
* disabling of the affected ports and interfaces for a configurable time
***AP_HA-4** The prodct shall implement coordinated brute‑force and overload protection mechanisms that not only detect excessive authentication attempts or inbound traffic surges but also enforce active mitigation actions including, but not limited to connection throttling, temporary IP blocking, message buffering, QoS parameterisation.
***AP_HA-5** The product shall implement recovery or failover to mitigate overload attempts.
***AP_HA-8** If the product can be exposed to DDoS, the product shall implement DDoS mitigations like listed above.
## 5.11 Non-interference
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (i).
@@ -1907,8 +1900,6 @@ Verify that:
## 6.7 Confidentiality protection
### 6.7.2 Secure channel tests
#### 6.7.2.1 CON_CHANNEL-1
**Objective:** The implementation and operation follows the Agreed Cryptographic Mechanisms specification and the Annex K.<br/>
@@ -1954,7 +1945,88 @@ Verify that:
## 6.8 Integrity protection
### 6.8.2.1 INT_ROTATE-1
### 6.8.1 INT_CONF-1
**Objective:** Protect the management actions and the interraction with the system enabling only secure channels.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
**Activities:**
1. Study the technical documentation.
2. Study the product and all available interfaces in operation.
3. Monitor all network activity.
**Verdict:**
1. Pass, if secure channel is used in interfacing with the system.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.8.1.1 INT_CONF-2
**Objective:** Prevent the use of old keys.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Have a managed element connected to the system.
3. Have additional managed elements configured in the system.
**Activities:**
1. Study the technical documentation.
2. Initiate configuration transfer to the managed element.
3. Repeat transfer, and distord the configuration if it is possible by editing the content while keeping a valid schema.
**Verdict:**
1. Pass, and the documented configuration transfer upholds the integrity of the configuration
2. and if the managed element does not have access to other configurations configured in the system
3. the device detects the alteration of configuration when it is possible to perform.
1. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.8.1.3 INT_CONF-3
**Objective:** Prevent the use of old keys.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Have a managed element connected to the system.
**Activities:**
1. Study the technical documentation.
2. Study the connection towards the product from the managed element side.
**Verdict:**
1. Pass, if the element can cryptographically verify the product.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.8.2 Cryptographic key intialisation and rotation
#### 6.8.2.1 INT_ROTATE-1
**Objective:** When employees and administrators roles change, the related keys shall change accordingly.<br/>
**Preparation:** None<br/>
@@ -1965,7 +2037,7 @@ Verify that:
**Verdict:**
1. Pass, if key rotation can be made on demand,
1. Pass, if key rotation can be made on demand
2. and the instructed rotation policy is fit for the foreseeable use of the product
3. and the keys can be initialised when the product is taken into a use for a firts time or after a reset to factory settings.
4. Fail otherwise.
@@ -1974,6 +2046,53 @@ Verify that:
1. References to to documentation sections.
#### 6.8.2.2 INT_ROTATE-2
**Objective:** New devices can be initialised with the shared secrets and trust anchors.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Have a managed element to test with.
**Activities:**
1. Study the technical documentation.
2. Reset the managed element to factory defaults.
3. Attach the element into the system.
**Verdict:**
1. Pass, if managed element has the cryptographical keys and trust structures in use after the test actions.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
#### 6.8.2.3 INT_ROTATE-3
**Objective:** Prevent the use of old keys.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
**Activities:**
1. Configure the system with an expired key.
2. Reboot the necessary services.
**Verdict:**
1. Pass, if an event is emited to logs and the system operation is halted if the key is significant for the operation or the service.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
