1.1 Automation Rules — The Lightweight Layer

The three triggers

Automation rules fire on one of three events: incident creation, incident update, or alert creation. The trigger you select determines when the rule evaluates and which properties are available for conditions.

Incident created is the primary trigger for most automation. It fires once, when the incident first appears in the queue after alert grouping completes. At that point the incident has its full entity mapping, correlated alerts, severity, title, and MITRE tactic assignment. This is the trigger for severity overrides, analyst routing, enrichment playbook triggers, and FP auto-close rules. If you are building your first automation rule, start here.

Incident updated fires every time a property changes on an existing incident: status change, severity change, owner assignment, tag addition, comment addition, or new alerts correlated into the incident. The update trigger is useful for two specific patterns. First, escalation routing: when an analyst manually changes severity from Medium to High, the update trigger can reassign the incident to a senior analyst or trigger a different playbook. Second, tag-based orchestration: when a playbook completes enrichment and adds an "enriched" tag, an update-triggered rule can fire a downstream collection or containment playbook. The update trigger requires careful condition design because it fires on every property change, which means a rule without narrow conditions fires repeatedly on the same incident.

Alert created fires when an individual alert is generated, before it is grouped into an incident. This trigger exists primarily for analytics rules that produce alerts without creating incidents (rules with incident creation disabled). The alert trigger has a significant limitation: the only condition available is the analytics rule name. You cannot filter by severity, entity type, or any other property. The alert trigger also cannot be used to respond to alerts from Microsoft security rules (Defender XDR-sourced alerts). For most automation, the incident trigger is the correct choice. Use the alert trigger only when you specifically need to respond to standalone alerts that have no parent incident.

Conditions: filtering which incidents match

Without conditions, an automation rule fires on every incident. That is occasionally correct, for example a rule that adds an "unreviewed" tag to all new incidents, but usually too broad. Conditions narrow the rule to specific incident types.

Conditions on incident-triggered rules evaluate incident properties. The incident provider condition filters by source: Microsoft Sentinel (analytics-rule-generated) or Microsoft Defender XDR (imported). The analytics rule name condition is the most common filter because it maps automation to specific detection types. "If analytics rule name contains AiTM Credential Phishing" targets only AiTM incidents for enrichment. Severity conditions route High and Critical incidents to different automation than Medium and Low. Title conditions match text in the incident title, which is less precise than analytics rule name because titles can change, but useful when multiple analytics rules produce related incidents. Tag conditions enable coordination between rules: "if tag does not contain auto-enriched" prevents the enrichment playbook from running twice on the same incident.

Conditions chain with AND logic by default. All conditions in a single group must match for the rule to fire. If you need OR logic, use condition groups. Each condition group evaluates independently, and the rule fires if any group matches. You could create a rule that fires on AiTM incidents (group 1) OR impossible travel incidents (group 2) OR suspicious inbox rule incidents (group 3), running the same enrichment playbook for all three detection types.

Entity-level conditions filter based on the entities mapped to the incident. You can condition on entity types (contains Account, contains Host, contains IP) or on specific entity properties (account UPN contains "admin," host name starts with "SRV-NGE"). Entity conditions are powerful for routing: incidents containing server entities route to the infrastructure team, incidents containing only workstation entities route to the general SOC queue.

All conditions are case insensitive. This is important because entity values from different log sources may arrive in different case formats. A condition matching "admin" will catch "ADMIN," "Admin," and "admin" regardless of source.

The seven action types

When conditions match, the rule executes its actions in sequence. A single rule can chain multiple actions.

Change severity overrides the incident's default severity. Detection rules set severity based on generic logic, but your environment context justifies a different level. At NE, every AiTM detection is High regardless of the analytics rule's default severity, because the business impact of a compromised session at an engineering company with active intellectual property is always high.

Change status moves the incident through its lifecycle. The primary use is auto-closing false positives with a classification. An auto-close rule sets the status to Closed, the classification to BenignPositive or FalsePositive, and adds a comment explaining the reason.

Assign owner routes the incident to a specific analyst, a Microsoft Entra group, or the Unassigned queue. Assign to a group or shared queue, never to an individual analyst, because individuals take leave, change roles, and are unavailable during off-hours. NE's routing assigns identity incidents to the identity security group, endpoint incidents to the endpoint team, and unassigned High severity incidents to the SOC lead after 15 minutes.

Add tags labels incidents for tracking, filtering, and playbook coordination. Tags serve two operational purposes: they record automation state ("enrichment-pending," "enriched," "auto-closed") and they enable downstream triggering (an update-triggered rule can fire when a specific tag appears).

Add incident tasks creates a checklist within the incident that guides the analyst through the triage process. A rule triggered on AiTM incidents can add tasks: "Check sign-in context for geographic anomaly," "Review MFA method used," "Check for inbox rule creation within 30 minutes of sign-in." Tasks turn tribal knowledge into documented, repeatable triage procedures.

Run playbook triggers a Logic App. This is the bridge between the lightweight automation rule and the powerful playbook layer. The automation rule provides the filtering logic (which incidents trigger the playbook), and the playbook provides the execution logic (what happens when triggered). Section 1.2 covers playbooks in detail.

Close incident is a combined action that sets the status to Closed, applies a classification (True Positive, False Positive, Benign True Positive), and optionally adds a closing comment. Used exclusively in FP auto-close patterns.

{
  "displayName": "SA-Rule-003: Enrich AiTM Incidents",
  "order": 11,
  "triggeringLogic": {
    "triggerType": "IncidentCreated",
    "conditions": [
      {
        "conditionType": "Property",
        "conditionProperties": {
          "propertyName": "IncidentAnalyticRuleNames",
          "operator": "Contains",
          "propertyValues": ["AiTM Credential Phishing Detection"]
        }
      },
      {
        "conditionType": "Property",
        "conditionProperties": {
          "propertyName": "IncidentLabel",
          "operator": "DoesNotContain",
          "propertyValues": ["auto-enriched"]
        }
      }
    ]
  },
  "actions": [
    {
      "actionType": "ModifyProperties",
      "actionConfiguration": {
        "severity": "High",
        "labels": [{ "labelName": "enrichment-pending" }]
      }
    },
    {
      "actionType": "RunPlaybook",
      "actionConfiguration": {
        "playbookResourceId": "/subscriptions/.../SA-Enrichment-AiTM"
      }
    }
  ]
}

This rule combines three actions in one execution: override severity to High, add the "enrichment-pending" tag, and trigger the enrichment playbook. The tag condition prevents the playbook from running twice on the same incident. Order 11 places the rule in the enrichment band, after severity/routing rules (1-10) and before collection rules (21-30).

Execution order and conflict resolution

Sentinel evaluates all active automation rules in numerical order when an incident matches a trigger. The rule with the lowest order number fires first. When multiple rules match the same incident, all matching rules execute sequentially. This creates a specific conflict risk: if Rule 1 (order 1) changes severity from Medium to High, and Rule 2 (order 5) has a condition requiring Medium severity, Rule 2 will not fire because Rule 1 already changed the severity before Rule 2 evaluated.

The execution order at NE follows a deliberate banding strategy. Orders 1 through 10 are reserved for severity and assignment rules. These fire first because severity changes affect downstream conditions and because routing ensures the correct analyst sees the incident immediately. Orders 11 through 20 are for enrichment playbook triggers. Enrichment fires early so the data is available when the analyst opens the incident. Orders 21 through 30 are for collection playbook triggers. Evidence collection fires after enrichment because the enrichment data may determine which evidence to collect. Orders 31 through 40 are for containment playbook triggers. Containment fires last because it depends on the confidence score that enrichment calculates.

This banding strategy prevents the most common conflict: a containment playbook firing before enrichment has completed. Without explicit ordering, the containment playbook would make a decision based on the raw alert data alone, without the enrichment context that the confidence threshold model requires.

The four production patterns

Four patterns cover the majority of automation rule use cases at NE. Every automation rule you build maps to one of these patterns.

Pattern 1: severity override. The analytics rule sets AiTM detection to Medium because the rule was designed for a generic environment. At NE, every AiTM detection is High because NE handles engineering intellectual property and a compromised session has immediate data exfiltration risk. The automation rule fires on incident creation, matches the AiTM analytics rule name, and changes severity to High. One rule, one condition, one action. Deployed in two minutes.

Pattern 2: smart routing. Identity incidents go to the identity specialist. Endpoint incidents go to the endpoint analyst. Unassigned High severity incidents after 15 minutes go to the SOC lead. The routing rules use entity conditions: if the incident contains Account entities with UPN matching admin patterns, route to the identity team. If the incident contains Host entities, route to the endpoint team. The assignment target is always a group or queue, never an individual. When the identity specialist takes leave, the identity security group still receives incidents.

Pattern 3: FP auto-close. NE's impossible travel detection fires 120 times per week. After 30 days of analyst classification, 78% are false positives caused by VPN exit node geo-location. The detection cannot be tuned further without losing the 22% true positives. The automation rule auto-closes impossible travel incidents where the title matches the known-FP pattern. The rule sets status to Closed, classification to BenignPositive, adds the "auto-closed-travel" tag, and adds a comment documenting the auto-close reason. The tag enables a monthly audit query that checks whether any auto-closed incidents had subsequent related alerts suggesting the auto-close was wrong.

Pattern 4: playbook orchestration. This is the most important pattern because it connects the lightweight automation rule to the powerful playbook layer. The rule fires on incident creation, conditions match on the analytics rule name, and the actions chain: change severity, add "enrichment-pending" tag, run the enrichment playbook. The tag prevents double-execution. The enrichment playbook replaces "enrichment-pending" with "enriched" on completion, and an update-triggered rule watching for the "enriched" tag can fire the next playbook in the sequence.

This chaining pattern is how you build multi-stage automation without building a single monolithic playbook. Each stage has its own automation rule, its own playbook, and its own tag for coordination. If the enrichment playbook fails, the "enrichment-pending" tag persists, the "enriched" tag never appears, and the downstream rules never fire. The failure is visible and recoverable.

Expiration and lifecycle management

Every automation rule should have an expiration date if it addresses a temporary condition: a campaign-specific suppression, a holiday-period severity override, a rule compensating for a temporarily misconfigured detection. Rules without expiration persist indefinitely and accumulate over months, creating overlapping rules that nobody understands. At NE, temporary rules expire after 30 days. Permanent rules are reviewed quarterly during the governance review from Section 0.9. Any rule that has not fired in 90 days is investigated and potentially disabled.

The Automation page in the Defender portal shows the "Last run" timestamp for each rule. A rule that has never run may have conditions that are too narrow, may target an analytics rule that has been renamed, or may have been superseded by a newer rule. Treat unfired rules as potential dead automation and investigate before assuming they are intentional.