CIS Microsoft Azure Foundations Benchmark v4.0.0

Level 1

2 Common Reference Recommendations

2.1 Secrets and Keys

Microsoft Managed Keys (MMK) (also known as Platform-managed keys (PMK)) provides a very low overhead method of encrypting data at rest and implementing encryption key management. Keys maintained in an MMK implementation are automatically managed by Azure and require no customer interaction.

By default, Encryption type is set to Microsoft Managed Keys.

Manual

The encryption of data at rest is a foundational component of data security. Data at rest without encryption is easily compromised through loss or theft. Encrypting data at rest introduces confidentiality to the data by obfuscating the data contents with a cipher algorithm and provides an authentication requirement through the use of cryptographic keys. MMK makes the encryption of data at rest very easy to implement and maintain.

Level 2

2 Common Reference Recommendations

2.1 Secrets and Keys

Customer Managed Keys introduce additional depth to security by providing a means to manage access control for encryption keys. Where compliance and security frameworks indicate the need, and organizational capacity allows, sensitive data at rest can be encrypted using Customer Managed Keys (CMK) rather than Microsoft Managed keys.

By default, Encryption type is set to Microsoft Managed Keys.

If the key expires due to setting the 'activation date' and 'expiration date', the key must be rotated manually. Using Customer Managed Keys may also incur additional man-hour requirements to create, store, manage, and protect the keys as needed.

Manual

By default in Azure, data at rest tends to be encrypted using Microsoft Managed Keys. If your organization wants to control and manage encryption keys for compliance and defense-in-depth, Customer Managed Keys can be established. While it is possible to automate the assessment of this recommendation, the assessment status for this recommendation remains 'Manual' due to ideally limited scope. The scope of application - which workloads CMK is applied to - should be carefully considered to account for organizational capacity and targeted to workloads with specific need for CMK.

Level 1

2 Common Reference Recommendations

2.2 Networking

Disable public network access to prevent exposure to the internet and reduce the risk of unauthorized access. Use private endpoints to securely manage access within trusted networks.

Disabling public network access restricts access to the service. This enhances security but may require the configuration of private endpoints for any services or users needing access within trusted networks.

Automated

Disabling public network access improves security by ensuring that a service is not exposed on the public internet.

This Common Reference Recommendation is referenced in the following Service Recommendations: - Storage Services > Storage Accounts > Networking > Ensure that 'Public Network Access' is 'Disabled' for storage accounts

Level 1

2 Common Reference Recommendations

2.2 Networking

Restricting default network access provides a foundational level of security to networked resources. To limit access to selected networks, the default action must be changed.

By default, interfaces attached to virtual networks will accept connections from clients on any network and have a default outbound access rule which allows access to the internet. The default outbound access rule is scheduled for retirement on September 30th, 2025: https://azure.microsoft.com/en-us/updates?id=default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access

All allowed networks and protocols will need to be allow-listed which creates some administrative overhead. Implementing a deny-by-default rule may result in a loss of network connectivity. Careful planning and a scheduled implementation window allowing for downtime is highly recommended.

Automated

Resources using Virtual Network interfaces should be configured to deny-by-default all access from all networks (including internet traffic). Access can be granted to traffic from specific Azure Virtual networks, allowing a secure network boundary for specific applications to be built. If necessary, access can also be granted to public internet IP address ranges to enable connections from specific internet or on-premises clients. For all traffic inbound from- and outbound to- the internet, a NAT Gateway is recommended at minimum, and ideally all traffic flows through a security gateway device such as a firewall. Security gateway devices will provide an additional level of visibility to inbound and outbound traffic and usually perform advanced monitoring and response activity such as intrusion detection and prevention (IDP), and deep packet inspection (DPI) which help detect activity indicating vulnerabilities and threats.

This Common Reference Recommendation is referenced in the following Service Recommendations: - Storage Services > Storage Accounts > Networking > Ensure default network access rule for storage accounts is set to deny

Level 2

2 Common Reference Recommendations

2.2 Networking

Use private endpoints to allow clients and services to securely access data located over a network via an encrypted Private Link. To do this, the private endpoint uses an IP address from the VNet for each service. Network traffic between disparate services securely traverses encrypted over the VNet. This VNet can also link addressing space, extending your network and accessing resources on it. Similarly, it can be a tunnel through public networks to connect remote infrastructures together. This creates further security through segmenting network traffic and preventing outside sources from accessing it.

By default, Private Endpoints are not created for services.

If an Azure Virtual Network is not implemented correctly, this may result in the loss of critical network traffic. Private endpoints are charged per hour of use. Refer to https://azure.microsoft.com/en-us/pricing/details/private-link/ and https://azure.microsoft.com/en-us/pricing/calculator/ to estimate potential costs.

Automated

Securing traffic between services through encryption protects the data from easy interception and reading.

A NAT gateway is the recommended solution for outbound internet access. This Common Reference Recommendation is referenced in the following Service Recommendations: - Storage Services > Storage Accounts > Networking > Ensure Private Endpoints are used to access Storage Accounts

Level 1

3 Analytics Services

3.1 Azure Databricks

Networking for Azure Databricks can be set up in a few different ways. Using a customer-managed Virtual Network (VNet) (also known as VNet Injection) ensures that compute clusters and control planes are securely isolated within the organization’s network boundary. By default, Databricks creates a managed VNet, which provides limited control over network security policies, firewall configurations, and routing.

By default, Azure Databricks uses a Databricks-Managed VNet.

Audit from Azure Portal 1. Go to Azure Portal → Search for Databricks Workspaces. 1. Select the Databricks Workspace to audit. 1. Under Networking, check if the workspace is deployed in a Customer-Managed VNet. 1. If the Virtual Network field shows Databricks-Managed VNet, it is non-compliant. 1. Verify NSG rules and Private Endpoints for fine-grained access control. Audit from Azure CLI Run the following command to check if Databricks is using a customer-managed VNet: az network vnet show --resource-group <resource-group-name> --name <vnet-name> Ensure that Databricks subnets are present in the VNet configuration. Validate NSG rules attached to the Databricks subnets. Audit from PowerShell Get-AzDatabricksWorkspace -ResourceGroupName <resource-group-name> -Name <databricks-workspace-name> | Select-Object VirtualNetworkId If VirtualNetworkId is null or shows a Databricks-Managed VNet, it is non-compliant. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 9c25c9e4-ee12-4882-afd2-11fb9d87893f - Name: 'Azure Databricks Workspaces should be in a virtual network'

• Requires additional configuration during Databricks workspace deployment. - Might increase operational overhead for network maintenance. - May impact connectivity if misconfigured (e.g., restrictive NSG rules or missing routes).

Automated

Using a customer-managed VNet ensures better control over network security and aligns with zero-trust architecture principles. It allows for: - Restricted outbound internet access to prevent unauthorized data exfiltration. - Integration with on-premises networks via VPN or ExpressRoute for hybrid connectivity. - Fine-grained NSG policies to restrict access at the subnet level. - Private Link for secure API access, avoiding public internet exposure.

Remediate from Azure Portal 1. Delete the existing Databricks workspace (migration required). 1. Create a new Databricks workspace with VNet Injection: 1. Go to Azure Portal → Create Databricks Workspace. 1. Select Advanced Networking. 1. Choose Deploy into your own Virtual Network. 1. Specify a customer-managed VNet and associated subnets. 1. Enable Private Link for secure API access. Remediate from Azure CLI Deploy a new Databricks workspace in a custom VNet: az databricks workspace create --name <databricks-workspace-name> \ --resource-group <resource-group-name> \ --location <region> \ --managed-resource-group <managed-rg-name> \ --enable-no-public-ip true \ --network-security-group-rule NoAzureServices \ --public-network-access Disabled \ --custom-virtual-network-id /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name> Ensure NSG Rules are correctly configured: az network nsg rule create --resource-group <resource-group-name> \ --nsg-name <nsg-name> \ --name DenyAllOutbound \ --direction Outbound \ --access Deny \ --priority 4096 Remediate from PowerShell New-AzDatabricksWorkspace -ResourceGroupName <resource-group-name> -Name <databricks-workspace-name> -Location <region> -ManagedResourceGroupName <managed-rg-name> -CustomVirtualNetworkId /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name>

Level 1

3 Analytics Services

3.1 Azure Databricks

Network Security Groups (NSGs) should be implemented to control inbound and outbound traffic to Azure Databricks subnets, ensuring only authorized communication. NSGs should be configured with deny rules to block unwanted traffic and restrict communication to essential sources only.

By default, Databricks subnets do not have NSGs assigned.

Audit from Azure Portal 1. Navigate to Virtual Networks > Subnets, and review NSG assignments. Audit from Azure CLI az network nsg list --query [].{Name:name, Rules:securityRules} Audit from PowerShell Get-AzNetworkSecurityGroup -ResourceGroupName <resource-group-name>

• NSGs require periodic maintenance to ensure rule accuracy. * Misconfigured NSGs could inadvertently block required traffic.

Manual

Remediate from Azure Portal 1. Assign NSG to Databricks subnets under Networking > NSG Settings.

Level 2

3 Analytics Services

3.1 Azure Databricks

By default, data exchanged between worker nodes in an Azure Databricks cluster is not encrypted. To ensure that data is encrypted at all times, whether at rest or in transit, you can create an initialization script that configures your clusters to encrypt traffic between worker nodes using AES 256-bit encryption over a TLS 1.3 connection.

By default, traffic is not encrypted between cluster worker nodes.

Audit from Azure Portal Review cluster init scripts: 1. Navigate to your Azure Databricks workspace, go to the Clusters section, select a cluster, and check the Advanced Options for any init scripts that configure encryption settings. Verify spark configuration: 2. Ensure that the following Spark configurations are set: spark.authenticate true spark.authenticate.enableSaslEncryption true spark.network.crypto.enabled true spark.network.crypto.keyLength 256 spark.network.crypto.keyFactoryAlgorithm PBKDF2WithHmacSHA1 spark.io.encryption.enabled true These settings can be found in the cluster's Spark configuration properties. Check keystone management: 3. Verify that the Java KeyStore (JKS) file is securely stored in DBFS and that its integrity is maintained. 4. Ensure that the keystore password is securely managed and not hardcoded in scripts.

• Enabling encryption may introduce a performance penalty due to the computational overhead associated with encrypting and decrypting traffic. This can result in longer query execution times, especially for data-intensive operations. * Implementing encryption requires creating and managing init scripts, which adds complexity to cluster configuration and maintenance. * The shared encryption secret is derived from the hash of the keystore stored in DBFS. If the keystore is updated or rotated, all running clusters must be restarted to prevent authentication failures between Spark workers and drivers.

Manual

• Protects sensitive data during transit between cluster nodes, mitigating risks of data interception or unauthorized access. * Aligns with organizational security policies and compliance requirements that mandate encryption of data in transit. * Enhances overall security posture by ensuring that all inter-node communications within the cluster are encrypted.

Create a JKS keystore: 1. Generate a Java KeyStore (JKS) file that will be used for SSL/TLS encryption. 2. Upload the keystore file to a secure directory in DBFS (e.g. /dbfs/<keystore-directory>/jetty_ssl_driver_keystore.jks). Develop an init script: 3. Create an init script that performs the following tasks: - Retrieves the JKS keystore file and password. - Derives a shared encryption secret from the keystore. - Configures Spark driver and executor settings to enable encryption. 4. Example init script: #!/bin/bash set -euo pipefail keystore_dbfs_file=/dbfs/<keystore-directory>/jetty_ssl_driver_keystore.jks max_attempts=30 while [ ! -f ${keystore_dbfs_file} ]; do if [ $max_attempts == 0 ]; then echo ERROR: Unable to find the file : $keystore_dbfs_file. Failing the script. exit 1 fi sleep 2s ((max_attempts--)) done sasl_secret=$(sha256sum $keystore_dbfs_file | cut -d' ' -f1) if [ -z ${sasl_secret} ]; then echo ERROR: Unable to derive the secret. Failing the script. exit 1 fi local_keystore_file=$DB_HOME/keys/jetty_ssl_driver_keystore.jks local_keystore_password=gb1gQqZ9ZIHS if [[ $DB_IS_DRIVER = TRUE ]]; then driver_conf=${DB_HOME}/driver/conf/spark-branch.conf echo Configuring driver conf at $driver_conf if [ ! -e $driver_conf ]; then echo spark.authenticate true >> $driver_conf echo spark.authenticate.secret $sasl_secret >> $driver_conf echo spark.authenticate.enableSaslEncryption true >> $driver_conf echo spark.network.crypto.enabled true >> $driver_conf echo spark.network.crypto.keyLength 256 >> $driver_conf echo spark.network.crypto.keyFactoryAlgorithm PBKDF2WithHmacSHA1 >> $driver_conf echo spark.io.encryption.enabled true >> $driver_conf echo spark.ssl.enabled true >> $driver_conf echo spark.ssl.keyPassword $local_keystore_password >> $driver_conf echo spark.ssl.keyStore $local_keystore_file >> $driver_conf echo spark.ssl.keyStorePassword $local_keystore_password >> $driver_conf echo spark.ssl.protocol TLSv1.3 >> $driver_conf fi fi executor_conf=${DB_HOME}/conf/spark.executor.extraJavaOptions echo Configuring executor conf at $executor_conf if [ ! -e $executor_conf ]; then echo -Dspark.authenticate=true >> $executor_conf echo -Dspark.authenticate.secret=$sasl_secret >> $executor_conf echo -Dspark.authenticate.enableSaslEncryption=true >> $executor_conf echo -Dspark.network.crypto.enabled=true >> $executor_conf echo -Dspark.network.crypto.keyLength=256 >> $executor_conf echo -Dspark.network.crypto.keyFactoryAlgorithm=PBKDF2WithHmacSHA1 >> $executor_conf echo -Dspark.io.encryption.enabled=true >> $executor_conf echo -Dspark.ssl.enabled=true >> $executor_conf echo -Dspark.ssl.keyPassword=$local_keystore_password >> $executor_conf echo -Dspark.ssl.keyStore=$local_keystore_file >> $executor_conf echo -Dspark.ssl.keyStorePassword=$local_keystore_password >> $executor_conf echo -Dspark.ssl.protocol=TLSv1.3 >> $executor_conf fi 5. Save.

Level 1

3 Analytics Services

To ensure centralized identity and access management, users and groups from Microsoft Entra ID should be synchronized with Azure Databricks. This is achieved through SCIM provisioning, which automates the creation, update, and deactivation of users and groups in Databricks based on Entra ID assignments. Enabling this integration ensures that access controls in Databricks remain consistent with corporate identity governance policies, reducing the risk of orphaned accounts, stale permissions, and unauthorized access.

By default, Azure Databricks does not sync users and groups from Microsoft Entra ID.

Audit from Azure Portal Verify SCIM provisioning is enabled: 1. Go to Microsoft Entra ID. 1. Under Manage, click Enterprise applications. 1. Click the name of the Azure Databricks SCIM application. 1. Under Provisioning, confirm that SCIM provisioning is enabled and running. Check user sync status in Azure Portal: 5. Under Provisioning Logs, verify the last successful sync and any failed entries. Check user sync status in Databricks: 6. Go to Admin Console > Identity and Access Management. 7. Confirm that Users and Groups match those assigned in Microsoft Entra ID. Ensure role-based access control (RBAC) mapping is correct: 8. Verify that users are assigned appropriate Databricks roles (e.g. Admin, User, Contributor). 9. Confirm that groups are mapped to workspace access roles.

SCIM provisioning requires role mapping to avoid misconfigured user privileges.

Manual

Syncing users and groups from Microsoft Entra ID centralizes access control, enforces the least privilege principle by automatically revoking unnecessary access, reduces administrative overhead by eliminating manual user management, and ensures auditability and compliance with industry regulations.

Remediate from Azure Portal Enable provisioning in Azure Portal: 1. Go to Microsoft Entra ID. 1. Under Manage, click Enterprise applications. 1. Click the name of the Azure Databricks SCIM application. 1. Under Provisioning, select Automatic and enter the SCIM endpoint and API token from Databricks. Enable provisioning in Databricks: 5. Navigate to Admin Console > Identity and Access Management. 6. Enable SCIM provisioning and generate an API token. Configure role assignments: 7. Ensure groups from Entra ID are mapped to appropriate Databricks roles. 8. Restrict administrative privileges to designated security groups. Regularly monitor sync logs: 9. Periodically review sync logs in Microsoft Entra ID and Databricks Admin Console. 10. Configure Azure Monitor alerts for provisioning failures. Disable manual user creation in Databricks: 11. Ensure that all user management is controlled via SCIM sync from Entra ID. 12. Disable personal access token usage for authentication. Remediate from Azure CLI Enable SCIM User and Group Provisioning in Azure Databricks: az ad app update --id <databricks-app-id> --set provisioning.provisioningMode=Automatic

Level 1

3 Analytics Services

3.1 Azure Databricks

Unity Catalog is a centralized governance model for managing and securing data in Azure Databricks. It provides fine-grained access control to databases, tables, and views using Microsoft Entra ID identities. Unity Catalog also enhances data lineage, audit logging, and compliance monitoring, making it a critical component for security and governance.

New workspaces have Unity Catalog enabled by default. Existing workspaces may require manual enablement.

Method 1: Verify unity catalog deployment: 1. As an Azure Databricks account admin, log into the account console. 1. Click Workspaces. 1. Find your workspace and check the Metastore column. If a metastore name is present, your workspace is attached to a Unity Catalog metastore and therefore enabled for Unity Catalog. Method 2: Run a SQL query to confirm Unity Catalog enablement Run the following SQL query in the SQL query editor or a notebook that is attached to a Unity Catalog-enabled compute resource. No admin role is required. SELECT CURRENT_METASTORE(); If the query returns a metastore ID like the following, then your workspace is attached to a Unity Catalog metastore and therefore enabled for Unity Catalog.

• Improperly configured permissions may lead to data exfiltration or unauthorized access. * Unity Catalog requires structured governance policies to be effective and prevent overly permissive access.

Manual

• Enforces centralized access control policies and reduces data security risks. * Enables identity-based authentication via Microsoft Entra ID. * Improves compliance with industry regulations (e.g. GDPR, HIPAA, SOC 2) by providing audit logs and access visibility. * Prevents unauthorized data access through table-, row-, and column-level security (RLS & CLS).

Use the remediation procedure written in this article: https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/get-started.

Level 1

3 Analytics Services

3.1 Azure Databricks

Databricks personal access tokens (PATs) provide API-based authentication for users and applications. By default, users can generate API tokens without expiration, leading to potential security risks if tokens are leaked, improperly stored, or not rotated regularly. To mitigate these risks, administrators should: * Restrict token creation to approved users and service principals. * Enforce expiration policies to prevent long-lived tokens. * Monitor token usage and revoke unused or compromised tokens.

By default, personal access tokens are enabled and users can create the Personal access token and their expiry time.

Azure Databricks administrators can monitor and revoke personal access tokens within their workspace. Detailed instructions are available in the Monitor and Revoke Personal Access Tokens section of the Microsoft documentation: https://learn.microsoft.com/en-us/azure/databricks/admin/access-control/tokens. To evaluate the usage of personal access tokens in your Azure Databricks account, you can utilize the provided notebook that lists all PATs not rotated or updated in the last 90 days, allowing you to identify tokens that may require revocation. This process is detailed here: https://docs.azure.cn/en-us/databricks/security/auth/oauth-pat-usage. Implementing diagnostic logging provides a comprehensive reference of audit log services and events, enabling you to track activities related to personal access tokens. More information can be found in the diagnostic log reference section: https://docs.azure.cn/en-us/databricks/security/auth/oauth-pat-usage.

If revoked improperly, applications relying on these tokens may fail, requiring a remediation plan for token rotation. Increased administrative effort is required to track and manage API tokens effectively.

Manual

Restricting usage and enforcing expiry for personal access tokens reduces exposure to long-lived tokens, minimizes the risk of API abuse if compromised, and aligns with security best practices through controlled issuance and enforced expiry.

Remediate from Azure Portal Disable personal access tokens: If your workspace does not require PATs, you can disable them entirely to prevent their use.

Level 1

3 Analytics Services

3.1 Azure Databricks

Azure Databricks Diagnostic Logging provides insights into system operations, user activities, and security events within a Databricks workspace. Enabling diagnostic logs helps organizations: * Detect security threats by logging access, job executions, and cluster activities. * Ensure compliance with industry regulations such as SOC 2, HIPAA, and GDPR. * Monitor operational performance and troubleshoot issues proactively.

Audit from Azure Portal Check if diagnostic logging is enabled for the Databricks workspace: 1. Go to Azure Databricks. 1. Select a workspace. 1. In the left-hand menu, select Monitoring > Diagnostic settings. 1. Verify if a diagnostic setting is configured. If not, diagnostic logging is not enabled. Ensure that logging is enabled for the following categories:

Logs consume storage and may require additional monitoring tools, leading to increased operational overhead and costs. Incomplete log configurations may result in missing critical events, reducing monitoring effectiveness.

Manual

Diagnostic logging provides visibility into security and operational activities within Databricks workspaces while maintaining an audit trail for forensic investigations, and it supports compliance with regulatory standards that require logging and monitoring.

Remediate from Azure Portal Enable diagnostic logging for Azure Databricks: 1. Navigate to your Azure Databricks workspace. 1. In the left-hand menu, select Monitoring > Diagnostic settings. 1. Click + Add diagnostic setting. 1. Under Category details, select the log categories you wish to capture, such as AuditLogs, Clusters, Notebooks, and Jobs. 1. Choose a destination for the logs: - Log Analytics workspace: For advanced querying and monitoring. - Storage account: For long-term retention. - Event Hub: For integration with third-party systems. 1. Provide a Name for the diagnostic setting. 1. Click Save. Implement log retention policies: 1. Navigate to your Log Analytics workspace. 1. Under General, select Usage and estimated costs. 1. Click Data Retention. 1. Adjust the retention period slider to the desired number of days (up to 730 days). 1. Click OK. Monitor logs for anomalies: 1. Navigate to Azure Monitor. 1. Select Alerts > + New alert rule. 1. Under Scope, specify the Databricks resource. 1. Define Condition based on log queries that identify anomalies (e.g. unauthorized access attempts). 1. Configure Actions to notify stakeholders or trigger automated responses. 1. Provide an Alert rule name and description. 1. Click Create alert rule. Remediate from Azure CLI Enable diagnostic logging for Azure Databricks: az monitor diagnostic-settings create --name DatabricksLogging --resource <databricks-resource-id> --logs '[{category: AuditLogs, enabled: true}, {category: Clusters, enabled: true}, {category: Notebooks, enabled: true}, {category: Jobs, enabled: true}]' --workspace <log-analytics-id> Implement log retention policies: az monitor log-analytics workspace update --resource-group <resource-group> --name <log-analytics-name> --retention-time 365 Monitor logs for anomalies: az monitor activity-log alert create --name DatabricksAnomalyAlert --resource-group <resource-group> --scopes <databricks-resource-id> --condition contains 'UnauthorizedAccess'

• Ensure that the Azure Databricks workspace is on the Premium plan to utilize diagnostic logging features. * Regularly review and update alert rules to adapt to evolving security threats and operational requirements.

Level 2

3 Analytics Services

3.1 Azure Databricks

Azure Databricks encrypts data in transit using TLS 1.2+ to secure API, workspace, and cluster communications. By default, data at rest is encrypted using Microsoft-managed keys.

By default, Azure Databricks uses Microsoft-managed keys for encryption. Data in transit is always encrypted using TLS 1.2+. Customer-Managed Keys (CMK) must be manually enabled.

Audit from Azure Portal 1. Go to Azure Portal → Databricks Workspaces. 1. Select a Databricks Workspace and go to Encryption settings. 1. Check if customer-managed keys (CMK) are enabled under Managed Disk Encryption. 1. If CMK is not enabled, the workspace is non-compliant. Audit from Azure CLI Run the following command to check encryption settings for Databricks workspace: az databricks workspace show --name <databricks-workspace-name> --resource-group <resource-group-name> --query encryption Ensure that keySource is set to Microsoft.KeyVault. Audit from PowerShell Get-AzDatabricksWorkspace -ResourceGroupName <resource-group-name> -Name <databricks-workspace-name> | Select-Object Encryption Verify that encryption is set to Customer-Managed Keys (CMK). Audit from Databricks CLI databricks workspace get-metadata --workspace-id <workspace-id> Ensure that encryption settings reflect a CMK setup.

Enabling CMK encryption requires additional configuration. Key management introduces maintenance overhead (rotation, revocation, lifecycle management). Potential access issues will be encountered if keys are deleted or rotated incorrectly.

Automated

Organizations with stricter needs for control of encryption keys should enable customer-managed keys (CMK) for greater control over data encryption, auditing, and regulatory compliance. Azure Key Vault should be used to store and manage CMKs. Enforcing encryption at rest and in transit in Azure Databricks: - Protects sensitive data from unauthorized access. - Ensures regulatory compliance (ISO 27001, GDPR, HIPAA, SOC 2). - Allows key revocation and rotation control with customer-managed keys (CMK). - Mitigates insider threats by preventing unauthorized access to raw storage.

NOTE: These remediations assume that an Azure KeyVault already exists in the subscription. Remediate from Azure CLI 1. Create a dedicated key: az keyvault key create --vault-name <keyvault-name> --name <key-name> --protection <software or hsm> 2. Assign permissions to Databricks: az keyvault set-policy --name <keyvault-name> --resource-group <resource-group-name> --spn <databricks-spn> --key-permissions get wrapKey unwrapKey 3. Enable encryption with CMK: az databricks workspace update --name <databricks-workspace-name> --resource-group <resource-group-name> --key-source Microsoft.KeyVault --key-name <key-name> --keyvault-uri <keyvault-uri> Remediate from PowerShell $Key = Add-AzKeyVaultKey -VaultName <keyvault-name> -Name <key-name> -Destination <software or hsm> Set-AzDatabricksWorkspace -ResourceGroupName <resource-group-name> -WorkspaceName <databricks-workspace-name> -EncryptionKeySource Microsoft.KeyVault -KeyVaultUri $Key.Id

Level 2

4 Compute Services

4.1 Virtual Machines

Verify identities without MFA that can log in to a privileged virtual machine using separate login credentials. An adversary can leverage the access to move laterally and perform actions with the virtual machine's managed identity. Make sure the virtual machine only has necessary permissions, and revoke the admin-level permissions according to the principle of least privilege.

Audit from Azure Portal 1. Log in to the Azure portal. 1. Select the Subscription, then click on Access control (IAM). 1. Click Role : All and click All to display the drop-down menu. 1. Type Virtual Machine Administrator Login and select Virtual Machine Administrator Login. 1. Review the list of identities that have been assigned the Virtual Machine Administrator Login role. 1. Go to Microsoft Entra ID. 1. For Per-user MFA: 1. Under Manage, click Users. 1. Click Per-user MFA. 1. Ensure that none of the identities assigned the Virtual Machine Administrator Login role from step 4 have Status set to disabled. 1. For Conditional Access: 1. Under Manage, click Security. 1. Under Protect, click Conditional Access. 1. Ensure that none of the identities assigned the Virtual Machine Administrator Login role from step 4 are exempt from a Conditional Access policy requiring MFA for all users.

This recommendation requires the Entra ID P2 license to implement. Ensure that identities provisioned to a virtual machine utilize an RBAC/ABAC group and are allocated a role using Azure PIM, and that the role settings require MFA or use another third-party PAM solution for accessing virtual machines.

Manual

Integrating multi-factor authentication (MFA) as part of the organizational policy can greatly reduce the risk of an identity gaining control of valid credentials that may be used for additional tactics such as initial access, lateral movement, and collecting information. MFA can also be used to restrict access to cloud resources and APIs. An Adversary may log into accessible cloud services within a compromised environment using Valid Accounts that are synchronized to move laterally and perform actions with the virtual machine's managed identity. The adversary may then perform management actions or access cloud-hosted resources as the logged-on managed identity.

Remediate from Azure Portal 1. Log in to the Azure portal. 2. This can be remediated by enabling MFA for user, Removing user access or Reducing access of managed identities attached to virtual machines. - Case I : Enable MFA for users having access on virtual machines. 1. Go to Microsoft Entra ID. 1. For Per-user MFA: 1. Under Manage, click Users. 1. Click Per-user MFA. 1. For each user requiring remediation, check the box next to their name. 1. Click Enable MFA. 1. Click Enable. 1. For Conditional Access: 1. Under Manage, click Security. 1. Under Protect, click Conditional Access. 1. Update the Conditional Access policy requiring MFA for all users, removing each user requiring remediation from the Exclude list. - Case II : Removing user access on a virtual machine. 1. Select the Subscription, then click on Access control (IAM). 2. Select Role assignments and search for Virtual Machine Administrator Login or Virtual Machine User Login or any role that provides access to log into virtual machines. 3. Click on Role Name, Select Assignments, and remove identities with no MFA configured. - Case III : Reducing access of managed identities attached to virtual machines. 1. Select the Subscription, then click on Access control (IAM). 2. Select Role Assignments from the top menu and apply filters on Assignment type as Privileged administrator roles and Type as Virtual Machines. 3. Click on Role Name, Select Assignments, and remove identities access make sure this follows the least privileges principal.

Level 1

6 Identity Services

Ensure that users are notified on their primary and alternate emails on password resets.

By default, Notify users on password resets? is set to Yes.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select Password reset 1. Under Manage, select Notifications 1. Ensure that Notify users on password resets? is set to Yes

Users will receive emails alerting them to password changes to both their primary and alternate emails.

Manual

User notification on password reset is a proactive way of confirming password reset activity. It helps the user to recognize unauthorized password reset activities.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select Password reset 1. Under Manage, select Notifications 1. Set Notify users on password resets? to Yes 1. Click Save

Level 1

6 Identity Services

6.1 Security Defaults (Per-User MFA)

[IMPORTANT - Please read the section overview: If your organization pays for Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, F5, or Business Premium, and EM&S E3 or E5 licenses) and CAN use Conditional Access, ignore the recommendations in this section and proceed to the Conditional Access section.] Security defaults in Microsoft Entra ID make it easier to be secure and help protect your organization. Security defaults contain preconfigured security settings for common attacks. Security defaults is available to everyone. The goal is to ensure that all organizations have a basic level of security enabled at no extra cost. You may turn on security defaults in the Azure portal.

If your tenant was created on or after October 22, 2019, security defaults may already be enabled in your tenant.

Audit from Azure Portal To ensure security defaults is enabled in your directory: 1. From Azure Home select the Portal Menu. 2. Browse to Microsoft Entra ID > Properties. 3. Select Manage security defaults. 4. Under Security defaults, verify that Enabled (recommended) is selected.

This recommendation should be implemented initially and then may be overridden by other service/product specific CIS Benchmarks. Administrators should also be aware that certain configurations in Microsoft Entra ID may impact other Microsoft services such as Microsoft 365.

Manual

Security defaults provide secure default settings that we manage on behalf of organizations to keep customers safe until they are ready to manage their own identity security settings. For example, doing the following: - Requiring all users and admins to register for MFA. - Challenging users with MFA - when necessary, based on factors such as location, device, role, and task. - Disabling authentication from legacy authentication clients, which can’t do MFA.

Remediate from Azure Portal To enable security defaults in your directory: 1. From Azure Home select the Portal Menu. 1. Browse to Microsoft Entra ID > Properties. 1. Select Manage security defaults. 1. Under Security defaults, select Enabled (recommended). 1. Select Save.

This recommendation differs from the Microsoft 365 Benchmark. This is because the potential impact associated with disabling Security Defaults is dependent upon the security settings implemented in the environment. It is recommended that organizations disabling Security Defaults implement appropriate security settings to replace the settings configured by Security Defaults.

Level 1

6 Identity Services

6.1 Security Defaults (Per-User MFA)

[IMPORTANT - Please read the section overview: If your organization pays for Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, F5, or Business Premium, and EM&S E3 or E5 licenses) and CAN use Conditional Access, ignore the recommendations in this section and proceed to the Conditional Access section.] Enable multifactor authentication for all users. Note: Since 2024, Azure has been rolling out mandatory multifactor authentication. For more information: - https://azure.microsoft.com/en-us/blog/announcing-mandatory-multi-factor-authentication-for-azure-sign-in - https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication

Multifactor authentication is not enabled for all users by default. Starting in 2024, multifactor authentication is enabled for administrative accounts by default.

Audit from Azure Portal 1. Go to Microsoft Entra ID. 1. Under Manage, click Users. 1. Click Per-user MFA from the top menu. 1. Ensure that Status is enabled for all users. Audit from REST API Run the following Graph PowerShell command: get-mguser -All | where {$_.StrongAuthenticationMethods.Count -eq 0} | Select-Object -Property UserPrincipalName If the output contains any UserPrincipalName, then this recommendation is non-compliant.

Users would require two forms of authentication before any access is granted. Additional administrative time will be required for managing dual forms of authentication when enabling multifactor authentication.

Manual

Multifactor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. Multifactor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multifactor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk.

Remediate from Azure Portal 1. Go to Microsoft Entra ID. 1. Under Manage, click Users. 1. Click Per-user MFA from the top menu. 1. Click the box next to a user with Status disabled. 1. Click Enable MFA. 1. Click Enable. 1. Repeat steps 1-6 for each user requiring remediation. Other options within Azure Portal - https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa - https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings - https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-admin-mfa - https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted#enable-multi-factor-authentication-with-conditional-access

Level 1

6 Identity Services

6.1 Security Defaults (Per-User MFA)

[IMPORTANT - Please read the section overview: If your organization pays for Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, F5, or Business Premium, and EM&S E3 or E5 licenses) and CAN use Conditional Access, ignore the recommendations in this section and proceed to the Conditional Access section.] Do not allow users to remember multi-factor authentication on devices.

By default, Allow users to remember multi-factor authentication on devices they trust is disabled.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, click Users 1. Click the Per-user MFA button on the top bar 1. Click on Service settings 1. Ensure that Allow users to remember multi-factor authentication on devices they trust is not enabled

For every login attempt, the user will be required to perform multi-factor authentication.

Manual

Remembering Multi-Factor Authentication (MFA) for devices and browsers allows users to have the option to bypass MFA for a set number of days after performing a successful sign-in using MFA. This can enhance usability by minimizing the number of times a user may need to perform two-step verification on the same device. However, if an account or device is compromised, remembering MFA for trusted devices may affect security. Hence, it is recommended that users not be allowed to bypass MFA.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, click Users 1. Click the Per-user MFA button on the top bar 1. Click on Service settings 1. Uncheck the box next to Allow users to remember multi-factor authentication on devices they trust 1. Click Save

Level 2

6 Identity Services

Restrict security group management to administrators only.

By default, Owners can manage group membership requests in My Groups is set to No.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Self Service Group Management, ensure that Owners can manage group membership requests in My Groups is set to No

Group Membership for user accounts will need to be handled by Admins and cause administrative overhead.

Manual

Restricting security group management to administrators only prohibits users from making changes to security groups. This ensures that security groups are appropriately managed and their management is not delegated to non-administrators.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Self Service Group Management, set Owners can manage group membership requests in My Groups to No 1. Click Save

Level 2

6 Identity Services

6.2 Conditional Access

Microsoft Entra ID Conditional Access allows an organization to configure Named locations and configure whether those locations are trusted or untrusted. These settings provide organizations the means to specify Geographical locations for use in conditional access policies, or define actual IP addresses and IP ranges and whether or not those IP addresses and/or ranges are trusted by the organization.

By default, no locations are configured under the Named locations blade within the Microsoft Entra ID Conditional Access blade.

Audit from Azure Portal 1. In the Azure Portal, navigate to Microsoft Entra ID 1. Under Manage, click Security 1. Under Protect, click Conditional Access 1. Under Manage, click Named locations Ensure there are IP ranges location settings configured and marked as Trusted Audit from PowerShell Get-MgIdentityConditionalAccessNamedLocation In the output from the above command, for each Named location group, make sure at least one entry contains the IsTrusted parameter with a value of True. Otherwise, if there is no output as a result of the above command or all of the entries contain the IsTrusted parameter with an empty value, a NULL value, or a value of False, the results are out of compliance with this check.

When configuring Named locations, the organization can create locations using Geographical location data or by defining source IP addresses or ranges. Configuring Named locations using a Country location does not provide the organization the ability to mark those locations as trusted, and any Conditional Access policy relying on those Countries location setting will not be able to use the All trusted locations setting within the Conditional Access policy. They instead will have to rely on the Select locations setting. This may add additional resource requirements when configuring and will require thorough organizational testing. In general, Conditional Access policies may completely prevent users from authenticating to Microsoft Entra ID, and thorough testing is recommended. To avoid complete lockout, a 'Break Glass' account with full Global Administrator rights is recommended in the event all other administrators are locked out of authenticating to Microsoft Entra ID. This 'Break Glass' account should be excluded from Conditional Access Policies and should be configured with the longest pass phrase feasible in addition to a FIDO2 security key or certificate kept in a very secure physical location. This account should only be used in the event of an emergency and complete administrator lockout. NOTE: Starting July 2024, Microsoft will begin requiring MFA for All Users - including Break Glass Accounts. By the end of October 2024, this requirement will be enforced. Physical FIDO2 security keys, or a certificate kept on secure removable storage can fulfill this MFA requirement. If opting for a physical device, that device should be kept in a very secure, documented physical location.

Manual

Defining trusted source IP addresses or ranges helps organizations create and enforce Conditional Access policies around those trusted or untrusted IP addresses and ranges. Users authenticating from trusted IP addresses and/or ranges may have less access restrictions or access requirements when compared to users that try to authenticate to Microsoft Entra ID from untrusted locations or untrusted source IP addresses/ranges.

Remediate from Azure Portal 1. In the Azure Portal, navigate to Microsoft Entra ID 1. Under Manage, click Security 1. Under Protect, click Conditional Access 1. Under Manage, click Named locations 1. Within the Named locations blade, click on IP ranges location 1. Enter a name for this location setting in the Name text box 1. Click on the + sign 1. Add an IP Address Range in CIDR notation inside the text box that appears 1. Click on the Add button 1. Repeat steps 7 through 9 for each IP Range that needs to be added 1. If the information entered are trusted ranges, select the Mark as trusted location check box 1. Once finished, click on Create Remediate from PowerShell Create a new trusted IP-based Named location policy [System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.IpRange]]$ipRanges = @() $ipRanges.Add(<first IP range in CIDR notation>) $ipRanges.Add(<second IP range in CIDR notation>) $ipRanges.Add(<third IP range in CIDR notation>) New-MgIdentityConditionalAccessNamedLocation -dataType #microsoft.graph.ipNamedLocation -DisplayName <name of IP Named location policy> -IsTrusted $true -IpRanges $ipRanges Set an existing IP-based Named location policy to trusted Update-MgIdentityConditionalAccessNamedLocation -PolicyId <ID of the policy> -dataType #microsoft.graph.ipNamedLocation -IsTrusted $true

Level 2

6 Identity Services

6.2 Conditional Access

CAUTION: If these policies are created without first auditing and testing the result, misconfiguration can potentially lock out administrators or create undesired access issues. Conditional Access Policies can be used to block access from geographic locations that are deemed out-of-scope for your organization or application. The scope and variables for this policy should be carefully examined and defined.

This policy does not exist by default.

Audit from Azure Portal 1. From Azure Home open the Portal menu in the top left, and select Microsoft Entra ID. 1. Scroll down in the menu on the left, and select Security. 1. Select on the left side Conditional Access. 1. Select Policies. 1. Select the policy you wish to audit, then: - Under Assignments > Users, review the users and groups for the personnel the policy will apply to - Under Assignments > Target resources, review the cloud apps or actions for the systems the policy will apply to - Under Conditions > Locations, Review the Include locations for those that should be blocked - Under Conditions > Locations, Review the Exclude locations for those that should be allowed (Note: locations set up in the previous recommendation for Trusted Location should be in the Exclude list.) - Under Access Controls > Grant - Confirm that Block access is selected. Audit from Azure CLI As of this writing there are no subcommands for Conditional Access Policies within the Azure CLI Audit from PowerShell $conditionalAccessPolicies = Get-MgIdentityConditionalAccessPolicy foreach($policy in $conditionalAccessPolicies) {$policy | Select-Object @{N='Policy ID'; E={$policy.id}}, @{N=Included Locations; E={$policy.Conditions.Locations.IncludeLocations}}, @{N=Excluded Locations; E={$policy.Conditions.Locations.ExcludeLocations}}, @{N=BuiltIn GrantControls; E={$policy.GrantControls.BuiltInControls}}} Make sure there is at least 1 row in the output of the above PowerShell command that contains Block under the BuiltIn GrantControls column and location IDs under the Included Locations and Excluded Locations columns. If not, a policy containing these options has not been created and is considered a finding.

Microsoft Entra ID P1 or P2 is required. Limiting access geographically will deny access to users that are traveling or working remotely in a different part of the world. A point-to-site or site to site tunnel such as a VPN is recommended to address exceptions to geographic access policies.

Manual

Conditional Access, when used as a deny list for the tenant or subscription, is able to prevent ingress or egress of traffic to countries that are outside of the scope of interest (e.g.: customers, suppliers) or jurisdiction of an organization. This is an effective way to prevent unnecessary and long-lasting exposure to international threats such as APTs.

Remediate from Azure Portal Part 1 of 2 - Create the policy and enable it in Report-only mode. 1. From Azure Home open the portal menu in the top left, and select Microsoft Entra ID. 1. Scroll down in the menu on the left, and select Security. 1. Select on the left side Conditional Access. 1. Select Policies. 1. Click the + New policy button, then: 1. Provide a name for the policy. 1. Under Assignments, select Users then: - Under Include, select All users - Under Exclude, check Users and groups and only select emergency access accounts and service accounts (NOTE: Service accounts are excluded here because service accounts are non-interactive and cannot complete MFA) 1. Under Assignments, select Target resources then: - Under Include, select All cloud apps - Leave Exclude blank unless you have a well defined exception 1. Under Conditions, select Locations then: - Select Include, then add entries for locations for those that should be blocked - Select Exclude, then add entries for those that should be allowed (IMPORTANT: Ensure that all Trusted Locations are in the Exclude list.) 1. Under Access Controls, select Grant select Block Access. 1. Set Enable policy to Report-only. 1. Click Create. Allow some time to pass to ensure the sign-in logs capture relevant conditional access events. These events will need to be reviewed to determine if additional considerations are necessary for your organization (e.g. legitimate locations are being blocked and investigation is needed for exception). NOTE: The policy is not yet 'live,' since Report-only is being used to audit the effect of the policy. Part 2 of 2 - Confirm that the policy is not blocking access that should be granted, then toggle to On. 1. With your policy now in report-only mode, return to the Microsoft Entra blade and click on Sign-in logs. 1. Review the recent sign-in events - click an event then review the event details (specifically the Report-only tab) to ensure: - The sign-in event you're reviewing occurred after turning on the policy in report-only mode - The policy name from step 6 above is listed in the Policy Name column - The Result column for the new policy shows that the policy was Not applied (indicating the location origin was not blocked) 1. If the above conditions are present, navigate back to the policy name in Conditional Access and open it. 1. Toggle the policy from Report-only to On. 1. Click Save. Remediate from PowerShell First, set up the conditions objects values before updating an existing conditional access policy or before creating a new one. You may need to use additional PowerShell cmdlets to retrieve specific IDs such as the Get-MgIdentityConditionalAccessNamedLocation which outputs the Location IDs for use with conditional access policies. $conditions = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet $conditions.Applications = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessApplicationCondition $conditions.Applications.IncludeApplications = <All | Office365 | app ID | @(app ID 1, app ID 2, etc...> $conditions.Applications.ExcludeApplications = <Office365 | app ID | @(app ID 1, app ID 2, etc...)> $conditions.Users = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessUserCondition $conditions.Users.IncludeUsers = <All | None | GuestsOrExternalUsers | Specific User ID | @(User ID 1, User ID 2, etc.)> $conditions.Users.ExcludeUsers = <GuestsOrExternalUsers | Specific User ID | @(User ID 1, User ID 2, etc.)> $conditions.Users.IncludeGroups = <group ID | All | @(Group ID 1, Group ID 2, etc...)> $conditions.Users.ExcludeGroups = <group ID | @(Group ID 1, Group ID 2, etc...)> $conditions.Users.IncludeRoles = <Role ID | All | @(Role ID 1, Role ID 2, etc...)> $conditions.Users.ExcludeRoles = <Role ID | @(Role ID 1, Role ID 2, etc...)> $conditions.Locations = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition $conditions.Locations.IncludeLocations = <Location ID | @(Location ID 1, Location ID 2, etc...) > $conditions.Locations.ExcludeLocations = <AllTrusted | Location ID | @(Location ID 1, Location ID 2, etc...)> $controls = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls $controls._Operator = OR $controls.BuiltInControls = block Next, update the existing conditional access policy with the condition set options configured with the previous commands. Update-MgIdentityConditionalAccessPolicy -PolicyId <policy ID> -Conditions $conditions -GrantControls $controls To create a new conditional access policy that complies with this best practice, run the following commands after creating the condition set above New-MgIdentityConditionalAccessPolicy -Name Policy Name -State <enabled|disabled> -Conditions $conditions -GrantControls $controls

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 2

6 Identity Services

6.2 Conditional Access

Conditional Access Policies can be used to prevent the Device code authentication flow. Device code flow should be permitted only for users that regularly perform duties that explicitly require the use of Device Code to authenticate, such as utilizing Azure with PowerShell.

This policy does not exist by default.

Audit from Azure Portal 1. From Azure Home open the Portal menu in the top left and select Microsoft Entra ID. 1. Scroll down in the menu on the left and select Security. 1. Select on the left side Conditional Access. 1. Select Policies. 1. Select the policy you wish to audit, then: - Under Assignments > Users, review the users and groups for the personnel the policy will apply to - Under Assignments > Target resources, review the cloud apps or actions for the systems the policy will apply to - Under Conditions > Authentication Flows, review the configuration to ensure Device code flow is selected - Under Access Controls > Grant - Confirm that Block access is selected.

Microsoft Entra ID P1 or P2 is required. This policy should be tested using the Report-only mode before implementation. Without a full and careful understanding of the accounts and personnel who require Device code authentication flow, implementing this policy can block authentication for users and devices who rely on Device code flow. For users and devices that rely on device code flow authentication, more secure alternatives should be implemented wherever possible.

Manual

Attackers use Device code flow in phishing attacks and, if successful, results in the attacker gaining access tokens and refresh tokens which are scoped to user_impersonation, which can perform any action the user has permission to perform.

Remediate from Azure Portal Part 1 of 2 - Create the policy and enable it in Report-only mode. 1. From Azure Home open the portal menu in the top left and select Microsoft Entra ID. 1. Scroll down in the menu on the left and select Security. 1. Select on the left side Conditional Access. 1. Select Policies. 1. Click the + New policy button, then: 1. Provide a name for the policy. 1. Under Assignments, select Users then: - Under Include, select All users - Under Exclude, check Users and groups and only select emergency access accounts 1. Under Assignments, select Target resources then: - Under Include, select All cloud apps - Leave Exclude blank unless you have a well defined exception 1. Under Conditions > Authentication Flows, set Configure to Yes then: - Select Device code flow - Select Done 1. Under Access Controls > Grant, select Block Access. 1. Set Enable policy to Report-only. 1. Click Create. Allow some time to pass to ensure the sign-in logs capture relevant conditional access events. These events will need to be reviewed to determine if additional considerations are necessary for your organization (e.g. many legitimate use cases of device code authentication are observed). NOTE: The policy is not yet 'live,' since Report-only is being used to audit the effect of the policy. Part 2 of 2 - Confirm that the policy is not blocking access that should be granted, then toggle to On. 1. With your policy now in report-only mode, return to the Microsoft Entra blade and click on Sign-in logs. 1. Review the recent sign-in events - click an event then review the event details (specifically the Report-only tab) to ensure: - The sign-in event you're reviewing occurred after turning on the policy in report-only mode - The policy name from step 6 above is listed in the Policy Name column - The Result column for the new policy shows that the policy was Not applied (indicating the device code authentication flow was not blocked) 1. If the above conditions are present, navigate back to the policy name in Conditional Access and open it. 1. Toggle the policy from Report-only to On. 1. Click Save.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 2

6 Identity Services

6.2 Conditional Access

A Conditional Access policy can be enabled to ensure that users are required to use Multifactor Authentication (MFA) to login. Note: Since 2024, Azure has been rolling out mandatory multifactor authentication. For more information: - https://azure.microsoft.com/en-us/blog/announcing-mandatory-multi-factor-authentication-for-azure-sign-in - https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication

Starting October 2024, MFA will be required for all accounts by default.

Audit from Azure Portal 1. From Azure Home open the Portal Menu in the top left, and select Microsoft Entra ID. 1. Scroll down in the menu on the left, and select Security. 1. Select on the left side Conditional Access. 1. Select Policies. 1. Select the policy you wish to audit. 1. Click the blue text under Users. 1. Under Include ensure that All Users is specified. 1. Under Exclude ensure that no users or groups are specified. If there are users or groups specified for exclusion, a very strong justification should exist for each exception, and all excepted account-level objects should be recorded in documentation along with the justification for comparison in future audits.

There is an increased cost associated with Conditional Access policies because of the requirement of Microsoft Entra ID P1 or P2 licenses. Additional support overhead may also need to be considered.

Manual

Multifactor authentication is strongly recommended to increase the confidence that a claimed identity can be proven to be the subject of the identity. This results in a stronger authentication chain and reduced likelihood of exploitation.

Remediate from Azure Portal 1. From Azure Home open Portal menu in the top left, and select Microsoft Entra ID. 1. Select Security. 1. Select Conditional Access. 1. Select Policies. 1. Click + New policy. 1. Enter a name for the policy. 1. Click the blue text under Users. 1. Under Include, select All users. 1. Under Exclude, check Users and groups. 1. Select users this policy should not apply to and click Select. 1. Click the blue text under Target resources. 1. Select All cloud apps. 1. Click the blue text under Grant. 1. Under Grant access, check Require multifactor authentication and click Select. 1. Set Enable policy to Report-only. 1. Click Create. After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource in the References which monitors Azure sign ins.

Level 2

6 Identity Services

6.2 Conditional Access

Entra ID tracks the behavior of sign-in events. If the Entra ID domain is licensed with P2, the sign-in behavior can be used as a detection mechanism for additional scrutiny during the sign-in event. If this policy is set up, then Risky Sign-in events will prompt users to use multi-factor authentication (MFA) tokens on login for additional verification.

MFA is not enabled by default.

Audit from Azure Portal 1. From Azure Home select the Portal Menu in the top left and select Microsoft Entra ID. 1. Select Security. 1. Select on the left side Conditional Access. 1. Select Policies. 1. Select the policy you wish to audit. 1. Click the blue text under Users. 1. View under Include the corresponding users and groups to whom the policy is applied. 1. View under Exclude to determine which users and groups to whom the policy is not applied.

Risk Policies for Conditional Access require Microsoft Entra ID P2. Additional overhead to support or maintain these policies may also be required if users lose access to their MFA tokens.

Manual

Enabling multi-factor authentication is a recommended setting to limit the potential of accounts being compromised and limiting access to authenticated personnel. Enabling this policy allows Entra ID's risk-detection mechanisms to force additional scrutiny on the login event, providing a deterrent response to potentially malicious sign-in events, and adding an additional authentication layer as a reaction to potentially malicious behavior.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu in the top left and select Microsoft Entra ID. 1. Select Security 1. Select Conditional Access. 1. Select Policies. 1. Click + New policy. 1. Enter a name for the policy. 1. Click the blue text under Users. 1. Under Include, select All users. 1. Under Exclude, check Users and groups. 1. Select users this policy should not apply to and click Select. 1. Click the blue text under Target resources. 1. Select All cloud apps. 1. Click the blue text under Conditions. 1. Select Sign-in risk. 1. Update the Configure toggle to Yes. 1. Check the sign-in risk level this policy should apply to, e.g. High and Medium. 1. Select Done. 1. Click the blue text under Grant and check Require multifactor authentication then click the Select button. 1. Click the blue text under Session then check Sign-in frequency and select Every time and click the Select button. 1. Set Enable policy to Report-only. 1. Click Create. After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource the in References which monitors Azure sign ins.

Level 2

6 Identity Services

6.2 Conditional Access

This recommendation ensures that users accessing the Windows Azure Service Management API (i.e. Azure Powershell, Azure CLI, Azure Resource Manager API, etc.) are required to use multi-factor authentication (MFA) credentials when accessing resources through the Windows Azure Service Management API.

MFA is not enabled by default for administrative actions.

Audit from Azure Portal 1. From the Azure Admin Portal dashboard, open Microsoft Entra ID. 1. In the menu on the left of the Entra ID blade, click Security. 1. In the menu on the left of the Security blade, click Conditional Access. 1. In the menu on the left of the Conditional Access blade, click Policies. 1. Click on the name of the policy you wish to audit. 1. Click the blue text under Users. 1. Under the Include section of Users, ensure that All Users is selected. 1. Under the Exclude section of Users, review the Users and Groups that are excluded from the policy (NOTE: this should be limited to break-glass emergency access accounts, non-interactive service accounts, and other carefully considered exceptions). 1. On the left side, click the blue text under Target resources. 1. Under the Include section of Target Resources, ensure that the Select apps radio button is selected. 1. Under Select, ensure that Windows Azure Service Management API is listed.

Conditional Access policies require Microsoft Entra ID P1 or P2 licenses. Similarly, they may require additional overhead to maintain if users lose access to their MFA. Any users or groups which are granted an exception to this policy should be carefully tracked, be granted only minimal necessary privileges, and conditional access exceptions should be regularly reviewed or investigated.

Manual

Administrative access to the Windows Azure Service Management API should be secured with a higher level of scrutiny to authenticating mechanisms. Enabling multi-factor authentication is recommended to reduce the potential for abuse of Administrative actions, and to prevent intruders or compromised admin credentials from changing administrative settings. IMPORTANT: While this recommendation allows exceptions to specific Users or Groups, they should be very carefully tracked and reviewed for necessity on a regular interval through an Access Review process. It is important that this rule be built to include All Users to ensure that all users not specifically excepted will be required to use MFA to access the Azure Service Management API.

Remediate from Azure Portal 1. From the Azure Admin Portal dashboard, open Microsoft Entra ID. 1. Click Security in the Entra ID blade. 1. Click Conditional Access in the Security blade. 1. Click Policies in the Conditional Access blade. 1. Click + New policy. 1. Enter a name for the policy. 1. Click the blue text under Users. 1. Under Include, select All users. 1. Under Exclude, check Users and groups. 1. Select users or groups to be exempted from this policy (e.g. break-glass emergency accounts, and non-interactive service accounts) then click the Select button. 1. Click the blue text under Target resources. 1. Under Include, click the Select apps radio button. 1. Click the blue text under Select. 1. Check the box next to Windows Azure Service Management APIs then click the Select button. 1. Click the blue text under Grant. 1. Under Grant access check the box for Require multi-factor authentication then click the Select button. 1. Before creating, set Enable policy to Report-only. 1. Click Create. After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with administrators changing settings until they use an MFA device linked to their accounts. An emergency access account is recommended for this eventuality if all administrators are locked out. Please see the documentation in the references for further information. Similarly further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 2

6 Identity Services

6.2 Conditional Access

This recommendation ensures that users accessing Microsoft Admin Portals (i.e. Microsoft 365 Admin, Microsoft 365 Defender, Exchange Admin Center, Azure Portal, etc.) are required to use multi-factor authentication (MFA) credentials when logging into an Admin Portal.

MFA is not enabled by default for administrative actions.

Audit from Azure Portal 1. From the Azure Admin Portal dashboard, open Microsoft Entra ID. 1. In the menu on the left of the Entra ID blade, click Security. 1. In the menu on the left of the Security blade, click Conditional Access. 1. In the menu on the left of the Conditional Access blade, click Policies. 1. Click on the name of the policy you wish to audit. 1. Click the blue text under Users. 1. Under the Include section of Users, review Users and Groups to ensure that All Users is selected. 1. Under the Exclude section of Users, review the Users and Groups that are excluded from the policy (NOTE: this should be limited to break-glass emergency access accounts, non-interactive service accounts, and other carefully considered exceptions). 1. On the left side, click the blue text under Target Resources. 1. Under the Include section of Target resources, ensure the Select apps radio button is selected. 1. Under Select, ensure Microsoft Admin Portals is listed.

Conditional Access policies require Microsoft Entra ID P1 or P2 licenses. Similarly, they may require additional overhead to maintain if users lose access to their MFA. Any users or groups which are granted an exception to this policy should be carefully tracked, be granted only minimal necessary privileges, and conditional access exceptions should be reviewed or investigated.

Manual

Administrative Portals for Microsoft Azure should be secured with a higher level of scrutiny to authenticating mechanisms. Enabling multi-factor authentication is recommended to reduce the potential for abuse of Administrative actions, and to prevent intruders or compromised admin credentials from changing administrative settings. IMPORTANT: While this recommendation allows exceptions to specific Users or Groups, they should be very carefully tracked and reviewed for necessity on a regular interval through an Access Review process. It is important that this rule be built to include All Users to ensure that all users not specifically excepted will be required to use MFA to access Admin Portals.

Remediate from Azure Portal 1. From the Azure Admin Portal dashboard, open Microsoft Entra ID. 1. Click Security in the Entra ID blade. 1. Click Conditional Access in the Security blade. 1. Click Policies in the Conditional Access blade. 1. Click + New policy. 1. Enter a name for the policy. 1. Click the blue text under Users. 1. Under Include, select All users. 1. Under Exclude, check Users and groups. 1. Select users or groups to be exempted from this policy (e.g. break-glass emergency accounts, and non-interactive service accounts) then click the Select button. 1. Click the blue text under Target resources. 1. Under Include, click the Select apps radio button. 1. Click the blue text under Select. 1. Check the box next to Microsoft Admin Portals then click the Select button. 1. Click the blue text under Grant. 1. Under Grant access check the box for Require multifactor authentication then click the Select button. 1. Before creating, set Enable policy to Report-only. 1. Click Create. After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with administrators changing settings until they use an MFA device linked to their accounts. An emergency access account is recommended for this eventuality if all administrators are locked out. Please see the documentation in the references for further information. Similarly further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 1

6 Identity Services

6.3 Periodic Identity Reviews

Microsoft Azure admin accounts should not be used for routine, non-administrative tasks.

Audit from Azure Portal Monitor: 1. Go to Monitor. 1. Click Activity log. 1. Review the activity log and ensure that admin accounts are not being used for daily operations. Microsoft Entra ID: 1. Go to Microsoft Entra ID. 1. Under Monitoring, click Sign-in logs. 1. Review the sign-in logs and ensure that admin accounts are not being accessed more frequently than necessary.

Minor administrative overhead includes managing separate accounts, enforcing stricter access controls, and potential licensing costs for advanced security features.

Manual

Using admin accounts for daily operations increases the risk of accidental misconfigurations and security breaches.

If admin accounts are being used for daily operations, consider the following: - Monitor and alert on unusual activity. - Enforce the principle of least privilege. - Revoke any unnecessary administrative access. - Use Conditional Access to limit access to resources. - Ensure that administrators have separate admin and user accounts. - Use Microsoft Entra ID Protection helps organizations detect, investigate, and remediate identity-based risks. - Use Privileged Identity Management (PIM) in Microsoft Entra ID to limit standing administrator access to privileged roles, discover who has access, and review privileged access.

Level 1

6 Identity Services

6.3 Periodic Identity Reviews

Microsoft Entra ID has native and extended identity functionality allowing you to invite people from outside your organization to be guest users in your cloud account and sign in with their own work, school, or social identities.

By default no guest users are created.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Click on Add filter 1. Select User type 1. Select Guest from the Value dropdown 1. Click Apply 1. Audit the listed guest users Audit from Azure CLI az ad user list --query [?userType=='Guest'] Ensure all users listed are still required and not inactive. Audit from Azure PowerShell Get-AzureADUser |Where-Object {$_.UserType -like Guest} |Select-Object DisplayName, UserPrincipalName, UserType -Unique Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: e9ac8f8e-ce22-4355-8f04-99b911d6be52 - Name: 'Guest accounts with read permissions on Azure resources should be removed' - Policy ID: 94e1c2ac-cbbe-4cac-a2b5-389c812dee87 - Name: 'Guest accounts with write permissions on Azure resources should be removed' - Policy ID: 339353f6-2387-4a45-abe4-7f529d121046 - Name: 'Guest accounts with owner permissions on Azure resources should be removed'

Before removing guest users, determine their use and scope. Like removing any user, there may be unforeseen consequences to systems if an account is removed without careful consideration.

Manual

Guest users are typically added outside your employee on-boarding/off-boarding process and could potentially be overlooked indefinitely. To prevent this, guest users should be reviewed on a regular basis. During this audit, guest users should also be determined to not have administrative privileges.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Click on Add filter 1. Select User type 1. Select Guest from the Value dropdown 1. Click Apply 1. Check the box next to all Guest users that are no longer required or are inactive 1. Click Delete 1. Click OK Remediate from Azure CLI Before deleting the user, set it to inactive using the ID from the Audit Procedure to determine if there are any dependent systems. az ad user update --id <exampleaccountid@domain.com> --account-enabled {false} After determining that there are no dependent systems, delete the user. Remove-AzureADUser -ObjectId <exampleaccountid@domain.com> Remediate from Azure PowerShell Before deleting the user, set it to inactive using the ID from the Audit Procedure to determine if there are any dependent systems. Set-AzureADUser -ObjectId <exampleaccountid@domain.com> -AccountEnabled false After determining that there are no dependent systems, delete the user. PS C:\>Remove-AzureADUser -ObjectId <exampleaccountid@domain.com>

It is good practice to use a dynamic security group to manage guest users. To create the dynamic security group: 1. Navigate to the 'Microsoft Entra ID' blade in the Azure Portal 2. Select the 'Groups' item 3. Create new 4. Type of 'dynamic' 5. Use the following dynamic selection rule. (user.userType -eq Guest) 6. Once the group has been created, select access reviews option and create a new access review with a period of monthly and send to relevant administrators for review.

Level 1

6 Identity Services

6.3 Periodic Identity Reviews

The User Access Administrator role grants the ability to view all resources and manage access assignments at any subscription or management group level within the tenant. Due to its high privilege level, this role assignment should be removed immediately after completing the necessary changes at the root scope to minimize security risks.

Audit from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Subscriptions. 1. Select a subscription. 1. Select Access control (IAM). 1. Look for the following banner at the top of the page: Action required: X users have elevated access in your tenant. You should take immediate action and remove all role assignments with elevated access. If the banner is displayed, the User Access Administrator is assigned. Audit from Azure CLI Run the following command: az role assignment list --role User Access Administrator --scope / Ensure that the command does not return any User Access Administrator role assignment information.

Increased administrative effort to manage and remove role assignments appropriately.

Automated

The User Access Administrator role provides extensive access control privileges. Unnecessary assignments heighten the risk of privilege escalation and unauthorized access. Removing the role immediately after use minimizes security exposure.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Subscriptions. 1. Select a subscription. 1. Select Access control (IAM). 1. Look for the following banner at the top of the page: Action required: X users have elevated access in your tenant. You should take immediate action and remove all role assignments with elevated access. 1. Click View role assignments. 1. Click Remove. Remediate from Azure CLI Run the following command: az role assignment delete --role User Access Administrator --scope /

Level 1

6 Identity Services

6.3 Periodic Identity Reviews

Periodic review of privileged role assignments is performed to ensure that the privileged roles assigned to users are accurate and appropriate.

Audit from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Subscriptions. 1. Select a subscription. 1. Select Access control (IAM). 1. Look for the number under the word Privileged accompanied by a link titled View Assignments. Click the View assignments link. 1. For each privileged role listed, evaluate whether the assignment is appropriate and current for each User, Group, or App assigned to each privileged role. NOTE: The judgement of what constitutes 'appropriate and current' assignments requires a clear understanding of your organization's personnel, systems, policy, and security requirements. This cannot be effectively prescribed in procedure.

Increased administrative effort to manage and remove role assignments appropriately.

Manual

Privileged roles are crown jewel assets that can be used by malicious insiders, threat actors, and even through mistake to significantly damage an organization in numerous ways. These roles should be periodically reviewed to: - identify lingering permissions assignment (e.g. an administrator has been terminated, the administrator account is being retained, but the permissions are no longer necessary and has not been properly addressed by process) - detect lateral movement through privilege escalation (e.g. an account with administrative permission has been compromised and is elevating other accounts in an attempt to circumvent detection mechanisms)

Level 1

6 Identity Services

Require administrators or appropriately delegated users to create new tenants.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select User settings 1. Ensure that Restrict non-admin users from creating tenants is set to Yes Audit from PowerShell Import-Module Microsoft.Graph.Identity.SignIns Connect-MgGraph -Scopes 'Policy.ReadWrite.Authorization' Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions | Format-List Review the DefaultUserRolePermissions section of the output. Ensure that AllowedToCreateTenants is not True.

Enforcing this setting will ensure that only authorized users are able to create new tenants.

Automated

It is recommended to only allow an administrator to create new tenants. This prevent users from creating new Microsoft Entra ID or Azure AD B2C tenants and ensures that only authorized users are able to do so.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select User settings 1. Set Restrict non-admin users from creating tenants to Yes 1. Click Save Remediate from PowerShell Import-Module Microsoft.Graph.Identity.SignIns Connect-MgGraph -Scopes 'Policy.ReadWrite.Authorization' Select-MgProfile -Name beta $params = @{ DefaultUserRolePermissions = @{ AllowedToCreateTenants = $false } } Update-MgPolicyAuthorizationPolicy -AuthorizationPolicyId -BodyParameter $params

Level 1

6 Identity Services

Ensures that two alternate forms of identification are provided before allowing a password reset.

By default, the Number of methods required to reset is set to 2.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select Password reset 1. Select Authentication methods 1. Ensure that Number of methods required to reset is set to 2

There may be administrative overhead, as users who lose access to their secondary authentication methods will need an administrator with permissions to remove it. There will also need to be organization-wide security policies and training to teach administrators to verify the identity of the requesting user so that social engineering cannot render this setting useless.

Manual

A Self-service Password Reset (SSPR) through Azure Multi-factor Authentication (MFA) ensures the user's identity is confirmed using two separate methods of identification. With multiple methods set, an attacker would have to compromise both methods before they could maliciously reset a user's password.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select Password reset 1. Select Authentication methods 1. Set the Number of methods required to reset to 2 1. Click Save

Level 1

6 Identity Services

The account lockout threshold determines how many failed login attempts are permitted prior to placing the account in a locked-out state and initiating a variable lockout duration.

By default, Lockout threshold is set to 10.

Audit from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Security. 1. Under Manage, select Authentication methods. 1. Under Manage, select Password protection. 1. Ensure that Lockout threshold is set to 10 or fewer.

If account lockout threshold is set too low (less than 3), users may experience frequent lockout events and the resulting security alerts may contribute to alert fatigue. If account lockout threshold is set too high (more than 10), malicious actors can programmatically execute more password attempts in a given period of time.

Manual

Account lockout is a method of protecting against brute-force and password spray attacks. Once the lockout threshold has been exceeded, the account enters a locked-out state which prevents all login attempts for a variable duration. The lockout in combination with a reasonable duration reduces the total number of failed login attempts that a malicious actor can execute in a given period of time.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Security. 1. Under Manage, select Authentication methods. 1. Under Manage, select Password protection. 1. Set the Lockout threshold to 10 or fewer. 1. Click Save.

NOTE: The variable number for failed login attempts allowed before lockout is prescribed by many security and compliance frameworks. The appropriate setting for this variable should be determined by the most restrictive security or compliance framework that your organization follows.

Level 1

6 Identity Services

The account lockout duration value determines how long an account retains the status of lockout, and therefore how long before a user can continue to attempt to login after passing the lockout threshold.

By default, Lockout duration in seconds is set to 60.

Audit from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Security. 1. Under Manage, select Authentication methods. 1. Under Manage, select Password protection. 1. Ensure that Lockout duration in seconds is set to 60 or higher.

If account lockout duration is set too low (less than 60 seconds), malicious actors can perform more password spray and brute-force attempts over a given period of time. If the account lockout duration is set too high (more than 300 seconds) users may experience inconvenient delays during lockout.

Manual

Account lockout is a method of protecting against brute-force and password spray attacks. Once the lockout threshold has been exceeded, the account enters a locked-out state which prevents all login attempts for a variable duration. The lockout in combination with a reasonable duration reduces the total number of failed login attempts that a malicious actor can execute in a given period of time.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Security. 1. Under Manage, select Authentication methods. 1. Under Manage, select Password protection. 1. Set the Lockout duration in seconds to 60 or higher. 1. Click Save.

Level 1

6 Identity Services

Microsoft Azure applies a default global banned password list to all user and admin accounts that are created and managed directly in Microsoft Entra ID. The Microsoft Entra password policy does not apply to user accounts that are synchronized from an on-premises Active Directory environment, unless Microsoft Entra ID Connect is used and EnforceCloudPasswordPolicyForPasswordSyncedUsers is enabled. Review the Default Value section for more detail on the password policy. For increased password security, a custom banned password list is recommended

By default the custom banned password list is not 'Enabled'. Organization-specific terms can be added to the custom banned password list, such as the following examples: - Brand names - Product names - Locations, such as company headquarters - Company-specific terms - Abbreviations that have specific company meaning - Months and weekdays with your company's local languages The default global banned password list is already applied to your resources which applies the following basic requirements: Characters allowed: - Uppercase characters (A - Z) - Lowercase characters (a - z) - Numbers (0 - 9) - Symbols: - @ # $ % ^ & * - _ ! + = [ ] { } | \ : ' , . ? / ` ~ ( ) ; < > - blank space Characters not allowed: - Unicode characters Password length: Passwords require: - A minimum of eight characters - A maximum of 256 characters Password complexity: Passwords require three out of four of the following categories: - Uppercase characters - Lowercase characters - Numbers - Symbols Note: Password complexity check isn't required for Education tenants. Password not recently used: - When a user changes or resets their password, the new password can't be the same as the current or recently used passwords. - Password isn't banned by Entra ID Password Protection. - The password can't be on the global list of banned passwords for Azure AD Password Protection, or on the customizable list of banned passwords specific to your organization. Evaluation New passwords are evaluated for strength and complexity by validating against the combined list of terms from the global and custom banned password lists. Even if a user's password contains a banned password, the password may be accepted if the overall password is otherwise strong enough.

Audit from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Security. 1. Under Manage, select Authentication methods. 1. Under Manage, select Password protection. 1. Ensure Enforce custom list is set to Yes. 1. Review the list of words banned from use in passwords.

Increasing password complexity may increase user account administration overhead. Utilizing the default global banned password list and a custom list requires a Microsoft Entra ID P1 or P2 license. On-premises Active Directory Domain Services users who aren't synchronized to Microsoft Entra ID still benefit from Microsoft Entra ID Password Protection based on the existing licensing of synchronized users.

Manual

Implementing a custom banned password list gives your organization further control over the password policy. Disallowing easy-to-guess passwords increases the security of your Azure resources.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Security. 1. Under Manage, select Authentication methods. 1. Under Manage, select Password protection. 1. Set the Enforce custom list option to Yes. 1. Click in the Custom banned password list text box. 1. Add a list of words, one per line, to prevent users from using in passwords. 1. Click Save.

Level 1

6 Identity Services

Ensure that the number of days before users are asked to re-confirm their authentication information is not set to 0.

By default, the Number of days before users are asked to re-confirm their authentication information is set to 180 days.

Audit from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Users. 1. Select Password reset. 1. Under Manage, select Registration. 1. Ensure that Number of days before users are asked to re-confirm their authentication information is not set to 0.

Users will be prompted to re-confirm their authentication information after the number of days specified.

Manual

This setting is necessary if 'Require users to register when signing in' is enabled. If authentication re-confirmation is disabled, registered users will never be prompted to re-confirm their existing authentication information. If the authentication information for a user changes, such as a phone number or email, then the password reset information for that user reverts to the previously registered authentication information.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Microsoft Entra ID. 1. Under Manage, select Users. 1. Select Password reset. 1. Under Manage, select Registration. 1. Set the Number of days before users are asked to re-confirm their authentication information to your organization-defined frequency. 1. Click Save.

Level 1

6 Identity Services

Ensure that all Global Administrators are notified if any other administrator resets their password.

By default, Notify all admins when other admins reset their password? is set to No.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select Password reset 1. Under Manage, select Notifications 1. Ensure that Notify all admins when other admins reset their password? is set to Yes

All Global Administrators will receive a notification from Azure every time a password is reset. This is useful for auditing procedures to confirm that there are no out of the ordinary password resets for Administrators. There is additional overhead, however, in the time required for Global Administrators to audit the notifications. This setting is only useful if all Global Administrators pay attention to the notifications and audit each one.

Manual

Administrator accounts are sensitive. Any password reset activity notification, when sent to all Administrators, ensures that all Global Administrators can passively confirm if such a reset is a common pattern within their group. For example, if all Administrators change their password every 30 days, any password reset activity before that may require administrator(s) to evaluate any unusual activity and confirm its origin.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select Password reset 1. Under Manage, select Notifications 1. Set Notify all admins when other admins reset their password? to Yes 1. Click Save

Level 1

6 Identity Services

Require administrators to provide consent for applications before use.

By default, Users consent for applications is set to Allow user consent for apps.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Enterprise applications 1. Under Security, select Consent and permissions 1. Under Manage, select User consent settings 1. Ensure User consent for applications is set to Do not allow user consent Audit from PowerShell Connect-MgGraph (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object -ExpandProperty PermissionGrantPoliciesAssigned If the command returns no values in response, the configuration complies with the recommendation.

Enforcing this setting may create additional requests that administrators need to review.

Manual

If Microsoft Entra ID is running as an identity provider for third-party applications, permissions and consent should be limited to administrators or pre-approved. Malicious applications may attempt to exfiltrate data or abuse privileged user accounts.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Enterprise applications 1. Under Security, select Consent and permissions 1. Under Manage, select User consent settings 1. Set User consent for applications to Do not allow user consent 1. Click Save

Level 2

6 Identity Services

Allow users to provide consent for selected permissions when a request is coming from a verified publisher.

By default, User consent for applications is set to Allow user consent for apps.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Enterprise applications 1. Under Security, select Consent and permissions1. UnderManage, select User consent settings1. UnderUser consent for applications, ensure Allow user consent for apps from verified publishers, for selected permissionsis selected **Audit from PowerShell** ``` Connect-MgGraph (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object -ExpandProperty PermissionGrantPoliciesAssigned ``` The command should return eitherManagePermissionGrantsForSelf.microsoft-user-default-low` or a custom app consent policy id if one is in use.

Enforcing this setting may create additional requests that administrators need to review.

Manual

If Microsoft Entra ID is running as an identity provider for third-party applications, permissions and consent should be limited to administrators or pre-approved. Malicious applications may attempt to exfiltrate data or abuse privileged user accounts.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Enterprise applications 1. Under Security, select Consent and permissions1. UnderManage, select User consent settings1. UnderUser consent for applications, select Allow user consent for apps from verified publishers, for selected permissions1. ClickSave`

Level 1

6 Identity Services

Require administrators or appropriately delegated users to register third-party applications.

By default, Users can register applications is set to Yes.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select User settings 1. Ensure that Users can register applications is set to No Audit from PowerShell (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Format-List AllowedToCreateApps Command should return the value of False

Enforcing this setting will create additional requests for approval that will need to be addressed by an administrator. If permissions are delegated, a user may approve a malevolent third party application, potentially giving it access to your data.

Automated

It is recommended to only allow an administrator to register custom-developed applications. This ensures that the application undergoes a formal security review and approval process prior to exposing Microsoft Entra ID data. Certain users like developers or other high-request users may also be delegated permissions to prevent them from waiting on an administrative user. Your organization should review your policies and decide your needs.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select User settings 1. Set Users can register applications to No 1. Click Save Remediate from PowerShell $param = @{ AllowedToCreateApps = $false } Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions $param

Level 1

6 Identity Services

Limit guest user permissions.

By default, Guest user access restrictions is set to Guest users have limited access to properties and memberships of directory objects.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select External Identities 1. Select External collaboration settings 1. Under Guest user access, ensure that Guest user access restrictions is set to Guest user access is restricted to properties and memberships of their own directory objects Audit from PowerShell 1. Enter the following: Connect-MgGraph (Get-MgPolicyAuthorizationPolicy).GuestUserRoleId Which will give a result like: Id : authorizationPolicy OdataType : Description : Used to manage authorization related settings across the company. DisplayName : Authorization Policy EnabledPreviewFeatures : {} GuestUserRoleId : 10dae51f-b6af-4016-8d66-8c2a99b929b3 PermissionGrantPolicyIdsAssignedToDefaultUserRole : {user-default-legacy} If the GuestUserRoleID property does not equal 2af84b1e-32c8-42b7-82bc-daa82404023b then it is not set to most restrictive.

This may create additional requests for permissions to access resources that administrators will need to approve. According to https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions#services-currently-not-supported Service without current support might have compatibility issues with the new guest restriction setting. - Forms - Project - Yammer - Planner in SharePoint

Automated

Limiting guest access ensures that guest accounts do not have permission for certain directory tasks, such as enumerating users, groups or other directory resources, and cannot be assigned to administrative roles in your directory. Guest access has three levels of restriction. 1. Guest users have the same access as members (most inclusive), 2. Guest users have limited access to properties and memberships of directory objects (default value), 3. Guest user access is restricted to properties and memberships of their own directory objects (most restrictive). The recommended option is the 3rd, most restrictive: Guest user access is restricted to their own directory object.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select External Identities 1. Select External collaboration settings 1. Under Guest user access, set Guest user access restrictions to Guest user access is restricted to properties and memberships of their own directory objects 1. Click Save Remediate from PowerShell 1. Enter the following to update the policy ID: Update-MgPolicyAuthorizationPolicy -GuestUserRoleId 2af84b1e-32c8-42b7-82bc-daa82404023b 1. Check the GuestUserRoleId again: (Get-MgPolicyAuthorizationPolicy).GuestUserRoleId 1. Ensure that the GuestUserRoleId is equal to the earlier entered value of 2af84b1e-32c8-42b7-82bc-daa82404023b.

Level 2

6 Identity Services

Restrict invitations to users with specific administrative roles only.

By default, Guest invite restrictions is set to Anyone in the organization can invite guest users including guests and non-admins

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select External Identities 1. Select External collaboration settings 1. Under Guest invite settings, for Guest invite restrictions, ensure that Only users assigned to specific admin roles can invite guest users is selected Note: This setting has 4 levels of restriction, which include: - Anyone in the organization can invite guest users including guests and non-admins (most inclusive), - Member users and users assigned to specific admin roles can invite guest users including guests with member permissions, - Only users assigned to specific admin roles can invite guest users, - No one in the organization can invite guest users including admins (most restrictive). Audit from Powershell Enter the following: Connect-MgGraph (Get-MgPolicyAuthorizationPolicy).AllowInvitesFrom If the resulting value is adminsAndGuestInviters the configuration complies.

With the option of Only users assigned to specific admin roles can invite guest users selected, users with specific admin roles will be in charge of sending invitations to the external users, requiring additional overhead by them to manage user accounts. This will mean coordinating with other departments as they are onboarding new users.

Automated

Restricting invitations to users with specific administrator roles ensures that only authorized accounts have access to cloud resources. This helps to maintain Need to Know permissions and prevents inadvertent access to data. By default the setting Guest invite restrictions is set to Anyone in the organization can invite guest users including guests and non-admins. This would allow anyone within the organization to invite guests and non-admins to the tenant, posing a security risk.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select External Identities 1. Select External collaboration settings 1. Under Guest invite settings, set Guest invite restrictions, to Only users assigned to specific admin roles can invite guest users 1. Click Save Remediate from Powershell Enter the following: Connect-MgGraph Update-MgPolicyAuthorizationPolicy -AllowInvitesFrom adminsAndGuestInviters

Level 1

6 Identity Services

Restrict access to the Microsoft Entra ID administration center to administrators only. NOTE: This only affects access to the Entra ID administrator's web portal. This setting does not prohibit privileged users from using other methods such as Rest API or Powershell to obtain sensitive information from Microsoft Entra ID.

By default, Restrict access to Microsoft Entra admin center is set to No

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select User settings 1. Under Administration centre, ensure that Restrict access to Microsoft Entra admin center is set to Yes

All administrative tasks will need to be done by Administrators, causing additional overhead in management of users and resources.

Manual

The Microsoft Entra ID administrative center has sensitive data and permission settings. All non-administrators should be prohibited from accessing any Microsoft Entra ID data in the administration center to avoid exposure.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Users 1. Under Manage, select User settings 1. Under Administration centre, set Restrict access to Microsoft Entra admin center to Yes 1. Click Save

Level 2

6 Identity Services

Restrict access to group web interface in the Access Panel portal.

By default, Restrict user ability to access groups features in the Access Pane is set to No

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Self Service Group Management, ensure that Restrict user ability to access groups features in My Groups is set to Yes

Setting to Yes could create administrative overhead by customers seeking certain group memberships that will have to be manually managed by administrators with appropriate permissions.

Manual

Self-service group management enables users to create and manage security groups or Office 365 groups in Microsoft Entra ID. Unless a business requires this day-to-day delegation for some users, self-service group management should be disabled. Any user can access the Access Panel, where they can reset their passwords, view their information, etc. By default, users are also allowed to access the Group feature, which shows groups, members, related resources (SharePoint URL, Group email address, Yammer URL, and Teams URL). By setting this feature to 'Yes', users will no longer have access to the web interface, but still have access to the data using the API. This is useful to prevent non-technical users from enumerating groups-related information, but technical users will still be able to access this information using APIs.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Self Service Group Management, set Restrict user ability to access groups features in My Groups to Yes 1. Click Save

Level 2

6 Identity Services

Restrict security group creation to administrators only.

By default, Users can create security groups in Azure portals, API or PowerShell is set to Yes

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Security Groups, ensure that Users can create security groups in Azure portals, API or PowerShell is set to No

Enabling this setting could create a number of requests that would need to be managed by an administrator.

Manual

When creating security groups is enabled, all users in the directory are allowed to create new security groups and add members to those groups. Unless a business requires this day-to-day delegation, security group creation should be restricted to administrators only.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Security Groups, set Users can create security groups in Azure portals, API or PowerShell to No 1. Click Save

Level 2

6 Identity Services

Restrict Microsoft 365 group creation to administrators only.

By default, Users can create Microsoft 365 groups in Azure portals, API or PowerShell is set to Yes.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Microsoft 365 Groups, ensure that Users can create Microsoft 365 groups in Azure portals, API or PowerShell is set to No

Enabling this setting could create a number of requests that would need to be managed by an administrator.

Manual

Restricting Microsoft 365 group creation to administrators only ensures that creation of Microsoft 365 groups is controlled by the administrator. Appropriate groups should be created and managed by the administrator and group creation rights should not be delegated to any other user.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Groups 1. Under Settings, select General 1. Under Microsoft 365 Groups, set Users can create Microsoft 365 groups in Azure portals, API or PowerShell to No 1. Click Save

Level 1

6 Identity Services

NOTE: This recommendation is only relevant if your subscription is using Per-User MFA. If your organization is licensed to use Conditional Access, the preferred method of requiring MFA to join devices to Entra ID is to use a Conditional Access policy (see additional information below for link). Joining or registering devices to Microsoft Entra ID should require multi-factor authentication.

By default, Require Multifactor Authentication to register or join devices with Microsoft Entra is set to No.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Devices 1. Under Manage, select Device settings 1. Under Microsoft Entra join and registration settings, ensure that Require Multifactor Authentication to register or join devices with Microsoft Entra is set to Yes

A slight impact of additional overhead, as Administrators will now have to approve every access to the domain.

Manual

Multi-factor authentication is recommended when adding devices to Microsoft Entra ID. When set to Yes, users who are adding devices from the internet must first use the second method of authentication before their device is successfully added to the directory. This ensures that rogue devices are not added to the domain using a compromised user account.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Devices 1. Under Manage, select Device settings 1. Under Microsoft Entra join and registration settings, set Require Multifactor Authentication to register or join devices with Microsoft Entra to Yes 1. Click Save

If Conditional Access is available, this recommendation should be bypassed in favor of the Conditional Access implementation of requiring Multifactor Authentication to register or join devices with Microsoft Entra. https://learn.microsoft.com/en-us/entra/identity/conditional-access/how-to-policy-mfa-device-register-join

Level 1

6 Identity Services

The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access.

By default, no custom owner roles are created.

Audit from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Subscriptions. 1. Select a subscription. 1. Select Access control (IAM). 1. Select Roles. 1. Click Type and select Custom role from the drop-down menu. 1. Select View next to a role. 1. Select JSON. 1. Check for assignableScopes set to the subscription, and actions set to *. 1. Repeat steps 7-9 for each custom role. Audit from Azure CLI List custom roles: az role definition list --custom-role-only True Check for entries with assignableScope of the subscription, and an action of * Audit from PowerShell Connect-AzAccount Get-AzRoleDefinition |Where-Object {($_.IsCustom -eq $true) -and ($_.Actions.contains('*'))} Check the output for AssignableScopes value set to the subscription. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: a451c1ef-c6ca-483d-87ed-f49761e3ffb5 - Name: 'Audit usage of custom RBAC roles'

Subscriptions will need to be handled by Administrators with permissions.

Automated

Custom roles in Azure with administrative access can obfuscate the permissions granted and introduce complexity and blind spots to the management of privileged identities. For less mature security programs without regular identity audits, the creation of Custom roles should be avoided entirely. For more mature security programs with regular identity audits, Custom Roles should be audited for use and assignment, used minimally, and the principle of least privilege should be observed when granting permissions

Remediate from Azure Portal 1. From Azure Home select the Portal Menu. 1. Select Subscriptions. 1. Select a subscription. 1. Select Access control (IAM). 1. Select Roles. 1. Click Type and select Custom role from the drop-down menu. 1. Check the box next to each role which grants subscription administrator privileges. 1. Select Delete. 1. Select Yes. Remediate from Azure CLI List custom roles: az role definition list --custom-role-only True Check for entries with assignableScope of the subscription, and an action of *. To remove a violating role: az role definition delete --name <role name> Note that any role assignments must be removed before a custom role can be deleted. Ensure impact is assessed before deleting a custom role granting subscription administrator privileges.

Level 2

6 Identity Services

Resource locking is a powerful protection mechanism that can prevent inadvertent modification or deletion of resources within Azure subscriptions and resource groups, and it is a recommended NIST configuration.

A role for administering resource locks does not exist by default.

Audit from Azure Portal 1. In the Azure portal, navigate to a subscription or resource group. 1. Click Access control (IAM). 1. Click Roles. 1. Click Type : All. 1. Click to view the drop-down menu. 1. Select Custom role. 1. Click View in the Details column of a custom role. 1. Review the role permissions. 1. Click Assignments and review the assignments. 1. Click the X to exit the custom role details page. 1. Repeat steps 7-10. Ensure that at least one custom role exists that assigns the Microsoft.Authorization/locks permission to appropriate members. 1. Repeat steps 1-11 for each subscription or resource group.

By adding this role, specific permissions may be granted for managing only resource locks rather than needing to provide the broad Owner or User Access Administrator role, reducing the risk of the user being able to cause unintentional damage.

Manual

Given that the resource lock functionality is outside of standard Role-Based Access Control (RBAC), it would be prudent to create a resource lock administrator role to prevent inadvertent unlocking of resources.

Remediate from Azure Portal 1. In the Azure portal, navigate to a subscription or resource group. 1. Click Access control (IAM). 1. Click + Add. 1. Click Add custom role. 1. In the Custom role name field enter Resource Lock Administrator. 1. In the Description field enter Can Administer Resource Locks. 1. For Baseline permissions select Start from scratch. 1. Click Next. 1. Click Add permissions. 1. In the Search for a permission box, type Microsoft.Authorization/locks. 1. Click the result. 1. Check the box next to Permission. 1. Click Add. 1. Click Review + create. 1. Click Create. 1. Click OK. 1. Click + Add. 1. Click Add role assignment. 1. In the Search by role name, description, permission, or ID box, type Resource Lock Administrator. 1. Select the role. 1. Click Next. 1. Click + Select members. 1. Select appropriate members. 1. Click Select. 1. Click Review + assign. 1. Click Review + assign again. 1. Repeat steps 1-26 for each subscription or resource group requiring remediation. Remediate from PowerShell: Below is a PowerShell definition for a resource lock administrator role created at an Azure Management group level Import-Module Az.Accounts Connect-AzAccount $role = Get-AzRoleDefinition User Access Administrator $role.Id = $null $role.Name = Resource Lock Administrator $role.Description = Can Administer Resource Locks $role.Actions.Clear() $role.Actions.Add(Microsoft.Authorization/locks/*) $role.AssignableScopes.Clear() * Scope at the Management group level Management group $role.AssignableScopes.Add(/providers/Microsoft.Management/managementGroups/MG-Name) New-AzRoleDefinition -Role $role Get-AzureRmRoleDefinition Resource Lock Administrator

Level 2

6 Identity Services

Users who are set as subscription owners are able to make administrative changes to the subscriptions and move them into and out of Microsoft Entra ID.

By default Subscription leaving Microsoft Entra tenant and Subscription entering Microsoft Entra tenant are set to Allow everyone (default)

Audit from Azure Portal 1. From the Azure Portal Home select the portal menu 1. Select Subscriptions 1. In the Advanced options drop-down menu, select Manage Policies 1. Ensure Subscription leaving Microsoft Entra tenant and Subscription entering Microsoft Entra tenant are set to Permit no one

Subscriptions will need to have these settings turned off to be moved.

Manual

Permissions to move subscriptions in and out of a Microsoft Entra tenant must only be given to appropriate administrative personnel. A subscription that is moved into a Microsoft Entra tenant may be within a folder to which other users have elevated permissions. This prevents loss of data or unapproved changes of the objects within by potential bad actors.

Remediate from Azure Portal 1. From the Azure Portal Home select the portal menu 1. Select Subscriptions 1. In the Advanced options drop-down menu, select Manage Policies 1. Set Subscription leaving Microsoft Entra tenant and Subscription entering Microsoft Entra tenant to Permit no one 1. Click Save changes

Level 1

6 Identity Services

This recommendation aims to maintain a balance between security and operational efficiency by ensuring that a minimum of 2 and a maximum of 4 users are assigned the Global Administrator role in Microsoft Entra ID. Having at least two Global Administrators ensures redundancy, while limiting the number to four reduces the risk of excessive privileged access.

Audit from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Roles and administrators 1. Under Administrative Roles, select Global Administrator 1. Ensure less than 5 users are actively assigned the role. 1. Ensure that at least 2 users are actively assigned the role.

Implementing this recommendation may require changes in administrative workflows or the redistribution of roles and responsibilities. Adequate training and awareness should be provided to all Global Administrators.

Manual

The Global Administrator role has extensive privileges across all services in Microsoft Entra ID. The Global Administrator role should never be used in regular daily activities; administrators should have a regular user account for daily activities, and a separate account for administrative responsibilities. Limiting the number of Global Administrators helps mitigate the risk of unauthorized access, reduces the potential impact of human error, and aligns with the principle of least privilege to reduce the attack surface of an Azure tenant. Conversely, having at least two Global Administrators ensures that administrative functions can be performed without interruption in case of unavailability of a single admin.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu 1. Select Microsoft Entra ID 1. Under Manage, select Roles and administrators 1. Under Administrative Roles, select Global Administrator If more than 4 users are assigned: 1. Remove Global Administrator role for users which do not or no longer require the role. 1. Assign Global Administrator role via PIM which can be activated when required. 1. Assign more granular roles to users to conduct their duties. If only one user is assigned: 1. Provide the Global Administrator role to a trusted user or create a break glass admin account.

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Enable Diagnostic settings for exporting activity logs. Diagnostic settings are available for each individual resource within a subscription. Settings should be configured for all appropriate resources for your environment.

By default, diagnostic setting is not set.

Audit from Azure Portal To identify Diagnostic Settings on a subscription: 1. Go to Monitor 2. Click Activity Log 3. Click Export Activity Logs 4. Select a Subscription 5. Ensure a Diagnostic setting exists for the selected Subscription To identify Diagnostic Settings on specific resources: 1. Go to Monitoring 2. Click Diagnostic settings 3. Ensure a Diagnostic setting exists for all appropriate resources. Audit from Azure CLI To identify Diagnostic Settings on a subscription: az monitor diagnostic-settings subscription list --subscription <subscription ID> To identify Diagnostic Settings on a resource az monitor diagnostic-settings list --resource <resource Id> Audit from PowerShell To identify Diagnostic Settings on a Subscription: Get-AzDiagnosticSetting -SubscriptionId <subscription ID> To identify Diagnostic Settings on a specific resource: Get-AzDiagnosticSetting -ResourceId <resource ID>

Manual

A diagnostic setting controls how a diagnostic log is exported. By default, logs are retained only for 90 days. Diagnostic settings should be defined so that logs can be exported and stored for a longer duration to analyze security activities within an Azure subscription.

Remediate from Azure Portal To enable Diagnostic Settings on a Subscription: 1. Go to Monitor 2. Click on Activity log 3. Click on Export Activity Logs 4. Click + Add diagnostic setting 5. Enter a Diagnostic setting name 6. Select Categories for the diagnostic setting 7. Select the appropriate Destination details (this may be Log Analytics, Storage Account, Event Hub, or Partner solution) 8. Click Save To enable Diagnostic Settings on a specific resource: 1. Go to Monitoring 1. Click Diagnostic settings 1. Select Add diagnostic setting 1. Enter a Diagnostic setting name 1. Select the appropriate log, metric, and destination (this may be Log Analytics, Storage Account, Event Hub, or Partner solution) 1. Click Save Repeat these step for all resources as needed. Remediate from Azure CLI To configure Diagnostic Settings on a Subscription: az monitor diagnostic-settings subscription create --subscription <subscription id> --name <diagnostic settings name> --location <location> <[--event-hub <event hub ID> --event-hub-auth-rule <event hub auth rule ID>] [--storage-account <storage account ID>] [--workspace <log analytics workspace ID>] --logs <JSON encoded categories> (e.g. [{category:Security,enabled:true},{category:Administrative,enabled:true},{category:Alert,enabled:true},{category:Policy,enabled:true}]) To configure Diagnostic Settings on a specific resource: az monitor diagnostic-settings create --subscription <subscription ID> --resource <resource ID> --name <diagnostic settings name> <[--event-hub <event hub ID> --event-hub-rule <event hub auth rule ID>] [--storage-account <storage account ID>] [--workspace <log analytics workspace ID>] --logs <resource specific JSON encoded log settings> --metrics <metric settings (shorthand|json-file|yaml-file)> Remediate from PowerShell To configure Diagnostic Settings on a subscription: $logCategories = @(); $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Administrative -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Security -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category ServiceHealth -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Alert -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Recommendation -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Policy -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Autoscale -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category ResourceHealth -Enabled $true New-AzSubscriptionDiagnosticSetting -SubscriptionId <subscription ID> -Name <Diagnostic settings name> <[-EventHubAuthorizationRule <event hub auth rule ID> -EventHubName <event hub name>] [-StorageAccountId <storage account ID>] [-WorkSpaceId <log analytics workspace ID>] [-MarketplacePartner ID <full ARM Marketplace resource ID>]> -Log $logCategories To configure Diagnostic Settings on a specific resource: ``` $logCategories = @() $logCategories += New-AzDiagnosticSettingLogSettingsObject -Category <resource specific log category> -Enabled $true Repeat command and variable assignment for each Log category specific to the resource where this Diagnostic Setting will get configured. $metricCategories = @() $metricCategories += New-AzDiagnosticSettingMetricSettingsObject -Enabled $true [-Category <resource specific metric category | AllMetrics>] [-RetentionPolicyDay <Integer>] [-RetentionPolicyEnabled $true] Repeat command and variable assignment for each Metric category or use the 'AllMetrics' category. New-AzDiagnosticSetting -ResourceId <resource ID> -Name <Diagnostic settings name> -Log $logCategories -Metric $metricCategories [-EventHubAuthorizationRuleId <event hub auth rule ID> -EventHubName <event hub name>] [-StorageAccountId <storage account ID>] [-WorkspaceId <log analytics workspace ID>] [-MarketplacePartnerId <full ARM marketplace resource ID>]>

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Prerequisite: A Diagnostic Setting must exist. If a Diagnostic Setting does not exist, the navigation and options within this recommendation will not be available. Please review the recommendation at the beginning of this subsection titled: Ensure that a 'Diagnostic Setting' exists. The diagnostic setting should be configured to log the appropriate activities from the control/management plane.

When the diagnostic setting is created using Azure Portal, by default no categories are selected.

Audit from Azure Portal 1. Go to Monitor. 1. Click Activity log. 1. Click on Export Activity Logs. 1. Select the appropriate Subscription. 1. Click Edit setting next to a diagnostic setting. 1. Ensure that the following categories are checked: Administrative, Alert, Policy, and Security. Audit from Azure CLI Ensure the categories 'Administrative', 'Alert', 'Policy', and 'Security' set to: 'enabled: true' az monitor diagnostic-settings subscription list --subscription <subscription ID> Audit from PowerShell Ensure the categories Administrative, Alert, Policy, and Security are set to Enabled:True Get-AzSubscriptionDiagnosticSetting -Subscription <subscriptionID> Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 3b980d31-7904-4bb7-8575-5665739a8052 - Name: 'An activity log alert should exist for specific Security operations' - Policy ID: b954148f-4c11-4c38-8221-be76711e194a - Name: 'An activity log alert should exist for specific Administrative operations' - Policy ID: c5447c04-a4d7-4ba8-a263-c9ee321a6858 - Name: 'An activity log alert should exist for specific Policy operations'

Automated

A diagnostic setting controls how the diagnostic log is exported. Capturing the diagnostic setting categories for appropriate control/management plane activities allows proper alerting.

Remediate from Azure Portal 1. Go to Monitor. 1. Click Activity log. 1. Click on Export Activity Logs. 1. Select the Subscription from the drop down menu. 1. Click Edit setting next to a diagnostic setting. 1. Check the following categories: Administrative, Alert, Policy, and Security. 1. Choose the destination details according to your organization's needs. 1. Click Save. Remediate from Azure CLI az monitor diagnostic-settings subscription create --subscription <subscription id> --name <diagnostic settings name> --location <location> <[--event-hub <event hub ID> --event-hub-auth-rule <event hub auth rule ID>] [--storage-account <storage account ID>] [--workspace <log analytics workspace ID>] --logs [{category:Security,enabled:true},{category:Administrative,enabled:true},{category:Alert,enabled:true},{category:Policy,enabled:true}] Remediate from PowerShell $logCategories = @(); $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Administrative -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Security -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Alert -Enabled $true $logCategories += New-AzDiagnosticSettingSubscriptionLogSettingsObject -Category Policy -Enabled $true New-AzSubscriptionDiagnosticSetting -SubscriptionId <subscription ID> -Name <Diagnostic settings name> <[-EventHubAuthorizationRule <event hub auth rule ID> -EventHubName <event hub name>] [-StorageAccountId <storage account ID>] [-WorkSpaceId <log analytics workspace ID>] [-MarketplacePartner ID <full ARM Marketplace resource ID>]> -Log $logCategories

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Storage accounts with the activity log exports can be configured to use Customer Managed Keys (CMK).

By default, for a storage account keySource is set to Microsoft.Storage allowing encryption with vendor Managed key and not a Customer Managed Key.

Audit from Azure Portal 1. Go to Monitor. 1. Select Activity log. 1. Select Export Activity Logs. 1. Select a Subscription. 1. Note the name of the Storage Account for the diagnostic setting. 1. Navigate to Storage accounts. 1. Click on the storage account name noted in Step 5. 1. Under Security + networking, click Encryption. 1. Ensure Customer-managed keys is selected and a key is set. Audit from Azure CLI 1. Get storage account id configured with log profile: az monitor diagnostic-settings subscription list --subscription <subscription id> --query 'value[*].storageAccountId' 2. Ensure the storage account is encrypted with CMK: az storage account list --query [?name=='<Storage Account Name>'] In command output ensure keySource is set to Microsoft.Keyvault and keyVaultProperties is not set to null Audit from PowerShell Get-AzStorageAccount -ResourceGroupName <resource group name> -Name <storage account name>|select-object -ExpandProperty encryption|format-list Ensure the value of KeyVaultProperties is not null or empty, and ensure KeySource is not set to Microsoft.Storage. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: fbb99e8e-e444-4da0-9ff1-75c92f5a85b2 - Name: 'Storage account containing the container with activity logs must be encrypted with BYOK'

NOTE: You must have your key vault setup to utilize this. All Audit Logs will be encrypted with a key you provide. You will need to set up customer managed keys separately, and you will select which key to use via the instructions here. You will be responsible for the lifecycle of the keys, and will need to manually replace them at your own determined intervals to keep the data secure.

Automated

Configuring the storage account with the activity log export container to use CMKs provides additional confidentiality controls on log data, as a given user must have read permission on the corresponding storage account and must be granted decrypt permission by the CMK.

Remediate from Azure Portal 1. Go to Monitor. 1. Select Activity log. 1. Select Export Activity Logs. 1. Select a Subscription. 1. Note the name of the Storage Account for the diagnostic setting. 1. Navigate to Storage accounts. 1. Click on the storage account. 1. Under Security + networking, click Encryption. 1. Next to Encryption type, select Customer-managed keys. 1. Complete the steps to configure a customer-managed key for encryption of the storage account. Remediate from Azure CLI az storage account update --name <name of the storage account> --resource-group <resource group for a storage account> --encryption-key-source=Microsoft.Keyvault --encryption-key-vault <Key Vault URI> --encryption-key-name <KeyName> --encryption-key-version <Key Version> Remediate from PowerShell Set-AzStorageAccount -ResourceGroupName <resource group name> -Name <storage account name> -KeyvaultEncryption -KeyVaultUri <key vault URI> -KeyName <key name>

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Enable AuditEvent logging for key vault instances to ensure interactions with key vaults are logged and available.

By default, Diagnostic AuditEvent logging is not enabled for Key Vault instances.

Audit from Azure Portal 1. Go to Key vaults. 1. For each Key vault, under Monitoring, go to Diagnostic settings. 1. Click Edit setting next to a diagnostic setting. 1. Ensure that a destination is configured. 1. Under Category groups, ensure that audit and allLogs are checked. Audit from Azure CLI List all key vaults az keyvault list For each keyvault id az monitor diagnostic-settings list --resource <id> Ensure that storageAccountId reflects your desired destination and that categoryGroup and enabled are set as follows in the sample outputs below. logs: [ { categoryGroup: audit, enabled: true, }, { categoryGroup: allLogs, enabled: true, } Audit from PowerShell List the key vault(s) in the subscription Get-AzKeyVault For each key vault, run the following: Get-AzDiagnosticSetting -ResourceId <key_vault_id> Ensure that StorageAccountId, ServiceBusRuleId, MarketplacePartnerId, or WorkspaceId is set as appropriate. Also, ensure that enabled is set to true, and that categoryGroup reflects both audit and allLogs category groups. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: cf820ca0-f99e-4f3e-84fb-66e913812d21 - Name: 'Resource logs in Key Vault should be enabled'

Automated

Monitoring how and when key vaults are accessed, and by whom, enables an audit trail of interactions with confidential information, keys, and certificates managed by Azure Key Vault. Enabling logging for Key Vault saves information in a user provided destination of either an Azure storage account or Log Analytics workspace. The same destination can be used for collecting logs for multiple Key Vaults.

Remediate from Azure Portal 1. Go to Key vaults. 2. Select a Key vault. 3. Under Monitoring, select Diagnostic settings. 4. Click Edit setting to update an existing diagnostic setting, or Add diagnostic setting to create a new one. 5. If creating a new diagnostic setting, provide a name. 6. Configure an appropriate destination. 7. Under Category groups, check audit and allLogs. 8. Click Save. Remediate from Azure CLI To update an existing Diagnostic Settings az monitor diagnostic-settings update --name <diagnostic_setting_name> --resource <key_vault_id> To create a new Diagnostic Settings az monitor diagnostic-settings create --name <diagnostic_setting_name> --resource <key_vault_id> --logs [{category:audit,enabled:true},{category:allLogs,enabled:true}] --metrics [{category:AllMetrics,enabled:true}] <[--event-hub <event_hub_ID> --event-hub-rule <event_hub_auth_rule_ID> | --storage-account <storage_account_ID> |--workspace <log_analytics_workspace_ID> | --marketplace-partner-id <solution_resource_ID>]> Remediate from PowerShell Create the Log settings object $logSettings = @() $logSettings += New-AzDiagnosticSettingLogSettingsObject -Enabled $true -Category audit $logSettings += New-AzDiagnosticSettingLogSettingsObject -Enabled $true -Category allLogs Create the Metric settings object $metricSettings = @() $metricSettings += New-AzDiagnosticSettingMetricSettingsObject -Enabled $true -Category AllMetrics Create the Diagnostic Settings for each Key Vault New-AzDiagnosticSetting -Name <diagnostic_setting_name> -ResourceId <key_vault_id> -Log $logSettings -Metric $metricSettings [-StorageAccountId <storage_account_ID> | -EventHubName <event_hub_name> -EventHubAuthorizationRuleId <event_hub_auth_rule_ID> | -WorkSpaceId <log analytics workspace ID> | -MarketPlacePartnerId <full resource ID for third-party solution>]

DEPRECATION WARNING Retention rules for Key Vault logging is being migrated to Azure Storage Lifecycle Management. Retention rules should be set based on the needs of your organization and security or compliance frameworks. Please visit https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/migrate-to-azure-storage-lifecycle-policy?tabs=portal for detail on migrating your retention rules. Microsoft has provided the following deprecation timeline: March 31, 2023 – The Diagnostic Settings Storage Retention feature will no longer be available to configure new retention rules for log data. This includes using the portal, CLI PowerShell, and ARM and Bicep templates. If you have configured retention settings, you'll still be able to see and change them in the portal. March 31, 2024 – You will no longer be able to use the API (CLI, Powershell, or templates), or Azure portal to configure retention setting unless you're changing them to 0. Existing retention rules will still be respected. September 30, 2025 – All retention functionality for the Diagnostic Settings Storage Retention feature will be disabled across all environments.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Ensure that network flow logs are captured and fed into a central log analytics workspace. Retirement Notice On September 30, 2027, network security group (NSG) flow logs will be retired. Starting June 30, 2025, it will no longer be possible to create new NSG flow logs. Azure recommends migrating to virtual network flow logs. Review https://azure.microsoft.com/en-gb/updates?id=Azure-NSG-flow-logs-Retirement for more information. For virtual network flow logs, consider applying the recommendation Ensure that virtual network flow logs are captured and sent to Log Analytics in this section.

By default Network Security Group logs are not sent to Log Analytics.

Audit from Azure Portal 1. Navigate to Network Watcher. 1. Under Logs, select Flow logs. 1. Click Add filter. 1. From the Filter drop-down, select Flow log type. 1. Review existing Network security group flow logs, if any remain, to ensure they are enabled and configured to send logs to a Log Analytics Workspace. 1. Review Virtual network flow logs for new or migrated coverage. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 27960feb-a23c-4577-8d36-ef8b5f35e0be - Name: 'All flow log resources should be in enabled state' - Policy ID: c251913d-7d24-4958-af87-478ed3b9ba41 - Name: 'Flow logs should be configured for every network security group' - Policy ID: 4c3c6c5f-0d47-4402-99b8-aa543dd8bcee - Name: 'Flow logs should be configured for every virtual network'

The impact of configuring NSG Flow logs is primarily one of cost and configuration. If deployed, it will create storage accounts that hold minimal amounts of data on a 5-day lifecycle before feeding to Log Analytics Workspace. This will increase the amount of data stored and used by Azure Monitor.

Manual

Network Flow Logs provide valuable insight into the flow of traffic around your network and feed into both Azure Monitor and Azure Sentinel (if in use), permitting the generation of visual flow diagrams to aid with analyzing for lateral movement, etc.

Remediate from Azure Portal Existing NSG flow logs can still be reviewed under Network Watcher > Flow logs. If you already have NSG flow logs configured, ensure they remain enabled and that Traffic Analytics sends data to a Log Analytics Workspace until migration is complete. Azure no longer allows creation of new NSG flow logs after June 30, 2025. For new or migrated deployments, create Virtual network flow logs instead: 1. Navigate to Network Watcher. 1. Under Logs, select Flow logs. 1. Select + Create. 1. Select the desired Subscription. 1. For Flow log type, select Virtual network. 1. Select + Select target resource. 1. Select Virtual network. 1. Select a virtual network. 1. Click Confirm selection. 1. Select or create a new Storage Account. 1. If using a v2 storage account, input the retention in days to retain the log. 1. Click Next. 1. Under Analytics, for Flow log version, select Version 2. 1. Check the box next to Enable traffic analytics. 1. Select a processing interval. 1. Select a Log Analytics Workspace. 1. Select Next. 1. Optionally add Tags. 1. Select Review + create. 1. Select Create.

On September 30, 2027, NSG flow logs will be retired, and creating new NSG flow logs has not been possible since June 30, 2025. Azure recommends migrating to virtual network flow logs, which address NSG flow log limitations. After retirement, traffic analytics using NSG flow logs will no longer be supported, and existing NSG flow log resources will be deleted. Previously collected NSG flow log records will remain available per their retention policies. For details, see the official announcement: https://azure.microsoft.com/en-gb/updates?id=Azure-NSG-flow-logs-Retirement.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Enable AppServiceHTTPLogs diagnostic log category for Azure App Service instances to ensure all http requests are captured and centrally logged.

Not configured.

Audit from Azure Portal 1. Go to App Services. For each App Service: 2. Under Monitoring, go to Diagnostic settings. 3. Ensure a diagnostic setting exists that logs HTTP logs to a destination aligned to your environment's approach to log consumption (event hub, storage account, etc. dependent on what is consuming the logs such as SIEM or other log aggregation utility). Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 91a78b24-f231-4a8a-8da9-02c35b2b6510 - Name: 'App Service apps should have resource logs enabled' - Policy ID: d639b3af-a535-4bef-8dcf-15078cddf5e2 - Name: 'App Service app slots should have resource logs enabled'

Log consumption and processing will incur additional cost.

Automated

Capturing web requests can be important supporting information for security analysts performing monitoring and incident response activities. Once logging, these logs can be ingested into SIEM or other central aggregation point for the organization.

Remediate from Azure Portal 1. Go to App Services. For each App Service: 2. Under Monitoring, go to Diagnostic settings. 3. To update an existing diagnostic setting, click Edit setting against the setting. To create a new diagnostic setting, click Add diagnostic setting and provide a name for the new setting. 4. Check the checkbox next to HTTP logs. 5. Configure a destination based on your specific logging consumption capability (for example Stream to an event hub and then consuming with SIEM integration for Event Hub logging). 6. Click Save.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Ensure that virtual network flow logs are captured and fed into a central log analytics workspace.

Audit from Azure Portal 1. Go to Network Watcher. 1. Under Logs, select Flow logs. 1. Click Add filter. 1. From the Filter drop-down menu, select Flow log type. 1. From the Value drop-down menu, check Virtual network only. 1. Click Apply. 1. Ensure that at least one virtual network flow log is listed and is configured to send logs to a Log Analytics Workspace. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 2f080164-9f4d-497e-9db6-416dc9f7b48a - Name: 'Network Watcher flow logs should have traffic analytics enabled' - Policy ID: 4c3c6c5f-0d47-4402-99b8-aa543dd8bcee - Name: 'Audit flow logs configuration for every virtual network'

• Virtual network flow logs are charged per gigabyte of network flow logs collected and come with a free tier of 5 GB/month per subscription. * If traffic analytics is enabled with virtual network flow logs, traffic analytics pricing applies at per gigabyte processing rates. * The storage of logs is charged separately.

Manual

Virtual network flow logs provide critical visibility into traffic patterns. Sending logs to a Log Analytics workspace enables centralized analysis, correlation, and alerting for faster threat detection and response.

Remediate from Azure Portal 1. Go to Network Watcher. 1. Under Logs, click Flow logs. 1. Click + Create. 1. Select a subscription. 1. Next to Flow log type, select Virtual network. 1. Click + Select target resource. 1. Select Virtual network. 1. Select a virtual network. 1. Click Confirm selection. 1. Select a storage account, or create a new storage account. 1. Set the retention in days for the storage account. 1. Click Next. 1. Under Analytics, for Flow logs version, select Version 2. 1. Check the box next to Enable traffic analytics. 1. Select a processing interval. 1. Select a Log Analytics Workspace. 1. Click Next. 1. Optionally, add Tags. 1. Click Review + create. 1. Click Create. 1. Repeat steps 1-20 for each subscription or virtual network requiring remediation.

On September 30, 2027, NSG flow logs will be retired, and creating new NSG flow logs will no longer be possible after June 30, 2025. Azure recommends migrating to virtual network flow logs, which address NSG flow log limitations. After retirement, traffic analytics using NSG flow logs will no longer be supported, and existing NSG flow log resources will be deleted. Previously collected NSG flow log records will remain available per their retention policies. For details, see the official announcement: https://azure.microsoft.com/en-gb/updates?id=Azure-NSG-flow-logs-Retirement.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Ensure that a Microsoft Entra diagnostic setting is configured to send Microsoft Graph activity logs to a suitable destination, such as a Log Analytics workspace, storage account, or event hub. This enables centralized monitoring and analysis of all HTTP requests that the Microsoft Graph service receives and processes for a tenant.

By default, Microsoft Entra diagnostic settings do not exist.

Audit from Azure Portal 1. Go to Microsoft Entra ID. 1. Under Monitoring, click Diagnostic settings. 1. Next to each diagnostic setting, click Edit setting, and review the selected log categories and destination details. 1. Ensure that at least one diagnostic setting is configured to send MicrosoftGraphActivityLogs to an appropriate destination.

A Microsoft Entra ID P1 or P2 tenant license is required to access the Microsoft Graph activity logs. The amount of data logged and, thus, the cost incurred can vary significantly depending on the tenant size and the applications in your tenant that interact with the Microsoft Graph APIs. See the following pricing calculations for respective services: - Log Analytics: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/cost-logs#pricing-model. - Azure Storage: https://azure.microsoft.com/en-gb/pricing/details/storage/blobs/. - Event Hubs: https://azure.microsoft.com/en-gb/pricing/details/event-hubs/

Manual

Microsoft Graph activity logs provide visibility into HTTP requests made to the Microsoft Graph service, helping detect unauthorized access, suspicious activity, and security threats. Configuring diagnostic settings in Microsoft Entra ensures these logs are collected and sent to an appropriate destination for monitoring, analysis, and retention.

Remediate from Azure Portal 1. Go to Microsoft Entra ID. 1. Under Monitoring, click Diagnostic settings. 1. Click + Add diagnostic setting. 1. Provide a Diagnostic setting name. 1. Under Logs > Categories, check the box next to MicrosoftGraphActivityLogs. 1. Configure an appropriate destination for the logs. 1. Click Save.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Ensure that a Microsoft Entra diagnostic setting is configured to send Microsoft Entra activity logs to a suitable destination, such as a Log Analytics workspace, storage account, or event hub. This enables centralized monitoring and analysis of Microsoft Entra activity logs.

By default, Microsoft Entra diagnostic settings do not exist.

Audit from Azure Portal 1. Go to Microsoft Entra ID. 1. Under Monitoring, click Diagnostic settings. 1. Next to each diagnostic setting, click Edit setting, and review the selected log categories and destination details. 1. Ensure that at least one diagnostic setting is configured to send the following logs to an appropriate destination: - AuditLogs - SignInLogs - NonInteractiveUserSignInLogs - ServicePrincipalSignInLogs - ManagedIdentitySignInLogs - ProvisioningLogs - ADFSSignInLogs - RiskyUsers - UserRiskEvents - NetworkAccessTrafficLogs - RiskyServicePrincipals - ServicePrincipalRiskEvents - EnrichedOffice365AuditLogs - MicrosoftGraphActivityLogs - RemoteNetworkHealthLogs - NetworkAccessAlerts

To export sign-in data, your organization needs an Azure AD P1 or P2 license. The amount of data logged and, thus, the cost incurred can vary significantly depending on the tenant size. See the following pricing calculations for respective services: - Log Analytics: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/cost-logs#pricing-model. - Azure Storage: https://azure.microsoft.com/en-gb/pricing/details/storage/blobs/. - Event Hubs: https://azure.microsoft.com/en-gb/pricing/details/event-hubs/

Manual

Microsoft Entra activity logs enables you to assess many aspects of your Microsoft Entra tenant. Configuring diagnostic settings in Microsoft Entra ensures these logs are collected and sent to an appropriate destination for monitoring, analysis, and retention.

Remediate from Azure Portal 1. Go to Microsoft Entra ID. 1. Under Monitoring, click Diagnostic settings. 1. Click + Add diagnostic setting. 1. Provide a Diagnostic setting name. 1. Under Logs > Categories, check the box next to each of the following logs: - AuditLogs - SignInLogs - NonInteractiveUserSignInLogs - ServicePrincipalSignInLogs - ManagedIdentitySignInLogs - ProvisioningLogs - ADFSSignInLogs - RiskyUsers - UserRiskEvents - NetworkAccessTrafficLogs - RiskyServicePrincipals - ServicePrincipalRiskEvents - EnrichedOffice365AuditLogs - MicrosoftGraphActivityLogs - RemoteNetworkHealthLogs - NetworkAccessAlerts 1. Configure an appropriate destination for the logs. 1. Click Save.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Ensure that Intune logs are captured and fed into a central log analytics workspace.

By default, Intune diagnostic settings do not exist.

Audit from Azure Portal 1. Go to Intune. 1. Click Reports. 1. Under Azure monitor, click Diagnostic settings. 1. Next to each diagnostic setting, click Edit setting, and review the selected log categories and destination details. 1. Ensure that at least one diagnostic setting is configured to send the following logs to a Log Analytics workspace: - AuditLogs - OperationalLogs - DeviceComplianceOrg - Devices - Windows365AuditLogs

A Microsoft Intune plan is required to access Intune: https://www.microsoft.com/en-gb/security/business/microsoft-intune-pricing. The amount of data logged and, thus, the cost incurred can vary significantly depending on the tenant size. For information on Log Analytics workspace costs, visit: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/cost-logs.

Manual

Intune includes built-in logs that provide information about your environments. Sending logs to a Log Analytics workspace enables centralized analysis, correlation, and alerting for faster threat detection and response.

Remediate from Azure Portal 1. Go to Intune. 1. Click Reports. 1. Under Azure monitor, click Diagnostic settings. 1. Click + Add diagnostic setting. 1. Provide a Diagnostic setting name. 1. Under Logs > Categories, check the box next to each of the following logs: - AuditLogs - OperationalLogs - DeviceComplianceOrg - Devices - Windows365AuditLogs 1. Under Destination details, check the box next to Send to Log Analytics workspace. 1. Select a Subscription. 1. Select a Log Analytics workspace. 1. Click Save.

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Create Policy Assignment event.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Authorization/policyAssignments/write. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Create policy assignment' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription ID> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Authorization/policyAssignments/write in the output. If it's missing, generate a finding. Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Authorization/policyAssignments/write}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf If the output is empty, an alert rule for Create Policy Assignments is not configured. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: c5447c04-a4d7-4ba8-a263-c9ee321a6858 - Name: 'An activity log alert should exist for specific Policy operations'

Automated

Monitoring for create policy assignment events gives insight into changes done in Azure policy - assignments and can reduce the time it takes to detect unsolicited changes.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Create policy assignment (Policy assignment). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Authorization/policyAssignments/write and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription ID> --action-group <action group ID> Remediate from PowerShell Create the conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Authorization/policyAssignments/write -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Get the Action Group information and store it in a variable, then create a new Action object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope variable. $scope = /subscriptions/<subscription ID> Create the Activity Log Alert Rule for Microsoft.Authorization/policyAssignments/write New-AzActivityLogAlert -Name <activity alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Delete Policy Assignment event.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Authorization/policyAssignments/delete. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Delete policy assignment' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription ID> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Authorization/policyAssignments/delete in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Authorization/policyAssignments/delete}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: c5447c04-a4d7-4ba8-a263-c9ee321a6858 - Name: 'An activity log alert should exist for specific Policy operations'

Automated

Monitoring for delete policy assignment events gives insight into changes done in azure policy - assignments and can reduce the time it takes to detect unsolicited changes.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Delete policy assignment (Policy assignment). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Authorization/policyAssignments/delete and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the conditions object $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Authorization/policyAssignments/delete -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Action object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope variable. $scope = /subscriptions/<subscription id> Create the Activity Log Alert Rule for Microsoft.Authorization/policyAssignments/delete. New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

This log alert also applies for Azure Blueprints.

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an Activity Log Alert for the Create or Update Network Security Group event.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Network/networkSecurityGroups/write. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Create or Update Network Security Group' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription ID> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Network/networkSecurityGroups/write in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Network/networkSecurityGroups/write}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: b954148f-4c11-4c38-8221-be76711e194a - Name: 'An activity log alert should exist for specific Administrative operations'

Automated

Monitoring for Create or Update Network Security Group events gives insight into network access changes and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Create or Update Network Security Group (Network Security Group). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Network/networkSecurityGroups/write and level=verbose --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Network/networkSecurityGroups/write -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription id> Create the Activity Log Alert Rule for Microsoft.Network/networkSecurityGroups/write New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Delete Network Security Group event.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Network/networkSecurityGroups/delete. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Delete Network Security Group' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription ID> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Network/networkSecurityGroups/delete in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Network/networkSecurityGroups/delete}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: b954148f-4c11-4c38-8221-be76711e194a - Name: 'An activity log alert should exist for specific Administrative operations'

Automated

Monitoring for Delete Network Security Group events gives insight into network access changes and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Delete Network Security Group (Network Security Group). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Network/networkSecurityGroups/delete and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Network/networkSecurityGroups/delete -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription id> Create the Activity Log Alert Rule for Microsoft.Network/networkSecurityGroups/delete New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Create or Update Security Solution event.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Security/securitySolutions/write. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Create or Update Security Solutions' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription Id> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Security/securitySolutions/write in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Security/securitySolutions/write}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: b954148f-4c11-4c38-8221-be76711e194a - Name: 'An activity log alert should exist for specific Administrative operations'

Automated

Monitoring for Create or Update Security Solution events gives insight into changes to the active security solutions and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Create or Update Security Solutions (Security Solutions). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Security/securitySolutions/write and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Security/securitySolutions/write -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription ID> Create the Activity Log Alert Rule for Microsoft.Security/securitySolutions/write New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Delete Security Solution event.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Security/securitySolutions/delete. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Delete Security Solutions' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription Id> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Security/securitySolutions/delete in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Security/securitySolutions/delete}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: b954148f-4c11-4c38-8221-be76711e194a - Name: 'An activity log alert should exist for specific Administrative operations'

Automated

Monitoring for Delete Security Solution events gives insight into changes to the active security solutions and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Delete Security Solutions (Security Solutions). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Security/securitySolutions/delete and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Security/securitySolutions/delete -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription ID> Create the Activity Log Alert Rule for Microsoft.Security/securitySolutions/delete New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Create or Update SQL Server Firewall Rule event.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Sql/servers/firewallRules/write. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Create/Update server firewall rule' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription Id> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Sql/servers/firewallRules/write in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Sql/servers/firewallRules/write}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: b954148f-4c11-4c38-8221-be76711e194a - Name: 'An activity log alert should exist for specific Administrative operations'

There will be a substantial increase in log size if there are a large number of administrative actions on a server.

Automated

Monitoring for Create or Update SQL Server Firewall Rule events gives insight into network access changes and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Create/Update server firewall rule (Server Firewall Rule). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Sql/servers/firewallRules/write and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Sql/servers/firewallRules/write -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription ID> Create the Activity Log Alert Rule for Microsoft.Sql/servers/firewallRules/write New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Delete SQL Server Firewall Rule.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Sql/servers/firewallRules/delete. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Delete server firewall rule' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription Id> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Sql/servers/firewallRules/delete in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Sql/servers/firewallRules/delete}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: b954148f-4c11-4c38-8221-be76711e194a - Name: 'An activity log alert should exist for specific Administrative operations'

There will be a substantial increase in log size if there are a large number of administrative actions on a server.

Automated

Monitoring for Delete SQL Server Firewall Rule events gives insight into SQL network access changes and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Delete server firewall rule (Server Firewall Rule). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Sql/servers/firewallRules/delete and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Sql/servers/firewallRules/delete -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription ID> Create the Activity Log Alert Rule for Microsoft.Sql/servers/firewallRules/delete New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Create or Update Public IP Addresses rule.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Network/publicIPAddresses/write. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Create or Update Public Ip Address' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription Id> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Network/publicIPAddresses/write in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Network/publicIPAddresses/write}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 1513498c-3091-461a-b321-e9b433218d28 - Name: 'Enable logging by category group for Public IP addresses (microsoft.network/publicipaddresses) to Log Analytics'

There will be a substantial increase in log size if there are a large number of administrative actions on a server.

Automated

Monitoring for Create or Update Public IP Address events gives insight into network access changes and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Create or Update Public Ip Address (Public Ip Address). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Network/publicIPAddresses/write and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Network/publicIPAddresses/write -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription ID> Create the Activity Log Alert Rule for Microsoft.Network/publicIPAddresses/write New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for the Delete Public IP Address rule.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Navigate to the Monitor blade. 1. Click on Alerts. 1. In the Alerts window, click on Alert rules. 1. Ensure an alert rule exists where the Condition column contains Operation name=Microsoft.Network/publicIPAddresses/delete. 1. Click on the Alert Name associated with the previous step. 1. Ensure the Condition panel displays the text Whenever the Activity Log has an event with Category='Administrative', Operation name='Delete Public Ip Address' and does not filter on Level, Status or Caller. 1. Ensure the Actions panel displays an Action group is assigned to notify the appropriate personnel in your organization. Audit from Azure CLI az monitor activity-log alert list --subscription <subscription Id> --query [].{Name:name,Enabled:enabled,Condition:condition.allOf,Actions:actions} Look for Microsoft.Network/publicIPAddresses/delete in the output Audit from PowerShell Get-AzActivityLogAlert -SubscriptionId <subscription ID>|where-object {$_.ConditionAllOf.Equal -match Microsoft.Network/publicIPAddresses/delete}|select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 1513498c-3091-461a-b321-e9b433218d28 - Name: 'Enable logging by category group for Public IP addresses (microsoft.network/publicipaddresses) to Log Analytics'

There will be a substantial increase in log size if there are a large number of administrative actions on a server.

Automated

Monitoring for Delete Public IP Address events gives insight into network access changes and may reduce the time it takes to detect suspicious activity.

Remediate from Azure Portal 1. Navigate to the Monitor blade. 1. Select Alerts. 1. Select Create. 1. Select Alert rule. 1. Choose a subscription. 1. Select Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Delete Public Ip Address (Public Ip Address). 1. Click Apply. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. Remediate from Azure CLI az monitor activity-log alert create --resource-group <resource group name> --condition category=Administrative and operationName=Microsoft.Network/publicIPAddresses/delete and level=<verbose | information | warning | error | critical> --scope /subscriptions/<subscription ID> --name <activity log rule name> --subscription <subscription id> --action-group <action group ID> Remediate from PowerShell Create the Conditions object. $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Administrative -Field category $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Microsoft.Network/publicIPAddresses/delete -Field operationName $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Equal Verbose -Field level Retrieve the Action Group information and store in a variable, then create the Actions object. $actionGroup = Get-AzActionGroup -ResourceGroupName <resource group name> -Name <action group name> $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object $scope = /subscriptions/<subscription ID> Create the Activity Log Alert Rule for Microsoft.Network/publicIPAddresses/delete New-AzActivityLogAlert -Name <activity log alert rule name> -ResourceGroupName <resource group name> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription ID> -Enabled $true

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Create an activity log alert for Service Health.

By default, no monitoring alerts are created.

Audit from Azure Portal 1. Go to Monitor. 1. Click Alerts. 1. Click Alert rules. 1. Ensure an alert rule exists for a subscription with Condition set to Service names=All, Event types=All and Target resource type set to Subscription. 1. If an alert rule is found for step 4, click the name of the alert rule. 1. Ensure the Actions panel displays an action group configured to notify appropriate personnel. 1. Repeat steps 1-6 for each subscription. Audit from Azure CLI Run the following command to list activity log alerts: az monitor activity-log alert list --subscription <subscription-id> For each activity log alert, run the following command: az monitor activity-log alert show --subscription <subscription-id> --resource-group <resource-group> --activity-log-alert-name <activity-log-alert> Ensure an alert exists for ServiceHealth with scopes set to a subscription ID. Repeat for each subscription. Audit from PowerShell Run the following command to locate ServiceHealth alert rules for a subscription: Get-AzActivityLogAlert -SubscriptionId <subscription-id> | where-object {$_.ConditionAllOf.Equal -match ServiceHealth} | select-object Location,Name,Enabled,ResourceGroupName,ConditionAllOf Ensure that at least one ServiceHealth alert rule is returned. Repeat for each subscription.

There is no charge for creating activity log alert rules.

Automated

Monitoring for Service Health events provides insight into service issues, planned maintenance, security advisories, and other changes that may affect the Azure services and regions in use.

Remediate from Azure Portal 1. Go to Monitor. 1. Click Alerts. 1. Click + Create. 1. Select Alert rule from the drop-down menu. 1. Choose a subscription. 1. Click Apply. 1. Select the Condition tab. 1. Click See all signals. 1. Select Service health. 1. Click Apply. 1. Open the drop-down menu next to Event types. 1. Check the box next to Select all. 1. Select the Actions tab. 1. Click Select action groups to select an existing action group, or Create action group to create a new action group. 1. Follow the prompts to choose or create an action group. 1. Select the Details tab. 1. Select a Resource group, provide an Alert rule name and an optional Alert rule description. 1. Click Review + create. 1. Click Create. 1. Repeat steps 1-19 for each subscription requiring remediation. Remediate from Azure CLI For each subscription requiring remediation, run the following command to create a ServiceHealth alert rule for a subscription: az monitor activity-log alert create --subscription <subscription-id> --resource-group <resource-group> --name <alert-rule> --condition category=ServiceHealth and properties.incidentType=Incident --scope /subscriptions/<subscription-id> --action-group <action-group> Remediate from PowerShell Create the Conditions object: $conditions = @() $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Field category -Equal ServiceHealth $conditions += New-AzActivityLogAlertAlertRuleAnyOfOrLeafConditionObject -Field properties.incidentType -Equal Incident Retrieve the Action Group information and store in a variable: $actionGroup = Get-AzActionGroup -ResourceGroupName <resource-group> -Name <action-group> Create the Actions object: $actionObject = New-AzActivityLogAlertActionGroupObject -Id $actionGroup.Id Create the Scope object: $scope = /subscriptions/<subscription-id> Create the activity log alert rule: New-AzActivityLogAlert -Name <alert-rule> -ResourceGroupName <resource-group> -Condition $conditions -Scope $scope -Location global -Action $actionObject -Subscription <subscription-id> -Enabled $true Repeat for each subscription requiring remediation.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

Application Insights within Azure act as an Application Performance Monitoring solution providing valuable data into how well an application performs and additional information when performing incident response. The types of log data collected include application metrics, telemetry data, and application trace logging data providing organizations with detailed information about application activity and application transactions. Both data sets help organizations adopt a proactive and retroactive means to handle security and performance related metrics within their modern applications.

Application Insights are not enabled by default.

Audit from Azure Portal 1. Navigate to Application Insights. 2. Ensure an Application Insights service is configured and exists. Audit from Azure CLI az monitor app-insights component show --query [].{ID:appId, Name:name, Tenant:tenantId, Location:location, Provisioning_State:provisioningState} Ensure the above command produces output, otherwise Application Insights has not been configured. Audit from PowerShell Get-AzApplicationInsights|select location,name,appid,provisioningState,tenantid

Because Application Insights relies on a Log Analytics Workspace, an organization will incur additional expenses when using this service.

Automated

Configuring Application Insights provides additional data not found elsewhere within Azure as part of a much larger logging and monitoring program within an organization's Information Security practice. The types and contents of these logs will act as both a potential cost saving measure (application performance) and a means to potentially confirm the source of a potential incident (trace logging). Metrics and Telemetry data provide organizations with a proactive approach to cost savings by monitoring an application's performance, while the trace logging data provides necessary details in a reactive incident response scenario by helping organizations identify the potential source of an incident within their application.

Remediate from Azure Portal 1. Navigate to Application Insights. 2. Under the Basics tab within the PROJECT DETAILS section, select the Subscription. 3. Select the Resource group. 4. Within the INSTANCE DETAILS, enter a Name. 5. Select a Region. 6. Next to Resource Mode, select Workspace-based. 7. Within the WORKSPACE DETAILS, select the Subscription for the log analytics workspace. 8. Select the appropriate Log Analytics Workspace. 9. Click Next:Tags >. 10. Enter the appropriate Tags as Name, Value pairs. 11. Click Next:Review+Create. 12. Click Create. Remediate from Azure CLI az monitor app-insights component create --app <app name> --resource-group <resource group name> --location <location> --kind web --retention-time <INT days to retain logs> --workspace <log analytics workspace ID> --subscription <subscription ID> Remediate from PowerShell New-AzApplicationInsights -Kind web -ResourceGroupName <resource group name> -Name <app insights name> -location <location> -RetentionInDays <INT days to retain logs> -SubscriptionID <subscription ID> -WorkspaceResourceId <log analytics workspace ID>

Level 1

7 Management and Governance Services

7.1 Logging and Monitoring

Resource Logs capture activity to the data access plane while the Activity log is a subscription-level log for the control plane. Resource-level diagnostic logs provide insight into operations that were performed within that resource itself; for example, reading or updating a secret from a Key Vault. Currently, 95 Azure resources support Azure Monitoring (See the more information section for a complete list), including Network Security Groups, Load Balancers, Key Vault, AD, Logic Apps, and CosmosDB. The content of these logs varies by resource type. A number of back-end services were not configured to log and store Resource Logs for certain activities or for a sufficient length. It is crucial that monitoring is correctly configured to log all relevant activities and retain those logs for a sufficient length of time. Given that the mean time to detection in an enterprise is 240 days, a minimum retention period of two years is recommended.

By default, Azure Monitor Resource Logs are 'Disabled' for all resources.

Audit from Azure Portal The specific steps for configuring resources within the Azure console vary depending on resource, but typically the steps are: 1. Go to the resource 2. Click on Diagnostic settings 3. In the blade that appears, click Add diagnostic setting 4. Configure the diagnostic settings 5. Click on Save Audit from Azure CLI List all resources for a subscription az resource list --subscription <subscription id> For each resource run the following az monitor diagnostic-settings list --resource <resource ID> An empty result means a diagnostic settings is not configured for that resource. An error message means a diagnostic settings is not supported for that resource. Audit from PowerShell Get a list of resources in a subscription context and store in a variable $resources = Get-AzResource Loop through each resource to determine if a diagnostic setting is configured or not. foreach ($resource in $resources) {$diagnosticSetting = Get-AzDiagnosticSetting -ResourceId $resource.id -ErrorAction SilentlyContinue; if ([string]::IsNullOrEmpty($diagnosticSetting)) {$message = Diagnostic Settings not configured for resource: + $resource.Name;Write-Output $message}else{$diagnosticSetting}} A result of Diagnostic Settings not configured for resource: <resource name> means a diagnostic settings is not configured for that resource. Otherwise, the output of the above command will show configured Diagnostic Settings for a resource. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: cf820ca0-f99e-4f3e-84fb-66e913812d21 - Name: 'Resource logs in Key Vault should be enabled' - Policy ID: 91a78b24-f231-4a8a-8da9-02c35b2b6510 - Name: 'App Service apps should have resource logs enabled' - Policy ID: 428256e6-1fac-4f48-a757-df34c2b3336d - Name: 'Resource logs in Batch accounts should be enabled' - Policy ID: 057ef27e-665e-4328-8ea3-04b3122bd9fb - Name: 'Resource logs in Azure Data Lake Store should be enabled' - Policy ID: c95c74d9-38fe-4f0d-af86-0c7d626a315c - Name: 'Resource logs in Data Lake Analytics should be enabled' - Policy ID: 83a214f7-d01a-484b-91a9-ed54470c9a6a - Name: 'Resource logs in Event Hub should be enabled' - Policy ID: 383856f8-de7f-44a2-81fc-e5135b5c2aa4 - Name: 'Resource logs in IoT Hub should be enabled' - Policy ID: 34f95f76-5386-4de7-b824-0d8478470c9d - Name: 'Resource logs in Logic Apps should be enabled' - Policy ID: b4330a05-a843-4bc8-bf9a-cacce50c67f4 - Name: 'Resource logs in Search services should be enabled' - Policy ID: f8d36e2f-389b-4ee4-898d-21aeb69a0f45 - Name: 'Resource logs in Service Bus should be enabled' - Policy ID: f9be5368-9bf5-4b84-9e0a-7850da98bb46 - Name: 'Resource logs in Azure Stream Analytics should be enabled'

Costs for monitoring varies with Log Volume. Not every resource needs to have logging enabled. It is important to determine the security classification of the data being processed by the given resource and adjust the logging based on which events need to be tracked. This is typically determined by governance and compliance requirements.

Manual

A lack of monitoring reduces the visibility into the data plane, and therefore an organization's ability to detect reconnaissance, authorization attempts or other malicious activity. Unlike Activity Logs, Resource Logs are not enabled by default. Specifically, without monitoring it would be impossible to tell which entities had accessed a data store that was breached. In addition, alerts for failed attempts to access APIs for Web Services or Databases are only possible when logging is enabled.

Azure Subscriptions should log every access and operation for all resources. Logs should be sent to Storage and a Log Analytics Workspace or equivalent third-party system. Logs should be kept in readily-accessible storage for a minimum of one year, and then moved to inexpensive cold storage for a duration of time as necessary. If retention policies are set but storing logs in a Storage Account is disabled (for example, if only Event Hubs or Log Analytics options are selected), the retention policies have no effect. Enable all monitoring at first, and then be more aggressive moving data to cold storage if the volume of data becomes a cost concern. Remediate from Azure Portal The specific steps for configuring resources within the Azure console vary depending on resource, but typically the steps are: 1. Go to the resource 2. Click on Diagnostic settings 3. In the blade that appears, click Add diagnostic setting 4. Configure the diagnostic settings 5. Click on Save Remediate from Azure CLI For each resource, run the following making sure to use a resource appropriate JSON encoded category for the --logs option. az monitor diagnostic-settings create --name <diagnostic settings name> --resource <resource ID> --logs [{category:<resource specific category>,enabled:true,rentention-policy:{enabled:true,days:180}}] --metrics [{category:AllMetrics,enabled:true,retention-policy:{enabled:true,days:180}}] <[--event-hub <event hub ID> --event-hub-rule <event hub auth rule ID> | --storage-account <storage account ID> |--workspace <log analytics workspace ID> | --marketplace-partner-id <full resource ID of third-party solution>]> Remediate from PowerShell Create the log settings object $logSettings = @() $logSettings += New-AzDiagnosticSettingLogSettingsObject -Enabled $true -RetentionPolicyDay 180 -RetentionPolicyEnabled $true -Category <resource specific category> $logSettings += New-AzDiagnosticSettingLogSettingsObject -Enabled $true -RetentionPolicyDay 180 -RetentionPolicyEnabled $true -Category <resource specific category number 2> Create the metric settings object $metricSettings = @() $metricSettings += New-AzDiagnosticSettingMetricSettingsObject -Enabled $true -RetentionPolicyDay 180 -RetentionPolicyEnabled $true -Category AllMetrics Create the diagnostic setting for a specific resource New-AzDiagnosticSetting -Name <diagnostic settings name> -ResourceId <resource ID> -Log $logSettings -Metric $metricSettings

For an up-to-date list of Azure resources which support Azure Monitor, refer to the Supported Log Categories reference.

Level 2

7 Management and Governance Services

7.1 Logging and Monitoring

The use of Basic or Free SKUs in Azure whilst cost effective have significant limitations in terms of what can be monitored and what support can be realized from Microsoft. Typically, these SKU’s do not have a service SLA and Microsoft may refuse to provide support for them. Consequently Basic/Free SKUs should never be used for production workloads.

Policy should enforce standard SKUs for the following artifacts: - Public IP Addresses - Network Load Balancers - REDIS Cache - SQL PaaS Databases - VPN Gateways

This needs to be audited by Azure Policy (one for each resource type) and denied for each artifact that is production. Audit from Azure Portal 1. Open Azure Resource Graph Explorer 1. Click New query 1. Paste the following into the query window: Resources | where sku contains 'Basic' or sku contains 'consumption' | order by type 4. Click Run query then evaluate the results in the results window. 5. Ensure that no production artifacts are returned. Audit from Azure CLI az graph query -q Resources | where sku contains 'Basic' or sku contains 'consumption' | order by type Alternatively, to filter on a specific resource group: az graph query -q Resources | where resourceGroup == '<resourceGroupName>' | where sku contains 'Basic' or sku contains 'consumption' | order by type Ensure that no production artifacts are returned. Audit from PowerShell Get-AzResource | ?{ $_.Sku -EQ Basic} Ensure that no production artifacts are returned.

The impact of enforcing Standard SKU's is twofold 1) There will be a cost increase 2) The monitoring and service level agreements will be available and will support the production service. All resources should be either tagged or in separate Management Groups/Subscriptions

Manual

Typically, production workloads need to be monitored and should have an SLA with Microsoft, using Basic SKUs for any deployed product will mean that that these capabilities do not exist. The following resource types should use standard SKUs as a minimum. - Public IP Addresses - Network Load Balancers - REDIS Cache - SQL PaaS Databases - VPN Gateways

Each resource has its own process for upgrading from basic to standard SKUs that should be followed if required. - Public IP Address: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-upgrade. - Basic Load Balancer: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-basic-upgrade-guidance. - Azure Cache for Redis: https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-how-to-scale. - Azure SQL Database: https://learn.microsoft.com/en-us/azure/azure-sql/database/scale-resources. - VPN Gateway: https://learn.microsoft.com/en-us/azure/vpn-gateway/gateway-sku-resize.

Level 2

7 Management and Governance Services

Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion of, or modifications to, a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and, when applied, will place restrictions on the resource for all users. These locks are very useful when there is an important resource in a subscription that users should not be able to delete or change. Locks can help prevent accidental and malicious changes or deletion.

By default, no locks are set.

Audit from Azure Portal 1. Navigate to the specific Azure Resource or Resource Group. 2. Click on Locks. 3. Ensure the lock is defined with name and description, with type Read-only or Delete as appropriate. Audit from Azure CLI Review the list of all locks set currently: az lock list --resource-group <resourcegroupname> --resource-name <resourcename> --namespace <Namespace> --resource-type <type> --parent Audit from PowerShell Run the following command to list all resources. Get-AzResource For each resource, run the following command to check for Resource Locks. Get-AzResourceLock -ResourceName <Resource Name> -ResourceType <Resource Type> -ResourceGroupName <Resource Group Name> Review the output of the Properties setting. Compliant settings will have the CanNotDelete or ReadOnly value.

There can be unintended outcomes of locking a resource. Applying a lock to a parent service will cause it to be inherited by all resources within. Conversely, applying a lock to a resource may not apply to connected storage, leaving it unlocked. Please see the documentation for further information.

Manual

As an administrator, it may be necessary to lock a subscription, resource group, or resource to prevent other users in the organization from accidentally deleting or modifying critical resources. The lock level can be set to to CanNotDelete or ReadOnly to achieve this purpose. - CanNotDelete means authorized users can still read and modify a resource, but they cannot delete the resource. - ReadOnly means authorized users can read a resource, but they cannot delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role.

Remediate from Azure Portal 1. Navigate to the specific Azure Resource or Resource Group. 2. For each mission critical resource, click on Locks. 3. Click Add. 4. Give the lock a name and a description, then select the type, Read-only or Delete as appropriate. 5. Click OK. Remediate from Azure CLI To lock a resource, provide the name of the resource, its resource type, and its resource group name. az lock create --name <LockName> --lock-type <CanNotDelete/Read-only> --resource-group <resourceGroupName> --resource-name <resourceName> --resource-type <resourceType> Remediate from PowerShell Get-AzResourceLock -ResourceName <Resource Name> -ResourceType <Resource Type> -ResourceGroupName <Resource Group Name> -Locktype <CanNotDelete/Read-only>

Level 1

8 Networking Services

Network security groups should be periodically evaluated for port misconfigurations. Where RDP is not explicitly required and narrowly configured for resources attached to a network security group, Internet-level access to Azure resources should be restricted or eliminated.

By default, RDP access from internet is not enabled.

Audit from Azure Portal 1. Go to Network security groups. 1. Under Settings, click Inbound security rules. 1. Ensure that no inbound security rule exists that matches the following: - Port: 3389 or range including 3389 - Protocol: TCP or Any - Source: 0.0.0.0/0, Internet, or Any - Action: Allow 1. Repeat steps 1-3 for each network security group. To audit from Azure Resource Graph: 1. Go to Resource Graph Explorer. 1. Click New query. 1. Paste the following into the query window: resources | where type =~ microsoft.network/networksecuritygroups | project id, name, securityRule = properties.securityRules | mv-expand securityRule | extend access = securityRule.properties.access, direction = securityRule.properties.direction, protocol = securityRule.properties.protocol, destinationPort = case(isempty(securityRule.properties.destinationPortRange), securityRule.properties.destinationPortRanges, securityRule.properties.destinationPortRange), sourceAddress = case(isempty(securityRule.properties.sourceAddressPrefix), securityRule.properties.sourceAddressPrefixes, securityRule.properties.sourceAddressPrefix) | where access =~ Allow and direction =~ Inbound and protocol in~ (tcp, ) | mv-expand destinationPort | mv-expand sourceAddress | extend destinationPortMin = toint(split(destinationPort, -)[0]), destinationPortMax = toint(split(destinationPort, -)[-1]) | where (destinationPortMin <= 3389 and destinationPortMax >= 3389) or destinationPort == | where sourceAddress in~ (*, 0.0.0.0, internet, any) or sourceAddress endswith /0 1. Click Run query. 1. Ensure that no results are returned. Audit from Azure CLI List network security groups with non-default security rules: az network nsg list --query [*].[name,securityRules] Ensure that no network security group has an inbound security rule that matches the following: access : Allow destinationPortRange : 3389, *, or <range-including-3389> direction : Inbound protocol : TCP or * sourceAddressPrefix : 0.0.0.0/0, Internet, or * Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 22730e10-96f6-4aac-ad84-9383d35b5917 - Name: 'Management ports should be closed on your virtual machines'

Automated

The potential security problem with using RDP over the Internet is that attackers can use various brute force techniques to gain access to Azure Virtual Machines. Once the attackers gain access, they can use a virtual machine as a launch point for compromising other machines on an Azure Virtual Network or even attack networked devices outside of Azure.

Remediate from Azure Portal 1. Go to Network security groups. 1. Under Settings, click Inbound security rules. 1. Check the box next to any inbound security rule matching: - Port: 3389 or range including 3389 - Protocol: TCP or Any - Source: 0.0.0.0/0, Internet, or Any - Action: Allow 1. Click Delete. 1. Click Yes. Remediate from Azure CLI For each network security group rule requiring remediation, run the following command to delete a rule: az network nsg rule delete --resource-group <resource-group> --nsg-name <network-security-group> --name <rule>

Level 1

8 Networking Services

Network security groups should be periodically evaluated for port misconfigurations. Where certain ports and protocols may be exposed to the Internet, they should be evaluated for necessity and restricted wherever they are not explicitly required.

By default, SSH access from internet is not enabled.

Audit from Azure Portal 1. Open the Networking blade for the specific Virtual machine in Azure portal 2. Verify that the INBOUND PORT RULES does not have a rule for SSH such as - port = 22, - protocol = TCP OR ANY, - Source = Any OR Internet Audit from Azure CLI List Network security groups with corresponding non-default Security rules: az network nsg list --query [*].[name,securityRules] Ensure that none of the NSGs have security rule as below access : Allow destinationPortRange : 22 or * or [port range containing 22] direction : Inbound protocol : TCP or * sourceAddressPrefix : * or 0.0.0.0 or <nw>/0 or /0 or internet or any Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 22730e10-96f6-4aac-ad84-9383d35b5917 - Name: 'Management ports should be closed on your virtual machines'

Automated

The potential security problem with using SSH over the Internet is that attackers can use various brute force techniques to gain access to Azure Virtual Machines. Once the attackers gain access, they can use a virtual machine as a launch point for compromising other machines on the Azure Virtual Network or even attack networked devices outside of Azure.

Where SSH is not explicitly required and narrowly configured for resources attached to the Network Security Group, Internet-level access to your Azure resources should be restricted or eliminated. For internal access to relevant resources, configure an encrypted network tunnel such as: ExpressRoute Site-to-site VPN Point-to-site VPN

Level 1

8 Networking Services

Network security groups should be periodically evaluated for port misconfigurations. Where certain ports and protocols may be exposed to the Internet, they should be evaluated for necessity and restricted wherever they are not explicitly required.

By default, UDP access from internet is not enabled.

Audit from Azure Portal 1. Open the Networking blade for the specific Virtual machine in Azure portal 2. Verify that the INBOUND PORT RULES does not have a rule for UDP such as - protocol = UDP, - Source = Any OR Internet Audit from Azure CLI List Network security groups with corresponding non-default Security rules: az network nsg list --query [*].[name,securityRules] Ensure that none of the NSGs have security rule as below access : Allow destinationPortRange : * or [port range containing 53, 123, 161, 389, 1900, or other vulnerable UDP-based services] direction : Inbound protocol : UDP sourceAddressPrefix : * or 0.0.0.0 or <nw>/0 or /0 or internet or any

Automated

The potential security problem with broadly exposing UDP services over the Internet is that attackers can use DDoS amplification techniques to reflect spoofed UDP traffic from Azure Virtual Machines. The most common types of these attacks use exposed DNS, NTP, SSDP, SNMP, CLDAP and other UDP-based services as amplification sources for disrupting services of other machines on the Azure Virtual Network or even attack networked devices outside of Azure.

Where UDP is not explicitly required and narrowly configured for resources attached to the Network Security Group, Internet-level access to your Azure resources should be restricted or eliminated. For internal access to relevant resources, configure an encrypted network tunnel such as: ExpressRoute Site-to-site VPN Point-to-site VPN

Level 1

8 Networking Services

Express Route: https://docs.microsoft.com/en-us/azure/expressroute/:Site-to-Site VPN: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal:Point-to-Site VPN: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal:https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-network-security#ns-1-establish-network-segmentation-boundaries

Network security groups should be periodically evaluated for port misconfigurations. Where certain ports and protocols may be exposed to the Internet, they should be evaluated for necessity and restricted wherever they are not explicitly required and narrowly configured.

Audit from Azure Portal 1. For each VM, open the Networking blade 2. Verify that the INBOUND PORT RULES does not have a rule for HTTP(S) such as - port = 80/ 443, - protocol = TCP, - Source = Any OR Internet Audit from Azure CLI List Network security groups with corresponding non-default Security rules: az network nsg list --query [*].[name,securityRules] Ensure that none of the NSGs have security rule as below access : Allow destinationPortRange : 80/443 or * or [port range containing 80/443] direction : Inbound protocol : TCP sourceAddressPrefix : * or 0.0.0.0 or <nw>/0 or /0 or internet or any

Automated

The potential security problem with using HTTP(S) over the Internet is that attackers can use various brute force techniques to gain access to Azure resources. Once the attackers gain access, they can use the resource as a launch point for compromising other resources within the Azure tenant.

Remediate from Azure Portal 1. Go to Virtual machines. 2. For each VM, open the Networking blade. 3. Click on Inbound port rules. 4. Delete the rule with: * Port = 80/443 OR [port range containing 80/443] * Protocol = TCP OR Any * Source = Any (*) OR IP Addresses(0.0.0.0/0) OR Service Tag(Internet) * Action = Allow Remediate from Azure CLI 1. Run below command to list network security groups: az network nsg list --subscription <subscription-id> --output table 2. For each network security group, run below command to list the rules associated with the specified port: az network nsg rule list --resource-group <resource-group> --nsg-name <nsg-name> --query [?destinationPortRange=='80 or 443'] 3. Run the below command to delete the rule with: * Port = 80/443 OR [port range containing 80/443] * Protocol = TCP OR * * Source = Any (*) OR IP Addresses(0.0.0.0/0) OR Service Tag(Internet) * Action = Allow az network nsg rule delete --resource-group <resource-group> --nsg-name <nsg-name> --name <rule-name>

Level 2

8 Networking Services

Network Security Group Flow Logs should be enabled and the retention period set to greater than or equal to 90 days. Retirement Notice On September 30, 2027, network security group (NSG) flow logs will be retired. Starting June 30, 2025, it will no longer be possible to create new NSG flow logs. Azure recommends migrating to virtual network flow logs. Review https://azure.microsoft.com/en-gb/updates?id=Azure-NSG-flow-logs-Retirement for more information. For virtual network flow logs, consider applying the recommendation Ensure that virtual network flow log retention days is set to greater than or equal to 90 in this section.

By default, Network Security Group Flow Logs are disabled.

Audit from Azure Portal 1. Go to Network Watcher. 1. Select Flow logs. 1. Review existing Network security group flow logs, if any remain, and ensure Status is set to On and Retention (days) is set to 0, 90, or a number greater than 90. 1. Review Virtual network flow logs for new or migrated coverage. Audit from Azure CLI az network watcher flow-log list --location <location> --query [*].[name,retentionPolicy,targetResourceId] Ensure each relevant flow log has retention days set to 0, 90, or a number greater than 90. Audit from Azure Policy If referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure. If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions - Policy ID: 5e1cd26a-5090-4fdb-9d6a-84a90335e22d - Name: 'Configure network security groups to use specific workspace, storage account and flowlog retention policy for traffic analytics'

This will keep IP traffic logs for longer than 90 days. As a level 2, first determine your need to retain data, then apply your selection here. As this is data stored for longer, your monthly storage costs will increase depending on your data use.

Automated

Flow logs enable capturing information about IP traffic flowing in and out of network security groups. Logs can be used to check for anomalies and give insight into suspected breaches.

Remediate from Azure Portal Existing NSG flow logs can still be reviewed under Network Watcher > Flow logs. If you already have NSG flow logs configured, ensure Status is set to On and Retention (days) is set to 0, 90, or a number greater than 90 until migration is complete. Azure no longer allows creation of new NSG flow logs after June 30, 2025. For new or migrated deployments, configure Virtual network flow logs instead and set Retention days to 0, 90, or a number greater than 90. Remediate from Azure CLI Update an existing flow log retention policy with: az network watcher flow-log update --location <location> --name <flow-log> --retention <number-of-days>

On September 30, 2027, NSG flow logs will be retired, and creating new NSG flow logs has not been possible since June 30, 2025. Azure recommends migrating to virtual network flow logs, which address NSG flow log limitations. After retirement, traffic analytics using NSG flow logs will no longer be supported, and existing NSG flow log resources will be deleted. Previously collected NSG flow log records will remain available per their retention policies. For details, see the official announcement: https://azure.microsoft.com/en-gb/updates?id=Azure-NSG-flow-logs-Retirement.