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

5 Automatic Recovery: Some computer systems are able to detect when the system BIOS has been

NIST platform security: roots of trust, firmware and secure enclaves SP 800-147
All changes in this version
first version loaded 5 Automatic Recovery: Some computer systems are able to detect when the system BIOS has been

Title

Automatic Recovery: Some computer systems are able to detect when the system BIOS has been

Control

corrupted and recover from a backup firmware image stored in a separate storage location from the primary system BIOS (e.g., a second flash memory chip, a hidden partition on a hard drive).

2.4 Importance of BIOS Integrity

As the first code that is executed by the main CPU, the system BIOS is a critical security component of a computer system. While the system BIOS, possibly with the use of a Trusted Platform Module (TPM), can verify the integrity of firmware and software executed later in the boot process, typically all or part of the system BIOS is implicitly trusted.

The system BIOS is a potentially attractive target for attack. Malicious code running at the BIOS level could have a great deal of control over a computer system. It could be used to compromise any components that are loaded later in the boot process, including the SMM code, boot loader, hypervisor, and operating system. The BIOS is stored on non-volatile memory that persists between power cycles. Malware written into a BIOS could be used to re-infect machines even after new operating systems have been installed or hard drives replaced. Because the system BIOS runs early in the boot process with very high privileges on the machine, malware running at the BIOS level may be very difficult to detect. Because the BIOS loads first, there is no opportunity for anti-malware products to authoritatively scan the BIOS.

BIOS exploits would likely be highly system-specific—directed at a specific version of a system BIOS or certain hardware components (e.g., a particular motherboard chipset). In contrast, most malware targets software executing at or above the operating system kernel, where it is easier to develop and can attack larger classes of machines. BIOS-level malware may be more likely employed in targeted attacks on high-value computer systems. The move to UEFI-based BIOS may make it easier for malware to target the BIOS in a widespread fashion, as these BIOS implementations are based on a common specification.

For the reasons outlined above, there are few known instances of BIOS-level malware. At this time, the only publicly known malware targeting the system BIOS that has infected a significant number of computers is the CIH virus, also known as the Chernobyl virus [Sym02], first discovered in 1998. One element of the payload of this virus attempted to overwrite the BIOS on systems using a specific chipset that was widely deployed at the time. This malware relied on several vulnerabilities that are not present in modern machines.

Security researchers have demonstrated other potential attacks on conventional BIOS and EFI/UEFI firmware. Proof-of-concept attacks have been demonstrated that allow for the insertion of malicious code into conventional BIOS implementations that permit unsigned updates [SaOr09]. Other researchers have discovered a buffer-overflow vulnerability in the EFI BIOS on a modern platform. Although this EFI BIOS write-protects firmware early in the boot process and only flashes signed updates to firmware, the buffer overflow allowed the researchers to bypass the secure update process by executing an unsigned portion of the firmware update package before write protections were applied [WoTe09].

Vulnerabilities such as these could allow attackers to create stealthy malware that operate with very high privileges on a system. The system BIOS loads SMI handlers before passing control of the computer to the operating system. Malicious code written into a BIOS could modify the SMI handlers to create malware that would run in SMM [EmSp08]. This would give the malware unrestricted access to physical memory and peripherals connected to the host machine, and it would be very difficult for software running on the operating system to detect.

2.5 Threats to the System BIOS

The preceding section established the importance of maintaining the integrity of the system BIOS. This section describes some of the various ways that the integrity of the system BIOS can be attacked, and identifies the attacks considered within scope for the security controls and processes specified in Section 3.

The first threat to the integrity of the system BIOS comes while the system moves through the supply chain. Supply chain security techniques are out of scope for the security controls specified in this document. Some of the procedures specified in Section 3.2 can, however, be used to identify and remedy systems that have an unapproved system BIOS.

Assuming that the system arrives with the manufacturer’s intended system BIOS installed, there are a number of threats to the integrity of the system BIOS during the system’s lifetime:
• One of the most difficult threats to prevent is a user-initiated installation of a malicious system BIOS. User-initiated BIOS update utilities are often the primary method for updating the system BIOS. The guidelines included in this document will not prevent users from installing unapproved BIOS images if they have physical access to the computer system. As with supply chain threats, security processes may be able to detect and remediate the unapproved system BIOS, such as initiating a recovery process to restore to an approved BIOS.

• Malware could leverage weak BIOS security controls or exploit vulnerabilities in the system BIOS itself to reflash or modify the system BIOS. General-purpose malicious software is unlikely to include this functionality, but a targeted attack on an organization could be directed towards an organization’s standard system BIOS. The malicious BIOS can be delivered to the system either over a network, or using media. The guidelines presented in this document are designed to prevent these kinds of attack.

• Network-based system management tools could also be used to launch an organization-wide attack on system BIOSs. For example, consider an organization-maintained update server for the organization’s deployed system BIOS; a compromised server could push a malicious system BIOS to computer systems across the organization. This is a high-impact attack, but requires either an insider or compromise of an organization’s update process. The guidelines presented in this document are designed to prevent this kind of attack.

• Any of the preceding mechanisms could be used to rollback to an authentic but vulnerable system BIOS. This is a particularly insidious attack, since the “bad” BIOS is authentic (i.e., shipped by the manufacturer). The security controls specified in the following section are primarily focused on verifying the source and integrity of the system BIOS. This document includes recommended controls for rollback protection.

The controls described in the following section are primarily focused on preventing unauthorized modification of the system BIOS by potentially malicious software running on computer systems. Installation of an unapproved system BIOS in the supply chain, by individuals with physical access, or through rollback to an authenticated but vulnerable system BIOS, are not addressed by the controls in Section 3.1, but can be addressed using processes specified in Section 3.2. 3. Threat Mitigation

BIOS is a critical component of a secure system. As the first code executed during the boot process, the system BIOS is implicitly trusted by hardware and software components in a system. The previous section described the system BIOS’s role in the boot process, the system BIOS’s appeal to attackers, and the potential threats resulting in the unauthorized modification of the BIOS. This section presents security guidelines for BIOS implementations and recommended practices for managing BIOSs in an enterprise environment. Section 3.1 provides guidelines for a secure BIOS update process. It is intended for platform vendors designing, implementing, or selecting a system BIOS implementation. While products may not be immediately available, organizations can use these guidelines at input to their procurement processes and begin developing plans to make use of these security features when they are available. Organizations can use the recommended BIOS management practices in Section 3.2 when developing these plans. The recommendations are intended to prevent unauthorized modification of the BIOS.

3.1 Security Guidelines for System BIOS Implementations

This subsection provides guidelines intended to maintain the integrity of the BIOS after it has been provisioned by securing the mechanisms used for updating the BIOS. In particular, this subsection defines guidelines for system BIOS implementations for a secure BIOS update mechanism. A secure BIOS update mechanism includes: 1. a process for verifying the authenticity and integrity of BIOS updates; and 2. a mechanism for ensuring that the BIOS is protected from modification outside of the secure update process.

Authentication verifies that a BIOS update image was generated by an authentic source and is unaltered. All updates to the system BIOS shall either go through an authenticated BIOS update mechanism as described in Section 3.1.1 or use an optional secure local update mechanism compliant with the guidelines in Section 3.1.2.

These guidelines for a secure BIOS update mechanism do not mitigate all risks associated with the system BIOS. Some threats to unauthorized modification of the system BIOS remain. For example, these guidelines do not prevent individuals with physical access to systems from modifying the system BIOS. Nor do they guarantee the absence of vulnerabilities in the system BIOS implementations. The guidelines on the system BIOS should be used in conjunction with organizations’ existing security policies and procedures.

3.1.1 BIOS Update Authentication

The authenticated BIOS update mechanism employs digital signatures to ensure the authenticity of the BIOS update image. To update the BIOS using the authenticated BIOS update mechanism, there shall be a Root of Trust for Update (RTU) that contains a signature verification algorithm and a key store that includes the public key needed to verify the signature on the BIOS update image. The key store and the signature verification algorithm shall be stored in a protected fashion on the computer system and shall be modifiable only using an authenticated update mechanism or a secure local update mechanism as outlined in Section 3.1.2.

The key store in the RTU shall include a public key used to verify the signature on a BIOS update image or include a hash [FIPS 180-3] of the public key if a copy of the public key is provided with the BIOS update image. In the latter case, the update mechanism shall hash the public key provided with the BIOS update image and ensure that it matches a hash which appears in the key store before using the provided public key to verify the signature on the BIOS update image.

BIOS images shall be signed in conformance with NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications [SP800-89], using an approved digital signature algorithm as specified in NIST FIPS 186-3, Digital Signature Standard [FIPS186-3], that provides at least 112 bits of security strength, in accordance with NIST SP 800-131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths [SP800-131A].

The update mechanism shall ensure that the BIOS update image has been digitally signed and that the digital signature can be verified using a key in the RTU before updating the BIOS. Recovery mechanisms shall also use the authenticated update mechanism unless the recovery process meets the guidelines for a secure local update. The authenticated update mechanism should prevent the unauthorized rollback of the BIOS to an earlier authentic version that has a known security weakness. This limitation of the rollback mechanism may be accomplished, for example, by verifying that the version number of the BIOS image is larger than the currently installed BIOS image’s version number.

Some organizations may wish to assert greater control over BIOS updates in high-security environments. The authenticated update mechanism may be designed to permit organizational control over the update process, where updates to the BIOS or rollbacks of the BIOS to an earlier version are permitted only if the update or rollback has been authorized by the organization. For example, specific BIOS images could be authorized by an organization by countersigning them with an organization-controlled key, which would be verified during the update process.

3.1.2 Secure Local Update

BIOS implementations may optionally include a secure local update mechanism that updates the system BIOS without using the authenticated update mechanism. The secure local update mechanism, if it is implemented, should be used only to load the first BIOS image or to recover from a corruption of a system BIOS that cannot be fixed using the authenticated update mechanism described in Section 3.1.1. A secure local update mechanism shall ensure the authenticity and integrity of the BIOS update image by requiring physical presence. Further protections may be implemented in the secure local update mechanism by requiring the entry of an administrator password or the unlocking of a physical lock (e.g., a motherboard jumper) before permitting the system BIOS to be updated.

3.1.3 Integrity Protection

To prevent unintended or malicious modification of the system BIOS outside the authenticated BIOS update process, the RTU and the system BIOS (excluding configuration data used by the system BIOS that is stored in non-volatile memory) shall be protected from unintended or malicious modification with a mechanism that cannot be overridden outside of an authenticated BIOS update. The protection mechanism shall itself be protected from unauthorized modification.

The authenticated BIOS update mechanism shall be protected from unintended or malicious modification by a mechanism that is at least as strong as that protecting the RTU and the system BIOS.

The protection mechanism shall protect relevant regions of the system flash memory containing the system BIOS prior to executing firmware or software that can be modified without using an authenticated update mechanism or a secure local update mechanism. Protections should be enforced by hardware mechanisms that are not alterable except by an authorized mechanism. 3.1.4 Non-Bypassability

The authenticated BIOS update mechanism shall be the exclusive mechanism for modifying the system BIOS absent physical intervention through the secure local update mechanism. The design of the system and accompanying system components and firmware shall ensure that there are no mechanisms that allow the system processor or any other system component to bypass the authenticated update mechanism, except for the secure local update mechanism. Any such mechanisms capable of bypassing the authenticated update mechanism could create a vulnerability allowing malicious software to modify the system BIOS or overwrite the system flash with a BIOS image from an illegitimate source.

A modern platform includes design features that give system components direct access to the system BIOS for performance improvements, such as shadowing the BIOS in RAM or for system management mode operations. System components may have read access to BIOS flash memory, but they shall not be able to directly modify the system BIOS except through the authenticated update mechanism or by an authorized mechanism requiring physical intervention. For example, bus mastering that bypasses the main processor (e.g., Direct Memory Access to the system flash) shall not be capable of directly modifying the firmware. Also, microcontrollers on the system shall not be capable of directly modifying the firmware, unless the hardware and firmware components of the microcontroller are protected with equivalent mechanisms at the RTU. These non-bypassability guidelines do not apply to configuration data used by the system BIOS that is stored in non-volatile memory.

3.2 Recommended Practices for BIOS Management

This section introduces considerations for managing system BIOS in an enterprise operational environment leveraging the existing policy, process, and operations practices. It focuses on key activities revolving around provisioning, deploying, managing, and decommissioning the system BIOS as part of its overall platform life cycle. Activities performed in a recovery phase are also specified to handle exceptional conditions.

Provisioning Phase: It is crucial that the organization institute a mechanism for identifying, inventorying, and tracking the different computer systems across the enterprise throughout their life cycle. Identifying and monitoring the BIOS image characteristics such as manufacturer name, version, or time stamp allows the organization to perform update, rollback, and recovery. The organization should maintain a “golden master image” for each approved system BIOS, including superseded versions, in secure offline storage.

If the platform has a configurable Root of Trust for Update (RTU), the organization needs to maintain a copy of the key store and signature verification algorithm. If the RTU is integrated into the system BIOS then this guideline is satisfied by maintaining the golden BIOS image. If the RTU is not integrated into the system BIOS, the security afforded the RTU should be at least as strong as that for the golden BIOS image.

Most organizations will rely upon the manufacturer as the source for the authenticated BIOS. In this case, the organization does not maintain any private keys, and the RTU contains only public keys provided by the manufacturer. Where the organization prefers to participate actively in the BIOS authentication process by countersigning some or all approved system BIOS updates, the RTU may contain one or more public keys associated with the organization. In this case, the organization must securely maintain the corresponding private key so that the next BIOS update can be signed. Private keys should be maintained under multi-party control to protect against insider attacks. For organizational keys, the corresponding public keys must also be maintained securely (to ensure authentication of origin). In addition, a common configuration baseline for each platform must be created to conform to the organization’s policy. The baseline should ensure that the integrity protection and non-bypassability features are enabled (if they are configurable), and organization policies for password policy and device boot order are enforced. Finally, the BIOS image information and associated baseline of settings for each platform should be documented in the configuration management plan. 2

Platform Deployment Phase: The secure local update process should be used to provision the approved BIOS for that platform from the golden master image, the corresponding RTU should be installed, and BIOS-related configuration parameters established before computer systems are deployed. This will help the organization maintain a consistent, known starting posture. The organization should periodically perform assessments to confirm that the organization’s BIOS policies, processes, and procedures are being followed properly.

Specifically, the procedures must ensure that the appropriate system BIOS is installed, the RTU contains all required keys and no unauthorized keys, and the integrity protection and non-bypassability features are enabled if they are configurable.

Operation and Maintenance Phase: This phase includes the operations and maintenance activities that are important for maintaining BIOS security and reliability in the operational environment. System BIOS updates should be performed using a change management process and the new approved version should be documented in the configuration plan, noting the previous BIOS image has been superseded.

The BIOS image and configuration baseline should be continuously monitored. If an unapproved deviation from this baseline is detected, the event should be investigated, documented, and remediated as part of incident response activities. The incident response plan should document the process and set of authorized tools that can be used to capture the evidence to help determine the root cause. 3 The secure local update mechanism should be used to recover from a BIOS image compromise.

When a new BIOS image is required to extend system capabilities, improve system reliability, or remediate software vulnerabilities, BIOS updates should be performed using the authenticated update process. Where the organization participates actively in the update process, the multi-party control process must be executed to retrieve the private key from secure storage and generate the digital signature. The BIOS installation package should also be signed, and the digital signature should be verified before execution. Once the update has executed successfully, the configuration baseline should be validated to confirm that the computer system is still in compliance with the organization’s defined policy.

Recovery Phase: In some circumstances, a BIOS update will be required that cannot be accomplished using the authenticated update process. For example, a corrupted system BIOS or RTU may be unable to execute or invoke the authentication procedures. In this case, the appropriate system BIOS and/or RTU may be able to be installed using the secure local update process. In other cases, a BIOS update may have unintended consequences, forcing the organization to roll back to an earlier version. Extra steps may be required for an authenticated update to authorize rollback (if versioning or timestamps are compared during the standard authentication process), or the secure local update process may be required to reestablish a secure baseline. As with the Operations and Maintenance phase, it is essential to validate

2 See Draft NIST SP 800-128, Guide for Security Configuration Management of Information Systems [SP800-128] for guidelines on developing a configuration management plan. 3 For additional information on establishing incident response capabilities and handling incidents efficiently and effectively, see NIST SP 800-61rev1 Computer Security Incident Handling Guide [SP800-61]. the configuration of the BIOS against the organization’s defined policy after BIOS rollback or reinstallation.

Disposition Phase: Before the computer system is disposed and leaves the organization, the organization should remove or destroy any sensitive data from the system BIOS. The configuration baseline should be reset to the manufacturer’s default profile; in particular, sensitive settings such as passwords should be deleted from the system and keys should also be removed from the key store. If the system BIOS includes any organization-specific customizations then a vendor-provided BIOS image should be installed. This phase of the platform life cycle reduces chances for accidental data leakage.