Update: Changing the Account Name Entity Mapping in Microsoft Sentinel
The upcoming update introduces more consistent and predictable entity data across analytics, incidents, and automation by standardizing how the Account Name property is populated when using UPN‑based mappings in analytic rules. Going forward, Account Name property will consistently contain only the UPN prefix, with new dedicated fields added for the full UPN and UPN suffix. While this improves consistency and enables more granular automation, customers who rely on specific Account Name values in automation rules or Logic App playbooks may need to take action. Timeline Effective date: July 1, 2026. The change will apply automatically - no opt-in is required. Scope of impact Analytics Rules which include mapping of User Principal Name (UPN) to the Account Name entity field, where the resulting alerts are processed by Automation Rules or Logic App Playbooks that reference the AccountName property. What’s changing Currently When an Analytic Rule includes mapping of a full UPN (for example: 'user@domain.com') to the Account Name field, the resulting input value for the Automation Rule or/and Logic App Playbook is inconsistent. In some cases, it contains only the UPN prefix: 'user', and in other cases the full UPN ('user@domain.com'). After July 1, 2026 Account Name property will consistently contain only the UPN prefix The following new fields will be added to the entity object: AccountName (UPN prefix) UPNSuffix UserPrincipalName (full UPN) This change provides an enhanced filtering and automation logic based on these new fields. Example Before Analytics Rule maps: 'user@domain.com' Automation Rule receives: Account Name: 'user' or 'user@domain.com' (inconsistent) After Analytics Rule maps: 'user@domain.com' Automation Rule receives: Account Name: 'user' UPNSuffix: 'domain.com' Logic App Playbook and SecurityAlert table receives: AccountName: 'user' UPNSuffix: 'domain.com' UserPrincipalName: 'user@domain.com' Feature / Location Before After SecurityAlert table Logic App Playbook Entity Why does it matter? If your automation logic relies on exact string comparisons against the full UPN stored in Account Name, those conditions may no longer match after the update. This most commonly affects: Automation Rules using "Equals" condition on Account Name Logic App Playbooks comparing entity field 'accountName' to a full UPN value Call to action Avoid strict equality checks against Account Name Use flexible operators such as: Contains Starts with Leverage the new UPNSuffix field for clearer intent Example update Before - Account name will show as 'user' or 'user@domain.com' After - Account Name will show as 'user' Recommended changes: Account Name Contains/Startswith 'user' UPNSuffix Equals/Startswith/Contains 'domain.com' This approach ensures compatibility both before and after the change takes effect. Where to update Review any filters, conditions, or branching logic that depend on Account Name values. Automation Rules: Use the 'Account name' field Logic App Playbooks: Update conditions referencing the entity: 'accountName' For example: Automation Rule before the change: Automation Rule after the change: Summary A consistency improvement to Account Name mapping is coming on July 1, 2026 The change affects Automation Rules and Logic App Playbooks that rely on UPN to Account Name mappings New UPN related fields provide better structure and control Customers should follow the recommendations above before the effective change dateAutomating Microsoft Sentinel: Part 2: Automate the mundane away
Welcome to the second entry of our blog series on automating Microsoft Sentinel. In this series, we’re showing you how to automate various aspects of Microsoft Sentinel, from simple automation of Sentinel Alerts and Incidents to more complicated response scenarios with multiple moving parts. So far, we’ve covered Part 1: Introduction to Automating Microsoft Sentinel where we talked about why you would want to automate as well as an overview of the different types of automation you can do in Sentinel. Here is a preview of what you can expect in the upcoming posts [we’ll be updating this post with links to new posts as they happen]: Part 1: Introduction to Automating Microsoft Sentinel Part 2: Automation Rules [You are here] – Automate the mundane away Part 3: Playbooks 1 – Playbooks Part I – Fundamentals Part 4: Playbooks 2 – Playbooks Part II – Diving Deeper Part 5: Azure Functions / Custom Code Part 6: Capstone Project (Art of the Possible) – Putting it all together Part 2: Automation Rules – Automate the mundane away Automation rules can be used to automate Sentinel itself. For example, let’s say there is a group of machines that have been classified as business critical and if there is an alert related to those machines, then the incident needs to be assigned to a Tier 3 response team and the severity of the alert needs to be raised to at least “high”. Using an automation rule, you can take one analytic rule, apply it to the entire enterprise, but then have an automation rule that only applies to those business-critical systems to make those changes. That way only the items that need that immediate escalation receive it, quickly and efficiently. Automation Rules In Depth So, now that we know what Automation Rules are, let’s dive in to them a bit deeper to better understand how to configure them and how they work. Creating Automation Rules There are three main places where we can create an Automation Rule: 1) Navigating to Automation under the left menu 2) In an existing Incident via the “Actions” button 3) When writing an Analytic Rule, under the “Automated response” tab The process for each is generally the same, except for the Incident route and we’ll break that down more in a bit. When we create an Automation Rule, we need to give the rule a name. It should be descriptive and indicative of what the rule is going to do and what conditions it applies to. For example, a rule that automatically resolves an incident based on a known false positive condition on a server named SRV02021 could be titled “Automatically Close Incident When Affected Machine is SRV02021” but really it’s up to you to decide what you want to name your rules. Trigger The next thing we need to define for our Automation Rule is the Trigger. Triggers are what cause the automation rule to begin running. They can fire when an incident is created or updated, or when an alert is created. Of the two options (incident based or alert based), it’s preferred to use incident triggers as they’re potentially the aggregation of multiple alerts and the odds are that you’re going to want to take the same automation steps for all of the alerts since they’re all related. It’s better to reserve alert-based triggers for scenarios where an analytic rule is firing an alert, but is set to not create an incident. Conditions Conditions are, well, the conditions to which this rule applies. There are two conditions that are always present: The Incident provider and the Analytic rule name. You can choose multiple criterion and steps. For example, you could have it apply to all incident providers and all rules (as shown in the picture above) or only a specific provider and all rules, or not apply to a particular provider, etc. etc. You can also add additional Conditions that will either include or exclude the rule from running. When you create a new condition, you can build it out by multiple properties ranging from information about the Incident all the way to information about the Entities that are tagged in the incident Remember our earlier Automation Rule title where we said this was a false positive about a server name SRV02021? This is where we make the rule match that title by setting the Condition to only fire this automation if the Entity has a host name of “SRV2021” By combining AND and OR group clauses with the built in conditional filters, you can make the rule as specific as you need it to be. You might be thinking to yourself that it seems like while there is a lot of power in creating these conditions, it might be a bit onerous to create them for each condition. Recall earlier where I said the process for the three ways of creating Automation Rules was generally the same except using the Incident Action route? Well, that route will pre-fill variables for that selected instance. For example, for the image below, the rule automatically took the rule name, the rules it applies to as well as the entities that were mapped in the incident. You can add, remove, or modify any of the variables that the process auto-maps. NOTE: In the new Unified Security Operations Platform (Defender XDR + Sentinel) that has some new best practice guidance: If you've created an automation using "Title" use "Analytic rule name" instead. The Title value could change with Defender's Correlation engine. The option for "incident provider" has been removed and replaced by "Alert product names" to filter based on the alert provider. Actions Now that we’ve tuned our Automation Rule to only fire for the situations we want, we can now set up what actions we want the rule to execute. Clicking the “Actions” drop down list will show you the options you can choose When you select an option, the user interface will change to map to your selected option. For example, if I choose to change the status of the Incident, the UX will update to show me a drop down menu with options about which status I would like to set. If I choose other options (Run playbook, change severity, assign owner, add tags, add task) the UX will change to reflect my option. You can assign multiple actions within one Automation Rule by clicking the “Add action” button and selecting the next action you want the system to take. For example, you might want to assign an Incident to a particular user or group, change its severity to “High” and then set the status to Active. Notably, when you create an Automation rule from an Incident, Sentinel automatically sets a default action to Change Status. It sets the automation up to set the Status to “Closed” and a “Benign Positive – Suspicious by expected”. This default action can be deleted and you can then set up your own action. In a future episode of this blog we’re going to be talking about Playbooks in detail, but for now just know that this is the place where you can assign a Playbook to your Automation Rules. There is one other option in the Actions menu that I wanted to specifically talk about in this blog post though: Incident Tasks Incident Tasks Like most cybersecurity teams, you probably have a run book of the different tasks or steps that your analysts and responders should take for different situations. By using Incident Tasks, you can now embed those runbook steps directly in the Incident. Incident tasks can be as lightweight or as detailed as you need them to be and can include rich formatting, links to external content, images, etc. When an incident with Tasks is generated, the SOC team will see these tasks attached as part of the Incident and can then take the defined actions and check off that they’ve been completed. Rule Lifetime and Order There is one last section of Automation rules that we need to define before we can start automating the mundane away: when should the rule expire and in what order should the rule run compared to other rules. When you create a rule in the standalone automation UX, the default is for the rule to expire at an indefinite date and time in the future, e.g. forever. You can change the expiration date and time to any date and time in the future. If you are creating the automation rule from an Incident, Sentinel will automatically assume that this rule should have an expiration date and time and sets it automatically to 24 hours in the future. Just as with the default action when created from an incident, you can change the date and time of expiration to any datetime in the future, or set it to “Indefinite” by deleting the date. Conclusion In this blog post, we talked about Automation Rules in Sentinel and how you can use them to automate mundane tasks in Sentinel as well as leverage them to help your SOC analysts be more effective and consistent in their day-to-day with capabilities like Incident Tasks. Stay tuned for more updates and tips on automating Microsoft Sentinel!Automating Microsoft Sentinel: A blog series on enabling Smart Security
This entry guides readers through building custom Playbooks in Microsoft Sentinel, highlighting best practices for trigger selection, managed identities, and integrating built-in tools and external APIs. It offers practical steps and insights to help security teams automate incident response and streamline operations within Sentinel.Microsoft Sentinel and Defender: ITSM Integrations Explained
One of the main changes and advantages of onboarding Microsoft Sentinel to the Defender portal is the fact that alerts are automatically correlated into single incidents. Alert correlation will kick in when we have enough evidence that multiple alerts are related. This has great benefits, as it can quickly unveil multi-stage attacks that otherwise could look like unrelated harmless alerts. It also helps reduce the amount of incidents by merging those that are related. However, each organization has its own internal processes, teams, etc., so transitioning to this new way of working can be challenging. Furthermore, for organizations that use external ITSM tools to manage their incidents and alerts this means the logic in the incident synchronization must be considered before onboarding Microsoft Sentinel on Defender. This is critical as you will need to make sure that updates on incidents due to correlation are properly reflected on your tool. In this article, we will review the most relevant fields in the Azure management API and in the Microsoft security graph API. If you are building a new integration, we recommend transitioning to the Microsoft Graph security API. However, if you have an existing integration relying on the Microsoft Sentinel REST APIs, you can simply update what you have. If you are using ServiceNow as your ITSM tool, we recommend using this out-of-the-box app provided by ServiceNow. It relies on the Azure Management API: Microsoft Sentinel - ServiceNow Store. The latest version includes improvements that take care of the correlation logic. If you are using a different ITSM tool with an out-of-the-box integration, we recommend checking whether the latest version available already covers this change in the logic. Otherwise, if you wish to update or create your own integration logic, we are providing some guidance below. How does the correlation logic affect incidents Understanding how the correlation logic affects incidents and when it kicks in is the first step. We recommend reading our official documentation, which explains different scenarios for Incident correlation and merging. However, below we will describe in more detail how correlation affects incidents, bearing in mind how this can influence synchronization with external ITSM systems. Since correlation will automatically move alerts and close incidents, you need to understand how this works and check if your synchronization logic need modifications. When two or more alerts are identified as related, they are aggregated into a single incident. This can happen in two ways: Existing incidents: Alerts from different incidents may be moved into a new or existing “target” incident. The original (“source”) incidents will lose those alerts and will be automatically closed. On Defender, any references to the ”source” incident will be redirected to the “target” incident. On Microsoft Sentinel on Azure, you will still see the old incident, although it will be closed, it will contain the tag “redirected” and it will contain a link to the “target” incident. New alerts: Alerts that are not yet part of any incident may be directly added to the “target” incident. Please keep in mind that Sentinel alerts that are triggered without an incident (which is possible through the Sentinel analytic rules settings) will not be considered for correlation. In other words, when Sentinel alerts are correlated to a target incident, there will always be a “source” incident which will be closed. We recommend reading about the criteria for merging incidents is, as well as specific scenarios when incidents aren't merged. Using the Microsoft Sentinel REST APIs If you have an existing integration based on the Microsoft Sentinel REST APIs, these are the relevant endpoints: Get all incidents Incidents - List - REST API (Azure Sentinel) | Microsoft Learn Get a specific incident Incidents - Get - REST API (Azure Sentinel) | Microsoft Learn Get all alerts for a specific incident Incidents - List Alerts - REST API (Azure Sentinel) | Microsoft Learn What we observe in most organizations with external ITSM systems is that they generally synchronize incidents only, not alerts; and their analysts go to Microsoft Sentinel to view the alerts and other details, hunt, etc. Therefore, we will focus on the endpoint to get all incidents, which is probably the endpoint you are using today. Let us have a look at the payload for an incident that has been closed due to redirection: These are the relevant fields for you: id: resource ID of the incident on Azure, now closed name: the incident GUID on Azure title: the source incident title (now closed, the new incident will probably have a different name) status: it will always be closed in this scenario labelName: it will always be redirected in this scenario, this tag is automatically added to incidents closed by automatic alert correlation incidentNumber: the incident number of the source incident in Azure alertCount: this will always be zero in this scenario, as the incident was emptied and alerts were transferred to the target incident providerIncidentUrl: the url of the target incident on Defender where you can find the transferred alerts incidentUrl: the url of the source incident (now closed) on Sentinel on Azure. Opening this url takes you to the old incident, which contains a banner with the new target incident url providerName: Once you onboard your Microsoft Sentinel workspace to Defender, this field will always be Microsoft XDR, as all incidents (also Sentinel incidents) are created on Defender providerIncidentId: the target incident ID on Defender Updates you could make A logic you could implement is to have an automation rule that detects when an incident is updated with the tag “Redirected”: This should trigger a logic app that calls your ITSM system: On your ITSM system, make sure you are mapping the providerIncidentUrl (link to Defender), this is important for two reasons: The link on the ITSM system should take your analysts to Defender, as it contains all the details of the incident and the alerts The API only references the url of the target incident on Defender. Since you probably want to update the target incident on your ITSM system, you will need to find the “providerIncidentUrl” on your system. Close the source incident on the ITSM system Update the source incident on the ITSM system with a description/comment with a link to the providerIncidentUrl (which is the URL of the target incident) On the target incident (providerIncidentUrl) on the ITSM system, add a description/comment mentioning the incident absorbed the alerts from the former incident Potentially increase severity of your target incident on the ITSM system Other more complex logics could include updating the owner. Important! Bear in mind that Incident provider is no longer a condition you can select on Defender because, once you onboard Microsoft Sentinel to Defender, the incident provider is always Microsoft Defender XDR. If you use this condition today, please change it to Alert product names instead (if you wish to make a distinction between different alert providers) The incident title is no longer predictable, as incident names can change through merging. If you use incident title as a condition, please change it to Analytic rule name and select the analytic rule that should trigger the automation. You can use mariocuomo 's script, which generates a report with a list of all automation rules that contain either of these conditions, so you can update them before transitioned to Defender: mariocuomo/Sentinel-Transition-To-Defender-Helper-Script: This repository contains an helper script that I developed to assist Sentinel customer to adopt Sentinel in Defender. While other changes should not affect you in this logic, we recommend reading Configure automation rules and playbooks in Defender to understand what else changes. Using the Microsoft Graph security API If you are building a new integration, or if your previous integration needs multiple updates, we recommend creating your integration based on the Microsoft Graph security API. This is the API endpoint in the Microsoft security graph API to get your incidents: https://graph.microsoft.com/beta/security/incidents If you want to get alerts under your incidents as well, please use this endpoint to get incidents and corresponding alerts: https://graph.microsoft.com/beta/security/incidents?$expand=alerts Important! Please note that alerts triggered by Sentinel analytic rules where an incident is not created are not visible on Defender, although they will be visible on the SecurityAlert table (either on the Microsoft Sentinel Azure portal, or on Defender in Advanced Hunting). This means that the Microsoft Graph security APIs cannot be used yet to submit your alerts to an ITSM system. If you wish to send alerts to an ITSM system, please use the Microsoft Sentinel REST APIs. Now, let’s have a look at the API response for an incident that was redirected: These are the relevant fields for you: id: The id of the source incident on Defender status: it will always be “redirected” in this scenario. incidentWebUrl: this is the url of the source incident on Defender, now redirected redirectIncidentId: the ID of the target incident on Defender lastModifiedBy: In this scenario you will always see Microsoft 365 Defender-AlertCorrelation As you probably noticed, in the Graph API you will not find Azure Sentinel fields. What would my logic look like Assuming you are using the Microsoft Graph security API, you are already streaming your Defender incidents to your ITSM system. If you want to update your logic to close source incidents where alerts have been transferred to a target incident, your logic could look like this: Run a logic app every few minutes to check for incidents that changed the status to “redirected”. You can do it through such an API call: https://graph.microsoft.com/v1.0/security/incidents?$filter=status eq 'redirected' and lastUpdateDateTime ge 2025-09-03T11:15:00Z (add the correct timestamp here) Now, you can find those incidents on your ITSM system and update them: Close them on the ITSM system Add a description or comment with the new incident (redirectIncidentId) You could make more changes, like going to the target incident on your ITSM system and detail there that your incident has absorbed alerts from a source incident. Remember you can add tags to your incidents on Defender too, such as the incident ID on your ITSM system. This will make synchronization easier. You can refer to the field “customTags” for this purpose. Special thanks to my colleagues NChristis, sagiyagen365 and BenjiSec for reviewing and contributing to this article!Automating Microsoft Sentinel: Playbook Fundamentals
Welcome to the third entry of our blog series on automating Microsoft Sentinel. In this series, we’re showing you how to automate various aspects of Microsoft Sentinel, from simple automation of Sentinel Alerts and Incidents to more complicated response scenarios with multiple moving parts. So far, we’ve covered Part 1: Introduction to Automating Microsoft Sentinel where we talked about why you would want to automate as well as an overview of the different types of automation you can do in Sentinel and Part 2: Automation Rules where we talked about automating the mundane away. In this post, we’re going to start talking about Playbooks which can be used for automating just about anything. Here is a preview of what you can expect in the upcoming posts [we’ll be updating this post with links to new posts as they happen]: Part 1: Introduction to Automating Microsoft Sentinel Part 2: Automation Rules – Automate the mundane away Part 3: Playbooks 1 Part I – Fundamentals [You are here] Part 4: Playbooks 2 Part II – Diving Deeper Part 5: Azure Functions / Custom Code Part 6: Capstone Project (Art of the Possible) – Putting it all together Part 3: Playbooks - Fundamentals Pre-Built Playbooks in Content Hub Before we dive any deeper into Playbooks, I want to first point out that there are many pre-built playbooks available in the Content Hub. As of this writing, there are 484 playbooks available from 195 providers covering all manner of use cases like threat intelligence ingestion, incident response, operations integrations, and more in both first party Microsoft and third-party security tools. Before we dive into the internals of Playbooks and start creating our own, you really should do yourself a favor and take a look at the Content Hub and see if there isn’t already a Playbook doing what you want. You can also review the list of solutions at the Microsoft Sentinel GitHub page at Azure-Sentinel/Solutions at master · Azure/Azure-Sentinel Basic Structure of a Playbook Microsoft Sentinel Playbooks are built on Azure Logic Apps which is a low to no-code workflow automation platform. We’ll be diving into the details of how to create a Logic App from start to finish in the next installment of this series, but for now just know that there are two key “custom” features that Sentinel exposes for use in Playbooks: Triggers and Entities. Triggers The events or actions that can start a Playbook running are Triggers. These can be Incident, Alert, or Entity based. Incident Triggers Incident triggers are when an incident is either created or updated in Sentinel. Incident triggers can be tied to Automation Rules (which were covered in part 2 of this series) and can also be manually triggered by an analyst. Playbooks launched with Incident triggers receive all the incident objects, including any entities it contains as well as the alerts it is comprised of. Alert Triggers Alert triggers are similar to Incident triggers; except they trigger when an Alert is fired due to an Analytic Rule having a result. This is especially useful when you have an Alert that is not configured to create an Incident. Alert triggers can also be tied to Automation Rules Entity Triggers Entity triggers are different from Incident and Alert triggers as they cannot be tied to Automation Rules. Instead, they are triggered manually by an analyst. For example, let’s say that there is a user account that is part of an Incident and during the investigation the analyst decided they wanted to disable that user account in Entra. They could use an Entity Trigger to launch the Playbook, passing the Account Entity to the playbook for the account to be disabled. Entities We can’t really talk about Entity Triggers without talking about Entities themselves. So, what is an Entity in Sentinel? Entities are data elements that identify components in an alert or incident. There are many different types of entities within Sentinel, but for Playbooks we only need to focus on five key ones: IP Host Account URL FileHash (for more information on Entities in general, please see: https://learn.microsoft.com/azure/sentinel/entities ) How do you use Entity Triggers? When you are building an Analytic rule, you can identify the different Entities that it contains. These are then carried along as part of the Alert and exposed for further actions. This means that all you need to do is map the results of the Analytic Rule to the different Entity types using values returned from your query. For example, let’s say we are creating an Analytic Rule to alert on a new CloudShell user being created in Azure with the following query: let match_window = 3m; AzureActivity | where ResourceGroup has "cloud-shell" | where (OperationNameValue =~ "Microsoft.Storage/storageAccounts/listKeys/action") | where ActivityStatusValue =~ "Success" | extend TimeKey = bin(TimeGenerated, match_window), AzureIP = CallerIpAddress | join kind = inner (AzureActivity | where ResourceGroup has "cloud-shell" | where (OperationNameValue =~ "Microsoft.Storage/storageAccounts/write") | extend TimeKey = bin(TimeGenerated, match_window), UserIP = CallerIpAddress ) on Caller, TimeKey | summarize count() by TimeKey, Caller, ResourceGroup, SubscriptionId, TenantId, AzureIP, UserIP, HTTPRequest, Type, Properties, CategoryValue, OperationList = strcat(OperationNameValue, ' , ', OperationNameValue1) | extend Name = tostring(split(Caller,'@',0)[0]), UPNSuffix = tostring(split(Caller,'@',1)[0]) When we use this query as the basis for an Alert, we can then use Entity Mapping under Alert Enhancement to take the relevant fields returned and map them to Entity objects: This example maps the values "Caller", "Name", and "UPNSuffix" returned by the query to the "FullName", "Name", and "UPNSuffix" fields of an Account Entity. It also maps the UserIP result to the "Address" field of an IP Entity. When the Alert fires, it will include a collection of Account and IP Entities with the necessary values in its Entities field. Now if we wanted to, we could use a Playbook based on Entity Triggers to act on the Account or IP entities. What is a “strong” identifier versus a “weak” identifier and why is it important? Entities have fields that identify individual instances. Strong identifiers uniquely identify an entity, while weak identifiers may not. Often, combining weak identifiers can create a strong identifier. For example, Account entities can be identified by a strong identifier like a Microsoft Entra ID (GUID) or User Principal Name (UPN). Alternatively, a combination of weak identifiers like Name and NTDomain can be used. Different data sources might identify the same user differently. When Microsoft Sentinel recognizes two entities as the same based on their identifiers, it merges them into one for consistent handling. We’ll be covering more details on using Entities and Triggers in the next article when we start building Playbooks from scratch. Conclusion In this article we talked about the fundamentals of Playbooks in Sentinel , the Content Hub which is the home of pre-built Playbooks, as well as the different types of Triggers that can be used to launch a Playbook. In the next article we’ll be covering how to build a playbook from scratch and put these concepts to work. Additional Resources Supported triggers and actions in Microsoft Sentinel playbooks Entities in Microsoft SentinelAutomating Microsoft Sentinel: A blog series on enabling Smart Security
Welcome to the first entry of our blog series on automating Microsoft Sentinel. We're excited to share insights and practical guidance on leveraging automation to enhance your security posture. In this series, we'll explore the various facets of automation within Microsoft Sentinel. Whether you're a seasoned security professional or just starting, our goal is to empower you with the knowledge and tools to streamline your security operations and stay ahead of threats. Join us on this journey as we uncover the power of automation in Microsoft Sentinel and learn how to transform your security strategy from reactive to proactive. Stay tuned for our upcoming posts where we'll dive deeper into specific automation techniques and share success stories from the field. Let's make your security smarter, faster, and more resilient together. In this series, we will show you how to automate various aspects of Microsoft Sentinel, from simple automation of Microsoft Sentinel Alerts and Incidents to more complicated response scenarios with multiple moving parts. We’re doing this as a series so that we can build up our knowledge step-by-step and finishing off with a “capstone project” that takes SOAR into areas that most people aren’t aware of or even thought was possible. Here is a preview of what you can expect in the upcoming posts [we’ll be updating this post with links to new posts as they happen]: Part 1: [You are here] – Introduction to Automating Microsoft Sentinel Part 2: Automation Rules – Automate the mundane away Part 3: Playbooks 1 – Playbooks Part I – Fundamentals o Triggers o Entities o In-App Content / GitHub o Consumption plan vs. dedicated – which to choose and why? Part 4: Playbooks 2 – Playbooks Part II – Diving Deeper o Built-In 1 st and 3 rd Party Connections (ServiceNow, etc.) o REST APIs (everything else) Part 5: Azure Functions / Custom Code o Why Azure Functions? o Consumption vs. Dedicated – which to choose and why? Part 6: Capstone Project (Art of the Possible) – Putting it all together Part 1: Introduction to Automating Microsoft Sentinel Microsoft Sentinel is a cloud-native security information and event management (SIEM) platform that helps you collect, analyze, and respond to security threats across your enterprise. But did you know that it also has a native, integrated Security Orchestration, Automation, and Response (SOAR) platform? A SOAR platform that can do just about anything you can think of? It’s true! What is SOAR and why would I want to use it? A Security Orchestration, Automation, and Response (SOAR) platform helps your team take action in response to alerts or events in your SIEM. For example, let’s say Contoso Corp has a policy where if a user has a medium sign-in risk in Entra ID and fails their login three times in a row within a ten-minute timeframe that we force them to re-confirm their identity with MFA. While an analyst could certainly take the actions required, wouldn’t it be better if we could do that automatically? Using the Sentinel SOAR capabilities, you could have an analytic rule that automatically takes the action without the analyst being involved at all. Why Automate Microsoft Sentinel? Automation is a key component of any modern security operations center (SOC). Automation can help you: Reduce manual tasks and human errors Improve the speed and accuracy of threat detection and response Optimize the use of your resources and skills Enhance your visibility and insights into your security environment Align your security processes with your business objectives and compliance requirements Reduce manual tasks and human errors Alexander Pope famously wrote “To err is human; to forgive, divine”. Busy and distracted humans make mistakes. If we can reduce their workload and errors, then it makes sense to do so. Using automation, we can make sure that all of the proper steps in our response playbook are followed and we can make our analysts lives easier by giving them a simpler “point and click” response capability for those scenarios that a human is “in the loop” or by having the system run the automation in response to events and not have to wait for the analyst to respond. Improve the speed and accuracy of threat detection and response Letting machines do machine-like things (such as working twenty-four hours a day) is a good practice. Leveraging automation, we can let our security operations center (SOC) run around the clock by having automation tied to analytics. Rather than waiting for an analyst to come online, triage an alert and then take action, Microsoft Sentinel can stand guard and respond when needed. Optimize the use of your resources and skills Having our team members repeat the same mundane tasks is not optimal for the speed of response and their work satisfaction. By automating the mundane away, we can give our teams more time to learn new things or work on other tasks. Enhance your visibility and insights into your security environment Automation can be leveraged for more than just responding to an alert or incident. We can augment the information we have about entities involved in an alert or incident by using automation to call REST based APIs to do point-in-time lookups of the latest threat information, vulnerability data, patching statuses, etc. Align your security processes with your business objectives and compliance requirements If you have to meet particular regulatory requirements or internal KPIs, automation can help your team to achieve their goals quickly and consistently. What Tools and Frameworks Can You Use to Automate Microsoft Sentinel? Microsoft Sentinel provides several tools that enable you to automate your security workflows, such as: Automation Rules o Automation rules can be used to automate Microsoft Sentinel itself. For example, let’s say there is a group of machines that have been classified as business critical and if there is an alert related to those machines, then the incident needs to be assigned to a Tier 3 response team, and the severity of the alert needs to be raised to at least “high”. Using an automation rule, you can take one analytic rule, apply it to the entire enterprise, but then have an automation rule that only applies to those business-critical systems. That way only the items that need that immediate escalation receive it, quickly and efficiently. o Another great use of Automation Rules is to create Incident Tasks for analysts to follow. If you have a process and workflow, by using Incident Tasks, you can have those appear inside of an Incident right there for the analysts to follow. No need to go “look it up” in a PDF or other document. Playbooks: You can use playbooks to automatically execute actions based on triggers, such as alerts, incidents, or custom events. Playbooks are based on Azure Logic Apps, which allow you to create workflows using various connectors, such as Microsoft Teams, Azure Functions, Azure Automation, and third-party services. Azure Functions can be leveraged to run custom code like PowerShell or Python and can be called from Sentinel via Playbooks. This way if you have a process or code that’s beyond a Playbook , you can still call it from the normal Sentinel workflow. Conclusion In this blog post, we introduced the automation capabilities and benefits of SOAR in Microsoft Sentinel, and some of the tools and frameworks that you can use to automate your security workflows. In the next blog posts, we will dive deeper into each of these topics and provide some practical examples and scenarios of how to automate Microsoft Sentinel. Stay tuned for more updates and tips on automating Microsoft Sentinel! Additional Resources What are Automation Rules? Automate Threat Response with playbooks in Microsoft Sentinel
Automate Extraction of Microsoft Sentinel Analytical Rules from GitHub Solutions
🔧 Enhancing Pre-Deployment Rule Insights Extracting metadata like Rule Name, Severity, MITRE Tactics, and Techniques for out-of-the-box analytical rules across multiple solutions can be time-consuming when done manually—especially before the rules are deployed. 🚀 Script Overview The PowerShell script, hosted on GitHub, lets you: Provide the exact Microsoft Sentinel solution name as input, from Microsoft Sentinel GitHub: Azure-Sentinel/Solutions at master · Azure/Azure-Sentinel · GitHub Automatically query the [Microsoft Sentinel GitHub repo] Parse all associated analytical rule YAMLs under that solution Export relevant metadata into a structured CSV 📥 GitHub Link This is My GitHub repository where the custom PowerShell script is hosted. It allows you to extract built-in analytical rules from Microsoft Sentinel solutions based on the solution name: 🔗 GitHub - SentinelArtifactExtract (Optimized Script) 📝 Pre-Requisites: Generate GitHub Personal Access token: GitHub official page to generate PAT: Managing your personal access tokens - GitHub Docs Why GitHub PAT token: It will help us to Authenticate and overcome the GitHub API rate limit Error (403). Download the Script from GitHub to Azure CloudShell: Use Invoke-WebRequest or curl to download the raw script: Command to Download the Raw Script from GitHub: Invoke-WebRequest -Uri "https://raw.githubusercontent.com/vdabhi123/SentinelArtifactExtract/main/Extract%20Sentinel%20Analytical%20Rule%20with%20Solution%20Name%20prompt/OptimizedVersionPromptforSolutionNameOnly" -OutFile "ExtractRules.ps1 Invoke-WebRequest in Azure CloudShell Update the Script with you GitHub PAT (generated in pre-requisite 1) in main script: To update the PAT token you can use vim and ensure to run the updated script. 🧪 How to Use the Script Open Azure Cloud Shell (PowerShell). Upload and run the script. (This is Optional if Pre-requisite 3 is followed) Run the Script and Enter the **exact** solution name (e.g., `McAfee ePolicy Orchestrator`). The script fetches rule metadata and exports to CSV in the same directory. Download the CSV from Cloud Shell. & 2 as highlighted. 📤 Sample Output The script generates a CSV with the following columns: - `Solution` - `AnalyticalRuleName` - `Description` - `Severity` - `MITRE_Tactics` - `MITRE_Techniques` Example file name: Formatted Output with all Analytical Rule and other metadata for the Solution: ✅ Benefits Streamlines discovery of built-in analytical rules for initial Microsoft Sentinel deployments. Accelerates requirements gathering by exporting rules into a shareable CSV format. Enables collaborative planning—output can be shared with clients or Microsoft to determine which rules to implement or recommend. Eliminates manual effort of browsing GitHub or Microsoft Sentinel UI or exporting and reviewing full JSON rule files individually. 💡 Pro Tips Always verify the solution name from the official Microsoft Sentinel GitHub Solutions folder. Azure-Sentinel/Solutions at master · Azure/Azure-Sentinel · GitHub 📌 Final Thoughts This script was created in response to a real-world project need and is focused on improving the discovery and extraction of Microsoft Sentinel analytical rules. A follow-up blog covering the export of additional Sentinel artifacts—such as Playbooks, Workbooks, and Hunting Queries—will be published soon.Introducing Threat Intelligence Ingestion Rules
Microsoft Sentinel just rolled out a powerful new public preview feature: Ingestion Rules. This feature lets you fine-tune your threat intelligence (TI) feeds before they are ingested to Microsoft Sentinel. You can now set custom conditions and actions on Indicators of Compromise (IoCs), Threat Actors, Attack Patterns, Identities, and their Relationships. Use cases include: Filter Out False Positives: Suppress IoCs from feeds known to generate frequent false positives, ensuring only relevant intel reaches your analysts. Extending IoC validity periods for feeds that need longer lifespans. Tagging TI objects to match your organization's terminology and workflows Get Started Today with Ingestion Rules To create new “Ingestion rule”, navigate to “Intel Management” and Click on “Ingestion rules” With the new Ingestion rules feature, you have the power to modify or remove indicators even before they are integrated into Sentinel. These rules allow you to act on indicators currently in the ingestion pipeline. > Click on “Ingestion rules” Note: It can take up to 15 minutes for the rule to take effect Use Case #1: Delete IOC’s with less confidence score while ingesting When ingesting IOC's from TAXII/Upload API/File Upload, indicators are imported continuously. With pre-ingestion rules, you can filter out indicators that do not meet a certain confidence threshold. Specifically, you can set a rule to drop all indicators in the pipeline with a confidence score of 0, ensuring that only reliable data makes it through. Use Case #2: Extending IOC’s The following rule can be created to automatically extend the expiration date for all indicators in the pipeline where the confidence score is greater than 75. This ensures that these high-value indicators remain active and usable for a longer duration, enhancing the overall effectiveness of threat detection and response. Use Case #3: Bulk Tagging Bulk tagging is an efficient way to manage and categorize large volumes of indicators based on their confidence scores. With pre-ingestion rules, you can set up a rule to tag all indicators in the pipeline where the confidence score is greater than 75. This automated tagging process helps in organizing indicators, making it easier to search, filter, and analyze them based on their tags. It streamlines the workflow and improves the overall management of indicators within Sentinel. Managing Ingestion rules In addition to the specific use cases mentioned, managing ingestion rules gives you control over the entire ingestion process. 1. Reorder Rules You can reorder rules to prioritize certain actions over others, ensuring that the most critical rules are applied first. This flexibility allows for a tailored approach to data ingestion, optimizing the system's performance and accuracy. 2. Create From Creating new ingestion rules from existing ones can save you a significant amount of time and offer the flexibility to incorporate additional logic or remove unnecessary elements. Effectively duplicating these rules ensures you can quickly adapt to new requirements, streamline operations, and maintain a high level of efficiency in managing your data ingestion process. 3. Delete Ingestion Rules Over time, certain rules may become obsolete or redundant as your organizational needs and security strategies evolve. It's important to note that each workspace is limited to a maximum of 25 ingestion rules. Having a clean and relevant set of rules ensures that your data ingestion process remains streamlined and efficient, minimizing unnecessary processing and potential conflicts. Deleting outdated or unnecessary rules allows for a more focused approach to threat detection and response. It reduces clutter, which can significantly enhance the performance. By regularly reviewing and purging obsolete rules, you maintain a high level of operational efficiency and ensure that only the most critical and up-to-date rules are in place. Conclusion By leveraging these pre-ingestion rules effectively, you can enhance the quality and reliability of the IOC’s ingested into Sentinel, leading to more accurate threat detection and an improved security posture for your organization.
