@@ -239,50 +239,6 @@ See [5.2.6 Role based authorisation](#526-role-based-authorisation)
### 5.3.4 Secure updates
System updates are essential to keep the number of known vulnerabilities at a minimum.
A wide variety of threats related to secure update may appear both prior to an update and during the update process.
Pre-update acquisition & distribution secure update threats:
- Tampered update packages during storage or transmission
- Update retrieved from an untrusted or unauthenticated source
- Use of revoked or compromised signing keys
Threats to secure update during installation & execution:
- Authenticity or integrity verification bypass
- Downgrade to a older version
- Rollback protections bypass
- Loss of availability if update fails or is interrupted
Therefore, application of updates needst to be performed in a manner that maintains the integrity of the software state and, where relevant, supports the availability objectives defined for the product keeping the system within the set [5.3.8 High Availability](#538-high-availability) targets.
Requirements:
-**[REQ-UPDATES-0]:** Authenticity and integrity of update package shall be verifiable using a cryptographic digital signature verification prior to installation.
-**[REQ-UPDATES-1]:** The product shall maintain a monotonic version counter or equivalent mechanism to prevent installation of updates with an older version.
-**[REQ-UPDATES-2]:** If the product supports intentional rollback, invoking action shall require explicit authorisation and shall be based on separately versioned and signed rollback metadata.
-**[REQ-UPDATES-3]:** The product shall provide a mechanism to restore the system operational state after a failed update.
-**[REQ-UPDATES-4]:** The product shall automatically recover from a failed update and resume operation if applicable.
-**[REQ-UPDATES-5]:** The product shall inform the system user about update availability if applicable.
-**[REQ-UPDATES-6]:** The product shall track the relevant component versions of the product and the managed devices if applicable.
-**[REQ-UPDATES-7]:** The product shall log start and finish of the update download if applicable.
-**[REQ-UPDATES-8]:** The product shall perform an automatic update of the product and the managed devices if the operative context and the application design allows this to happen within the defined availability targets.
-**[REQ-UPDATES-9]:** The product shall provide a way for the system user to postpone or re-schedule the application update.
-**[REQ-UPDATES-10]:** Automatic updates shall be on by default if applicable.
These requirements are generally binding, and there is no low-medium-high tiering available.
The requirements REQ-UPDATES-4 to 8 and 10 are conditional due to different operative management and ownership models.
A cellphone that is connected to a corporate inventory management often has it's own update manager, and the device does not rely on the centralised control.
Similary in a modern cluster deployment, the application can not update itself, as the control is in the cluster, which makes the provisioning, scheduling and network shaping decisions for all applications running in the same context.
Applying automatic updates are also subject to the operative environment design.
> Example: The cluster design might not have the capasity to provison the extra workload needed to make a seameless trasfer of application functions as intentend by the product. Availability of the capasity might require coordination outside of the update automation.
Distributed application design and delay lines built with buffers might tolerate partial downtime of individual components and services, but as the workload scheduling control can be outside of the proruct context.
<mark>Add reference to operative model when moving to the new structure.</mark>
### 5.3.5 Logging
In many product deployments, privileged users manage monitoring tasks also with the analysis of product logging records.
@@ -593,63 +549,6 @@ DDoS mitigations:
1. References to to documentation sections.
#### 6.2.5.0 REQ-SBOM-0
**Objective:** To make clear what part of the system to update, the source of the dependency should be understandable.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
**Verdict:**
1. Pass if system dependencies and application dependencies are clearly separated.
1. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
#### 6.2.5.1 REQ-SBOM-1
**Objective:** Clarify machine readable SBOM listings that are essential for the vulnerability management.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Study the SBOM.
**Verdict:**
1. Pass if provided SBOM identifiers are unique
1. and recognised in the industry
1. and cross referable to known vulnerability databases.
1. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
#### 6.2.5.2 REQ-SBOM-2
**Objective:** Prevent the software deliverables to erode over time.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Study the SBOM.
3. Check that the SBOM considers the update of components, its dependencies and that it allows to identify the source.
**Verdict:**
1. Pass, if the listed SBOM entries is consistent with the corresponding real NMS components
2. and the update frequency has a possibility to match the expected changes in the deployment complexity.
@@ -1104,6 +1104,49 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
***SU_UPDATE-2** The product shall have divorserd OS and Application update procedures which makes it possible to obtain the set High Availability targets when the operational environment makes this possible.
***SU_UPDATE-3** The product shall ensure that the product can be updated at the time of first use to address all known exploitable vulnerabilities which were discovered after the product's placement on the market and before that first use.
System updates are essential to keep the number of known vulnerabilities at a minimum.
A wide variety of threats related to secure update may appear both prior to an update and during the update process.
Pre-update acquisition & distribution secure update threats:
* Tampered update packages during storage or transmission
* Update retrieved from an untrusted or unauthenticated source
* Use of revoked or compromised signing keys
Threats to secure update during installation & execution:
* Authenticity or integrity verification bypass
* Downgrade to a older version
* Rollback protections bypass
* Loss of availability if update fails or is interrupted
Therefore, application of updates needst to be performed in a manner that maintains the integrity of the software state and, where relevant, supports the availability objectives defined for the product keeping the system within the set [5.3.8 High Availability](#538-high-availability) targets.
Requirements:
***SU_UPDATES-0:** Authenticity and integrity of update package shall be verifiable using a cryptographic digital signature verification prior to installation.
***SU_UPDATES-1:** The product shall maintain a monotonic version counter or equivalent mechanism to prevent installation of updates with an older version.
***SU_UPDATES-2:** If the product supports intentional rollback, invoking action shall require explicit authorisation and shall be based on separately versioned and signed rollback metadata.
***SU_UPDATES-3:** The product shall provide a mechanism to restore the system operational state after a failed update.
***SU_UPDATES-4:** The product shall automatically recover from a failed update and resume operation if applicable.
***SU_UPDATES-5:** The product shall inform the system user about update availability if applicable.
***SU_UPDATES-6:** The product shall track the relevant component versions of the product and the managed devices if applicable.
***SU_UPDATES-7:** The product shall log start and finish of the update download if applicable.
***SU_UPDATES-8:** The product shall perform an automatic update of the product and the managed devices if the operative context and the application design allows this to happen within the defined availability targets.
***SU_UPDATES-9:** The product shall provide a way for the system user to postpone or re-schedule the application update.
***SU_UPDATES-10:** Automatic updates shall be on by default if applicable.
These requirements are generally binding, and there is no low-medium-high tiering available.
The requirements REQ-UPDATES-4 to 8 and 10 are conditional due to different operative management and ownership models.
A cellphone that is connected to a corporate inventory management often has it's own update manager, and the device does not rely on the centralised control.
Similary in a modern cluster deployment, the application can not update itself, as the control is in the cluster, which makes the provisioning, scheduling and network shaping decisions for all applications running in the same context.
Applying automatic updates are also subject to the operative environment design.
> Example: The cluster design might not have the capasity to provison the extra workload needed to make a seameless trasfer of application functions as intentend by the product. Availability of the capasity might require coordination outside of the update automation.
Distributed application design and delay lines built with buffers might tolerate partial downtime of individual components and services, but as the workload scheduling control can be outside of the proruct context. See [4.3.2 Physical/Hardware environment](#432-physicalhardware-environment) for more.
