Security Alerts and Smart Alert Groups

Azure Security Center (ASC) continuously monitors your Azure resources, subscriptions, and workloads for security threats. When it detects a potential threat, it generates a security alert. Each alert contains: - Alert name – descriptive title (e.g., 'SSH brute force attack detected') - Severity – High, Medium, or Low (determined by the confidence and impact) - Description – detailed explanation of the threat - Affected resource – the Azure resource under attack - Mitigation steps – recommended actions to remediate - Alert ID – unique identifier - Time generated – timestamp in UTC

Alerts are triggered by:

ASC uses three severity levels: - High: A confirmed security breach that requires immediate attention (e.g., a known malicious IP connecting to a VM) - Medium: A suspicious activity that indicates a potential breach (e.g., a failed login followed by a successful login from an unusual location) - Low: A benign but notable event that may indicate a deeper threat (e.g., a security policy violation that could be exploited)

The severity is based on the detection model's confidence and the potential impact. For example, a brute force attack that succeeded is High; one that failed is Medium.

Smart alert groups (also called fusion alerts) are a feature of Microsoft Defender for Cloud that automatically aggregates related alerts into a single incident. This reduces alert fatigue by grouping alerts that are part of the same attack chain. For example:

These three alerts might be grouped into a single smart alert group titled 'Multi-stage incident involving [resource]'. The group contains: - Group ID – unique identifier - Start time – earliest alert time - End time – latest alert time - Severity – highest severity among grouped alerts - Alerts – list of individual alerts with their details

The grouping is performed by machine learning models that analyze temporal and causal relationships. For example, if alert A (malicious PowerShell) occurs within 5 minutes of alert B (network connection to C2 server), they are likely related. The default time window for correlation is 24 hours, but this is not configurable.

To further reduce noise, you can create alert suppression rules. These rules automatically dismiss alerts that match certain criteria. For example, if you have a test VM that regularly performs scans, you can suppress alerts from that VM. Suppression rules are defined at the subscription level and apply to all resources in that subscription. Key properties: - Alert name – the exact alert name to suppress (e.g., 'SSH brute force attack detected') - Suppression scope – subscription or resource group - Conditions – additional filters like resource name, IP address, or user - Duration – how long the suppression is active (e.g., 24 hours, 7 days, or indefinite) - Reason – justification for suppression (for audit purposes)

Note: Suppression rules do not prevent alert generation; they simply hide the alert from the alerts list. The alert is still stored and can be viewed in the activity log.

You can automate responses to alerts using Azure Logic Apps (playbooks). For example, when a high-severity alert is triggered, you can automatically:

Playbooks are triggered by alert creation or when an alert is dismissed. They are defined in ASC under 'Security automation' and require a Logic App with a specific trigger (e.g., 'When a Microsoft Defender for Cloud alert is created').

Azure Sentinel is a cloud-native SIEM that can ingest alerts from ASC. When connected, Sentinel provides advanced correlation, investigation, and hunting capabilities. You can forward ASC alerts to Sentinel via the 'Continuous export' setting in ASC, which sends alerts to a Log Analytics workspace. Sentinel then uses its own analytics rules to create incidents from alerts.

Each alert goes through states: - Active – newly generated - Dismissed – manually dismissed or suppressed - Resolved – marked as resolved by a user or automated process - In Progress – being investigated

You can change the state via the portal or API. Alerts are retained for 90 days in the ASC database.

You can manage alerts programmatically using Azure PowerShell or Azure CLI. For example:

List alerts:

Get-AzSecurityAlert -SubscriptionId <subscription-id>

Dismiss an alert:

Set-AzSecurityAlert -AlertName <alert-name> -Status Dismissed

Create a suppression rule (Azure CLI):

az security alert-suppression-rule create \
  --name "SuppressTestVM" \
  --alert-rule-name "SSH brute force attack detected" \
  --expiration-date-utc "2025-12-31" \
  --reason "Test VM"

Get smart alert groups:

Get-AzSecurityAlert -IncludeSmartGrouping

A large bank uses Azure for its trading applications. They need to detect and respond to threats quickly to meet PCI DSS and SOX compliance. They enable Microsoft Defender for Cloud for all subscriptions and configure data collection with 'All Events' for VMs running Windows Server 2022. They receive hundreds of alerts daily, many false positives from security scanning tools. To reduce noise, they create suppression rules for specific alert names like 'VM detected as vulnerable to brute force' from their internal scanners by filtering on source IP ranges. They also create a playbook that automatically isolates any VM that triggers a 'Malware detected' alert by applying an NSG rule that blocks all inbound/outbound traffic except to a forensic management subnet. The playbook also sends a Slack notification to the security team. They use smart alert groups to see multi-stage attacks; for example, a phishing alert combined with a lateral movement alert is grouped into a single incident, allowing the SOC to respond holistically. The bank retains alerts for 90 days for audit purposes and exports them to Azure Sentinel for advanced hunting.

A SaaS company hosts customer workloads in separate Azure subscriptions. They use Azure Lighthouse to manage multiple tenants. They need to ensure alerts from each tenant are visible centrally. They enable Defender for Cloud at the management group level and use Azure Policy to enforce data collection settings across all subscriptions. They create suppression rules for common false positives like 'SSH brute force' on their bastion hosts. They use smart alert groups to reduce alert fatigue: if a single tenant's resources show multiple low-severity alerts within 24 hours, they are grouped as a potential breach. They also set up automated response playbooks that run only for high-severity alerts to avoid costly downtime. For example, a 'Ransomware detected' alert triggers a playbook that snapshots the affected VM and then shuts it down. The company monitors alert volume and adjusts suppression rules quarterly. A common misconfiguration is failing to exclude management resources from alerting, leading to hundreds of false positives from admin activities. They resolve this by creating suppression rules for alerts from specific resource groups.

A hospital uses Azure for its EHR system. They must protect patient data and comply with HIPAA. They enable Defender for Cloud and configure advanced threat detection for Azure SQL Database to detect SQL injection attempts. They receive alerts for 'Access from unusual location' when doctors travel. To avoid false positives, they create suppression rules for known IP ranges of hospital offices. They use smart alert groups to correlate a SQL injection alert with a subsequent data export alert, which indicates a potential data breach. They have a playbook that automatically triggers a Logic App to revoke the compromised user's access and send an alert to the privacy officer. They also integrate with Azure Sentinel for long-term log retention (required by HIPAA for 6 years). A common issue is that alert suppression rules are too broad, accidentally suppressing real threats. For example, suppressing all 'Access from unusual location' alerts would miss a real attacker. They mitigate by using conditions to limit suppression to specific users or IP ranges.