Listen to this Post
Introduction:
As Security Orchestration, Automation, and Response (SOAR) evolves within the Microsoft ecosystem, recent updates to the Microsoft Sentinel and Unified Defender XDR portals have introduced significant changes to how automation rules are constructed. With the deprecation of the “Incident provider” condition and the shift towards using “Analytic rule name” and “Alert product names,” Security Operations Center (SOC) engineers must adapt their playbooks to maintain accuracy and prevent automation misfires. Understanding these modifications is crucial for ensuring that incident response workflows remain robust, predictable, and efficient in a modern SecOps environment.
Learning Objectives:
- Understand the rationale behind the deprecation of the Incident provider condition and the adoption of new filtering mechanisms.
- Learn how to implement automation rules using “Analytic rule name” and “Alert product names” for precise incident orchestration.
- Gain practical knowledge on updating existing SOAR playbooks to align with the new Microsoft Sentinel and Unified Portal standards.
You Should Know:
- Adapting Automation Logic: From Incident Titles to Analytic Rule Names
The original post by Uros Babic highlights a critical shift: relying on the incident title for automation logic is no longer a best practice. Incident titles can be manually modified or customized by different data sources, leading to inconsistent triggering of automation rules. Microsoft now recommends using the “Analytic rule name” as a condition. This field is inherently more stable because it is tied directly to the scheduled or NRT (Near Real-Time) query that generated the alert.
Step‑by‑step guide explaining what this does and how to use it:
1. Navigate to the Microsoft Sentinel workspace within the Azure Portal or the Unified Defender XDR portal.
2. Go to the “Automation” blade (or “Configuration” -> “Automation” in the new unified interface).
3. Click “Create” and select “Automation rule.”
- In the “Conditions” section, add a new condition. You will now look for the option “Analytic rule name” under the “Alert” category.
- Set the operator to “Equals” or “Contains” and select the specific analytic rule from the dropdown (e.g., “Mimikatz Detection,” “Anomalous Logon”).
- This ensures that the subsequent actions (e.g., triggering a playbook, tagging incidents) will only fire for incidents generated by that precise analytic rule, bypassing any inconsistencies in the incident title that might be introduced by manual edits or data ingestion variations.
2. Refining Triggers: Filtering by “Alert Product Names”
The removal of the “Incident provider” condition from the UI necessitates a more granular approach. Previously, you might have filtered automation based on the provider (e.g., “Microsoft Defender for Endpoint”). The new standard is to filter by “Alert product names.” This allows for finer control, especially in a hybrid environment where multiple security products (both Microsoft and third-party) are feeding alerts into Sentinel.
Step‑by‑step guide explaining what this does and how to use it:
1. Within the same automation rule creation or editing pane, add another condition.
2. Look for the field “Alert product names.” This is an array that contains the names of the products that generated the specific alerts within the incident.
3. Define the condition. For example, you can set “Alert product names” “Contains” “Microsoft Defender for Cloud Apps” or “Azure Active Directory Identity Protection.”
4. By using this filter, you ensure that your automation runs only on incidents that contain alerts from specific security tools. This is far more precise than the old provider-based filter, as it can handle incidents that may have alerts from multiple providers, allowing you to build logic that executes only when a particular product’s alert is present.
5. Combine this with the “Operator” logic (e.g., “And” / “Or”) to create complex conditions, such as: Trigger playbook X only if the incident was generated by “Analytic rule A” AND it contains alerts from “Alert product name B.”
3. Practical Example: Building a Phishing Response Playbook
To illustrate these changes, let’s construct a rule for a phishing incident.
– Scenario: You have an analytic rule named “Microsoft Defender for Office 365 – Phish Detected” that creates an incident when a phishing email is reported or detected.
– Old Method: The rule might have checked if the Incident contained “Phish” or if the Provider was “M365 Defender.”
– New Method:
– Condition 1: “Analytic rule name” “Equals” “Microsoft Defender for Office 365 – Phish Detected.”
– Condition 2: “Alert product names” “Contains” “Microsoft Defender for Office 365.”
– Action: Run a playbook that isolates the user’s mailbox, resets their password, and posts a message to a Teams channel dedicated to phishing.
This approach ensures the automation only runs for the specific rule and product you intend, preventing it from accidentally triggering on a different type of phishing alert from a third-party email gateway.
4. Verifying Your Existing Automation Rules
It is essential to audit your current rules to ensure they are not relying on deprecated fields. While Microsoft may have removed the “Incident provider” from the UI, rules that were created using it might still function, but they cannot be modified with that condition. Best practice dictates you rebuild them.
Step‑by‑step guide:
- In the Microsoft Sentinel Automation blade, list all your current automation rules.
- Export the rules for review. This can be done via Azure Resource Graph Explorer or by scripting with PowerShell.
– PowerShell (Az module) Example:
Connect to Azure Connect-AzAccount Define variables $subscriptionId = "Your-Subscription-ID" $resourceGroupName = "Your-Resource-Group" $workspaceName = "Your-Sentinel-Workspace" Get all automation rules Get-AzSentinelAutomationRule -ResourceGroupName $resourceGroupName -WorkspaceName $workspaceName | Export-Csv -Path "AutomationRulesBackup.csv" -NoTypeInformation
3. Open the CSV and filter for any rules that might have used the old logic. Look for descriptions or note the creation date if you know when the update occurred.
4. For critical rules, create new versions using the “Analytic rule name” and “Alert product names” logic.
5. Once the new rules are tested and verified, disable the old ones to prevent duplicate actions or conflicts.
5. Integrating with Logic Apps for Complex Orchestration
While automation rules handle the trigger logic, the heavy lifting is often done by playbooks (Azure Logic Apps). The changes in the automation layer directly impact how you pass data to these playbooks.
Configuration Insight:
When you configure an action in your new automation rule (e.g., “Run playbook”), the incident and alert data passed to the Logic App now includes the structured “Analytic Rule Name” and “Alert Product Names.” This allows your playbook to have conditional branches internally.
– Within the Logic App designer: After the trigger “When a Microsoft Sentinel incident is created,” add a “Condition” action.
– Use the dynamic content: Select “Incident” -> “Alert Products” or “Analytic Rule Name” from the list of incident properties.
– Configure the Logic App: For instance, if `Alert Products` contains “Microsoft Cloud App Security,” run a specific set of actions to investigate unusual data exfiltration. If it contains “Azure AD Identity Protection,” run a different set to handle compromised user remediation.
What Undercode Say:
- Precision over Pattern Matching: Relying on static, backend properties like “Analytic rule name” rather than mutable front-end fields like the incident title is a fundamental shift towards more reliable security automation. It reduces false positives caused by human error or data source inconsistencies.
- Granularity is Key for Complex Environments: The move to “Alert product names” reflects the reality of modern SOCs, where a single incident can be a fusion of alerts from multiple sources. This filter allows for “if-this-product-is-present-then-do-this” logic, enabling more nuanced incident response without creating an explosion of simple, brittle rules.
- Automation Hygiene is Now Mandatory: These updates force a necessary cleanup. Auditing and refactoring existing automation rules is not just about compliance with a UI change; it is an opportunity to optimize performance, reduce unnecessary playbook executions, and ensure that your SOAR infrastructure is lean and effective against evolving threats.
Prediction:
This move by Microsoft signals a broader industry trend towards “source-aware” automation. In the future, we can expect automation engines to leverage even deeper data lineage, potentially using MITRE ATT&CK technique IDs or specific threat actor profiles as native filters. As SIEM and XDR platforms become more integrated, the ability to filter automation based on the precise analytic that fired—and the exact product that detected the anomaly—will become the baseline for enterprise-grade SOAR. Organizations that fail to adapt will find their incident response pipelines flooded with noise, while those embracing these changes will achieve a new level of operational efficiency and defensive accuracy.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Uros Babic – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
