Azure security baseline for Container Registry

This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Container Registry. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Container Registry.

Note

Controls not applicable to Container Registry, and those for which the global guidance is recommended verbatim, have been excluded. To see how Container Registry completely maps to the Azure Security Benchmark, see the full Container Registry security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

NS-1: Implement security for internal traffic

Guidance: Limit access to your private Azure container registry from an Azure virtual network to ensure that only approved resources can access the registry. For cross-premises scenarios, you can also configure firewall rules to allow​ registry access only from specific IP addresses.​ From behind a firewall, configure firewall access rules and service tags to access your container registry.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerRegistry:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
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. Audit, Deny, Disabled 1.1.0

NS-2: Connect private networks together

Guidance: When you enable private endpoint for your Azure Container Registry resources you'll need to establish private network connectivity. Use Azure ExpressRoute or Azure Virtual Private Network (VPN) to create private connections between Azure datacenters which host your container registries and on-premises infrastructure in a colocation environment. To connect two or more virtual networks in Azure, use virtual network peering.

Network traffic between peered virtual networks is private and is kept on the Azure backbone network.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerRegistry:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
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. Audit, Disabled 1.0.1

NS-3: Establish private network access to Azure services

Guidance: Use Azure Private Link to enable private access to Container Registry from your virtual networks without crossing the internet.

Private access is another defense in-depth measure to the authentication and traffic security offered by Azure services.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerRegistry:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
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. Audit, Disabled 1.0.1

NS-4: Protect applications and services from external network attacks

Guidance: Protect your Azure Container Registry resources against attacks from external networks. Configuring them with Private Link to prevent external network access to your Container Registries. In situations where virtual networks and Private Link cannot be used, Container Registry allows specifying firewall access rules to limit access to certain networks.

Azure Container Registry isn't intended to host web applications. It's a managed, private Docker registry service. Other network-based application security like web application firewalls, or DDoS do not apply to this service.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

NS-6: Simplify network security rules

Guidance: For resources that need access to your container registry, use virtual network service tags for the Azure Container Registry service to define network access controls on Network Security Groups or Azure Firewall. You can use service tags in place of specific IP addresses when creating security rules.

By specifying the service tag name "AzureContainerRegistry" in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

NS-7: Secure Domain Name Service (DNS)

Guidance: Container Registry doesn't expose its underlying DNS configurations. These settings are maintained by Microsoft.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: None

Identity Management

For more information, see the Azure Security Benchmark: Identity Management.

IM-1: Standardize Azure Active Directory as the central identity and authentication system

Guidance: Container Registry uses Azure Active Directory (Azure AD) as the default identity and access management service. Standardize Azure AD to govern your organization's identity and access management in:

  • Microsoft Cloud resources. Resources include: - The Azure portal

    • Azure Storage
    • Azure Linux and Windows virtual machines
    • Azure Key Vault
    • Platform-as-a-service (PaaS)
    • Software-as-a-service (SaaS) applications
  • Your organization's resources, such as applications on Azure or your corporate network resources.

Securing Azure AD should be a high priority in your organization's cloud security practice. provides an identity secure score to help you compare your identity security posture to Microsoft's best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations, and to make improvements in your security posture.

The Azure Container Registry service supports a set of built-in Azure roles that provide different levels of permissions to an Azure container registry. Use Azure role-based access control (Azure RBAC) to assign specific permissions to users, service principals, or other identities that need to interact with a registry. For example, use it to assign permissions to pull or push container images.

There are several ways to authenticate with an Azure container registry. Each is applicable to one or more registry usage scenarios.

Recommended ways include:

  • Authenticate to a registry directly via individual login
  • Applications and container orchestrators can perform unattended, or "headless," authentication by using an Azure AD service principal
  • If you use a container registry with Azure Kubernetes Service (AKS) or another Kubernetes cluster, see Scenarios to authenticate with Azure Container Registry from Kubernetes.

For more information, see:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

IM-2: Manage application identities securely and automatically

Guidance: Container Registry supports multiple ways to authenticate against a customer registry:

  • Managed identities (preferred) - Customers may authenticate against their Container Registry using system identities, or user-assigned identities.- Azure AD applications - Customers may use an Azure AD application/service principal to authenticate to their Container Registry.

For more information, see:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

IM-3: Use Azure AD single sign-on (SSO) for application access

Guidance: Container Registry uses Azure AD to provide identity and access management to Azure resources, cloud applications, and on-premises applications. Identities include enterprise identities like employees, and external identities like partners, vendors, and suppliers. Azure AD enables single sign-on (SSO) to manage and secure access to your organization's on-premises and cloud data and resources.

Connect all your users, applications, and devices to Azure AD. Azure AD offers seamless, secure access, and greater visibility and control.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

IM-7: Eliminate unintended credential exposure

Guidance: Container Registry allows customers to deploy resource configurations as Azure Resource Manager templates that may potentially contain identities and secrets. We recommend you implement Credential Scanner to identify credentials within code or configurations. Credential Scanner will also encourage moving discovered credentials to more secure locations like Azure Key Vault.

For GitHub, you can use the native secret scanning feature to identify credentials or other forms of secrets within the code.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Privileged Access

For more information, see the Azure Security Benchmark: Privileged Access.

PA-1: Protect and limit highly privileged users

Guidance: The most critical built-in roles for Azure AD are the Global Administrator and the Privileged Role Administrator. Users assigned to these two roles can delegate administrator roles:

  • Global Administrator/Company Administrator: Users with this role have access to all administrative features in Azure AD, and services that use Azure AD identities.

  • Privileged Role Administrator: Users with this role can manage role assignments in Azure AD, and in Azure AD Privileged Identity Management (PIM). Also, this role allows management of all aspects of PIM and administrative units.

Note: You might have other critical roles that need to be governed if you use custom roles with certain privileged permissions assigned. You might also want to apply similar controls to the administrator account of critical business assets.

Limit the number of highly privileged accounts or roles and protect these accounts at an elevated level. Users with this privilege can directly or indirectly read and modify every resource in your Azure environment.

You can enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD PIM. JIT grants temporary permissions to do privileged tasks only when users need it. PIM can also generate security alerts when there's suspicious or unsafe activity in your Azure AD organization.

Create standard operating procedures around the use of dedicated administrative accounts.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-3: Review and reconcile user access regularly

Guidance: Container Registry uses Azure AD accounts to manage its resources and review user accounts. Access assignments regularly to make sure the accounts and their access are valid. You can use Azure AD access reviews to review group memberships, enterprise application access, and role assignments. Azure AD reporting can provide logs to help discover stale accounts.You can also create access review report workflows in Azure AD PIM to ease the review process.

You can also configure Azure AD PIM to alert you when there are too many administrator accounts. PIM can identify administrator accounts that are stale or improperly configured.

Note: Some Azure services support local users and roles that aren't managed through Azure AD. Manage these users separately.

The Azure Container Registry service supports a set of built-in Azure roles that provide different levels of permissions to an Azure container registry. Use Azure RBAC to assign specific permissions to users, service principals, or other identities that need to interact with a registry. For example, use it to assign permissions to pull or push container images.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critically important for the security of sensitive roles like administrator, developer, and critical service operator. Use highly secured user workstations and/or Azure Bastion for administrative tasks. Use Azure AD, Microsoft Defender Advanced Threat Protection (ATP), and/or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. The secured workstations can be centrally managed to enforce secured configuration like:

  • Strong authentication

  • Software and hardware baselines

  • Restricted logical and network access.

For more information, see:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-7: Follow just enough administration (least privilege principle)

Guidance: Container Registry integrates with Azure RBAC to manage its resources. With RBAC, you manage Azure resource access through role assignments. You can assign roles to users, groups, service principals, and managed identities. Certain resources have pre-defined, built-in roles. You can inventory or query these roles through tools like Azure CLI, Azure PowerShell, or the Azure portal. Limit the privileges you assign to resources through Azure RBAC to what the roles require. This practice complements the JIT approach of Azure AD PIM. Review roles and assignments periodically.

Use built-in roles to allocate permissions, and only create custom roles when required. The Azure Container Registry service supports a set of built-in Azure roles that provide different levels of permissions to an Azure container registry. Use Azure RBAC to assign specific permissions to users, service principals, or other identities that need to interact with a registry. For example, use it to assign permissions to pull or push container images.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-8: Choose approval process for Microsoft support

Guidance: In support scenarios where Microsoft needs to access customer data, Container Registry supports Customer Lockbox. It provides an interface for you to review and approve or reject customer data access requests.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

DP-2: Protect sensitive data

Guidance: Protect sensitive data by restricting access using Azure RBAC, network-based access controls, and specific controls in Azure services like encryption. To ensure consistent access control, align all types of access control with your enterprise segmentation strategy. Inform the enterprise segmentation strategy about the location of sensitive or business critical data and systems. For the underlying platform (managed by Microsoft), Microsoft treats all customer content as sensitive and guards against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented some default data protection controls and capabilities.

By creating tokens, a registry owner can provide users or services with scoped, time-limited access to repositories to pull or push images or perform other actions. A token provides more fine-grained permissions than other registry authentication options, which scope permissions to an entire registry.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

DP-3: Monitor for unauthorized transfer of sensitive data

Guidance: Turn on the audit logs feature for Azure Container Registry and monitor who does push and pull operations on the registry. Set alerts and forward these logs to your SIEM. Set up triggers for activity that is suspicious or forms an irregular pattern of access.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

DP-4: Encrypt sensitive information in transit

Guidance: To complement access controls, protect data in transit against "out of band" attacks (like traffic capture) using encryption to ensure that attackers can't easily read or modify the data.

Azure Container Registry enforces data encryption in transit to the service and requires all secure connections from servers and applications to use TLS 1.2. Enable TLS 1.2 by using any recent docker client (version 18.03.0 or later). Support for TLS 1.0 and 1.1 is retired.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

DP-5: Encrypt sensitive data at rest

Guidance: To complement access controls, Container Registry encrypts data at rest to protect against "out of band" attacks (like accessing underlying storage) using encryption. It helps ensure that attackers can't easily read or modify the data.

Azure provides encryption for data at rest by default. For highly sensitive data, you have options to implement more encryption at rest on all Azure resources where available. Azure manages your encryption keys by default, but Azure also provides options to manage your own keys (customer-managed keys) for certain Azure services to meet regulatory requirements.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerRegistry:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Container registries should be encrypted with a customer-managed key 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 are commonly required to meet regulatory compliance standards. Customer-managed keys 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 at https://aka.ms/acr/CMK. Audit, Deny, Disabled 1.1.2

Asset Management

For more information, see the Azure Security Benchmark: Asset Management.

AM-1: Ensure security team has visibility into risks for assets

Guidance: Make sure security teams are granted Security Reader permissions in your Azure tenant and subscriptions, so they can monitor for security risks by using Microsoft Defender for Cloud.

Monitoring for security risks could be the responsibility of a central security team or a local team, depending on how you structure responsibilities. Always aggregate security insights and risks centrally within an organization.

You can apply Security Reader permissions broadly to an entire tenant's Root Management Group, or scope permissions to specific management groups or subscriptions.

Note: Getting visibility into workloads and services might require more permissions.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

AM-2: Ensure security team has access to asset inventory and metadata

Guidance: Make sure that security teams have access to a continuously updated inventory of assets on Azure, like Container Registry. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks, and as an input to continuous security improvements. Create an Azure AD group to contain your organization's authorized security team and assign it read access to all Container Registry resources. You can simplify the process with a single high-level role assignment in your subscription.

Apply tags to your Azure resources, resource groups, and subscriptions to logically organize them into a taxonomy. Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production.

Use Azure Virtual Machine Inventory to automate the collection of information about software on virtual machines. Software Name, Version, Publisher, and Refresh Time are available from the Azure portal. To get access to install dates and other information, enable guest-level diagnostics and bring the Windows Event Logs into a Log Analytics Workspace.

Use Microsoft Defender for Cloud Adaptive Application Controls to specify which file types a rule might or might not apply to.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

AM-3: Use only approved Azure services

Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules to trigger alerts when a non-approved service is detected.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Logging and Threat Detection

For more information, see the Azure Security Benchmark: Logging and Threat Detection.

LT-1: Enable threat detection for Azure resources

Guidance: Use the Microsoft Defender for Cloud built-in threat detection capability and enable Microsoft Defender for your Container Registry resources. Microsoft Defender for Container Registry provides another layer of security intelligence. It detects unusual and potentially harmful attempts to access or exploit your Container Registry resources.

Forward any logs from Container Registry to your SIEM, which can be used to set up custom threat detections. Make sure you're monitoring different types of Azure assets for potential threats and anomalies. Focus on getting high-quality alerts to reduce false positives for analysts to sort through. Alerts can be sourced from log data, agents, or other data.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-2: Enable threat detection for Azure identity and access management

Guidance: Azure AD provides the following user logs. You can view the logs in Azure AD reporting. You can integrate with Azure Monitor, Microsoft Sentinel, or other SIEM and monitoring tools for sophisticated monitoring and analytics use cases.

  • Sign-ins - The sign-ins report provides information about the usage of managed applications and user sign-in activities.- Audit logs - Provides traceability through logs for all changes made by various Azure AD features. Audit logs include changes made to any resource within Azure AD. Changes include adding or removing users, apps, groups, roles, and policies.
  • Risky sign-ins - An indicator for sign-in attempts by someone who might not be the legitimate owner of a user account.
  • Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.Microsoft Defender for Cloud can also alert you about certain suspicious activities like an excessive number of failed authentication attempts. Deprecated accounts in the subscription can also trigger alerts. Microsoft Defender for Cloud can also alert you about suspicious activities like an excessive number of failed authentication attempts, or about deprecated accounts.

In addition to basic security hygiene monitoring, Microsoft Defender for Cloud's Threat Protection module can collect more in-depth security alerts from:

  • Individual Azure compute resources like VMs, containers, and app service
  • Data resources like Azure SQL Database and Azure Storage
  • Azure service layers

This capability gives you visibility into account anomalies in individual resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-3: Enable logging for Azure network activities

Guidance: Enable these logs:

  • Network Security Group (NSG) resource logs

  • NSG flow logs

  • Azure Firewall logs

Collect the logs for security analysis. Use them to support incident investigations, threat hunting, and security alert generation. You can send the flow logs to an Azure Monitor Log Analytics workspace and then use Traffic Analytics to provide insights.

Container Registry doesn't produce or process DNS query logs.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-4: Enable logging for Azure resources

Guidance: Activity logs are available automatically. The logs contain all PUT, POST, and DELETE, but not GET, operations for Container Registry resources. You can use activity logs to find errors when troubleshooting, or to monitor how users modified resources.

Enable Azure resource logs for Container Registry. You can use Microsoft Defender for Cloud and Azure Policy to enable resource logs and log data collecting. These logs can be critical for investigating security incidents and for forensic exercises.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-6: Configure log storage retention

Guidance: For storage accounts or Log Analytics workspaces that store Container Registry logs, set a log retention period that meets your organization's compliance regulations.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-7: Use approved time synchronization sources

Guidance: Azure Container Registry doesn't support configuring your own time synchronization sources. The Container Registry service relies on Microsoft time synchronization sources, and isn't exposed to customers for configuration.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: None

Posture and Vulnerability Management

For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.

PV-1: Establish secure configurations for Azure services

Guidance: You can use Azure Blueprints to automate deployment and configuration of services and application environments in a single blueprint definition. Environments for:

  • Azure Resources Manager templates

  • Azure RBAC controls and policies

Use Azure Blueprints to automate deployment and configuration of Azure Container Registry resource including:

  • Azure Resources Manager templates
  • Azure RBAC role assignments
  • Azure Policy assignments

Use Azure Policy or Microsoft Defender for Cloud to maintain security configurations for all Azure Container Registry resources. Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PV-2: Sustain secure configurations for Azure services

Guidance: Use Microsoft Defender for Cloud to monitor your configuration baseline. Use Azure Policy [deny] and [deploy if not exist] to enforce secure configuration across Azure compute resources including VMs, containers, and others.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PV-5: Securely store custom operating system and container images

Guidance: Container Registry allows customers to manage operating system images or container images. Use Azure Shared Image Gallery to share your images with different users, service principals, or Azure AD groups within your organization. Store container images in Azure Container Registry and use Azure RBAC to ensure that only authorized users have access.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PV-6: Perform software vulnerability assessments

Guidance: Container Registry allows service deployment in its environment.

Follow recommendations from Microsoft Defender for Cloud for performing vulnerability assessments on your deployed services:

  • Azure virtual machines
  • Container images
  • SQL servers

Microsoft Defender for Cloud has a built-in vulnerability scanner for virtual machine, container images, and SQL database.

As required, export scan results at consistent intervals and compare the results with previous scans to verify that vulnerabilities have been remediated. When using vulnerability management recommendations suggested by Microsoft Defender for Cloud, you can pivot into the selected solution's portal to view historical scan data.

Microsoft performs vulnerability management on the underlying systems that support Container Registry.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ContainerRegistry:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Vulnerabilities in Azure Container Registry images should be remediated Container image vulnerability assessment scans your registry for security vulnerabilities on each pushed container image and exposes detailed findings for each image (powered by Qualys). Resolving the vulnerabilities can greatly improve your containers' security posture and protect them from attacks. AuditIfNotExists, Disabled 2.0.0

PV-7: Rapidly and automatically remediate software vulnerabilities

Guidance: Not applicable. This recommendation is intended for compute resources. Azure Container Registry doesn't deploy customer-facing compute resources which customers would need to configure.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

PV-8: Conduct regular attack simulation

Guidance: As required, conduct penetration testing or red team activities on your Azure resources. Make sure to fix of all critical security findings.

Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests don't violate Microsoft policies. Use Microsoft's Red Teaming strategy and execution. Do live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Endpoint Security

For more information, see the Azure Security Benchmark: Endpoint Security.

ES-3: Ensure antimalware software and signatures are updated

Guidance: Ensure antimalware signatures are updated rapidly and consistently.

Follow the recommendations in Microsoft Defender for Cloud: Compute & Apps to ensure all endpoints are up to date with the latest signatures. Microsoft Antimalware will automatically install the latest signatures and engine updates by default.

Microsoft handles antimalware for the underlying platform through regular updates and deployments

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Backup and Recovery

For more information, see the Azure Security Benchmark: Backup and Recovery.

BR-1: Ensure regular automated backups

Guidance: The data in your Microsoft Azure container registry is always automatically replicated to ensure durability and high availability. Azure Container Registry copies your data so that it is protected from planned and unplanned events.

Optionally, geo-replicate a container registry to maintain registry replicas in multiple Azure regions or regions with Availability Zones enabled.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

BR-2: Encrypt backup data

Guidance: System data is encrypted at rest using Microsoft managed key.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

BR-3: Validate all backups including customer-managed keys

Guidance: Container Registry maintains backup of its own critical system data. Periodically ensure that you can restore backed-up customer-managed keys.

Use encryption at rest on all Azure resources. By default, all data in an Azure container registry is encrypted at rest using Microsoft-managed keys.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

BR-4: Mitigate risk of lost keys

Guidance: Make sure you have measures in place to prevent and recover from the loss of Azure Backup encryption keys. Enable soft delete and purge protection in Azure Key Vault to protect keys against accidental or malicious deletion.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Next steps