1.3 Your First Automation Rule

Naming convention

Adopt a naming convention before creating your first rule. Every automation rule and playbook on the platform will accumulate over months. Without a convention, the Automation page becomes an unreadable list of "New automation rule (3)" entries that nobody can interpret without opening each one.

NE's convention is SA-Rule-{NNN}-{Purpose} where NNN is the order number and Purpose is a short description. The order number in the name makes the execution sequence visible in the rule list without opening the rule configuration. Examples: SA-Rule-001-AiTM-Severity-Override, SA-Rule-005-Identity-Routing, SA-Rule-050-FP-Travel-AutoClose, SA-Rule-100-AiTM-Enrichment-Trigger. The three-digit order number pads correctly in alphabetical sort.

Playbooks use a parallel convention: SA-Playbook-{Purpose}. The SA prefix groups all security automation resources in the Azure resource list. The Purpose matches the automation rule that triggers it. SA-Rule-100-AiTM-Enrichment-Trigger calls SA-Playbook-Enrichment-AiTM. When an analyst looks at the Automation page and sees a rule triggering a playbook, the naming relationship makes the automation stack self-documenting. When a playbook fails at 3am, the on-call analyst reads the name and immediately knows what it was supposed to do.

Rule 1: AiTM severity override

This is the simplest possible automation rule. One trigger, one condition, two actions. Deploy it in under five minutes.

Name: SA-Rule-001-AiTM-Severity-Override. Trigger: When incident is created. Conditions: Add a condition for the incident title. Set the operator to Contains and enter "AiTM." Add an OR condition group for additional AiTM detection variants: title contains "credential phishing" OR title contains "token theft" OR title contains "adversary-in-the-middle." If your analytics rule name is available as a condition (it depends on onboarding state), use analytics rule name instead of title because rule names are more stable than incident titles.

Actions: Change severity to High. Add tag "aitm-triage." The severity override ensures every AiTM incident has the correct priority regardless of the analytics rule's default configuration. The tag enables filtering and downstream automation coordination.

Order: 1. This is the first rule that fires on any new incident. Severity must be correct before downstream rules evaluate severity-based conditions. If a routing rule at order 5 assigns High severity incidents to the senior analyst, the severity override at order 1 ensures AiTM incidents arrive with the correct severity before the routing rule evaluates.

Expiration: None. This is a permanent rule. Set an expiration only for temporary rules created during active campaigns or holidays.

Click Apply. The rule is live immediately. Every AiTM incident created from this point forward is automatically set to High severity and tagged for triage. The deployment took under three minutes.

Rule 2: identity smart routing

Name: SA-Rule-005-Identity-Routing. Trigger: When incident is created. Conditions: Add a condition for MITRE ATT&CK tactics. Set the operator to Contains and select "InitialAccess" and "CredentialAccess." This captures sign-in anomalies, brute force attempts, AiTM, password spray, and credential phishing detections without needing to list every analytics rule by name. The tactic-based condition is more resilient than title matching because new analytics rules that target identity attack techniques are automatically captured without requiring condition updates.

Actions: Assign owner to the identity security group (a Microsoft Entra security group, not an individual analyst). Add tag "identity-routed."

Order: 5. Fires after severity overrides (order 1-4) so the severity is already correct when the analyst receives the assignment notification.

The routing rule eliminates the queue-scanning step. The identity specialist opens Sentinel and sees only identity incidents, already assigned, already at the correct severity. The endpoint analyst sees endpoint incidents. Neither analyst wastes time scanning the full queue to find their incidents. On a Monday morning queue with 14 incidents, routing saves 15-20 minutes of manual triage distribution.

Rule 3: known-FP auto-close

This rule requires the most careful design because it closes incidents without human review. The conditions must be narrow enough that the rule cannot accidentally close a real attack.

Name: SA-Rule-050-FP-Travel-AutoClose. Trigger: When incident is created. Conditions: The conditions must be narrow enough to target only the specific FP pattern and nothing else. Add a condition: incident title contains "Impossible Travel." Add an AND condition: incident title contains the known-FP user identifier (the specific executive who flies weekly, referenced by their UPN or display name in the incident title). Both conditions must match. If the executive stops traveling, the condition stops matching and the rule stops closing incidents, which is the correct behavior. Do not use broad conditions like "title contains travel" because that would catch legitimate impossible travel detections for other users.

Actions: Change status to Closed. Set classification to BenignPositive. Add tag "auto-closed-travel." Add a comment that documents the auto-close: "Auto-closed by SA-Rule-050. Known weekly travel pattern for [executive]. Monthly review: run SA-Audit-AutoClose query to verify no related alerts within 24 hours of closure."

Order: 50. Fires after severity overrides and routing, but before playbook triggers. An auto-closed incident should not trigger enrichment playbooks because enrichment would waste Logic App execution costs on a known false positive. The order sequence matters: if the enrichment playbook at order 100 fires before the auto-close at order 50, you pay for enrichment on incidents that will be immediately closed.

Every FP auto-close rule needs a paired audit query. Without the audit, you have no way to detect when an auto-close rule is masking a real compromise. The following query joins auto-closed incidents with non-auto-closed incidents that share the same entities:

// Monthly audit: check auto-closed incidents for missed compromises
SecurityIncident
| where TimeGenerated > ago(30d)
| where Labels has "auto-closed-travel"
| extend ClosedEntities = tostring(AdditionalData.relatedEntities)
| join kind=inner (
    SecurityIncident
    | where TimeGenerated > ago(30d)
    | where Labels !has "auto-closed"
    | where Status != "Closed" or Classification == "TruePositive"
    | extend OpenEntities = tostring(AdditionalData.relatedEntities)
) on $left.ClosedEntities == $right.OpenEntities
| project AutoClosedTitle = Title, AutoClosedTime = TimeGenerated,
          RelatedIncidentTitle = Title1, RelatedIncidentTime = TimeGenerated1,
          SharedEntity = ClosedEntities
| sort by AutoClosedTime desc

If this query returns results, an auto-closed incident's entity appeared in a separate, potentially real incident within the same 30-day window. Investigate each match. If the auto-close rule masked a real compromise, tighten the conditions or retire the rule entirely. Schedule this query as a Sentinel analytics rule that generates an informational alert on the first of each month. The alert serves as a mandatory review reminder.

Rule 4: enrichment playbook trigger

Name: SA-Rule-100-AiTM-Enrichment-Trigger. Trigger: When incident is created. Conditions: Incident title contains "AiTM" AND tag does not contain "auto-enriched." The title condition matches AiTM incidents. The tag condition prevents the enrichment playbook from running twice if the incident is updated after enrichment completes.

Actions: Add tag "enrichment-pending." Run playbook SA-Playbook-Enrichment-AiTM (you build this playbook in Section 1.4). The "enrichment-pending" tag signals that the playbook has been triggered but has not completed. The playbook replaces this tag with "auto-enriched" on successful completion. If the playbook fails, the "enrichment-pending" tag persists, which tells an investigating analyst that enrichment was attempted but did not succeed.

Order: 100. Fires after all severity, routing, and auto-close rules. This order ensures the enrichment playbook only runs on incidents that survived auto-close filtering and already have the correct severity and assignment. Running enrichment on an incident that will be auto-closed wastes Logic App execution costs.

The tag coordination between the automation rule and the playbook is the mechanism that enables multi-stage automation. When the enrichment playbook completes and adds the "auto-enriched" tag, an update-triggered automation rule (which you build later in the course) can fire a downstream collection or containment playbook. Each stage has its own rule, its own playbook, and its own tag. If enrichment fails, the downstream rules never fire. The failure is visible and recoverable.

Validating the deployed rules

After deploying all four rules, validate each one. Three methods are available, and you should use at least two to confirm each rule works as designed.

Wait for a real incident. If the analytics rules fire regularly, the next matching incident triggers the automation rules. Check the incident in the queue: is the severity correct? Is the tag present? Is the owner assigned? For the FP auto-close rule, check the closed incidents view: is the classification BenignPositive? Is the closing comment present? This is the strongest validation because it uses real alert data with full entity mapping.

Create a test incident manually. In the Defender portal, navigate to Incidents and use the Create incident feature. Set the title to include "AiTM" (matching the condition) and the initial severity to Medium. After creation, check whether the automation rule changed the severity to High and added the tag. Manual incidents are useful for testing conditions but have a limitation: manually created incidents have limited entity mapping, so entity-based conditions on Rule 2 may not fire as expected.

Check the automation rule run history. On the Automation page, select each rule and open the run history. Each run shows whether the rule evaluated (conditions checked), matched (conditions met), and executed (actions completed). If the rule evaluated but did not match, the conditions are too narrow or the incident properties did not meet the criteria. If the rule matched but did not execute, there may be a permissions issue with the playbook for Rule 4. The Sentinel service account needs the Microsoft Sentinel Automation Contributor role on the playbook's resource group, and this is the most common reason for silent playbook trigger failures.

Common failures after deployment: the rule fires but the playbook does not execute (missing Automation Contributor role on the playbook resource group). The rule does not fire at all (the analytics rule name in the condition does not match the actual analytics rule name in your workspace, often because the name was customized during deployment). The auto-close rule closes incidents too broadly (the title condition was too permissive). Check the run history for each rule within 48 hours of deployment and adjust conditions as needed.