@@ -1167,28 +1167,26 @@ Threats to secure update during installation & execution:
* 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.
Therefore, application of updates needs 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.
***SU_UPDATES-4:** Authenticity and integrity of update package shall be verifiable using a cryptographic signature verification prior to installation.
***SU_UPDATES-5:** The product shall maintain a monotonic version counter or equivalent mechanism to prevent installation of updates with an older version.
***SU_UPDATES-6:** The product shall provide a mechanism to restore the system to the operational state after a failed update.
***SU_UPDATES-7:** The product shall provide a way for the system user to postpone or re-schedule the application update.
The requirements **SU_UPDATES-8** to **13** 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.
***SU_UPDATES-8:** If the product supports intentional rollback, invoking action shall require explicit authorisation and an auditable event is emitted with rollback metadata.
***SU_UPDATES-9:** The product shall automatically recover from a failed update and resume operation if applicable.
***SU_UPDATES-10:** The product shall inform the system user about update availability if applicable.
***SU_UPDATES-11:** The product shall track the relevant component versions of the product and the managed devices if applicable.
***SU_UPDATES-12:** The product shall log start and finish of the update download if applicable.
***SU_UPDATES-13:** 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-14:** Automatic updates shall be on by default if applicable.
Applying automatic updates is 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.
@@ -2022,6 +2020,290 @@ Verify that:
* References to document sections.
* Screenshots from the update configurations and of the corresponding conducts.
### 6.5.4 SU_UPDATE-4
**Objective:** Update packages are not altered.<br/>
**Preparation:**
1. Study the technical documentation.
**Activities:**
1. Fetch a product update package from upstream source.
2. Study the provided update package.
**Verdict:**
1. Pass, if package signature is valid and the used signature is implemented according to Annex K.
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.5.5 SU_UPDATE-5
**Objective:** Prevent accidental installation of older packages.<br/>
1. Pass, if there are no out of order version numbering used within the implemented scheme.
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.5.6 SU_UPDATE-6
**Objective:** Reduce the outages due to failed update.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Start an update;
2. Kill the process performing the update or otherwise, from the system side, interrupt the process unexpectedly;
3. Perform the instructed measures.
**Verdict:**
1. Pass, if system is able to recover from the test.
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.5.7 SU_UPDATE-7
**Objective:** Protect the high availability of the system in peak usage hours and prevent of installation of updates that are known to break services.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Study the interface how the post-pone of an update works.
**Verdict:**
1. Pass, if system user has control over when the update is made.
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.5.8 SU_UPDATE-8
**Objective:** Rollback operations are auditable.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Perform a rollback to a previous version.
2. Observe the emitted audit record.
**Verdict:**
1. Pass, if rollback is done successfully
2. and audit event is emitted.
3. 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.5.9 SU_UPDATE-9
**Objective:** Protect the availability of the product.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Initiate update;
2. Interrupt the update by killing the active update process.
**Verdict:**
1. Pass, if system recovers to fully functional state.
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.5.10 SU_UPDATE-10
**Objective:** Product user has knowledge about the possiblity to update.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Study the system and the nofication mechanism.
**Verdict:**
1. Pass, if the nofication mechanism functions as expected.
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.5.11 SU_UPDATE-11
**Objective:** Product user is has an understandment of what versions are installed.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Investigate the version information.
2. Cross-reference to technical documentation to understand the relevancy of the component.
**Verdict:**
1. Pass, if no importan components are left out form the versioning.
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.5.12 SU_UPDATE-12
**Objective:** Product user understand the status of the system.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Investigate the system log trail about updates.
2. Initiate a download if not performed.
**Verdict:**
1. Pass, if the logs show the update package being transferred to 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.5.13 SU_UPDATE-13
**Objective:** Ensure the latest fixes are applied to the product.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Launch a old version of the product.
3. Study the technical documentation.
**Activities:**
1. Observe the automation performing the update.
**Verdict:**
1. Pass, if update happens without user interaction.
2. Fail otherwise.
> NOTE: System time distortion is allowable for testing purposes.
**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.5.14 SU_UPDATE-14
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Investigate the configuration options.
**Verdict:**
1. Pass, if automatic updates are turned on by default.
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.
