Azure security baseline for Service Bus

This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Service Bus. 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 Service Bus.

Note

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

Network Security

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

NS-1: Implement security for internal traffic

Guidance: Microsoft Azure Service Bus doesn't support deploying directly into a virtual network. You can't apply certain networking features with the offering's resources, such as:

  • Network security groups (NSGs).
  • Route tables.
  • Other network-dependent appliances, such as an Azure Firewall.

Use Azure Sentinel to discover the use of legacy insecure protocols, such as:

  • Secure Sockets Layer (SSL) and Transport Layer Security (TLS) version 1 (TLSv1).
  • Server Message Block (SMB) version 1 (SMBv1).
  • LAN Manager (LM) and NT LAN Manager (NTLM) version 1 (NTLMv1).
  • wDigest.
  • Unsigned Lightweight Directory Access Protocol (LDAP) binds.
  • Weak ciphers in Kerberos.

For more information, read the following articles:

Responsibility: Microsoft

Azure Security Center monitoring: None

NS-3: Establish private network access to Azure services

Guidance: Using Azure Private Link, enable private access to Service Bus from your virtual networks without crossing the internet.

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

Using Azure virtual network service endpoints, provide secure access to Service Bus. The access goes through an optimized route over the Azure backbone network without crossing the internet.

Responsibility: Customer

Azure Security Center monitoring: None

NS-6: Simplify network security rules

Guidance: Using Azure virtual network service tags, define on NSGs or Azure Firewall the network access controls that are configured for your Service Bus resources. When you create security rules, use service tags in place of specific IP addresses. By specifying the service tag name in the appropriate rule's source or destination field, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes that the service tag encompasses. It automatically updates the service tag as addresses change.

Responsibility: Customer

Azure Security Center monitoring: None

NS-7: Secure Domain Name Service (DNS)

Guidance: Follow the best practices for DNS security to mitigate against common attacks, such as:

  • Dangling DNS
  • DNS amplifications attacks
  • DNS poisoning and spoofing

Do you want to use Azure DNS as your authoritative DNS service? Then protect DNS zones and records from accidental or malicious modification by using Azure role-based access control (Azure RBAC) and resource locks.

Responsibility: Customer

Azure Security Center monitoring: None

Identity Management

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

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

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

  • Microsoft Cloud resources, such as:

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

Make securing Azure AD a high priority in your organization's cloud security practice. To help you assess identity security posture against Microsoft's best practice recommendations, Azure AD provides an identity secure score. Use the score to gauge how closely your configuration matches best practice recommendations. Then you make improvements in your security posture.

Note: Azure AD supports external identities. Users without a Microsoft account can sign in to their applications and resources with their external identity.

Responsibility: Customer

Azure Security Center monitoring: None

IM-2: Manage application identities securely and automatically

Guidance: Service Bus supports managed identities for its Azure resources. Instead of creating service principals to access other resources, use managed identities with Service Bus. Service Bus can natively authenticate to the Azure services and resources that support Azure AD authentication. It authenticates through a predefined access grant rule without using credentials that are hardcoded in source code or configuration files.

Do you want to configure service principals with certificate credentials and fall back to client secrets? Then use Azure AD to create a service principal with restricted permissions at the resource level. In both cases, you can use Key Vault with Azure-managed identities. The runtime environment (such as an Azure function) can then retrieve the credential from the key vault.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Service Bus uses Azure AD to provide identity and access management to:

  • Azure resources
  • Cloud applications
  • On-premises applications

This management applies to enterprise identities, such as employees. It also applies to external identities, including:

  • Partners
  • Vendors
  • Suppliers

With identity and access management, single sign-on (SSO) can manage and secure access to your organization's data and resources. SSO management occurs on-premises and in the cloud. For seamless, secure access and greater visibility and control, connect to Azure AD all of your:

  • Users
  • Applications
  • Devices

For more information, read the following articles:

Responsibility: Customer

Azure Security Center monitoring: None

Privileged Access

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

PA-1: Protect and limit highly privileged users

Guidance: Not applicable; Service Bus doesn't use administrative accounts.

Responsibility: Customer

Azure Security Center monitoring: None

PA-3: Review and reconcile user access regularly

Guidance: To regularly ensure the user accounts and their access are valid, Service Bus uses Azure AD accounts to:

  • Manage its resources.
  • Review user accounts.
  • Access assignments.

Use Azure AD and access reviews to review:

  • Group memberships
  • Access to enterprise applications
  • Role assignments

Azure AD reporting can provide logs to help discover stale accounts. To assist the review process, also use Azure AD Privileged Identity Management (PIM) to create access review report workflows.

You can also configure Azure AD PIM to:

  • Alert you when an excessive number of administrator accounts are created.
  • Identify administrator accounts that are stale or improperly configured.

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

Responsibility: Customer

Azure Security Center monitoring: None

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critically important for the security of sensitive roles, such as:

  • Administrator
  • Developer
  • Critical service operator

Use highly secured user workstations or Azure Bastion for administrative tasks. To deploy a secure and managed user workstation, use one or more of:

  • Azure AD
  • Microsoft Defender Advanced Threat Protection (ATP)
  • Microsoft Intune

You can manage the secured workstations centrally to enforce secured configuration, including:

  • Strong authentication
  • Software and hardware baselines
  • Restricted logical and network access

For more information, read the following articles:

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Service Bus is integrated with Azure RBAC to manage its resources. Azure RBAC lets you manage Azure resource access through role assignments. Assign these roles to:

  • Users
  • Groups
  • Service principals
  • Managed identities

There are predefined built-in roles for certain resources. Inventory or query these roles through tools, such as:

  • Azure CLI
  • Azure PowerShell
  • Azure portal

Always limit the privileges you assign to resources through the Azure RBAC to what the roles require. This practice complements the just-in-time (JIT) approach of Azure AD PIM, and it should be reviewed periodically.

Use built-in roles to grant permissions. Only create custom roles when necessary.

Responsibility: Customer

Azure Security Center monitoring: None

Asset Management

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

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

Guidance: Grant your security teams the Security Reader permissions in your Azure tenant and subscriptions. Then your teams can monitor for security risks using Azure Security Center.

Depending on how you structure the security team responsibilities, a central security team or a local team could be responsible to monitor for security risks. Always aggregate security insights and risks centrally within an organization.

You can apply Security Reader permissions broadly to an entire tenant (root management group). Or scope those permissions to management groups or specific subscriptions.

Note: Extra permissions might be necessary to get visibility into workloads and services.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Give security teams access to a continuously updated inventory of assets on Azure, such as Service Bus. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks. The inventory is also an input to continuous security improvements. Create an Azure AD group to contain your organization's authorized security team. Assign read access to the team for all Service Bus resources. To simplify this process, you can use a single high-level role assignment within your subscription.

To logically organize into a taxonomy, apply tags to your Azure:

  • Resources
  • Resource groups
  • Subscriptions

Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production.

Use Azure virtual machine inventory to automate the collection of information about software on virtual machines. Items that are available from the Azure portal include:

  • Software Name
  • Version
  • Publisher
  • Refresh Time

To get access to install dates and other information, enable guest-level diagnostics. Then bring the Windows event logs into a Log Analytics workspace.

Service Bus doesn't let you run an application or install software on its resources.

Responsibility: Customer

Azure Security Center monitoring: None

AM-3: Use only approved Azure services

Guidance: Using Azure Policy, audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within their subscriptions. When an unapproved service is detected, use Monitor to create rules to trigger alerts.

Responsibility: Customer

Azure Security Center monitoring: None

Logging and Threat Detection

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

LT-1: Enable threat detection for Azure resources

Guidance: Use the Azure Security Center built-in threat detection capability, and enable Azure Defender (formerly Azure Advanced Threat Protection) for your Service Bus resources. Azure Defender for Service Bus provides another layer of security intelligence. It detects unusual and potentially harmful attempts to access or exploit your Service Bus resources.

Forward any logs from Service Bus to your SIEM, which you can use to set up custom threat detections. Monitor different types of Azure assets for potential threats and anomalies. Focus on getting high-quality alerts, which reduce the number of false positives for analysts to sort through. You can source alerts from log data, agents, or other data.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Azure AD provides the following user logs:

  • Sign-ins. The sign-ins report provides information about the usage of managed applications and user sign-in activities.

  • Audit logs. Audit logs provide traceability for all changes that various features make within Azure AD. Examples include changes made to any resources within Azure AD, such as adding or removing:

    • Users
    • Apps
    • Groups
    • Roles
    • Policies
  • Risky sign-ins. A risky sign-in indicates a sign-in attempt that might have been made by someone who isn't the user account's legitimate owner.

  • Users flagged for risk. A risky user indicates a user account that might have been compromised.

You can view the logs in Azure AD reporting. For more sophisticated monitoring and analytics use cases, you can integrate the logs with:

  • Monitor
  • Azure Sentinel
  • Other SIEM/monitoring tools

Azure Security Center can also trigger alerts on certain suspicious activities. These activities include an excessive number of failed authentication attempts or deprecated accounts in the subscription. Besides the basic security hygiene monitoring, Azure Security Center's Threat Protection module can also collect more in-depth security alerts from:

  • Individual Azure compute resources (virtual machines, containers, or app service)
  • Data resources (SQL DB and storage)
  • Azure service layers

This capability lets you see account anomalies inside individual resources.

Responsibility: Customer

Azure Security Center monitoring: None

LT-3: Enable logging for Azure network activities

Guidance: Service Bus isn't intended to deploy into virtual networks. You can't:

  • Enable NSG flow logging.
  • Route traffic through a firewall.
  • Make packet captures.

For security analysis, enable and collect:

  • NSG resource logs
  • NSG flow logs
  • Azure Firewall logs
  • Web Application Firewall (WAF) logs

The security analysis supports:

  • Incident investigations
  • Threat hunting
  • Security alert generation

Send the flow logs to a Log Analytics workspace in Monitor. Then use Traffic Analytics to provide insights.

Service Bus logs all network traffic that it processes for customer access. Enable the network flow capability within your deployed offering resources.

Service Bus doesn't produce or process DNS query logs.

Responsibility: Customer

Azure Security Center monitoring: None

LT-4: Enable logging for Azure resources

Guidance: Activity logs contain all write operations (PUT, POST, and DELETE) for your Service Bus resources. Activity logs are automatically available, but they don't contain read operations (GET). Use activity logs to find an error when troubleshooting. Or use the logs to monitor how a user in your organization modified a resource.

Enable Azure resource logs for Service Bus. To enable resource logs and log data collecting, use Azure Security Center and Azure Policy. These logs can be critical when you investigate security incidents and do forensic exercises.

Service Bus also produces security audit logs for the local administrator accounts. Enable these local admin audit logs.

Responsibility: Customer

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

Azure Policy built-in definitions - Microsoft.ServiceBus:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Resource logs in Service Bus should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0

LT-5: Centralize security log management and analysis

Guidance: Centralize logging storage and analysis to enable correlation. For each log source, make sure you assign:

  • Data owner
  • Access guidance
  • Storage location
  • What tools are used to process and access the data
  • Data retention requirements

Integrate Azure activity logs into your central logging. Ingest logs through Monitor to aggregate security data that's generated by:

  • Endpoint devices
  • Network resources
  • Other security systems

In Monitor, use Log Analytics workspaces to query and do analytics. Use storage accounts for long term and archival storage.

Also enable and onboard data to Azure Sentinel or a third-party SIEM.

Many organizations choose to use Azure Sentinel for "hot" data that's used frequently. The organizations then pick Storage for "cold" data that's used less frequently.

For applications that may run on Service Bus, forward all security-related logs to your SIEM for centralized management.

Responsibility: Customer

Azure Security Center monitoring: None

LT-6: Configure log storage retention

Guidance: Do you have storage accounts or Log Analytics workspaces that are used for storing Service Bus logs? Then set the log retention period using your organization's compliance regulations.

Responsibility: Customer

Azure Security Center monitoring: None

LT-7: Use approved time synchronization sources

Guidance: Not applicable; Service Bus doesn't support configuring your own time synchronization sources.

Service Bus service relies on Microsoft time synchronization sources. It isn't exposed to customers for configuration.

Responsibility: Microsoft

Azure Security Center monitoring: None

Posture and Vulnerability Management

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

PV-1: Establish secure configurations for Azure services

Guidance: Using Azure Blueprints, automate in a single blueprint definition the deployment and configuration of services and application environments, including:

  • Azure Resource Manager templates (ARM templates)
  • Azure RBAC controls
  • Policies

For more information, read the following articles:

Responsibility: Customer

Azure Security Center monitoring: None

PV-2: Sustain secure configurations for Azure services

Guidance: Use Azure Security Center to monitor your configuration baseline. Using the Azure Policy "Deny" and "DeployIfNotExists" policy definitions, enforce secure configuration across Azure compute resources, including:

  • Virtual machines
  • Containers
  • Other compute resources

For more information, read the following articles:

Responsibility: Customer

Azure Security Center monitoring: None

PV-3: Establish secure configurations for compute resources

Guidance: Not applicable; this recommendation is intended for compute resources.

Responsibility: Customer

Azure Security Center monitoring: None

PV-6: Make software vulnerability assessments

Guidance: Microsoft does vulnerability management on the underlying systems that support Service Bus.

Responsibility: Microsoft

Azure Security Center monitoring: None

PV-8: Conduct regular attack simulation

Guidance: As required, conduct penetration testing or red team activities on your Azure resources. Ensure remediation of all critical security findings.

To make sure your penetration tests don't violate Microsoft policies, follow the Microsoft Cloud Penetration Testing Rules of Engagement. Use Microsoft's strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed:

  • Cloud infrastructure
  • Services
  • Applications

For more information, read the following articles:

Responsibility: Customer

Azure Security Center monitoring: None

Endpoint Security

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

ES-2: Use centrally managed modern antimalware software

Guidance: Microsoft antimalware is enabled on the underlying host that supports Azure services (for example, Azure App Service). It doesn't run on customer content.

Responsibility: Microsoft

Azure Security Center monitoring: None

ES-3: Ensure antimalware software and signatures are updated

Guidance: Update antimalware signatures rapidly and consistently. To ensure all endpoints are up to date with the latest signatures, follow the recommendations in Azure Security Center: "Compute & Apps". For Windows, Microsoft Antimalware automatically installs the latest signatures and engine updates by default. If you're working in a Linux environment, use a third-party antimalware solution. For more information, see the following references:

Responsibility: Microsoft

Azure Security Center monitoring: None

Backup and Recovery

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

BR-1: Ensure regular automated backups

Guidance: Configure geo-disaster recovery for Azure Service Bus. What happens when entire Azure regions or datacenters (if no availability zones are used) experience downtime? Then data processing must continue to operate in another region or datacenter. Geo-disaster recovery and geo-replication are important features for any enterprise. Azure Service Bus supports both geo-disaster recovery and geo-replication, at the namespace level.

Responsibility: Customer

Azure Security Center monitoring: None

BR-2: Encrypt backup data

Guidance: Service Bus provides encryption of data at rest with Azure Storage Service Encryption (Azure SSE). Service Bus relies on Storage to store the data. By default, all the data that's stored with Storage is encrypted using Microsoft-managed keys. If you use Key Vault for storing customer-managed keys, do automated backups of your keys regularly.

Ensure regular automated backups of your Key Vault secrets with the Backup-AzKeyVaultSecret PowerShell command.

Responsibility: Shared

Azure Security Center monitoring: None

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

Guidance: Periodically make sure you can restore backed-up customer-managed keys.

Responsibility: Customer

Azure Security Center monitoring: None

BR-4: Mitigate risk of lost keys

Guidance: Have measures in place to prevent and recover from the loss of keys. To protect keys against accidental or malicious deletion, enable soft delete and purge protection in Key Vault.

Responsibility: Customer

Azure Security Center monitoring: None

Next steps