What is a recommended security practice what is a good source for finding such recommended practices?

This article lists the recommendations you might see in Microsoft Defender for Cloud. The recommendations shown in your environment depend on the resources you're protecting and your customized configuration.

Defender for Cloud's recommendations are based on the Azure Security Benchmark. Azure Security Benchmark is the Microsoft-authored, Azure-specific set of guidelines for security and compliance best practices based on common compliance frameworks. This widely respected benchmark builds on the 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 how to respond to these recommendations, see Remediate recommendations in Defender for Cloud.

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

Tip

If a recommendation's description says "No related policy", it's usually because that recommendation is dependent on a different recommendation and its policy. For example, the recommendation "Endpoint protection health failures should be remediated...", relies on the recommendation that checks whether an endpoint protection solution is even installed ("Endpoint protection solution should be installed..."). The underlying recommendation does have a policy. Limiting the policies to only the foundational recommendation simplifies policy management.

AppServices recommendations

There are 31 recommendations in this category.

Recommendation Description Severity
API App should only be accessible over HTTPS 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)
Medium
CORS should not allow every resource to access API Apps 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)
Low
CORS should not allow every resource to access Function Apps 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)
Low
CORS should not allow every resource to access Web Applications 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)
Low
Diagnostic logs in App Service should be enabled 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)

Medium
Ensure API app has Client Certificates Incoming client certificates set to On 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')
Medium
FTPS should be required in API apps Enable FTPS enforcement for enhanced security
(Related policy: FTPS only should be required in your API App)
High
FTPS should be required in function apps Enable FTPS enforcement for enhanced security
(Related policy: FTPS only should be required in your Function App)
High
FTPS should be required in web apps Enable FTPS enforcement for enhanced security
(Related policy: FTPS should be required in your Web App)
High
Function App should only be accessible over HTTPS 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)
Medium
Function apps should have Client Certificates (Incoming client certificates) enabled 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)
Medium
Java should be updated to the latest version for API apps 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)

Medium
Java should be updated to the latest version for function apps 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)

Medium
Java should be updated to the latest version for web apps 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)

Medium
Managed identity should be used in API apps 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)

Medium
Managed identity should be used in function apps 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)

Medium
Managed identity should be used in web apps 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)

Medium
Microsoft Defender for App Service should be enabled Microsoft Defender for App Service leverages the scale of the cloud, and the visibility that Azure has as a cloud provider, to monitor for common web app attacks.Microsoft Defender for App Service can discover attacks on your applications and identify emerging attacks.Important: Remediating this recommendation will result in charges for protecting your App Service plans. If you don't have any App Service plans in this subscription, no charges will be incurred.If you create any App Service plans on this subscription in the future, they will automatically be protected and charges will begin at that time.

Learn more in Protect your web apps and APIs.


(Related policy: Azure Defender for App Service should be enabled)
High
PHP should be updated to the latest version for API apps 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)

Medium
PHP should be updated to the latest version for web apps 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)

Medium
Python should be updated to the latest version for API apps 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)

Medium
Python should be updated to the latest version for function apps 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)

Medium
Python should be updated to the latest version for web apps 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)

Medium
Remote debugging should be turned off for API App 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)
Low
Remote debugging should be turned off for Function App 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)
Low
Remote debugging should be turned off for Web Applications 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)
Low
TLS should be updated to the latest version for API apps Upgrade to the latest TLS version
(Related policy: Latest TLS version should be used in your API App)
High
TLS should be updated to the latest version for function apps Upgrade to the latest TLS version
(Related policy: Latest TLS version should be used in your Function App)
High
TLS should be updated to the latest version for web apps Upgrade to the latest TLS version
(Related policy: Latest TLS version should be used in your Web App)
High
Web Application should only be accessible over HTTPS 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)
Medium
Web apps should request an SSL certificate for all incoming requests 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')

Medium

Compute recommendations

There are 58 recommendations in this category.

Recommendation Description Severity
Adaptive application controls for defining safe applications should be enabled on your machines 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)
High
Allowlist rules in your adaptive application control policy should be updated 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)
High
Authentication to Linux machines should require SSH keys 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)
Medium
Automation account variables should be encrypted It is important to enable encryption of Automation account variable assets when storing sensitive data.
(Related policy: Automation account variables should be encrypted)
High
Azure Backup should be enabled for virtual machines 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)

Low
Container hosts should be configured securely 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)
High
Diagnostic logs in Azure Stream Analytics should be enabled 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)
Low
Diagnostic logs in Batch accounts should be enabled 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)
Low
Diagnostic logs in Event Hub should be enabled 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 Hub should be enabled)
Low
Diagnostic logs in Kubernetes services should be enabled 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)
Low
Diagnostic logs in Logic Apps should be enabled 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 Hub, 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)
Low
Diagnostic logs in Search services should be enabled 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 Search services should be enabled)
Low
Diagnostic logs in Service Bus should be enabled 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)
Low
Diagnostic logs in Virtual Machine Scale Sets should be enabled 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)
Low
Endpoint protection health issues on machines should be resolved Resolve endpoint protection health issues on your virtual machines to protect them from latest threats and vulnerabilities. See the documentation for the endpoint protection solutions supported by Defender for Cloud and the endpoint protection assessments.
(No related policy)
Medium
Endpoint protection health issues on machines should be resolved For full Defender for Cloud protection, resolve monitoring agent issues on your machines by following the instructions in the Troubleshooting guide.
(Related policy: Monitor missing Endpoint Protection in Azure Security Center)
Medium
Endpoint protection health issues on virtual machine scale sets should be resolved 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)
Low
Endpoint protection should be installed on machines To protect machines from threats and vulnerabilities, install a supported endpoint protection solution.
Learn more about how endpoint protection for machines is evaluated in Endpoint protection assessment and recommendations in Microsoft Defender for Cloud.
(No related policy)
High
Endpoint protection should be installed on machines Install an endpoint protection solution on your Windows and Linux machines, to protect them from threats and vulnerabilities.
(No related policy)
Medium
Endpoint protection should be installed on virtual machine scale sets 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)
High
File integrity monitoring should be enabled on machines 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)
High
Guest Attestation extension should be installed on supported Linux virtual machine scale sets 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)
Low
Guest Attestation extension should be installed on supported Linux virtual machines 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)
Low
Guest Attestation extension should be installed on supported Windows virtual machine scale sets 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)
Low
Guest Attestation extension should be installed on supported Windows virtual machines 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)
Low
Guest Configuration extension should be installed on machines 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'. Learn more.
(Related policy: Virtual machines should have the Guest Configuration extension)
Medium
Install endpoint protection solution on virtual machines 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)
High
Linux virtual machines should enforce kernel module signature validation 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)
Low
Linux virtual machines should use only signed and trusted boot components 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 allow list or remove the identified components.
(No related policy)
Low
Linux virtual machines should use Secure Boot 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)
Low
Log Analytics agent should be installed on Linux-based Azure Arc-enabled machines 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)
High
Log Analytics agent should be installed on virtual machine scale sets 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)
High
Log Analytics agent should be installed on virtual machines 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)
High
Log Analytics agent should be installed on Windows-based Azure Arc-enabled machines 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)
High
Machines should be configured securely 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)
Low
Machines should be restarted to apply security configuration updates 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)
Low
Machines should have a vulnerability assessment solution 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)
Medium
Machines should have vulnerability findings resolved 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)
Low
Management ports of virtual machines should be protected with just-in-time network access control 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)
High
Microsoft Defender for servers should be enabled 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)
High
Microsoft Defender for servers should be enabled on workspaces 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)
Medium
Running container images should have vulnerability findings resolved Container image vulnerability assessment scans container images running on your Kubernetes clusters 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.
(No related policy)
High
Secure Boot should be enabled on supported Windows virtual machines 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)
Low
Service Fabric clusters should have the ClusterProtectionLevel property set to EncryptAndSign 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)
High
Service Fabric clusters should only use Azure Active Directory for client authentication 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)
High
System updates on virtual machine scale sets should be installed 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)
High
System updates should be installed on your machines 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)
High
System updates should be installed on your machines (powered by Update Center) 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)
High
Virtual machine scale sets should be configured securely 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)
High
Virtual machines guest attestation status should be healthy 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)

Medium
Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity 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)
Medium
Virtual machines should be migrated to new Azure Resource Manager resources 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)
High
Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources 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)
High
vTPM should be enabled on supported virtual machines 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)
Low
Vulnerabilities in security configuration on your Linux machines should be remediated (powered by Guest Configuration) 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)
Low
Vulnerabilities in security configuration on your Windows machines should be remediated (powered by Guest Configuration) Remediate vulnerabilities in security configuration on your Windows machines to protect them from attacks.
(No related policy)
Low
Windows Defender Exploit Guard should be enabled on machines 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)
Medium
Windows web servers should be configured to use secure communication protocols 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)
High

Container recommendations

There are 27 recommendations in this category.

Recommendation Description Severity
[Enable if required] Container registries should be encrypted with a customer-managed key (CMK) 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))
Low
Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed 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)
High
Azure Arc-enabled Kubernetes clusters should have the Defender extension installed 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. Learn more.
(No related policy)
High
Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed 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)
High
Container CPU and memory limits should be enforced 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)
Medium
Container images should be deployed from trusted registries only 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)
High
Container registries should not allow unrestricted network access 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)
Medium
Container registries should use private link 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)
Medium
Container registry images should have vulnerability findings resolved 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)
High
Container with privilege escalation should be avoided 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)

Medium
Containers sharing sensitive host namespaces should be avoided 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)
Medium
Containers should only use allowed AppArmor profiles 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)

High
Immutable (read-only) root filesystem should be enforced for containers 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)
Medium
Kubernetes API server should be configured with restricted access 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 inCreate a private Azure Kubernetes Service cluster.
(Related policy: Authorized IP ranges should be defined on Kubernetes Services)
High
Kubernetes clusters should be accessible only over HTTPS 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)
High
Kubernetes clusters should disable automounting API credentials 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)
High
Kubernetes clusters should gate deployment of vulnerable images Protect your Kubernetes clusters and container workloads from potential threats by restricting deployment of container images with vulnerable software components. Use Defender for Cloud's CI/CD scanning and Microsoft Defender for container registries to identify and patch vulnerabilities prior to deployment.Evaluation prerequisite: Azure policy add-on/extension and the Defender profile/extension.Applicable only for private preview customers.

(No related policy)

High
Kubernetes clusters should not grant CAPSYSADMIN security capabilities 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)
High
Kubernetes clusters should not use the default namespace 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)
Low
Least privileged Linux capabilities should be enforced for containers 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)
Medium
Microsoft Defender for Containers should be enabled Microsoft Defender for Containers provides hardening, vulnerability assessment and run-time protections for your Azure, hybrid, and multi-cloud 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 will automatically be protected and charges will begin at that time.

Learn more in Introduction to Microsoft Defender for Containers.


(No related policy)
High
Privileged containers should be avoided 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)
Medium
Role-Based Access Control should be used on Kubernetes Services 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. For more information, see Azure role-based access control.
(Related policy: Role-Based Access Control (RBAC) should be used on Kubernetes Services)
High
Running containers as root user should be avoided 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)
High
Services should listen on allowed ports only 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)
Medium
Usage of host networking and ports should be restricted 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)
Medium
Usage of pod HostPath volume mounts should be restricted to a known list to restrict node access from compromised containers 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)
Medium

Data recommendations

There are 78 recommendations in this category.

Recommendation Description Severity
[Enable if required] Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest 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)
Low
[Enable if required] Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK) 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))
Low
[Enable if required] Cognitive Services accounts should enable data encryption with a customer-managed key (CMK) 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))
Low
[Enable if required] MySQL servers should use customer-managed keys to encrypt data at rest 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)

Low
[Enable if required] PostgreSQL servers should use customer-managed keys to encrypt data at rest 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)

Low
[Enable if required] SQL managed instances should use customer-managed keys to encrypt data at rest 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)

Low
[Enable if required] SQL servers should use customer-managed keys to encrypt data at rest 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)

Low
[Enable if required] Storage accounts should use customer-managed key (CMK) for encryption 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)

Low
All advanced threat protection types should be enabled in SQL managed instance advanced data security settings 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)
Medium
All advanced threat protection types should be enabled in SQL server advanced data security settings 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)
Medium
API Management services should use a virtual network 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)
Medium
App Configuration should use private link 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)
Medium
Audit retention for SQL servers should be set to at least 90 days 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.)
Low
Auditing on SQL server should be enabled 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)
Low
Auto provisioning of the Log Analytics agent should be enabled on subscriptions 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)
Low
Azure Cache for Redis should reside within a virtual network 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)
Medium
Azure Cosmos DB accounts should have firewall rules 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)
Medium
Azure DevOps security posture findings should be resolved Defender for DevOps security posture checks helps you keep your ADO artifacts such as various org/project settings, build/release configurations, service connections, agent pools, etc., configured securely.
(No related policy)
Medium
Azure Event Grid domains should use private link 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)
Medium
Azure Event Grid topics should use private link 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)
Medium
Azure Kubernetes Service clusters should have Defender profile enabled 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)
High
Azure Machine Learning workspaces should use private link 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)
Medium
Azure SignalR Service should use private link 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)
Medium
Azure Spring Cloud should use network injection 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)
Medium
Code repositories should have code scanning findings resolved Defender for DevOps has found vulnerabilities in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities.
(No related policy)
Medium
Code repositories should have Dependabot scanning findings resolved Defender for DevOps has found vulnerabilities in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities.
(No related policy)
Medium
Code repositories should have infrastructure as code scanning findings resolved Defender for DevOps has found infrastructure as code security configuration issues in repositories. The issues shown below have been detected in template files. To improve the security posture of the related cloud resources, it is highly recommended to remediate these issues.
(No related policy)
Medium
Code repositories should have secret scanning findings resolved Defender for DevOps has found a secret in code repositories. This should be remediated immediately to prevent a security breach. Secrets found in repositories can be leaked or discovered by adversaries, leading to compromise of an application or service. For Azure DevOps, the Microsoft Security DevOps CredScan tool only scans builds on which it has been configured to run. Therefore, results may not reflect the complete status of secrets in your repositories.
(No related policy)
High
Cognitive Services accounts should enable data encryption 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)
Low
Cognitive Services accounts should restrict network access Network access to Cognitive Services accounts should be restricted. Configure network rules so only applications from allowed networks can access the Cognitive Services 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: Cognitive Services accounts should restrict network access)
Medium
Cognitive Services accounts should use customer owned storage or enable data encryption 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.)
Low
Diagnostic logs in Azure Data Lake Store should be enabled 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)
Low
Diagnostic logs in Data Lake Analytics should be enabled 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)
Low
Email notification for high severity alerts should be enabled 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)
Low
Email notification to subscription owner for high severity alerts should be enabled 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)
Medium
Enforce SSL connection should be enabled for MySQL database servers 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)

Medium
Enforce SSL connection should be enabled for PostgreSQL database servers 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)

Medium
Function apps should have vulnerability findings resolved 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)
High
Geo-redundant backup should be enabled for Azure Database for MariaDB 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)

Low
Geo-redundant backup should be enabled for Azure Database for MySQL 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)

Low
Geo-redundant backup should be enabled for Azure Database for PostgreSQL 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)

Low
GitHub repositories should have Code scanning enabled 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)
Medium
GitHub repositories should have Dependabot scanning enabled 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)
Medium
GitHub repositories should have Secret scanning enabled 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)
High
Microsoft Defender for Azure SQL Database servers should be enabled 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)
High
Microsoft Defender for DNS should be enabled 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: https://azure.microsoft.com/services/defender-for-cloud/#pricing.
(No related policy)
High
Microsoft Defender for open-source relational databases should be enabled 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)

High
Microsoft Defender for Resource Manager should be enabled 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: https://azure.microsoft.com/services/defender-for-cloud/#pricing.
(No related policy)
High
Microsoft Defender for SQL on machines should be enabled on workspaces 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)
Medium
Microsoft Defender for SQL servers on machines should be enabled 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)
High
Microsoft Defender for SQL should be enabled for unprotected Azure SQL servers 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)
High
Microsoft Defender for SQL should be enabled for unprotected SQL Managed Instances 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)
High
Microsoft Defender for Storage should be enabled Microsoft Defender for storage detects unusual and potentially harmful attempts to access or exploit storage accounts.
Important: Protections from this plan are charged as shown on the Defender plans page. If you don't have any Azure Storage accounts in this subscription, you won't be charged. If you later create Azure Storage accounts 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 Storage.
(Related policy: Azure Defender for Storage should be enabled)
High
Network Watcher should be enabled 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)
Low
Over-provisioned identities in subscriptions should be investigated to reduce the Permission Creep Index (PCI) Over-provisioned identities in subscription should be investigated to reduce the Permission Creep Index (PCI) and to safeguard your infrastructure. Reduce the PCI by removing the unused high risk permission assignments. High PCI reflects risk associated with the identities with permissions that exceed their normal or required usage
(No related policy)
Medium
Private endpoint connections on Azure SQL Database should be enabled 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)
Medium
Private endpoint should be enabled for MariaDB servers 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)

Medium
Private endpoint should be enabled for MySQL servers 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)

Medium
Private endpoint should be enabled for PostgreSQL servers 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)

Medium
Public network access on Azure SQL Database should be disabled 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)
Medium
Public network access should be disabled for Cognitive Services accounts This policy audits any Cognitive Services account in your environment with public network access enabled. Public network access should be disabled so that only connections from private endpoints are allowed.
(Related policy: Public network access should be disabled for Cognitive Services accounts)
Medium
Public network access should be disabled for MariaDB servers 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)
Medium
Public network access should be disabled for MySQL servers 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)
Medium
Public network access should be disabled for PostgreSQL servers 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)
Medium
Redis Cache should allow access only via SSL 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)
High
SQL databases should have vulnerability findings resolved 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)
High
SQL managed instances should have vulnerability assessment configured Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities.
(Related policy: Vulnerability assessment should be enabled on SQL Managed Instance)
High
SQL servers on machines should have vulnerability findings resolved 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)
High
SQL servers should have an Azure Active Directory administrator provisioned 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)
High
SQL servers should have vulnerability assessment configured Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities.
(Related policy: Vulnerability assessment should be enabled on your SQL servers)
High
Storage account should use a private link connection Private links enforce secure communication, by providing private connectivity to the storage account
(Related policy: Storage account should use a private link connection)
Medium
Storage accounts should be migrated to new Azure Resource Manager resources 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)
Low
Storage accounts should restrict network access using virtual network rules 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)
Medium
Subscriptions should have a contact email address for security issues 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)
Low
Transparent Data Encryption on SQL databases should be enabled Enable transparent data encryption to protect data-at-rest and meet compliance requirements
(Related policy: Transparent Data Encryption on SQL databases should be enabled)
Low
VM Image Builder templates should use private link 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 may directly expose resources to the internet and increase the potential attack surface.
(Related policy: VM Image Builder templates should use private link)
Medium
Web Application Firewall (WAF) should be enabled for Application Gateway 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, IP address ranges, and other http(s) parameters via custom rules.
(Related policy: Web Application Firewall (WAF) should be enabled for Application Gateway)
Low
Web Application Firewall (WAF) should be enabled for Azure Front Door Service service 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, 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)
Low

IdentityAndAccess recommendations

There are 29 recommendations in this category.

Recommendation Description Severity
A maximum of 3 owners should be designated for subscriptions 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)
High
Accounts with owner permissions on Azure resources should be MFA enabled 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 Multi-Factor 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). Multi-factor authentication is a process by which users are prompted, during the sign-in process, for an additional form of identification. For example, a code may be sent to their cellphone, or they may 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 multi-factor authentication (MFA) enforcement on your subscriptions
(No related policy)
High
Accounts with read permissions on Azure resources should be MFA enabled 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 Multi-Factor 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). Multi-factor authentication is a process by which users are prompted, during the sign-in process, for an additional form of identification. For example, a code may be sent to their cellphone, or they may 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: Manage multi-factor authentication (MFA) enforcement on your subscriptions
(No related policy)
High
Accounts with write permissions on Azure resources should be MFA enabled 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 Multi-Factor 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). Multi-factor authentication is a process by which users are prompted, during the sign-in process, for an additional form of identification. For example, a code may be sent to their cellphone, or they may 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 multi-factor authentication (MFA) enforcement on your subscriptions
(No related policy)
High
Azure Cosmos DB accounts should use Azure Active Directory as the only authentication method 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)
Medium
Blocked accounts with owner permissions on Azure resources should be removed 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)
High
Blocked accounts with read and write permissions on Azure resources should be remove 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)
High
Deprecated accounts should be removed from subscriptions 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)

High
Deprecated accounts with owner permissions should be removed from subscriptions 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)

High
Diagnostic logs in Key Vault should be enabled 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)
Low
External accounts with owner permissions should be removed from subscriptions 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)
High
External accounts with read permissions should be removed from subscriptions 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)
High
External accounts with write permissions should be removed from subscriptions 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)
High
Firewall should be enabled on Key Vault 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)
Medium
Guest accounts with owner permissions on Azure resources should be removed 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 are not 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)
High
Guest accounts with read permissions on Azure resources should be removed 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 are not 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)
High
Guest accounts with write permissions on Azure resources should be removed 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 are not 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)
High
Key Vault keys should have an expiration date 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 is a recommended security practice to set expiration dates on cryptographic keys.
(Related policy: Key Vault keys should have an expiration date)
High
Key Vault secrets should have an expiration date 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 is a recommended security practice to set expiration dates on secrets.
(Related policy: Key Vault secrets should have an expiration date)
High
Key vaults should have purge protection enabled 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)
Medium
Key vaults should have soft delete enabled 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)
High
MFA should be enabled on accounts with owner permissions on subscriptions Multi-Factor 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)
High
MFA should be enabled on accounts with read permissions on subscriptions Multi-Factor 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)
High
MFA should be enabled on accounts with write permissions on subscriptions Multi-Factor 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)
High
Microsoft Defender for Key Vault should be enabled Microsoft Defender for Cloud includes Microsoft Defender for Key Vault, providing an additional layer of security intelligence.Microsoft Defender for Key Vault detects unusual and potentially harmful attempts to access or exploit Key Vault accounts.

Important: Protections from this plan are charged as shown on the Defender plans page. If you don't have any key vaults in this subscription, you won't be charged. If you later create key vaults 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 Key Vault.
(Related policy: Azure Defender for Key Vault should be enabled)
High
Private endpoint should be configured for Key Vault 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)
Medium
Storage account public access should be disallowed 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)
Medium
There should be more than one owner assigned to subscriptions 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)
High
Validity period of certificates stored in Azure Key Vault should not exceed 12 months Ensure your certificates do not have a validity period that exceeds 12 months.
(Related policy: Certificates should have the specified maximum validity period)
Medium

IoT recommendations

There are 4 recommendations in this category.

Recommendation Description Severity
Default IP Filter Policy should be Deny IP Filter Configuration should have rules defined for allowed traffic and should deny all other traffic by default
(No related policy)
Medium
Diagnostic logs in IoT Hub should be enabled 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)
Low
Identical Authentication Credentials 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)
High
IP Filter rule large IP range 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)
Medium

Networking recommendations

There are 13 recommendations in this category.

Recommendation Description Severity
Access to storage accounts with firewall and virtual network configurations should be restricted 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-premise 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)
Low
Adaptive network hardening recommendations should be applied on internet facing virtual machines Defender for Cloud has analyzed the internet traffic communication patterns of the virtual machines listed below, and determined that the existing rules in the NSGs associated to them are overly-permissive, resulting in an increased potential attack surface.
This typically occurs when this IP address doesn't communicate regularly with this resource. Alternatively, the IP address has been flagged as malicious by Defender for Cloud's threat intelligence sources. Learn more in Improve your network security posture with adaptive network hardening.
(Related policy: Adaptive network hardening recommendations should be applied on internet facing virtual machines)
High
All network ports should be restricted on network security groups associated to your virtual machine 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)
High
Azure DDoS Protection Standard should be enabled 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)
Medium
Internet-facing virtual machines should be protected with network security groups 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)

High
IP forwarding on your virtual machine should be disabled 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)
Medium
Machines should have ports closed that might expose attack vectors 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)
High
Management ports of virtual machines should be protected with just-in-time network access control 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)
High
Management ports should be closed on your virtual machines 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)
Medium
Non-internet-facing virtual machines should be protected with network security groups 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)

Low
Secure transfer to storage accounts should be enabled 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)
High
Subnets should be associated with a network security group 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)

Low
Virtual networks should be protected by Azure Firewall 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. Learn more about Azure Firewall.
(Related policy: All Internet traffic should be routed via your deployed Azure Firewall)
Low

Deprecated recommendations

Recommendation Description & related policy Severity
Access to App Services should be restricted 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)
High
The rules for web applications on IaaS NSGs should be hardened 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)
High
Pod Security Policies should be defined to reduce the attack vector by removing unnecessary application privileges (Preview) 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)
Medium
Install Azure Security Center for IoT security module to get more visibility into your IoT devices Install Azure Security Center for IoT security module to get more visibility into your IoT devices. Low
Your machines should be restarted to apply system updates Restart your machines to apply the system updates and secure the machine from vulnerabilities. (Related policy: System updates should be installed on your machines) Medium
Monitoring agent should be installed on your machines This action installs a monitoring agent on the selected virtual machines. Select a workspace for the agent to report to. (No related policy) High

Next steps

To learn more about recommendations, see the following: