# Defender for Cloud Alert Rules and Suppression

> Chapter 93 of the Courseiva AZ-500 curriculum — https://courseiva.com/learn/az-500/alert-rules-defender

**Official objective:** 4.1 — Security Operations

## Introduction

For the Security Operations domain (Objective 4.1) of the AZ-500 exam, Azure Defender for Cloud alert rules and suppression serve as a critical mechanism for managing security alerts and reducing noise in cloud security operations. On the AZ-500 exam, this topic appears in roughly 5-8% of questions, often integrated with questions on security policies, automation, and incident response. Understanding how to create, configure, and manage alert suppression rules is essential for passing the Security Operations domain (Objective 4.1).

## Alert Rules as Security Guard with Suppression Log

Picture a security guard at a corporate building who keeps watch over a list of specific suspicious behaviours — these are the alert rules. Each rule is like a detailed instruction: 'If someone enters after 10 PM without a badge, log it and call the supervisor.' Now, the guard also has a suppression log — a notebook where he writes down: 'For the next 30 minutes, do not report badge-less entries from the IT team because they are doing a server upgrade.' When an event matches a rule, the guard first checks the suppression log. If the event is suppressed, he simply records it in a separate internal log but takes no further action. If not suppressed, he triggers the full alert process (calling supervisor, sending email, etc.). The suppression log has entries that expire automatically — after 30 minutes, the guard crosses out that entry. This mirrors how Azure Defender for Cloud alert suppression works: you define suppression rules with specific conditions (like alert title, entity, or time range) and a reason (e.g., false positive). When an alert fires, the system checks if it matches any active suppression rule. If it does, the alert is silently recorded but not shown in the active alerts list. The suppression remains in effect until its expiration time (default 24 hours but can be set up to 90 days). This prevents alert fatigue from known benign activities while still keeping a record for auditing.

## Core explanation

### What Are 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.

### How Alert Suppression Works Internally

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

### Key Components and Defaults

- **Alert Name**: The specific type of alert (e.g., "Suspicious process executed"). You can suppress by exact name or use wildcards (e.g., "*brute force*").
- **Entity**: The Azure resource or IP address associated with the alert. You can suppress alerts for a specific VM, subscription, or IP range.
- **Severity**: High, Medium, Low. You can suppress all alerts of a certain severity (not recommended).
- **Expiration**: Configurable from 1 to 90 days. Default is 24 hours. After expiration, the rule is automatically disabled and alerts are no longer suppressed.
- **Maximum suppression rules**: 250 per subscription.
- **Audit**: All suppression actions are logged in the Azure Activity Log under the category "Security."

### Creating and Managing Suppression Rules

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:
```bash
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"
```

### Interaction with Related Technologies

- **Security Policies**: Suppression rules are scoped to a subscription or resource group, aligning with security policy assignments.
- **Automation Rules**: Suppressed alerts do not trigger automation rules (e.g., Logic Apps, ITSM integration). This is important: if you have automation that responds to all high-severity alerts, suppression can prevent unwanted actions.
- **Workflow Automation**: Suppression rules are evaluated before workflow automation; thus, suppressed alerts are not forwarded to SIEM or ticketing systems.
- **Continuous Export**: Suppressed alerts are not exported via continuous export to Event Hubs or Log Analytics, unless you specifically configure export to include suppressed alerts.

### Best Practices

- **Use suppression for known false positives only** — never suppress alerts without understanding the root cause.
- **Set reasonable expiration times** — do not use permanent suppression (max 90 days). Re-evaluate periodically.
- **Document the reason** — mandatory field, but ensure it is descriptive (e.g., "Patching activity from admin VM 10.0.0.5").
- **Combine with automation** — instead of suppressing, consider auto-remediating with a Logic App and then suppressing future occurrences.
- **Monitor suppressed alerts** — periodically review suppressed alerts to ensure they are still benign.

### Common Pitfalls

- **Suppressing by severity alone** — this can hide critical alerts. Always use specific conditions.
- **Using too broad a scope** — e.g., suppressing all alerts from a subnet can mask real threats.
- **Not setting an expiration** — default is 24 hours, but if you forget to extend, alerts start appearing again. Conversely, setting too long an expiration can blind you to evolving threats.
- **Assuming suppression equals deletion** — suppressed alerts are still stored and can be audited. They count towards your alert quota (if applicable).

### Step-by-Step Creation in Portal

1. Navigate to Microsoft Defender for Cloud > Security alerts.
2. Click on "Suppression rules" (top menu).
3. Click "Add suppression rule."
4. Provide a name and description.
5. Under "Alert rule name," select the alert type or use "*" for all.
6. Set conditions: e.g., "Source IP equals 10.0.0.5".
7. Choose expiration: set a date up to 90 days from now.
8. Provide a reason (required).
9. Click "Create."

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

### API Example (REST)

Request body for creating a suppression rule:
```json
{
  "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"
      }
    ]
  }
}
```

### Monitoring Suppression Rules

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'."

## Real-world context

### Enterprise Scenario 1: Internal Vulnerability Scanner

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.

### Enterprise Scenario 2: Patching Activity

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.

### Enterprise Scenario 3: Geo-Fencing False Positives

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.

## Exam focus

### What AZ-500 Tests on This Topic

Objective 4.1: Configure security alert suppression. The exam expects you to understand:
- How to create and manage suppression rules via portal, CLI, and PowerShell.
- The difference between suppression and dismissal (suppression is temporary and rule-based; dismissal is permanent for a single alert).
- The maximum expiration (90 days) and maximum number of rules (250 per subscription).
- That suppressed alerts are still stored and can be viewed with the 'Include suppressed alerts' filter.
- That suppression rules are evaluated before automation rules, so suppressed alerts do not trigger notifications or workflows.

### Common Wrong Answers and Why Candidates Choose Them

1. **'Suppression permanently deletes the alert.'** — Candidates confuse suppression with dismissal. Reality: suppressed alerts are hidden but still exist for 90 days (default retention).
2. **'You can suppress alerts by severity only.'** — While technically possible, it is a bad practice and the exam emphasizes using specific conditions. The correct answer is to use alert name and entity conditions.
3. **'Suppression rules are applied globally across all subscriptions.'** — They are scoped to a subscription or management group. Candidates might think they are tenant-wide.
4. **'Suppressed alerts are not exported to SIEM.'** — This is true by default, but candidates may think they are always excluded. The exam might test that continuous export can include suppressed alerts if configured.

### Specific Numbers and Values to Memorize

- Maximum suppression rule expiration: 90 days.
- Default expiration: 24 hours.
- Maximum suppression rules per subscription: 250.
- Suppression rule API version: 2019-01-01-preview (may change, but exam uses this).
- Suppression rule state: Enabled or Disabled.

### Edge Cases and Exceptions

- If a suppression rule expires while an alert is being processed, the alert is still suppressed if the rule was active at the time of detection.
- You cannot suppress alerts from Azure Defender for Storage or other plans if they are not enabled.
- Suppression rules do not affect Azure Security Center's secure score calculations.
- If you delete a suppression rule, previously suppressed alerts remain suppressed (they are not retroactively unsuppressed).

### How to Eliminate Wrong Answers

Focus on the mechanism: suppression is a time-bound rule that hides alerts but does not delete them. If an answer says 'permanently' or 'deletes', it is wrong. If an answer suggests suppression without an expiration, it is wrong (max 90 days). If an answer says suppressed alerts affect automation, it is wrong. Always look for the specific conditions and the fact that suppression is rule-based.

## Step by step

1. **Identify Alert to Suppress** — Begin by reviewing security alerts in Defender for Cloud. Identify alerts that are known false positives or low-severity events that do not require action. For example, a weekly vulnerability scan from your internal scanner triggering 'SSH brute force' alerts. Note the alert name, source IP, and resource involved. This step ensures you suppress only the specific alerts you intend to.
2. **Define Suppression Rule Conditions** — In the Azure portal, go to Defender for Cloud > Security alerts > Suppression rules > Add. Choose the alert rule name (e.g., 'SSH brute force attack detected'). Add conditions such as 'Source IP equals 10.0.0.5' or 'Resource ID contains vm-scanner'. Conditions are logical AND within a rule. You can also use wildcards in alert names. Ensure the scope is precise to avoid suppressing legitimate alerts.
3. **Set Expiration and Reason** — Set an expiration date for the suppression rule. The maximum is 90 days from creation. A reasonable period might be 30 days for a recurring scan. Provide a clear reason, e.g., 'Internal vulnerability scanner - approved by security team'. This reason is stored in the audit log and helps during reviews. Without a reason, the rule cannot be created.
4. **Create and Validate the Rule** — Click 'Create' to save the suppression rule. Immediately verify that the rule appears in the suppression rules list with state 'Enabled'. You can test by triggering the alert (if possible) and checking that it no longer appears in the active alerts list. Use the 'Include suppressed alerts' filter to confirm the alert is suppressed.
5. **Monitor and Review Suppression Rules** — Regularly review suppression rules to ensure they are still needed. Use Azure Monitor to set alerts on rule creation or expiration. When a rule expires, alerts resume. If the reason is no longer valid, delete or update the rule. Also, periodically check suppressed alerts to ensure they remain benign. This step prevents alert fatigue from evolving threats.

## Comparisons

### Alert Suppression Rule vs Alert Dismissal

**Alert Suppression Rule:**
- Temporary (1-90 days expiration)
- Rule-based: matches future alerts automatically
- Does not delete the alert; hides it from active view
- Requires a reason and conditions
- Can be edited or deleted later

**Alert Dismissal:**
- Permanent action on a single alert instance
- One-time: you dismiss the specific alert only
- Marks the alert as dismissed; it remains visible with a status
- Does not require a reason (but recommended)
- Cannot be undone; alert remains dismissed

## Common misconceptions

- **Misconception:** Suppressed alerts are permanently deleted after the suppression period ends. **Reality:** Suppressed alerts are not deleted. They remain in the system for the standard retention period (90 days for most alerts). After the suppression rule expires, the alerts become visible again in the active alerts list.
- **Misconception:** You can create suppression rules with no expiration date (permanent). **Reality:** All suppression rules must have an expiration date between 1 and 90 days from creation. There is no option for permanent suppression. After expiration, the rule is automatically disabled.
- **Misconception:** Suppression rules can be applied to all alerts from a subscription regardless of type. **Reality:** You can suppress all alerts by using a wildcard '*' for the alert name, but this is not recommended. The exam expects you to know that suppression rules filter based on alert name, entity, or conditions, not just subscription-wide.
- **Misconception:** Suppressed alerts are not recorded in the Activity Log. **Reality:** The creation, modification, and deletion of suppression rules are recorded in the Azure Activity Log. However, the alerts themselves are not logged separately; they are simply hidden from the active alerts list.
- **Misconception:** You can suppress alerts from Azure Defender for Cloud only for virtual machines. **Reality:** Suppression rules can be applied to any alert type from any Defender plan, including App Service, SQL, Storage, Kubernetes, etc.

## Key takeaways

- Suppression rules are temporary (max 90 days) and rule-based; they hide alerts but do not delete them.
- Maximum 250 suppression rules per subscription.
- Suppressed alerts do not trigger automation rules (Logic Apps, email notifications).
- Suppression rules are scoped to a subscription or management group, not tenant-wide.
- Use specific conditions (alert name, source IP, resource) to avoid suppressing legitimate threats.
- Always set an expiration date; default is 24 hours.
- Periodically review and update suppression rules to adapt to changing environments.

## FAQ

**Can I suppress alerts for a specific IP address in Defender for Cloud?**

Yes, you can create a suppression rule with a condition on the 'Source IP' entity. For example, you can suppress all alerts from a known internal scanner IP. In the rule, under 'Conditions', choose 'Source IP' and set the operator to 'Equals' or 'Contains' with the IP address. This ensures that alerts from that IP are hidden for the duration of the rule.

**What happens to suppressed alerts after the suppression rule expires?**

When a suppression rule expires, it is automatically disabled. Any alerts that were previously suppressed are no longer hidden; they will appear in the active alerts list if they are still within the retention period. New alerts that match the conditions of the expired rule will also appear as normal alerts. The rule itself remains in the list with state 'Expired' until you delete it.

**Can I use wildcards in the alert name for suppression rules?**

Yes, you can use wildcards in the 'Alert rule name' field. For example, entering '*brute force*' will suppress any alert whose name contains 'brute force'. This is useful for suppressing a family of alerts. However, be cautious: broad wildcards may suppress legitimate alerts. Always combine with specific entity conditions.

**Are suppressed alerts included in continuous export to Event Hubs or Log Analytics?**

By default, suppressed alerts are not exported via continuous export. However, you can configure the continuous export settings to include suppressed alerts by checking the 'Include suppressed alerts' option. This is useful for auditing and long-term analysis. Without this setting, suppressed alerts are only visible in the Azure portal with the 'Include suppressed alerts' filter.

**How do I view all suppressed alerts in Defender for Cloud?**

In the Security alerts page, click on 'Filter' and toggle the 'Include suppressed alerts' switch to 'Yes'. This will show all alerts, including those suppressed by rules. Suppressed alerts are marked with a 'Suppressed' badge. You can also filter by suppression rule to see which alerts a specific rule has suppressed.

**Can I create a suppression rule that applies to multiple subscriptions?**

Suppression rules are created at the subscription level. To apply the same rule across multiple subscriptions, you must create the rule in each subscription individually. Alternatively, you can use Azure Policy to enforce a standard set of suppression rules across subscriptions, but this is not a native feature of suppression rules.

**What is the difference between suppressing an alert and dismissing it?**

Suppression is a rule-based, temporary action that automatically hides future alerts matching the rule. Dismissal is a one-time action on a specific alert instance that marks it as dismissed permanently. Suppressed alerts can become visible again after the rule expires; dismissed alerts remain dismissed indefinitely. Suppression requires a reason and expiration; dismissal does not require a reason.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/az-500/alert-rules-defender