Azure security baseline for Azure Cache for Redis

This security baseline applies guidance from the Azure Security Benchmark version1.0 to Azure Cache for Redis. 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 Azure Cache for Redis.

Note

Controls not applicable to Azure Cache for Redis, or for which the responsibility is Microsoft's, have been excluded. To see how Azure Cache for Redis completely maps to the Azure Security Benchmark, see the full Azure Cache for Redis security baseline mapping file.

Network Security

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

1.1: Protect Azure resources within virtual networks

Guidance: Deploy your Azure Cache for Redis instance within a virtual network (VNet). A VNet is a private network in the cloud. 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.

You may also specify firewall rules with a start and end IP address range. When firewall rules are configured, only client connections from the specified IP address ranges can connect to the cache.

Responsibility: Customer

Azure Security Center monitoring: None

1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and network interfaces

Guidance: When Virtual Machines are deployed in the same virtual network as your Azure Cache for Redis instance, you can use network security groups (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs into an Azure Storage Account for traffic audit. You may also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

Azure Security Center monitoring: None

1.3: Protect critical web applications

Guidance: Not applicable; this recommendation is intended for web applications running on Azure App Service or compute resources.

Responsibility: Customer

Azure Security Center monitoring: None

1.4: Deny communications with known-malicious IP addresses

Guidance: 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 deployed in a VNet, Azure Cache for Redis is not publicly addressable and can only be accessed from virtual machines and applications within the VNet.

Enable DDoS Protection Standard on the VNets associated with your Azure Cache for Redis instances to guard against distributed denial-of-service (DDoS) attacks. Use Azure Security Center Integrated Threat Intelligence to deny communications with known malicious or unused Internet IP addresses.

Responsibility: Customer

Azure Security Center monitoring: None

1.5: Record network packets

Guidance: When virtual machines are deployed in the same virtual network as your Azure Cache for Redis instance, you can use network security groups (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs into an Azure Storage Account for traffic audit. You may also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

Azure Security Center monitoring: None

1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: When using Azure Cache for Redis with your web applications running on Azure App Service or compute instances, deploy all resources within an Azure Virtual Network (VNet) and secure with an Azure Web Application Firewall (WAF) on Web Application Gateway. Configure the WAF to run in "Prevention Mode". Prevention Mode blocks intrusions and attacks that the rules detect. The attacker receives a "403 unauthorized access" exception, and the connection is closed. Prevention mode records such attacks in the WAF logs.

Alternatively, you may select an offer from the Azure Marketplace that supports IDS/IPS functionality with payload inspection and/or anomaly detection capabilities.

Responsibility: Customer

Azure Security Center monitoring: None

1.7: Manage traffic to web applications

Guidance: Not applicable; this recommendation is intended for web applications running on Azure App Service or compute resources.

Responsibility: Customer

Azure Security Center monitoring: None

1.8: Minimize complexity and administrative overhead of network security rules

Guidance: Use virtual network service tags to define network access controls on network security groups (NSG) or Azure Firewall. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name (e.g., ApiManagement) 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.

You may also use application security groups (ASG) to help simplify complex security configuration. ASGs enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups.

Responsibility: Customer

Azure Security Center monitoring: None

1.9: Maintain standard security configurations for network devices

Guidance: Define and implement standard security configurations for network resources related to your Azure Cache for Redis instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.Cache" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your Azure Cache for Redis instances. You may also make use of built-in policy definitions such as:

  • Only secure connections to your Redis Cache should be enabled

  • DDoS Protection Standard should be enabled

You may also use Azure Blueprints to simplify large-scale Azure deployments by packaging key environment artifacts, such as Azure Resource Manager (ARM) templates, Azure role-based access control (Azure RBAC), and policies, in a single blueprint definition. Easily apply the blueprint to new subscriptions and environments, and fine-tune control and management through versioning.

Responsibility: Customer

Azure Security Center monitoring: None

1.10: Document traffic configuration rules

Guidance: Use tags for network resources associated with your Azure Cache for Redis deployment in order to logically organize them into a taxonomy.

Responsibility: Customer

Azure Security Center monitoring: None

1.11: Use automated tools to monitor network resource configurations and detect changes

Guidance: Use the Azure Activity log to monitor network resource configurations and detect changes for network resources related to your Azure Cache for Redis instances. Create alerts within Azure Monitor that will trigger when changes to critical network resources take place.

Responsibility: Customer

Azure Security Center monitoring: None

Logging and Monitoring

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

2.2: Configure central security log management

Guidance: Enable Azure Activity Log diagnostic settings and send the logs to a Log Analytics workspace, Azure event hub, or Azure storage account for archive. Activity logs provide insight into the operations that were performed on your Azure Cache for Redis instances at the control plane level. Using Azure Activity Log data, you can determine the "what, who, and when" for any write operations (PUT, POST, DELETE) performed at the control plane level for your Azure Cache for Redis instances.

Responsibility: Customer

Azure Security Center monitoring: None

2.3: Enable audit logging for Azure resources

Guidance: Enable Azure Activity Log diagnostic settings and send the logs to a Log Analytics workspace, Azure event hub, or Azure storage account for archive. Activity logs provide insight into the operations that were performed on your Azure Cache for Redis instances at the control plane level. Using Azure Activity Log data, you can determine the "what, who, and when" for any write operations (PUT, POST, DELETE) performed at the control plane level for your Azure Cache for Redis instances.

While metrics are available by enabling Diagnostic Settings, audit logging at the data plane is not yet available for Azure Cache for Redis.

Responsibility: Customer

Azure Security Center monitoring: None

2.5: Configure security log storage retention

Guidance: In Azure Monitor, set log retention period for Log Analytics workspaces associated with your Azure Cache for Redis instances according to your organization's compliance regulations.

Note that audit logging at the data plane is not yet available for Azure Cache for Redis.

Responsibility: Customer

Azure Security Center monitoring: None

2.6: Monitor and review logs

Guidance: Enable Azure Activity Log diagnostic settings and send the logs to a Log Analytics workspace. Perform queries in Log Analytics to search terms, identify trends, analyze patterns, and provide many other insights based on the Activity Log Data that may have been collected for Azure Cache for Redis.

Note that audit logging at the data plane is not yet available for Azure Cache for Redis.

Responsibility: Customer

Azure Security Center monitoring: None

2.7: Enable alerts for anomalous activities

Guidance: You can configure to receive alerts based on metrics and activity logs related to your Azure Cache for Redis instances. Azure Monitor allows you to configure an alert to send an email notification, call a webhook, or invoke an Azure Logic App.

While metrics are available by enabling Diagnostic Settings, audit logging at the data plane is not yet available for Azure Cache for Redis.

Responsibility: Customer

Azure Security Center monitoring: None

Identity and Access Control

For more information, see the Azure Security Benchmark: Identity and Access Control.

3.1: Maintain an inventory of administrative accounts

Guidance: Azure Active Directory (Azure AD) has built-in roles that must be explicitly assigned and are queryable. Use the Azure AD PowerShell module to perform ad hoc queries to discover accounts that are members of administrative groups.

Responsibility: Customer

Azure Security Center monitoring: None

3.2: Change default passwords where applicable

Guidance: Control plane access to Azure Cache for Redis is controlled through Azure Active Directory (Azure AD). Azure AD does not have the concept of default passwords.

Data plane access to Azure Cache for Redis is controlled through access keys. These keys are used by the clients connecting to your cache and can be regenerated at any time.

It is not recommended that you build default passwords into your application. Instead, you can store your passwords in Azure Key Vault and then use Azure AD to retrieve them.

Responsibility: Shared

Azure Security Center monitoring: None

3.3: Use dedicated administrative accounts

Guidance: Create standard operating procedures around the use of dedicated administrative accounts. Use Azure Security Center Identity and Access Management to monitor the number of administrative accounts.

Additionally, to help you keep track of dedicated administrative accounts, you may use recommendations from Azure Security Center or built-in Azure Policies, such as:

  • There should be more than one owner assigned to your subscription

  • Deprecated accounts with owner permissions should be removed from your subscription

  • External accounts with owner permissions should be removed from your subscription

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

3.4: Use Azure Active Directory single sign-on (SSO)

Guidance: Azure Cache for Redis uses access keys to authenticate users and does not support single sign-on (SSO) at the data plane level. Access to the control plane for Azure Cache for Redis is available via REST API and supports SSO. To authenticate, set the Authorization header for your requests to a JSON Web Token that you obtain from Azure Active Directory (Azure AD).

Responsibility: Customer

Azure Security Center monitoring: None

3.5: Use multi-factor authentication for all Azure Active Directory-based access

Guidance: Enable Azure Active Directory (Azure AD) multifactor authentication and follow Azure Security Center Identity and Access Management recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

3.6: Use dedicated machines (Privileged Access Workstations) for all administrative tasks

Guidance: Use privileged access workstations (PAW) with multifactor authentication configured to log into and configure Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

3.7: Log and alert on suspicious activities from administrative accounts

Guidance: Use Azure Active Directory (Azure AD) Privileged Identity Management (PIM) for generation of logs and alerts when suspicious or unsafe activity occurs in the environment.

In addition, use Azure AD risk detections to view alerts and reports on risky user behavior.

Responsibility: Customer

Azure Security Center monitoring: None

3.8: Manage Azure resources from only approved locations

Guidance: Configure named locations in Azure Active Directory (Azure AD) Conditional Access to allow access from only specific logical groupings of IP address ranges or countries/regions.

Responsibility: Customer

Azure Security Center monitoring: None

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system. Azure AD protects data by using strong encryption for data at rest and in transit. Azure AD also salts, hashes, and securely stores user credentials.

Azure AD authentication cannot be used for direct access to Azure Cache for Redis' data plane, however, Azure AD credentials may be used for administration at the control plane level (i.e. the Azure portal) to control Azure Cache for Redis access keys.

Responsibility: Customer

Azure Security Center monitoring: None

3.10: Regularly review and reconcile user access

Guidance: Azure Active Directory (Azure AD) provides logs to help you discover stale accounts. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments. User access can be reviewed on a regular basis to make sure only the right Users have continued access.

Responsibility: Customer

Azure Security Center monitoring: None

3.11: Monitor attempts to access deactivated credentials

Guidance: You have access to Azure Active Directory (Azure AD) sign-in activity, audit and risk event log sources, which allow you to integrate with Azure Sentinel or a third-party SIEM.

You can streamline this process by creating diagnostic settings for Azure AD user accounts and sending the audit logs and sign-in logs to a Log Analytics workspace. You can configure desired log alerts within Log Analytics.

Responsibility: Customer

Azure Security Center monitoring: None

3.12: Alert on account sign-in behavior deviation

Guidance: For account login behavior deviation on the control plane, use Azure Active Directory (Azure AD) Identity Protection and risk detection features to configure automated responses to detected suspicious actions related to user identities. You can also ingest data into Azure Sentinel for further investigation.

Responsibility: Customer

Azure Security Center monitoring: None

Data Protection

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

4.1: Maintain an inventory of sensitive Information

Guidance: Use tags to assist in tracking Azure resources that store or process sensitive information.

Responsibility: Customer

Azure Security Center monitoring: None

4.2: Isolate systems storing or processing sensitive information

Guidance: Implement separate subscriptions and/or management groups for development, test, and production. Azure Cache for Redis instances should be separated by virtual network/subnet and tagged appropriately. Optionally, use the Azure Cache for Redis firewall to define rules so that only client connections from specified IP address ranges can connect to the cache.

Responsibility: Customer

Azure Security Center monitoring: None

4.3: Monitor and block unauthorized transfer of sensitive information

Guidance: Not yet available; data identification, classification, and loss prevention features are not yet available for Azure Cache for Redis.

Microsoft manages the underlying infrastructure for Azure Cache for Redis and has implemented strict controls to prevent the loss or exposure of customer data.

Responsibility: Shared

Azure Security Center monitoring: None

4.4: Encrypt all sensitive information in transit

Guidance: Azure Cache for Redis requires TLS-encrypted communications by default. TLS versions 1.0, 1.1 and 1.2 are currently supported. However, TLS 1.0 and 1.1 are on a path to deprecation industry-wide, so use TLS 1.2 if at all possible. If your client library or tool doesn't support TLS, then enabling unencrypted connections can be done through the Azure portal or management APIs. In such cases where encrypted connections aren't possible, placing your cache and client application into a virtual network would be recommended.

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.Cache:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Only secure connections to your Azure Cache for Redis should be enabled Audit enabling of only connections via SSL to Azure Cache for Redis. 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 Audit, Deny, Disabled 1.0.0

4.5: Use an active discovery tool to identify sensitive data

Guidance: Data identification, classification, and loss prevention features are not yet available for Azure Cache for Redis. Tag instances containing sensitive information as such and implement third-party solution if required for compliance purposes.

For the underlying platform which is managed by Microsoft, Microsoft treats all customer content as sensitive and goes to great lengths to guard against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented and maintains a suite of robust data protection controls and capabilities.

Responsibility: Customer

Azure Security Center monitoring: None

4.6: Use Role-based access control to control access to resources

Guidance: Use Azure role-based access control (Azure RBAC) to control access to the Azure Cache for Redis control plane (i.e. Azure portal).

Responsibility: Customer

Azure Security Center monitoring: None

4.8: Encrypt sensitive information at rest

Guidance: Azure Cache for Redis stores customer data in memory, and while strongly protected by many controls implemented by Microsoft, memory is not encrypted by default. If required by your organization, encrypt content before storing in Azure Cache for Redis.

If using the Azure Cache for Redis feature "Redis Data Persistence", data is sent to an Azure Storage account that you own and manage. You can configure persistence from the "New Azure Cache for Redis" blade during cache creation and on the Resource menu for existing premium caches.

Data in Azure Storage is encrypted and decrypted transparently using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant. Azure Storage encryption cannot be disabled. You can rely on Microsoft-managed keys for the encryption of your storage account, or you can manage encryption with your own keys.

Responsibility: Shared

Azure Security Center monitoring: None

4.9: Log and alert on changes to critical Azure resources

Guidance: Use Azure Monitor with the Azure Activity log to create alerts for when changes take place to production instances of Azure Cache for Redis and other critical or related resources.

Responsibility: Customer

Azure Security Center monitoring: None

Vulnerability Management

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

5.1: Run automated vulnerability scanning tools

Guidance: Follow recommendations from Azure Security Center on securing your Azure Cache for Redis instances and related resources.

Microsoft performs vulnerability management on the underlying systems that support Azure Cache for Redis.

Responsibility: Shared

Azure Security Center monitoring: None

Inventory and Asset Management

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

6.1: Use automated asset discovery solution

Guidance: Use Azure Resource Graph to query/discover all resources (such as compute, storage, network, ports, and protocols etc.) within your subscription(s). Ensure appropriate (read) permissions in your tenant and enumerate all Azure subscriptions as well as resources within your subscriptions.

Although classic Azure resources may be discovered via Resource Graph, it is highly recommended to create and use Azure Resource Manager resources going forward.

Responsibility: Customer

Azure Security Center monitoring: None

6.2: Maintain asset metadata

Guidance: Apply tags to Azure resources giving metadata to logically organize them into a taxonomy.

Responsibility: Customer

Azure Security Center monitoring: None

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track Azure Cache for Redis instances and related resources. Reconcile inventory on a regular basis and ensure unauthorized resources are deleted from the subscription in a timely manner.

In addition, use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

6.5: Monitor for unapproved Azure resources

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types
  • Allowed resource types

In addition, use Azure Resource Graph to query for and discover resources within the subscriptions.

Responsibility: Customer

Azure Security Center monitoring: None

6.9: Use only approved Azure services

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscription(s) using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

6.11: Limit users' ability to interact with Azure Resource Manager

Guidance: Configure Azure Conditional Access to limit users' ability to interact with Azure Resource Manager (ARM) by configuring "Block access" for the "Microsoft Azure Management" App.

Responsibility: Customer

Azure Security Center monitoring: None

Secure Configuration

For more information, see the Azure Security Benchmark: Secure Configuration.

7.1: Establish secure configurations for all Azure resources

Guidance: Define and implement standard security configurations for your Azure Cache for Redis instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.Cache" namespace to create custom policies to audit or enforce the configuration of your Azure Cache for Redis instances. You may also make use of built-in policy definitions related to your Azure Cache for Redis instances, such as:

  • Only secure connections to your Redis Cache should be enabled

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

7.3: Maintain secure Azure resource configurations

Guidance: Use Azure Policy [deny] and [deploy if not exist] to enforce secure settings across your Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

7.5: Securely store configuration of Azure resources

Guidance: If using custom Azure Policy definitions or Azure Resource Manager templates for your Azure Cache for Redis instances and related resources, use Azure Repos to securely store and manage your code.

Responsibility: Customer

Azure Security Center monitoring: None

7.7: Deploy configuration management tools for Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.Cache" namespace to create custom policies to alert, audit, and enforce system configurations. Additionally, develop a process and pipeline for managing policy exceptions.

Responsibility: Customer

Azure Security Center monitoring: None

7.9: Implement automated configuration monitoring for Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.Cache" namespace to create custom policies to alert, audit, and enforce system configurations. Use Azure Policy [audit], [deny], and [deploy if not exist] to automatically enforce configurations for your Azure Cache for Redis instances and related resources.

Responsibility: Customer

Azure Security Center monitoring: None

7.11: Manage Azure secrets securely

Guidance: For Azure virtual machines or web applications running on Azure App Service being used to access your Azure Cache for Redis instances, use Managed Service Identity in conjunction with Azure Key Vault to simplify and secure Azure Cache for Redis secret management. Ensure Key Vault soft delete is enabled.

Responsibility: Customer

Azure Security Center monitoring: None

7.12: Manage identities securely and automatically

Guidance: For Azure virtual machines or web applications running on Azure App Service being used to access your Azure Cache for Redis instances, use Managed Service Identity in conjunction with Azure Key Vault to simplify and secure Azure Cache for Redis secret management. Ensure Key Vault Soft Delete is enabled.

Use Managed Identities to provide Azure services with an automatically managed identity in Azure Active Directory (Azure AD). Managed Identities allows you to authenticate to any service that supports Azure AD authentication, including Azure Key Vault, without any credentials in your code.

Responsibility: Customer

Azure Security Center monitoring: None

7.13: Eliminate unintended credential exposure

Guidance: Implement Credential Scanner to identify credentials within code. Credential Scanner will also encourage moving discovered credentials to more secure locations such as Azure Key Vault.

Responsibility: Customer

Azure Security Center monitoring: None

Malware Defense

For more information, see the Azure Security Benchmark: Malware Defense.

8.2: Pre-scan files to be uploaded to non-compute Azure resources

Guidance: Microsoft anti-malware is enabled on the underlying host that supports Azure services (for example, Azure Cache for Redis), however it does not run on customer content.

Pre-scan any content being uploaded to non-compute Azure resources, such as App Service, Data Lake Storage, Blob Storage, Azure Database for PostgreSQL, etc. Microsoft cannot access your data in these instances.

Responsibility: Customer

Azure Security Center monitoring: None

Data Recovery

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

9.1: Ensure regular automated back-ups

Guidance: Enable Redis persistence. Redis persistence allows you to persist data stored in Redis. You can also take snapshots and back up the data, which you can load in case of a hardware failure. This is a huge advantage over Basic or Standard tier where all the data is stored in memory and there can be potential data loss in case of a failure where Cache nodes are down.

You may also use Azure Cache for Redis Export. Export allows you to export the data stored in Azure Cache for Redis to Redis compatible RDB file(s). You can use this feature to move data from one Azure Cache for Redis instance to another or to another Redis server. During the export process, a temporary file is created on the virtual machine that hosts the Azure Cache for Redis server instance, and the file is uploaded to the designated storage account. When the export operation completes with either a status of success or failure, the temporary file is deleted.

Responsibility: Customer

Azure Security Center monitoring: None

9.2: Perform complete system backups and backup any customer-managed keys

Guidance: Enable Redis persistence. Redis persistence allows you to persist data stored in Redis. You can also take snapshots and back up the data, which you can load in case of a hardware failure. This is a huge advantage over Basic or Standard tier where all the data is stored in memory and there can be potential data loss in case of a failure where Cache nodes are down.

You may also use Azure Cache for Redis Export. Export allows you to export the data stored in Azure Cache for Redis to Redis compatible RDB file(s). You can use this feature to move data from one Azure Cache for Redis instance to another or to another Redis server. During the export process, a temporary file is created on the virtual machine that hosts the Azure Cache for Redis server instance, and the file is uploaded to the designated storage account. When the export operation completes with either a status of success or failure, the temporary file is deleted.

If using Azure Key Vault to store credentials for your Azure Cache for Redis instances, ensure regular automated backups of your keys.

Responsibility: Customer

Azure Security Center monitoring: None

9.3: Validate all backups including customer-managed keys

Guidance: Use Azure Cache for Redis Import. Import can be used to bring Redis-compatible RDB files from any Redis server running in any cloud or environment, including Redis running on Linux, Windows, or any cloud provider such as Amazon Web Services and others. Importing data is an easy way to create a cache with pre-populated data. During the import process, Azure Cache for Redis loads the RDB files from Azure storage into memory and then inserts the keys into the cache.

Periodically test data restoration of your Azure Key Vault secrets.

Responsibility: Customer

Azure Security Center monitoring: None

Incident Response

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

10.1: Create an incident response guide

Guidance: Build out an incident response guide for your organization. Ensure that there are written incident response plans that define all roles of personnel as well as phases of incident handling/management from detection to post-incident review.

Responsibility: Customer

Azure Security Center monitoring: None

10.2: Create an incident scoring and prioritization procedure

Guidance: Security Center assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Security Center is in the finding or the analytics used to issue the alert as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Additionally, clearly mark subscriptions (for ex. production, non-prod) and create a naming system to clearly identify and categorize Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

10.3: Test security response procedures

Guidance: Conduct exercises to test your systems’ incident response capabilities on a regular cadence. Identify weak points and gaps and revise plan as needed.

Responsibility: Customer

Azure Security Center monitoring: None

10.4: Provide security incident contact details and configure alert notifications for security incidents

Guidance: Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that the customer's data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.

Responsibility: Customer

Azure Security Center monitoring: None

10.5: Incorporate security alerts into your incident response system

Guidance: Export your Azure Security Center alerts and recommendations using the Continuous Export feature. Continuous Export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion. You may use the Azure Security Center data connector to stream the alerts to Azure Sentinel.

Responsibility: Customer

Azure Security Center monitoring: None

10.6: Automate the response to security alerts

Guidance: Use the Workflow Automation feature in Azure Security Center to automatically trigger responses via "Logic Apps" on security alerts and recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

Penetration Tests and Red Team Exercises

For more information, see the Azure Security Benchmark: Penetration Tests and Red Team Exercises.

11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security findings

Guidance: Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests are not in violation of Microsoft policies. Use Microsoft's strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.

Responsibility: Shared

Azure Security Center monitoring: None

Next steps