Zero Trust security model

Introduction
Cloud applications and the mobile workforce have redefined the security perimeter.
Employees are bringing their own devices and working remotely. Data is being
accessed outside the corporate network and shared with external collaborators such
as partners and vendors. Corporate applications and data are moving from on-
premises to hybrid and cloud environments.

The new perimeter isn’t defined by the physical location(s) of the organization—it
now extends to every access point that hosts, stores, or accesses corporate resources
and services. Interactions with corporate resources and services now often bypass
on-premises perimeter-based security models that rely on network firewalls and
VPNs. Organizations which rely solely on on-premises firewalls and VPNs lack the
visibility, solution integration, and agility to deliver timely, end-to-end security
coverage.

Today, organizations need a new security model that more effectively adapts to the
complexity of the modern environment, embraces the mobile workforce, and
protects people, devices, applications, and data wherever they are located. This is the
core of Zero Trust.

Instead of believing everything behind a corporate firewall is safe, the Zero Trust
model assumes breach and verifies each request as though it originates from an
uncontrolled network. Regardless of where the request originates or what resource it
accesses, Zero Trust teaches us to “never trust, always verify.”

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.

Zero trust model

In a Zero Trust model, every access request is strongly authenticated, authorized
within policy constraints, and inspected for anomalies before being granted access.
Everything from the user’s identity to the application’s hosting environment is
assessed to prevent breach. Micro-segmentation and least privileged access
principles are applied to minimize lateral movement. Finally, rich intelligence and
analytics help us identify what happened, what was compromised, and how to
prevent it from happening again.

The guiding principles of Zero Trust are to:

 Verify explicitly. Always authenticate and authorize based on all

available data points, including user identity, location, device health,
service or workload, data classification, and anomalies.
 Use least privileged access. Limit user access with Just-In-Time and
Just-Enough Access (JIT/JEA), risk-based adaptive policies, and data
protection to protect both data and productivity.
 Assume breach. Minimize breach blast radius and prevent lateral
movement by segmenting access by network, user, devices, and
application awareness. Verify all sessions are encrypted end to end. Use
analytics to get visibility, drive threat detection, and improve defenses.

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 into your organization

A Zero Trust approach should extend throughout the entire digital estate and serve
as an integrated security philosophy and end-to-end strategy. This is done by
implementing Zero Trust controls and technologies across six foundational elements:

 Identities
 Devices
 Applications
 Data
 Infrastructure
 Networks
Each of these six foundational elements is a source of signal, a control plane for
enforcement, and a critical resource to be defended. This makes each an important
area on which to focus investment.

Scope within Microsoft

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.

Identities
Whether they represent people, services, or IOT devices, define the Zero Trust control plane
by identities.

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.

Devices
Once an identity has been granted access to a resource, data can flow to a variety of
different devices—from IoT devices to smartphones, BYOD to partner-managed devices, and
on-premises workloads to cloud hosted servers. This diversity creates a massive attack
surface area, requiring we monitor and enforce device health and compliance for secure
access.

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.
Applications
Applications and APIs provide the interface by which data is consumed. They may be legacy
on-premises, lift-and-shifted to cloud workloads, or modern SaaS applications. Controls and
technologies should be applied to discover Shadow IT, ensure appropriate in-app
permissions, gate access based on real-time analytics, monitor for abnormal behavior,
control of user actions, and validate secure configuration options.

Data
Ultimately, security teams are focused on protecting data. Where possible, data should
remain safe even when it leaves the devices, apps, infrastructure, and networks the
organization controls. Data should be classified, labeled, and encrypted, and access restricted
based on those attributes.

Infrastructure
Infrastructure (whether on-premises servers, cloud-based VMs, containers, or micro-services)
represents a critical threat vector. Assess for version, configuration, and JIT access to harden
defense, use telemetry to detect attacks and anomalies, and automatically block and flag
risky behavior and take protective actions.

Networks
All data is ultimately accessed over network infrastructure. Networking controls can provide
critical “in pipe” controls to enhance visibility and help prevent attackers from moving
laterally across the network. Networks should be segmented (including deeper in-network
micro segmentation), and real-time threat protection, end-to-end encryption, monitoring,
and analytics should be employed.

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

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.
Zero trust implementation
A Zero Trust strategy requires that you verify explicitly, use least privileged access
principles, and assume breach. Azure Active Directory can act as the policy decision
point to enforce your access policies based on user, device, target resource, and
environment insights.

To do this, we need to put Azure Active Directory in the path of every access request
—connecting every user and every app or resource through this identity control
plane. In addition to productivity gains and improved user experiences from single
sign-on (SSO) and consistent policy guardrails, connecting all users and apps
provides Azure AD with the signal to make the best possible decisions about the
authentication/authorization risk.

Connect user, groups and devices

Maintaining a healthy pipeline of your employees’ identities as well as the necessary security
artifacts (groups for authorization and devices for extra access policy controls) puts you in
the best place to use consistent identities and controls, which your on-premises and in the
cloud users already benefit from. We strongly prefer an authentication method that primarily
uses Azure AD (to provide you the best brute force, DDoS, and password spray protection).

Integrate all your app with Azure AD

SSO is not only a convenient feature for users, but it’s also a security posture, as it prevents
users from leaving copies of their credentials in various apps and helps them avoid getting
used to surrendering their credentials due to excessive prompting.
Once you have your users’ identities in Azure AD, you can use Azure AD to automate
provisioning those user identities into your various cloud applications.

Be sure to analyze the logs from Azure AD either in Azure or using a SIEM system of choice.

Enact Zero Trust principles

Once you have the Azure AD foundation in order, you can begin enacting the
principles of Zero Trust.

First principle--verify explicitly--provide Azure AD with a rich set of credentials and

controls that it can use to verify users:

 Roll out Azure Active Directory Multi-Factor Authentication.

 Enable Azure AD Hybrid Join or Azure AD Join.
 Enable Microsoft Intune for managing users mobile devices (EMS).
 Start rolling out passwordless credentials.

Second principle--use least privilege access--use the following tools to give the right
access at the right time:

 Conditional Access to require access controls.

 Secure privileged access with privileged identity management.
 Restrict user consent to applications.
 Manage entitlements to streamline access request and approval.

Third principle--assume breach--consider configuring the following tools to protect

your organization:

 Deploy Azure AD Password Protection.

 Block legacy authentication.
 Enable identity protection.
 Enable restricted session to use in access decisions.
 Enable Conditional Access integration with Microsoft Cloud App Security.
 Enable Microsoft Cloud App Security integration with identity protection.
 Integrate Microsoft Defender for Identity with Microsoft Cloud App
Security.
 Enable Microsoft Defender for Endpoint.

Within your organization, consider creating a Conditional Access policy requiring

Azure Active Directory Multi-Factor Authentication for administrators for quick wins
in your journey towards Zero Trust. To create a Conditional Access policy:

1. Within Azure AD, create a new Conditional Access policy with Directory
roles targeted.
 2. If your organization has a “break-glass” global administrator account,
remember to add the account to the Exclude section. In the following
screenshot, the global administrator role is selected. Consider also
adding these roles:
o Authentication Administrator
o Billing administrator
o Conditional Access administrator
o Exchange administrator
o Helpdesk administrator
o Password administrator
o Security administrator
o SharePoint administrator
o User administrator

3. For Cloud apps or actions, select All cloud apps:

4. Then under Conditions > Client apps (Preview), select Yes to also

target apps that don’t use Modern Authentication:

5. Under Access controls, set Grant Access to Require Multi-factor

authentication:

To enable Azure AD Identity Protection User risk and Sign-in risk policies to allow
access but require self-service password reset or multi-factor authentication:

To create an Intune Mobile Application Management (MAM) without enrollment

policy to protect organization data on mobile devices:

1. Within the Intune portal, select Client Apps -> App protection policies
-> + Create policy -> your targeted platform:
 2. After naming the policy, select from the list of available applications:

3. Under Data protection, select the controls you would like to implement.

If the applications are already being used on mobile devices, consider
limiting the amount of controls to reduce the amount of help-desk calls.

For iOS devices, consider the following settings:

o Blocking backup of org data to iTunes

o Restricting data sharing to only policy-managed apps
o Preventing “save as” of org data (by restricting save as
functionality to OneDrive for Business or SharePoint)
o Restricting cut/copy/paste to policy-managed apps with
paste in.

Policy-managed apps are the ones selected in the previous step.

1. Under Access requirements, you can configure a PIN or sign-in for accessing the
targeted applications, as well as a timeout to recheck for the PIN/sign-in:

Once all of the MAM protection settings have been configured, you must target Users who
will receive the policy. With MAM policies, there is no end-user configuration required. The
policy will automatically be applied when a user logs in to a targeted application on their
mobile device. The end user will just see a notification that the application is protected:

Zero trust transition within Microsoft

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.