Purpose of This Lesson

Microsoft Sentinel automation rules apply consistent actions to incidents and alerts without requiring an analyst to handle every step manually. They are useful for routing work, standardizing incident handling, and invoking response workflows such as playbooks.

This lesson focuses on creating a rule that automatically assigns newly created medium- and high-severity incidents to a designated analyst.

Key Concepts

What an Automation Rule Does

An automation rule evaluates Sentinel incidents or alerts against configured criteria. When the trigger and conditions match, Sentinel performs one or more actions.

A rule can be used to:

• Assign an incident owner.
• Change incident status.
• Change incident severity.
• Add tags or tasks.
• Run a playbook.
• Apply multiple actions in a defined sequence.

Automation rules are configured in the Microsoft Sentinel Automation area, accessed through the Microsoft Defender portal at security.microsoft.com.

Triggers

The trigger determines when Sentinel evaluates the rule. The lesson identifies three common trigger types:

• When an incident is created: Useful for immediate routing and enrichment.
• When an incident is updated: Useful when later changes should initiate additional processing.
• When an alert is created: Useful for alert-level response or enrichment before, or as part of, incident handling.

Choose the earliest trigger that matches the required workflow. For example, an ownership rule normally belongs on incident creation rather than incident update, unless reassignment is intentionally tied to later changes.

Conditions

Conditions restrict the rule to relevant incidents or alerts. Examples include:

• Severity
• Status
• Description or other incident properties
• Associated analytics rule
• Additional criteria joined with logical AND or OR relationships

A rule can target more than one severity. In the example, the condition matches incidents whose severity is medium or high.

Actions

Actions define what happens after the trigger and conditions match. The example uses assign owner to route the incident to a specific analyst. Other actions can be added, and they execute according to the rule’s action sequence.

An action that changes ownership should be supported by an operational process. For example, a named analyst may be appropriate in a lab, but a rotating queue, team owner, or workload-based assignment is usually safer in a production SOC.

Expiration

Automation rules can be configured to run indefinitely or to expire at a specified time. An expiration date is useful for temporary exercises, pilot workflows, on-call coverage, or incident-specific routing.

Microsoft Security Operations Context

Automation rules are part of the Microsoft Sentinel incident-management workflow. They complement, rather than replace:

• Analytics rules, which detect activity and create alerts or incidents.
• Playbooks, which use Azure Logic Apps to perform multi-step automated response.
• Workbooks, which visualize operational and security data.
• Manual triage, which remains necessary for investigation, validation, and decisions that require analyst judgment.

A typical flow is:

1. A data connector supplies telemetry to Sentinel.
2. An analytics rule detects suspicious activity.
3. Sentinel creates an alert or incident.
4. An automation rule evaluates the new object.
5. Sentinel assigns, updates, tags, or enriches the incident, or starts a playbook.
6. An analyst investigates and documents the outcome.

Automation should reduce repetitive handling without weakening evidence review or escalation controls.

Tool / Feature Decision Guide

Requirement	Appropriate Sentinel capability	Notes
Detect suspicious activity	Analytics rule	Produces alerts and, depending on configuration, incidents.
Assign incidents based on severity or other properties	Automation rule	Use conditions to limit the scope of routing.
Perform multi-step response actions	Playbook invoked by an automation rule	Validate permissions, connectors, and failure handling.
Track visual trends and operational metrics	Workbook	Does not replace incident automation.
Investigate an individual incident	Incident investigation and related entities	Analyst review is still required after automated actions.

Exam-Relevant Takeaways

• Automation rules are configured in Microsoft Sentinel > Configuration > Automation.
• A rule consists of a trigger, optional conditions, and one or more actions.
• Trigger choices include incident creation, incident update, and alert creation.
• Conditions can filter by severity and other incident or alert attributes.
• Actions can assign an owner, change status or severity, add tags or tasks, or run a playbook.
• Multiple conditions can be combined with logical AND or OR operators.
• Multiple actions can be added to one rule and execute in their configured order.
• Automation rules themselves have an execution order. Rules run serially in ascending order, so the lower order number has higher priority.
• Rules may be indefinite or configured with an expiration date.
• The best answer in a scenario is usually the narrowest rule that meets the requirement while minimizing unintended tenant-wide or workspace-wide impact.

Common Exam Traps

• Confusing analytics rules with automation rules: Analytics rules detect activity; automation rules respond to created or updated alerts and incidents.
• Using the wrong trigger: A rule intended to route new incidents should use incident creation, not incident update, unless the scenario specifically requires later reassignment.
• Ignoring rule order: Multiple matching rules may execute sequentially. A later rule may modify the result of an earlier rule.
• Assuming automation proves malicious activity: An automation rule performs configured actions; it does not validate whether an alert is a true positive.
• Overly broad conditions: A rule that matches all incidents can unexpectedly reassign, retag, or modify unrelated work.
• Forgetting expiration: Temporary routing or testing rules should not normally be left indefinite.
• Treating a named user as a scalable queue: Direct assignment may create bottlenecks or leave incidents unattended when that analyst is unavailable.

Real-World SOC Analyst Notes

• Start with a narrow scope, test in a controlled environment, and review the rule’s behavior before expanding it.
• Document the business reason, owner, conditions, actions, expiration, and expected impact for every production rule.
• Use severity as one routing signal, not as a substitute for triage. Severity can be misclassified by detection logic or later changed by an analyst.
• Be cautious with rules that change severity or close incidents automatically. These actions can hide risk and interfere with reporting or escalation.
• When invoking a playbook, verify permissions, connector authentication, target scope, error handling, and whether the action is reversible.
• Preserve investigation evidence. Automated tagging or assignment should not replace notes, timelines, entity review, and escalation procedures.
• Review rule interactions. Two rules that both assign owners or change severity can produce confusing outcomes depending on execution order.
• Apply change control to production automation. A small configuration error can affect a large volume of incidents.
• Reassess indefinite rules periodically. Staffing models, severity definitions, analytics rules, and escalation policies change over time.

Quick Reference Summary

1. Open Microsoft Sentinel in the Microsoft Defender portal.
2. Go to Configuration > Automation.
3. Create an automation rule.
4. Select the trigger, such as when an incident is created.
5. Add conditions, such as severity equals medium or high.
6. Select one or more actions, such as assigning an owner.
7. Set the expiration policy.
8. Set the rule order relative to other automation rules.
9. Apply the rule and validate its behavior with test incidents.

Flashcards

1. Q: What is the purpose of a Microsoft Sentinel automation rule?

A: To automatically perform actions on matching alerts or incidents.

1. Q: Where are Sentinel automation rules configured?

A: In Microsoft Sentinel under Configuration > Automation.

1. Q: Name three automation-rule triggers.

A: When an incident is created, when an incident is updated, and when an alert is created.

1. Q: What is the difference between a trigger and a condition?

A: The trigger determines when evaluation starts; conditions determine which alerts or incidents qualify.

1. Q: Can a rule match both medium- and high-severity incidents?

A: Yes. The severity criteria can use an OR relationship or an equivalent multi-value condition.

1. Q: What action assigns an incident to an analyst?

A: The assign owner action.

1. Q: What other actions can an automation rule perform?

A: It can change status or severity, add tags or tasks, and run a playbook.

1. Q: How are multiple automation rules ordered?

A: They execute serially in ascending order; the lower order number has higher priority.

1. Q: Why use an expiration date?

A: To limit temporary or experimental automation and prevent stale routing logic from remaining active indefinitely.

1. Q: Does an automation rule determine whether an incident is a true positive?

A: No. It performs configured actions; an analyst or investigation workflow must validate the incident.

Practice Questions

Question 1

A SOC wants every newly created medium- and high-severity Sentinel incident routed to the active triage analyst. Which configuration is most appropriate?

A. Create an analytics rule triggered by incident updates and change the incident severity.
B. Create an automation rule triggered when an incident is created, filter for medium or high severity, and assign an owner.
C. Create a workbook that filters incidents by severity.
D. Create a data connector that assigns incident ownership.

Correct answer: B

Explanation: An automation rule is designed for post-detection incident handling. The incident-created trigger, severity condition, and assign-owner action directly satisfy the requirement.

Question 2

Two Sentinel automation rules match the same incident. The SOC must ensure the first rule runs before the second. What should the analyst configure?

A. The analytics rule’s query frequency
B. The data connector’s polling interval
C. The automation rules’ execution order
D. The incident’s investigation graph

Correct answer: C

Explanation: Matching automation rules execute serially according to their order. A lower order number runs first.

Question 3

A team creates a routing rule for a two-week on-call rotation. Which configuration best reduces the risk of stale behavior?

A. Set the rule to run indefinitely.
B. Configure an expiration date at the end of the rotation.
C. Remove all conditions so every incident is routed.
D. Trigger the rule only when an alert is closed.

Correct answer: B

Explanation: An expiration date automatically limits the temporary routing rule and avoids leaving it active after the on-call period.

Question 4

A playbook must disable a user account whenever a high-severity incident is created. Before enabling the automation, what is the most important operational consideration?

A. Whether the workbook has enough visualizations
B. Whether the action is authorized, appropriately scoped, and safe for possible false positives
C. Whether all incidents are assigned to one analyst
D. Whether the rule has no expiration date

Correct answer: B

Explanation: Disabling an account is a high-impact action. The SOC should validate permissions, scope, approvals, false-positive risk, and rollback or recovery procedures before automating it.