Awareness: Update HGS policies after installing the February 2020 security update

This post has been republished via RSS; it originally appeared at: Data Center Security articles.

2/17/2020 update: KB4524244 has been removed from the Windows Update catalog and will not be re-offered (more info in the release notes). For customers who already installed KB4524244 or any other OEM or Windows update that changes your Secure Boot configuration, the guidance below still applies.

Users of the Host Guardian Service (HGS) for shielded VMs or SQL Server Always Encrypted with Secure Enclaves should be aware that the February 2020 Security Update (KB4524244) for Windows 10 and Windows Server may cause your guarded hosts or SQL Servers to fail attestation. You won't want to get caught by this in production, so read on to learn more about the update, how to prepare for the change, and best practice guidance for handling updates in production environments.


What's special about the February 2020 security update?

The February 2020 security update "addresses an issue in which a third-party Unified Extensible Firmware Interface (UEFI) boot manager might expose UEFI-enabled computers to a security vulnerability." It does this by updating your Secure Boot configuration to block the vulnerable boot manager. While updates to the Secure Boot configuration are rare, they are important to protect the integrity of the pre-OS boot process.


You normally wouldn't even notice that the Secure Boot configuration has been updated, but it's one of many measurements HGS analyzes when a machine attests in TPM mode. HGS compares the machine's current Secure Boot configuration (measured by the TPM) with the list of trusted baselines registered on HGS. Baselines captured before the February 2020 security update is installed will have the old Secure Boot configuration in them, so when an updated machine tries to attest, HGS will notice the discrepancy and flag the machine as unhealthy. This is the intended behavior, since a change to the Secure Boot configuration could indicate someone is trying to allow other, potentially compromised, boot managers to run on your computer. In the case of KB4524244, however, the updated Secure Boot configuration helps improve your security, so you'll want to capture a new baseline that includes the new configuration and register it as a trusted baseline with HGS.


Who's affected?

The changes included in KB4524244 will only affect attestation if all the following apply to your environment:

  1. You are using HGS in TPM attestation mode.
  2. You captured and registered the TPM baseline for your host(s) before installing KB4524244.
  3. You later install KB4524244 and reboot the machine to apply the update.

The best indication that your attestation failure is a result of the Secure Boot configuration update is if your AttestationSubstatus = SecureBootSettings. You can get this information by running Get-HgsClientConfiguration on the machine attesting with HGS. If this cmdlet returns other substatus values, check out our troubleshooting guide for more information.


PS C:\> Get-HgsClientConfiguration
IsHostGuarded : False
Mode : HostGuardianService
KeyProtectionServerUrl :
AttestationServerUrl :
AttestationOperationMode : Tpm
AttestationStatus : InsecureHostConfiguration
AttestationSubstatus : SecureBootSettings


Recommended update process

Microsoft recommends installing the February 2020 security update on all of your machines. To ensure a smooth rollout and avoid downtime for your shielded VMs or SQL Servers, it's recommended to apply the update and configure HGS in the following order:


  1. Isolate one of your machines to perform the initial update on. This machine will have temporary downtime, so make sure to move any production workloads off it first. You can also use a pre-prod environment machine if it has the same hardware configuration as your production servers.

  2. Run Get-HgsClientConfiguration to confirm it is passing attestation with HGS. You only want to capture an updated baseline on a known-good machine.

  3. Install KB4524244 on the machine and reboot it.

  4. Run Get-HgsClientConfiguration again and see if it fails with AttestationSubstatus = SecureBootSettings. If it still passes attestation, the Secure Boot configuration may not have been applied yet. Wait a few minutes then reboot the machine again. Don't proceed until the attestation starts failing.

  5. With the update applied, run the following command in an elevated PowerShell console:
    Get-HgsAttestationBaselinePolicy -Path .\Post-KB4524244.tcglog

    Tip: if you're running SQL Server in a VM, you may see an error saying the IOMMU is not available. Re-run the above command with -SkipValidation at the end to bypass this check.

  6. Copy the file to your HGS server, then register it with the following PowerShell command:
    Add-HgsAttestationTpmPolicy -Name Post-KB4524244 -Path .\Post-KB424244.tcglog

    Tip: if you're registering a Windows Server 2016 Hyper-V host with a Windows Server 2019 HGS server, make sure to add -PolicyVersion v1 to the end of the above command.

  7. Back on the machine where you captured the new baseline policy, run Get-HgsClientConfiguration again. It should pass attestation.

  8. The baseline policy will allow machines with the same hardware and software configuration to attest successfully. If you run a heterogeneous fleet (different hardware vendors, different generations of hardware, or different OS versions), repeat steps 1-7 for each unique hardware-software configuration. Generally, you'll need an updated baseline for each baseline you already registered with HGS. Use Get-HgsAttestationPolicy -PolicyType SecureBootSettings to see all baselines registered with HGS.

  9. Once all the unique configurations have been registered with HGS, you can roll out KB4524244 to your other machines and they should experience a seamless update.

  10. Finally, once all machines have been updated and rebooted, you can disable or remove the old baseline policies from HGS so computers without the Secure Boot configuration update aren't marked as healthy. See Disable-HgsAttestationPolicy and Remove-HgsAttestationPolicy for more information.


General update guidance

TPM attestation with HGS provides strong assurances about the security of your servers. It's recommended that you always test any software or hardware updates in an isolated, pre-production environment before rolling the changes out to all machines. This will help you catch any changes that cause attestation to fail and give you time to prepare new baseline or code integrity policies to trust those changes.


REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.