Security extends to all endpoints and services. Locking down boot devices on client systems helps protect against unauthorized installations by leveraging secure boot to allow only trusted devices.
Protecting client systems from booting to unauthorized devices is a security that is often overlooked when locking down computers. The benefits to implementing boot security has certainly not been lost in devices with the newer Unified Extensible Firmware Interface (UEFI), which takes boot security beyond a simple password protected feature.
Focusing on only allowing authorized devices, or trusted devices that use keys to verify that bootloaders, system files, and installation files maintain their integrity and have not been compromised or otherwise modified, Secure Boot - this component of UEFI - effectively ignores all other entries that could be used by a device to boot from that are not whitelisted by requiring signed keys for each entry.
Deployment servers, such as Windows Deployment Services (WDS) rely on PXE to boot to the client over the network to deploy images and configurations data via Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager (SCCM) repositories. In secured environments with Secure Boot enabled on client, each device will require a signed file generated by the deployment server itself to be installed to the UEFI firmware, before the client will boot to the server ensuring that only authorized deployments occur from trusted deployment servers.
Before we get into the crux of how to set this up, here are the requirements you'll need to perform this task:
- Server running Windows Server 2008 R2 (or later) running the following services:
- Windows Deployment Services
- Microsoft Deployment Toolkit or System Center Configuration Manager (installed and configured)
- Client PC running Windows 8 (or later) with UEFI enabled (Legacy mode disabled)
- Switched, Local Area Network
- User account with administrative access
- Firmware password enabled on client machine
- USB Flash Drive
1. Authenticate to the Windows Server and navigate to the following location and copy the .EFI files to USB Flash Drive. Each file is architecture specific, so if both 32 and 64-bit client support is required, make sure to copy both files:
2. With the file(s) successfully copied to USB, eject the Flash Drive and insert it into the client PC, and boot the device to the firmware.
3. If a firmware password is not set, make sure to set one prior to exiting the screen. While it's not a requirement for UEFI to function properly, it is a best practice and will prevent tampering of the firmware settings.
4. Navigate to the UEFI settings page of your device's firmware. This setting varies depending on your PC's manufacturer, however new Dell computers for example contain the required setting under the General | Boot Settings entry. Under the Boot List Option, ensure the radio button for UEFI is ticked, then click the Add Boot Option to navigate the file hierarchy and point the selection to the .EFI file(s) copied in step #1 above
5. Repeat step #4 until each EFI file has been successfully loaded. Then click the Apply and Exit buttons to save your changes, and exit the firmware respectively.
When the device reboots after exiting the firmware configuration screen, you may now press the appropriate key (in keeping with the Dell theme, F12) to access the boot selection prompt, where now the WDS server entry will appear for each architecture added. Selecting the desired one will boot to your trusted WDS server, while Secure Boot prevents all others from performing the boot process.
- How to get started with Windows Deployment Services (TechRepublic)
- How to deploy Windows using MDT and WDS (TechRepublic)
- How to configure the Microsoft Deployment Toolkit (TechRepublic)
- Intel: We're ending all legacy BIOS support by 2020 (ZDNet)
- Windows 10 security: Microsoft patches critical flaw in Windows Defender (ZDNet)
Does your organization leverage Secure Boot? Why or why not? And what kinds of issues have you faced in implementing Secure Boot or what issues have been resolved since implementing Secure Boot? Please share your stories with us, we'd love to hear from you.