Defender for Cloud Alert Rules and Suppression

Azure Defender for Cloud continuously monitors your Azure resources for security threats. When a threat is detected, it generates a security alert. However, not all alerts are actionable — some are known false positives (e.g., a security scan from your own team) or low-severity events that do not require immediate attention. Alert suppression allows you to define rules that automatically dismiss specific alerts for a defined period, reducing alert fatigue and allowing security teams to focus on genuine threats.

When Defender for Cloud detects a potential threat, it evaluates the event against all active security alerts policies. Each alert has a set of properties: alert name (type), severity, description, entities (e.g., IP address, resource ID), and timestamp. Before an alert is surfaced in the Azure portal or sent to connected SIEM systems, the system checks if the alert matches any active suppression rule.

A suppression rule consists of: - Scope: Which alerts to suppress (by alert name, entity type, or specific conditions). - Conditions: Logical expressions using alert properties (e.g., "Alert name equals 'SSH brute force' AND Source IP equals '10.0.0.5'"). - Reason: A justification for suppression (mandatory for auditing). - Expiration: How long the rule remains active (1 to 90 days, default 24 hours). - State: Active or expired.

If a match is found, the alert is still generated internally (for auditing and telemetry) but is marked as "suppressed" and not shown in the active alerts list. It does not trigger any configured automation (e.g., email notifications, Logic Apps). The suppressed alert can be viewed in the alert details page by selecting "Include suppressed alerts."

You can create suppression rules via: - Azure Portal: Defender for Cloud > Security alerts > Suppression rules > Add suppression rule. - REST API: https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Security/alertSuppressionRules/{ruleName}?api-version=2019-01-01-preview - Azure CLI: Use az security alert-suppression-rule create. - PowerShell: New-AzSecurityAlertSuppressionRule.

Example Azure CLI command:

az security alert-suppression-rule create \
  --name "SuppressSSHBruteForce" \
  --alert-rule-name "SSH brute force attack detected" \
  --reason "Known internal scanner" \
  --expiration-date-utc "2025-12-31" \
  --state "Enabled"

After creation, the rule appears in the list. You can edit, disable, or delete it anytime.

Request body for creating a suppression rule:

{
  "properties": {
    "alertType": "SSH brute force attack detected",
    "expirationDateUtc": "2025-12-31T23:59:59Z",
    "reason": "Known internal scanner",
    "state": "Enabled",
    "conditions": [
      {
        "property": "Source IP",
        "operator": "Equals",
        "value": "10.0.0.5"
      }
    ]
  }
}

You can use Azure Monitor to create alerts on suppression rule changes (e.g., when a rule is created or expires). This is important for governance. Use the Activity Log with filter "Operation name equals 'Create or Update Alert Suppression Rule'."

A large enterprise runs a weekly vulnerability scan using tools like Qualys or Nessus. These scans generate thousands of low-severity alerts in Defender for Cloud, overwhelming the SOC team. To manage this, the security engineer creates a suppression rule that suppresses alerts with alert name containing 'Vulnerability' and source IP matching the scanner's IP range (10.0.0.0/24). The rule is set to expire in 7 days (the scan frequency). Each week, the engineer reviews and recreates the rule if the scan is still ongoing. This reduces alert volume by 80% while still allowing the SOC to see any alerts from outside that IP range. Misconfiguration risk: if the scanner IP changes or the rule is not updated, alerts might be missed or false negatives occur.

During a monthly patching cycle, servers reboot and generate alerts like 'Suspicious process executed' or 'Windows Defender AV detection'. The patching team coordinates with the SOC to create a temporary suppression rule that suppresses alerts from the specific VM names (e.g., 'SQL-PROD-01') for 48 hours. After patching, the rule is deleted. This prevents alert fatigue while maintaining security coverage. Performance consideration: with thousands of VMs, creating individual suppression rules is impractical; instead, use a tag-based condition (e.g., 'Tag: PatchGroup = March') to suppress alerts from all patched VMs.

A company has remote employees who connect via VPN from multiple countries. Defender for Cloud generates alerts for 'Unusual sign-in from unfamiliar location' for these legitimate users. The SOC creates suppression rules for each user's home IP range, but this is unsustainable. Instead, they use a suppression rule that suppresses alerts for users in the 'Remote-Employees' Azure AD group, with a condition on the user principal name. This is more scalable but requires careful group management. Common pitfall: if the group membership is not updated when an employee leaves, their legitimate access might be suppressed, masking a real threat.