verview

The Microsoft Sentinel Triage Assistant (STAT) is a Custom Connector for Logic Apps, built to simplify and enhance incident-based automation within Microsoft Sentinel playbooks. By utilizing a collection of pre-built Automation Modules, STAT enables the execution of complex automation workflows in a consistent, user-friendly manner—directly through the Logic Apps Connector.

Purpose

STAT is designed to kickstart your automation journey in Microsoft Sentinel. It serves as both a practical tool and a learning resource, helping users explore what’s possible with Logic Apps automation and encouraging further expansion of their automation solutions. This functionality is freely available on GitHub

---

STAT Deployment Steps

Navigate to – https://github.com/briandelmsft/SentinelAutomationModules/tree/main/Deploy

Deploy the solution to your selected Azure subscription and datacenter region—this will serve as the environment where your Sentinel playbooks run. In most cases, a single deployment is sufficient; however, if you use multiple subscriptions or regions, you may need to deploy it separately in each one.

Click on the “Deploy to Azure”.

Continue the deployment by selecting the Standard Deployment Type and select “Deploy the sentinel STAT Solution” and Create.

Once the initial deployment is complete, you’ll need to update the Role-Based Access Control (RBAC) settings in Azure. To do this:

1. On the same page as the “Deploy” screen, find and download the GrantPermissions.ps1 file.
2. Open it in a text editor and make sure to uncomment the required modules—remove the comment tags from any lines that need to be activated before executing the PowerShell script.

Scroll down the GitHub page, click the “GrantPermissions.ps1” link, and download the file to your local machine

Open the file in a PowerShell editor (PowerShell ISE is used in the demo), then locate and update the two lines responsible for installing the modules: Microsoft.Graph.Applications and Az.Resources.

The script requires values for three variables: $TenantId, $AzureSubscriptionId, and $SentinelResourceGroupName.

Save the modified script locally—consider renaming it to PostDeployment-Permissions.ps1 to preserve the original file. In PowerShell ISE, click the Start button to run it. Alternatively, you can execute the script from a standard PowerShell command line.

The process starts by installing the necessary PowerShell modules. Once complete, the tool will initiate a connection and prompt you to authenticate.

Enter your Azure account credentials when prompted to proceed.

This authentication step ensures a secure, authorized link between the tool and Azure, allowing smooth access and interaction with Azure resources.

Complete the process by clicking the “Accept” button.

Configuration Part

Once the installation is complete, the system is primed with a basic setup. It’s now time to put the installed modules to work by integrating them into your automation workflow.

Automation is driven through the creation of “triage” playbooks in Logic Apps, which serve as the backbone for orchestrating actions. Meanwhile, the STAT connector operates behind the scenes, linking into Logic Apps to handle incoming requests.

To implement this successfully:

• Open the Logic Apps platform and begin building your triage playbooks
• Configure each playbook to align with your automation goals, incorporating the necessary modules
• Confirm that the STAT connector is properly connected to Logic Apps to ensure smooth request processing

By aligning the modules with your Logic Apps playbooks, you unlock efficient, automated workflows tailored to your environment’s needs

Triggering Part

To allow the STAT tool to process Sentinel incidents, you’ll need to set up Automation rules. These rules define when and how the STAT tool is triggered.

In the following example (provided for demonstration purposes only), the automation rule is configured to activate the STAT tool for every incident that occurs in Sentinel:

• Define the triggering conditions—in this case, the rule fires for each new incident
• Ensure the rule is correctly linked to the STAT tool to integrate it into the incident handling workflow

This configuration ensures that every generated incident triggers the STAT tool automatically.

To set it up, navigate to the Microsoft Sentinel blade, go to Configuration, and select Automation.

Click + Create and select Automation rule.

Configure the rule as follows:

• Name: Provide a descriptive name for the automation rule.
• Trigger: Select When incident is created (you can also choose When alert is created, if preferred).
• Conditions:
  • If Incident provider equals All
  • And Analytic rule name contains All
• Action: Set to Run playbook and select Sample-STAT-Triage
• Rule expiration: Set to Indefinite
• Order: Choose the desired execution order relative to other automation rules
• Status: Set to Enabled

Once all fields are configured, click Apply to save the rule.

Note: It’s recommended to temporarily disable this rule during configuration. Running the automation before the system is fully set up may cause issues with incident processing in Microsoft Sentinel.

Disabling the rule provides time to properly configure and test all necessary modules, connections, and conditions. This approach minimizes the risk of unintended behavior and ensures the automation functions smoothly once enabled.

As a best practice, always verify that the automation is correctly configured and operational before reactivating the rule.

In the Azure portal, navigate to the Logic Apps blade. To simplify the view, apply a filter to display only the STAT modules (optional, but helpful for clarity).

Select the Sample-STAT-Triage module to open its overview blade, where you can explore available actions and configurations.

Click on Logic App Designer to view the current workflow. While this may differ slightly from the initial setup, it will provide a clear understanding of the app’s structure and behavior.

To use this tool effectively, you’ll need to adjust any predefined parameters and configure additional modules as required. In the provided example, two modules are loaded.

The AAD Risks and Kusto Query Language (KQL) modules—along with others—offer detailed functionality, which you can explore further via the documentation on GitHub.

A key variable to note is AddIncidentComments. When set to true, it enables the module to capture output and automatically update the Comments section of the relevant incident being processed by the STAT tool.

To add a new module to the Sample-STAT-Triage Logic App, you’ll need to create a parallel processing branch. This allows multiple modules to run simultaneously within the workflow.

To do this:

• Click the “+” symbol below the Base module
• Choose “Insert a new step” and then select “Add a parallel branch”

In the “Choose an operation” field, type “Sentinel Triage” and select the corresponding operation.

Choose the module you want to include in your Logic App. For example, you might select “Defender for Cloud Apps”.

Click into BaseModuleBody to open the Dynamic content panel. Enter Base Module Body—this input is required for all newly added modules.

Specify a value for ScoreThreshold according to your requirements.

In the Add new parameter section, select AddIncidentComments, then click outside the module and set its value to True. This enables the module to post output to the Incident Comments field.

After adding the new module, it’s important to ensure its results are forwarded to the Risk Scoring Module. Currently, the parallel branch may not pass data forward correctly. To fix this:

• Review the current arrangement of modules within the parallel task
• Identify which modules need to be re-ordered for proper data flow
• Reorganize them to ensure results from this branch are passed on to the Risk Scoring Module

Rearranging modules ensures proper data handling across the Logic App’s parallel branches and enables accurate risk assessment.

Scroll down to the bottom of the Logic App and click New step.

This step creates a branching connection that links the modules together.

Drag the Condition object to the downward arrow, just above the Choose an operation box. Then, drag the Risk Scoring Module directly above that.

This arrangement ensures the new module forwards its results properly, just like the existing modules.

You can now close the Choose an operation box—this step was only needed to realign the flow.

At this point, the newly added module is integrated into the workflow and part of the logic flow.

Repeat this process for any additional modules you’d like to include.

Risk Module

After adding the desired modules to your automation workflow, the next step is to implement incident/alert scoring using the Risk Scoring Module.

This module consists of two components that work together to generate a risk value. Each component includes configurable variables within its Module body, such as:

• ScoreLabel: The name assigned to the score.
• ScoreMultiplier: A multiplier applied to each row, with the result scaled based on row count.
• ScorePerItem: Defines whether the score is calculated on a per-item basis (Yes or No).

The outputs from all integrated modules are aggregated in the Risk Scoring Module to produce a final total score, which is then passed to the next step in the workflow—typically a Condition module.

This total score is stored in the dynamic variable TotalScore, making it accessible for downstream decision-making in the automation logic.

Since the Microsoft Defender for Cloud Apps module has been added, you can now assign a custom scoring multiplier to it.

Click + Add new item to reveal an additional set of scoring fields.

• Scroll to the Microsoft Defender for Cloud Apps Module section and choose MDCA Module Body
• Enter a descriptive label for ScoreLabel
• Provide a numeric value for ScoreMultiplier (its purpose will become clearer in the upcoming modules)
• Set ScorePerItem to Yes

The Condition module acts as a decision gateway, determining how an incident should be processed. Based on the logic defined, it routes the incident to either the True or False path.

This module evaluates specified parameters or variables associated with the incident and applies the conditions you’ve configured. If the conditions are satisfied, it triggers the True branch; otherwise, it follows the False branch.

Leveraging the Condition module ensures your incident updates are dynamic, context-aware, and efficiently managed through automated logic.

Condition Module

Within the Condition module, the True or False outcome is determined by how much emphasis the user places on the TotalScore threshold.

In this example, all components are deliberately activated to simulate a fully operational flow. This is because the KQL query will always return at least one result—often itself—and additional modules in the workflow further increase the TotalScore. Setting the threshold to 1 doesn’t represent real-world usage; it’s configured this way purely for demonstration.

The goal of this scenario is to highlight how different modules influence the TotalScore and to showcase how updates propagate throughout the system. By ensuring all modules contribute and forcing updates, the example provides a more complete and instructive illustration of the scoring logic in action.

“True” Condition

When the Condition module evaluates as True, the workflow proceeds with the following actions:

• Assign an owner (optional)
• Set the Severity to High
• Change the Status to Active
• Add a Tag named STAT Triage – High Risk, with its value set to the TotalScore
• Optionally, add additional tags or parameters as needed

“False” Condition

When the Condition module evaluates as False, the following actions are performed:

• Optionally assign an owner
• Set Severity to Informational
• Add a Tag labeled STAT Triage – Low Risk
• Add a second Tag combining TotalScore with its actual value (e.g., TotalScore: 4)
• Change Status to Closed
• Set the Classification reason to Undetermined
• Set the Closed reason to Closed by STAT
• You may also add additional tags or parameters as needed

Processing

Once the automation workflow has been fully developed and tested, be sure to re-enable the automation rule if it was previously disabled during configuration.

To validate its effectiveness, simulate test attacks. While I use specific examples for internal testing, I’m unable to share those details due to company policy.

Review the results in the Incidents blade. When the automation rule is disabled, incidents generated from different hosts may show severities such as Low and Medium. However, with the rule enabled, those same incidents are elevated to High severity, and their Status changes to Active.

This comparison illustrates the automation’s impact—enhancing both incident severity and state—demonstrating how it streamlines response and boosts incident visibility.

To review the comments on an incident updated by the automation rule:

• Navigate to the incident in question
• Open the Comments section within the incident details

In this scenario, a KQL query was executed as part of the automation. Its results are automatically added to the incident’s Comments section, offering useful insights into what actions were taken.

Reviewing these comments provides greater clarity on the incident’s context and how the automation responded—especially through the lens of the KQL query’s findings.

In the Tags section, the following were added:

• RiskScore:10
• STAT Triage – High

Reviewing the Incident Activity Log reveals a detailed record of all changes made by the STAT tool.

For an example involving multiple modules contributing to the scoring process:

• Score: Represents the value assigned by each module during evaluation
• ScoreSource: Indicates the specific module responsible for generating that score within the STAT tool

Operational Cost

Customers often express concerns about potential costs when new features are introduced. In this case, the integration of Logic Apps provides both affordability and efficiency.

Consider a scenario with five distinct STAT-based playbooks. With 7,590 total base module runs, each playbook supports approximately 1,518 incidents. This entire activity incurred a cost of just $15 CAD (or $11 USD).

Logic Apps not only streamline workflows and automate processes—they do so with impressive cost-effectiveness, offering customers measurable productivity gains and a strong return on investment.