All systems in the business environment SHALL have UEFI Secure Boot enabled and enforced at all times.

Since the mid-2000s, systems using the Unified Extensible Firmware Interface (UEFI) have included Secure Boot as part of the UEFI specification. Secure Boot is a software feature that ensures system integrity by only allowing trusted, signed software to be run during the boot process. This is designed as a mitigation against threat actors who drop bootkit malware into a system, thus compromising the system from the boot process. Think of Secure Boot as a roll call that ensures that nothing in the boot process is suspicious or out of order.

Devices shipped with Secure Boot have the cryptographic signature of the default operating system preinstalled in the firmware. If the end users wish to use a different operating system, they can acquire signatures of the chosen OS and import them into the Secure Boot firmware. Each major software vendor obtains a digital certificate from a Trusted Certificate Authority (CA) and uses it to sign cryptographic keys, which are in turn used to sign their boot binaries. The public certificate of the Trusted CA can be imported into Secure Boot to validate boot signatures, or the vendor can use hashes of the binaries.

Secure Boot information is contained in the following variables:

  1. Exclusion/deny list database (DBX): Contains the digital certificates/hashes of denied or untrustworthy boot binaries. If a system contains something in its boot process that matches a certificate/hash in the DBX, it will not be trusted.
  2. Allow list database (DB): Contains a list of trusted certificates/hashes. After the DBX has been processed, boot binaries will be validated against the DB to see if they match any entries. If a match is found, the boot binary is trusted and allowed to continue. Otherwise, it is labeled as untrusted.
  3. Key Exchange Key (KEK): Contains digital certificates that are allowed to validate changes to the DBX and DB. If a command is issued to change records in DB or DBX and it has an associated certificate in the KEK database, the command will be executed. If the change command does not match a KEK certificate, it will not be allowed to execute.
  4. Platform Key (PK): This single key is directly associated with the Certificate Authority that is allowed to trust changes to KEK values. The PK can also sign changes to other UEFI variables, including DBX and DB. If any KEK changes are signed by keys other than the PK, they will be rejected.

Systems with Secure Boot will provide the option to boot with Legacy Boot Mode instead. This should not be used. Legacy Boot enables admins to boot from media that does not have a corresponding certificate/hash in Secure Boot. Businesses should ensure that their devices always have Secure Boot enabled and enforced. An average Secure Boot configuration will contain the following:

  • PK set by the system vendor
  • KEK certificate from the system vendor, a Microsoft 2011 KEK certificate, and a Microsoft 2023 KEK certificate
  • DB certificate for the Microsoft Windows Production CA (PCA) 2011, a DB certificate for the Microsoft UEFI CA 2011, a DB certificate for the Microsoft Windows UEFI CA 2023, a Microsoft UEFI CA 2023 certificate, and a Microsoft Option ROM UEFI CA 2023 certificate
  • List of DBX hashes

Upon receiving a new stock of devices, business IT admins should review the Secure Boot configuration to ensure it is enabled and functioning properly.