BaselineWatch
47 requirements
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

NIST platform security: roots of trust, firmware and secure enclaves SP 800-193

47 requirements · published 2018-05-04
Changes in this version
All1 Introduction2 Platform Architecture3 Principles and Key Concepts4 Firmware Security Guidelines for Platform Devices
RefTitleText
3 Principles and Key Concepts This section provides a brief description of the driving principles for platform resiliency which provide the foundation for the guidelines in this document. It also discusses major architectural concepts and considerations used throughout
3.1
in 3
 Principles Supporting Platform Resiliency The security guidelines in this document are based on the following three principles: • Protection: Mechanisms for ensuring that Platform Firmware code and critical data remain in a state of integrity and are protected from corruption, suc
3.2
in 3
 Resiliency Properties The technical guidelines in this document are written in terms of guidelines for individual platform devices in order to make them broadly applicable to a variety of devices, platforms and systems. Despite the narrow focus on devices, the i
3.3
in 3
 Roots of Trust and Chains of Trust The security mechanisms described in this document are founded in Roots of Trust (RoT). A Root of Trust is an element that forms the basis of providing one or more security-specific functions, such as measurement, storage, reporting, recove
3.4
in 3
 Device Relationships Due to lack of capability or functionality, some platform devices may not have their own root(s) of trust to perform an update, detection, or recovery. We refer to devices needing assistance as symbiont devices and those lending assistance
3.5
in 3
 Firmware Update Mechanisms A central tenet to the firmware protection guidelines is ensuring that only authentic and authorized firmware update images may be applied to platform devices. An update image is authentic if the source (e.g., the device, system manufacture
3.5.1
in 3.5
 Authenticated Update Mechanism An authenticated update mechanism employs digital signatures to ensure the authenticity of the firmware update image. An update of the firmware image using an authenticated update mechanism relies on a Root of Trust for Update (RTU) that co
3.5.2
in 3.5
 Authorized Update Mechanism 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
3.5.3
in 3.5
 Secure Local Update While this document recommends firmware updates be done through an authenticated update mechanism as described in Section 3.5.1 , some devices may also support a secure local update mechanism. These mechanisms instead authorize firmware upd
3.6
in 3
 Other Considerations for Platform Resiliency This document does not address certain other considerations that a purchaser, user, or IT administrator may take into account pertaining to platform cyber resiliency. A non-exhaustive list and discussion of these other considerations follow
3.6.1
in 3.6
 Management Vendors should carefully consider their target customers when designing resilient platforms to ensure proper management and control of policies and configuration settings can be administered in the way which best serve customer needs. Manag
3.6.2
in 3.6
 Authorization Mechanisms Some recovery and administrative actions can make significant changes to either the Platform Firmware or software. For example, firmware settings may control the boot order, and a software recovery agent may restore a backup erasing recentl
3.6.3
in 3.6
 Network-Assisted vs. Local Recovery In most cases, the ability to recover locally from corruption will be the most expedient, provide the highest level of customer satisfaction, and may be necessary if there is no network connectivity. But it is recognized that this is not al
3.6.4
in 3.6
 Automated vs. Manual Recovery Recovery can proceed in one of three ways:
3.6.5
in 3.6
 Event Logging Logging firmware and recovery-related events can often be useful for multiple purposes, including but not limited to: • Forensic analysis which allows for a Platform Administrator of a system to capture information which might have led to

15 of 47.