Secure Boot is a boot integrity feature that is part of the Unified Extensible Firmware Interface (UEFI) industry standard; most modern computer systems are delivered with a standard Secure Boot policy installed.

UEFI is a replacement for the legacy Basic Input Output System (BIOS) boot mechanism. UEFI provides an environment common to different computing architectures and platforms. UEFI also provides more configuration options, improved performance, enhanced interfaces, security measures to fight persistent firmware threats, and support for a wider variety of devices and form factors.

Cybercriminals target firmware to persist on an endpoint. Firmware is stored and executes from memory that is separate from the operating system and storage media. Antivirus software, which runs after the operating system has loaded, is ineffective at detecting and remediating malware in the early-boot firmware environment that executes before the operating system. Secure Boot provides a validation mechanism that reduces the risk of successful firmware exploitation and mitigates many published early-boot vulnerabilities.

Secure Boot is frequently not enabled due to issues with incompatible hardware and software. Custom certificates, signatures, and hashes should be utilized for incompatible software and hardware. Secure Boot can be customized to meet the needs of different environments. Customization enables administrators to realize the benefits of boot malware defenses, insider threat mitigations, and data-at-rest protections. Administrators should opt to customize Secure Boot rather than disable it for compatibility reasons. Customization may – depending on implementation – require infrastructures to sign their own boot binaries and drivers.

Recommendations for system administrators:

  • Machines running legacy BIOS or Compatibility Support Module (CSM) should be migrated to UEFI native mode
  • Secure Boot should be enabled on all endpoints and configured to audit firmware modules, expansion devices, and bootable OS images
  • Secure Boot should be customized, if necessary, to meet the needs of organizations and their supporting hardware and software
  • Firmware should be secured using a set of administrator passwords appropriate for a device’s capabilities and use case
  • Firmware should be updated regularly and treated as importantly as operating system and application updates
  • A Trusted Platform Module (TPM) should be leveraged to check the integrity of firmware and the Secure Boot configuration