Azure security baseline for Microsoft Sentinel

  • Article
  • 11 minutes to read

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

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 Microsoft Sentinel, and those for which the global guidance is recommended verbatim, have been excluded. To see how Microsoft Sentinel completely maps to the Azure Security Benchmark, see the full Microsoft Sentinel security baseline mapping file.

Network Security

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

NS-1: Implement security for internal traffic

Guidance: Not applicable. Microsoft Sentinel isn't designed to deploy in to an Azure Virtual Network. All of the underlying infrastructure for the service is fully managed by Microsoft.

Microsoft Sentinel doesn't support deploying directly into a virtual network. So, you can't use certain networking features with the offering's resources like:

  • Network security groups
  • Route tables
  • Other network-dependent appliances like an Azure Firewall

Responsibility: Microsoft

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: Microsoft Sentinel uses Azure Active Directory (Azure AD) as its default identity and access management service. Standardize Azure AD to govern your organization's identity and access management in:

  • Microsoft Cloud resources. Resources include:

    • The Azure portal

    • Azure Storage

    • Azure Linux and Windows virtual machines

    • 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.

Securing Azure AD should be a high priority in your organization's cloud security practice. Azure AD provides an identity secure score to help you assess identity security posture relative to Microsoft's best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations, and to make improvements in your security posture.

Note: Azure AD supports external identities that allow users without Microsoft accounts to sign in to their applications and resources.

Responsibility: Shared

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

Guidance: Microsoft Sentinel uses Azure AD to provide identity and access management for Azure resources, cloud applications, and on-premises applications. Identities include enterprise identities like employees, and external identities like partners, vendors, and suppliers. Azure AD identity and access management provide single sign-on (SSO) to manage and secure access to your organization's on-premises and cloud data and resources.

Responsibility: Customer

Privileged Access

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

PA-3: Review and reconcile user access regularly

Guidance: Microsoft Sentinel uses Azure AD accounts to manage its resources and review user accounts. Azure AD accesses assignments regularly to ensure the accounts and their access are valid. You can use Azure AD and 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 (PIM) to create access review report workflows to facilitate the review process.

In addition, Azure AD PIM can also be configured to alert you when an excessive number of administrator accounts are created, and to 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. You will need to manage these users separately.

Responsibility: Customer

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critical for security of sensitive roles like administrator, developer, and critical service operator. Use highly secured user workstations and Azure Bastion for administrative tasks.

Use Azure AD, Microsoft Defender Advanced Threat Protection (ATP), or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. You can manage secured workstations centrally to enforce a security configuration that includes:

  • Strong authentication

  • Software and hardware baselines

  • Restricted logical and network access

For more information, see the following references:

Responsibility: Customer

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

Guidance: Microsoft Sentinel is integrated with Azure role-based access control (Azure RBAC) to manage its resources. Azure RBAC allows you to manage Azure resource access through role assignments. You can assign roles to users, groups, service principals, and managed identities. Certain resources have pre-defined, built-in roles. You can inventory or query these roles through tools like Azure CLI, Azure PowerShell, or the Azure portal.

Limit the privileges you assign to resources through Azure RBAC to what the roles require. This practice complements the just-in-time (JIT) approach of Azure AD PIM. Review roles and assignments periodically.

Use built-in roles to allocate permissions and only create custom roles when required.

Responsibility: Customer

Data Protection

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

DP-4: Encrypt sensitive information in transit

Guidance: To complement access control, use encryption to protect data in transit against out-of-band attacks like traffic capture. Use encryption to ensure that attackers can't easily read or modify the data.

Azure Sentinel supports data encryption in transit with Transport Layer Security (TLS) v1.2 or greater.

This requirement is optional for traffic on private networks, but is critical for traffic on external and public networks. For HTTP traffic, make sure any clients that connect to your Azure resources can use TLS v1.2 or greater.

For remote management, use secure shell (SSH) for Linux or remote desktop protocol (RDP) and TLS for Windows. Don't use an unencrypted protocol. Disable weak ciphers and obsolete SSL, TLS, and SSH versions and protocols.

By default, Azure provides encryption for data in transit between Azure data centers.

Responsibility: Customer

DP-5: Encrypt sensitive data at rest

Guidance: To complement access controls, Azure Sentinel encrypts data at rest to protect against out-of-band attacks accessing underlying storage. Encryption helps ensure that attackers can't easily read or modify the data.

Azure provides encryption for data at rest by default. For highly sensitive data, you can implement more encryption at rest on Azure resources where available. Azure manages your encryption keys by default, and also provides options to manage your own keys. Customer-managed keys meet regulatory requirements for certain Azure services.

Responsibility: Customer

Asset Management

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

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

Guidance: Make sure to grant security teams Security Reader permissions in your Azure tenant and subscriptions, so they can monitor for security risks by using Microsoft Defender for Cloud.

Monitoring for security risks could be the responsibility of a central security team or a local team, depending on how you structure responsibilities. Always aggregate security insights and risks centrally within an organization.

You can apply Security Reader permissions broadly to an entire tenant's Root Management Group, or scope permissions to specific management groups or subscriptions.

Note: Visibility into workloads and services might require more permissions.

Responsibility: Customer

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

Guidance: Make sure that security teams have access to a continuously updated inventory of assets on Azure, like Microsoft Sentinel. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks, and as input to continuous security improvements. Create an Azure AD group to contain your organization's authorized security team and assign it read access to all Microsoft Sentinel resources. You can simplify the process with a single high-level role assignment in your subscription.

Apply tags to your Azure resources, resource groups, and subscriptions to logically organize them into a taxonomy. Each tag consists of a name and 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 collecting information about software on virtual machines (VMs). Software Name, Version, Publisher, and Refresh Time are available from the Azure portal. To access install dates and other information, enable guest-level diagnostics and bring the Windows Event Logs into a Log Analytics workspace.

Use Microsoft Defender for Cloud Adaptive Application Controls to specify which file types a rule might or might not apply to.

Responsibility: Customer

AM-3: Use only approved Azure services

Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within subscriptions. You can also use Azure Monitor to create rules that trigger alerts when they detect an unapproved service.

Responsibility: Customer

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: Microsoft Sentinel doesn't provide native capabilities to monitor security threats related to its resources.

Forward any logs from Microsoft Sentinel to your SIEM system. You can use your SIEM to set up custom threat detections.

Make sure to monitor different types of Azure assets for potential threats and anomalies. Focus on getting high-quality alerts, to reduce false positives for analysts to sort through. You can source alerts from log data, agents, or other data.

Responsibility: Customer

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

Guidance: Azure AD provides the following user logs. You can view the logs in Azure AD reporting. You can integrate with Azure Monitor, Microsoft Sentinel, or other SIEM and monitoring tools for sophisticated monitoring and analytics use cases:

  • Sign-ins - Provides information about managed application usage and user sign-in activities.

  • Audit logs - Provides traceability through logs for all changes made by various Azure AD features. Audit logs include changes made to any resource within Azure AD. Changes include adding or removing users, apps, groups, roles, and policies.

  • Risky sign-ins - An indicator for sign-in attempts by someone who might not be the legitimate owner of a user account.

  • Users flagged for risk - An indicator for a user account that might have been compromised.

Microsoft Defender for Cloud can also trigger alerts about suspicious activities like an excessive number of failed authentication attempts, or about deprecated accounts.

In addition to basic security hygiene monitoring, Microsoft Defender for Cloud's Threat Protection module can collect more in-depth security alerts from:

  • Individual Azure compute resources like VMs, containers, and app service

  • Data resources like Azure SQL Database and Azure Storage

  • Azure service layers

This capability gives you visibility into account anomalies in individual resources.

Responsibility: Customer

LT-4: Enable logging for Azure resources

Guidance: Automation activity logs are available automatically. The logs contain all PUT, POST, and DELETE, but not GET, operations for your Microsoft Sentinel resources. You can use activity logs to find errors when troubleshooting, or to monitor how users modified resources.

Microsoft Sentinel currently doesn't produce Azure resource logs.

Responsibility: Customer

Posture and Vulnerability Management

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

PV-6: Perform software vulnerability assessments

Guidance: Microsoft performs vulnerability management on the underlying systems that support Microsoft.

Responsibility: Microsoft

PV-8: Conduct regular attack simulation

Guidance: Conduct penetration testing or red team activities on your Azure resources as needed, and ensure remediation of all critical security findings.

Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests don't violate Microsoft policies. Use Microsoft's Red Teaming strategy and execution. Do live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.

Responsibility: Customer

Backup and Recovery

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

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

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

Responsibility: Customer

BR-4: Mitigate risk of lost keys

Guidance: Make sure you have measures in place to prevent and recover from key loss. Enable soft delete and purge protection in Azure Key Vault to protect keys against accidental or malicious deletion.

Responsibility: Customer

Next steps