SA1.3 Your First Automation Rule

Building the rule — step by step

Open your Sentinel workspace in the Azure portal. Navigate to Configuration → Automation. Click “Create” and select “Automation rule.”

Rule name. Use a naming convention from the start. The naming convention for this course is: SA-Rule-{Purpose}-{Target}. For this rule: SA-Rule-AiTM-Triage-Acceleration. The prefix SA-Rule distinguishes automation rules from playbooks (SA-Playbook) in the list view. The purpose and target make the rule’s function clear without opening it.

Trigger. Select “When incident is created.” This fires the rule once when the incident first appears in the queue — not on every update, which would cause the severity change and tag addition to re-execute on every analyst comment or status change.

Conditions. Click “Add condition” and select “Analytics rule name.” Set the operator to “Contains” and enter “AiTM.” If your AiTM detection uses a different name (many organisations name their rules differently), adjust accordingly. Click “Add condition” again with OR logic if you have multiple analytics rules that detect AiTM variants — “Contains ‘credential phishing’” OR “Contains ’token theft’” OR “Contains ‘session hijack.’”

The condition should be specific enough to target the correct alert type but broad enough to catch all variants. Testing after deployment will confirm whether the conditions match the expected incidents.

Actions. Add three actions in sequence:

Action 1: “Change severity” → set to “High.” AiTM incidents at NE are always High severity regardless of the detection’s default classification. This ensures AiTM incidents appear at the top of the queue.

Action 2: “Add tags” → enter “aitm-triage.” Tags serve two purposes: filtering in the incident queue (show me all aitm-triage tagged incidents) and playbook coordination (the enrichment playbook in SA1.4 will check for this tag to apply AiTM-specific enrichment).

Action 3: “Assign owner” → select the SOC Tier 2 analyst or queue. If your SOC uses individual assignment, select the identity analyst. If you use queues, select the identity queue. Avoid assigning to a single person — when that person is unavailable, incidents accumulate.

Order. Set to 100. This leaves room for future rules at lower order numbers (50 — severity overrides for other alert types) and higher order numbers (200 — playbook triggers that depend on the severity change).

Status. Enabled. There is no reason to create a disabled rule — deploy and validate.

Expiration. None. This is a permanent rule. Use expiration only for temporary rules created during active incidents.

Click “Apply” and the rule is live. Every AiTM incident created from this point forward is automatically set to High severity, tagged “aitm-triage,” and assigned to the correct analyst or queue.

Validating the rule

After deployment, validate that the rule works correctly. You need a test incident.

Option 1: Wait for a real alert. If your AiTM detection fires regularly, the next alert will trigger the rule. Check the incident: is the severity High? Is the tag present? Is the owner assigned? If yes, the rule works.

Option 2: Create a test incident manually. In Sentinel, navigate to Incidents → Create incident (preview). Set the title to include “AiTM” (matching your condition), set initial severity to Medium, and create the incident. Check immediately: did the automation rule change it to High and add the tag?

Option 3: Trigger the analytics rule. If you have a test environment, simulate the AiTM indicator (sign-in with MFA-claim-in-token from a new IP) to trigger the analytics rule. The resulting incident should have the automation rule applied.

If the rule did not fire, check: is the rule enabled? Does the analytics rule name match the condition exactly? Is the order number correct (not conflicting with another rule that closes the incident before this rule runs)?

Building three more rules in 10 minutes

Now that you know the process, build three additional rules:

Rule 2: Ransomware severity override (order 110). Trigger: incident created. Condition: analytics rule name contains “ransomware” OR “VSS deletion” OR “shadow copy.” Action: change severity to Critical. Ransomware indicators are always Critical at NE — they require immediate response.

Rule 3: Known FP auto-close (order 500). Trigger: incident created. Condition: analytics rule name = “Impossible Travel” AND incident title contains “ceo@northgateeng.com.” Actions: change status to Closed, classification = BenignPositive, add tag “auto-closed-known-travel,” add comment “Auto-closed: known weekly travel pattern for CEO. Monthly review scheduled.” Order 500 ensures this runs after any severity changes or enrichment triggers — you do not want to close an incident before enrichment runs.

Rule 4: Playbook trigger (order 200). Trigger: incident created. Condition: severity = High OR severity = Critical. Action: run playbook “SA-Playbook-Enrichment-General” (you will build this in SA1.4). This rule triggers the enrichment playbook on all high-priority incidents. Order 200 ensures it runs after Rule 1 (which sets AiTM to High at order 100).

Four rules. Fifteen minutes total. Your Sentinel automation is operational.

Your First Four Automation Rules

Rule	Order	Trigger	Condition	Actions
AiTM Triage	100	Created	Rule name contains “AiTM”	Severity → High, tag “aitm-triage”, assign Tier 2
Ransomware Priority	110	Created	Rule name contains “ransomware”	Severity → Critical
Playbook Trigger	200	Created	Severity = High or Critical	Run enrichment playbook
CEO Travel FP	500	Created	Rule = “Impossible Travel” + title has CEO	Close (BenignPositive), tag “auto-closed”