Implementing a Zero Trust security model at Microsoft
At Microsoft, our shift to a Zero Trust security model more than five years ago has helped us navigate many challenges.
The increasing prevalence of cloud-based services, mobile computing, internet of things (IoT), and bring your own device (BYOD) in the workforce have changed the technology landscape for the modern enterprise. Security architectures that rely on network firewalls and virtual private networks (VPNs) to isolate and restrict access to corporate technology resources and services are no longer sufficient for a workforce that regularly requires access to applications and resources that exist beyond traditional corporate network boundaries. The shift to the internet as the network of choice and the continuously evolving threats led us to adopt a Zero Trust security model internally here at Microsoft. Though our journey began many years ago, we expect that it will continue to evolve for years to come.
[Learn how we’re transitioning to modern access architecture with Zero Trust. Find out how to enable a remote workforce by embracing Zero Trust security. Running on VPN: Learn how we’re keeping our remote workforce connected.]
For a transcript, please view the video on YouTube: https://www.youtube.com/watch?v=ZVLlEj2So4E, select the “More actions” button (three dots icon) below the video, and then select “Show transcript.”
Carmichael Patton, a security architect at Microsoft, shares the work that his team, Digital Security and Resiliency, has been doing to support a Zero Trust security model.
The Zero Trust model
Based on the principle of verified trust—in order to trust, you must first verify—Zero Trust eliminates the inherent trust that is assumed inside the traditional corporate network. Zero Trust architecture reduces risk across all environments by establishing strong identity verification, validating device compliance prior to granting access, and ensuring least privilege access to only explicitly authorized resources.
Zero Trust requires that every transaction between systems (user identity, device, network, and applications) be validated and proven trustworthy before the transaction can occur. In an ideal Zero Trust environment, the following behaviors are required:
- Identities are validated and secure with multifactor authentication (MFA) everywhere. Using multifactor authentication eliminates password expirations and eventually will eliminate passwords. The added use of biometrics ensures strong authentication for user-backed identities.
- Devices are managed and validated as healthy. Device health validation is required. All device types and operating systems must meet a required minimum health state as a condition of access to any Microsoft resource.
- Telemetry is pervasive. Pervasive data and telemetry are used to understand the current security state, identify gaps in coverage, validate the impact of new controls, and correlate data across all applications and services in the environment. Robust and standardized auditing, monitoring, and telemetry capabilities are core requirements across users, devices, applications, services, and access patterns.
- Least privilege access is enforced. Limit access to only the applications, services, and infrastructure required to perform the job function. Access solutions that provide broad access to networks without segmentation or are scoped to specific resources, such as broad access VPN, must be eliminated.
Zero Trust scenarios
We have identified four core scenarios at Microsoft to help achieve Zero Trust. These scenarios satisfy the requirements for strong identity, enrollment in device management and device-health validation, alternative access for unmanaged devices, and validation of application health. The core scenarios are described here:
- Scenario 1: Applications and services have the mechanisms to validate multifactor authentication and device health.
- Scenario 2: Employees can enroll devices into a modern management system which guarantees the health of the device to control access to company resources.
- Scenario 3: Employees and business guests have a method to access corporate resources when not using a managed device.
- Scenario 4: Access to resources is limited to the minimum required—least privilege access—to perform a specified function.
Zero Trust scope and phases
We’re taking a structured approach toward Zero Trust, in an effort that spans many technologies and organizations, and requires investments that will carry over multiple years. The figure below represents a high-level view of the Zero Trust goals that we aim to fully achieve over the next two to three years, grouped into our core Zero Trust pillars. We will continually evaluate these goals and adjust them if necessary. While these goals don’t represent the full scope of the Zero Trust efforts and work streams, they capture the most significant areas of Zero Trust effort at Microsoft.
Scope
Our initial scope for implementing Zero Trust focused on common corporate services used across our enterprise—our employees, partners, and vendors. Our Zero Trust implementation targeted the core set of applications that Microsoft employees use daily (e.g., Microsoft Office apps, line-of-business apps) on platforms like iOS, Android, MacOS, and Windows (Linux is an eventual goal). As we have progressed, our focus has expanded to include all applications used across Microsoft. Any corporate-owned or personal device that accesses company resources must be managed through our device management systems.
Verify identity
To begin enhancing security for the environment, we implemented MFA using smart cards to control administrative access to servers. We later expanded the multifactor authentication requirement to include all users accessing resources from outside the corporate network. The massive increase in mobile devices connecting to corporate resources pushed us to evolve our multifactor authentication system from physical smart cards to a phone-based challenge (phone-factor) and later into a more modern experience using the Microsoft Azure Authenticator application.
The most recent progress in this area is the widespread deployment of Windows Hello for Business for biometric authentication. While Windows Hello hasn’t completely eliminated passwords in our environment, it has significantly reduced password usage and enabled us to remove our password-expiration policy. Additionally, multifactor authentication validation is required for all accounts, including guest accounts, when accessing Microsoft resources.
Verify device
Our first step toward device verification was enrolling devices into a device-management system. We have since completed the rollout of device management for Windows, Mac, iOS, and Android. Many of our high-traffic applications and services, such as Microsoft 365 and VPN, enforce device health for user access. Additionally, we’ve started using device management to enable proper device health validation, a foundational component that allows us to set and enforce health policies for devices accessing Microsoft resources. We’re using Windows Autopilot for device provisioning, which ensures that all new Windows devices delivered to employees are already enrolled in our modern device management system.
Devices accessing the corporate wireless network must also be enrolled in the device-management system. This includes both Microsoft–owned devices and personal BYOD devices. If employees want to use their personal devices to access Microsoft resources, the devices must be enrolled and adhere to the same device-health policies that govern corporate-owned devices. For devices where enrollment in device management isn’t an option, we’ve created a secure access model called Microsoft Azure Virtual Desktop. Virtual Desktop creates a session with a virtual machine that meets the device-management requirements. This allows individuals using unmanaged devices to securely access select Microsoft resources. Additionally, we’ve created a browser-based experience allowing access to some Microsoft 365 applications with limited functionality.
There is still work remaining within the verify device pillar. We’re in the process of enabling device management for Linux devices and expanding the number of applications enforcing device management to eventually include all applications and services. We’re also expanding the number of resources available when connecting through the Virtual Desktop service. Finally, we’re expanding device-health policies to be more robust and enabling validation across all applications and services.
Verify access
In the verify access pillar, our focus is on segmenting users and devices across purpose-built networks, migrating all Microsoft employees to use the internet as the default network, and automatically routing users and devices to appropriate network segments. We’ve made significant progress in our network-segmentation efforts. We have successfully deployed several network segments, both for users and devices, including the creation of a new internet-default wireless network across all Microsoft buildings. All users have received policy updates to their systems, thus making this internet-based network their new default.
As part of the new wireless network rollout, we also deployed a device-registration portal. This portal allows users to self-identify, register, or modify devices to ensure that the devices connect to the appropriate network segment. Through this portal, users can register guest devices, user devices, and IoT devices.
We’re also creating specialized segments, including purpose-built segments for the various IoT devices and scenarios used throughout the organization. We have nearly completed the migration of our highest-priority IoT devices in Microsoft offices into the appropriate segments.
We still have a lot of work to do within the verify access pillar. We’re following the investments in our wireless networks with similar wired network investments. For IoT, we need to complete the migration of the remaining high-priority devices in Microsoft offices and then start on high-priority devices in our datacenters. After these devices are migrated, we’ll start migrating lower-priority devices. Finally, we’re building auto-detection for devices and users, which will route them to the appropriate segment without requiring registration in the device-registration portal.
Verify services
In the verify services pillar, our efforts center on enabling conditional access across all applications and services. To achieve full conditional access validation, a key effort requires modernizing legacy applications or implementing solutions for applications and services that can’t natively support conditional access systems. This has the added benefit of eliminating the dependency on VPN and the corporate network. We’ve enabled auto-VPN for all users, which automatically routes users through the appropriate connection. Our goal is to eliminate the need for VPN and create a seamless experience for accessing corporate resources from the internet. With auto-VPN, the user’s system will transparently determine how to connect to resources, bypassing VPN for resources available directly from the internet or using VPN when connecting to a resource that is only available on the corporate network.
Amid the COVID-19 pandemic, a large percentage of our user population transitioned to work from home. This shift has provided increased use of remote network connectivity. In this environment, we’ve successfully identified and engaged application owners to initiate plans to make these applications or services accessible over the internet without VPN.
While we have taken the first steps toward modernizing legacy applications and services that still use VPN, we are in the process of establishing clear plans and timelines for enabling access from the internet. We also plan to invest in extending the portfolio of applications and services enforcing conditional access beyond Microsoft 365 and VPN.
Zero Trust architecture with Microsoft services
The graphic below provides a simplified reference architecture for our approach to implementing Zero Trust. The primary components of this process are Intune for device management and device security policy configuration, Microsoft Azure Active Directory (Azure AD) conditional access for device health validation, and Azure AD for user and device inventory.
The system works with Intune, by pushing device configuration requirements to the managed devices. The device then generates a statement of health, which is stored in Microsoft Azure AD. When the device user requests access to a resource, the device health state is verified as part of the authentication exchange with Azure AD.
A transition that’s paying off
Our transition to a Zero Trust model has made significant progress. Over the last several years, we’ve increased identity-authentication strength with expanded coverage of strong authentication and a transition to biometrics-based authentication by using Windows Hello for Business. We’ve deployed device management and device-health validation capabilities across all major platforms and will soon add Linux. We’ve also launched a Windows Virtual Desktop system that provides secure access to company resources from unmanaged devices.
As we continue our progress, we’re making ongoing investments in Zero Trust. We’re expanding health-validation capabilities across devices and applications, increasing the Virtual Desktop features to cover more use cases, and implementing better controls on our wired network. We’re also completing our IoT migrations and segmentation and modernizing or retiring legacy applications to enable us to deprecate VPN.
Each enterprise that adopts Zero Trust will need to determine what approach best suits their unique environment. This includes balancing risk profiles with access methods, defining the scope for the implementation of Zero Trust in their environments, and determining what specific verifications they want to require for users to gain access to their company resources. In all of this, encouraging the organization-wide embrace of Zero Trust is critical to success, no matter where you decide to begin your transition.
- Collect telemetry and evaluate risks, and then set goals.
- Get to modern identity and MFA—then onboard to AAD.
- For conditional access enforcement, focus on top used applications to ensure maximum coverage.
- Start with simple policies for device health enforcement such as device lock or password complexity.
- Run pilots and ringed rollouts. Slow and steady wins the race.
- Migrate your users to the Internet and monitor VPN traffic to understand internal dependencies.
- Focus on user experience as it is critical to employee productivity and morale. Without adoption, your program will not be a success.
- Communication is key—bring your employees on the journey with you!
- Assign performance indicators and goals for all workstreams and elements, including employee sentiment.
