BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

3.5.2 Authorized Update Mechanism

NIST platform security: roots of trust, firmware and secure enclaves SP 800-193
All changes in this version
first version loaded 3 Principles and Key Concepts part of 3.5

Title

Authorized Update Mechanism

Control

A system and its supporting management software and firmware may provide several authorized mechanisms for legitimately updating a firmware image. These include:

1) User-Initiated Updates : Vendors typically supply end users with utilities capable of updating a firmware image. This could be from external media to perform these updates, or via utilities that can update the firmware image from the user’s normal operating system. Depending on the security mechanisms implemented on the system, these utilities might directly update the firmware image or they may schedule an update for the next system reboot. The updated code will encounter critical data written by a different revision of the code. The updated code should ensure that the platform continues to function by remaining compatible with the critical data, by updating the critical data to be compatible with the updated code, or, at least by resetting the critical data values to their defaults.

2) Managed Updates : A given computer system may have hardware and software-based agents that allow a system administrator to remotely update the firmware image without direct involvement from the user.

3) Rollback : Implementations that authenticate updates before applying them may also check version numbers during the update process. In these cases, the firmware image may have a special update process for rolling back the installed firmware to an earlier version. For instance, the rollback process might require the physical presence of the user. This mechanism guards against attackers installing old firmware with known vulnerabilities.

4) Manual Recovery : To recover from corrupt or malfunctioning firmware, computer systems may provide mechanisms to allow a user with physical presence during the boot process to replace a firmware image with a known good version and configuration.

5) Automatic Recovery : Some computer systems are able to detect when a firmware image has been corrupted and recover from a backup firmware image stored in a location separate from the corrupted image (e.g., a second flash memory chip, a protected region of a storage device).