Azure security baseline for Azure Bastion

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

Note

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

Network Security

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

NS-1: Implement security for internal traffic

Guidance: When you deploy Azure Bastion resources you must create or use an existing virtual network. Ensure that all Azure virtual networks follow an enterprise segmentation principle that aligns to the business risks. Any system that could incur higher risk for the organization should be isolated within its own virtual network and sufficiently secured with a network security group (NSG).

Azure Bastion service requires following ports need to be open for service to function properly:

  • Ingress Traffic:

    • Ingress Traffic from public internet: The Azure Bastion will create a public IP that needs port 443 enabled on the public IP for ingress traffic. Port 3389/22 are NOT required to be opened on the AzureBastionSubnet.

    • Ingress Traffic from Azure Bastion control plane: For control plane connectivity, enable port 443 inbound from GatewayManager service tag. This enables the control plane, that is, Gateway Manager to be able to communicate with Azure Bastion.

  • Egress Traffic:

    • Egress Traffic to target virtual machines (VMs): Azure Bastion will reach the target VMs over private IP. The NSGs need to allow egress traffic to other target VM subnets for port 3389 and 22.

    • Egress Traffic to other public endpoints in Azure: Azure Bastion needs to be able to connect to various public endpoints within Azure (for example, for storing diagnostics logs and metering logs). For this reason, Azure Bastion needs outbound to 443 to AzureCloud service tag.

Connectivity to Gateway Manager and Azure service tag is protected (locked down) by Azure certificates. External entities, including the consumers of those resources, can't communicate on these endpoints.

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

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
All Internet traffic should be routed via your deployed Azure Firewall Azure Security Center has identified that some of your subnets aren't protected with a next generation firewall. Protect your subnets from potential threats by restricting access to them with Azure Firewall or a supported next generation firewall AuditIfNotExists, Disabled 3.0.0-preview
Subnets should be associated with a Network Security Group Protect your subnet from potential threats by restricting access to it with a Network Security Group (NSG). NSGs contain a list of Access Control List (ACL) rules that allow or deny network traffic to your subnet. AuditIfNotExists, Disabled 3.0.0

NS-2: Connect private networks together

Guidance: Azure Bastion does not expose any endpoints that can be accessed via a private network. Azure Bastion supports deploying into a peered network to centralize your Bastion deployment and enable cross-network connectivity.

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: Azure Bastion is integrated with Azure Active Directory (Azure AD) which is Azure's default identity and access management service. Users can access the Azure portal using Azure AD authentication to manage Azure Bastion service (create, update, and delete Bastion resources).

Connecting to virtual machines using Azure Bastion relies on either an SSH key or username/password, and currently does not support the use of Azure AD credentials.

You can store your SSH keys as Azure Key Vault secrets and use these secrets to connect to your virtual machines using Azure Bastion. You can control user access to these secrets by assigning Key Vault access policies either on individual users or Azure AD groups. Your users will need the following permissions to use this method to connect to a virtual machine:

  • Get access to the secrets stored in the chosen Azure Key Vault
  • List access to the secrets stored in the chosen Azure Key Vault

In addition to an SSH key or username/password, when connecting to virtual machines using Azure Bastion your user will need the following role assignments:

  • Reader role on the target virtual machine
  • Reader role on the NIC with the private IP of the target virtual machine
  • Reader role on the Azure Bastion resource

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Azure Bastion doesn't support SSO for authentication when authenticating to virtual machine resources, only SSH or username/password are supported. However, Azure Bastion uses Azure Active Directory (Azure AD) to provide identity and access management for the overall service. Users can authenticate to Azure AD to access and manage their Azure Bastion resources, and experience seamless single-sign on with their own synced enterprise identities via Azure AD Connect.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Azure Bastion is integrated with Azure Active Directory (Azure AD) for access and management of the service. Configure Azure Active Directory Multi-Factor Authentication for your Azure AD tenant. Azure AD supports strong authentication controls through multi-factor authentication (MFA) and strong passwordless methods.

  • Multifactor authentication: Enable Azure AD multifactor authentication and follow Azure Security Center identity and access management recommendations for your multifactor authentication setup. Multifactor authentication can be enforced on all users, select users, or at the per-user level based on sign-in conditions and risk factors.
  • Passwordless authentication: Three passwordless authentication options are available: Windows Hello for Business, Microsoft Authenticator app, and on-premises authentication methods such as smart cards.

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

IM-5: Monitor and alert on account anomalies

Guidance: Enable diagnostics logs for Azure Bastion remote sessions and use these logs to view which users connected to which workloads, at what time, from where, and other such relevant logging information. Create alerts for certain logged Bastion sessions using Azure Monitor to be notified when there are anomalies detected in the logs.

Responsibility: Customer

Azure Security Center monitoring: None

IM-6: Restrict Azure resource access based on conditions

Guidance: You can only access Azure Bastion service via the Azure portal, access to Azure portal can be restricted using Azure Active Directory (Azure AD) conditional access. Use Azure AD conditional access for more granular access control based on user-defined conditions, such as requiring user logins from certain IP ranges to use multifactor authentication.

Customer can also use different role-based access control policies at domain joined virtual machines level to further restrict access to the virtual machine.

Responsibility: Customer

Azure Security Center monitoring: None

Privileged Access

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

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

Guidance: Azure Bastion uses Azure role-based access control (Azure RBAC) to isolate access to business-critical systems by restricting which accounts are granted access to connect to certain virtual machines. Be sure to follow the principle of least privilege so that users only have the permissions needed to perform their specific tasks.

Ensure that you also restrict access to the management, identity, and security systems that have administrative access to your business critical access such as Active Directory Domain Controllers (DCs), security tools, and system management tools with agents installed on business critical systems. Attackers who compromise these management and security systems can immediately weaponize them to compromise business critical assets.

All types of access controls should be aligned to your enterprise segmentation strategy to ensure consistent access control.

Responsibility: Customer

Azure Security Center monitoring: None

PA-3: Review and reconcile user access regularly

Guidance: Azure Bastion uses Azure Active Directory (Azure AD) accounts and Azure RBAC to manage its resources. Review user accounts and access assignment regularly to ensure the accounts and their access are valid. You can use Azure AD access reviews to review group memberships, access to enterprise applications, and role assignments. Azure AD reporting can provide logs to help discover stale accounts. You can also use Azure AD Privileged Identity Management to create access review report workflow to facilitate the review process.

In addition, Azure Privileged Identity Management can also be configured to alert when an excessive number of administrator accounts are created, and to identify administrator accounts that are stale or improperly configured.

Responsibility: Customer

Azure Security Center monitoring: None

PA-4: Set up emergency access in Azure AD

Guidance: Azure Bastion is integrated with Azure Active Directory (Azure AD) and Azure RBAC to manage its resources. To prevent being accidentally locked out of your Azure AD organization, set up an emergency access account for access when normal administrative accounts cannot be used. Emergency access accounts are usually highly privileged, and they should not be assigned to specific individuals. Emergency access accounts are limited to emergency or "break glass"' scenarios where normal administrative accounts can't be used.

You should ensure that the credentials (such as password, certificate, or smart card) for emergency access accounts are kept secure and known only to individuals who are authorized to use them only in an emergency.

Responsibility: Customer

Azure Security Center monitoring: None

PA-5: Automate entitlement management

Guidance: Azure Bastion is integrated with Azure Active Directory (Azure AD) and Azure RBAC to manage its resources. Use Azure AD entitlement management features to automate access request workflows, including access assignments, reviews, and expiration. Dual or multi-stage approval is also supported.

Responsibility: Customer

Azure Security Center monitoring: None

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critically important for the security of sensitive roles like administrators, developers, and critical service operators. Depending on your requirements, you can use highly secured user workstations for performing administrative management tasks with your Azure Bastion resources in production environments. Use Azure Active Directory (Azure AD), Microsoft Defender Advanced Threat Protection (ATP), and/or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. The secured workstations can be centrally managed to enforce secured configuration, including strong authentication, software and hardware baselines, and restricted logical and network access.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Azure Bastion is integrated with Azure role-based access control (RBAC) to manage its resources. Azure RBAC allows you to manage Azure resource access through role assignments. You can assign these built-in 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. The privileges you assign to resources through the Azure RBAC should be always limited to what is required by the roles. This complements the just in time (JIT) approach of Azure Active Directory (Azure AD) Privileged Identity Management (PIM) and should be reviewed periodically. Use built-in roles to allocate permission and only create custom roles when required.

When connecting to virtual machines using Azure Bastion your user will need the following role assignments:

  • Reader role on the target virtual machine
  • Reader role on the NIC with the private IP of the target virtual machine
  • Reader role on the Azure Bastion resource

For more information, see the following references:

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: Ensure security teams are granted Security Reader permissions in your Azure tenant and subscriptions so they can monitor for security risks using Azure Security Center.

Depending on how security team responsibilities are structured, monitoring for security risks could be the responsibility of a central security team or a local team. That said, security insights and risks must always be aggregated centrally within an organization.

Security Reader permissions can be applied broadly to an entire tenant (Root Management Group) or scoped to management groups or specific subscriptions.

Note: Additional permissions might be required 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: Apply tags to your Azure Bastion resources, resource groups, and subscriptions to logically organize them into a taxonomy. Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production. Ensure that security teams have access to a continuously updated inventory of assets on Azure. They can use Azure Resource Graph to query and discover all resources in your subscriptions, including Azure services, applications, and network resources.

Responsibility: Customer

Azure Security Center monitoring: None

AM-3: Use only approved Azure services

Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment, this includes being able to allow or deny deployments of Azure Bastion resources. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules to trigger alerts when a non-approved service is detected.

Responsibility: Customer

Azure Security Center monitoring: None

AM-4: Ensure security of asset lifecycle management

Guidance: Remove access to Azure Bastion resources that have been deployed when they are no longer needed to minimize attack surface. Users can manage their Azure Bastion resources via the Azure portal, CLI, or REST APIs. You can also delete or force-disconnect an ongoing remote session if it is no longer needed or identified as a potential threat.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Azure Bastion is integrated with Azure Active Directory (Azure AD) for identity and authentication. You can use Azure Conditional Access to limit users' ability to interact with Azure Resources Manager by configuring "Block access" for the "Microsoft Azure Management" App.

Responsibility: Customer

Azure Security Center monitoring: None

Logging and Threat Detection

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

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

Guidance: Azure Bastion integrates with Azure Active Directory (Azure AD) and the service is accessed over the Azure portal. By default management actions to the service (such as create, update, and delete) are captured via the Azure Activity Log. Users should also enable Azure Bastion resource logs, such as session BastionAuditLogs to track bastion sessions.

Azure AD provides the following user logs that can be viewed in Azure AD reporting or integrated with Azure Monitor, Azure Sentinel or other SIEM/monitoring tools for more sophisticated monitoring and analytics use cases:

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

  • Audit logs - Provides traceability through logs for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles and policies.

  • Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.

  • Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.

Azure Security Center can also alert on certain suspicious activities such as an excessive number of failed authentication attempts, and deprecated accounts in the subscription. In addition to 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 (such as virtual machines, containers, app service), data resources (such as SQL DB and storage), and Azure service layers. This capability allows you to see account anomalies inside the individual resources.

Responsibility: Customer

Azure Security Center monitoring: None

LT-3: Enable logging for Azure network activities

Guidance: Enable Azure Bastion resource logs, use these diagnostics logs to view which users connected to which workloads, at what time, from where, and other such relevant logging information. Users can configure these logs to be sent to a storage account for long-term retention and auditing.

Enable and collect network security group (NSG) resource logs and NSG flow logs on the network security groups that are applied to the virtual networks you have your Azure Bastion resource deployed. These logs can then be used for analyzing network security and to support incident investigations, threat hunting, and security alert generation. You can send the flow logs to an Azure Monitor Log Analytics workspace and then use Traffic Analytics to provide insights.

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

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Network Watcher should be enabled Network Watcher is a regional service that enables you to monitor and diagnose conditions at a network scenario level in, to, and from Azure. Scenario level monitoring enables you to diagnose problems at an end to end network level view. It is required to have a network watcher resource group to be created in every region where a virtual network is present. An alert is enabled if a network watcher resource group is not available in a particular region. AuditIfNotExists, Disabled 3.0.0

LT-4: Enable logging for Azure resources

Guidance: Activity logs, which are automatically available, contain all write operations (PUT, POST, DELETE) for your Azure Bastion resources except read operations (GET). Activity logs can be used to find an error when troubleshooting or to monitor how a user in your organization modified a resource.

Responsibility: Customer

Azure Security Center monitoring: None

LT-5: Centralize security log management and analysis

Guidance: Centralize logging storage and analysis to enable correlation. For each log source, ensure you have assigned a data owner, access guidance, storage location, what tools are used to process and access the data, and data retention requirements.

Ensure you are integrating Azure activity logs into your central logging. Ingest logs via Azure Monitor to aggregate security data generated by endpoint devices, network resources, and other security systems. In Azure Monitor, use Log Analytics workspaces to query and perform analytics, and use Azure Storage accounts for long term and archival storage.

In addition, enable and onboard data to Azure Sentinel or a third-party SIEM.

Many organizations choose to use Azure Sentinel for “hot” data that is used frequently and Azure Storage for “cold” data that is used less frequently.

Responsibility: Customer

Azure Security Center monitoring: None

LT-6: Configure log storage retention

Guidance: Ensure that any storage accounts or Log Analytics workspaces used for storing Azure Bastion logs has the log retention period set according to your organization's compliance regulations.

In Azure Monitor, you can set your Log Analytics workspace retention period according to your organization's compliance regulations.

Responsibility: Customer

Azure Security Center monitoring: None

Incident Response

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

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

Guidance: Ensure your organization has processes to respond to security incidents, has updated these processes for Azure, and is regularly exercising them to ensure readiness.

Responsibility: Customer

Azure Security Center monitoring: None

IR-2: Preparation – setup incident notification

Guidance: Set up security incident contact information in Azure Security Center. This contact information is 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. You also have options to customize incident alert and notification in different Azure services based on your incident response needs.

Responsibility: Customer

Azure Security Center monitoring: None

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

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

High-quality alerts can be built based on experience from past incidents, validated community sources, and tools designed to generate and clean up alerts by fusing and correlating diverse signal sources.

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

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

Responsibility: Customer

Azure Security Center monitoring: None

IR-4: Detection and analysis – investigate an incident

Guidance: Ensure analysts can query and use diverse data sources as they investigate potential incidents, to build a full view of what happened. Diverse logs should be collected to track the activities of a potential attacker across the kill chain to avoid blind spots. You should also ensure insights and learnings are captured for other analysts and for future historical reference.

The data sources for investigation include the centralized logging sources that are already being collected from the in-scope services and running systems, but can also include:

  • Network data – use network security groups' flow logs, Azure Network Watcher, and Azure Monitor to capture network flow logs and other analytics information.

  • Snapshots of running systems:

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

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

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

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

Responsibility: Customer

Azure Security Center monitoring: None

IR-5: Detection and analysis – prioritize incidents

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

Azure Security Center assigns a severity to each alert to help you prioritize which alerts 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, mark resources using tags and create a naming system to identify and categorize Azure resources, especially those processing sensitive data. It is your responsibility to prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the incident occurred.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Automate manual repetitive tasks to speed up response time and reduce the burden on analysts. Manual tasks take longer to execute, slowing each incident and reducing how many incidents an analyst can handle. Manual tasks also increase analyst fatigue, which increases the risk of human error that causes delays, and degrades the ability of analysts to focus effectively on complex tasks. Use workflow automation features in Azure Security Center and Azure Sentinel to automatically trigger actions or run a playbook to respond to incoming security alerts. The playbook takes actions, such as sending notifications, disabling accounts, and isolating problematic networks.

Responsibility: Customer

Azure Security Center monitoring: None

Posture and Vulnerability Management

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

PV-1: Establish secure configurations for Azure services

Guidance: Define and implement standard security configurations for Azure Bastion with Azure Policy. Use Azure Policy aliases in the "Microsoft.Network" namespace to create custom policies to audit or enforce the network configuration of your Azure Bastion. Customers can also establish secure configurations by leveraging Azure Blueprints or ARM templates to deploy Bastion resources securely and consistently.

Responsibility: Customer

Azure Security Center monitoring: None

PV-2: Sustain secure configurations for Azure services

Guidance: Define and implement standard security configurations for Azure Bastion with Azure Policy. Use Azure Policy aliases in the "Microsoft.Network" namespace to create custom policies to audit or enforce the network configuration of your Bastion resources.

Responsibility: Customer

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 and ensure remediation of all critical security findings.

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

Governance and Strategy

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

GS-1: Define asset management and data protection strategy

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

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

  • Data classification standard in accordance with the business risks

  • Security organization visibility into risks and asset inventory

  • Security organization approval of Azure services for use

  • Security of assets through their lifecycle

  • Required access control strategy in accordance with organizational data classification

  • Use of Azure native and third-party data protection capabilities

  • Data encryption requirements for in-transit and at-rest use cases

  • Appropriate cryptographic standards

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

GS-2: Define enterprise segmentation strategy

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

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

Ensure that the segmentation strategy is implemented consistently across control types including network security, identity and access models, and application permission/access models, and human process controls.

Responsibility: Customer

Azure Security Center monitoring: None

GS-3: Define security posture management strategy

Guidance: Continuously measure and mitigate risks to your individual assets and the environment they are hosted in. Prioritize high value assets and highly-exposed attack surfaces, such as published applications, network ingress and egress points, user and administrator endpoints, etc.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Ensure you document and communicate a clear strategy for roles and responsibilities in your security organization. Prioritize providing clear accountability for security decisions, educating everyone on the shared responsibility model, and educate technical teams on technology to secure the cloud.

Responsibility: Customer

Azure Security Center monitoring: None

GS-5: Define network security strategy

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

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

  • Centralized network management and security responsibility

  • Virtual network segmentation model aligned with the enterprise segmentation strategy

  • Remediation strategy in different threat and attack scenarios

  • Internet edge and ingress and egress strategy

  • Hybrid cloud and on-premises interconnectivity strategy

  • Up-to-date network security artifacts (e.g. network diagrams, reference network architecture)

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

GS-6: Define identity and privileged access strategy

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

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

  • A centralized identity and authentication system and its interconnectivity with other internal and external identity systems

  • Strong authentication methods in different use cases and conditions

  • Protection of highly privileged users

  • Anomaly user activities monitoring and handling

  • User identity and access review and reconciliation process

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

GS-7: Define logging and threat response strategy

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

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

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

  • A well-defined incident response process aligning with NIST or another industry framework

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

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

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

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

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

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

Next steps