Introducing the Microsoft Sentinel Triage Assistant (STAT)

[Matt_Lowe]

*Note: This article was compiled and posted on behalf of Paul Bergson, Matt Lopinto, and Brian Delaney. I personally did not create or write this content.*

Non-Official Stance

As a Microsoft Cloud Solution Architect-Engineer, I am providing the following guidance to assist customers in deploying the STAT tool. These recommendations are based on my experiences and the challenges encountered within Azure environments.

Please note that the guidance I provide is not an official statement or directive from Microsoft. For official guidance on Azure, it is recommended to refer to the top-level Microsoft sites where official information is posted. The document also includes specific URLs that provide official details on certain topics.

It's important to emphasize that the guidance I offer is intended to support enterprise customers and provide insights based on my expertise and experience. For any official information or updates, it is always best to refer to the authoritative Microsoft sources.

Overview

The Microsoft Sentinel Triage Assistant (STAT) is a Logic Apps Custom Connector designed to streamline incident-based automation within Microsoft Sentinel playbooks. It leverages a library of Automation Modules, enabling the execution of complex automation tasks in a consistent and effortless manner directly from the Logic Apps Connector.

Purpose

The primary purpose of this tool is to facilitate the initiation of your automation journey and demonstrate the range of possibilities it offers. By engaging with automation and Logic Apps, users can gain familiarity with the concepts and leverage this example to expand their automation capabilities.

Availability

This tool is freely available on GitHub and has been developed by Brian Delaney.

Deployment

Open an internet browser and point it to:

• Launch your preferred internet browser.
• Navigate to the following URL:
  • GitHub - briandelmsft/SentinelAutomationModules: The Microsoft Sentinel Triage AssistanT (STAT) enab...
• Locate the "Deployment" section on the webpage.
• Proceed with deploying the solution to your chosen subscription and datacenter region, which will be the environment where your Sentinel Playbooks are employed. Note that typically a single deployment should suffice; however, if you have multiple subscriptions or datacenter regions, repeat the deployment process accordingly.
• To initiate the deployment, click on the "Deploy to Azure" button.

• Enter an account id, for the deployment.

• Provide a Subscription, Resource Group and Datacenter Region
  • Select Next

• There is the option for “Standard (recommended)” or “Advanced.”
  • With “Advanced” you have options for things such as customized naming to Logic Apps
    • For this demo, “Standard” will be selected.
      • For Gov, select “Advanced”
    • Select Next.

• Select “Deploy the Sentinel STAT Solution”.
  • Select Next.

• Check the “Deploy the Basic Sample Incident Triage” check box and leave the “Name” at its default.
  • Select Next.

• Review the page before moving on.
  • Select “Create”.

Following are a couple of screen grabs during the deployment phase:

 

Post Deployment

After completing the initial deployment phase, it is necessary to update the Role-Based Access Control (RBAC) settings within Azure. Follow the steps below to accomplish this task:

1. On the same page where the "Deploy" screen is located, locate and download the "GrantPermissions.ps1" file.
2. Open the downloaded file and ensure that a couple of modules, which are currently commented out, are uncommented. It is essential to remove the comment tags before running the PowerShell script.

It is worth noting that the reason behind the modules being commented out is unclear. However, it is imperative to uncomment them before proceeding with the execution of the PowerShell script.

• Scroll down the GitHub page and click on the hyperlink “GrantPermissions.ps1” and save locally.

• Open up the file in a PowerShell editor (ISE is used in the demo) and modify the two lines that Install the modules.

• Microsoft.Graph.Applications
• Az.Resources

• There are 3 variables that need to be populated within the script.
  • $TenantId
  • $AzureSubscriptionId
  • $SentinelResourceGroupName

• Save the updated file locally (I renamed it PostDeployment-Permissions.ps1 to keep the original file intact).
• Click on the start button within ISE.
  • This could be run from a PowerShell cmd line if you choose.

The installation process begins with the installation of the required PowerShell modules. Once the installation is complete, as the tool attempts to establish the connection, it will prompt you to authenticate your credentials.

Provide the required authentication details, such as your Azure account credentials, to proceed with the authentication process.

By authenticating your credentials, you ensure a secure and authorized connection between the tool and Azure, enabling seamless communication and access to Azure resources.

• It should then request permission to modify Permissions.

This concludes the RBAC update.

The optional “Restrict Calls to STAT Coordinator (optional)” was not run.

 

Installation Review

If you would like to see what Logic Apps were installed, just drill down to the Sentinel à Automation and select the “Active Playbooks” tab.

 

STAT Configuration

After the installation process, the system will have a basic setup in place. Now, it's time to leverage the installed modules and incorporate them into the automation workflow.

The automation is implemented through the creation of "triage" playbooks in Logic Apps. These playbooks serve as the foundation for automating the desired actions. The STAT connector, on the other hand, utilizes connectors to Logic Apps on the backend to process the incoming requests.

To effectively utilize the installed modules in the automation process, follow these steps:

1. Access the Logic Apps platform to build the "triage" playbooks.
2. Configure the playbooks according to the desired automation requirements, incorporating the installed modules as necessary.
3. Ensure that the STAT connector is appropriately connected to the Logic Apps on the backend to enable seamless processing of requests.

By leveraging the modules and integrating them into the Logic Apps playbooks, you can harness the power of automation and streamline various tasks and processes within your environment.

 

Triggering the STAT tool

To enable the STAT tool to process Sentinel Incidents, it is necessary to define Automation rules. These rules govern the behavior of the STAT tool and determine the conditions under which it will be triggered. In the example provided, the automation rule is configured to trigger the STAT tool for every generated Incident.

Here's how the automation rule in this example is set up:

1. Define the criteria or conditions that will trigger the automation rule. In this case, the condition is set to activate the STAT tool for every Incident that is generated within the Sentinel environment.
2. Configure the automation rule to ensure that it is properly associated with the STAT tool. This linkage enables the automation process to be seamlessly integrated into the Incident handling workflow.

By configuring the automation rule in this example, the STAT tool will be triggered automatically for every Incident that occurs. I am not recommending this configuration, only showing it for demonstration purposes.

• Browse to the Microsoft Sentinel blade and under “Configuration”, click on the “Automation” option.

• Click “+ Create”.
  • Select “Automation rule”.

• Automation rule name – Self explanatory.
• When should this rule be triggered.
  • “When incident is created” (‘When alert is created” is also available.
• Conditions.
  • If / Incident provider Equals “All”.
    • AND
  • If / Analytic rule name Contains “All”.
• Action
  • Run playbook.
    • “Sample-STAT-Triage”.
  • Rule expiration.
    • Indefinite
  • Order
    • User order of choosing with any other automation rules.
  • Status
    • “Enabled”
  • Click on “Apply”.

Note: To ensure proper configuration of the automation, it is recommended to temporarily disable this rule. Failure to do so may result in the automation running without the system being completely configured correctly, leading to potential issues during the processing of new incidents within your Microsoft Sentinel environment.

By disabling the rule until the automation is fully configured and tested, you can prevent any unintended consequences. This allows you to take the necessary time to ensure that the automation is set up correctly, including all necessary modules, connections, and conditions, before enabling the rule.

Disabling the rule during the configuration phase helps ensure that the automation operates smoothly once it is enabled, minimizing the risk of any errors or unexpected behavior. It is best practice to verify that the automation is configured correctly and functioning as intended before activating the rule.

 

Logic App Editing

Scoring Modules

At this writing there were 13 available modules. Details describing what each does can be found within the GitHub site.

• Base
• Azure Active Directory Risks
• File Insights
• Kusto Query Language (KQL)
• Microsoft Defender for Cloud Apps (MCAS)
• Microsoft Defender for Endpoint
• Office 365 Out of Office
• Microsoft Sentinel Related Alerts
• Microsoft Sentinel Threat Intelligence
• Microsoft Sentinel User Entity Behavior Analytics
• Microsoft Sentinel Watchlists
• Risk Scoring
• Run Playbook

• From the Azure portal, open the Logic apps blade and filter to only display the STAT modules (not necessary but much easier to understand).

• Click on the module “Sample-STAT-Triage”.
  • This should bring up the “Sample-STAT-Triage” blade and the different options that can be performed and interrogated.

• Click on “Logic app designer”.
  • This may differ slightly from the initial install, but it should give you an understanding of what to expect.

The use of this tool will require the user to modify any of the parameters that are currently set and/or additional modules and configure those parameters. Looking at my example there are two modules loaded.

The AAD Risks and Kusto Query Language (KQL) Modules, along with other modules, provide detailed information about their functions on the GitHub site. (#2) You can refer to the GitHub documentation for more information on these modules.

In particular, the variable "AddIncidentComments" plays a crucial role. When set to true, it enables the module to retrieve output and update the "Comments" section of the incident being processed by the STAT tool.

To incorporate a new module into the Logic app "Sample-STAT-Triage," you will need to add a "Parallel processing module." This addition will enable parallel execution of multiple modules within the Logic app.

• Select the “+” below the “Base” module, to “Insert a new step” and select “Add a parallel branch”.

• Enter “Sentinel Triage” in the “Choose an operation” entry box and select “Sentinel Triage…”.

• Select the module you would like to include in the Logic app. In my example, I chose the “Defender for Cloud Apps” module.

• Click inside the “BaseModuleBody”, this will bring up the “Dynamic content” entry box.
  • Enter “Base Module Body”, this is required in all newly added modules.

• Enter the level for the “ScoreThreshold” you would like.
• Click in the “Add new parameter” box.
  • Select “AddIncidentComments”.
    • Click away from the module.

• Select “True”.
  • This will ensure any values from this module are posted in the “Incident” comments field.

Once the new module has been added, it is necessary to forward the obtained results to the "Risk Scoring Module." However, it is important to note that the parallel task is currently not forwarding the results. To address this, a re-arrangement of a couple of modules is required.

To ensure proper forwarding of results in the parallel task, follow these steps:

1. Review the existing module arrangement within the parallel task.
2. Identify the modules that need to be re-arranged to enable forwarding of results to the "Risk Scoring Module."
3. Make the necessary adjustments by moving the modules in the desired order.

By re-arranging the modules within the parallel task, you will establish the proper forwarding of results to the "Risk Scoring Module."

• Zoom out to the bottom of the Logic App and select “New step”.

Note how this “New step”, creates a branch connection between the different modules.

• Drag the “Condition” object to the down arrow, just above the “Choose an operation” box, follow this by dragging the “Risk Scoring Module” right above this.

This will now allow the results from the new module to be forwarded on like the previous modules.

• Close the “Choose an operation” box, this step was only created to realign the modules.

The final product can be seen below with the new module now being able to be a part of the logic flow.

Go back following the same process and add any additional modules you might want.

 

Risk Scoring Module

Once you have added any desired modules to the automation workflow, the next step is to facilitate the scoring of the Incident/Alert. This scoring functionality is handled by the "Risk Scoring Module."

The "Risk Scoring Module" incorporates two modules that work together to calculate a risk value. Each module has its own set of variables defined in the "Module body," which include:

1. ScoreLabel:
   1. Name of the Score.
2. ScoreMultiplier:
   1. Specifies the multiplier to be applied for each row passed along.
   2. This number is multiplied against the row count.
3. ScorePeritem:
   1. Indicates whether the score is calculated on a per-item basis (Yes or No).

The values generated by the included modules are summed up within this module to obtain a final total. This total value is then passed along to the subsequent "Condition" module. The dynamic variable "TotalScore" holds this calculated final value.

Since the module “Microsoft Defender for Cloud Apps” was added, we can add a new scoring multiplier to the module.

• Click on “+ Add new item” and another set of values called out from the bulleted list above should appear.
• Scroll down to the “Microsoft Defender for Cloud Apps Module” and select “MDCA Module Body”.

• Enter a descriptive name for the “ScoreLabel”.
• Enter a numeric multiplier value for “ScoreMultiplier”.
  • This will make more sense with an explanation in the next couple of modules.
• Select “Yes” in “ScorePeritem”.

The "Condition" module serves as the decision-making point for determining how a new incident will be updated. This module directs the updating process to either a "True" process or a "False" process, based on specific criteria or conditions.

The purpose of the "Condition" module is to evaluate certain parameters or variables associated with the incident and make a determination on which process to trigger. If the conditions are met, the module will direct the flow to the "True" process. If the conditions are not met, it will direct the flow to the "False" process.

By utilizing the "Condition" module, you can dynamically control the updating process of new incidents based on predefined conditions, allowing for automated and efficient incident management.

Condition Module

Looking at the “Condition” module itself, the true or false value is generated by the weight that the user puts on the “TotalScore” importance.

In this example, all elements are intentionally updated to ensure comprehensive processing. This approach is adopted because the KQL query itself will always identify at least one incident (itself) during the process. Additionally, other modules incorporated in the workflow can contribute to incrementing the value of the TotalScore. Keeping the value at 1 does not accurately reflect the intended functionality; it was set to this value purely for demonstration purposes.

The objective of this example is to showcase the potential updates and demonstrate the impact of various modules on the TotalScore. By forcing updates on all components and allowing modules to contribute to the TotalScore, a more meaningful and illustrative example is generated.

Condition “True”

When the “Condition” module (True) is the receiver in the process, the following occurs:

• The option is available to set an owner.
• The “Severity” is changed to “High”.
• The “Status” is changed to “Active”.
• A tag named “STAT Triage – High Risk” is created.
  • Value set to “TotalScore”.
• The option to add a new item (Tag) or parameter is also available.

Condition “False”

When the “Condition” module (False) is the receiver in the process, the following occurs:

• The option is available to set an owner.
• The “Severity” is changed to “Informational”.
• A tag named “STAT Triage – Low Risk” is created.
• A tag named “TotalScore” + the value of “TotalScore” is created.
• The “Status” is changed to “Closed”.
  • Classification reason is changed to “Undetermined”.
  • Closed reason is set to “Closed by STAT”.
• The option to add a new item (Tag) or parameter is also available.

 

STAT Processing

Once you have completed the development of this automation process and are satisfied with its functionality, it is recommended to re-enable the automation rule if it was previously disabled during the testing phase.

To test the effectiveness of the automation, you can simulate a few fake attack signals. Although I have a couple of examples that I use for testing purposes, I am unable to provide the details or demonstrate the process due to company policy restrictions.

By examining the "Incidents" blade within the platform, you can observe the results of running the same attacks with both the automation rule enabled and disabled. From the included screengrab, you can clearly see that when no automation is implemented, the two "Incidents" (generated from different hosts) have a severity level of "Low" and "Medium." However, when the automation is enabled and executed, the severity level of these incidents is elevated to "High." Additionally, the "Status" field indicates that the incidents are now marked as "Active" with the automation-updated incidents.

By comparing the results, it becomes evident how the automation process enhances the severity and status of incidents, highlighting the efficiency and impact of the implemented automation.

To review the comments of an "Incident" that has been updated by the automation rule, follow these steps:

1. Navigate to the specific "Incident" that underwent automation updates.
2. Locate the "Comments" section within the incident details.

In this example, a KQL query was executed as part of the automation process. The results generated by the KQL query are populated in the "Comment" section of the incident. These comments provide valuable information and insights regarding the incident, allowing for a better understanding of the actions performed by the automation rule.

By examining the comments associated with the updated incident, you can gain further visibility into the specific details and outcomes of the automation processes, specifically the results obtained from the execution of the KQL query.

• Looking at the Tags.
  • “RiskScore:10” was added.
  • “STAT Triage – High” was added.

• Looking in the “Incident activity log”, there is a complete set of details of what was changed by the STAT tool.

To look at an example where multiple modules scored an alert.

• Score – This is the value assigned to each ScoreSource (Module)
• ScoreSource – This is an entry for each module that is processed within the STAT tool

 

Cost Impact

Customers are naturally concerned about the cost implications when new features are introduced to a service or product. With the integration of Logic Apps in this solution, let's explore a scenario where five distinct STAT-based playbooks are utilized. If we divide the total base module runs of 7,590 runs by 5 playbooks, equaling 1518 incidents impacted. This activity was at a cost of just $15 (CAN) or $11 (US). The efficiency and affordability offered by Logic Apps reassure customers about cost while optimizing workflows and processes, resulting in increased productivity and a remarkable return on investment.

References

1. GitHub - briandelmsft/SentinelAutomationModules: The Microsoft Sentinel Triage AssistanT (STAT) enab...
2. SentinelAutomationModules/readme.md at main  briandelmsft/SentinelAutomationModules · GitHub
3. SentinelAutomationModules/Modules at main · briandelmsft/SentinelAutomationModules (github.com)
4. Let’s automate your SOC – Introduction to automating your Microsoft Sentinel
5. Automate your SOC – Let’s talk about STAT, baby – Introduction and installation of Microsoft STAT Triage
6. Automate your SOC – Noise is the enemy of speed – How to optimize your incidents
7. Automate your SOC – Risky Business – Giving your incidents a risk score
8. Automate your SOC – Oh, that user again? Enrich your incident with by checking user’s Sign In Risk
9. Automate your SOC – Rise of the machine (risk) – Tell me about the risk of the user’s device
10. Let’s automate your SOC - Azure Cloud & AI Domain Blog (azurecloudai.blog)