A Look at Different Options for Storing and Searching Sentinel Archived Logs
As an Azure Sentinel user, you know the importance of having a secure and accessible backup of your log data. In this blog, we'll show you the various options available for storing and searching Sentinel logs beyond the default 90-day retention period. Explore the features and benefits of each solution to find the best fit for your organization.Tutorial: Get started with Azure WAF investigation Notebook
In this blog, we introduce you to the Azure WAF guided investigation Notebook using Microsoft Sentinel, which lets you investigate an Azure WAF triggered SQL injection attack event log. This Azure WAF Notebook queries incidents related to Azure WAF SQL injection events in your Microsoft Sentinel workspace. In addition to guiding you through the Azure WAF SQL injection incidents, the Notebook correlates the incidents with Threat Intelligence, maps them to the Sentinel entity graph, and gives you a complete picture of the attack landscape. Furthermore, it will guide you through an investigation experience to determine if the incident is a true positive, false positive or benign positive using Azure WAF raw logs. Upon confirmation of a false positive, the Azure WAF exclusions are applied automatically using Azure WAF APIs.
Microsoft Sentinel & Cyberint Threat Intel Integration Guide
Explore comprehensive guide on "Microsoft Sentinel & Cyberint Threat Intel Integration Guide," to learn how to integrate Cyberint's advanced threat intelligence with Microsoft Sentinel. This detailed resource will walk you through the integration process, enabling you to leverage enriched threat data for improved detection and response. Elevate your security posture and ensure robust protection against emerging threats. Read the guide to streamline your threat management and enhance your security capabilities.
Azure Active Directory Identity Protection user account enrichments removed: how to mitigate impact
AADIP connector no longer contains user account enrichment fields. In this post we'll offer mitigation steps you can take, to allow you to self enrich your AADIP data in your Microsoft Sentinel workspace using UEBA's IdentityInfo table.
Guided Hunting Notebook: Azure Resource Explorer
While hunting in Azure, you might find yourself pivoting from one resource to another or find that you may want to see the whole workspace from a big picture point of view. The Guided Hunting: Azure Resource Explorer notebook will allow you to take advantage of the new Azure Resource API and visualize all the resources in your subscription. It will also provide general contextual TI info about your resources of interest to help you recognize unusual behaviors.
Multi-workspace for Multi-tenant is now in Public Preview in Microsoft's Unified SecOps Platform
We are thrilled to announce that our unified security operations (SecOps) platform now supports multi workspaces for multiple tenants, currently available in public preview. This marks a significant advancement in our commitment to providing comprehensive security solutions tailored to the diverse needs of our customers. The unified platform integrates the capabilities of Microsoft Sentinel, Defender XDR, and more, offering a seamless and robust experience. What's Included in the Microsoft Unified Security Operations Platform? The unified SecOps platform integrates several advanced features designed to provide comprehensive security management across multiple workspaces and tenants: Single pane of glass for all your tenant’s incidents and alerts. Triage and investigate incidents and alerts across multiple workspaces and tenants in a single place. Improved threat hunting experience. Proactively search for security data across multiple workspaces and tenants using Advanced hunting. Multi-workspace, Multi-tenant Experience—Main Scenarios Multi-tenant portal To use the unified SecOps platform experience for multiple tenants and workspaces, you must first sign in to the multi-tenant portal. Learn more: https://aka.ms/mtoportal Make sure to onboard all your tenants’ workspaces separately in the main, single tenant portal. Workspaces are onboarded separately for each tenant. (each tenant is onboarded separately). Learn more: https://aka.ms/OnboardMultiWS Incidents and Alerts In the unified queues, you are now able to view all incidents and alerts, from all workloads, workspaces, and tenants, and filter by workspace or tenant. Each alert and incident is related to a single workspace and tenant to keep data boundaries. Bi-directional sync ensures that any change made in the unified SecOps portal is reflected in Microsoft Sentinel in the Azure portal, and vice versa. Advanced Hunting In Advanced Hunting, you'll be able to explore all your security data in a single place. For hunting and investigation purposes, you'll be able to query Microsoft Sentinel with data from all your workspaces, running queries across multiple workspaces and tenants using the workspace operator in your query. Instructions Navigate to Advanced Hunting in MTO portal. Select tenants and workspace in the selector: Click on the tenant selector in the right section of the window. For each tenant with workspace onboarded, click on “edit selection” and choose the workspace (we currently support only single WS selection per tenant). Run any cross-tenant queries with a single workspace in each tenant (all queries can be joined with Defender tables). Quering across multiple workspaces and multiple tenants using the “workspace operator”: You can run queries across multiple workspaces and multiple tenants. To do so, please select only a single tenant in the selector and use the workspace operator by calling other workspaces’ names. For example: You manage two tenants, with multiple workspaces for each tenant: TenantA: WS1, WS2; TenantB: WS3, WS4. You would like to run cross WS-cross tenants queries. You should: select any tenant in the selector (should be single select: TenantA, and WS1 selected). Run cross queries on “Usage” table. Query: union workspace("WorkspaceB2").Usage, Usage | where TimeGenerated > ago(1d) | summarize TotalRecords = count() by Workspace = TenantId Results: you should receive results from WS1 (TenantA) and results from WS3 (TenantB). This capability is available only for tenants that have permissions to other tenants’ workspaces using Azure Lighthouse. FAQ How can I onboard my tenants’ workspaces to the unified SecOps platform? Onboard each tenants’ workspaces separately in the single tenant portal. Learn more: https://aka.ms/OnboardMultiWS Is Azure Lighthouse supported in the MTO portal? Yes, Azure Lighthouse is supported and required to gain access to Microsoft Sentinel data in other tenants’ workspaces. What delegated access method is supported in the MTO portal? To use the multi workspace capability you must enable: Azure Lighthouse - required to access other tenants’ Microsoft Sentinel data. B2B - to access Defender data. GDAP is not supported yet for unified SecOps capabilities. Will data from one workspace/ one tenant be synced to a second workspace/ tenant? No, data boundaries between workspaces and tenants are maintained, ensuring that each workspace will only be synced with its own data. Can I still access my environment in Azure? Yes, all experiences remain the same. Conclusion Microsoft’s unified SecOps platform support for multi- workspace, multi- tenants customers represent a significant leap forward in cybersecurity management. By centralizing operations and providing robust tools for detection, investigation, and automation, it empowers organizations to maintain a vigilant and responsive security posture. The platform’s flexibility and comprehensive view of security data make it an invaluable asset for modern security operations. With the public preview now available, organizations can experience firsthand the transformative impact of the Unified Security Operations Platform. Join us in pioneering a new era of cybersecurity excellence. Learn More Please visit our documentation to learn more about the supported scenarios and how to onboard multiple workspaces and tenants to the unified platform: https://aka.ms/UsopMTO https://aka.ms/OnboardMultiWSAutomating 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 Sentinel
