Introducing a Unified Security Operations Platform with Microsoft Sentinel and Defender XDR
Read about our announcement of an exciting private preview that represents the next step in the SOC protection and efficiency journey by bringing together the power of Microsoft Sentinel, Microsoft Defender XDR and Microsoft Security Copilot into a unified security operations platform.Automating 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 SentinelTurn Complexity into Clarity: Introducing the New UEBA Behaviors Layer in Microsoft Sentinel
Security teams today face an overwhelming challenge: every data point is now a potential security signal, and SOCs are drowning in fragmented, high-volume logs from countless sources - firewalls, cloud platforms, identity systems, and more. Analysts spend precious time translating between schemas, manually correlating events, and piecing together timelines across disparate data sources. For custom detections, it’s no different. What if you could transform this noisy complexity into clear, actionable security intelligence? Today, we're thrilled to announce the release of the UEBA Behaviors layer - a breakthrough AI-based UEBA capability in Microsoft Sentinel that fundamentally changes how SOC teams understand and respond to security events. The Behaviors layer translates low-level, noisy telemetry into human-readable behavioral insights that answer the critical question: "Who did what to whom, and why does it matter?" Instead of sifting through thousands of raw CloudTrail events or firewall logs, you get enriched, normalized behaviors - each one mapped to MITRE ATT&CK tactics and techniques, tagged with entity roles, and presented with a clear, natural-language explanation. All behaviors are aggregated and sequenced within a time window or specific trigger, to give you the security story that resides in the logs. What Makes the Behaviors Layer Different? Unlike alerts - which signal potential threats - or anomalies - which flag unusual activity - behaviors are neutral, descriptive observations. They don't decide if something is malicious; they simply describe meaningful actions in a consistent, security-focused way. The Behaviors layer bridges the gap between alerts (work items for the SOC, indicating a breach) and raw logs, providing an abstraction layer that makes sense of what happened without requiring deep familiarity with every log source. While existing UEBA capabilities provide insights and anomalies for a specific event (raw log), behaviors turn clusters of related events – based on time windows or triggers – into security data. The technology behind it: Generative AI powers the Behaviors layer to create and scale the insights it provides. AI is used to develop behavior logic, map entities, perform MITRE mapping, and ensure explainability - all while maintaining quality guardrails. Each behavior is mapped back to raw logs, so you can always trace which events contributed to it. Real-World Impact: We've been working closely with enterprise customers during private preview, and their feedback speaks volumes about the transformative potential of the Behaviors layer: "We're constantly exploring innovative ways to detect anomalous behavior for our detection engineering and incident enrichment. Behaviors adds a powerful new layer that also covers third-party data sources in a multi-cloud environment - seamlessly integrable and packed with rich insights, including MITRE mapping and detailed context for deeper correlation and context-driven investigation." (Glueckkanja) "Microsoft's new AI-powered extension for UEBA enhances behavioral capabilities for PaloAlto logs. By intelligently aggregating and sequencing low-level security events, it elevates them into high-fidelity 'behaviors' - powerful, actionable signals. This enhanced behavioral intelligence significantly can improve your security operations. During investigations, these behaviors are immediately pointing to unusual or suspicious activities and providing a rich, contextual understanding of an entity's actions. They serve as a stable starting point for the analysts, instead of sifting through millions of logs." (BlueVoyant) How It Works: Aggregation and Sequencing The Behaviors layer operates using two powerful patterns: Aggregation Behaviors detect volume-based patterns. For example: "User accessed 50+ AWS resources in 1 hour." These are invaluable for spotting unusual activity levels and turning high-volume logs into actionable security insights. Sequencing Behaviors detect multi-step patterns that surface complex chains invisible in individual events. For example: "Access key created → used from new IP → privileged API calls." This helps you spot sophisticated tactics and procedures across sources. Once enabled, behaviors are aggregated and sequenced based on time windows and triggers tailored to each logic. When the time window closes or a pattern is identified, the behavior log is created immediately - providing near real-time availability. The behaviors are stored as records in Log Analytics. This means each behavior record contributes to your data volume and will be billed according to your Sentinel/Log Analytics data ingestion rates. Use Cases: Empowering Every SOC Persona The new Behaviors layer in Microsoft Sentinel enhances the daily workflows of SOC analysts, threat hunters, and detection engineers by providing a unified, contextual view of security activity across diverse data sources. SOC analysts can now investigate incidents faster by querying behaviors tied to the entities involved in an incident. For example, instead of reviewing 20 separate AWS API calls, a single behavior like “Suspicious mass secret access via AWS IAM” provides immediate clarity and context, with or without filtering on specific MITRE ATT&CK mapping. Simply use the following query (choose the entity you’re investigating): let targetTechniques = dynamic ("Password Guessing (T1110.001)"); // to filter on MITRE ATT&CK let behaviorInfoFiltered = BehaviorInfo | where TimeGenerated > ago(1d) | where AttackTechniques has_any (targetTechniques) | project BehaviorId, AttackTechniques; BehaviorEntities | where TimeGenerated > ago(1d) | where AccountUpn == ("user@domain.com") | join kind=inner (behaviorInfoFiltered) on BehaviorId Threat hunters benefit from the ability to proactively search for behaviors mapped to MITRE tactics or specific patterns, uncovering stealthy activity such as credential enumeration or lateral movement without complex queries. Another use case, is looking for specific entities that move across the MITRE ATT&CK chain within a specific time window, for example: let behaviorInfo = BehaviorInfo | where TimeGenerated > ago(12h) | where Categories has "Persistance" or Categories has "Discovery" // Replace with actual tactics | project BehaviorId, Categories, Title, TimeGenerated; BehaviorEntities | where TimeGenerated > ago(12h) | extend EntityName = coalesce(AccountUpn, DeviceName, CloudResourceId) // Replace with actual entity types | join kind=inner (behaviorInfo) on BehaviorId | summarize BehaviorTypes = make_set(Title), AffectedEntities = dcount(EntityName) by bin(TimeGenerated, 5m) | where AffectedEntities > 5 Detection engineers can build simpler, more explainable rules using normalized, high-fidelity behaviors as building blocks. This enables faster deployment of detections and more reliable automation triggers, such as correlating a new AWS access key creation with privilege escalation within a defined time window. Another example is joining the rarest behaviors with other signals that include the organization’s highest value assets: BehaviorInfo | where TimeGenerated > ago(5d) | summarize Occurrences = dcount(behaviorId), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Title | order by Occurrences asc Supported Data Sources & Coverage This release focuses on most common non-Microsoft data sources that traditionally lack easy behavioral context in Sentinel. Coverage of more behaviors will expand over time - both within each data source and across new sources. Initial supported sources include: CommonSecurityLog - Specific vendors and logs: o Cyber Ark Vault o Palo Alto Threats AWS CloudTrail - Coverage for several AWS services like EC2, IAM, S3, EKS, Secrets Manager (common AWS management activities) GCPAuditLogs Once enabled, two new tables (BehaviorInfo and BehaviorEntities) will populate in your Log Analytics workspace. You can query these tables in Advanced Hunting, use them in detection rules, or view them alongside incidents - just like any other Sentinel data. If you already benefit from Defender behaviors (such as Microsoft Defender for Cloud Apps), the same query will show results for all sources. Ready to Experience the Power of Behaviors? The future of security operations is here. Don't wait to modernize your SOC workflows. Enable the Behaviors layer in Microsoft Sentinel today and start transforming raw telemetry into clear, contextual insights that accelerate detection, investigation, and response. Get started now: Understand pre-requisites, limitations, pricing, and use of AI in Documentation. Navigate to your Sentinel workspace settings, enable the Behaviors layer (a new tab under the UEBA settings) and connect the data sources. This is currently supported for a single workspace per tenant (best chosen by the ingestion of the supported data sources). Once enabled, explore the BehaviorInfo and BehaviorEntities tables in Advanced Hunting. If you already benefit from behaviors in XDR, querying the tables will show results from both XDR and UEBA. Start building detection rules, hunting queries, and automation workflows using the behaviors as building blocks. Share your feedback to help us improve and expand coverage.Microsoft Sentinel’s AI-driven UEBA ushers in the next era of behavioral analytics
Co-author - Ashwin Patil Security teams today face an overwhelming challenge: every data point is now a potential security signal and SOCs are drowning in complex logs, trying to find the needle in the haystack. Microsoft Sentinel User and Entity Behavior Analytics (UEBA) brings the power of AI to automatically surface anomalous behaviors, helping analysts cut through the noise, save time, and focus on what truly matters. Microsoft Sentinel UEBA has already helped SOCs uncover insider threats, detect compromised accounts, and reveal subtle attack signals that traditional rule-based methods often miss. These capabilities were previously powered by a core set of high-value data sources - such as sign-in activity, audit logs, and identity signals - that consistently delivered rich context and accurate detections. Today, we’re excited to announce a major expansion: Sentinel UEBA now supports six new data sources including Microsoft first- and third-party platforms like Azure, AWS, GCP, and Okta, bringing deeper visibility, broader context, and more powerful anomaly detection tailored to your environment. This isn’t just about ingesting more logs. It’s about transforming how SOCs understand behavior, detect threats, and prioritize response. With this evolution, analysts gain a unified, cross-platform view of user and entity behavior, enabling them to correlate signals, uncover hidden risks, and act faster with greater confidence. Newly supported data sources are built for real-world security use cases: Authentication activities MDE DeviceLogonEvents – Ideal for spotting lateral movement and unusual access. AADManagedIdentitySignInLogs – Critical for spotting stealthy abuse of non - human identities. AADServicePrincipalSignInLogs - Identifying anomalies in service principal usage such as token theft or over - privileged automation. Cloud platforms & identity management AWS CloudTrail Login Events - Surfaces risky AWS account activity based on AWS CloudTrail ConsoleLogin events and logon related attributes. GCP Audit Logs - Failed IAM Access, Captures denied access attempts indicating reconnaissance, brute force, or privilege misuse in GCP. Okta MFA & Auth Security Change Events – Flags MFA challenges, resets, and policy modifications that may reveal MFA fatigue, session hijacking, or policy tampering. Currently supports the Okta_CL table (unified Okta connector support coming soon). These sources feed directly into UEBA’s entity profiles and baselines - enriching users, devices, and service identities with behavioral context and anomalies that would otherwise be fragmented across platforms. This will complement our existing supported log sources - monitoring Entra ID sign-in logs, Azure Activity logs and Windows Security Events. Due to the unified schema available across data sources, UEBA enables feature-rich investigation and the capability to correlate across data sources, cross platform identities or devices insights, anomalies, and more. AI-powered UEBA that understands your environment Microsoft Sentinel UEBA goes beyond simple log collection - it continuously learns from your environment. By applying AI models trained on your organization’s behavioral data, UEBA builds dynamic baselines and peer groups, enabling it to spot truly anomalous activity. UBEA builds baselines from 10 days (for uncommon activities) to 6 months, both for the user and their dynamically calculated peers. Then, insights are surfaced on the activities and logs - such as an uncommon activity or first-time activity - not only for the user but among peers. Those insights are used by an advanced AI model to identify high confidence anomalies. So, if a user signs in for the first time from an uncommon location, a common pattern in the environment due to reliance on global vendors, for example, then this will not be identified as an anomaly, keeping the noise down. However, in a tightly controlled environment, this same behavior can be an indication of an attack and will surface in the Anomalies table. Including those signals in custom detections can help affect the severity of an alert. So, while logic is maintained, the SOC is focused on the right priorities. How to use UEBA for maximum impact Security teams can leverage UEBA in several key ways. All the examples below leverage UEBA’s dynamic behavioral baselines looking back up to 6 months. Teams can also leverage the hunting queries from the "UEBA essentials" solution in Microsoft Sentinel's Content Hub. Behavior Analytics: Detect unusual logon times, MFA fatigue, or service principal misuse across hybrid environments. Get visibility into geo-location of events and Threat Intelligence insights. Here’s an example of how you can easily discover Accounts authenticating without MFA and from uncommonly connected countries using UEBA behaviorAnalytics table: BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "AwsConsoleSignIn" | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" | where ActivityInsights.IsMfaUsed == "No" | where ActivityInsights.CountryUncommonlyConnectedFromInTenant == True | evaluate bag_unpack(UsersInsights, "AWS_") | where InvestigationPriority > 0 // Filter noise - uncomment if you want to see low fidelity noise | project TimeGenerated, _WorkspaceId, ActionType, ActivityType, InvestigationPriority, SourceIPAddress, SourceIPLocation, AWS_UserIdentityType, AWS_UserIdentityAccountId, AWS_UserIdentityArn Anomaly detection Identify lateral movement, dormant account reactivation, or brute-force attempts, even when they span cloud platforms. Below are examples of how to discover UEBA Anomalous AwsCloudTrail anomalies via various UEBA activity insights or device insights attributes: Anomalies | where AnomalyTemplateName in ( "UEBA Anomalous Logon in AwsCloudTrail", // AWS ClousTrail anomalies "UEBA Anomalous MFA Failures in Okta_CL", "UEBA Anomalous Activity in Okta_CL", // Okta Anomalies "UEBA Anomalous Activity in GCP Audit Logs", // GCP Failed IAM access anomalies "UEBA Anomalous Authentication" // For Authentication related anomalies ) | project TimeGenerated, _WorkspaceId, AnomalyTemplateName, AnomalyScore, Description, AnomalyDetails, ActivityInsights, DeviceInsights, UserInsights, Tactics, Techniques Alert optimization Use UEBA signals to dynamically adjust alert severity in custom detections—turning noisy alerts into high-fidelity detections. The example below shows all the users with anomalous sign in patterns based on UEBA. Joining the results with any of the AWS alerts with same AWS identity will increase fidelity. BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "AwsConsoleSignIn" | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" | where ActivityInsights.FirstTimeConnectionViaISPInTenant == True or ActivityInsights.FirstTimeUserConnectedFromCountry == True | evaluate bag_unpack(UsersInsights, "AWS_") | where InvestigationPriority > 0 // Filter noise - uncomment if you want to see low fidelity noise | project TimeGenerated, _WorkspaceId, ActionType, ActivityType, InvestigationPriority, SourceIPAddress, SourceIPLocation, AWS_UserIdentityType, AWS_UserIdentityAccountId, AWS_UserIdentityArn, ActivityInsights | evaluate bag_unpack(ActivityInsights) Another example shows anomalous key vault access from service principal with uncommon source country location. Joining this activity with other alerts from the same service principle increases fidelity of the alerts. You can also join the anomaly UEBA Anomalous Authentication with other alerts from the same identity to bring the full power of UEBA into your detections. BehaviorAnalytics | where TimeGenerated > ago(1d) | where EventSource == "Authentication" and SourceSystem == "AAD" | evaluate bag_unpack(ActivityInsights) | where LogonMethod == "Service Principal" and Resource == "Azure Key Vault" | where ActionUncommonlyPerformedByUser == "True" and CountryUncommonlyConnectedFromByUser == "True" | where InvestigationPriority > 0 Final thoughts This release marks a new chapter for Sentinel UEBA—bringing together AI, behavioral analytics, and cross-cloud and identity management visibility to help defenders stay ahead of threats. If you haven’t explored UEBA yet, now’s the time. Enable it in your workspace settings and don’t forget to enable anomalies as well (in Anomalies settings). And if you’re already using it, these new sources will help you unlock even more value. Stay tuned for our upcoming Ninja show and webinar (register at aka.ms/secwebinars), where we’ll dive deeper into use cases. Until then, explore the new sources, use the UEBA workbook, update your watchlists, and let UEBA do the heavy lifting. UEBA onboarding and setting documentation Identify threats using UEBA UEBA enrichments and insights reference UEBA anomalies referenceLevel Up Your Security Skills with the New Microsoft Sentinel Ninja Training!
If you’ve explored our Microsoft Sentinel Ninja Training in the past, it’s time to revisit! Our training program has undergone some exciting changes to keep you ahead of the curve in the ever-evolving cybersecurity landscape. Microsoft Sentinel is a cutting-edge, cloud-native SIEM and SOAR solution designed to help security professionals protect their organizations from today’s complex threats. Our Ninja Training program is here to guide you through every aspect of this powerful tool. So, what’s new? In addition to the structured security roles format, the Ninja Training now offers a more interactive experience with updated modules, hands-on labs, and real-world scenarios. Whether you're focusing on threat detection, incident response, or automation, the training ensures you gain the practical skills needed to optimize your security operations. One of the biggest updates is the integration of Sentinel into the Defender XDR portal, creating a unified security platform. This merger simplifies workflows, speeds up incident response, and minimizes tool-switching, allowing for seamless operations. Other highlights include: Step-by-step guidance through the official Microsoft Sentinel documentation. Exclusive webinars and up-to-date blog posts from Microsoft experts. If you're ready to take your Sentinel skills to the next level or want to revisit the program’s new features, head over to the blog now and dive into the refreshed Microsoft Sentinel Ninja Training! Don’t miss out—your next cybersecurity breakthrough is just a click away!Automating 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!Case Management is now Generally Available
We are thrilled to announce the general availability of our Case Management service, a significant milestone in our commitment to providing a unified, security-focused case management system for Security Operations (SecOps) teams. This release builds on a successful public preview phase and incorporates customer feedback to streamline and optimize your security workflows. Recapping the Journey to Public Preview In our previous blog post, we shared our vision for creating a case management system that addresses the unique needs of SecOps teams. Many teams using Microsoft Sentinel or Microsoft Defender XDR face challenges due to the overreliance on third-party tools to manage cases. These tools often lack the necessary security context, leading to generic views, inefficiencies in case resolution, and increased response times. Additionally, the lack of integration with SecOps workflows hinders effective communication and collaboration within and outside the Security Operations Center (SOC). To address these challenges, we introduced the public preview of our case management service, marking the first steps towards a centralized, security-focused case management experience. This new service aims to reduce dependency on external ticketing systems by offering rich collaboration, customization, evidence collection, and reporting capabilities tailored specifically for SecOps workloads. Even at this early phase, customers are actively using case management for threat hunting, detection tuning, and managing complex incidents. Key Features and Enhancements During the public preview, we introduced several foundational features that have now been refined and expanded for general availability. With our case management service, you can: Create and track your SecOps-related cases in one place with the new cases page. Define your own workflow by configuring custom status values. Improve collaboration, quality, and accountability by assigning tasks and due dates. Handle escalations and complex cases by linking multiple incidents to a case. Manage access to your cases using Role-Based Access Control (RBAC). You can learn more about these capabilities in our public preview blog post and product documentation. Looking Ahead While this release marks a significant progression, it is only the beginning. We have an exciting roadmap ahead that includes added automation features, multi-tenant support, enhanced collaboration, and customization capabilities. These future enhancements will establish our case management system as an indispensable tool for SecOps teams, helping them stay ahead in the ever-evolving landscape of cybersecurity threats. We invite you to explore the general availability of the Case Management feature using our unified SecOps platform. Stay tuned for more updates as we continue to innovate and enhance our offerings to better serve your security needs. Thank you for your support and feedback as we work to enhance SecOps efficiency and effectiveness.
