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

4.2.4 Protection of Critical Data

NIST platform security: roots of trust, firmware and secure enclaves SP 800-193
All changes in this version
first version loaded 4 Firmware Security Guidelines for Platform Devices part of 4.2

Title

Protection of Critical Data

Control

Unauthorized changes to critical data stored and used by devices could also seriously impact the security posture of a device. Such changes could modify or disable important security-relevant functions provided by the platform, or prevent the device from functioning at all. While critical data may need to be modifiable by operating systems and other components, the guidelines in this section aim to provide a controlled interface for these changes and guard against changes that would put the device in an invalid state.

1) Critical data shall be modifiable only through the device itself or defined interfaces provided by device firmware. Examples of defined interfaces include proprietary or public application programming interfaces (APIs) used by the device’s firmware, or standards-based interfaces. Symbiont devices may rely on their host devices to meet this requirement. 2) Critical data updates shall be validated either by the device or a symbiont’s host device prior to committing changes to critical data to ensure that the new data is well-formed. Examples of validation can include range or bounds checking, format checking, etc. 3) Critical data updates shall be authorized by a Platform Administrator or part of an authorized firmware update mechanism. 4) Critical data updates may employ mechanisms to authenticate the critical data before it is used. 5) The device shall protect its factory defaults at least as well as it protects its code. The factory defaults shall be able to be updated in the same manner as the code.