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 Firmware Security Guidelines for Platform Devices

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

Title

Firmware Security Guidelines for Platform Devices

Control

This section details the technical security guidelines for devices in a platform for each of the three elements of resiliency: protection, detection, and recovery. Devices may implement the requirements in one or more of these sections based on the firmware resiliency properties, as defined in Section 3.2 , they aim to support. Section 4.1 provides foundational security guidelines for the Roots of Trust that support those properties. Section 4.2 provides security guidelines for the protection of firmware code and critical data. Guidelines for mechanisms to detect unauthorized changes to firmware and data are described in Section 4.3 . Finally, Section 4.4 specifies security guidelines for firmware and data recovery mechanisms.

While the guidelines are written in terms of applying to individual devices, a device may implement these guidelines with assistance from another device. Security functionality may be done by the device itself (self-contained) or it may rely upon a security architecture whereby another platform device provides some or all those security functions for that device. The reliance on another device to provide necessary security functionality demands a critical trust relationship between these devices, as described in Section 3.4 . These guidelines refer to the device relying on security functionality from another device as a symbiont , and the device providing that functionality for the symbiont as a host device . In these cases, the symbiont and host together form the Root of Trust or Chain of Trust responsible for implementing the security functions. The host device must additionally meet all of the requirements for a self-contained device.

The use of shall , should , and may are used as defined in RFC 2119 [5] .