Secure workstation - Root of trust to manage the cloud

Two months ago I introduced the Azure secure workstation, and I’ve had the privilege to present the ideal to some great audiences.

From the discussions, a common question I’ve been asked is a pattern that would provide the Secured PAW model lock down scenario to exclusively manage an Azure Portal (EG how to I assure only secured workstation, and users assigned to the program can manage my cloud services)?

In this article I’ll provide the NEXT step to accomplish exactly that outcome. This includes additional configurations that I only lightly covered, or net new technology to apply since the publishing of the doc.

Proposed outcome “How do I” Use a Secured workstation (that I can trust) to manage my Azure cloud.

Here’s how I would deploy the solution. First I will start by deploying the Secured Workstation model this using the secured profile.

New technology, and capabilities to add:

• Hardware root of trust – in our solution we post the idea that you can order a device from an autopilot partners, which will give you a level of confidence the device is secured by the manufacturer. Additionally we will look to modern technology in windows to provide a high confidence in the devices root of trust with a robust design. Outlined in this windows 10 document.
• The OS can be delivered in S mode, proving an assurance that as long as the manufacturer chain of custody is managed, the device you receive will have a clean, Microsoft validated OS. Additionally when you autopilot join the device, you can instrument Intune to flip the host our of S mode, and into enterprise, which gives you added flexibility, but still the chain of trust has not been altered. Outlined in my guidance under Intune Configuration.

• If trusting the hardware through change, and rebuild (Device Resets) is an issue, the next element to consider would be to use additional hardware restricted devices, as outlined in the SECCON (security configuration framework) Level 1,2, and 3.

Create a new policy with the following configuration
 Now before you ‘Enable the policy’ – it’s recommended that you test your exception user, as this user or group will be your break-glass user/group.

• Disable the need for passwords – and implement Fido

• Implement an isolated tenant for the management environment (reflects isolated identity)

• Implement Windows virtual desktop for productivity, while blocking all messaging capabilities on the local host… eg mail.

Recommended hardware features needed from device manufacturers:

·        Trusted Platform Module (TPM) 2.0

·        Bitlocker Drive Encryption

·        UEFI Secure Boot

·        Drivers and Firmware Distributed through Windows Update

·        Virtualization and HVCI Enabled

·        Drivers and Apps HVCI-Ready

·        Windows Hello

·        DMA I/O Protection

·        System Guard

·        Modern Standby

Additionally, we would enable Device Health Attestation to ensure the attackers cannot be persistent during the early boot of a device.

Internet URL blocking can be accomplished using technology that was not outlined in the original guidance. The capabilities that I refer too is the Cloud App security, which is a multimode Cloud Access Security Broker (CASB). The technology through integration to ATP will provide you a means to audit, and mange web destinations from your deployment.

Finally, the last element to implement is locking out access to all elevated cloud management roles, and capabilities in Azure Portal. This can be accomplished using Azure AD conditional access as I outlined in my docs, but I’d add the following rules.

                                                    i.     Assignment –> Select users and groups –> All users

                                                   ii.     Assignment -> Select users and groups -> exception -> Use a group, or user that CAN bypass the secured workstation. Consider this your break glass scenario, which I’ll discuss in a future blog.

                                                  iii.     Cloud Apps and actions –> Select apps -> Select ->

1.     Microsoft Azure Management

2.     Microsoft Intune

3.     And other apps you want exclusive access…

                                                 iv.     Condition -> Sign-in risk -> Select All (unless you opt to leave Low and No risk out)

                                                   v.     Condition ->  Device platform -> Select Any device, But exclude - Windows

                                                 vi.     Condition -> Device state -> Include All device state, but Exclude – Device marked as compliant, This  exclusion will be the path to ensure only your secured workstations can access your cloud management service.

                                                vii.     Access Control -> Grant -> Require device to be marked as compliant

This wraps up the solution lock-down, with the guidance your secure devices reflect a high quality root of trust, as well as the management of your service (Azure) is restricted to only allow users from this environment for management.

Future items to address in a continued quest for ultra locked down environment would be.

• Disable the need for passwords – and implement Fido
• Implement an isolated tenant for the management environment (reflects isolated identity)
• Implement Windows virtual desktop for productivity, while blocking all messaging capabilities on the local host… eg mail.

Hope this was helpful.