Azure security baseline for Event Grid
This security baseline applies guidance from the Azure Security Benchmark version 1.0 to Microsoft Azure Event Grid. 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 Event Grid.
When a feature has relevant Azure Policy Definitions they are listed in this baseline, to help you measure compliance to the Azure Security Benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.
Note
Controls not applicable to Event Grid, or for which the responsibility is Microsoft's, have been excluded. To see how Event Grid completely maps to the Azure Security Benchmark, see the full Event Grid 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: You can use private endpoints to allow ingress of events directly from your virtual network to your Event Grid topics and domains securely over a private link without going through the public internet. When you create a private endpoint for your Event Grid topic or domain, it provides secure connectivity between clients on your VNet and your Event Grid resource. The private endpoint is assigned an IP address from the IP address range of your virtual network. The connection between the private endpoint and the Event Grid service uses a secure private link.
Azure Event Grid also supports public IP-based access controls for publishing to topics and domains. With IP-based controls, you can limit the publishers to a topic or domain to only a set of approved set of machines and cloud services. This feature complements the authentication mechanisms supported by Event Grid.
Responsibility: Customer
1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and NICs
Guidance: Use Microsoft Defender for Cloud and follow network protection recommendations to help secure your Event Grid resources in Azure. If using
Azure virtual machines to access your Event Grid resources, enable network security group (NSG) flow logs and send logs into a storage account for traffic audit.
Responsibility: Customer
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: Not Applicable
1.4: Deny communications with known malicious IP addresses
Guidance: You can configure IP firewall for your Event Grid resource to restrict access over the public internet from only a select set of IP Addresses or IP Address ranges.
You can configure private endpoints to restrict access from only from selected virtual networks.
Enable DDoS Protection Standard on these virtual networks to guard against distributed denial-of-service (DDoS) attacks. Use Microsoft Defender for Cloud Integrated Threat Intelligence to deny communications with known malicious or unused Internet IP addresses. For more information, see the following articles:
How to configure private endpoints for Azure Event Grid topics or domains
For more information about the Microsoft Defender for Cloud Integrated Threat Intelligence
Responsibility: Customer
1.5: Record network packets
Guidance: If you are using Azure virtual machines to access your Event Grid resources, enable network security group (NSG) flow logs and send logs into a 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.
Note network policies are disabled by default when private endpoints are created for Event Grid so above workflow may not work.
If necessary for investigating anomalous activity, enable Network Watcher packet capture.
Responsibility: Customer
1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)
Guidance: Select an offer from the Azure Marketplace that supports IDS/IPS functionality with payload inspection capabilities. When payload inspection is not a requirement, Azure Firewall threat intelligence can be used. Azure Firewall threat intelligence-based filtering is used to alert on and/or block traffic to and from known malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed.
Deploy the firewall solution of your choice at each of your organization's network boundaries to detect and/or block malicious traffic.
Responsibility: Customer
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: Not Applicable
1.8: Minimize complexity and administrative overhead of network security rules
Guidance: For resources in virtual networks that need access to your Azure Event Grid resources, use Virtual Network service tags 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 (for example, AzureEventGrid) 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
1.9: Maintain standard security configurations for network devices
Guidance: Define and implement standard security configurations for network resources associated with your Azure Event Grid namespaces with Azure Policy. Use Azure Policy aliases in the "Microsoft.EventGrid" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your Event Grid resources.
You may also make use of built-in policy definitions related to Azure Event Grid, such as:
Azure Event Grid domains should use private links
Azure Event Grid topics should use private links Azure
Responsibility: Customer
1.10: Document traffic configuration rules
Guidance: Use tags for network resources associated with your Azure Event Grid resources in order to logically organize them into a taxonomy.
Responsibility: Customer
1.11: Use automated tools to monitor network resource configurations and detect changes
Guidance: Use Azure Activity Log to monitor network resource configurations and detect changes for network resources related to Azure Event Grid. Create alerts within Azure Monitor that will trigger when changes to critical network resources take place.
Responsibility: Customer
Logging and Monitoring
For more information, see the Azure Security Benchmark: Logging and Monitoring.
2.2: Configure central security log management
Guidance: Ingest logs via Azure Monitor to aggregate security data generated by Azure Event Grid. Within the Azure Monitor, use Log Analytics workspace(s) to query and perform analytics, and use storage accounts for long-term/archival storage. Alternatively, you may enable, and on-board data to Microsoft Sentinel or a third-party Security Incident and Event Management (SIEM).
Responsibility: Customer
2.3: Enable audit logging for Azure resources
Guidance: Diagnostic settings allow Event Grid users to capture and view publish and delivery failure Logs in either a Storage account, an event hub, or a Log Analytics Workspace.
Responsibility: Customer
2.4: Collect security logs from operating systems
Guidance: Not applicable; this recommendation is intended for compute resources.
Responsibility: Not Applicable
2.5: Configure security log storage retention
Guidance: In Azure Monitor, set the log retention period for Log Analytics workspaces associated with your Azure Event Grid resources according to your organization's compliance regulations.
Responsibility: Customer
2.6: Monitor and review Logs
Guidance: Analyze and monitor logs for anomalous behavior and regularly review the results from Azure Event Grid. Use Azure Monitor and a Log Analytics workspace to review logs and perform queries on log data.
Alternatively, you can enable and on-board data to Microsoft Sentinel or a third-party SIEM.
Enable Diagnostic logs for Azure event grid topics or domains
How to perform queries for Azure Event Grid in Log Analytics Workspaces
Responsibility: Customer
2.7: Enable alerts for anomalous activities
Guidance: Enable diagnostic settings on your event grid for access to publish and delivery failure logs. Activity logs, which are automatically available, include event source, date, user, timestamp, source addresses, destination addresses, and other useful elements. You may send the logs to a Log Analytics workspace. Use Microsoft Defender for Cloud with Log Analytics for monitoring and alerting on anomalous activity found in security logs and events.
You can also create alerts on Azure Event Grid metrics and activity log operations. You can create alerts on both publish and delivery metrics for Azure Event Grid resources (topics and domains).
Additionally, you can onboard your Log Analytics workspace to Microsoft Sentinel as it provides a security orchestration automated response (SOAR) solution. This allows for playbooks (automated solutions) to be created and used to remediate security issues.
Responsibility: Customer
2.8: Centralize anti-malware logging
Guidance: Not applicable; Azure Event Grid does not process or produce anti-malware related logs.
Responsibility: Not Applicable
2.9: Enable DNS query logging
Guidance: Not applicable; Azure Event Grid does not process or produce DNS-related logs.
Responsibility: Not Applicable
2.10: Enable command-line audit logging
Guidance: Not applicable; this recommendation is intended for compute resources.
Responsibility: Not Applicable
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 Event Grid allows you to control the level of access given to different users to do various management operations such as list event subscriptions, create new ones, and generate keys. Event Grid uses Azure role-based access control (Azure RBAC). Event Grid supports built-in roles as well as custom roles.
Azure role-based access control (Azure RBAC) allows you to manage access to Azure resources through role assignments. You can assign these roles to users, groups service principals and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell or the Azure portal.
How to get a directory role in Azure Active Directory (Azure AD) with PowerShell
How to get members of a directory role in Azure AD with PowerShell
Responsibility: Customer
3.2: Change default passwords where applicable
Guidance: Access management to Event Grid resources is controlled through Azure Active Directory (Azure AD). Azure AD does not have the concept of default passwords.
Responsibility: Customer
3.3: Use dedicated administrative accounts
Guidance: Create standard operating procedures around the use of dedicated administrative accounts.
You can also enable a Just-In-Time access by using Azure Active Directory (Azure AD) Privileged Identity Management and Azure Resource Manager.
Event Grid can enable a managed service identity for Azure event grid topics or domains and use it to forward events to supported destinations such as Service Bus queues and topics, event hubs, and storage accounts. Shared Access Signature (SAS) token is used for publishing events to Azure Event Grid. Create standard operating procedure around event access, forwarding, and publishing with those accounts.
Responsibility: Customer
3.4: Use single sign-on (SSO) with Azure Active Directory
Guidance: Not applicable; Event Grid service doesn't support SSO.
Responsibility: Not Applicable
3.5: Use multi-factor authentication for all Azure Active Directory based access
Guidance: Not applicable; Event Grid service doesn't use multifactor authentication.
Responsibility: Not Applicable
3.6: Use dedicated machines (Privileged Access Workstations) for all administrative tasks
Guidance: Not applicable; no Event Grid scenarios require Privileged Access Workstations.
Responsibility: Not Applicable
3.7: Log and alert on suspicious activities from administrative accounts
Guidance: Use Azure Active Directory (Azure AD) security reports and monitoring to detect when suspicious or unsafe activity occurs in the environment. Use Microsoft Defender for Cloud to monitor identity and access activity.
Responsibility: Customer
3.8: Manage Azure resources only from approved locations
Guidance: Not applicable. Event Grid doesn’t use Azure Active Directory (Azure AD) for authenticating event publishing clients; it supports authentication via SAS keys.
Responsibility: Customer
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.
Event Grid can enable a managed service identity for Azure event grid topics or domains and use it to forward events to supported destinations such as Service Bus queues and topics, event hubs, and storage accounts. Shared Access Signature (SAS) token is used for publishing events to Azure Event Grid.
Responsibility: Customer
3.10: Regularly review and reconcile user access
Guidance: Azure Active Directory (Azure AD) provides logs to help discover stale accounts. In addition, use Azure AD identity and 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.
Use Azure AD Privileged Identity Management (PIM) for generation of logs and alerts when suspicious or unsafe activity occurs in the environment.
Responsibility: Customer
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 any SIEM/monitoring tool.
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 alerts within Log Analytics workspace.
Responsibility: Customer
3.12: Alert on account login behavior deviation
Guidance: Use Azure Active Directory (Azure AD) Identity Protection features to configure automated responses to detected suspicious actions related to user identities. You can also ingest data into Microsoft Sentinel for further investigation.
Responsibility: Customer
3.13: Provide Microsoft with access to relevant customer data during support scenarios
Guidance: Not applicable; Event Grid service doesn't support Customer Lockbox currently.
Responsibility: Not Applicable
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
4.2: Isolate systems storing or processing sensitive information
Guidance: Implement isolation using separate subscriptions and management groups for individual security domains such as environment type and data sensitivity level. You can restrict the level of access to your Azure resources that your applications and enterprise environments demand. You can control access to Azure resources via Azure RBAC.
Responsibility: Customer
4.3: Monitor and block unauthorized transfer of sensitive information
Guidance: 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: Shared
4.4: Encrypt all sensitive information in transit
Guidance: Azure Event Grid requires HTTPS for publishing and supports HTTPS for delivering events to a webhook endpoint. In Azure Global, Event Grid supports both 1.1 and 1.2 versions of TLS, but we strongly recommend that you use the 1.2 version. In national clouds such as Azure Government and Azure operated by 21Vianet in China, Event Grid supports only 1.2 version of TLS.
Responsibility: Customer
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 Event Grid. Implement third-party solution if necessary 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
4.6: Use Azure RBAC to manage access to resources
Guidance: Azure Event Grid supports using Azure Active Directory (Azure AD) to authorize requests to Event Grid resources. With Azure AD, you can use Azure role-based access control (Azure RBAC) to grant permissions to a security principal, which may be a user, or an application service principal.
Responsibility: Customer
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 Event Grid resources and other critical or related resources.
Responsibility: Customer
Vulnerability Management
For more information, see the Azure Security Benchmark: Vulnerability Management.
5.3: Deploy an automated patch management solution for third-party software titles
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
5.4: Compare back-to-back vulnerability scans
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
5.5: Use a risk-rating process to prioritize the remediation of discovered vulnerabilities
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
Inventory and Asset Management
For more information, see the Azure Security Benchmark: Inventory and Asset Management.
6.1: Use automated asset discovery solution
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
6.2: Maintain asset metadata
Guidance: Apply tags to Azure resources giving metadata to logically organize them into a taxonomy.
Responsibility: Customer
6.3: Delete unauthorized Azure resources
Guidance: Use tagging, management groups, and separate subscriptions where appropriate, to organize and track assets. Reconcile inventory on a regular basis and ensure unauthorized resources are deleted from the subscription in a timely manner.
Responsibility: Customer
6.4: Define and maintain an inventory of approved Azure resources
Guidance: Create an inventory of approved Azure resources and approved software for compute resources as per your organizational needs.
Responsibility: Customer
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 subscription(s) using the following built-in policy definitions:
- Not allowed resource types
- Allowed resource types
In addition, use the Azure Resource Graph to query/discover resources within the subscription(s).
Responsibility: Customer
6.6: Monitor for unapproved software applications within compute resources
Guidance: Not applicable; this recommendation is intended for compute resources.
Responsibility: Not Applicable
6.7: Remove unapproved Azure resources and software applications
Guidance: Not applicable; this recommendation is intended for compute resources.
Responsibility: Not Applicable
6.8: Use only approved applications
Guidance: Not applicable; this recommendation is intended for compute resources.
Responsibility: Not Applicable
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
In addition, use the Azure Resource Graph to query/discover resources within the subscription(s).
Responsibility: Customer
6.10: Maintain an inventory of approved software titles
Guidance: Not applicable; this recommendation is intended for compute resources.
Responsibility: Not Applicable
6.11: Limit users' ability to interact with Azure Resource Manager
Guidance: Use Azure Active Directory (Azure AD) Conditional Access to limit users' ability to interact with Azure Resources Manager by configuring "Block access" for the "Microsoft Azure Management" App.
Responsibility: Customer
6.12: Limit users' ability to execute scripts in compute resources
Guidance: Not applicable; this recommendation is intended for compute resources.
Responsibility: Not Applicable
6.13: Physically or logically segregate high risk applications
Guidance: Not applicable; this recommendation is intended for web applications running on Azure App Service or compute resources.
Responsibility: Not Applicable
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 Event Grid service with Azure Policy. Use Azure Policy aliases in the "Microsoft.EventGrid" namespace to create custom policies to audit or enforce the configuration of your Azure Event Grid services.
Azure Resource Manager has the ability to export the template in JavaScript Object Notation (JSON), which should be reviewed to ensure that the configurations meet the security requirements for your organization before deployments.
Responsibility: Customer
7.2: Establish secure operating system configurations
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
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. In addition, you can use Azure Resource Manager templates to maintain the security configuration of your Azure resources required by your organization.
Responsibility: Customer
7.4: Maintain secure operating system configurations
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
7.5: Securely store configuration of Azure resources
Guidance: If using custom Azure Policy definitions for your Event Grid or related resources, use Azure Repos to securely store and manage your code.
Responsibility: Customer
7.6: Securely store custom operating system images
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
7.7: Deploy configuration management tools for Azure resources
Guidance: Use Azure Policy aliases in the "Microsoft.EventGrid" namespace to create custom policies to alert, audit, and enforce system configurations. Additionally, develop a process and pipeline for managing policy exceptions.
Responsibility: Customer
7.8: Deploy configuration management tools for operating systems
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
7.9: Implement automated configuration monitoring for Azure resources
Guidance: Use Microsoft Defender for Cloud to perform baseline scans for your Azure Resources. Additionally, use Azure Policy to alert and audit Azure resource configurations.
Responsibility: Customer
7.10: Implement automated configuration monitoring for operating systems
Guidance: Not applicable; this guideline is intended for compute resources.
Responsibility: Not Applicable
7.11: Manage Azure secrets securely
Guidance: Event Grid uses Shared Access Signature (SAS) token for publishing events to Event Grid topics or domains. Generating SAS tokens with only access to the resources that are needed in a limited time window.
Use managed identities in conjunction with Azure Key Vault to simplify secret management for your cloud applications.
Responsibility: Customer
7.12: Manage identities securely and automatically
Guidance: Event Grid can enable a managed service identity for Azure event grid topics or domains. Use it to forward events to supported destinations such as Service Bus queues and topics, event hubs, and storage accounts.
Responsibility: Customer
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
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 Event Grid), however it does not run on customer content.
It is your responsibility to pre-scan any content being uploaded to non-compute Azure resources. Microsoft cannot access customer data, and therefore cannot conduct anti-malware scans of customer content on your behalf.
Responsibility: Customer
Data Recovery
For more information, see the Azure Security Benchmark: Data Recovery.
9.1: Ensure regular automated back ups
Guidance: Event Grid has an automatic geo disaster recovery (GeoDR) of meta-data not only for new, but all existing domains, topics, and event subscriptions. If an entire Azure region goes down, Event Grid will already have all of your event-related infrastructure metadata synced to a paired region.
Responsibility: Customer
9.2: Perform complete system backups and backup any customer-managed keys
Guidance: Event Grid has an automatic geo disaster recovery (GeoDR) of meta-data not only for new, but all existing domains, topics, and event subscriptions. If an entire Azure region goes down, Event Grid will already have all of your event-related infrastructure metadata synced to a paired region.
Currently, Event Grid doesn’t support customer-managed keys.
Responsibility: Customer
9.3: Validate all backups including customer-managed keys
Guidance: Event Grid has an automatic geo disaster recovery (GeoDR) of meta-data not only for new, but all existing domains, topics, and event subscriptions. If an entire Azure region goes down, Event Grid will already have all of your event-related infrastructure metadata synced to a paired region.
Currently, Event Grid doesn’t support customer-managed keys.
Responsibility: Customer
9.4: Ensure protection of backups and customer-managed keys
Guidance: Enable soft delete and purge protection in Key Vault to protect keys against accidental or malicious deletion.
Currently, Event Grid doesn’t support customer-managed keys.
Responsibility: Customer
Incident Response
For more information, see the Azure Security Benchmark: Incident Response.
10.1: Create an incident response guide
Guidance: Develop an incident response guide for your organization. Ensure there are written incident response plans that define all the roles of personnel as well as the phases of incident handling and management from detection to post-incident review.
Responsibility: Customer
10.2: Create an incident scoring and prioritization procedure
Guidance: Microsoft Defender for Cloud assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Microsoft Defender for Cloud is in the finding or the analytically 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, mark subscriptions using tags and create a naming system to identify and categorize Azure resources, especially those processing sensitive data. It's your responsibility to prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the incident occurred.
Responsibility: Customer
10.3: Test security response procedures
Guidance: Conduct exercises to test your systems' incident response capabilities on a regular cadence to help protect your Azure resources. Identify weak points and gaps and then revise your response plan as needed.
Responsibility: Customer
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 your data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.
Responsibility: Customer
10.5: Incorporate security alerts into your incident response system
Guidance: Export your Microsoft Defender for Cloud alerts and recommendations using the continuous export feature to help identify risks to Azure resources. Continuous export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion. You can use the Microsoft Defender for Cloud data connector to stream the alerts to Microsoft Sentinel.
Responsibility: Customer
10.6: Automate the response to security alerts
Guidance: Use workflow automation feature Microsoft Defender for Cloud to automatically trigger responses to security alerts and recommendations to protect your Azure resources.
Responsibility: Customer
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
Next steps
- See the Azure Security Benchmark V2 overview
- Learn more about Azure security baselines
Feedback
Submit and view feedback for