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!How to: Ingest Splunk alert data to Microsoft Sentinel SIEM
Thanks to Javier Soriano, Principal Product Manager - OneSOC Customer Experience Engineering, for the peer review Introduction Although the recommended approach is to not have multiple SIEM solutions in place, many organizations are still running dual-SIEM setups, sometimes even introducing additional ones in the mix. Combination most often seen is running a legacy solution and pairing it with modern SIEM solutions like Microsoft Sentinel SIEM. Side-by-side architecture is recommended for just long enough to complete the migration, train people and update processes - but organizations might stay with the side-by-side configuration longer when they are not ready to move away from legacy solutions. In such situations, organizations usually opt for sending alerts from their legacy SIEM to Sentinel SIEM: Cloud data is ingested and analyzed in Sentinel SIEM On-premises data is ingested and analyzed in legacy SIEM which generates alerts Alerts are forwarded from legacy SIEM to Sentinel SIEM With this approach, SOC teams have a single interface where they are able to cross-correlate and investigate alerts from their organizations while benefiting from full value of unified security operations in Microsoft Defender. Send Splunk alerts to Sentinel SIEM Splunk side When an alert is raised in Splunk, organizations have an option to set up following alert actions: Email notification action Webhook alert action Output results to a CSV lookup Log events Monitor triggered alerts Send alerts and dashboards to Splunk Mobile Users Interestingly, it is possible to work with Webhooks to make an HTTP POST request on a URL. The data is in JSON format which makes it easily consumable by Sentinel SIEM. For this to work, Splunk needs the hook URL from the target source (in this case, Sentinel SIEM). { "result": { "sourcetype" : "mongod", "count" : "8" }, "sid" : "scheduler_admin_search_W2_at_14232356_132", "results_link" : "http://web.example.local:8000/app/search/@go?sid=scheduler_admin_search_W2_at_14232356_132", "search_name" : null, "owner" : "admin", "app" : "search" } Example: Splunk alert JSON payload Microsoft side From Microsoft perspective, organizations can take advantage of Logs Ingestion API, which allows for any application that can make a REST API call to send data to Sentinel SIEM. To configure Logs Ingestion API, a couple of supporting resources are needed: Microsoft Entra application which will authenticate against the API Custom table in Log Analytics workspace, where the data will be sent to and accessible from Sentinel SIEM Data Collection Rule (DCR) which will direct data to the target custom table Entra application from the first step needs to have RBAC assigned on the DCR resource A solution to call Logs Ingestion API so the data can be sent to the Sentinel SIEM. In order to make this process streamlined and easy to deploy, a solution has been developed which will automate creation of all of these supporting resources and allow you to have a Webhook URL ready which can be just placed in your Splunk solution: https://github.com/Azure/Azure-Sentinel/tree/master/Tools/SplunkAlertIngestion Picture: Content of the solution The script with supporting ARM templates can be run directly from the Azure Cloud Shell and configured with a couple of parameters: ./SplunkAlertIngestion.ps1 -ServicePrincipalName "" -tableName "" -workspaceResourceId "" -dataCollectionRuleName "" -location "" ServicePrincipalName - mandatory, define a name for the SP tableName - mandatory, define a name for the custom table with the suffix _CL (example: SplunkAlertInfo_CL) workspaceResourceId - mandatory, the resourceId can be fetched from the Log Analytics Workspace Properties blade (/subscriptions/xxx-xxx/resourceGroups/xxx/providers/Microsoft.OperationalInsights/workspaces/xxx) dataCollectionRuleName - mandatory, define DCR name location - mandatory, define Azure location for the resources (example: northeurope, eastus2) LogicAppName - not mandatory, define the name for the LogicApp, otherwise it will be named SplunkAlertAutomationLogicApp Result The script will create all supporting resources that are needed and will provide the Webhook URL as an output. Use this URL to configure trigger action in Splunk: Picture: Instructions for configuring webhook alert action in Splunk Once the webhook is configured on Splunk side, any time the alert is raised it will trigger the webhook, which will initiate the Logic App resource on Azure side responsible for parsing the data and sending that data through Logs Ingestion API to the destination table in Sentinel SIEM. Picture: Workflow of the Logic App Conclusion Ingesting alert data from other solutions in your organization to Sentinel SIEM allows for security teams to take advantage of unified security operations in Microsoft Defender - easier cross-correlation between various data sources, comprehensive threat intelligence and case management experience.RSAC 2025 new Microsoft Sentinel connectors announcement
Microsoft Sentinel is a leading cloud-native security information and event management (SIEM) solution that helps organizations confidently detect, investigate and respond to threats across their multi-cloud, multiplatform environments. Microsoft Sentinel offers seamless integration of data from both Microsoft and third-party sources for a comprehensive view across the entire digital environment. We are very pleased to share the latest Microsoft Sentinel integrations from our valued Independent Software Vendor (ISV) partners that allow you to seamlessly connect your existing security solutions with Microsoft Sentinel and benefit from robust analytics and automation capabilities to strengthen your defenses against evolving cyber threats. Featured ISVs Google Threat Intelligence for Microsoft Sentinel The Google Threat Intelligence Solution for Microsoft Sentinel integrates Google's extensive threat intelligence with Microsoft Sentinel to enrich security investigations. This solution automates the process of gathering intelligence on indicators like IPs, file hashes, and URLs, providing valuable context and improving the accuracy and efficiency of incident response. Infoblox App for Microsoft Sentinel The Infoblox App for Microsoft Sentinel enhances Security Operations Centers (SOC) by integrating actionable intelligence and contextual network data derived from DNS data into Microsoft Sentinel. This integration provides SOC analysts with tools to quickly identify and respond to potential threats such as malware and data exfiltration, improving overall security posture. This integration offers seamless configuration, intuitive dashboards, and unique DNS-based threat intelligence to streamline threat detection and response. Netskope Data Connector for Microsoft Sentinel Built on the CCF, this connector seamlessly streams CASB alerts, DLP incidents, and threat logs into Microsoft Sentinel, delivering real-time visibility and actionable insights. With a one-click setup and automated data flow, the integration simplifies incident management. This empowers security teams to focus on rapid incident response and proactive policy enforcement, boosting both security posture and operational efficiency. New and notable Dragos Platform for Microsoft Sentinel Integration The Dragos Platform integration with Microsoft Sentinel streamlines IT/OT security by providing visibility into OT assets, threats, and vulnerabilities for industrial environments. This integration enables customers to seamlessly incorporate OT-specific threat detection into their existing IT security workflows, creating a unified approach to managing alerts. Jamf Protect for Microsoft Sentinel The Jamf Protect for Microsoft Sentinel solution provides comprehensive Apple Endpoint Security insights by integrating detailed event data from macOS endpoints into a Microsoft Sentinel workspace. This integration offers full visibility into security events through Workbooks, Analytic Rules, and Unified Logging events captured by Jamf Protect. Additionally, it includes tools such as Hunting Queries, Playbooks, and a Data Connector to enhance incident investigation and automated actions. Trigger Torq Workflows from Microsoft Sentinel Incidents The Torq Sentinel Solution triggers Torq workflows directly from Microsoft Sentinel incidents, simplifying the setup process and streamlining the deployment of Hyperautomated Microsoft Sentinel workflows. When new incidents are created or existing incidents are updated in Microsoft Sentinel, Torq leverages Hyperautomation and agentic AI to help eliminate false positives, create and prioritize comprehensive security cases, and help autonomously remediate incidents to enhance SOC teams’ efficiency. ZeroFox Alerts & CTI Connectors for Microsoft Sentinel The ZeroFox Alerts & CTI Connectors for Microsoft Sentinel allows you to ingest ZeroFox alert data into Microsoft Sentinel. This integration leverages a global data collection engine, AI-based analysis, and automated remediation to help protect your digital assets and data from threats at the scale and speed of the internet. It enables organizations to visualize and analyze these threats directly from Microsoft Sentinel, improving security posture through correlation with other internal IT and security data sources. Solutions now available for Microsoft Sentinel Microsoft Sentinel now offers a range of solutions. Alongside commercially supported integrations, the Microsoft Sentinel content hub connects you to hundreds of community-based solutions and thousands of practitioner contributions. You can find more details and setup instructions for these integrations via the content hub in Microsoft Sentinel. Microsoft’s Sentinel Promise to customers For customers migrating to Sentinel, Microsoft offers the Sentinel Promise program backed by App Assure. This initiative ensures ISVs receive the support they need to build high-quality connectors. Read our recent announcement to learn how our Sentinel Promise helps promote seamless integration of your essential data sources. Message to our partners We deeply appreciate the unwavering collaboration and valuable contributions of our partners. Your steadfast partnership has been crucial in delivering the most comprehensive, timely insights and security value to our mutual customers. We are grateful to be working together to enhance the security landscape. Security is indeed a team effort, and your dedication and innovation are instrumental in our collective success. We aim for these new partner solutions to provide significant value and welcome your feedback and suggestions. We continually work on enhancing Microsoft Sentinel and expanding its partner ecosystem. Please stay informed of further updates and announcements. Learn more Microsoft’s commitment to security Microsoft’s Secure Future Initiative Unified SecOps | SIEM and XDR solutions Unified Platform documentation | Microsoft Defender XDR What else is new with Microsoft Sentinel? Microsoft Sentinel product home Microsoft Sentinel content hub catalog Microsoft's Sentinel Promise What’s new with Microsoft Sentinel at Secure 2025 Exciting new Microsoft Sentinel connectors announcement at Ignite 2024 Additional resources Best practices for partners integrating with Microsoft Sentinel What's New: Create your own codeless data connector Latest Microsoft Tech Community Sentinel blog announcements Microsoft Sentinel pricing Microsoft Sentinel customer stories Microsoft Sentinel documentationApp Assure’s promise: Migrate to Sentinel with confidence
In today's evolving cyber-threat landscape, enterprises need the most up-to-date tools for detection, investigation, and response. Cloud-native, AI-driven solutions like Microsoft's Sentinel provide businesses with faster implementation, greater integration and automation capabilities, and intelligent event correlation. But when moving from on-prem to the cloud, or from one SIEM to another, migrating can seem risky and complex for Security Operations Centers (SOCs) that have spent years investing in customized solutions. One challenge businesses face is how to port over third-party connectors, especially ones processing large data volumes, which can reach terabytes per day. For customers with such needs, Microsoft has built the Codeless Connector Framework (CCF) in Microsoft Sentinel. Microsoft Sentinel’s Codeless Connector Framework reduces friction for enterprises migrating to the cloud For enterprises ready to modernize their security operations, Microsoft recommends leveraging integrations built on CCF. These integrations are built to handle large data workloads and provide a number of powerful benefits: CCF connectors are a scalable and reliable SaaS offering, capable of handling high-volume data ingestion effortlessly. Its Data Collection Rules (DCRs) enable log filtering and transformation at ingestion, reducing data volume and lowering costs. CCF also streamlines installation and deployment. What formerly took hundreds of lines of code to configure, now takes a few simple mouse clicks. CCF communication is conducted privately between Microsoft services without being exposed to the public internet, thus aligning with Microsoft's security best practices to provide a secure and robust integration environment. What makes CCF an even more compelling and powerful tool is that our App Assure team stands behind the platform to uphold Microsoft’s Sentinel compatibility promise. Microsoft’s Sentinel promise How App Assure delivers on this promise Backed by Microsoft engineering, App Assure is here to help. If a Microsoft Sentinel ISV solution is not yet available or you have an issue with a solution already published by an ISV, App Assure may be able to assist with the following customer scenarios: Working with ISVs to develop new CCF solutions. Working with ISVs to add new features to existing CCF solutions. For supported scenarios, an App Assure Manager will be assigned to guide you through the process, ensuring you can leverage the full power of Sentinel. For customer scenarios that are not supported, App Assure will help you identify available resources. To engage App Assure and learn more about what we support, submit a request for assistance. Partner Testimonials App Assure has already been working with many ISVs on behalf of our customers to fulfil Microsoft’s Sentinel promise. Two recent engagements where we facilitated the integration of tools that our customers rely on include: 1Password NetskopeMulti-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 Azure Resource Diagnostics Log Forwarding Between Tenants with PowerShell
As a Managed Security Service Provider (MSSP), there is often a need to collect and forward logs from customer tenants to the MSSP's Sentinel instance for comprehensive security monitoring and analysis. When customers acquire new businesses or operate multiple Azure tenants, they need a streamlined approach to manage security operations across all tenants. This involves consolidating logs into a single Sentinel instance to maintain a unified security posture and simplify management. Current Challenges: Forwarding logs across tenants can be done manually by setting up logging for each resource individually, like Storage accounts, Key Vaults, etc. using Lighthouse. However, this method is cumbersome. Automation through Azure Policy would be ideal, but it is not feasible in this case because Azure Policy is tied to managed identities. These identities are confined to a single tenant and cannot be used to push logs to another tenant. In this article, we will explore how we can forward the Azure resources diagnostics logs from one tenant to another tenant Sentinel instance using PowerShell script. High Level Architecture: Approach: Resources Creation This section describes the creation of resources necessary for log forwarding to Log Analytic Workspace. Lighthouse Enablement Refer to the below links to learn more about Lighthouse configuration for Sentinel: Managing Microsoft Sentinel across multiple tenants using Lighthouse | Microsoft Community Hub Manage Microsoft Sentinel workspaces at scale - Azure Lighthouse | Microsoft Learn Create Multitenant SPN On the customer tenant, create the multitenant application registration and sets up a client secret for it. An admin on the customer side provisions a service principal in its tenant. This service principal is based on the multitenant application that the provider created. The customer applies role-based access control (RBAC) roles to this new service principal so that it's authorized to enable the diagnostic settings on customer tenant and able to forward the logs to MSSP log analytic workspace. Required Permission: Monitoring Contributor at Customer Tenant & Log Analytic Contributor at MSSP Tenant Access Delegation Provide the Monitoring contributor role for the multitenant SPN created on step 1.2 on customer tenants to enable the logging of diagnostic settings for all the required scope of azure resources on subscription level using the azure lighthouse delegation. Delegate Log Analytic Contributor Role in the MSSP tenant to the multitenant SPN created on step 1.2 using the azure lighthouse delegation to forward the logs to Microsoft Sentinel on MSSP tenant. Logging Configuration PowerShell Script: PowerShell script used to enable logging on Azure resources across all subscriptions in the customer tenant. The solution involves the following components: - Master PowerShell Script (Mainfile.ps1): This script lists and executes child scripts for different Azure resources depending on logging requirement. - Child PowerShell Scripts: Individual scripts for enabling diagnostic settings on specific Azure resources (e.g., Child_AzureActivity.ps1, Child_KeyVault.ps1, etc.). - Configuration Script (Config.ps1): Contains SPN details, diagnostic settings, and destination Sentinel instance details. Master PowerShell Scripts Details: This file contains the list of child Azure resource PowerShell scripts that need to be executed one by one. Comment on the child file name where logging is not required. Logging Configuration PowerShell Scripts Details: This file holds SPN details like Tenant ID, Client ID, Client Secrets and diagnostic settings name and destination sentinel instance details along with logging category for each resource logs. Change the values according to the environment and as per requirement. Child PowerShell Scripts Details: Child_AzureActivity.ps1 Child_KeyvVault.ps1 Child_NSG.ps1 Child_AzureSQL.ps1 Child_AzureFirewall.ps1 Child_PublicIPDDOS.ps1 Child_WAF_AppGateway.ps1 Child_WAF_FrontDoor.ps1 Child_WAF_PolicyDiagnostics.ps1 Child_AKS.ps1 Child_StorageAccount.ps1 Execution: Run the main PowerShell script at scheduling interval, which executes the child scripts to enable diagnostic settings for various resources such as Azure Activity, Azure Firewall, Azure Key Vault, etc. Main file executes the child PowerShell scripts one by one as configured. Below is the logic of how the child file works: Import the config.ps1 file to gather information about SPN & destination Sentinel instance & logging information. Login to tenant using the SPN. Get the list of subscriptions in the tenant. Get the list of resources details (Ex.: NSG or Key vault) from each subscription one by one. Check if the diagnostic setting is enabled for the resource with certain key words. If enabled, it will skip and go to the next resource. If it is not enabled, it will enable the logging and forward the logs to the MSSP Sentinel. Expected Result & Log Verification Once the script is executed successfully, logging configuration will be enabled on Azure activity & Azure resources diagnostic settings and log will be shipped to destination Sentinel in different tenant. On MSSP Microsoft Sentinel, verify the logs have been collected properly in AzureActivity & AzureDiagnostics table. Sample PowerShell scripts: scripts/Enabling cross tenant logging using PowerShell script at main · SanthoshSecurity/scriptsCorrelating Microsoft Defender for Cloud alerts in Sentinel
Incident load is one of the major pain points of modern SOC. One of the methods used to manage alert fatigue is using grouping. In this blog post we will demonstrate a concept for correlating Microsoft Defender for Cloud alerts using Microsoft Sentinel analytics rules. This can be applied to many scenarios made possible using the new ‘Sentinel entities’ entity mapping.Microsoft Sentinel Solution for SAP® Applications - New data exfiltration detection rules
On August 2022, Microsoft Sentinel solution for SAP was made generally available (GA). Together with releasing the Microsoft Sentinel Solution for SAP® Applications, new additional OOTB content has been added. This blog covers five new data exfiltration detection rules included with the Microsoft Sentinel Solution for SAP® Applications (these rules are currently in preview).
