SA1.1 Automation Rules — The Lightweight Layer

What automation rules can do

Automation rules operate at the incident level. When an incident is created or updated, Sentinel evaluates all active automation rules in order. Each rule checks its conditions against the incident’s properties. If conditions match, the rule executes its actions.

The trigger is either “When incident is created” or “When incident is updated.” Most rules use the creation trigger — you want the rule to fire when the incident first appears, not every time an analyst adds a comment or changes a tag. The update trigger is useful for specific scenarios: routing incidents to a different team when severity is manually escalated, or triggering a containment playbook when an analyst adds a “confirmed-compromise” tag.

Conditions filter which incidents the rule applies to. Without conditions, the rule fires on every incident — which is occasionally correct (a rule that adds an “unreviewed” tag to all new incidents) but usually too broad. Conditions include:

Analytics rule name — match incidents from specific detection rules. “If analytics rule name equals ‘AiTM Credential Phishing Detection’” targets only AiTM incidents. This is the most common condition because it maps automation to specific detection types.

Incident severity — match incidents at a specific severity level. “If severity equals High or Critical” targets the incidents that need immediate attention. Combine with the “run playbook” action to trigger enrichment only on high-priority incidents.

Title contains — match incidents where the title includes specific text. Less precise than analytics rule name (titles can change) but useful when multiple analytics rules produce related incidents. “If title contains ‘ransomware’” catches all ransomware-related incidents regardless of which rule generated them.

Tag — match incidents with specific tags. “If tag does not contain ‘auto-enriched’” prevents the enrichment playbook from running twice on the same incident (the playbook adds the tag after enrichment).

Actions modify the incident or trigger external automation. A single rule can execute multiple actions in sequence:

Change severity — override the incident’s default severity. The detection rule may set severity based on generic logic, but your environment-specific context justifies a different level. AiTM is always High at NE regardless of the detection’s default.

Assign owner — route the incident to a specific analyst or queue. Identity incidents go to the identity specialist. Endpoint incidents go to the endpoint analyst. Unassigned High severity incidents after 30 minutes go to the SOC lead for redistribution.

Add tags — tag incidents for tracking, filtering, and playbook coordination. Add “enrichment-pending” when the enrichment playbook is triggered. The playbook replaces it with “enriched” on completion. Add “auto-closed” to FP auto-close incidents for monthly audit review.

Run playbook — trigger a Logic App playbook. 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).

Close incident — change the incident status to Closed with a classification (True Positive, False Positive, Benign True Positive) and a comment. Used for FP auto-close patterns.

What automation rules cannot do

Automation rules cannot query data. They cannot look up an IP in a watchlist, check a user’s risk score, or call an external API. The conditions evaluate incident properties only — severity, title, tags, analytics rule name, entity types. Any condition that requires data lookup needs a playbook.

Automation rules cannot execute containment actions. They cannot revoke sessions, isolate endpoints, or disable accounts. They can trigger a playbook that does these things, but the rule itself is limited to incident property modifications and playbook triggers.

Automation rules cannot process complex logic. There are no if-else branches, no loops, no variable assignments. If you need “if the IP is in the VIP watchlist, do X; otherwise, do Y” — that is a playbook.

The mental model: automation rules are the dispatcher. They look at the incoming incident, make a quick classification decision based on surface properties, and route it to the correct handler (change severity, assign analyst, trigger playbook). The handler (playbook) does the complex work.

Execution order

Automation rules execute in the order you configure. Each rule has an order number (1 to 1000). Sentinel processes rules sequentially from the lowest order number to the highest.

Order matters when rules depend on each other. If Rule A (order 10) changes severity from Medium to High, and Rule B (order 20) triggers a playbook on High severity incidents, Rule A must execute before Rule B. If the order were reversed, Rule B would evaluate the incident at Medium severity and skip the playbook trigger.

The practical approach: use order numbers with gaps. Set your first rule to order 100, the second to order 200, the third to order 300. This leaves room to insert new rules between existing ones without renumbering everything. Numbering 1, 2, 3 forces renumbering when you need to insert a rule between 1 and 2.

Expiration dates. Automation rules can have expiration dates — useful for temporary rules. During an active incident, you might create a rule that auto-escalates all alerts from a specific IP to Critical severity. After the incident is resolved, the rule expires automatically instead of requiring manual removal.

The four production patterns

Pattern 1: Severity override. Your AiTM detection fires at Medium severity by default (Microsoft’s default for many identity protection alerts). Your environment context says AiTM is always High because you have a confirmed phishing campaign and any AiTM is a real threat. Create an automation rule: trigger on incident creation, condition: analytics rule name = “AiTM Credential Phishing,” action: change severity to High. Every AiTM incident is now immediately High severity in the queue.

This pattern applies across detection sources. Defender for Identity alerts arrive at Medium severity for Kerberoasting — but in your environment, Kerberoasting is High because you have service accounts with weak passwords. Defender for Office 365 alerts arrive at Medium for “email reported by user as phishing” — but your user-reported phishing has a 40% true positive rate, warranting High severity.

Pattern 2: Smart routing. Different incident types require different analyst skills. Identity incidents (AiTM, impossible travel, consent phishing) go to the analyst with Entra ID expertise. Endpoint incidents (suspicious process, persistence detection) go to the analyst with Windows forensics expertise. All Critical severity incidents go to the IR lead regardless of type.

Implement with multiple rules: Rule 1 (order 100) — analytics rule name contains “identity” → assign to identity analyst. Rule 2 (order 200) — analytics rule name contains “endpoint” → assign to endpoint analyst. Rule 3 (order 300) — severity = Critical → assign to IR lead. Rule 3 overwrites Rule 1/2’s assignment for Critical incidents because it executes later — which is the desired behavior.

Pattern 3: FP auto-close. The impossible travel detection fires 120 times per week. After 30 days of tracking, you know that 78% are false positives caused by VPN exit node geo-location. You cannot tune the detection further without losing the 22% true positives. Solution: an automation rule that auto-closes impossible travel incidents where the analytics rule name matches AND the incident title contains the known-FP user (the CEO who flies weekly).

The rule closes the incident with classification “BenignPositive,” adds a tag “auto-closed-travel,” and adds a comment “Auto-closed: known travel pattern for [user]. Review monthly to confirm pattern persists.” The monthly review ensures auto-close rules do not mask a real compromise.

Pattern 4: Playbook trigger. The most important pattern. Automation rules are the mechanism that connects incidents to playbooks. Rule: trigger on incident creation, condition: analytics rule name = “AiTM Credential Phishing,” action 1: change severity to High, action 2: add tag “enrichment-pending,” action 3: run playbook “SA-Enrichment-AiTM.”

This single rule combines three patterns — severity override, tagging, and playbook trigger — in one execution. The tag prevents the playbook from running twice (the playbook checks for “enrichment-pending” and replaces it with “enriched”).