Information Technology Navigator

As COVID forced organizations around the world to send their workforce home, creating the work from home (WFH) phenomenon, IT and security teams rapidly focused on Zero Trust approaches to security to mitigate challenges of enabling secure remote work. Modern workplace employees are getting their work done any way they can these days – using personal devices, sharing data through new services, maxing out home WiFi, and collaborating outside the confines of traditional corporate network security. It has created an IT balancing act between security and WFH productivity.

Businesses have quickly discovered that traditional security models which required bringing users and data to ‘safe’ network places, doesn’t scale or provide the needed visibility. Using Zero Trust security principles to secure users, data, and devices (wherever they may be) has become a business imperative almost overnight.

Identity is the Control Plane

Everything is open on the Internet. When your remote users access their cloud-hosted email, virtually all elements of that interaction are outside of the traditional “walled garden.” With the many networks, devices, and applications required for daily business, the only common denominator is the user and therefore, identity is the control plane.

Nearly all corporate resources require some form of authentication, making identity a common denominator across all access requests, whether from a personal device on a public Wi-Fi network or a corporate device inside the network perimeter. Using identity as the control plane enables companies to treat every single access request as untrusted until the user, device, and other factors are fully vetted.

Establishing Identity

Establishing each user’s identity is critical for core of trust for other transactions. If one is unsure of a user’s identity, then no other system access control or security matters. Once we can confirm who the user is, we can explicitly verify every element of access whether resources are on-premises, in cloud-hosted servers, or managed by third-party SaaS apps such as Microsoft 365.

Zero Trust Framework

A Zero Trust framework represents a cultural shift from network-based controls to identity-based policies and processes. When it comes to securing your Microsoft and Office 365 services, Azure Active Directory (AD) is at the heart of the Zero Trust strategy. Azure AD provides critical functionality for your Zero Trust strategy by enabling strong authentication, a point of integration for device security, and the core of your user-centric policies to guarantee least-privileged access.

Azure AD’s capabilities are the policy decision point for access to resources based on user identity, environment, device health, and risk—verified explicitly at the point of access. You can implement a Zero Trust strategy with Azure AD whether your identity foundation with Azure AD is cloud only, AD Synced w/Pwd hash or passthrough authentication, or federated identities.

Identity is the best starting point for Zero Trust. Users can have multiple devices and access enterprise resources from a variety of networks and apps. A Zero Trust strategy requires that we verify explicitly, use least privileged access principles, and assume breach. Let’s start with the principle of Verify Explicitly.

Ways to Enact the Principle of Verify Explicitly

MFA is a foundational element to reduce user session risk. As users appear on new devices and attempt login from new locations, being able to respond to an MFA challenge is one of the most certain ways that your users can teach us that these are familiar devices/locations as they move around the world (without having administrators parse individual signals). Most organizations have deployed one form or another of MFA at this point in time. The most common use cases are:

• To protect administrators 
• To access specific apps, Microsoft or 3^rd party  
• To protect all users 
• To secure access from network locations you don't trust 
• To protect management of Azure IaaS and PaaS 

Tying the device to user identity information signals a green light for controls.

If you are managing a user’s laptop/computer, you can bring that information into Azure AD and use it to help make better decisions. For example, you may choose to allow rich client access to data (clients that have offline copies on their computer) if you know the user is coming from a machine that your organization controls and manages. If you do not bring this in, you will likely choose to block access from rich clients, which may result in your users working around your security or using Shadow IT.

3. Enable Microsoft Intune for Mobile Devices

The same can be said about users’ mobile devices. The more you know about them (patch level, jailbroken, rooted, etc.) the more you are able to trust or mistrust them and provide a rationale for why you should block/allow access

Ways to Enact the Principle of Least Privilege:

1. Implement Conditional Access

Conditional Access is at the heart of the new identity-driven control plane. If you are already involved in Conditional Access implementation you should make sure that you have a set of fallback policies.

If you're not yet using Conditional Access you’ll need:

• Licensing requirements for Conditional Access features - AAD P1/2
• Common Conditional Access policies based on Microsoft recommended security defaults

Typical policies deployed by organizations are:

• Block legacy authentication*
• Require MFA for administrators*
• Require MFA for Azure management*
• Require MFA for all users*

* These four policies when configured together, mimic functionality enabled by security defaults.

• Additional recommended policies include:
  • Sign-in risk-based Conditional Access (Requires Azure AD Premium P2)
  • User risk-based Conditional Access (Requires Azure AD Premium P2)
  • Require trusted location for MFA registration
  • Block access by location
  • Require compliant device
  • Block access except specific apps
• Deploy Trusted IP locations
  • Configuring these IPs informs the risk of Identity Protection mentioned above
  • Troubleshooting Conditional Access using the What If tool
• Plan an Azure AD reporting and monitoring deployment (i.e., review of user sign-ins to services)

2. Secure Privileged Access with Privileged Identity Management

Privileged access is not only administrative access, but also application owner or developer access that can change the way your mission critical apps run and handle data. Microsoft recommends developing and following a stage-based roadmap to secure privileged access against cyber attackers. Adjust your roadmap to accommodate your existing capabilities and specific requirements within your organization. It is best to start by scheduling the quickest and most effective implementations first with the following:

• Implement least privilege delegation
• Review existing assignments to roles and map out assignments
• Create permanent or eligible role assignments
• Review audit log for visibility of roles activity

3. Restrict User Consent to Applications

Restrict user consent and manage consent requests can provide a quick win to ensure that no unnecessary exposure of your organization’s data or apps occurs. It is also recommended that you review prior/existing consent in your organization for any excessive or malicious consent. This feature will disable all future user consent operations to any application.

AAD > Enterprise apps > Users can consent to apps accessing and can be done in M365 admin center > Settings > Org settings User consent to apps or in Azure AD > Enterprise Apps

Detect and Remediate

The simplest way to verify the Illicit Consent Grant attack is to run GetAzureADPSPermissions.ps1, this script will dump all the OAuth consent grants and OAuth apps for all users in your tenancy into one .csv file and enable you to identify valid vs illicit apps and remove the illicit apps.

Assume Breach

Lastly, you can implement the principle of Assume Breach by:  

While enabling other methods to verify users explicitly, you should not forget about weak passwords, password spray and breach replay attacks. Azure AD Password Protection (both in the cloud and on-prem) detects and blocks known weak passwords and their variants and can also block additional weak terms that are specific to your organization.

2. Blocking Legacy Authentication

One of the most common attack vectors for malicious actors is to use stolen/replayed credentials against legacy protocols, such as SMTP, IMAP or POP that cannot handle modern security challenges. We recommend blocking legacy authentication in your organization. Even if your business isn’t ready to block legacy authentication across the entire company, you should ensure that sign-ins using legacy authentication aren’t bypassing policies that require grant controls such as requiring multi-factor authentication or compliant/hybrid Azure AD joined devices. During authentication, legacy authentication clients do not support sending MFA, device compliance, or join state information to Azure AD. Therefore, apply policies with grant controls to all client applications so that legacy authentication-based sign-ins that cannot satisfy the grant controls are blocked. With the general availability of the client apps condition in August 2020, newly created Conditional Access policies apply to all client apps by default.

When a user’s risk is low, but they are signing in from an unknown device, you may want to allow them access to critical resources, but not allow them to do things that leave your organization in a non-compliant state. Now you can configure Exchange Online and SharePoint Online to offer the user a restricted session that allows them to read emails or view files, but not download them and save them on an untrusted device.

I hope this clarifies Zero Trust for Identities points of implementation. Remember, with the Zero Trust strategy:

• It’s a journey
• Start small and expand
• Pilot, test and learn
• Align to existing initiatives with
  • Technology upgrades
  • Cloud service adoption – Microsoft 365/Office 365 

Major Phases of Zero Trust

Zero Trust was a topic we covered at one of our Cloud Clinic sessions – a series of complimentary training webinars. My colleagues and I have authored blogs on Azure Reserved Instances, Azure Sentinel and Continuous Access Evaluation to explain how these features work. I encourage you to check them out. We’ll be hosting more Cloud Clinics in 2021. Follow us on Twitter @Daymarksi to keep up with new topics and dates. And feel free to contact me if you have questions or need help adopting a Zero Trust strategy.