Microsoft SC200 - Sentinel SIEM/SOAR Part 2

Sentinel Detections and Automations

In the previous section, we explored Workspace Manager, Data Connectors, and Settings. This section dives deeper into Sentinel's detection and response capabilities, focusing on:

Analytics
Watchlists
Automation

Configuration and settings for these features can also be found under the sentinel Configuration section.

Sentinel Analytics (Detection Rules)

Analytics rules are the core of Sentinel’s threat detection engine. These rules run queries against your ingested data and trigger alerts when suspicious patterns or behaviors are found. They form the foundation of proactive threat detection within your SIEM.

Sentinel Watchlists

Watchlists are custom tables you can upload and use within detection logic. Common use cases include:

Whitelisting known safe entities (e.g., internal admin machines)
Triggering alerts on high-value assets (e.g., list of executive laptops or sensitive servers)

They enable dynamic filtering, customization, and precise targeting within analytic queries.

Sentinel Automation (Playbooks)

For repetitive or well-understood tasks, Sentinel allows you to automate response actions through Logic Apps-based playbooks. These automations can:

Enrich alerts with threat intel
Send notifications or ticketing actions
Isolate endpoints or disable accounts

This helps reduce manual workload and speeds up incident response across repeatable processes.

Microsoft Sentinel Analytics

In Microsoft Sentinel, Analytics Rules are built using Kusto Query Language (KQL) to monitor ingested log data and trigger alerts based on defined conditions. These rules are foundational to threat detection in Sentinel and come in multiple types based on how and when they run.

Types of Analytics Rules in Microsoft Sentinel

1. Scheduled Analytics Rules

These are KQL-based detections executed at fixed intervals (e.g., every 5, 10, or 12 hours).
Best for:
- Correlating events over a time window
- Integrating entity mapping
- Building detections that use historical patterns

2. Near Real-Time (NRT) Analytics Rules

Run at high frequency, typically every minute, much faster than regular scheduled rules.
Use ingestion time (TimeGenerated) instead of event-generation time, which minimizes delay due to log ingestion latency.
Limitations:
- Cannot query across multiple workspaces
- Not suited for rules requiring lookback or stateful logic

Tip: NRT rules are ideal for high-priority signals where speed matters more than depth.

Entity Mapping in Analytics Rules

Available in - Scheduled and NRT rules
Purpose - Automatically extracts key entities (usernames, IPs, hosts, etc.) from the query output and maps them to Sentinel’s incident model.
Why it matters - Enriched alerts provide more context for investigation and automate response workflows.

Note: Entity mapping is not supported in Fusion, Threat Intelligence, or Microsoft Security Incident rules.

3. Threat Intelligence Detections

Leverage threat intel feeds to detect known IOCs (IPs, domains, file hashes).
Useful for identifying confirmed malicious infrastructure or indicators.

4. Microsoft Security Incident Detections

Based on alerts generated from Microsoft security products like Defender for Endpoint or Defender for Identity.
These alerts are automatically ingested and surfaced as incidents in Sentinel.

5. Fusion Rules

Use machine learning to correlate low- to medium-fidelity signals into a high-confidence incident.
Designed to identify multi-stage attacks across various data sources (e.g., lateral movement + credential access).
Important: Fusion rules correlate signals but do not create custom analytics rules or allow user-defined queries.

6. Anomaly Detection

Leverages behavioral baselines to detect deviations in user or system activity.
Common sources: Azure Active Directory logs, sign-in behavior, etc.
Watch out: Too-sensitive thresholds can lead to a high volume of alerts, tune these carefully.

7. Machine Learning (ML) Behavior Analytics

Uses advanced AI to spot malicious behavior patterns over time.
Complements rule-based detections by surfacing previously unseen tactics.

Sentinel Analytics - Understanding and Creating Analytic rules

In Microsoft Sentinel, the Analytics section (found under Configuration) allows you to view, manage, and create analytic rules that define how the SIEM detects suspicious activity and generates alerts.

Within the Analytics section of Microsoft Sentinel, you'll find three main tabs: Active rules, Rule templates, and Anomalies. By default, the Active rules tab is selected, displaying all currently enabled detection rules in your environment.

Now we will drill down into each of the main Analytic rue sub-sections.

Sentinel Analytics - Active Rules

In the Active Rules tab of Microsoft Sentinel, you’ll see a list of detection rules currently enabled in your SIEM. Each rule includes key fields such as Status, MITRE ATT&CK Tactic, Technique, and Sub-Technique.

Two of the most important columns are:

Rule Type – Common types include:
- Scheduled: Runs KQL queries at set intervals.
- Microsoft Security: Ingests alerts from Microsoft security products.
- Fusion, Near-real-time (NRT), or Anomaly: Specialized rule types for advanced detection.
Source – Indicates the origin of the rule, such as:
- Custom Content: Created manually in your environment.
- Gallery Content: Provided by Microsoft or community.
- Threat Intelligence or Microsoft 365: Based on integrated security solutions.

Sentinel Analytics - Rule templates

The queries within scheduled rule templates are written by security and data science experts, either from Microsoft or from third-party solution vendors. These templates come fully preconfigured, including the KQL query and rule parameters, and are ready to be enabled with minimal modification.

To enable an analytic rule from a template in Microsoft Sentinel:

Simply select “Create rule”. This launches the rule creation wizard, which comes pre-populated with default values.
Each template lists its required data sources. If your environment does not have the necessary log sources connected, the rule will not function correctly.
When you open a template, Sentinel automatically checks for data source availability. If a required source is missing, the “Create rule” button may be disabled, and a message will inform you of the issue.

Always verify that the needed data connectors are enabled before attempting to activate a rule.

Note: While these templates provide a solid starting point, most SIEM practitioners know that out-of-the-box content often needs tuning to work effectively in a specific environment. Still, they are valuable baselines for building and enabling new detection rules tailored to your organization.

Sentinel Analytics - Anomalies

Anomaly rules in Microsoft Sentinel leverage User Entity Behavior Analytics (UEBA) and Machine Learning (ML) to monitor specific behaviors over time, establishing a baseline of what’s considered normal. When activity exceeds that baseline, it’s flagged as anomalous.

Sentinel provides built-in anomaly templates that deliver immediate value. These templates are customizable, allowing you to tune thresholds and parameters to fit your environment.

Important: You cannot directly edit a built-in anomaly rule. To customize one, first duplicate the rule, then modify the copy. The original rule continues running until you disable or delete it.

Types of Anomaly Detection Models

Sentinel uses two distinct models for anomaly detection:

1. UEBA Anomalies (User and Entity Behavior Analytics)

These focus on deviations from normal user or entity behavior. Common detections include:

Anomalous Account Access Removal
Anomalous Account Creation / Deletion / Manipulation
Anomalous Code Execution
Anomalous Data Destruction
Anomalous Privilege Grants
Anomalous Sign-ins / Failed Sign-ins
Anomalous Password Resets

UEBA-based detections require the UEBA feature to be enabled in your Sentinel environment.

2. Machine Learning-Based Anomalies

These detections are based on statistical irregularities and behavioral outliers—not necessarily linked to specific entities. Examples include:

Suspicious volume of logins to a computer
Suspicious volume of logins with elevated tokens
Suspicious logins to a user account

These anomalies are driven by unusual patterns that may not be inherently malicious, but they can greatly enhance detection quality, investigation workflows, and proactive threat hunting.

Analytics Rule Creation

To create a new analytics rule, select "Create" and then choose "Scheduled query rule"—the most commonly used rule type in Sentinel.

Scheduled rules use Kusto Query Language (KQL) to analyze data over a defined lookback period at regular intervals. If the query returns a number of results that exceed a configured threshold, an alert is generated. this will bring up the analytics rule creation wizard.

The first step in the analytics rule wizard is the General tab. Here, you define key details such as the rule name, description, severity, and MITRE ATT&CK mappings. You can also toggle the setting to enable or disable the rule by default.

Tip: Add the Mitre ATT&CK Tactics Techniques and sub-Techniques the analytic rule is designed to detect. This helps with detection coverage mapping and SOC audits. Sentinel has a Mitre ATTACK under Threat Management that displays the number of analytic rules your Sentinel instance has for each Mitre ATTACK technique.

The next step in the rule creation wizard is Set rule logic. This is where you define the KQL query that powers the detection and configure key logic settings, such as scheduling frequency, lookback period, and alert threshold.

The Alert enrichment section includes three key components: Entity Mapping, Custom Details, and Alert Details.

Entity Mapping is especially critical for scheduled analytics rules. It enriches alerts and incidents with relevant entities, such as IPs, accounts, and hostnames, that play a vital role in investigations and response actions.

Microsoft Sentinel recognizes entities added through analytics rule mappings as well as those natively included in external alerts. You can map up to three identifiers per entity. Strong identifiers (like a full email address or IP) can uniquely identify an entity on their own, while weak identifiers may require additional context. The entity mapping enrichment improves alert clarity and helps drive automated response and deeper insights during threat investigation.

To add an entity, click Add new entity, then select the appropriate entity type (e.g., IP, URL, account).

Next, you’ll map the field name from the log source to the corresponding field in the Sentinel schema for that entity type. When a log event matches the rule (e.g., username, IP, or URL), Sentinel will assign that field’s value to the appropriate entity field, enabling accurate correlation and enrichment.

Further down in the Set rule logic section, you’ll find critical configuration options such as Query Schedule and Alert Thresholds. These play a key role in how your detection rules behave and perform.

Query Schedule

Run query every: This setting defines how frequently the query runs. While it may seem ideal to run queries as often as possible for faster detections, frequent execution, especially of complex queries, can significantly impact system performance. Common intervals include every 15 minutes, hourly, or even daily, depending on the nature of the detection.
Lookup data from the last: This defines the lookback window the query uses each time it runs. A common mistake is to set this shorter than the query frequency. For example, if the rule runs every 2 hours but only looks back 1 hour, you’ll have a 1-hour data gap. Typically, this value should match or slightly exceed the query interval to avoid missed detections due to timing mismatches.

Ingestion Delay Considerations

Log ingestion delays can lead to missed detections. These delays can occur across three stages:

Source System Delay: The system generating audit logs might batch them and send them at intervals, causing a delay between event occurrence and log transmission.
Forwarding Infrastructure Delay: Systems like syslog servers or message brokers (e.g., Event Hubs) may introduce their own processing delays.
SIEM Ingestion Delay: Finally, the SIEM itself can experience delays in parsing and ingesting incoming logs.

For example, if your rule runs every 5 minutes with a 5-minute lookback window, but the log arrives 10 minutes late due to upstream delay, the event won’t be detected. By the time the log is ingested, the next query run has already passed that time range.

Tip: Some logging systems also include an “ingest timestamp,” which can be useful for aligning queries to ingestion time rather than event time. However, not all platforms support this natively in their detection logic.

Alert Thresholds

The Alert Threshold settings are essential when you want an alert to trigger only after a certain number of events occur, often used for detecting high-frequency or repeated activity.

A common example is failed logon attempts. Users occasionally mistype passwords, generating one or two failed logins, which is usually benign. However, a high number of failed logins, especially across multiple systems, could indicate a brute-force password attack, or more commonly, a misconfigured script using outdated credentials.

You can also define how alerts are grouped:

Grouped alert: Multiple matching events are rolled into a single alert (e.g., one alert for 10 failed logons).
Individual alerts: Each matching event triggers its own alert (e.g., 10 alerts for 10 failed logons).

Another key option is suppression, which prevents the rule from running again for a defined period after an alert is generated. This helps avoid alert fatigue by limiting duplicate or excessive alerts for the same behavior.

Incident Settings

The next tab in the analytics rule wizard is Incident Settings, where you configure how alerts generated by the rule are handled, specifically whether they create incidents and how multiple alerts are grouped.

Understanding the distinction between alerts and incidents is key:

Alerts: Signals generated from threat detection logic indicating potentially malicious or suspicious activity.
Incidents: Containers that group related alerts together to represent a broader security event. These can span across Microsoft solutions and external integrations.

You can configure the following options:

Create incidents from alerts triggered by this rule - This option enables the creation of a new incident whenever this analytic rule triggers an alert.
Group related alerts into incidents - If enabled, alerts triggered by this rule will be grouped into a single incident if they share common entities (e.g., user, IP, hostname) within a specific time window. Up to 150 alerts can be grouped into a single incident.
- For example, if an alert fires based on a suspicious login and another fires 15 minutes later with the same user or IP, both may be grouped into a single incident.
- This setting is particularly useful for consolidating fragmented detections into a single, coherent picture.

This grouping logic helps analysts connect the dots across related activities, providing a more streamlined and contextualized investigation experience. However, there’s a trade-off: in some cases, unrelated alerts may be grouped together if they share similar entities, so tuning and testing are essential.

When configuring alert grouping in Microsoft Sentinel, you have a few important options to control how alerts are grouped into incidents:

Time Frame: By default, any alerts triggered within 5 hours of the first alert in an incident are added to the same incident. After this window, a new incident is created. You can customize this window anywhere between 5 minutes and 7 days, depending on the nature of the detection.
Grouping Criteria: You can choose how Sentinel determines which alerts are grouped together:
- Group alerts if all entities match – Alerts are grouped only when all associated entities (such as IP, account, or host) are the same.
- Group all alerts from this rule into a single incident – Regardless of entity differences, all alerts from this rule are grouped together.
- Group alerts if selected entities and custom details match – Provides more control by specifying certain entity types or alert fields that must match to group.

Automated Response

Automation rules allow you to centrally manage and coordinate automation across your Microsoft Sentinel environment. These rules provide a structured way to apply automation logic across multiple scenarios, enhancing both efficiency and consistency. Automation workflows are first created and stored in the Automation Library, accessible from the Sentinel configuration section. Once defined, these automations can be linked directly to analytic rules during rule creation via the wizard interface.

When to Implement Automation

In most scenarios, incident-triggered automation is the preferred method.

In Sentinel, an incident acts as a comprehensive case file, it aggregates all relevant evidence, including alerts, entities, analyst comments, and other investigation artifacts. While alerts represent individual detection signals, incidents provide context by combining related alerts and enriching them with additional information.

This makes incidents the ideal trigger point for automation, as they represent a fuller picture of a potential threat. Automations applied at the incident level can streamline processes such as:

Auto-assigning incidents based on severity or entity type
Enriching incidents with threat intelligence
Sending notifications or initiating playbooks
Closing false positives automatically

By focusing automation on incidents, you ensure that responses are context-aware and reduce the noise caused by automating every individual alert.

The final step in the rule creation wizard is the Review and Create tab, which provides a summary of all your configured settings. Once reviewed, you can finalize and deploy the analytic rule.

Analytics Rule Efficiency, Workbooks, and Rule Reruns

Microsoft Sentinel provides additional tools to help you monitor and optimize your analytics rules, including:

Analytics Insights (Individual rules)
Analytics Workbooks (all rules)
Manual Rule Reruns

These options are accessible from the Analytics Rule menu and are essential for tuning and operational visibility.

Key Insights to Monitor

Each rule includes health and performance insights, such as:

Failed Executions: View a list of rule runs that failed within the selected time range.
Top Health Issues: See the most frequent problems impacting the rule.
Alert Graph: Visualizes alert volume over time.
Incident Classification: Summarizes how incidents triggered by this rule have been classified after investigation.

Analytics Workbooks

Under the Analytics Workbooks menu, you’ll find prebuilt interactive dashboards to help assess rule performance and health. One of the most commonly used is the Analytics & Health Audit Workbook, which provides:

Visibility into whether rules are running as expected
An audit trail of rule changes
Insight into rule effectiveness and operational health

These workbooks are valuable tools for continuous improvement and compliance monitoring.

Manual Rule Reruns

Sentinel allows manual reruns of analytics rules. This is particularly useful in scenarios like:

Rule refinement and tuning: Validate updates before deployment.
Testing and validation: Ensure rules behave as expected in different environments or with recent data.
Incident investigation: Replay rules against historic data to check for missed detections.
Compliance and auditing: Demonstrate detection coverage retroactively.

Reruns are a practical way to test and iterate on detection logic without waiting for the next scheduled execution.

Analytic Rule limits

Be aware of Microsoft Sentinel’s current rule limits:

Scheduled Analytics Rules: Maximum of 512
Near Real-Time (NRT) Rules: Maximum of 50

These limits are important to consider when designing and scaling your detection strategy.

Base Events vs. Triggered (Correlated) Events

A foundational concept in working with SIEM systems is understanding the distinction between base events and triggered events, also known as correlated events.

Base events are the original logs ingested into the SIEM from various data sources (e.g., endpoint agents, firewalls, identity systems).
When a detection rule (such as an analytics rule) identifies suspicious behavior, it generates an alert. This alert is recorded as a new, correlated event, often enriched with metadata such as entity mappings, timestamps, rule names, and severity.

The diagram below highlights the SOC Triad, with core cybersecurity tools like Network Detection and Response (NDR) and Endpoint Detection and Response (EDR) forming its foundation. These tools generate critical telemetry data, which flows into a Security Information and Event Management (SIEM) system at the top of the triad. It’s important to note that in modern environments, additional sources beyond NDR and EDR, such as cloud and other specialized data, now contribute valuable logging data to enhance SOC visibility and response.

Logging systems, such as Sentinel, continuously scan ingested log data for conditions that may signal a security issue, which Sentinel refers to as "analytic rules." When an alert rule's criteria are met, an alert is generated in the logging system. This alert is logged as a distinct event from the original log or logs that triggered it. It's worth noting that some SIEM systems process data in memory, evaluating alert rule conditions at the point of ingestion rather than through post logging system ingest queries.

These correlated events do not always include the full raw base event data. As a result, during an investigation, analysts may need to pivot back to the original base events for deeper analysis or evidence gathering.

High-quality SIEM platforms provide seamless linking between correlated events and their base events, enabling investigators to:

Quickly trace back to the root cause.
Extract relevant context for incident response or automated workflows.
Avoid loss of detail in enrichment layers.

Where Correlated Events Are Stored in Sentinel

Depending on the detection mechanism, correlated data is stored in specific tables:

SecurityAlert & SecurityIncident: Alerts and incidents triggered by Scheduled, Near Real-Time (NRT), Threat Intelligence, and Fusion rules.
Anomalies Table: Captures behavioral anomalies detected by machine learning models. These are not immediately turned into alerts but may be used for hunting or correlated with other data.

Understanding this relationship helps analysts accurately trace alerts to their underlying causes and ensures automation scripts or manual investigations operate on the most relevant data.

Special Sentinel Rules

Fusion Rules in Microsoft Sentinel - Advanced Multistage Attack Detection

Microsoft Sentinel leverages Fusion, a correlation engine powered by scalable machine learning algorithms, to automatically detect multistage attacks. Fusion identifies patterns of anomalous behavior and suspicious activity that unfold across various stages of the kill chain. These detections often surface complex attack chains that would be difficult to detect using traditional methods.

Unlike UEBA anomalies or other ML-based detections, Microsoft classifies Fusion rules in their own category due to their cross-signal correlation and ML-driven nature.

To enable Fusion detections, it's essential that all relevant data connectors are properly configured. These connectors bring in the telemetry necessary to fuel the Fusion engine's advanced correlation models.

Recommendation: For optimal results, ensure all supported source signals, across all severity levels, are included. These are pre-selected by default, and leaving them enabled helps maximize detection coverage. You will also see the fusion rule in Sentinal named as 'Advanced Multistage Attack Detection'

Sentinel Summary Rules

Summary rules are specialized analytics rules designed to aggregate and summarize large datasets into a custom log table. This allows for:

Faster querying
Better long-range visibility
More efficient correlation of recurring patterns

These are ideal when you're dealing with high-volume data and need performance optimization.

Sentinel Rules Management

Sentinel Analytics and GitHub Resources

Microsoft Sentinel supports integration with a comprehensive GitHub repository that houses a wide range of prebuilt content, including:

Analytic rule templates
Hunting and exploration queries
Workbooks
Playbooks
Data connectors and parsers

While many of these templates are still available via GitHub, much of the content has been transitioned into Microsoft Sentinel Solutions, which are easily discoverable and deployable through the Sentinel Content Hub.

For a more user-friendly experience, the community has also developed a visually enhanced interface for exploring these GitHub rules: AnalyticsRules.Exchange

This front-end offers a more intuitive way to browse and understand analytic rule templates outside of the GitHub UI.

Microsoft Sentinel Watchlists

Watchlists in Microsoft Sentinel allow you to enrich detections and investigations by correlating your own data, such as high-value assets, terminated employees, service accounts, white list values, etc with events ingested into Sentinel. You can access watchlists via the Configuration blade in Sentinel. From the main Watchlists page, you can view existing watchlists or create a new one using the creation wizard.

Creating a Watchlist

Basics Tab
- Provide a name, description, and alias.
- The alias is used to reference the watchlist in KQL queries.

Source Tab
- Choose between Local File or Azure Storage as your data source.
- Upload a file (commonly a .csv) and specify if it includes headers.
- Be mindful: certain column names like IPAddress may conflict with reserved Sentinel schema terms. Renaming may be necessary.
- Define a SearchKey, which Sentinel uses to perform efficient lookups against the data.

Review + Create
- Confirm your settings and create the watchlist.

Built-In Watchlist Templates

Microsoft Sentinel also provides predefined templates for common use cases, including:

High-Value Assets
Terminated Employees
Identity Correlation
Network Addresses
Service Accounts

These templates help streamline watchlist creation and ensure consistent usage across environments.

Using Watchlists in KQL

Two of the most common tasks when working with Microsoft Sentinel watchlists are:

1. Viewing a Watchlist with _GetWatchlist

You can view the contents of a watchlist using the _GetWatchlist operator:

_GetWatchlist('HighValueMachines')

This displays the entries from the HighValueMachines watchlist, making it easy to review or correlate with other data.

2. Using a Watchlist in a Query with let

You can assign a watchlist to a variable using the let statement. This allows you to integrate watchlist values directly into your query logic.

let watchlistIPs = _GetWatchlist('ipwatchlist') | project SearchKey; <YourTable> | where IPAddress in (watchlistIPs)

This pattern is useful for filtering results based on watchlist values—such as identifying traffic to or from suspicious IPs, known service accounts, or critical assets.

Note: Ensure your watchlist has the correct column heading set as the SearchKey during creation, as this is the field used for matching.

Using Watchlists to Reduce False Positives in Analytic Rules

One effective method for reducing false positives in detection rules is leveraging watchlists to whitelist known benign values.

Take, for instance, an analytic rule designed to detect anomalies in UserAgent strings. Malicious activity often involves the use of unusual or inconsistent UserAgent strings, making this a valuable detection signal. However, with the increasing number of legitimate applications and frequent updates, these anomalies can also result in numerous false positives.

To mitigate this, you can create a watchlist (e.g., UserAgent_Benign) that includes known and approved UserAgent strings. In your KQL-based detection logic, you can reference this watchlist to exclude benign values from triggering alerts.

Step 1: Load Approved UserAgent Strings into a Variable

let ApprovedUserAgents = (_GetWatchList("UserAgent_Benign") | project SearchKey);

Step 2: Exclude Known Benign Values in Your Detection Logic

| where not(UserAgent in~ (ApprovedUserAgents))

This approach allows you to fine-tune your detections, minimize alert fatigue, and focus on truly anomalous or suspicious behavior. It also supports a more adaptive and maintainable detection strategy, as you can update the watchlist without modifying the detection rule itself.

Sentinel Automations & Playbooks

Microsoft Sentinel provides two key automation features to streamline incident response:

Automation Rules – Define conditions and actions to respond to incidents and alerts.
Playbooks – Logic App-based workflows that execute response actions, such as notifying analysts, blocking IPs, or gathering enrichment data.

Creating Sentinel Automation Rules

To get to the Sentinel automations setting select 'Automations' under the Sentinel configuration blade.

The main automations page in Sentinel. A key point that gets confusing is the difference between automations and playbooks. Automation rules are used to manage incident handling, while playbooks are sets of procedures that automate specific tasks in response to alerts or incidents. Automation rules can be used to trigger playbooks, but they can also perform actions like tagging, assigning, or closing incidents without needing a playbook. Playbooks, on the other hand, are more complex automations that can involve multiple steps and integrations with other services.

Automation rules have three core components:

Trigger
Condition
Action

Sentinel Automation Rule Construction

Automation rules in Microsoft Sentinel are configured under Configuration/Automation and are used to streamline responses to incidents and alerts.

Two key considerations when configuring an automation rule:

Which incidents should it apply to? - Clearly define the scope of incidents the rule is meant to impact, by category, severity, source, or other attributes.
What is the desired outcome? - Determine what action you want the rule to take, whether it’s enrichment, containment, escalation, or resolution.

Sentinel Automations Trigger Types

Automation rules support three primary triggers:

When an incident is created
When an incident is updated
When an alert is created

Each trigger type supports different conditions and actions. For example, if a trigger is based on an incident update, you can define conditions such as "only trigger if the severity field is changed."

Sentinel Automation Conditions by Trigger Type

Condition triggers enable detailed control over automation by allowing you to define precise criteria based on incident and entity details before executing automation actions.

Incident Created

Conditions can be based on:

Incident Properties:
- Analytic rule name
- Title, description
- Severity, status, owner
- Custom details
- Incident provider (Microsoft Sentinel, Microsoft 365 Defender, or both)

Tip: Use the Incident Provider condition to target alerts from specific sources.

Entity Properties:
- Username, domain
- Hostname, IP address
- File name/hash
- Email or URL indicators
- IoT device info

Example entity value condition like an IP address.

Incident Updated

Includes all incident creation properties, plus:

State Changes:
- Severity, status, tags, tactics
Activity History:
- Owner changes
- Who/what updated the incident (user, automation rule, playbook, M365 Defender, etc.)
- Alerts or comments added
Changed, Changed To, Changed From
Added
Updated By: user, app, playbook, etc.

Example conditions based on status Changed from Closed AND Updated by User

Alert Created

Only supports filtering by analytic rule name
More limited in condition flexibility than incident-based triggers

Sentinel Automation Actions

If the defined conditions are met, the following actions can be executed:

Run a playbook
Update incident status
Change incident severity
Assign incident to an owner
Add a tag to the incident
Create a task

Action execution also occurs in the sequence you specify, and you can change the action sequence.

To view which Incidents used automations the following KQL query can be used.

SecurityIncident
| where ModifiedBy contains "Automation"

Sentinel Playbooks

Sentinel playbooks are built off of logic apps which is a cloud-based service that helps automate workflows and integrate different applications, systems, and data sources across cloud and on-premises environments. It allows users to create automated workflows with a low-code/no-code approach, using pre-built connectors and a visual designer. Logic Apps can be used to automate tasks, integrate data, and orchestrate processes without needing extensive coding skills. Logic apps are configured separately within Azure and operate independently of Microsoft Sentinel.

The example below, adapted from Microsoft’s article 'Use a Microsoft Sentinel playbook to stop potentially compromised users', showcases a logic app that automates response actions, such as creating Teams channels, sending emails, and enforcing access blocks if users aren’t already restricted in Entra ID or the firewall.

There are two primary ways to run playbooks (Logic Apps) in Microsoft Sentinel:

Via analytics rules (legacy method) – This approach runs a playbook automatically when an alert is generated. However, this method is being deprecated in March 2026 in favor of a more flexible system.
Via Sentinel automation rules triggered by conditions – This is the recommended approach moving forward. Automation rules can evaluate incident or entity conditions and then execute actions such as running a playbook. The diagram below illustrates how to configure a playbook as an action within an automation rule.

Playbook Integration Best Practices

To run a playbook from an automation rule:

The playbook must begin with the trigger: When a Microsoft Sentinel incident is created or updated
Then attach it to an automation rule with the desired trigger.

NRT Rules Caveat- Near-Real-Time (NRT) analytics rules do not support attaching playbooks directly through incident configuration. Instead: Create an automation rule triggered by the incident Add a Run Playbook action Ensure the playbook uses the correct incident-based trigger

Alert Automation (Classic)- Reserved for legacy configurations that trigger playbooks at the alert level, not recommended for NRT scenarios involving incidents.

Manual Playbook Execution from Incident View

To allow playbooks to appear in the “Actions” pane of an incident:

Ensure the playbook uses the incident trigger
This enables manual execution during investigation

Alert-triggered playbooks are only usable at the alert level and won't appear under incident actions.

Initialization Note

A playbook labeled as "kind not initialized" means it exists but has no logic defined (no triggers or actions). It must be built out before it can be used.

Permissions for Automation & Playbooks

Proper permissions are critical for managing and running automations securely in Sentinel. Azure uses Role-Based Access Control (RBAC) to enforce these permissions at the subscription and resource group levels.

Core Sentinel Roles

Role	Capabilities
Sentinel Reader	View incidents, data, and resources
Sentinel Responder	Manage incidents (assign, change severity/state), but cannot edit rules
Sentinel Contributor	Full access to Sentinel resources (create/edit/delete rules, workbooks, etc.)

Tip: Assign Sentinel Responder to Tier 1 analysts to manage incidents without giving them configuration access.

Additional Roles for Automation Access

Role	Purpose
Logic App Contributor	Create and edit playbooks
Sentinel Playbook Operator	View, list, and manually run playbooks
Sentinel Automation Contributor	Grants Sentinel system access to run playbooks from automation rules

Important: Sentinel Automation Contributor must be explicitly assigned to the resource group where the playbook resides. Assign this role to the Azure Security Insights app identity, not to user accounts. Even if you assign Logic App Contributor or delegate the role on the playbook itself, Sentinel still won't run the playbook unless it has access to the resource group via this role.

Scenario-Based Access Control

Requirement: Allow Tier 1 analysts to run pre-configured playbooks but prevent them from editing them or other Sentinel settings.

Solution:

Assign analysts the Sentinel Responder role
Assign the Logic App Operator role for manual playbook execution
Keep configuration roles (Contributor) restricted to engineering or automation team