Security recommendations

This article lists all the security recommendations you might see in Microsoft Defender for Cloud. The recommendations that appear in your environment are based on the resources that you're protecting and on your customized configuration.

Recommendations in Defender for Cloud are based on the Azure cloud security benchmark. The Azure cloud security benchmark is the Microsoft-authored set of guidelines for security and compliance best practices. This widely respected benchmark builds on controls from the Center for Internet Security (CIS) and the National Institute of Standards and Technology (NIST), with a focus on cloud-centric security.

To learn about actions that you can take in response to these recommendations, see Remediate recommendations in Defender for Cloud.

Your secure score is based on the number of security recommendations you completed. To decide which recommendations to resolve first, look at the severity of each recommendation and its potential impact on your secure score.

AppServices recommendations

API App should only be accessible over HTTPS

Description: Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. (Related policy: API App should only be accessible over HTTPS).

Severity: Medium

CORS should not allow every resource to access API Apps

Description: Cross-Origin Resource Sharing (CORS) should not allow all domains to access your API app. Allow only required domains to interact with your API app. (Related policy: CORS should not allow every resource to access your API App).

Severity: Low

CORS should not allow every resource to access Function Apps

Description: Cross-Origin Resource Sharing (CORS) should not allow all domains to access your Function app. Allow only required domains to interact with your Function app. (Related policy: CORS should not allow every resource to access your Function Apps).

Severity: Low

CORS should not allow every resource to access Web Applications

Description: Cross-Origin Resource Sharing (CORS) should not allow all domains to access your web application. Allow only required domains to interact with your web app. (Related policy: CORS should not allow every resource to access your Web Applications).

Severity: Low

Diagnostic logs in App Service should be enabled

Description: Audit enabling of diagnostic logs on the app. This enables you to recreate activity trails for investigation purposes if a security incident occurs or your network is compromised (No related policy).

Severity: Medium

Ensure API app has Client Certificates Incoming client certificates set to On

Description: Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. (Related policy: Ensure API app has 'Client Certificates (Incoming client certificates)' set to 'On').

Severity: Medium

FTPS should be required in API apps

Description: Enable FTPS enforcement for enhanced security (Related policy: FTPS only should be required in your API App).

Severity: High

FTPS should be required in function apps

Description: Enable FTPS enforcement for enhanced security (Related policy: FTPS only should be required in your Function App).

Severity: High

FTPS should be required in web apps

Description: Enable FTPS enforcement for enhanced security (Related policy: FTPS should be required in your Web App).

Severity: High

Function App should only be accessible over HTTPS

Description: Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. (Related policy: Function App should only be accessible over HTTPS).

Severity: Medium

Function apps should have Client Certificates (Incoming client certificates) enabled

Description: Client certificates allow for the app to request a certificate for incoming requests. Only clients with valid certificates will be able to reach the app. (Related policy: Function apps should have 'Client Certificates (Incoming client certificates)' enabled).

Severity: Medium

Java should be updated to the latest version for API apps

Description: Periodically, newer versions are released for Java either due to security flaws or to include additional functionality. Using the latest Python version for API apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'Java version' is the latest, if used as a part of the API app).

Severity: Medium

Managed identity should be used in API apps

Description: For enhanced authentication security, use a managed identity. On Azure, managed identities eliminate the need for developers to have to manage credentials by providing an identity for the Azure resource in Azure AD and using it to obtain Azure Active Directory (Azure AD) tokens. (Related policy: Managed identity should be used in your API App).

Severity: Medium

Managed identity should be used in function apps

Description: For enhanced authentication security, use a managed identity. On Azure, managed identities eliminate the need for developers to have to manage credentials by providing an identity for the Azure resource in Azure AD and using it to obtain Azure Active Directory (Azure AD) tokens. (Related policy: Managed identity should be used in your Function App).

Severity: Medium

Managed identity should be used in web apps

Description: For enhanced authentication security, use a managed identity. On Azure, managed identities eliminate the need for developers to have to manage credentials by providing an identity for the Azure resource in Azure AD and using it to obtain Azure Active Directory (Azure AD) tokens. (Related policy: Managed identity should be used in your Web App).

Severity: Medium

PHP should be updated to the latest version for API apps

Description: Periodically, newer versions are released for PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for API apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'PHP version' is the latest, if used as a part of the API app).

Severity: Medium

Python should be updated to the latest version for API apps

Description: Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest Python version for API apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'Python version' is the latest, if used as a part of the API app).

Severity: Medium

Remote debugging should be turned off for API App

Description: Remote debugging requires inbound ports to be opened on an API app. Remote debugging should be turned off. (Related policy: Remote debugging should be turned off for API Apps).

Severity: Low

Remote debugging should be turned off for Function App

Description: Remote debugging requires inbound ports to be opened on an Azure Function app. Remote debugging should be turned off. (Related policy: Remote debugging should be turned off for Function Apps).

Severity: Low

Remote debugging should be turned off for Web Applications

Description: Remote debugging requires inbound ports to be opened on a web application. Remote debugging is currently enabled. If you no longer need to use remote debugging, it should be turned off. (Related policy: Remote debugging should be turned off for Web Applications).

Severity: Low

TLS should be updated to the latest version for API apps

Description: Upgrade to the latest TLS version. (Related policy: Latest TLS version should be used in your API App).

Severity: High

TLS should be updated to the latest version for function apps

Description: Upgrade to the latest TLS version. (Related policy: Latest TLS version should be used in your Function App).

Severity: High

TLS should be updated to the latest version for web apps

Description: Upgrade to the latest TLS version. (Related policy: Latest TLS version should be used in your Web App).

Severity: High

Web Application should only be accessible over HTTPS

Description: Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. (Related policy: Web Application should only be accessible over HTTPS).

Severity: Medium

Web apps should request an SSL certificate for all incoming requests

Description: Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. (Related policy: Ensure WEB app has 'Client Certificates (Incoming client certificates)' set to 'On').

Severity: Medium

Compute recommendations

Adaptive application controls for defining safe applications should be enabled on your machines

Description: Enable application controls to define the list of known-safe applications running on your machines, and alert you when other applications run. This helps harden your machines against malware. To simplify the process of configuring and maintaining your rules, Defender for Cloud uses machine learning to analyze the applications running on each machine and suggest the list of known-safe applications. (Related policy: Adaptive application controls for defining safe applications should be enabled on your machines).

Severity: High

Allowlist rules in your adaptive application control policy should be updated

Description: Monitor for changes in behavior on groups of machines configured for auditing by Defender for Cloud's adaptive application controls. Defender for Cloud uses machine learning to analyze the running processes on your machines and suggest a list of known-safe applications. These are presented as recommended apps to allow in adaptive application control policies. (Related policy: Allowlist rules in your adaptive application control policy should be updated).

Severity: High

Authentication to Linux machines should require SSH keys

Description: Although SSH itself provides an encrypted connection, using passwords with SSH still leaves the VM vulnerable to brute-force attacks. The most secure option for authenticating to an Azure Linux virtual machine over SSH is with a public-private key pair, also known as SSH keys. Learn more in Detailed steps: Create and manage SSH keys for authentication to a Linux VM in Azure. (Related policy: Audit Linux machines that are not using SSH key for authentication).

Severity: Medium

Automation account variables should be encrypted

Description: It is important to enable encryption of Automation account variable assets when storing sensitive data. (Related policy: Automation account variables should be encrypted).

Severity: High

Azure Backup should be enabled for virtual machines

Description: Protect the data on your Azure virtual machines with Azure Backup. Azure Backup is an Azure-native, cost-effective, data protection solution. It creates recovery points that are stored in geo-redundant recovery vaults. When you restore from a recovery point, you can restore the whole VM or specific files. (Related policy: Azure Backup should be enabled for Virtual Machines).

Severity: Low

Container hosts should be configured securely

Description: Remediate vulnerabilities in security configuration on machines with Docker installed to protect them from attacks. (Related policy: Vulnerabilities in container security configurations should be remediated).

Severity: High

Diagnostic logs in Azure Stream Analytics should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Azure Stream Analytics should be enabled).

Severity: Low

Diagnostic logs in Batch accounts should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Batch accounts should be enabled).

Severity: Low

Diagnostic logs in Event Hubs should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Event Hubs should be enabled).

Severity: Low

Diagnostic logs in Logic Apps should be enabled

Description: To ensure you can recreate activity trails for investigation purposes when a security incident occurs or your network is compromised, enable logging. If your diagnostic logs aren't being sent to a Log Analytics workspace, Azure Storage account, or Azure Event Hubs, ensure you've configured diagnostic settings to send platform metrics and platform logs to the relevant destinations. Learn more in Create diagnostic settings to send platform logs and metrics to different destinations. (Related policy: Diagnostic logs in Logic Apps should be enabled).

Severity: Low

Diagnostic logs in Service Bus should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Service Bus should be enabled).

Severity: Low

Diagnostic logs in Virtual Machine Scale Sets should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Virtual Machine Scale Sets should be enabled).

Severity: High

Endpoint protection health issues on virtual machine scale sets should be resolved

Description: Remediate endpoint protection health failures on your virtual machine scale sets to protect them from threats and vulnerabilities. (Related policy: Endpoint protection solution should be installed on virtual machine scale sets).

Severity: Low

Endpoint protection should be installed on virtual machine scale sets

Description: Install an endpoint protection solution on your virtual machines scale sets, to protect them from threats and vulnerabilities. (Related policy: Endpoint protection solution should be installed on virtual machine scale sets).

Severity: High

File integrity monitoring should be enabled on machines

Description: Defender for Cloud has identified machines that are missing a file integrity monitoring solution. To monitor changes to critical files, registry keys, and more on your servers, enable file integrity monitoring. When the file integrity monitoring solution is enabled, create data collection rules to define the files to be monitored. To define rules, or see the files changed on machines with existing rules, go to the file integrity monitoring management page. (No related policy)

Severity: High

Guest Attestation extension should be installed on supported Linux virtual machine scale sets

Description: Install Guest Attestation extension on supported Linux virtual machine scale sets to allow Microsoft Defender for Cloud to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment only applies to trusted launch enabled Linux virtual machine scale sets.

Important: Trusted launch requires the creation of new virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. Learn more about Trusted launch for Azure virtual machines. (No related policy)

Severity: Low

Guest Attestation extension should be installed on supported Linux virtual machines

Description: Install Guest Attestation extension on supported Linux virtual machines to allow Microsoft Defender for Cloud to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment only applies to trusted launch enabled Linux virtual machines.

Important: Trusted launch requires the creation of new virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. Learn more about Trusted launch for Azure virtual machines. (No related policy)

Severity: Low

Guest Attestation extension should be installed on supported Windows virtual machine scale sets

Description: Install Guest Attestation extension on supported virtual machine scale sets to allow Microsoft Defender for Cloud to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment only applies to trusted launch enabled virtual machine scale sets.

Important: Trusted launch requires the creation of new virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. Learn more about Trusted launch for Azure virtual machines. (No related policy)

Severity: Low

Guest Attestation extension should be installed on supported Windows virtual machines

Description: Install Guest Attestation extension on supported virtual machines to allow Microsoft Defender for Cloud to proactively attest and monitor the boot integrity. Once installed, boot integrity will be attested via Remote Attestation. This assessment only applies to trusted launch enabled virtual machines.

Important: Trusted launch requires the creation of new virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. Learn more about Trusted launch for Azure virtual machines. (No related policy)

Severity: Low

Guest Configuration extension should be installed on machines

Description: To ensure secure configurations of in-guest settings of your machine, install the Guest Configuration extension. In-guest settings that the extension monitors include the configuration of the operating system, application configuration or presence, and environment settings. Once installed, in-guest policies will be available such as Windows Exploit guard should be enabled. (Related policy: Virtual machines should have the Guest Configuration extension).

Severity: Medium

Install endpoint protection solution on virtual machines

Description: Install an endpoint protection solution on your virtual machines, to protect them from threats and vulnerabilities. (Related policy: Monitor missing Endpoint Protection in Azure Security Center).

Severity: High

Linux virtual machines should enforce kernel module signature validation

Description: To help mitigate against the execution of malicious or unauthorized code in kernel mode, enforce kernel module signature validation on supported Linux virtual machines. Kernel module signature validation ensures that only trusted kernel modules will be allowed to run. This assessment only applies to Linux virtual machines that have the Azure Monitor Agent installed. (No related policy)

Severity: Low

Linux virtual machines should use only signed and trusted boot components

Description: With Secure Boot enabled, all OS boot components (boot loader, kernel, kernel drivers) must be signed by trusted publishers. Defender for Cloud has identified untrusted OS boot components on one or more of your Linux machines. To protect your machines from potentially malicious components, add them to your allowlist or remove the identified components. (No related policy)

Severity: Low

Linux virtual machines should use Secure Boot

Description: To protect against the installation of malware-based rootkits and boot kits, enable Secure Boot on supported Linux virtual machines. Secure Boot ensures that only signed operating systems and drivers will be allowed to run. This assessment only applies to Linux virtual machines that have the Azure Monitor Agent installed. (No related policy)

Severity: Low

Log Analytics agent should be installed on Linux-based Azure Arc-enabled machines

Description: Defender for Cloud uses the Log Analytics agent (also known as OMS) to collect security events from your Azure Arc machines. To deploy the agent on all your Azure Arc machines, follow the remediation steps. (No related policy)

Severity: High

Log Analytics agent should be installed on virtual machine scale sets

Description: Defender for Cloud collects data from your Azure virtual machines (VMs) to monitor for security vulnerabilities and threats. Data is collected using the Log Analytics agent, formerly known as the Microsoft Monitoring Agent (MMA), which reads various security-related configurations and event logs from the machine and copies the data to your workspace for analysis. You'll also need to follow that procedure if your VMs are used by an Azure managed service such as Azure Kubernetes Service or Azure Service Fabric. You cannot configure auto-provisioning of the agent for Azure virtual machine scale sets. To deploy the agent on virtual machine scale sets (including those used by Azure managed services such as Azure Kubernetes Service and Azure Service Fabric), follow the procedure in the remediation steps. (Related policy: Log Analytics agent should be installed on your virtual machine scale sets for Azure Security Center monitoring).

Severity: High

Log Analytics agent should be installed on virtual machines

Description: Defender for Cloud collects data from your Azure virtual machines (VMs) to monitor for security vulnerabilities and threats. Data is collected using the Log Analytics agent, formerly known as the Microsoft Monitoring Agent (MMA), which reads various security-related configurations and event logs from the machine and copies the data to your Log Analytics workspace for analysis. This agent is also required if your VMs are used by an Azure managed service such as Azure Kubernetes Service or Azure Service Fabric. We recommend configuring auto-provisioning to automatically deploy the agent. If you choose not to use auto-provisioning, manually deploy the agent to your VMs using the instructions in the remediation steps. (Related policy: Log Analytics agent should be installed on your virtual machine for Azure Security Center monitoring).

Severity: High

Log Analytics agent should be installed on Windows-based Azure Arc-enabled machines

Description: Defender for Cloud uses the Log Analytics agent (also known as MMA) to collect security events from your Azure Arc machines. To deploy the agent on all your Azure Arc machines, follow the remediation steps. (No related policy)

Severity: High

Machines should be configured securely

Description: Remediate vulnerabilities in security configuration on your machines to protect them from attacks. (Related policy: Vulnerabilities in security configuration on your machines should be remediated).

Severity: Low

Machines should be restarted to apply security configuration updates

Description: To apply security configuration updates and protect against vulnerabilities, restart your machines. This assessment only applies to Linux virtual machines that have the Azure Monitor Agent installed. (No related policy)

Severity: Low

Machines should have a vulnerability assessment solution

Description: Defender for Cloud regularly checks your connected machines to ensure they're running vulnerability assessment tools. Use this recommendation to deploy a vulnerability assessment solution. (Related policy: A vulnerability assessment solution should be enabled on your virtual machines).

Severity: Medium

Machines should have vulnerability findings resolved

Description: Resolve the findings from the vulnerability assessment solutions on your virtual machines. (Related policy: A vulnerability assessment solution should be enabled on your virtual machines).

Severity: Low

Management ports of virtual machines should be protected with just-in-time network access control

Description: Defender for Cloud has identified some overly permissive inbound rules for management ports in your Network Security Group. Enable just-in-time access control to protect your VM from internet-based brute-force attacks. Learn more in Understanding just-in-time (JIT) VM access. (Related policy: Management ports of virtual machines should be protected with just-in-time network access control).

Severity: High

Microsoft Defender for servers should be enabled

Description: Microsoft Defender for servers provides real-time threat protection for your server workloads and generates hardening recommendations as well as alerts about suspicious activities. You can use this information to quickly remediate security issues and improve the security of your servers.

Important: Remediating this recommendation will result in charges for protecting your servers. If you don't have any servers in this subscription, no charges will be incurred. If you create any servers on this subscription in the future, they will automatically be protected and charges will begin at that time. Learn more in Introduction to Microsoft Defender for servers. (Related policy: Azure Defender for servers should be enabled).

Severity: High

Microsoft Defender for servers should be enabled on workspaces

Description: Microsoft Defender for servers brings threat detection and advanced defenses for your Windows and Linux machines. With this Defender plan enabled on your subscriptions but not on your workspaces, you're paying for the full capability of Microsoft Defender for servers but missing out on some of the benefits. When you enable Microsoft Defender for servers on a workspace, all machines reporting to that workspace will be billed for Microsoft Defender for servers - even if they're in subscriptions without Defender plans enabled. Unless you also enable Microsoft Defender for servers on the subscription, those machines won't be able to take advantage of just-in-time VM access, adaptive application controls, and network detections for Azure resources. Learn more in Introduction to Microsoft Defender for servers. (No related policy)

Severity: Medium

Secure Boot should be enabled on supported Windows virtual machines

Description: Enable Secure Boot on supported Windows virtual machines to mitigate against malicious and unauthorized changes to the boot chain. Once enabled, only trusted bootloaders, kernel, and kernel drivers will be allowed to run. This assessment only applies to trusted launch enabled Windows virtual machines.

Important: Trusted launch requires the creation of new virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. Learn more about Trusted launch for Azure virtual machines. (No related policy)

Severity: Low

Service Fabric clusters should have the ClusterProtectionLevel property set to EncryptAndSign

Description: Service Fabric provides three levels of protection (None, Sign, and EncryptAndSign) for node-to-node communication using a primary cluster certificate. Set the protection level to ensure that all node-to-node messages are encrypted and digitally signed. (Related policy: Service Fabric clusters should have the ClusterProtectionLevel property set to EncryptAndSign).

Severity: High

Service Fabric clusters should only use Azure Active Directory for client authentication

Description: Perform Client authentication only via Azure Active Directory in Service Fabric (Related policy: Service Fabric clusters should only use Azure Active Directory for client authentication).

Severity: High

System updates on virtual machine scale sets should be installed

Description: Install missing system security and critical updates to secure your Windows and Linux virtual machine scale sets. (Related policy: System updates on virtual machine scale sets should be installed).

Severity: High

System updates should be installed on your machines

Description: Install missing system security and critical updates to secure your Windows and Linux virtual machines and computers (Related policy: System updates should be installed on your machines).

Severity: High

System updates should be installed on your machines (powered by Update Center)

Description: Your machines are missing system, security, and critical updates. Software updates often include critical patches to security holes. Such holes are frequently exploited in malware attacks so it's vital to keep your software updated. To install all outstanding patches and secure your machines, follow the remediation steps. (No related policy)

Severity: High

Virtual machine scale sets should be configured securely

Description: Remediate vulnerabilities in security configuration on your virtual machine scale sets to protect them from attacks. (Related policy: Vulnerabilities in security configuration on your virtual machine scale sets should be remediated).

Severity: High

Virtual machines guest attestation status should be healthy

Description: Guest attestation is performed by sending a trusted log (TCGLog) to an attestation server. The server uses these logs to determine whether boot components are trustworthy. This assessment is intended to detect compromises of the boot chain, which might be the result of a bootkit or rootkit infection. This assessment only applies to Trusted Launch enabled virtual machines that have the Guest Attestation extension installed. (No related policy)

Severity: Medium

Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity

Description: The Guest Configuration extension requires a system assigned managed identity. Azure virtual machines in the scope of this policy will be non-compliant when they have the Guest Configuration extension installed but do not have a system assigned managed identity. Learn more (Related policy: Guest Configuration extension should be deployed to Azure virtual machines with system assigned managed identity).

Severity: Medium

Virtual machines should be migrated to new Azure Resource Manager resources

Description: Virtual Machines (classic) was deprecated and these VMs should be migrated to Azure Resource Manager. Because Azure Resource Manager now has full IaaS capabilities and other advancements, we deprecated the management of IaaS virtual machines (VMs) through Azure Service Manager (ASM) on February 28, 2020. This functionality will be fully retired on March 1, 2023.

To view all affected classic VMs make sure to select all your Azure subscriptions under 'directories + subscriptions' tab.

Available resources and information about this tool & migration: Overview of Virtual machines (classic) deprecation, step by step process for migration & available Microsoft resources. Details about Migrate to Azure Resource Manager migration tool. Migrate to Azure Resource Manager migration tool using PowerShell. (Related policy: Virtual machines should be migrated to new Azure Resource Manager resources).

Severity: High

Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources

Description: By default, a virtual machine's OS and data disks are encrypted-at-rest using platform-managed keys; temp disks and data caches aren't encrypted, and data isn't encrypted when flowing between compute and storage resources. For a comparison of different disk encryption technologies in Azure, see https://aka.ms/diskencryptioncomparison. Use Azure Disk Encryption to encrypt all this data. Disregard this recommendation if:

1. You're using the encryption-at-host feature, or 2. Server-side encryption on Managed Disks meets your security requirements. Learn more in Server-side encryption of Azure Disk Storage. (Related policy: Disk encryption should be applied on virtual machines)

Severity: High

vTPM should be enabled on supported virtual machines

Description: Enable virtual TPM device on supported virtual machines to facilitate Measured Boot and other OS security features that require a TPM. Once enabled, vTPM can be used to attest boot integrity. This assessment only applies to trusted launch enabled virtual machines.

Important: Trusted launch requires the creation of new virtual machines. You can't enable trusted launch on existing virtual machines that were initially created without it. Learn more about Trusted launch for Azure virtual machines. (No related policy)

Severity: Low

Vulnerabilities in security configuration on your Linux machines should be remediated (powered by Guest Configuration)

Description: Remediate vulnerabilities in security configuration on your Linux machines to protect them from attacks. (Related policy: Linux machines should meet requirements for the Azure security baseline).

Severity: Low

Vulnerabilities in security configuration on your Windows machines should be remediated (powered by Guest Configuration)

Description: Remediate vulnerabilities in security configuration on your Windows machines to protect them from attacks. (No related policy)

Severity: Low

Windows Defender Exploit Guard should be enabled on machines

Description: Windows Defender Exploit Guard uses the Azure Policy Guest Configuration agent. Exploit Guard has four components that are designed to lock down devices against a wide variety of attack vectors and block behaviors commonly used in malware attacks while enabling enterprises to balance their security risk and productivity requirements (Windows only). (Related policy: Audit Windows machines on which Windows Defender Exploit Guard is not enabled).

Severity: Medium

Windows web servers should be configured to use secure communication protocols

Description: To protect the privacy of information communicated over the Internet, your web servers should use the latest version of the industry-standard cryptographic protocol, Transport Layer Security (TLS). TLS secures communications over a network by using security certificates to encrypt a connection between machines. (Related policy: Audit Windows web servers that are not using secure communication protocols).

Severity: High

Linux virtual machines should enable Azure Disk Encryption or EncryptionAtHost

Description: By default, a virtual machine's OS and data disks are encrypted-at-rest using platform-managed keys; temp disks and data caches aren't encrypted, and data isn't encrypted when flowing between compute and storage resources. Use Azure Disk Encryption or EncryptionAtHost to encrypt all this data. Visit https://aka.ms/diskencryptioncomparison to compare encryption offerings. This policy requires two prerequisites to be deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. (Related policy: Linux virtual machines should enable Azure Disk Encryption or EncryptionAtHost).

Severity: High

Windows virtual machines should enable Azure Disk Encryption or EncryptionAtHost

Description: By default, a virtual machine's OS and data disks are encrypted-at-rest using platform-managed keys; temp disks and data caches aren't encrypted, and data isn't encrypted when flowing between compute and storage resources. Use Azure Disk Encryption or EncryptionAtHost to encrypt all this data. Visit https://aka.ms/diskencryptioncomparison to compare encryption offerings. This policy requires two prerequisites to be deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. (Related policy: Windows virtual machines should enable Azure Disk Encryption or EncryptionAtHost).

Severity: High

Virtual machines and virtual machine scale sets should have encryption at host enabled

Description: Use encryption at host to get end-to-end encryption for your virtual machine and virtual machine scale set data. Encryption at host enables encryption at rest for your temporary disk and OS/data disk caches. Temporary and ephemeral OS disks are encrypted with platform-managed keys when encryption at host is enabled. OS/data disk caches are encrypted at rest with either customer-managed or platform-managed key, depending on the encryption type selected on the disk. Learn more at Use the Azure portal to enable end-to-end encryption using encryption at host. (Related policy: Virtual machines and virtual machine scale sets should have encryption at host enabled).

Severity: Medium

Container recommendations

(Enable if required) Container registries should be encrypted with a customer-managed key (CMK)

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of the contents of your registries. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about CMK encryption at https://aka.ms/acr/CMK. (Related policy: Container registries should be encrypted with a customer-managed key (CMK)).

Severity: Low

Type: Control plane

Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed

Description: Azure Policy extension for Kubernetes extends Gatekeeper v3, an admission controller webhook for Open Policy Agent (OPA), to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner. (No related policy)

Severity: High

Type: Control plane

Azure Arc-enabled Kubernetes clusters should have the Defender extension installed

Description: Defender's extension for Azure Arc provides threat protection for your Arc-enabled Kubernetes clusters. The extension collects data from all control plane (master) nodes in the cluster and sends it to the Microsoft Defender for Kubernetes backend in the cloud for further analysis. (No related policy)

Severity: High

Type: Control plane

Azure Kubernetes Service clusters should have Defender profile enabled

Description: Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.AzureDefender profile on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more in Introduction to Microsoft Defender for Containers. (No related policy)

Severity: High

Type: Control plane

Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed

Description: Azure Policy add-on for Kubernetes extends Gatekeeper v3, an admission controller webhook for Open Policy Agent (OPA), to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner. Defender for Cloud requires the Add-on to audit and enforce security capabilities and compliance inside your clusters. Learn more. Requires Kubernetes v1.14.0 or later. (Related policy: Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters).

Severity: High

Type: Control plane

Container registries should not allow unrestricted network access

Description: Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific public IP addresses or address ranges. If your registry doesn't have an IP/firewall rule or a configured virtual network, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: https://aka.ms/acr/portal/public-network and here https://aka.ms/acr/vnet. (Related policy: Container registries should not allow unrestricted network access).

Severity: Medium

Type: Control plane

Container registries should use private link

Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your container registries instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/acr/private-link. (Related policy: Container registries should use private link).

Severity: Medium

Type: Control plane

Diagnostic logs in Kubernetes services should be enabled

Description: Enable diagnostic logs in your Kubernetes services and retain them up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs. (No related policy)

Severity: Low

Type: Control plane

Kubernetes API server should be configured with restricted access

Description: To ensure that only applications from allowed networks, machines, or subnets can access your cluster, restrict access to your Kubernetes API server. You can restrict access by defining authorized IP ranges, or by setting up your API servers as private clusters as explained in Create a private Azure Kubernetes Service cluster. (Related policy: Authorized IP ranges should be defined on Kubernetes Services).

Severity: High

Type: Control plane

Role-Based Access Control should be used on Kubernetes Services

Description: To provide granular filtering on the actions that users can perform, use Role-Based Access Control (RBAC) to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies. (Related policy: Role-Based Access Control (RBAC) should be used on Kubernetes Services).

Severity: High

Type: Control plane

Microsoft Defender for Containers should be enabled

Description: Microsoft Defender for Containers provides hardening, vulnerability assessment and run-time protections for your Azure, hybrid, and multicloud Kubernetes environments. You can use this information to quickly remediate security issues and improve the security of your containers.

Important: Remediating this recommendation will result in charges for protecting your Kubernetes clusters. If you don't have any Kubernetes clusters in this subscription, no charges will be incurred. If you create any Kubernetes clusters on this subscription in the future, they'll automatically be protected and charges will begin at that time. Learn more in Introduction to Microsoft Defender for Containers. (No related policy)

Severity: High

Type: Control plane

Container CPU and memory limits should be enforced

Description: Enforcing CPU and memory limits prevents resource exhaustion attacks (a form of denial of service attack).

We recommend setting limits for containers to ensure the runtime prevents the container from using more than the configured resource limit.

(Related policy: Ensure container CPU and memory resource limits do not exceed the specified limits in Kubernetes cluster).

Severity: Medium

Type: Kubernetes Data plane

Container images should be deployed from trusted registries only

Description: Images running on your Kubernetes cluster should come from known and monitored container image registries. Trusted registries reduce your cluster's exposure risk by limiting the potential for the introduction of unknown vulnerabilities, security issues, and malicious images.

(Related policy: Ensure only allowed container images in Kubernetes cluster).

Severity: High

Type: Kubernetes Data plane

Container with privilege escalation should be avoided

Description: Containers shouldn't run with privilege escalation to root in your Kubernetes cluster. The AllowPrivilegeEscalation attribute controls whether a process can gain more privileges than its parent process. (Related policy: Kubernetes clusters should not allow container privilege escalation).

Severity: Medium

Type: Kubernetes data plane

Containers sharing sensitive host namespaces should be avoided

Description: To protect against privilege escalation outside the container, avoid pod access to sensitive host namespaces (host process ID and host IPC) in a Kubernetes cluster. (Related policy: Kubernetes cluster containers should not share host process ID or host IPC namespace).

Severity: Medium

Type: Kubernetes data plane

Containers should only use allowed AppArmor profiles

Description: Containers running on Kubernetes clusters should be limited to allowed AppArmor profiles only. ;AppArmor (Application Armor) is a Linux security module that protects an operating system and its applications from security threats. To use it, a system administrator associates an AppArmor security profile with each program. (Related policy: Kubernetes cluster containers should only use allowed AppArmor profiles).

Severity: High

Type: Kubernetes data plane

Immutable (read-only) root filesystem should be enforced for containers

Description: Containers should run with a read only root file system in your Kubernetes cluster. Immutable filesystem protects containers from changes at run-time with malicious binaries being added to PATH. (Related policy: Kubernetes cluster containers should run with a read only root file system).

Severity: Medium

Type: Kubernetes data plane

Kubernetes clusters should be accessible only over HTTPS

Description: Use of HTTPS ensures authentication and protects data in transit from network layer eavesdropping attacks. This capability is currently generally available for Kubernetes Service (AKS), and in preview for AKS Engine and Azure Arc-enabled Kubernetes. For more info, visit https://aka.ms/kubepolicydoc (Related policy: Enforce HTTPS ingress in Kubernetes cluster).

Severity: High

Type: Kubernetes Data plane

Kubernetes clusters should disable automounting API credentials

Description: Disable automounting API credentials to prevent a potentially compromised Pod resource to run API commands against Kubernetes clusters. For more information, see https://aka.ms/kubepolicydoc. (Related policy: Kubernetes clusters should disable automounting API credentials).

Severity: High

Type: Kubernetes Data plane

Kubernetes clusters should not grant CAPSYSADMIN security capabilities

Description: To reduce the attack surface of your containers, restrict CAP_SYS_ADMIN Linux capabilities. For more information, see https://aka.ms/kubepolicydoc. (No related policy)

Severity: High

Type: Kubernetes data plane

Kubernetes clusters should not use the default namespace

Description: Prevent usage of the default namespace in Kubernetes clusters to protect against unauthorized access for ConfigMap, Pod, Secret, Service, and ServiceAccount resource types. For more information, see https://aka.ms/kubepolicydoc. (Related policy: Kubernetes clusters should not use the default namespace).

Severity: Low

Type: Kubernetes data plane

Least privileged Linux capabilities should be enforced for containers

Description: To reduce attack surface of your container, restrict Linux capabilities and grant specific privileges to containers without granting all the privileges of the root user. We recommend dropping all capabilities, then adding those that are required (Related policy: Kubernetes cluster containers should only use allowed capabilities).

Severity: Medium

Type: Kubernetes data plane

Privileged containers should be avoided

Description: To prevent unrestricted host access, avoid privileged containers whenever possible.

Privileged containers have all of the root capabilities of a host machine. They can be used as entry points for attacks and to spread malicious code or malware to compromised applications, hosts, and networks. (Related policy: Do not allow privileged containers in Kubernetes cluster).

Severity: Medium

Type: Kubernetes data plane

Running containers as root user should be avoided

Description: Containers shouldn't run as root users in your Kubernetes cluster. Running a process as the root user inside a container runs it as root on the host. If there's a compromise, an attacker has root in the container, and any misconfigurations become easier to exploit. (Related policy: Kubernetes cluster pods and containers should only run with approved user and group IDs).

Severity: High

Type: Kubernetes Data plane

Services should listen on allowed ports only

Description: To reduce the attack surface of your Kubernetes cluster, restrict access to the cluster by limiting services access to the configured ports. (Related policy: Ensure services listen only on allowed ports in Kubernetes cluster).

Severity: Medium

Type: Kubernetes data plane

Usage of host networking and ports should be restricted

Description: Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. Pods created with the hostNetwork attribute enabled will share the node's network space. To avoid compromised container from sniffing network traffic, we recommend not putting your pods on the host network. If you need to expose a container port on the node's network, and using a Kubernetes Service node port does not meet your needs, another possibility is to specify a hostPort for the container in the pod spec. (Related policy: Kubernetes cluster pods should only use approved host network and port range).

Severity: Medium

Type: Kubernetes data plane

Usage of pod HostPath volume mounts should be restricted to a known list to restrict node access from compromised containers

Description: We recommend limiting pod HostPath volume mounts in your Kubernetes cluster to the configured allowed host paths. If there's a compromise, the container node access from the containers should be restricted. (Related policy: Kubernetes cluster pod hostPath volumes should only use allowed host paths).

Severity: Medium

Type: Kubernetes Data plane

Azure registry container images should have vulnerabilities resolved (powered by Qualys)

Description: Container image vulnerability assessment scans your registry for security vulnerabilities and exposes detailed findings for each image. Resolving the vulnerabilities can greatly improve your containers' security posture and protect them from attacks. (Related policy: Vulnerabilities in Azure Container Registry images should be remediated).

Severity: High

Type: Vulnerability Assessment

Azure registry container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)

Description: Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. Resolving vulnerabilities can greatly improve your security posture, ensuring images are safe to use prior to deployment. (Related policy: Vulnerabilities in Azure Container Registry images should be remediated).

Severity: High

Type: Vulnerability Assessment

Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)

Description: Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. This recommendation provides visibility to vulnerable images currently running in your Kubernetes clusters. Remediating vulnerabilities in container images that are currently running is key to improving your security posture, significantly reducing the attack surface for your containerized workloads.

Severity: High

Type: Vulnerability Assessment

Data recommendations

(Enable if required) Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of your Azure Cosmos DB. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about CMK encryption at https://aka.ms/cosmosdb-cmk. (Related policy: Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest).

Severity: Low

(Enable if required) Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Manage encryption at rest of your Azure Machine Learning workspace data with customer-managed keys (CMK). By default, customer data is encrypted with service-managed keys, but CMKs are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about CMK encryption at https://aka.ms/azureml-workspaces-cmk. (Related policy: Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)).

Severity: Low

(Enable if required) Cognitive Services accounts should enable data encryption with a customer-managed key (CMK)

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data stored in Cognitive Services to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about CMK encryption at https://aka.ms/cosmosdb-cmk. (Related policy: Cognitive Services accounts should enable data encryption with a customer-managed key?(CMK))

Severity: Low

(Enable if required) MySQL servers should use customer-managed keys to encrypt data at rest

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of your MySQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. (Related policy: Bring your own key data protection should be enabled for MySQL servers).

Severity: Low

(Enable if required) PostgreSQL servers should use customer-managed keys to encrypt data at rest

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of your PostgreSQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. (Related policy: Bring your own key data protection should be enabled for PostgreSQL servers).

Severity: Low

(Enable if required) SQL managed instances should use customer-managed keys to encrypt data at rest

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Implementing Transparent Data Encryption (TDE) with your own key provides you with increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement. (Related policy: SQL managed instances should use customer-managed keys to encrypt data at rest).

Severity: Low

(Enable if required) SQL servers should use customer-managed keys to encrypt data at rest

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Implementing Transparent Data Encryption (TDE) with your own key provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement. (Related policy: SQL servers should use customer-managed keys to encrypt data at rest).

Severity: Low

(Enable if required) Storage accounts should use customer-managed key (CMK) for encryption

Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Secure your storage account with greater flexibility using customer-managed keys (CMKs). When you specify a CMK, that key is used to protect and control access to the key that encrypts your data. Using CMKs provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. (Related policy: Storage accounts should use customer-managed key (CMK) for encryption).

Severity: Low

All advanced threat protection types should be enabled in SQL managed instance advanced data security settings

Description: It is recommended to enable all advanced threat protection types on your SQL managed instances. Enabling all types protects against SQL injection, database vulnerabilities, and any other anomalous activities. (No related policy)

Severity: Medium

All advanced threat protection types should be enabled in SQL server advanced data security settings

Description: It is recommended to enable all advanced threat protection types on your SQL servers. Enabling all types protects against SQL injection, database vulnerabilities, and any other anomalous activities. (No related policy)

Severity: Medium

API Management services should use a virtual network

Description: Azure Virtual Network deployment provides enhanced security, isolation, and allows you to place your API Management service in a non-internet routable network that you control access to. These networks can then be connected to your on-premises networks using various VPN technologies, which enables access to your backend services within the network and/or on-premises. The developer portal and API gateway can be configured to be accessible either from the Internet or only within the virtual network. (Related policy: API Management services should use a virtual network).

Severity: Medium

App Configuration should use private link

Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your app configuration instances instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/appconfig/private-endpoint. (Related policy: App Configuration should use private link).

Severity: Medium

Audit retention for SQL servers should be set to at least 90 days

Description: Audit SQL servers configured with an auditing retention period of less than 90 days. (Related policy: SQL servers should be configured with 90 days auditing retention or higher.)

Severity: Low

Auditing on SQL server should be enabled

Description: Enable auditing on your SQL Server to track database activities across all databases on the server and save them in an audit log. (Related policy: Auditing on SQL server should be enabled).

Severity: Low

Auto provisioning of the Log Analytics agent should be enabled on subscriptions

Description: To monitor for security vulnerabilities and threats, Microsoft Defender for Cloud collects data from your Azure virtual machines. Data is collected by the Log Analytics agent, formerly known as the Microsoft Monitoring Agent (MMA), which reads various security-related configurations and event logs from the machine and copies the data to your Log Analytics workspace for analysis. We recommend enabling auto provisioning to automatically deploy the agent to all supported Azure VMs and any new ones that are created. (Related policy: Auto provisioning of the Log Analytics agent should be enabled on your subscription).

Severity: Low

Azure Cache for Redis should reside within a virtual network

Description: Azure Virtual Network (VNet) deployment provides enhanced security and isolation for your Azure Cache for Redis, as well as subnets, access control policies, and other features to further restrict access. When an Azure Cache for Redis instance is configured with a VNet, it is not publicly addressable and can only be accessed from virtual machines and applications within the VNet. (Related policy: Azure Cache for Redis should reside within a virtual network).

Severity: Medium

Azure Database for MySQL should have an Azure Active Directory administrator provisioned

Description: Provision an Azure AD administrator for your Azure Database for MySQL to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services (Related policy: An Azure Active Directory administrator should be provisioned for MySQL servers).

Severity: Medium

Azure Database for PostgreSQL should have an Azure Active Directory administrator provisioned

Description: Provision an Azure AD administrator for your Azure Database for PostgreSQL to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services
(Related policy: An Azure Active Directory administrator should be provisioned for PostgreSQL servers).

Severity: Medium

Azure Cosmos DB accounts should have firewall rules

Description: Firewall rules should be defined on your Azure Cosmos DB accounts to prevent traffic from unauthorized sources. Accounts that have at least one IP rule defined with the virtual network filter enabled are deemed compliant. Accounts disabling public access are also deemed compliant. (Related policy: Azure Cosmos DB accounts should have firewall rules).

Severity: Medium

Azure Event Grid domains should use private link

Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Event Grid domains instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/privateendpoints. (Related policy: Azure Event Grid domains should use private link).

Severity: Medium

Azure Event Grid topics should use private link

Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your topics instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/privateendpoints. (Related policy: Azure Event Grid topics should use private link).

Severity: Medium

Azure Machine Learning workspaces should use private link

Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure Machine Learning workspaces instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/azureml-workspaces-privatelink. (Related policy: Azure Machine Learning workspaces should use private link).

Severity: Medium

Azure SignalR Service should use private link

Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your SignalR resources instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/asrs/privatelink. (Related policy: Azure SignalR Service should use private link).

Severity: Medium

Azure Spring Cloud should use network injection

Description: Azure Spring Cloud instances should use virtual network injection for the following purposes: 1. Isolate Azure Spring Cloud from Internet. 2. Enable Azure Spring Cloud to interact with systems in either on premises data centers or Azure service in other virtual networks. 3. Empower customers to control inbound and outbound network communications for Azure Spring Cloud. (Related policy: Azure Spring Cloud should use network injection).

Severity: Medium

SQL servers should have an Azure Active Directory administrator provisioned

Description: Provision an Azure AD administrator for your SQL server to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services. (Related policy: An Azure Active Directory administrator should be provisioned for SQL servers).

Severity: High

Azure Synapse Workspace authentication mode should be Azure Active Directory Only

Description: Azure Synapse Workspace authentication mode should be Azure Active Directory Only Azure Active Directory only authentication methods improves security by ensuring that Synapse Workspaces exclusively require Azure AD identities for authentication. Learn more. (Related policy: Synapse Workspaces should use only Azure Active Directory identities for authentication).

Severity: Medium

Cognitive Services accounts should enable data encryption

Description: This policy audits any Cognitive Services account not using data encryption. For each Cognitive Services account with storage, should enable data encryption with either customer managed or Microsoft managed key. (Related policy: Cognitive Services accounts should enable data encryption).

Severity: Low

Cognitive Services accounts should use customer owned storage or enable data encryption

Description: This policy audits any Cognitive Services account not using customer owned storage nor data encryption. For each Cognitive Services account with storage, use either customer owned storage or enable data encryption. (Related policy: Cognitive Services accounts should use customer owned storage or enable data encryption.)

Severity: Low

Diagnostic logs in Azure Data Lake Store should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Azure Data Lake Store should be enabled).

Severity: Low

Diagnostic logs in Data Lake Analytics should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Data Lake Analytics should be enabled).

Severity: Low

Email notification for high severity alerts should be enabled

Description: To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, enable email notifications for high severity alerts in Defender for Cloud. (Related policy: Email notification for high severity alerts should be enabled).

Severity: Low

Email notification to subscription owner for high severity alerts should be enabled

Description: To ensure your subscription owners are notified when there is a potential security breach in their subscription, set email notifications to subscription owners for high severity alerts in Defender for Cloud. (Related policy: Email notification to subscription owner for high severity alerts should be enabled).

Severity: Medium

Enforce SSL connection should be enabled for MySQL database servers

Description: Azure Database for MySQL supports connecting your Azure Database for MySQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server. (Related policy: Enforce SSL connection should be enabled for MySQL database servers).

Severity: Medium

Enforce SSL connection should be enabled for PostgreSQL database servers

Description: Azure Database for PostgreSQL supports connecting your Azure Database for PostgreSQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server. (Related policy: Enforce SSL connection should be enabled for PostgreSQL database servers).

Severity: Medium

Function apps should have vulnerability findings resolved

Description: Runtime vulnerability scanning for functions scans your function apps for security vulnerabilities and exposes detailed findings. Resolving the vulnerabilities can greatly improve your serverless applications security posture and protect them from attacks. (No related policy)

Severity: High

Geo-redundant backup should be enabled for Azure Database for MariaDB

Description: Azure Database for MariaDB allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery options in case of a region failure. Configuring geo-redundant storage for backup is only allowed when creating a server. (Related policy: Geo-redundant backup should be enabled for Azure Database for MariaDB).

Severity: Low

Geo-redundant backup should be enabled for Azure Database for MySQL

Description: Azure Database for MySQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery options in case of a region failure. Configuring geo-redundant storage for backup is only allowed when creating a server. (Related policy: Geo-redundant backup should be enabled for Azure Database for MySQL).

Severity: Low

Geo-redundant backup should be enabled for Azure Database for PostgreSQL

Description: Azure Database for PostgreSQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery options in case of a region failure. Configuring geo-redundant storage for backup is only allowed when creating a server. (Related policy: Geo-redundant backup should be enabled for Azure Database for PostgreSQL).

Severity: Low

GitHub repositories should have Code scanning enabled

Description: GitHub uses code scanning to analyze code in order to find security vulnerabilities and errors in code. Code scanning can be used to find, triage, and prioritize fixes for existing problems in your code. Code scanning can also prevent developers from introducing new problems. Scans can be scheduled for specific days and times, or scans can be triggered when a specific event occurs in the repository, such as a push. If code scanning finds a potential vulnerability or error in code, GitHub displays an alert in the repository. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project. (No related policy)

Severity: Medium

GitHub repositories should have Dependabot scanning enabled

Description: GitHub sends Dependabot alerts when it detects vulnerabilities in code dependencies that affect repositories. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project or other projects that use its code. Vulnerabilities vary in type, severity, and method of attack. When code depends on a package that has a security vulnerability, this vulnerable dependency can cause a range of problems. (No related policy)

Severity: Medium

GitHub repositories should have Secret scanning enabled

Description: GitHub scans repositories for known types of secrets, to prevent fraudulent use of secrets that were accidentally committed to repositories. Secret scanning will scan the entire Git history on all branches present in the GitHub repository for any secrets. Examples of secrets are tokens and private keys that a service provider can issue for authentication. If a secret is checked into a repository, anyone who has read access to the repository can use the secret to access the external service with those privileges. Secrets should be stored in a dedicated, secure location outside the repository for the project. (No related policy)

Severity: High

Microsoft Defender for Azure SQL Database servers should be enabled

Description: Microsoft Defender for SQL is a unified package that provides advanced SQL security capabilities. It includes functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate a threat to your database, and discovering and classifying sensitive data. Important: Protections from this plan are charged as shown on the Defender plans page. If you don't have any Azure SQL Database servers in this subscription, you won't be charged. If you later create Azure SQL Database servers on this subscription, they'll automatically be protected and charges will begin. Learn about the pricing details per region. Learn more in Introduction to Microsoft Defender for SQL. (Related policy: Azure Defender for Azure SQL Database servers should be enabled).

Severity: High

Microsoft Defender for DNS should be enabled

Description: Microsoft Defender for DNS provides an additional layer of protection for your cloud resources by continuously monitoring all DNS queries from your Azure resources. Defender for DNS alerts you about suspicious activity at the DNS layer. Learn more in Introduction to Microsoft Defender for DNS. Enabling this Defender plan results in charges. Learn about the pricing details per region on Defender for Cloud's pricing page: Defender for Cloud Pricing. (No related policy)

Severity: High

Microsoft Defender for open-source relational databases should be enabled

Description: Microsoft Defender for open-source relational databases detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Learn more in Introduction to Microsoft Defender for open-source relational databases.

Important: Enabling this plan will result in charges for protecting your open-source relational databases. If you don't have any open-source relational databases in this subscription, no charges will be incurred. If you create any open-source relational databases on this subscription in the future, they will automatically be protected and charges will begin at that time. (No related policy)

Severity: High

Microsoft Defender for Resource Manager should be enabled

Description: Microsoft Defender for Resource Manager automatically monitors the resource management operations in your organization. Defender for Cloud detects threats and alerts you about suspicious activity. Learn more in Introduction to Microsoft Defender for Resource Manager. Enabling this Defender plan results in charges. Learn about the pricing details per region on Defender for Cloud's pricing page: Defender for Cloud Pricing. (No related policy)

Severity: High

Microsoft Defender for SQL on machines should be enabled on workspaces

Description: Microsoft Defender for servers brings threat detection and advanced defenses for your Windows and Linux machines. With this Defender plan enabled on your subscriptions but not on your workspaces, you're paying for the full capability of Microsoft Defender for servers but missing out on some of the benefits. When you enable Microsoft Defender for servers on a workspace, all machines reporting to that workspace will be billed for Microsoft Defender for servers - even if they're in subscriptions without Defender plans enabled. Unless you also enable Microsoft Defender for servers on the subscription, those machines won't be able to take advantage of just-in-time VM access, adaptive application controls, and network detections for Azure resources. Learn more in Introduction to Microsoft Defender for servers. (No related policy)

Severity: Medium

Microsoft Defender for SQL servers on machines should be enabled

Description: Microsoft Defender for SQL is a unified package that provides advanced SQL security capabilities. It includes functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate a threat to your database, and discovering and classifying sensitive data.

Important: Remediating this recommendation will result in charges for protecting your SQL servers on machines. If you don't have any SQL servers on machines in this subscription, no charges will be incurred. If you create any SQL servers on machines on this subscription in the future, they will automatically be protected and charges will begin at that time. Learn more about Microsoft Defender for SQL servers on machines. (Related policy: Azure Defender for SQL servers on machines should be enabled).

Severity: High

Microsoft Defender for SQL should be enabled for unprotected Azure SQL servers

Description: Microsoft Defender for SQL is a unified package that provides advanced SQL security capabilities. It surfaces and mitigates potential database vulnerabilities, and detects anomalous activities that could indicate a threat to your database. Microsoft Defender for SQL is billed as shown on pricing details per region. (Related policy: Advanced data security should be enabled on your SQL servers).

Severity: High

Microsoft Defender for SQL should be enabled for unprotected SQL Managed Instances

Description: Microsoft Defender for SQL is a unified package that provides advanced SQL security capabilities. It surfaces and mitigates potential database vulnerabilities, and detects anomalous activities that could indicate a threat to your database. Microsoft Defender for SQL is billed as shown on pricing details per region. (Related policy: Advanced data security should be enabled on SQL Managed Instance).

Severity: High

Network Watcher should be enabled

Description: Network Watcher is a regional service that enables you to monitor and diagnose conditions at a network scenario level in, to, and from Azure. Scenario level monitoring enables you to diagnose problems at an end-to-end network level view. Network diagnostic and visualization tools available with Network Watcher help you understand, diagnose, and gain insights to your network in Azure. (Related policy: Network Watcher should be enabled).

Severity: Low

Private endpoint connections on Azure SQL Database should be enabled

Description: Private endpoint connections enforce secure communication by enabling private connectivity to Azure SQL Database. (Related policy: Private endpoint connections on Azure SQL Database should be enabled).

Severity: Medium

Private endpoint should be enabled for MariaDB servers

Description: Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for MariaDB. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure. (Related policy: Private endpoint should be enabled for MariaDB servers).

Severity: Medium

Private endpoint should be enabled for MySQL servers

Description: Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for MySQL. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure. (Related policy: Private endpoint should be enabled for MySQL servers).

Severity: Medium

Private endpoint should be enabled for PostgreSQL servers

Description: Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for PostgreSQL. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure. (Related policy: Private endpoint should be enabled for PostgreSQL servers).

Severity: Medium

Public network access on Azure SQL Database should be disabled

Description: Disabling the public network access property improves security by ensuring your Azure SQL Database can only be accessed from a private endpoint. This configuration denies all logins that match IP or virtual network based firewall rules. (Related policy: Public network access on Azure SQL Database should be disabled).

Severity: Medium

Public network access should be disabled for MariaDB servers

Description: Disable the public network access property to improve security and ensure your Azure Database for MariaDB can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. (Related policy: Public network access should be disabled for MariaDB servers).

Severity: Medium

Public network access should be disabled for MySQL servers

Description: Disable the public network access property to improve security and ensure your Azure Database for MySQL can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. (Related policy: Public network access should be disabled for MySQL servers).

Severity: Medium

Public network access should be disabled for PostgreSQL servers

Description: Disable the public network access property to improve security and ensure your Azure Database for PostgreSQL can only be accessed from a private endpoint. This configuration disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. (Related policy: Public network access should be disabled for PostgreSQL servers).

Severity: Medium

Redis Cache should allow access only via SSL

Description: Enable only connections via SSL to Redis Cache. Use of secure connections ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking. (Related policy: Only secure connections to your Azure Cache for Redis should be enabled).

Severity: High

SQL databases should have vulnerability findings resolved

Description: SQL Vulnerability assessment scans your database for security vulnerabilities, and exposes any deviations from best practices such as misconfigurations, excessive permissions, and unprotected sensitive data. Resolving the vulnerabilities found can greatly improve your database security posture. Learn more (Related policy: Vulnerabilities on your SQL databases should be remediated).

Severity: High

SQL managed instances should have vulnerability assessment configured

Description: Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities. (Related policy: Vulnerability assessment should be enabled on SQL Managed Instance).

Severity: High

SQL servers on machines should have vulnerability findings resolved

Description: SQL Vulnerability assessment scans your database for security vulnerabilities, and exposes any deviations from best practices such as misconfigurations, excessive permissions, and unprotected sensitive data. Resolving the vulnerabilities found can greatly improve your database security posture. Learn more (Related policy: Vulnerabilities on your SQL servers on machine should be remediated).

Severity: High

SQL servers should have an Azure Active Directory administrator provisioned

Description: Provision an Azure AD administrator for your SQL server to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services. (Related policy: An Azure Active Directory administrator should be provisioned for SQL servers).

Severity: High

SQL servers should have vulnerability assessment configured

Description: Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities. (Related policy: Vulnerability assessment should be enabled on your SQL servers).

Severity: High

Storage account should use a private link connection

Description: Private links enforce secure communication, by providing private connectivity to the storage account (Related policy: Storage account should use a private link connection).

Severity: Medium

Storage accounts should be migrated to new Azure Resource Manager resources

Description: To benefit from new capabilities in Azure Resource Manager, you can migrate existing deployments from the Classic deployment model. Resource Manager enables security enhancements such as: stronger access control (RBAC), better auditing, ARM-based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication, and support for tags and resource groups for easier security management. Learn more (Related policy: Storage accounts should be migrated to new Azure Resource Manager resources).

Severity: Low

Storage accounts should restrict network access using virtual network rules

Description: Protect your storage accounts from potential threats using virtual network rules as a preferred method instead of IP-based filtering. Disabling IP-based filtering prevents public IPs from accessing your storage accounts. (Related policy: Storage accounts should restrict network access using virtual network rules).

Severity: Medium

Subscriptions should have a contact email address for security issues

Description: To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, set a security contact to receive email notifications from Defender for Cloud. (Related policy: Subscriptions should have a contact email address for security issues)

Severity: Low

Transparent Data Encryption on SQL databases should be enabled

Description: Enable transparent data encryption to protect data-at-rest and meet compliance requirements (Related policy: Transparent Data Encryption on SQL databases should be enabled).

Severity: Low

VM Image Builder templates should use private link

Description: Audit VM Image Builder templates that do not have a virtual network configured. When a virtual network is not configured, a public IP is created and used instead, which might directly expose resources to the internet and increase the potential attack surface. (Related policy: VM Image Builder templates should use private link).

Severity: Medium

Web Application Firewall (WAF) should be enabled for Application Gateway

Description: Deploy Azure Web Application Firewall (WAF) in front of public facing web applications for additional inspection of incoming traffic. Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities such as SQL injections, Cross-Site Scripting, local and remote file executions. You can also restrict access to your web applications by countries/regions, IP address ranges, and other http(s) parameters via custom rules. (Related policy: Web Application Firewall (WAF) should be enabled for Application Gateway).

Severity: Low

Web Application Firewall (WAF) should be enabled for Azure Front Door Service service

Description: Deploy Azure Web Application Firewall (WAF) in front of public facing web applications for additional inspection of incoming traffic. Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities such as SQL injections, Cross-Site Scripting, local and remote file executions. You can also restrict access to your web applications by countries/regions, IP address ranges, and other http(s) parameters via custom rules. (Related policy: Web Application Firewall (WAF) should be enabled for Azure Front Door Service?service)

Severity: Low

Cognitive Services should use private link

Description: Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to Cognitive Services, you'll reduce the potential for data leakage. Learn more about private links. (Related policy: Cognitive Services should use private link).

Severity: Medium

Azure Cosmos DB should disable public network access

Description: Disabling public network access improves security by ensuring that your Cosmos DB account isn't exposed on the public internet. Creating private endpoints can limit exposure of your Cosmos DB account. Learn more. (Related policy: Azure Cosmos DB should disable public network access).

Severity: Medium

Cosmos DB accounts should use private link

Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Cosmos DB account, data leakage risks are reduced. Learn more about private links. (Related policy: Cosmos DB accounts should use private link).

Severity: Medium

Azure SQL Database should be running TLS version 1.2 or newer

Description: Setting TLS version to 1.2 or newer improves security by ensuring your Azure SQL Database can only be accessed from clients using TLS 1.2 or newer. Using versions of TLS less than 1.2 is not recommended since they have well documented security vulnerabilities. (Related policy: Azure SQL Database should be running TLS version 1.2 or newer).

Severity: Medium

Azure SQL Managed Instances should disable public network access

Description: Disabling public network access (public endpoint) on Azure SQL Managed Instances improves security by ensuring that they can only be accessed from inside their virtual networks or via Private Endpoints. Learn more about public network access. (Related policy: Azure SQL Managed Instances should disable public network access).

Severity: Medium

Storage accounts should prevent shared key access

Description: Audit requirement of Azure Active Directory (Azure AD) to authorize requests for your storage account. By default, requests can be authorized with either Azure Active Directory credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over shared Key, and is recommended by Microsoft. (Related policy: policy)

Severity: Medium

Identity and access recommendations

A maximum of 3 owners should be designated for subscriptions

Description: To reduce the potential for breaches by compromised owner accounts, we recommend limiting the number of owner accounts to a maximum of 3 (Related policy: A maximum of 3 owners should be designated for your subscription).

Severity: High

Accounts with owner permissions on Azure resources should be MFA enabled

Description: If you only use passwords to authenticate your users, you're leaving an attack vector open. Users often use weak passwords for multiple services. By enabling multifactor authentication (MFA), you provide better security for your accounts, while still allowing your users to authenticate to almost any application with single sign-on (SSO). Multifactor authentication is a process by which users are prompted, during the sign-in process, for another form of identification. For example, a code might be sent to their cellphone, or they might be asked for a fingerprint scan. We recommend you to enable MFA for all accounts that have owner permissions on Azure resources, to prevent breach and attacks. More details and frequently asked questions are available here: Manage multifactor authentication (MFA) enforcement on your subscriptions (No related policy).

Severity: High

Accounts with read permissions on Azure resources should be MFA enabled

Description: If you only use passwords to authenticate your users, you're leaving an attack vector open. Users often use weak passwords for multiple services. By enabling multifactor authentication (MFA), you provide better security for your accounts, while still allowing your users to authenticate to almost any application with single sign-on (SSO). Multifactor authentication is a process by which users are prompted, during the sign-in process, for an additional form of identification. For example, a code might be sent to their cellphone, or they might be asked for a fingerprint scan. We recommend you to enable MFA for all accounts that have read permissions on Azure resources, to prevent breach and attacks. More details and frequently asked questions are available here. (No related policy)

Severity: High

Accounts with write permissions on Azure resources should be MFA enabled

Description: If you only use passwords to authenticate your users, you are leaving an attack vector open. Users often use weak passwords for multiple services. By enabling multifactor authentication (MFA), you provide better security for your accounts, while still allowing your users to authenticate to almost any application with single sign-on (SSO). Multifactor authentication is a process by which users are prompted, during the sign-in process, for an additional form of identification. For example, a code might be sent to their cellphone, or they might be asked for a fingerprint scan. We recommend you to enable MFA for all accounts that have write permissions on Azure resources, to prevent breach and attacks. More details and frequently asked questions are available here: Manage multifactor authentication (MFA) enforcement on your subscriptions (No related policy).

Severity: High

Azure Cosmos DB accounts should use Azure Active Directory as the only authentication method

Description: The best way to authenticate to Azure services is by using Role-Based Access Control (RBAC). RBAC allows you to maintain the minimum privilege principle and supports the ability to revoke permissions as an effective method of response when compromised. You can configure your Azure Cosmos DB account to enforce RBAC as the only authentication method. When the enforcement is configured, all other methods of access will be denied (primary/secondary keys and access tokens). (No related policy)

Severity: Medium

Blocked accounts with owner permissions on Azure resources should be removed

Description: Accounts that have been blocked from signing in on Active Directory, should be removed from your Azure resources. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (No related policy)

Severity: High

Blocked accounts with read and write permissions on Azure resources should be remove

Description: Accounts that have been blocked from signing in on Active Directory, should be removed from your Azure resources. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (No related policy)

Severity: High

Deprecated accounts should be removed from subscriptions

Description: User accounts that have been blocked from signing in, should be removed from your subscriptions. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (Related policy: Deprecated accounts should be removed from your subscription).

Severity: High

Deprecated accounts with owner permissions should be removed from subscriptions

Description: User accounts that have been blocked from signing in, should be removed from your subscriptions. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (Related policy: Deprecated accounts with owner permissions should be removed from your subscription).

Severity: High

Diagnostic logs in Key Vault should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Key Vault should be enabled).

Severity: Low

External accounts with owner permissions should be removed from subscriptions

Description: Accounts with owner permissions that have different domain names (external accounts), should be removed from your subscription. This prevents unmonitored access. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (Related policy: External accounts with owner permissions should be removed from your subscription).

Severity: High

External accounts with read permissions should be removed from subscriptions

Description: Accounts with read permissions that have different domain names (external accounts), should be removed from your subscription. This prevents unmonitored access. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (Related policy: External accounts with read permissions should be removed from your subscription).

Severity: High

External accounts with write permissions should be removed from subscriptions

Description: Accounts with write permissions that have different domain names (external accounts), should be removed from your subscription. This prevents unmonitored access. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (Related policy: External accounts with write permissions should be removed from your subscription).

Severity: High

Firewall should be enabled on Key Vault

Description: Key vault's firewall prevents unauthorized traffic from reaching your key vault and provides an additional layer of protection for your secrets. Enable the firewall to make sure that only traffic from allowed networks can access your key vault. (Related policy: Firewall should be enabled on Key Vault).

Severity: Medium

Guest accounts with owner permissions on Azure resources should be removed

Description: Accounts with owner permissions that have been provisioned outside of the Azure Active Directory tenant (different domain names), should be removed from your Azure resources. Guest accounts aren't managed to the same standards as enterprise tenant identities. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (No related policy)

Severity: High

Guest accounts with read permissions on Azure resources should be removed

Description: Accounts with read permissions that have been provisioned outside of the Azure Active Directory tenant (different domain names), should be removed from your Azure resources. Guest accounts aren't managed to the same standards as enterprise tenant identities. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (No related policy)

Severity: High

Guest accounts with write permissions on Azure resources should be removed

Description: Accounts with write permissions that have been provisioned outside of the Azure Active Directory tenant (different domain names), should be removed from your Azure resources. Guest accounts aren't managed to the same standards as enterprise tenant identities. These accounts can be targets for attackers looking to find ways to access your data without being noticed. (No related policy)

Severity: High

Key Vault keys should have an expiration date

Description: Cryptographic keys should have a defined expiration date and not be permanent. Keys that are valid forever provide a potential attacker with more time to compromise the key. It's a recommended security practice to set expiration dates on cryptographic keys. (Related policy: Key Vault keys should have an expiration date).

Severity: High

Key Vault secrets should have an expiration date

Description: Secrets should have a defined expiration date and not be permanent. Secrets that are valid forever provide a potential attacker with more time to compromise them. It's a recommended security practice to set expiration dates on secrets. (Related policy: Key Vault secrets should have an expiration date).

Severity: High

Key vaults should have purge protection enabled

Description: Malicious deletion of a key vault can lead to permanent data loss. A malicious insider in your organization can potentially delete and purge key vaults. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted key vaults. No one inside your organization or Microsoft will be able to purge your key vaults during the soft delete retention period. (Related policy: Key vaults should have purge protection enabled).

Severity: Medium

Key vaults should have soft delete enabled

Description: Deleting a key vault without soft delete enabled permanently deletes all secrets, keys, and certificates stored in the key vault. Accidental deletion of a key vault can lead to permanent data loss. Soft delete allows you to recover an accidentally deleted key vault for a configurable retention period. (Related policy: Key vaults should have soft delete enabled).

Severity: High

MFA should be enabled on accounts with owner permissions on subscriptions

Description: Multifactor authentication (MFA) should be enabled for all subscription accounts with owner permissions to prevent a breach of accounts or resources. (Related policy: MFA should be enabled on accounts with owner permissions on your subscription).

Severity: High

MFA should be enabled on accounts with read permissions on subscriptions

Description: Multifactor authentication (MFA) should be enabled for all subscription accounts with read privileges to prevent a breach of accounts or resources. (Related policy: MFA should be enabled on accounts with read permissions on your subscription).

Severity: High

MFA should be enabled on accounts with write permissions on subscriptions

Description: Multifactor authentication (MFA) should be enabled for all subscription accounts with write privileges to prevent a breach of accounts or resources. (Related policy: MFA should be enabled accounts with write permissions on your subscription).

Severity: High

Private endpoint should be configured for Key Vault

Description: Private link provides a way to connect Key Vault to your Azure resources without sending traffic over the public internet. Private link provides defense in depth protection against data exfiltration. (Related policy: Private endpoint should be configured for Key Vault).

Severity: Medium

Storage account public access should be disallowed

Description: Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data, but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it. (Related policy: Storage account public access should be disallowed).

Severity: Medium

There should be more than one owner assigned to subscriptions

Description: Designate more than one subscription owner in order to have administrator access redundancy. (Related policy: There should be more than one owner assigned to your subscription).

Severity: High

Validity period of certificates stored in Azure Key Vault should not exceed 12 months

Description: Ensure your certificates do not have a validity period that exceeds 12 months. (Related policy: Certificates should have the specified maximum validity period).

Severity: Medium

IoT recommendations

Default IP Filter Policy should be Deny

Description: IP Filter Configuration should have rules defined for allowed traffic and should deny all other traffic by default (No related policy).

Severity: Medium

Diagnostic logs in IoT Hub should be enabled

Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in IoT Hub should be enabled).

Severity: Low

Identical Authentication Credentials

Description: Identical authentication credentials to the IoT Hub used by multiple devices. This could indicate an illegitimate device impersonating a legitimate device. It also exposes the risk of device impersonation by an attacker (No related policy).

Severity: High

IP Filter rule large IP range

Description: An Allow IP Filter rule's source IP range is too large. Overly permissive rules might expose your IoT hub to malicious intenders (No related policy).

Severity: Medium

Networking recommendations

Access to storage accounts with firewall and virtual network configurations should be restricted

Description: Review the settings of network access in your storage account firewall settings. We recommended configuring network rules so that only applications from allowed networks can access the storage account. To allow connections from specific internet or on-premises clients, access can be granted to traffic from specific Azure virtual networks or to public internet IP address ranges. (Related policy: Storage accounts should restrict network access).

Severity: Low

All network ports should be restricted on network security groups associated to your virtual machine

Description: Defender for Cloud has identified some of your network security groups' inbound rules to be too permissive. Inbound rules should not allow access from 'Any' or 'Internet' ranges. This can potentially enable attackers to target your resources. (Related policy: All network ports should be restricted on network security groups associated to your virtual machine).

Severity: High

Azure DDoS Protection Standard should be enabled

Description: Defender for Cloud has discovered virtual networks with Application Gateway resources unprotected by the DDoS protection service. These resources contain public IPs. Enable mitigation of network volumetric and protocol attacks. (Related policy: Azure DDoS Protection Standard should be enabled).

Severity: Medium

Internet-facing virtual machines should be protected with network security groups

Description: Protect your VM from potential threats by restricting access to it with a network security group (NSG). NSGs contain a list of Access Control List (ACL) rules that allow or deny network traffic to your VM from other instances, in or outside the same subnet. To keep your machine as secure as possible, the VM access to the internet must be restricted and an NSG should be enabled on the subnet. VMs with 'High' severity are internet-facing VMs. (Related policy: Internet-facing virtual machines should be protected with network security groups).

Severity: High

IP forwarding on your virtual machine should be disabled

Description: Defender for Cloud has discovered that IP forwarding is enabled on some of your virtual machines. Enabling IP forwarding on a virtual machine's NIC allows the machine to receive traffic addressed to other destinations. IP forwarding is rarely required (e.g., when using the VM as a network virtual appliance), and therefore, this should be reviewed by the network security team. (Related policy: IP Forwarding on your virtual machine should be disabled).

Severity: Medium

Machines should have ports closed that might expose attack vectors

Description: Azure's terms of use prohibit the use of Azure services in ways that could damage, disable, overburden, or impair any Microsoft server or the network. This recommendation lists exposed ports that need to be closed for your continued security. It also illustrates the potential threat to each port. (No related policy)

Severity: High

Management ports of virtual machines should be protected with just-in-time network access control

Description: Defender for Cloud has identified some overly permissive inbound rules for management ports in your Network Security Group. Enable just-in-time access control to protect your VM from internet-based brute-force attacks. Learn more in Understanding just-in-time (JIT) VM access. (Related policy: Management ports of virtual machines should be protected with just-in-time network access control).

Severity: High

Management ports should be closed on your virtual machines

Description: Open remote management ports are exposing your VM to a high level of risk from Internet-based attacks. These attacks attempt to brute force credentials to gain admin access to the machine. (Related policy: Management ports should be closed on your virtual machines).

Severity: Medium

Non-internet-facing virtual machines should be protected with network security groups

Description: Protect your non-internet-facing virtual machine from potential threats by restricting access to it with a network security group (NSG). NSGs contain a list of Access Control List (ACL) rules that allow or deny network traffic to your VM from other instances, whether or not they're on the same subnet. Note that to keep your machine as secure as possible, the VM's access to the internet must be restricted and an NSG should be enabled on the subnet. (Related policy: Non-internet-facing virtual machines should be protected with network security groups).

Severity: Low

Secure transfer to storage accounts should be enabled

Description: Secure transfer is an option that forces your storage account to accept requests only from secure connections (HTTPS). Use of HTTPS ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking. (Related policy: Secure transfer to storage accounts should be enabled).

Severity: High

Subnets should be associated with a network security group

Description: Protect your subnet from potential threats by restricting access to it with a network security group (NSG). NSGs contain a list of Access Control List (ACL) rules that allow or deny network traffic to your subnet. When an NSG is associated with a subnet, the ACL rules apply to all the VM instances and integrated services in that subnet, but don't apply to internal traffic inside the subnet. To secure resources in the same subnet from one another, enable NSG directly on the resources as well. Note that the following subnet types will be listed as not applicable: GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet. (Related policy: Subnets should be associated with a Network Security Group).

Severity: Low

Virtual networks should be protected by Azure Firewall

Description: Some of your virtual networks aren't protected with a firewall. Use Azure Firewall to restrict access to your virtual networks and prevent potential threats. (Related policy: All Internet traffic should be routed via your deployed Azure Firewall).

Severity: Low

API management recommendations

API Management subscriptions should not be scoped to all APIs

Description & related policy: API Management subscriptions should be scoped to a product or an individual API instead of all APIs, which could result in excessive data exposure.

Severity: Medium

API Management calls to API backends should not bypass certificate thumbprint or name validation

Description & related policy: API Management should validate the backend server certificate for all API calls. Enable SSL certificate thumbprint and name validation to improve the API security.

Severity: Medium

API Management direct management endpoint should not be enabled

Description & related policy: The direct management REST API in Azure API Management bypasses Azure Resource Manager role-based access control, authorization, and throttling mechanisms, thus increasing the vulnerability of your service.

Severity: Low

API Management APIs should use only encrypted protocols

Description & related policy: APIs should be available only through encrypted protocols, like HTTPS or WSS. Avoid using unsecured protocols, such as HTTP or WS to ensure security of data in transit.

Severity: High

API Management secret named values should be stored in Azure Key Vault

Description & related policy: Named values are a collection of name and value pairs in each API Management service. Secret values can be stored either as encrypted text in API Management (custom secrets) or by referencing secrets in Azure Key Vault. Reference secret named values from Azure Key Vault to improve security of API Management and secrets. Azure Key Vault supports granular access management and secret rotation policies.

Severity: Medium

API Management should disable public network access to the service configuration endpoints

Description & related policy: To improve the security of API Management services, restrict connectivity to service configuration endpoints, like direct access management API, Git configuration management endpoint, or self-hosted gateways configuration endpoint.

Severity: Medium

API Management minimum API version should be set to 2019-12-01 or higher

Description & related policy: To prevent service secrets from being shared with read-only users, the minimum API version should be set to 2019-12-01 or higher.

Severity: Medium

API Management calls to API backends should be authenticated

Description & related policy: Calls from API Management to backends should use some form of authentication, whether via certificates or credentials. Does not apply to Service Fabric backends.

Severity: Medium

AI recommendations

Resource logs in Azure Machine Learning Workspaces should be enabled (Preview)

Description & related policy: Resource logs enable recreating activity trails to use for investigation purposes when a security incident occurs or when your network is compromised.

Severity: Medium

Azure Machine Learning Workspaces should disable public network access (Preview)

Description & related policy: Disabling public network access improves security by ensuring that the Machine Learning Workspaces aren't exposed on the public internet. You can control exposure of your workspaces by creating private endpoints instead. For more information, see Configure a private endpoint for an Azure Machine Learning workspace.

Severity: Medium

Azure Machine Learning Computes should be in a virtual network (Preview)

Description & related policy: Azure Virtual Networks provide enhanced security and isolation for your Azure Machine Learning Compute Clusters and Instances, as well as subnets, access control policies, and other features to further restrict access. When a compute is configured with a virtual network, it is not publicly addressable and can only be accessed from virtual machines and applications within the virtual network.

Severity: Medium

Azure Machine Learning Computes should have local authentication methods disabled (Preview)

Description & related policy: Disabling local authentication methods improves security by ensuring that Machine Learning Computes require Azure Active Directory identities exclusively for authentication. For more information, see Azure Policy Regulatory Compliance controls for Azure Machine Learning.

Severity: Medium

Azure Machine Learning compute instances should be recreated to get the latest software updates (Preview)

Description & related policy: Ensure Azure Machine Learning compute instances run on the latest available operating system. Security is improved and vulnerabilities reduced by running with the latest security patches. For more information, see Vulnerability management for Azure Machine Learning.

Severity: Medium

Resource logs in Azure Databricks Workspaces should be enabled (Preview)

Description & related policy: Resource logs enable recreating activity trails to use for investigation purposes when a security incident occurs or when your network is compromised.

Severity: Medium

Azure Databricks Workspaces should disable public network access (Preview)

Description & related policy: Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can control exposure of your resources by creating private endpoints instead. For more information, see Enable Azure Private Link.

Severity: Medium

Azure Databricks Clusters should disable public IP (Preview)

Description & related policy: Disabling public IP of clusters in Azure Databricks Workspaces improves security by ensuring that the clusters aren't exposed on the public internet. For more information, see Secure cluster connectivity.

Severity: Medium

Azure Databricks Workspaces should be in a virtual network (Preview)

Description & related policy: Azure Virtual Networks provide enhanced security and isolation for your Azure Databricks Workspaces, as well as subnets, access control policies, and other features to further restrict access. For more information, see Deploy Azure Databricks in your Azure virtual network.

Severity: Medium

Azure Databricks Workspaces should use private link (Preview)

Description & related policy: Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to Azure Databricks workspaces, you can reduce data leakage risks. For more information, see Create the workspace and private endpoints in the Azure portal UI.

Severity: Medium

Azure AI Services resources should restrict network access

Description: By restricting network access, you can ensure that only allowed networks can access the service. This can be achieved by configuring network rules so that only applications from allowed networks can access the Azure AI service resource.

Severity: Medium

Diagnostic logs in Azure AI services resources should be enabled

Description: Enable logs for Azure AI services resources. This enables you to recreate activity trails for investigation purposes, when a security incident occurs or your network is compromised.

Severity: Low

Deprecated recommendations

Access to App Services should be restricted

Description & related policy: Restrict access to your App Services by changing the networking configuration, to deny inbound traffic from ranges that are too broad. (Related policy: [Preview]: Access to App Services should be restricted).

Severity: High

The rules for web applications on IaaS NSGs should be hardened

Description & related policy: Harden the network security group (NSG) of your virtual machines that are running web applications, with NSG rules that are overly permissive with regard to web application ports. (Related policy: The NSGs rules for web applications on IaaS should be hardened).

Severity: High

Pod Security Policies should be defined to reduce the attack vector by removing unnecessary application privileges (Preview)

Description & related policy: Define Pod Security Policies to reduce the attack vector by removing unnecessary application privileges. It is recommended to configure pod security policies so pods can only access resources which they are allowed to access. (Related policy: [Preview]: Pod Security Policies should be defined on Kubernetes Services).

Severity: Medium

Install Azure Security Center for IoT security module to get more visibility into your IoT devices

Description & related policy: Install Azure Security Center for IoT security module to get more visibility into your IoT devices.

Severity: Low

Your machines should be restarted to apply system updates

Description & related policy: Restart your machines to apply the system updates and secure the machine from vulnerabilities. (Related policy: System updates should be installed on your machines).

Severity: Medium

Monitoring agent should be installed on your machines

Description & related policy: This action installs a monitoring agent on the selected virtual machines. Select a workspace for the agent to report to. (No related policy)

Severity: High

Java should be updated to the latest version for web apps

Description & related policy: Periodically, newer versions are released for Java software either due to security flaws or to include additional functionality. Using the latest Java version for web apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'Java version' is the latest, if used as a part of the Web app).

Severity: Medium

Python should be updated to the latest version for function apps

Description & related policy: Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest Python version for function apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'Python version' is the latest, if used as a part of the Function app).

Severity: Medium

Python should be updated to the latest version for web apps

Description & related policy: Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest Python version for web apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'Python version' is the latest, if used as a part of the Web app).

Severity: Medium

Java should be updated to the latest version for function apps

Description & related policy: Periodically, newer versions are released for Java software either due to security flaws or to include additional functionality. Using the latest Java version for function apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'Java version' is the latest, if used as a part of the Function app).

Severity: Medium

PHP should be updated to the latest version for web apps

Description & related policy: Periodically, newer versions are released for PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for web apps is recommended to benefit from security fixes, if any, and/or new functionalities of the latest version. (Related policy: Ensure that 'PHP version' is the latest, if used as a part of the WEB app).

Severity: Medium

Related content

• What are security policies, initiatives, and recommendations?
• Review your security recommendations