The update of a system has to be done often enough to keep the number of known vulnerabilities in minimum. A wide variety of threats related to secure update may appear both prior to an update and during the update process and the product shall mitigate both of these types of threat.
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:
Threats to secure update during installation & execution:
- Authenticity or integrity verification bypass
- Downgrade to a vulnerable version
- Downgrade to a older version
- Rollback protections bypass
- Loss of availability if update fails or is interrupted
Therefore, it is important to test all system upgrades and design the upgrade procedure in a way, that keeps the system within the set [5.3.8 High Availability] targets.
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]:** The product shall verify the authenticity and integrity of update packages 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 vulnerable version.
-**[REQ-UPDATES-2]:** If the product supports intentional rollback, this action shall require explicit authorisation and shall be based on separately versioned and signed rollback metadata.
-**[REQ-UPDATES-3]:** The product shall apply updates in an atomic manner such that incomplete or failed updates do not result in a partially updated state. In the event that an update cannot be completed successfully, the product shall automatically restore a previously operational software state, ensuring the product remains functional.
-**[REQ-UPDATES-5]:** The product shall inform the user about update availability if applicable.
-**[REQ-UPDATES-0]:** Authenticity and integrity of upgrade 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 upgrade 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-5, REQ-UPDATES-6, REQ-UPDATES-7 and REQ-UPDATES-8 are conditional due to different operative management models.
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 ran in the same context.
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.
In some occasions, the cluster design does not have the capasity to provison the extra workload needed to make a seameless trasfer of application functions.
Distributed application design and delay lines built with buffers might tolerate partial downtime of individual components and services, but as the upgrade controller designs are not fully matured, the evaluation of upgrade structures needs to be left for the assessors.
> 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>
