Auditing the Cloud: Microsoft Azure

Author: Adam Kohnke, CISA, CISSP, PNPT
Date Published: 30 September 2020
Related: Azure Audit Program | Digital | English

When it comes to the cloud and the methods used to audit this expanding technology, Amazon Web Services (AWS) is not the only major player. There may not be as many advertisements for Azure, but as of 2019, Microsoft was one of the top-three providers of public cloud services.¹ The following examines the leading public cloud service providers, including a basic financial analysis, and then introduces Microsoft Azure and the audit techniques enterprises can use to assess the Microsoft Azure Platform as a Service (PaaS). The general audit program outlined here is not intended as a prescriptive set of tests that each enterprise should conduct; it is meant to serve as a foundation for the development of security, risk and compliance assessments related to Azure deployments.

From a security audit and risk perspective, a financial analysis of any service provider allows an enterprise to better assess the provider’s maturity (e.g., security services offered, market stability, financial risk from investments, potential for cyberattacks due to size). The larger the technological footprint a service provider offers, the more attention it is likely to receive from cybercriminals. In addition, rapid market expansion may lead to larger gaps between the introduction of new services and the creation and maturation of associated security capabilities, leading to increased risk. Assessment of the financial status of a cloud service provider (CSP) can help IT audit teams and executive management determine whether the provider is growing too quickly in an insecure manner, whether rapid expansion may lead to increased security breaches and whether growth is occurring in a way that deviates from the enterprise risk appetite.

Cloud Service Providers

It is difficult to declare a definitive winner in the category of top public CSP. Microsoft chooses not to publicly disclose total revenue figures specific to Azure.²^,³ As of 2019, AWS was widely accepted as the market leader in both Infrastructure as a Service (IaaS) and overall cloud services, finishing the year with an estimated US$35 billion.⁴ Second place was assumed to belong to Microsoft, whose “Commercial Cloud” portfolio, which includes Azure, LinkedIn Premium and MS Dynamics, ended 2019 with US$38 billion in total revenue for all cloud services combined.⁵ Google Cloud ended 2019 in third place with US$10 billion in total revenue.⁶

THE LARGER THE TECHNOLOGICAL FOOTPRINT A SERVICE PROVIDER OFFERS, THE MORE ATTENTION IT IS LIKELY TO RECEIVE FROM CYBERCRIMINALS.

Financial resources are pouring into the public cloud services market, and a great deal of short-term market growth is expected, potentially creating increased business and security risk for enterprises consuming these services. To minimize such risk, enterprises must develop a fundamental understanding of how to audit public CSPs such as Microsoft Azure.

Microsoft Azure

Microsoft Azure is a cloud computing platform that provides a pay-as-you-go service to both public and private enterprises, renting them compute, power, storage and other services from infrastructure hosted in Microsoft data centers.⁷ As of this writing, Microsoft Azure offers approximately 100 services divided into 13 general categories, including virtual machine (VM) infrastructure capability for Linux and Windows compute workloads; application hosting with full web application programming interface (API) management; Internet of Things (IoT) Software as a Service (SaaS) for secure, centralized device information gathering or relay; and virtual reality (VR) services that allow customers to explore new software possibilities. Figure 1 details the Azure categories and their groupings.⁸

Source: Microsoft, “What Is Azure?,” http://docs.microsoft.com/en-us/learn/modules/welcome-to-azure/2-what-is-azure. Reprinted with permission.

The Microsoft Azure public cloud platform relies on virtualization, which is the separation between a computer’s hardware and its operating system via an abstraction layer known as a hypervisor, which emulates all computer functions in a VM-based environment. The Azure cloud platform extrapolates the virtualization concept on a staggering scale through the implementation of massive server farms dispersed across several geographic areas to provide public cloud services to customers. Each data center has multiple physical server racks, with a hypervisor assigned to each server to control its virtualization operations (e.g., creating and managing VMs, managing allocated compute resources). Microsoft Azure uses the following components to seamlessly manage the individual customer cloud experience: the Azure web portal, the orchestrator and its APIs, a network switch, and fabric controllers, which all directly or indirectly interact with the physical servers and the hypervisors. One server in each rack is assigned the fabric controller software, which directly communicates through the network switch with the orchestrator to manage all actions occurring within Azure, such as creating a VM, assigning storage to the VM, deleting VMs or responding to user requests. User requests to manage Azure resources occur via the Azure web API, which can be accessed by many tools, including the Azure portal and Azure command line interface (CLI). Figure 2 depicts a basic example of a new VM being created via the Azure portal, which, in turn, is packaged by the orchestrator and sent to the fabric controllers for assignment to a physical server for processing of the creation request.⁹

Source: Microsoft, “What Is Azure?,” http://docs.microsoft.com/en-us/learn/modules/welcome-to-azure/2-what-is-azure. Reprinted with permission.

When an enterprise subscribes to Azure cloud services, it establishes the highest-level security boundary, called an Azure tenant. Azure tenants virtually represent the enterprise that has established a relationship with Microsoft Azure; they can be single tenants or multitenants.¹⁰ All tenants are identified by a globally unique identifier (GUID) and rely on the Azure Active Directory (AAD), which serves as the digital identity service model for securing all SaaS, IaaS and PaaS resources within Azure. The next level in the Azure hierarchy is the management group. Management groups allow an enterprise to organize Azure resources into a hierarchy of strategic collections, providing another level of classification and centralized access control that transcends Azure subscriptions; for example, an enterprise can designate a human resources (HR) management group to dictate Azure policy decisions over HR-associated Azure subscriptions and resources, or it can assign a marketing management group to define how resources allocated to marketing can be deployed and accessed. Next, Azure subscriptions are billed service agreements between the enterprise and Microsoft, allowing the use of any number of Microsoft cloud platforms or services, such as the Azure PaaS or Office 365 SaaS.¹¹ The final level is the resource group, which allows the enterprise to logically group similar resources such as Structured Query Language (SQL) databases or VMs together for ease of management, such as by application, by department or by operating environment. Figure 3 illustrates the hierarchy of tenants, management groups, subscriptions, resource groups and resources themselves.¹²^,¹³

Source: Microsoft, “Enterprise Governance Management,” http://docs.microsoft.com/en-us/learn/modules/intro-to-governance/4-management-groups. Reprinted with permission.

Auditing the Azure Cloud Platform

Source: Microsoft, “Cloud Security Is a Shared Responsibility,” http://docs.microsoft.com/en-us/learn/modules/intro-to-security-in-azure/2-shared-responsibility. Reprinted with permission.

Before an audit or security assessment begins, it is important to understand which aspects of Azure the customer is responsible for and which aspects Microsoft is responsible for, as this will help focus audit and assurance activities. Similar to AWS, Azure operates under the shared responsibility model, where, depending on the type of services the customer subscribes to, management of certain aspects of Azure, such as patch management, are handled by Microsoft, by the customer or by both (figure 4).¹⁴

Governance Controls
Governance controls are a key factor in shared responsibility. Even though the cloud provider is primarily responsible for operating certain controls within Azure, the customer has an ethical, professional and moral responsibility to oversee the cloud provider’s activity for every vendor-managed control to the extent possible.

Executive management should clearly define an Azure governance strategy that includes, but is not limited to, the number of tenants allowed (single or multitenant); management groups that are logically organized by business function, geographic location or the like; subscriptions allowed under each management group, which are further divided by operating environment, such as product or development; and strategies to logically group and dictate the type of deployed resources associated with each subscription. As part of its governance strategy, executive management should consider declaring and routinely assessing the physical regions where it deploys Azure resources to ensure service availability, which involves determining whether the region meets regulatory or other compliance needs and whether the region is capable of fulfilling the enterprise’s availability, business continuity and disaster recovery needs.

Governance audits should also assess whether management has included adequate enforcement mechanisms to carry out its governance strategy through the use of Azure policy, which allows the enterprise to control where resources can be deployed (e.g., limiting VM locations to the US Western Region for the IT management group), how many and what type of resources can be deployed (e.g., disallowing the creation of a VM with more than four central processing units [CPUs]), whether resources can be created without tagging them, and many other compliance scenarios.¹⁵ Other key governance-related considerations include the development, implementation and routine assessment of a resource-tagging strategy to support effective cost management, billing forecasts and monitoring of resources that may be impacted in the future. Finally, a governance audit should consider the implementation of routine cloud vendor management practices that are facilitated through the use of Microsoft’s Service Trust portal, which provides the results of Service Organization Controls (SOC), the Federal Risk and Authorization Management Program (FedRAMP), International Organization for Standardization (ISO) 27001, and Payment Card Industry Data Security Standard (PCI DSS) attestations for Azure.¹⁶

Identity and Access Management
Auditing identity and access management (IdAM) begins with an assessment of whether management has declared and documented the rationale for role-based access controls (RBACs) applied to management groups, subscriptions, resource groups and the individuals accessing resources based on their job functions for all Azure tenants. The concept of management groups establishes the basis for effective RBAC, but RBAC within Azure can be implemented against management groups, individual subscriptions and resource groups. To limit the time and resources needed to manage access, the enterprise should consider placing related subscriptions and their resources under associated management groups and then, to the extent possible, configuring a single RBAC assignment for each management group. In this way, access controls cannot be altered by resources or subscription owners lower in the management hierarchy, improving security and allowing easier access management.

Azure can be accessed in many ways, including the Azure web portal, Azure CLI and Azure Powershell. The focus of the audit should expand here by assessing the extent to which management has identified allowable access methods and the individuals assigned to sensitive access roles or groups, such as service contributor or global administrator. Next, the audit should assess whether management has enforced the use of multifactor authentication (MFA) controls for each role or user posing an elevated access risk. This includes considering how management has defined the MFA user access strategy, which can be either per-user MFA or security access group assignments using conditional access policies that permit the enterprise to define conditions that allow or reject user access.¹⁷ Finally, the MFA configuration should be reviewed to determine whether settings such as Trusted Internet Protocols (IPs) are enabled that allow MFA to be bypassed if a request is generated from a specified IP address range or whether there are legacy applications such as Office 2010 that do not support Azure MFA.

THE AUDIT SHOULD ASSESS WHETHER MANAGEMENT HAS ENFORCED THE USE OF MULTIFACTOR AUTHENTICATION (MFA) CONTROLS FOR EACH ROLE OR USER POSING AN ELEVATED ACCESS RISK.

Another key audit topic at the IdAM level is the use of managed service identities (MSIs), which allow a nonhuman Azure resource, such as a VM or SQL database, to authenticate without explicitly presenting credentials.¹⁸ MSIs can increase security by allowing Azure to automatically handle rotating credentials associated with each MSI; this requires much less effort to maintain than prior setups before MSIs became available in Azure. There are some drawbacks to the use of MSIs, such as the limited number of Azure resources that support the use of MSIs and the fact that MSIs only authenticate outbound requests from one resource to another. The audit should focus on the ability to identify the full population of MSIs in use across Azure tenants; the rationale behind their use, as they generate costs; whether the MSI credentials are securely stored and routinely rotated; and whether the associated resources for which the MSI has been created already have embedded credentials, eliminating the need for an MSI to begin with.

To finalize the audit of IdAM controls, the assessment should determine whether the use of single sign-on (SSO) has been leveraged to streamline password and user management in enterprise applications; whether there is a banned password list; whether password policy is enforced to strengthen user credentials; and whether resource protection mechanisms, such as resource locks, are in place to prevent the unauthorized deletion of critical resources within Azure tenants. Resource locks can be set against subscriptions, resource groups and individual resources, permitting the enterprise to set a delete (allowing all actions except delete) or read-only policy that applies regardless of RBAC permissions and serves as a strong control to protect enterprise data from accidental or malicious deletion. Auditors should also assess whether management periodically revalidates access for users and MSIs to certify that access is appropriate based on job responsibilities and that unused accounts and identities are removed from the Azure environment.

Network Controls
The audit of network security controls in Azure includes assessing high-level network architecture and integration points (if any) that have been configured. Microsoft recommends the use of an N-tier architecture where simple web applications are being deployed, such as if the enterprise is migrating on-premises applications to Azure with minimal changes and under certain application development scenarios. The N-tier concept involves segmenting application resources into distinct tiers, such as a web tier or a data tier, and restricting communications between each tier to enhance security.¹⁹ At this level, the audit should determine, at a minimum, whether a demilitarized zone (DMZ) exists in front of deployed web-facing applications, whether a web application firewall (WAF) exists between the application front end and the Internet, whether resources in each tier are configured using distinct subnetworks to isolate each tier, and whether security groups (firewall rules within Azure) and routing rules are properly configured to restrict network traffic between tiers and directly to resources (preventing direct Remote Desktop Protocol [RDP] traffic to VMs and requiring a jump-off box).

Additionally, the audit should determine whether management has configured the Azure Security Center or other monitoring tools to identify Internet-facing resources that do not have network security groups associated with them and whether resources exist that are not secured behind firewalls. Within Azure, Microsoft offers enterprises a basic protection service to thwart common distributed denial of service (DDoS)-based attacks, but for enterprises looking to secure critical data, the Azure DDoS standard solution may be ideal. It has a variety of desirable features that the basic version does not, such as security information and event management (SIEM) tool integration, access to Microsoft DDoS experts, post-attack mitigation reports, and real-time attack metrics that may be useful in preventing future DDoS attacks.²⁰

Finally, audits at the network level should focus on existing network integration points, such as those sourced from the enterprise’s on-premises network or other business partners that may have connections to the Azure platform. Through the use of Azure ExpressRoute, an enterprise can securely integrate on-premises or other networks with Azure, using a redundant Border Gateway Protocol (BGP) connection through an approved third-party connection provider, such as AT&T, that does not interact with the public Internet.²¹ Although Azure ExpressRoute connections increase privacy and minimize public intrusion by not communicating over the Internet, the enterprise must ensure that layer 2 encryption via Media Access Control Security (MACSec) or layer 3 encryption using IP Security (IPSec) is enabled, with the enterprise encryption keys securely stored and rotated within the Azure Key Vault. The type of encryption used depends on the Azure ExpressRoute connectivity model selected (cloud exchange colocation, point-to-point Ethernet or any-to-any IP virtual private network [VPN]) and the enterprise’s specific connectivity requirements.²² Each integration point should be assessed routinely for security appropriateness and justification to exist, and any changes to the connection configuration should result in alerts to the appropriate personnel.

Encryption
Data encryption within Azure depends primarily on the types of resources and Azure services to which the enterprise subscribes. The audit should start with an understanding of the overall data protection or data encryption policy the enterprise has defined for Azure. An assessment of that policy should cover the scope of the tenants, subscriptions and so forth to which the policy applies and the responsible parties who manage the configurations, encryption keys and the like. The encryption policy should also state the accepted algorithms or ciphers (Secure Hash Algorithm [SHA] or Advanced Encryption Standard [AES]), the minimum encryption strength of each algorithm (256 bit vs. 512 bit) applied to each resource type that requires encryption, and under which scenarios data encryption should occur (e.g., upon creation, at rest, in use, in transit).²³ Because encryption is the final protection against unauthorized data manipulation or loss, it is crucial that the data encryption policy is well planned and comprehensive enough to cover all applicable business resources, has proper executive-level support, and is subjected to ongoing monitoring via database auditing or virtual desktop checks to ensure sustained compliance.

There are many encryption options available for data at rest (data stored on a persistent medium such as a hard disk drive) and data in transit (data traveling between public or private networked devices). The Azure disk encryption service allows VM disks to be encrypted using either Bitlocker technology for Windows or dm-crypt for Linux. For both types of encryption keys, storage in the Azure Key Vault is recommended, and it is capable of centrally managing all necessary encryption-based activities such as creating, distributing, rotating and deleting encryption keys, secrets, digital certificates and connection strings.²⁴ The Azure Key Vault has its own separate authentication and authorization function; it can also create multiple vaults for various objects and purposes. The audit should begin by assessing which Azure resources have been designated to integrate and store encryption objects (e.g., keys, certificates) in the Azure Key Vault; the vaults defined in the Azure Key Vault; the appropriateness of the users, accounts and end points, such as workstations, that have access to manage these encryption objects; and whether there is sufficient monitoring to log the users or MSIs accessing or changing objects stored in the Azure Key Vault.

EACH INTEGRATION POINT SHOULD ROUTINELY BE ASSESSED FOR SECURITY APPROPRIATENESS AND JUSTIFICATION TO EXIST, AND ANY CHANGES TO THE CONNECTION CONFIGURATION SHOULD RESULT IN ALERTS TO THE APPROPRIATE PERSONNEL.

The audit should then concentrate on whether the enterprise has defined capabilities to restore accidentally or maliciously deleted key vaults and their contents through an evaluation of the soft-delete and purge-protection features available in the Azure Key Vault.²⁵ A related audit focus at this level is determining whether the enterprise is routinely practicing the deletion and recovery of key vaults and encryption objects to ensure that these mechanisms work as expected and fully support emergency recovery efforts related to security breaches or accidents triggered by personnel.

For any documents, emails or sensitive data produced using Azure resources, the Azure information protection solution can assist with data classification and data protection using a combination of encryption and identity management policies that apply to documents even after they have been sent outside of Azure tenants, reducing data leakage. For information created in Azure, the audit should assess the extent to which the enterprise seeks to classify, label and control access to intellectual property created, stored and transmitted by Azure resources.

Security Incident Response
Assessment of a security incident response plan (SIRP) includes, but is not limited to, determining whether defined roles and responsibilities have been documented and examining the criteria for a security event (an observable occurrence, such as a user connecting to a network), a security incident (a violation of security policy or practice) and a security breach (a security incident that results in the loss of enterprise data and/or system compromise). The SIRP should also detail the various phases of the response and the expected actions by responders, such as preparation, detection and analysis, containment, eradication, recovery, and postmortem. The audit should focus on verifying the existence of an SIRP; ensuring that it has proper executive support within the enterprise; determining whether its scope includes Azure tenants, subscriptions and resources; ensuring that it includes planned incident response exercises and lessons-learned activities; and ascertaining that it is routinely reviewed internally for completeness, accuracy and adequacy.

BECAUSE ENCRYPTION IS THE FINAL PROTECTION AGAINST UNAUTHORIZED DATA MANIPULATION OR LOSS, IT IS CRUCIAL THAT THE DATA ENCRYPTION POLICY IS WELL PLANNED AND COMPREHENSIVE ENOUGH TO COVER ALL APPLICABLE BUSINESS RESOURCES…

To bolster security incident response capabilities, Azure Security Center’s standard subscription can assist in the detection and prevention of and the timely response to security threats affecting not only Azure resources, but also on-premises resources that have been integrated with Azure tenants.²⁶ At this level, the audit should focus on determining whether the enterprise routinely reviews security scores published by the Security Center, prioritizes the control recommendations offered by the Security Center and acts on them in a timely manner. The audit should also identify any security recommendations the enterprise chooses not to act on; these should be documented as security exceptions, with a clear justification for the enterprise’s failure to follow them. These exceptions should require the approval of security and IT operations management, and they should be routinely reassessed to determine whether the conditions justifying the exception are still valid.

In addition, audit activity at the security incident response level should focus on determining whether Azure Security Center alerts have been integrated with the enterprise’s SIEM tool or whether the enterprise has subscribed to an option such as Azure Sentinel, which is capable of expanding security incident response capabilities by performing automated threat detection and reporting using artificial intelligence (AI) or responding to common security incidents using native Security Orchestration Automated Response (SOAR) functions.²⁷ Finally, the audit should ensure that the enterprise has registered its contact information with Microsoft so that it can receive prompt notification of critical security incidents affecting the Azure platform. In addition, the enterprise should subscribe to external threat intelligence feeds that routinely inform it of potential threats impacting Azure resources.

THE ENTERPRISE SHOULD SUBSCRIBE TO EXTERNAL THREAT INTELLIGENCE FEEDS THAT ROUTINELY INFORM IT OF POTENTIAL THREATS IMPACTING AZURE RESOURCES.

Conclusion

The topics discussed here only scratch the surface of security risk and the controls required to address it. The companion Azure audit program²⁸ provides a more comprehensive approach to managing risk factors, but it is only a general recommendation. Each enterprise will subscribe to and configure a different combination of Azure resources. By adopting a risk-based approach and understanding the connections between internal Azure resources and external resources and the data flows in between, an enterprise can obtain a clearer picture of where its primary risk lies and which controls are key to managing that risk. Maintaining some level of assurance will be the primary challenge, requiring enterprises to balance available resources against emerging threats and the malicious actors behind them. With grit, patience and a measured approach, enterprises can increase their chances of operating securely in the Azure cloud and returning tremendous value to their stakeholders.

Endnotes

Adam Kohnke, CISA, CISSP, eJPT

Currently serves as the identity and access management team leader for North American operations at QBE Insurance, Australia’s second largest insurer. He has four years of experience in IT audit within the financial services industries and more than six years of IT service management experience in the healthcare and construction industries.

Home / Resources / ISACA Journal / Issues / 2020 / Volume 5 / Auditing the Cloud Microsoft Azure