Implementing Zero Trust Architecture on Azure Hybrid Cloud

This article outlines an approach to model NIST’s Zero Trust Security Architecture while migrating to MS Azure but still working with hybrid cloud deployments, and using tools and services offered by Azure.

What Is a Zero Trust Architecture (ZTA)?

The term ZTA has been in use in the domain of enterprise security models and architectures for organizations since 2010 when Forrester coined the term but became popular after NIST published it as a framework (SP 800-207, final version published in Aug. 2020). ZTA further got a lot of visibility after the US govt recently mandated all Federal agencies to adopt ZTA.

ZTA evolves security much beyond the scope of the conventional perimeter (AKA enterprise firewalls) based approach. Its core principle is that organizations should not automatically trust anything inside or outside their perimeter(s) and, instead, must verify anything and everything trying to connect to their systems before granting access. 

So, no access should be granted to any resource unless we know who wants to access it and if the principle of least privilege (POLP) is satisfied.

Tenets of ZTA and how Azure-Based Tooling Can Be Employed

I will try to elaborate on the core tenets of ZTA as per NIST (Italicized) and, then, propose the corresponding mapping in the MS Azure services and tooling.

To begin with, following basic infrastructure/configuration changes or enablement of services is a must.

Micro-segmentation: Broad perimeters need to be broken down into smaller networks, each having its own network access. This micro-segmentation approach reduces the threat surface area significantly. In Azure, it’s easily doable using a variety of virtual networks (VNets), each with its custom configuration of Network Security Group (NSG) to restrict the visibility of the resources within the VNets to only desired networks.

A set of microservices can be easily segmented out this way for limiting access on the network.

Azure AD and IAM: Subscribe to Azure Active Directory (AAD), Azure Active Directory Identity Protection, and Azure AD Privileged Identity Management (PIM). This will require AAD Premium P2 licenses.

These advanced tools help with several aspects of Zero Trust Architecture is covered below. AAD can also manage users and groups for hybrid environments very well. There is also an option to use a federated authentication model.

1. All data sources and computing services are considered resources. A network may be composed of multiple classes of devices. A network may also have small footprint devices that send data to aggregators/storage, software as a service (SaaS), systems sending instructions to actuators, and other functions. Also, an enterprise may decide to classify personally owned devices as resources if they can access enterprise-owned resources.

Azure AD allows for the provisioning of users and configuring identity and access management (IAM) for the users using its portal. In addition, it allows for device registrations. Users can register their work as well as personal devices as “trusted” ones. Users get SSO ability as a benefit.

Azure also allows managed identities which allow for machine/application to machine/application access without requiring specific access granted to individual users. One can also create service principal objects and register applications in Azure AD. Together they satisfy SaaS scenarios. 

2. All communication is secured regardless of network location. Network location alone does not imply trust. Access requests from assets located on enterprise-owned network infrastructure (e.g., inside a legacy network perimeter) must meet the same security requirements as access requests and communication from any other non-enterprise-owned network.

For our use cases, this tenet primarily meant API calls from inside the firewall need to be secured as well. Using TLS even for internal API calls/requests, making them offload at API Gateway, which then routes the requests as per rules defined. 

In most cases, generally, only external API calls or requests over HTTP use TLS. Further security enforcement is possible by using TLS even for internal calls to prevent spoofing or MITM attacks.

Micro-segmentation of the services/resources in groups with controlled network access can also help. Preferring Azure Express Route over the public internet for sensitive data can be used for further reducing threat surfaces.

3. Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task. This could mean only “sometime recently” for this particular transaction and may not occur directly before initiating a session or performing a transaction with a resource. However, authentication and authorization to one resource will not automatically grant access to a different resource. 

4. Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes. An organization protects resources by defining what resources it has, who its members are (or ability to authenticate users from a federated community), and what access to resources those members need. For zero trust, client identity can include the user account (or service identity) and any associated attributes assigned by the enterprise to that account or artifacts to authenticate automated tasks. Requesting asset state can include device characteristics such as software versions installed, network location, time/date of request, previously observed behavior, and installed credentials. Behavioral attributes include, but not limited to, automated subject analytics, device analytics, and measured deviations from observed usage patterns. The policy is the set of access rules based on attributes that an organization assigns to a subject, data asset, or application. Environmental attributes may include such factors as requestor network location, time, reported active attacks, etc. These rules and attributes are based on the needs of the business process and acceptable level of risk. Resource access and action permission policies can vary based on the sensitivity of the resource/data. The least privilege principles are applied to restrict both visibility and accessibility.

For tenets #3 and #4, Azure IAM and Privileged Identity Management (PIM) support various features including the setting up of a dynamic policy as explained below. In addition, conditional policies can greatly enhance security by enforcing additional security measures like MFA or password reset. See the bullet points below.

• Use Azure RBAC to manage data-plane access to resources where possible. Examples include Azure Key Vault, a storage account, or a SQL database.
• Deploy Azure AD conditional-access policies for any user with rights to Azure environments. Doing so provides another mechanism to help protect a controlled Azure environment from unauthorized access.
• Enforce multi-factor authentication for any user with rights to the Azure environments. Multi-factor authentication enforcement is a requirement of many compliance frameworks. It greatly lowers the risk of credential theft and unauthorized access.
• Use Azure AD Privileged Identity Management (PIM) to establish zero standing access and least privilege. Map your organization's roles to the minimum level of access needed. Azure AD PIM can either be an extension of existing tools and processes, use Azure native tools as outlined, or use both as needed.
• Use Azure AD PIM access reviews to periodically validate resource entitlements. Access reviews are part of many compliance frameworks. As a result, many organizations will already have a process in place to address this requirement.
• Integrate Azure AD logs with the platform-central Log Analytics workspace. It allows for a single source of truth around log and monitoring data in Azure, which gives organizations cloud-native options to meet requirements around log collection and retention.
• Use Azure Security Center just-in-time access for all infrastructure as a service (IaaS) resources to enable network-level protection for ephemeral user access to IaaS virtual machines.
• Use Azure AD managed identities for Azure resources to avoid authentication based on usernames and passwords. Because many security breaches of public cloud resources originate with credential theft embedded in code or other text sources, enforcing managed identities for programmatic access greatly reduces the risk of credential theft.
• Use privileged identities for automation runbooks that require elevated access permissions. Automated workflows that violate critical security boundaries should be governed by the same tools and policies users of equivalent privilege are.

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted. The enterprise evaluates the security posture of the asset when evaluating a resource request. An enterprise implementing a ZTA should establish a continuous diagnostics and mitigation (CDM) or similar system to monitor the state of devices and applications and should apply patches/fixes as needed. Assets that are discovered to be subverted, have known vulnerabilities, and/or are not managed by the enterprise may be treated differently (including denial of all connections to enterprise resources) than devices owned by or associated with the enterprise that is deemed to be in their most secure state. An enterprise implementing a ZTA would be expected to have Identity, Credentials, and Access Management (ICAM) and asset management systems in place. This includes the use of multifactor authentication (MFA) for access to some or all enterprise resources. Continual monitoring with possible re-authentication and reauthorization occurs throughout user transactions, as defined and enforced by policy (e.g., time-based, new resource requested, resource modification, anomalous subject activity detected) that strives to achieve a balance of security, availability, usability, and cost-efficiency.

For tenet #5, Azure IAM and Identity Protection together satisfy most of the requirements, as explained below. In addition, services like Azure Identity Protection organizations accomplish  the following three key tasks:

• Automate the detection and remediation of identity-based risks.
• Investigate risks using data in the portal.
• Export risk detection data to third-party utilities for further analysis.

Clubbed with “Conditional Access” policies additional security measures like granting limited time bound access (e.g. during a maintenance window), enforcing multi-factor authentication, and enforcing password reset.

Some of the risks covered by Identity Protection are:

Data from Identity Protection can be exported to other tools for archive and further investigation and correlation. The Microsoft Graph-based APIs allow organizations to collect this data for further processing in a tool such as their SIEM.

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture. An enterprise should collect data about asset security posture, network traffic, and access requests, process that data, and use any insight gained to improve policy creation and enforcement. This data can also be used to provide context for access requests from subjects.

Microsoft Azure offers excellent support on security threat modeling, protection, and analytics. Through Azure Sentinel (Cloud SIEM) and Azure Security Center (Security Dashboard for Hybrid Clouds) we can achieve the following:

• Improve security posture management and threat protection for hybrid cloud workloads.
• Collect data at cloud scale — across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds.
• Detect previously uncovered threats and minimise false positives using analytics and unparalleled threat intelligence from Microsoft.
• Investigate threats with AI and hunt suspicious activities at scale, tapping into decades of cybersecurity work at Microsoft.
• Respond to incidents rapidly with built-in orchestration and automation of common tasks.
• Assess and visualise the security state of your resources in Azure, on-premises and in other clouds with Azure Secure Score.
• Simplify enterprise compliance and view your compliance against regulatory requirements.
• Protect all your hybrid cloud workloads with Azure Defender, which is integrated with Security Centre.
• Use AI and automation to cut through false alarms, quickly identify threats, and streamline threat investigation.

I plan to publish a similar study on AWS and ZTA when time permits. In the meantime, any comments and suggestions are most welcome.