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](https://github.com/MicrosoftDocs/SecurityBenchmarks/raw/master/Azure Offer Security Baselines/2.0/container-registry-security-baseline-v2.0.xlsx).

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

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure 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

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure 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

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure 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

Azure Security Center monitoring: None

NS-5: Deploy intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: Use Azure Firewall threat intelligence-based filtering to alert on and block traffic to and from known malicious IP addresses and domains. The Microsoft Threat Intelligence feed provides the IP addresses and domains. When you require payload inspection, deploy a third-party Intrusion Detection System (IDS) or Intrusion Prevention System (IPS). You can find them in Azure Marketplace. Make sure the one you choose has payload inspection capabilities. Alternately, you can use a host-based IDS, IPS, or Endpoint Detection and Response (EDR) solution with a network-based IDS or IPS. Or use host-based solutions instead of network-based solutions.

Responsibility: Customer

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center monitoring: None

IM-4: Use strong authentication controls for all Azure AD based access

Guidance: Container Registry uses Azure AD, which supports strong authentication controls through multi-factor authentication (MFA) and strong passwordless methods.

  • Multi-factor authentication - Enable Azure AD MFA, and then follow Azure Security Center Identity and Access Management best practices recommendations in your MFA setup. You can enforce MFA on all users, select users, or at the per-user level, based on sign-in conditions and risk factors.

  • Passwordless authentication - The three available no-password authentication options are Windows Hello for Business, Microsoft Authenticator app, and on-premises authentication methods such as smart cards.

For administrators and privileged users, make sure to use the highest level of the strong authentication method. Then roll out the appropriate strong authentication policy to other users.

Responsibility: Customer

Azure Security Center monitoring: None

IM-5: Monitor and alert on account anomalies

Guidance: Container Registry integrates with Azure AD, which provides the following data sources:

  • Sign-ins - Provides information about managed application usage 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 - An indicator for a user account that might be compromised.

You can integrate these data sources with Azure Monitor, Azure Sentinel, or third-party security information and event management (SIEM) systems.

Azure Security Center can also alert you about suspicious activities like an excessive number of failed authentication attempts, or about deprecated accounts.

Azure Advanced Threat Protection (ATP) can use Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions.

Each container registry includes an admin user account. It's disabled by default. You can enable the admin user and manage its credentials in the Azure portal, or by using the Azure CLI or other Azure tools. The admin account has full permissions to the registry.

Responsibility: Customer

Azure Security Center 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

Azure Security Center 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

Azure Security Center monitoring: None

PA-2: Restrict administrative access to business-critical systems

Guidance: Container Registry uses Azure RBAC to isolate access to business-critical systems. RBAC restricts which accounts are granted privileged access to their subscriptions and management groups.

Align all types of access controls to your enterprise segmentation strategy to ensure consistent access control.

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.

There are several ways to authenticate with an Azure container registry, each of which 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

For more information, see:

Responsibility: Customer

Azure Security Center 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

Azure Security Center monitoring: None

PA-4: Set up emergency access in Azure AD

Guidance: Container Registry uses Azure AD to manage its resources. To prevent being accidentally locked out of your Azure AD organization, set up an emergency account for access when you can't use normal administrative accounts. Emergency access accounts are highly privileged, and they shouldn't be assigned to specific individuals. Emergency access accounts are limited to emergency or "break glass" scenarios.

Make sure to keep emergency access account credentials like passwords, certificates, or smart cards secure. Credentials should be known only to those who are authorized to use them in an emergency.

Responsibility: Customer

Azure Security Center monitoring: None

PA-5: Automate entitlement management

Guidance: Container Registry integrates with Azure AD to manage its resources. Use Azure AD entitlement management features to automate access request workflows, including access assignments, reviews, and expiration. Entitlement management also supports dual or multi-stage approval workflows.

Responsibility: Customer

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure 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 Azure Security Center.

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

Azure Security Center 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 Security Center Adaptive Application Controls to specify which file types a rule might or might not apply to.

Responsibility: Customer

Azure Security Center 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

Azure Security Center monitoring: None

AM-4: Ensure security of asset lifecycle management

Guidance: Establish or update security policies that address asset lifecycle management processes for potentially high impact modifications. These modifications include but are not limited to:

  • Identity providers and access
  • Data sensitivity
  • Network configuration
  • Administrative privilege assignment.

Outline any high-impact configurations that the customer should be aware of.

Remove Azure resources when they are no longer needed.

Responsibility: Customer

Azure Security Center monitoring: None

AM-5: Limit users' ability to interact with Azure Resource Manager

Guidance: Use Azure Conditional Access to limit users' ability to interact with Azure Resources Manager by configuring "Block access" for the "Microsoft Azure Management" app.

Note: These conditional access policies don't apply to other means of programmatically authenticating users like application or service principals.

Responsibility: Customer

Azure Security Center 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 Azure Security Center built-in threat detection capability and enable Azure Defender (formerly Azure Advanced Threat Protection) for your Container Registry resources. Azure 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

Azure Security Center 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, Azure 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.

Azure Security Center 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.

Azure Security Center 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, Azure Security Center'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

Azure Security Center 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

Azure Security Center 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 Azure Security Center 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

Azure Security Center 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

Azure Security Center 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

Azure Security Center monitoring: None

Incident Response

For more information, see the Azure Security Benchmark: Incident Response.

IR-1: Preparation – update incident response process for Azure

Guidance: Make sure your organization has processes to respond to security incidents, updates these processes for Azure, and exercises them regularly to ensure readiness.

Responsibility: Customer

Azure Security Center monitoring: None

IR-2: Preparation – setup incident notification

Guidance: Set up security incident contact information in Azure Security Center. Microsoft uses this information to contact you if the Microsoft Security Response Center (MSRC) finds that an unlawful or unauthorized party accessed your data. You can also customize incident alerts and notifications in different Azure services, based on your incident response needs.

Responsibility: Customer

Azure Security Center monitoring: None

IR-3: Detection and analysis – create incidents based on high-quality alerts

Guidance: Make sure you have a process to create high-quality alerts and measure the quality of alerts. This process helps you learn lessons from past incidents and prioritize alerts for analysts, so they don't waste time on false positives.

You can build high-quality alerts based on:

  • Experience from past incidents

  • Validated community sources

  • Tools that fuse and correlate diverse signal sources to generate and clean up alerts

Azure Security Center provides high-quality alerts across many Azure assets. You can use the ASC data connector to stream Azure Security Center alerts to Azure Sentinel. In Azure Sentinel, you can create advanced alert rules to generate incidents automatically for an investigation.

Use the export feature to export your Azure Security Center alerts and recommendations and help identify risks to Azure resources. You can export alerts and recommendations either manually or in an ongoing, continuous fashion.

Responsibility: Customer

Azure Security Center monitoring: None

IR-4: Detection and analysis – investigate an incident

Guidance: Make sure analysts can query and use diverse data sources to build a full view as they investigate potential incidents. Collect diverse logs to track a potential attacker's activities across the kill chain to avoid blind spots. Make sure to capture insights and learnings for other analysts and for future historical reference.

The data sources for investigation include centralized logging that's being collected from in-scope services and running systems. Data sources can also include:

  • Network data - Use NSGs' flow logs, Azure Network Watcher, and Azure Monitor to capture network flow logs and other analytics information.

  • Snapshots of running systems:

  • Use Azure virtual machine's snapshot capability to create a snapshot of the running system's disk.

  • Use the operating system's native memory dump capability to create a snapshot of the running system's memory.

  • Use the snapshot feature of the Azure services or your software's own capability to create snapshots of the running systems.

Azure Sentinel provides extensive data analytics across virtually any log source and a case management portal to manage the full lifecycle of incidents. Intelligence information during an investigation can be associated with an incident for tracking and reporting purposes.

Responsibility: Customer

Azure Security Center monitoring: None

IR-5: Detection and analysis – prioritize incidents

Guidance: Provide context to analysts on which incidents to focus on first based on alert severity and asset sensitivity.

Azure Security Center assigns a severity to each alert to help you prioritize which alerts to investigate first. The severity is based on:

  • How confident Security Center is in the finding or the analytics used to issue the alert

  • The confidence level that there was malicious intent behind the activity that led to the alert

Mark resources using tags, and create a naming system to identify and categorize Azure resources that have sensitive data. It's your responsibility to prioritize alert remediation. Base priorities on the importance of the Azure resources and environment where the incidents occur.

Responsibility: Customer

Azure Security Center monitoring: None

IR-6: Containment, eradication and recovery – automate the incident handling

Guidance: Automate manual repetitive tasks to speed up response time and reduce the burden on analysts. Manual tasks take longer to execute, slowing incident response and reducing how many incidents an analyst can handle. Manual tasks also increase analyst fatigue. Fatigue degrades analysts' ability to focus on complex tasks, and increases the risk of human error that causes delays.

Use workflow automation features in Azure Security Center and Azure Sentinel to trigger actions or run playbooks in response to incoming security alerts. Playbooks take actions like sending notifications, disabling accounts, and isolating problematic networks.

Responsibility: Customer

Azure Security Center 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 Azure Security Center 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

Azure Security Center monitoring: None

PV-2: Sustain secure configurations for Azure services

Guidance: Use Azure Security Center 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

Azure Security Center 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

Azure Security Center monitoring: None

PV-6: Perform software vulnerability assessments

Guidance: Container Registry allows service deployment in its environment.

Follow recommendations from Azure Security Center for performing vulnerability assessments on your deployed services:

  • Azure virtual machines
  • Container images
  • SQL servers

Azure Security Center 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 Azure Security Center, 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

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure 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

Azure Security Center 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

Azure Security Center 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 Azure Security Center: 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

Azure Security Center 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

Azure Security Center monitoring: None

BR-2: Encrypt backup data

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

Responsibility: Customer

Azure Security Center 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

Azure Security Center 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

Azure Security Center monitoring: None

Governance and Strategy

For more information, see the Azure Security Benchmark: Governance and Strategy.

GS-1: Define asset management and data protection strategy

Guidance: Make sure you document and communicate a clear strategy for continuous monitoring and protection of systems and data. Prioritize discovery, assessment, protection, and monitoring of business-critical data and systems.

This strategy should include documented guidance, policy, and standards for the following elements:

  • Data classification standard in accordance with the business risks
  • Security organization visibility into risks and asset inventory
  • Security organization approval of Azure services for use
  • Security of assets through their lifecycle
  • Required access control strategy in accordance with organizational data classification
  • Use of Azure native and third-party data protection capabilities
  • Data encryption requirements for in-transit and at-rest use cases
  • Appropriate cryptographic standards

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

GS-2: Define enterprise segmentation strategy

Guidance: Establish an enterprise-wide strategy to segment asset access. Use a combination of identity, network, application, subscription, management group, and other controls.

Carefully balance security separation with enabling daily operation of systems that need to communicate with each other and access data.

Make sure to implement the segmentation strategy consistently across control types. Control types include:

  • Network security

  • Identity and access models

  • Application permission and access models

  • Human process controls

For more information, see:

Responsibility: Customer

Azure Security Center monitoring: None

GS-3: Define security posture management strategy

Guidance: Continuously measure and mitigate risks to your individual assets and the environment that hosts them. Prioritize high-value assets and highly exposed attack surfaces, including:

  • Published applications

  • Network ingress and egress points

  • User and administrator endpoints

For more information, see:

Responsibility: Customer

Azure Security Center monitoring: None

GS-4: Align organization roles, responsibilities, and accountabilities

Guidance: Make sure to document and communicate a clear strategy for roles and responsibilities in your security organization. Provide clear accountability for security decisions. Educate everyone on the shared responsibility model, and educate technical teams on how to secure the cloud.

Responsibility: Customer

Azure Security Center monitoring: None

GS-5: Define network security strategy

Guidance: Establish an Azure network security approach as part of your organization's overall security access control strategy.

This strategy should include documented guidance, policy, and standards for the following elements:

  • Centralized network management and security responsibility

  • Virtual network segmentation model aligned with the enterprise segmentation strategy

  • Remediation strategy in different threat and attack scenarios

  • Internet edge and ingress and egress strategy

  • Hybrid cloud and on-premises interconnectivity strategy

  • Up-to-date network security artifacts, such as network diagrams and reference network architecture

For more information, see:

Responsibility: Customer

Azure Security Center monitoring: None

GS-6: Define identity and privileged access strategy

Guidance: Establish an Azure identity and privileged access approach as part of your organization's overall security access control strategy.

This strategy should include documented guidance, policy, and standards for the following elements:

  • A centralized identity and authentication system

  • Interconnectivity with other internal and external identity systems

  • Strong authentication methods in different use cases and conditions

  • Protection of highly privileged users

  • Anomalous user activity monitoring and handling

  • A user identity and access review and reconciliation process

For more information, see:

Responsibility: Customer

Azure Security Center monitoring: None

GS-7: Define logging and threat response strategy

Guidance: Establish a logging and threat response strategy to rapidly detect and remediate threats while meeting compliance requirements. Prioritize providing analysts with high-quality alerts and seamless experiences, so they can focus on threats rather than integration and manual steps.

This strategy should include documented guidance, policy, and standards for the following elements:

  • The security operations (SecOps) organization's role and responsibilities

  • A well-defined incident response process that aligns with National Institute of Standards and Technology (NIST) or another industry framework

  • Log capture and retention to support threat detection, incident response, and compliance

  • Centralized visibility and correlation information about threats, using SIEM, native Azure, and other sources

  • Communication and notification plan with your customers, suppliers, and public parties of interest

  • Use of Azure native and third-party platforms for incident handling. Incident handling includes logging and threat detection, forensics, and attack remediation and eradication

  • Processes for handling post-incident activities, such as lessons learned and evidence retention

For more information, see:

Responsibility: Customer

Azure Security Center monitoring: None

GS-8: Define backup and recovery strategy

Guidance: Establish an Azure backup and recovery strategy for your organization.

This strategy should include documented guidance, policy, and standards for the following elements:

  • Recovery time objective (RTO) and recovery point objective (RPO) definitions that align with your business resiliency objectives

  • Redundancy in your applications and infrastructure setup

  • Backup protection using access control and data encryption

For more information, see:

Responsibility: Customer

Azure Security Center monitoring: None

Next steps