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 Platform Architecture

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

Title

Platform Architecture

Control

Ensuring a platform’s firmware code and critical data are always in a state of integrity is critical to ensure that a computing system can be operated free from malware. Modern client and server computing systems can be considered to be separated into two high-level logical constructs, platform and software . For the purposes of this document, we will describe the combination of these two logical constructs as a system. Note that Figure 1 is merely illustrative and is not intended to represent all possible devices in a platform, nor is it intended to represent an exemplary architecture for any particular device. At a high-level, items in blue-shaded boxes are devices to be considered part of a platform.

Figure 1: High-Level System Architecture

Broadly speaking, the platform is comprised of hardware and firmware necessary to boot the system to a point at which software, or an operating system, can be loaded; software is comprised of elements required to load the operating system and all applications and data subsequently handled by the operating system. Note that some firmware continues to execute once software has started. Existing industry best practice, as well as NIST publications such as NIST SP 800-147, BIOS Protection Guidelines [1] , and NIST SP 800-147B, BIOS Protection Guidelines for Servers [2] , already address the issue of protecting the integrity of a platform’s host processor boot firmware (traditionally called BIOS, and more recently UEFI [3] ) 1 and its update mechanisms, but protection is only one of three key elements of cyber resiliency (the other two being detection and recovery). Additionally, the resilience of other critical firmware on the platform has not yet been addressed to the level the host processor boot firmware has been. While it is beyond the scope of this document to identify and define every category and

1 For purposes of this document, host processor boot firmware will be used generically to refer to either legacy Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI). 2. fTPM

7. SPI Flash App1

Operating system(s), including VMM User Data

11. Platform Runtime

10. Host processor boot firmware Master Boot Record or EFI System Partition +UEFI OS Loader App2 App3 App4

Platform 2. TPM 3. BMC/ME 4. Host Processor 5. NIC 6. GPU 8. HDD / SDD HC

Kbd Mouse Memory Display SO

9. eMMC/UFS