Azure security baseline for Event Grid

  • Article
  • 25 minutes to read

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:

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:

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.

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.

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