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

2.2.2.1 Critical Data

NIST platform security: roots of trust, firmware and secure enclaves SP 800-193
All changes in this version
first version loaded 2 Platform Architecture part of 2.2.2

Title

Critical Data

Control

Critical data may be used for various purposes, including:
• Configuration settings: Data which tells the code how to configure operational aspects of the device Example: Enabling a peripheral that is disallowed by enterprise security policies. Example: The table of non-functional sectors in a hard drive.
• Policies: Data which tells the code what path to take or how to respond Example: The system’s boot order describes the valid devices to attempt to boot from as well as the order . Example: UEFI Secure Boot, a set of security configurations controlling which third party code the BIOS will hand control to.

Critical data is difficult to precisely define because data that may be critical for one device may not be critical for another. However, common characteristics of critical data include:

• It must be in a valid state for the proper booting and run-time operation of the device;
• It persists across power cycles (e.g. stored in non-volatile memory)
• It modifies the behavior or function of the device
• It must be in a valid state to support protection, detection and/or recovery of platform firmware and associated data.

Some critical data is hard-coded in code, and updated only by means of a firmware image update. For the purposes of this document, hard-coded data is considered part of the code, and protected according to the firmware code protection, detection and recovery guidelines.

Platform devices often have other data that is configurable during normal operation by Platform Administrators, hardware, firmware or software. Because corruption of critical data can interfere with the normal or secure operation of a system, it is important to protect critical data from corruption, and to be able to recover when problems are detected. However, strong protection of some forms of critical data can be architecturally difficult, due to expectations that some entities, such as operating systems and device drivers, have access to change these settings.

Some configuration data can only be changed through defined interfaces controlled by platform- level code. For example, UEFI runtime variables fall into this category. This basic level of protection guards against attackers directly modifying configuration data, and allows Platform Firmware to validate input before committing changes to storage. However, entities may be able to use these defined interfaces to make well-formed, but malicious, configuration changes.

To guard against such tampering, changes to some particularly sensitive configuration data may require authorization before being applied using the defined interfaces described above. In some cases, platform devices, such as host processor boot firmware or service processor firmware, may be capable of authenticating Platform Administrators prior to allowing them to make changes. Other authentication techniques may allow Platform Firmware to cryptographically verify the source and integrity of changes.

Some critical data is managed by the firmware with no programmatic exposure through external interfaces (e.g., wear leveling data) and if lost or damaged can result in permanent loss of service of the device. This type of state data needs to be protected at the highest level and cannot be writeable from the rest of the platform.