Microsoft is implementing a Zero Trust security model to ensure a healthy and protected environment by using the internet as the default network with strong identity, device health enforcement, and least privilege access.

EXPLORE RELATED CONTENT

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 Microsoft to adopt a Zero Trust security model. The journey began a few years ago and will continue to evolve for years to come.

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 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 can validate multifactor authentication and device health.
  • Scenario 2. Employees can enroll devices into a modern management system that enforces device health to control access to company resources.
  • Scenario 3. Microsoft employees and business guests have a secure way to access corporate resources when using an unmanaged 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

Microsoft is 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


Pre-Zero Trust characteristics compared to the four pillars of Zero Trust implementation: Verify identity,  Verify device,  Verify access,  and Verify services.

Figure 1. The major goals for each Zero Trust pillar

 

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 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 Windows 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 has 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

Figure 2 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, 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 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.

Users and devices in an unprivileged network

Figure 2. Zero Trust architecture

 

A transition in progress

Our transition to a Zero Trust model has made significant progress. Over the past two 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.


You might also be interested in

Flipping the retail metaverse on its head with augmented reality shopping
October 15, 2021

Flipping the retail metaverse on its head with augmented reality shopping

Read blog
Prioritizing accessibility at Microsoft with feedback from people with disabilities
October 13, 2021

Prioritizing accessibility at Microsoft with feedback from people with disabilities

Read blog
Boosting Microsoft’s response to cybersecurity attacks with Microsoft Azure Sentinel
October 12, 2021

Boosting Microsoft’s response to cybersecurity attacks with Microsoft Azure Sentinel

Read blog
Moving to next-generation SIEM with Azure Sentinel
October 06, 2021

Moving to next-generation SIEM with Azure Sentinel

Read case study