9.6 Automation Rules

Automation Rules

Introduction

Automation rules execute when incidents are created or updated. They perform no-code actions: assign ownership, change severity, add tags, suppress noise, and trigger playbooks. They are the first responder — handling routine triage tasks before an analyst opens the incident, freeing analyst time for actual investigation.

Automation rule architecture

An automation rule has three parts: a trigger (when does it run?), conditions (which incidents match?), and actions (what does it do?).

Triggers: “When incident is created” (most common) or “When incident is updated” (for workflow-based automation). The creation trigger fires once per incident. The update trigger fires whenever an incident property changes (status, severity, owner, etc.).

Conditions: Filter which incidents the rule applies to. Conditions can match on: analytics rule name, severity, status, entities (specific IP, account, or host), tags, incident provider, and any combination of these. Example: “Trigger when incident is created AND analytics rule name contains ‘brute force’ AND severity is High.”

Actions (in execution order):

Assign owner — route the incident to a specific analyst or team. Tag incident — add labels for categorisation (e.g., “identity-attack,” “phishing,” “review-needed”). Change severity — override the rule-assigned severity based on conditions. Change status — auto-close known false positives without analyst review. Run playbook — trigger a Logic Apps playbook for complex automated response. Suppress — prevent the rule from creating incidents for a time window (useful during planned maintenance).

Production automation rule examples

Example 1: Auto-assign by attack type. Route identity-related incidents to the identity specialist and endpoint incidents to the endpoint analyst.

Trigger: When incident is created. Condition: Analytics rule name contains “sign-in” OR “brute force” OR “MFA” OR “token.” Action: Assign owner → identity-analyst@northgateeng.com.

Second rule: Condition: Analytics rule name contains “process” OR “malware” OR “endpoint” OR “service install.” Action: Assign owner → endpoint-analyst@northgateeng.com.

Example 2: Severity escalation for VIP users. Automatically escalate any incident involving executive accounts to High severity.

Trigger: When incident is created. Condition: Entity Account contains any of: ceo@, cfo@, ciso@, board-member@. Action: Change severity → High. Add tag → “VIP.” Run playbook → “Notify-CISO-Channel.”

Example 3: Auto-close known false positives. Suppress incidents from a rule that consistently fires for a specific benign condition while you work on tuning the rule.

Trigger: When incident is created. Condition: Analytics rule name = “Suspicious PowerShell execution” AND Entity Host = “BUILD-SERVER-01.” Action: Change status → Closed. Classification → False Positive. Add tag → “auto-closed-known-benign.”

This is a tactical fix — it suppresses the noise while you tune the analytics rule’s KQL to exclude the build server. Remove the automation rule once the analytics rule is tuned.

Example 4: Tag incidents by data source for reporting. Automatically tag incidents based on which analytics rule created them.

Trigger: When incident is created. Condition: Analytics rule name contains “CEF” OR “CommonSecurityLog.” Action: Add tag → “network-detection.”

This enables workbook reporting that groups incidents by detection layer (identity, endpoint, network, custom).

Automation rule ordering and execution

Automation rules execute in the order you define (you can set the execution order when multiple rules match the same incident). The first rule executes first, then the second, and so on.

Order matters for conflicting actions. If Rule 1 assigns to analyst-A and Rule 2 assigns to analyst-B, the last rule to execute wins (Rule 2). If Rule 1 sets severity to High and Rule 2 sets severity to Medium, Medium wins.

Best practice: Assign execution order intentionally. Generic rules (auto-tag all incidents) execute first. Specific rules (escalate VIP incidents) execute after — overriding the generic rules where needed.

Expiration dates. Automation rules can have an expiration date — useful for tactical suppression rules. “Auto-close false positives from BUILD-SERVER-01 until 2026-04-15” — after which the rule expires automatically, ensuring tactical fixes do not become permanent blind spots.

Advanced condition patterns

Automation rule conditions can match on multiple properties simultaneously, enabling precise targeting.

Condition: Analytics rule name. Match incidents from a specific detection. Use contains for partial matching: “Analytics rule name contains ‘brute force’” matches “Brute force followed by success” and “Distributed brute force from proxy.”

Condition: Entity values. Match incidents involving specific entities. “Entity Host contains ‘DC-’” matches all domain controller incidents. “Entity Account contains ‘admin’” matches incidents involving admin accounts.

Condition: Tag values. Match incidents that already have specific tags (useful for chaining automation rules). Rule 1 adds tag “identity-attack.” Rule 2 triggers on incidents with tag “identity-attack” AND severity High → runs the containment playbook. This creates a two-stage automation pipeline.

Condition: Incident provider. Match by the source product. “Incident provider equals Microsoft 365 Defender” targets only Defender XDR-synced incidents. Useful for routing Defender incidents to a different team than Sentinel-native incidents.

Complex condition example — shift-based routing:

Rule 1 (business hours): Condition = “Incident created between 08:00-18:00 UTC” → Assign to day-shift@northgateeng.com. Rule 2 (out-of-hours): Condition = “Incident created between 18:00-08:00 UTC” → Assign to night-shift@northgateeng.com, add tag “after-hours.” Rule 3 (all hours): Condition = severity = High → Run playbook “Notify-SOC-Manager” (overrides time-based routing for critical incidents).

Note: time-based conditions are not natively supported in automation rules. Implement by: using the playbook trigger to check the current time and route accordingly, or deploying a Logic App that runs hourly and reassigns unassigned incidents based on the current shift schedule.

Building the automation rule library

Organise your automation rules into categories for maintainability.

Category 1: Routing rules. Assign incidents to the correct analyst or team based on attack type, severity, or data source. These are the most common automation rules.

Category 2: Enrichment rules. Add tags that categorise incidents for reporting: “network-detection,” “identity-attack,” “endpoint-alert,” “custom-source.” These tags power workbook filters (subsection 9.9).

Category 3: Escalation rules. Increase severity or trigger playbooks when conditions indicate a high-priority threat: VIP user involved, multiple entities affected, or correlation with known campaigns.

Category 4: Suppression rules. Auto-close known false positives with expiration dates. Always document the suppression rationale and set an expiration.

Category 5: Playbook triggers. Rules whose primary purpose is to trigger a specific playbook for automated response.

Naming convention: Use a consistent naming format: [Category]-[Target]-[Action]. Examples: Routing-Identity-AssignToIdentityTeam, Escalation-VIP-RaiseSeverityHigh, Suppression-BuildServer-AutoClose-Expires20260415, PlaybookTrigger-BruteForce-UserContainment. This makes the automation rule library searchable and understandable months after creation.

Incident update triggers: workflow automation

Beyond creation triggers, automation rules can fire when incidents are updated — enabling workflow-based automation.

Use case 1: Escalation on reassignment. When an analyst reassigns a High-severity incident to a different analyst (indicating they need help), trigger a Teams notification to the SOC manager.

Trigger: When incident is updated. Condition: Severity = High AND Status changed to Active AND Owner changed. Action: Run playbook “Notify-SOC-Manager-Escalation.”

Use case 2: SLA breach alerting. When a High-severity incident has been Active for more than 4 hours without being closed, trigger an alert.

This requires a scheduled approach rather than an update trigger (because the incident was NOT updated — that is the problem). Create a scheduled analytics rule that queries SecurityIncident for Active + High + age > 4 hours and generates an alert. The automation rule then acts on the alert.

1
2
3
4
5
6
7
8

// SLA breach detection — incidents active too long
SecurityIncident
| where Status == "Active"
| where Severity == "High"
| where datetime_diff('hour', now(), CreatedTime) > 4
| project IncidentNumber, Title, Severity, CreatedTime,
    AgeHours = datetime_diff('hour', now(), CreatedTime),
    Owner = tostring(Owner.assignedTo)

Use case 3: Auto-close on resolution playbook completion. When a playbook adds a comment containing “CONTAINMENT_COMPLETE” to the incident, automatically close the incident.

Trigger: When incident is updated. Condition: Comments contain “CONTAINMENT_COMPLETE.” Action: Change status → Closed. Classification → True Positive.

This creates a fully automated loop: analytics rule detects threat → automation rule triggers containment playbook → playbook contains threat and adds completion marker → automation rule closes incident. No human interaction required for high-confidence, fully-automated response chains.

Automation rule templates for common scenarios

These templates cover the most common automation needs. Adapt the conditions and actions for your environment.

Template: Route by MITRE tactic.

Name: Routing-Tactic-InitialAccess-AssignIdentityTeam
Trigger: When incident is created
Condition: Tactics contains "InitialAccess" OR Tactics contains "CredentialAccess"
Actions:
  1. Assign owner → identity-team@northgateeng.com
  2. Add tag → "identity-triage"
Order: 10

Template: VIP user escalation.

Name: Escalation-VIP-RaiseSeverityAndNotify
Trigger: When incident is created
Condition: Entity Account contains value from watchlist "VIPUsers"
Actions:
  1. Change severity → High
  2. Add tag → "vip-user"
  3. Run playbook → "Notify-CISO-Channel"
Order: 50 (runs after routing rules)

Template: After-hours notification.

Name: Notification-AfterHours-EscalateHigh
Trigger: When incident is created
Condition: Severity = High
Actions:
  1. Run playbook → "AfterHours-Notification"
     (Playbook checks time; if outside 08:00-18:00 UTC,
      sends SMS to on-call analyst)
Order: 100

Template: Maintenance window suppression.

Name: Suppression-MaintenanceWindow-AutoClose
Trigger: When incident is created
Condition: Analytics rule name contains "Suspicious Process"
  AND Entity Host contains "PATCH-SERVER"
Actions:
  1. Change status → Closed
  2. Classification → Benign Positive
  3. Add tag → "maintenance-window-suppression"
Expiration: 2026-04-01T06:00:00Z (maintenance ends)

Automation rules for multi-stage incident management

Chain automation rules to create multi-stage workflows.

Stage 1 (creation): Automation rule routes the incident, adds initial tags, and triggers an enrichment playbook.

Stage 2 (enrichment complete): When the enrichment playbook adds a comment with TI results, a second automation rule checks the results. If the IP is confirmed malicious (comment contains “MALICIOUS”), escalate severity and trigger the containment playbook.

Stage 3 (containment complete): When the containment playbook adds “CONTAINMENT_COMPLETE,” a third automation rule closes the incident as True Positive.

This three-stage chain provides: automatic routing, automatic enrichment, automatic containment, and automatic closure — with each stage triggered by the completion of the previous stage. The entire chain executes within 2-5 minutes of incident creation.

Automation rule limits and constraints

Rule limit. Each workspace supports up to 512 automation rules. This is sufficient for most deployments, but track your usage if you create many tactical suppression rules.

Condition complexity. Each automation rule supports up to 10 conditions in an AND/OR combination. For more complex logic, use a playbook — the Logic Apps designer supports unlimited conditional branches.

Execution time. Automation rules execute within seconds. If a playbook is triggered, the automation rule itself completes instantly — it does not wait for the playbook to finish. The playbook runs asynchronously.

No loops. Automation rules cannot trigger other automation rules in a chain (to prevent infinite loops). If Rule A modifies an incident and Rule B triggers on incident update, Rule B fires — but any changes Rule B makes do not re-trigger Rule A.

Automation maturity progression

Build automation incrementally. Start simple and add complexity as you gain confidence.

Level 1: Tagging only. Deploy automation rules that add tags to incidents based on the analytics rule name or entity type. No changes to severity, assignment, or status. Risk: zero — tags are additive and do not affect investigation. Value: enables workbook filtering and reporting by attack category.

Level 2: Assignment routing. Add automation rules that assign incidents to specific analysts or teams based on attack type or severity. Risk: low — if the assignment is wrong, the analyst can reassign manually. Value: eliminates the “who picks this up?” lag at the start of every incident.

Level 3: Severity adjustment. Add rules that escalate severity for VIP users or known-malicious indicators. Risk: low-medium — an incorrect escalation creates urgency for a benign event. Mitigate with accurate VIP watchlists. Value: ensures critical incidents receive immediate attention.

Level 4: Tactical suppression. Add rules that auto-close known false positives with expiration dates. Risk: medium — suppressing a genuine threat is a detection failure. Mitigate with strict conditions, expiration dates, and post-tuning review. Value: reduces analyst noise by 10-30%.

Level 5: Playbook-triggered response. Add rules that trigger containment playbooks for high-confidence, high-severity detections. Risk: medium-high — automated containment actions affect users and systems. Mitigate with approval workflows for VIP users, staged rollout, and failure notification. Value: reduces Mean Time to Contain from hours to minutes.

Progress through each level over 4-8 weeks. Do not jump to Level 5 without Level 1-4 operating correctly — each level builds the confidence and operational maturity needed for the next.

Automation ROI calculation

Quantify the value of automation to justify investment in playbook development.

Time saved per incident. Measure the tasks automation handles and estimate the analyst time saved.

Automatic assignment: saves ~2 minutes per incident (analyst does not need to review the queue and self-assign). At 50 incidents/day = 100 minutes saved daily.

Automatic enrichment: saves ~5 minutes per incident (analyst does not run manual TI lookups). At 20 High-severity incidents/day = 100 minutes saved daily.

Automatic containment: saves ~15 minutes per incident (analyst does not manually revoke tokens, reset passwords, isolate devices). At 5 containment actions/day = 75 minutes saved daily.

Total daily time saved: 275 minutes (~4.5 hours). That is more than half an analyst’s shift freed for investigation rather than routine tasks.

Cost justification: If an analyst costs £75/hour, 4.5 hours/day saved = £337/day = £7,400/month. Against the cost of Logic Apps execution (~£50/month for the playbook compute) and the initial development time (~40 hours × £75 = £3,000 one-time), the ROI is achieved within the first month.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Estimate automation time savings — incidents with automation vs without
let AutomatedIncidents = SecurityIncident
| where TimeGenerated > ago(30d)
| where Status == "Closed"
| where Tags has "auto-enriched" or Tags has "auto-contained"
| summarize AvgMTTR_auto = avg(datetime_diff('minute', ClosedTime, CreatedTime));
let ManualIncidents = SecurityIncident
| where TimeGenerated > ago(30d)
| where Status == "Closed"
| where not(Tags has "auto-enriched") and not(Tags has "auto-contained")
| summarize AvgMTTR_manual = avg(datetime_diff('minute', ClosedTime, CreatedTime));
AutomatedIncidents | extend Type = "Automated"
| union (ManualIncidents | extend Type = "Manual")

Automation rule quarterly audit

Every quarter, audit your automation rule library.

Check 1: Execution rate. Are all rules executing? Rules with zero executions in 90 days may be targeting incident conditions that no longer occur (the analytics rule was renamed, the entity pattern changed). Disable or update.

Check 2: Suppression rule expiration. Are all tactical suppression rules still within their expiration date? If any expired, they are no longer executing — which is correct. But check: was the underlying analytics rule tuned as planned? If not, the false positive pattern has returned without suppression.

Check 3: Assignment accuracy. Are incidents being routed to the correct analysts? If organisational structure has changed (new team members, role changes), update the assignment automation rules.

Check 4: Playbook health. Are all triggered playbooks executing successfully? Check Logic App run histories for failures. Renew any expiring managed identity credentials or API keys.

Monitoring automation rule execution

Verify your automation rules are executing correctly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Automation rule execution audit
SentinelHealth
| where TimeGenerated > ago(7d)
| where SentinelResourceType == "Automation rule"
| summarize
    Executions = count(),
    Successes = countif(Status == "Success"),
    Failures = countif(Status != "Success")
    by SentinelResourceName
| extend SuccessRate = round(Successes * 100.0 / Executions, 1)
| order by Executions desc

Rules with less than 100% success rate need investigation. Common failures: the assigned user does not exist (left the organisation), the playbook trigger failed (Logic App permissions expired), or the condition matched unexpectedly broad incidents.

Automation rules vs playbooks: when to use which

Automation rules are for simple, no-code actions: assign, tag, change severity, suppress, trigger playbooks. They execute instantly. They require no external service configuration. Use for: routing, categorisation, severity adjustment, and noise suppression.

Playbooks are for complex, multi-step workflows: send notifications, query external APIs, isolate devices, reset passwords, create tickets, and multi-conditional logic. They execute via Logic Apps and take 30 seconds to several minutes. Use for: response actions that involve external systems.

Combined pattern: An automation rule triggers a playbook. The automation rule handles the immediate no-code action (assign, tag, escalate severity), then triggers the playbook for the complex action (notify Teams, isolate device, create ServiceNow ticket). This combines instant triage with automated response.

Knowledge check