Microsoft Defender: Problems with correlations in Azure Sentinel
Hi community! Sharing something we've noticed this week, in case anyone else is running into the same thing. Since around October 31, several of our environments have been generating more incidents than before. Many of the automation rules we have deployed are based on the incident title, and they're now "failing" because the alert that creates the incident is being correlated and the incident is getting a different title. On top of that, I can't base these automation rules on the analytics rule name instead, because the alert comes from Defender and that condition isn't available for it in the automation rule. In addition, some incidents from Sentinel analytics rules now show Defender-generated titles, even though they contain only a single alert. For example, the rule "Office365 Sharepoint File transfer Folders above threshold" now generates an incident called "Exfiltration incident involving one user", and "PoC - Nueva aplicación popular" now generates "Suspicious activity incident". .Microsoft Sentinel - switching simple mode to kql mode in sentinel logs
In sentinel, when i go to the alert page and from there i opened the corresponding the events using Link to LA clickable link, it opens the events in simple mode. However i have configured the Logs to open it in KQL mode and every time i have to changed it to KQL mode to do the task
MC1457836 vs docs: Sentinel in unified RBAC with a service principal or GDAP. Which is it?
This is about the article https://learn.microsoft.com/en-us/defender-xdr/activate-defender-rbac, which states: Assigning permissions to a service principal or to a GDAP user group in Microsoft Sentinel isn’t supported in unified RBAC. If you need either capability, don’t activate Sentinel in unified RBAC yet. Continue using Azure RBAC for Microsoft Sentinel. Message center notice MC1457836 announces that Microsoft automatically enables unified RBAC on all tenants between late September and late December 2026, including Sentinel Reader, Responder and Contributor workspace permissions. These two statements cannot both be followed. The article tells affected customers not to activate Sentinel; MC1457836 activates it for them. This is not hypothetical for MSSPs. We operate a managed XDR service across roughly 25 customer tenants. Both unsupported capabilities are load-bearing in that model: A service principal holds Microsoft Sentinel Contributor through Azure Lighthouse and deploys analytics rules via ARM (Microsoft.OperationalInsights/workspaces/providers/alertRules). GDAP user groups are the standard delegated access route for partners. Could this be clarified: Does the service principal and GDAP limitation also apply to tenants activated through the MC1457836 automatic rollout, or does that path behave differently? If it does apply, what is the recommended action for tenants that are auto-activated before the limitation is lifted? Is deactivating the Sentinel workload after activation the supported mitigation, and is it expected to fully restore Azure RBAC behaviour for a service principal? Can a tenant be excluded from automatic Sentinel activation in advance, rather than only opting out afterwards? The article also warns that changing permissions in the Azure portal after Sentinel is active in unified RBAC may cause sync errors. For Lighthouse-delegated permissions, which are managed outside the customer tenant entirely, is that a supported configuration once Sentinel is active? A note in the “Before you begin” section describing how this limitation interacts with the automatic rollout would help partners decide whether to pre-emptively opt out.
Growing our connector ecosystem with 500+ Microsoft Sentinel connectors
Connecting the modern security environment Having spent years working across Microsoft's cloud, AI, and customer-facing organizations. I have seen that technology delivers the greatest value when it works with the environments customers already operate. That's especially true in cybersecurity. Most organizations rely on a diverse mix of platforms, applications, and security solutions. Security teams need to bring signals from across that environment together so they can understand risk, investigate threats, and respond with confidence. As a Microsoft Security customer experience leader, one of my priorities is ensuring that we're helping connect these technologies and get more value from their existing investments. When security data remains fragmented across disconnected tools, teams can lose valuable context. When that data comes together, defenders gain a more complete view of their environment and can make faster, better-informed decisions. Expanding the connector ecosystem Microsoft recently announced the Integrated Security Operations Center (ISOC) in Microsoft Defender. ISOC brings together security signals, threat intelligence, AI, and protection capabilities into a unified experience. It gives humans defenders and AI agents shared context to reason across the environment, coordinate investigations, and strengthen protection. Today, we are expanding the connector ecosystem to more than 500 connectors that enable customers to bring data from Microsoft and diverse third-party sources into their security operations experience. By connecting more signals across the technology estate, organizations can build a more complete understanding of risk and uncover relationships that might otherwise remain fragmented across separate tools. Combined with Microsoft's threat intelligence, AI, and protection capabilities, those signals become actionable context that helps human defenders and AI agents make better decisions and coordinate protection at the speed of the threat. Growing through partnership The strength of this connector ecosystem reflects the work of Microsoft and our technology partners to support our shared customers. Together, we are helping organizations connect the technologies they rely on and bring more of their security data into a unified operational experience. Below we showcase just a portion of the many partners with solutions available in Microsoft Security Store today. We remain committed to expanding this ecosystem so customers can achieve can gain broader visibility and greater value from their security investments. How to Get Started For Customers If you are a Microsoft Sentinel or ISOC customer, or considering adopting it, we are committed that you have the security connectors and integrations you need to enable your use of the platform. If an integration with an independent software vendor, or ISV solution is not yet available, or you have an issue with a solution already published, we have a dedicated team that may be able to assist by working with ISVs to build new, or update existing, connectors. If you have such a need, submit a request here. For Software Companies If you are a software development partner, the Microsoft Sentinel Codeless Connector Framework, or CCF, provides a streamlined way to bring your product into the Microsoft Security ecosystem. Use our Sentinel connector builder agent now to turn your API documentation into a working connector in just minutes. Partners can also come to us directly for engineering guidance and support in getting a connector built or improved. Reach out to us via our intake form. Building a more connected foundation for security operations Our goal is simple: help customers protect their digital environments by giving human defenders and AI agents a more complete picture of risk. We'll continue investing in connectors, partnerships, and integrated security experiences to help customers defend their organizations with greater visibility, context, and confidence. Learn More Microsoft Sentinel What is Microsoft Sentinel Empower Real-Time Security with Microsoft Sentinel’s CCF Push Feature | Microsoft Community Hub Sentinel connector hands-on labs Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough Microsoft Sentinel features in public preview Accelerate connectors development using AI agent in Microsoft Sentinel | Microsoft Community Hub Extending Sentinel Data Integration: Azure Blob Storage Support for CCF Connectors | Microsoft Community Hub Public Preview: Nested API Support Comes to Microsoft Sentinel CCF | Microsoft Community Hub Public Preview: Multi-Account Support for Microsoft Sentinel Codeless Connectors | Microsoft Community Hub
Microsoft Sentinel Armis Connector
Hi all, In our environment, we use Armis and collect Armis activity, alert, and device logs in Microsoft Sentinel. For this, we use the Microsoft-released Armis connector from Content Hub. The connector uses an Azure Function app to collect logs from Armis via the REST API. However, the connector uses the legacy HTTP Data Collector API, which Microsoft has deprecated, and support ended in September 2026. My questions: Has Microsoft released a DCR-based or CCF connector for collecting Armis logs? I couldn't find any newly released connector in Content Hub. If an issue occurs on the connector side, is Microsoft support still available, given that Microsoft hasn't released a new connector to migrate to?How to maintain and update Azure Function Connector deployed via WEBSITE_RUN_FROM_PACKAGE?
Background We recently completed a migration from the legacy Microsoft Sentinel Box connector to the newer Box Events (CCP) connector. During the migration we discovered that the legacy Box connector was implemented using: Azure Functions JWT authentication WEBSITE_RUN_FROM_PACKAGE The Function App is configured as: WEBSITE_RUN_FROM_PACKAGE=https://aka.ms/sentinel-BoxDataConnector-functionapp and the Azure Function therefore operates in read-only mode because it is running directly from the package referenced by that URL. The migration to the new Box Events (CCP) connector has been successful and is now ingesting data into BoxEventsV2_CL using Client Credentials Grant (CCG) authentication. What prompted the question While reviewing the legacy Azure Function deployment, we noticed that: The Box Solution GitHub repository has received updates over time. The Box Solution itself has been updated (currently v3.16 in our environment). Analytics, parsers, and connector components have evolved. The legacy Azure Function deployment still appears to be tied to the original package referenced by WEBSITE_RUN_FROM_PACKAGE. This raised a broader lifecycle and maintenance question: Questions 1. Is the package referenced by: https://aka.ms/sentinel-BoxDataConnector-functionapp still actively maintained and republished by Microsoft? 2. If updates are made to the Box Solution source code or supporting files in the GitHub repository, are those updates expected to flow automatically to existing Azure Function deployments that use WEBSITE_RUN_FROM_PACKAGE? 3. If updates do not automatically flow to existing deployments, what was the intended maintenance model for customers using the legacy Azure Function connector? For example, were customers expected to: Continue using the Microsoft-hosted package URL indefinitely? Periodically redeploy using updated templates? Download and self-maintain the Function App package? Modify the Function App to stop using WEBSITE_RUN_FROM_PACKAGE? 4. Prior to the introduction of the Box Events (CCP) connector, how were customers expected to apply updates, dependency changes, security fixes, and other improvements to existing Box Azure Function deployments? 5. Is migration to the Box Events (CCP) connector now considered the only supported path for customers wishing to remain current with Microsoft Sentinel Box integrations? Reason for asking The goal is not to troubleshoot the new CCP connector. Rather, we are trying to better understand the support and maintenance lifecycle of the legacy Azure Function-based Box connector and how Microsoft intended customers to remain current when deployments were originally made using a Microsoft-hosted WEBSITE_RUN_FROM_PACKAGE endpoint. Any clarification from the Box Solution maintainers or Microsoft Sentinel team would be appreciated. NB I came across this notice after following some links from the Box Solution listed in Azure. https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/known_issues.md#known-issue-2--solution-re-deployment-or-update That seems to indicate that somehow we are meant to Redeploy the entire package when there is an update and then somehow copy / update all the Custom Analytics Rules and Automations. Is there no way to merge the new modules and updates without basically having to start over with a side-by-side deployment?Manage all your Microsoft Sentinel data in one place with Unified Data Management (Public Preview)
As security teams bring in more data from more sources and use it across SIEM and XDR workflows, decisions about connector health, ingestion volume, and cost optimization get harder. Today, we’re announcing the public preview of Unified Data Management for Microsoft Sentinel, available in the new Data & connectors experience in the Microsoft Defender portal, so you can monitor and manage your data from a single place. What Unified Data Management is and why it matters Unified Data Management brings connectors, tables, and ingestion health together. Instead of moving between separate pages, you can see your full data landscape, spot issues, and act on them from one view. It’s designed to help you quickly answer questions like: Which connectors are configured and which need attention? Which tables are receiving data? Are there ingestion spikes, drops, or stale data patterns? Which tables drive the most ingestion volume? What schema, transformations, and retention settings apply to a table? You’ll find it under Setup & configuration > Data & connectors, organized into three tabs: Overview, Connectors, and Tables. Overview: See health at a glance The Overview tab gives you a workspace-level snapshot of ingestion and health, so you can catch data issues before they impact analytics, detections, investigations, or reporting. It surfaces: Ingestion volume: Daily ingestion split by Analytics tier and Data Lake tier for your selected time range. Connectors that need attention: Connectors with credential errors, ingestion failures, or outages, including error type, failure count, and last successful ingestion. Table ingestion fluctuations: Tables with unexpected volume changes, grouped into spikes and drops. Data ingestion volume by table: Your top ingesting tables, ranked by daily volume. Ingestion latency by table: How long it takes for data to become available after it’s generated. Together, these insights help you troubleshoot connector failures, track down cost spikes, validate that new connectors are flowing, and catch unexpected changes in volume. Figure 1: The Overview tab shows daily ingestion volume by tier alongside data health insights, including connectors that need attention and tables with unexpected volume spikes or drops. Connectors: One inventory for unified and classic connectors The Connectors tab puts unified data connectors and Sentinel classic data connectors side by side, so it’s easier to see which data sources are onboarded and how they're connected. From here, you can: View onboarded connectors with their status, provider, content source, and available updates. Switch between unified connectors and Sentinel classic connectors. Search and filter connectors by provider, data type, and status. Open connector details to review configuration and health. Unified connectors reduce duplication by allowing supported data sources to connect once and feed data across Microsoft security products. Sentinel classic connectors continue to support the broad connector ecosystem, including connectors built with the Codeless Connector Framework (CCF). Figure 2: The Connectors tab brings unified and Sentinel classic connectors into a single inventory, with counts for onboarded and connected connectors, available updates, and filters for provider, data type, and status. Tables: Health, schema, transformations, and retention in one place The Tables tab brings Microsoft Sentinel and Microsoft Defender XDR tables together with their health signals, schema, transformations, and retention settings. Key insights now appear right in the grid, so you can compare tables side by side: last data received, average daily ingestion volume, estimated daily ingestion cost, volume anomaly, tier, and retention settings. This makes it easier to spot tables that have gone stale, are growing unexpectedly, or are driving a big share of your ingestion volume. Select any table to open the details panel, which organizes everything about that table into tabs: Details panel tab What it shows Overview Table type, tier, analytics retention, total retention, and other table metadata. Schema Column names, data types, and descriptions, with no KQL query required. Transformations Filter, Split, and Scope Tag transformation rules applied to the table. Retention Analytics retention and total retention settings. Figure 3: The Tables tab opens a details panel for any selected table. The Schema tab is especially useful when you need to understand incoming data, validate table fields, or create transformation logic without first writing schema-discovery queries. Built for everyday data operations in the Microsoft Defender portal Data management touches nearly every part of security operations, from detection and investigation to hunting, retention, and cost optimization. By bringing these tasks into the Microsoft Defender portal, Unified Data Management cuts down on context switching and makes it clearer how connectors, tables, health, transformations, and retention fit together. It’s one more step in Microsoft Sentinel’s investment in a unified security operations experience, where SIEM and XDR data can be managed and used together. Preview availability and prerequisites Unified Data Management is now available in public preview in commercial cloud environments. To experience it, you’ll need: Microsoft Sentinel onboarded to the Microsoft Defender portal. Unified role-based access control (URBAC) enabled in the Microsoft Defender portal. Data (manage) permission in the Data Operations permission group. Workspace permissions equivalent to Log Analytics Contributor, including permissions to write workspace and table settings. Get started Ready to try it? Open the Microsoft Defender portal and go to Setup & configuration > Data & connectors. From there: Start on the Overview tab to check ingestion volume and data health. Use the Connectors tab to view your unified and classic connectors. Explore the Tables tab to review table health, schema, transformations, and retention. For implementation and configuration guidance, see: Manage data in Microsoft Sentinel and Defender Configure data connectors Manage your existing tables and data Monitor the health of your Microsoft Sentinel data connectors Unified connectors overview Microsoft Sentinel data connectors More Microsoft Sentinel data integration news Public Preview: Nested API Support Comes to Microsoft Sentinel CCF Create a pull codeless connector for Microsoft Sentinel Logs Ingestion API in Azure Monitor
Expanded cross-tenant delegated access in Microsoft Defender is generally available
Security operations rarely stop at a single tenant boundary. Managed security service providers (MSSPs) protect many customer environments, and central security teams often operate across a tenant estate spanning business units, regions, or subsidiaries. In both cases, teams need to delegate security work without granting broad access or managing permissions one analyst at a time. Today, we’re announcing the general availability of cross-tenant delegated administration in Microsoft Defender, built on the same governance relationship model as Microsoft Entra Tenant Governance. Organizations can now use a consistent governance model to establish cross-tenant relationships, delegate access to partner or central security teams, and enforce least-privilege permissions across their tenant estate. We’re also extending delegated access to support Microsoft Sentinel resources and enabling granular permissions for delegated users through Defender unified RBAC, reducing the need for separate access models across identity and security. With the consistent access model, MSSPs partners (non-CSP) and multitenant organizations can run security operations across tenants, while each customer or governed tenant decides exactly what access to grant. Govern access across your tenant estate Microsoft Entra Tenant Governance helps organizations establish least-privilege governance relationships across related tenants. The same governance relationship model now extends into Microsoft Defender and Sentinel, enabling MSSPs and central security teams to manage security operations across governed environments without requiring separate local administrator identities in each tenant. This model helps organizations: Scale without multiplying identities. Analysts use their home-tenant accounts instead of requiring local administrator or Microsoft Entra B2B guest accounts in every governed tenant. Apply least privilege. Each governed tenant controls the roles and resource scopes assigned to remote tenant groups. Simplify ongoing administration. The partner or central team keeps access current by managing membership in its own security groups rather than maintaining individual assignments across customer tenants. Support integrated security operations. MSSPs and multitenant organizations can use a consistent governance relationship to support delegated operations across Microsoft Defender and Sentinel. Bring identity and security access together. Use a consistent governance relationship model across Microsoft Entra, Defender, and Sentinel, reducing the need for separate delegated-access arrangements. One relationship, two controls A governance relationship is a directional connection between two Microsoft Entra tenants: The governing tenant is where the MSSP or central security team manages its analysts and security groups. The governed tenant is the customer or organizational tenant that grants delegated access. After the relationship is approved, selected security groups from the governing tenant are represented in the governed tenant as remote tenant groups. The governed tenant can then assign the supported roles and resource scopes those groups need, while the governing tenant continues to manage group membership. This creates a clear separation of responsibilities: tenant administrators set the access boundaries in the governed tenant, and partners or central security teams manage their analysts within those boundaries. How the relationship works The governance relationship is established through a three-step, consent-based handshake: The governed tenant sends an invitation. A customer or organizational administrator enables governance invitations in Microsoft Defender and invites the governing tenant. The governing tenant sends the relationship request. The MSSP or central security team creates an access template containing the relevant security groups and Microsoft Entra role assignments, then sends the governance relationship request. The governed tenant approves the request and assigns roles and resource scopes. The governed tenant explicitly approves the governance relationship and configures the Defender and Sentinel roles and resource scopes granted to the remote tenant groups. With approval and permissions in place, the governance relationship is ready to be used. Figure 1: The governed tenant reviews the requested role assignments and retains final approval over delegated access. The relationship provides the cross-tenant foundation. Governed-tenant administrators then apply the workload and resource permissions required for the intended security operations: For Microsoft Defender: Administrators can assign supported Microsoft Defender unified RBAC roles to remote tenant groups, including custom roles with the permissions and scopes required for the work. For Microsoft Sentinel: Customers can manage delegated access using Defender unified RBAC or Azure RBAC, assigning remote tenant groups the permissions needed to operate customer environments with least privilege. Figure 2: Assign custom roles to a remote tenant group using Defender unified RBAC. This distinction allows each governed tenant to approve the relationship and right-size access for its own environment while the governing tenant manages the analysts who perform the work. What partners are saying Partners are seeing how expanded support for delegated access can simplify cross-tenant operations and help them deliver managed security services with least privilege. “The ability to assign Azure RBAC and Defender Unified RBAC to remote tenant groups over GDAP will allow us to securely and efficiently configure and access customer environments at scale. Historically, we would need to configure a range of different access methods to access all the different services, but now we can use GDAP to access everything we need to provide managed SOC services.” — Riley Boon, Senior Capability Engineer, CyberCX “Microsoft's investments in its partner programs pay off in real outcomes for the products BlueVoyant and our customers rely on every day. Over the past several months, Microsoft has worked alongside BlueVoyant to address limitations in Granular Delegated Admin Privileges (GDAP) and deliver new capabilities, including support for assigning GDAP security groups to Sentinel workspace roles and Unified Role-Based Access Control (URBAC) support for GDAP remote tenant groups. These improvements let us manage customer environments with least-privilege access. That is what customers have been asking for and Microsoft listened.” — Ryan Sturm, Senior Manager – Microsoft Security Engineering, BlueVoyant Whether you’re onboarding your first customer tenant or consolidating access across dozens, the same model applies: tenant administrators set the boundaries, and your team works within them. Get started Start with the work your partner or central security team needs to do. Identify the eligible security groups, establish the governance relationship, and assign only the workload roles and scopes that work requires. Configure delegated access with governance relationships for multitenant organizations Manage unified role-based access control in multitenant management Create custom roles with Microsoft Defender unified RBAC Additional resources Microsoft Entra tenant governance documentation
Microsoft Defender XDR / Defender for Endpoint data connectors inconsistent failures
Hello, We are deploying our SOC (Sentinel) environments via Bicep. Now the Defender XDR ( MicrosoftThreatProtection) and Defender for Endpoint ( MicrosoftDefenderAdvancedThreatProtection) data connectors are failing to deploy inconsistantly. It seems to be a known issue due to the following posts: - https://github.com/Azure/SimuLand/issues/23 - https://techcommunity.microsoft.com/t5/microsoft-sentinel/quot-missing-consent-invalid-license-quot-defender-for-endpoint/m-p/3027212 - https://github.com/Azure/Azure-Sentinel/issues/5007 Next to this issue I see almost no development on the data connectors API, is there some news to be spread how to enable data connectors automated in the future, since it seems to be moving to Content Hub. It is hard to find any docs about how to deploy this for example via Bicep!? Also I have a question regarding 'Tenant-based Microsoft Defender for Cloud (Preview)' data connector. We deploy this now via GenericUI data connector kind, but this has no option to enable it via automation. Same as the question in the previous paragraph, how would this be made possible?Introducing the Microsoft Sentinel ASIM EmailEvent schema
Email remains one of the most common entry points for security threats. Yet email products often describe the same activity with different table names, fields, and values. This makes it harder to build detections and investigations that work consistently across data sources. The Microsoft Sentinel Advanced Security Information Model, or ASIM, EmailEvent schema is now available. It provides a common structure for email delivery and inspection events, helping customers and partners create security content that works across supported email data sources. A consistent view of email security activity EmailEvent standardizes the information analysts need to understand what happened to an email and why. It covers: Email delivery and inspection events Sender, source, and recipient information Message subject, size, direction, and delivery location URLs and file attachments SPF, DKIM, and DMARC authentication results Delivery actions such as delivered, blocked, quarantined, or deleted Threat, risk, confidence, tactic, technique, and remediation details Instead of learning a different data model for every product, analysts can query the normalized EmailEvent fields. Parser developers map each source's native data to the same schema. How it works Consider an email that contains a suspicious attachment. The email security product records the sender, recipients, attachment, authentication results, inspection verdict, and final action. A connector collects that event. A parser or Data Collection Rule maps the source fields to EmailEvent. Microsoft Sentinel can then query the normalized record using the same field names used for other supported email sources. This common structure separates security content from the details of a specific product. When another source adds an EmailEvent parser, existing source-independent queries and detections can work with that source without being rewritten around its native field names. Why it matters Simpler analytics: Write queries against one consistent set of email fields. Broader coverage: Apply source-independent security content across normalized email sources. Faster investigations: Compare delivery, authentication, attachment, URL, and threat details without translating different data models. Easier integration: Give connector and parser developers a defined contract for bringing new email telemetry into ASIM. EmailEvent does not replace the rich native data produced by email security products. It provides a consistent security layer that makes that data easier to use together. Build on EmailEvent The EmailEvent release includes the schema definition, source-independent parser framework, filtering parser, deployment templates, and validation support in the Azure-Sentinel repository. The schema version is 1.0.0. Customers can use normalized EmailEvent data to develop hunting queries, analytics rules, workbooks, and investigation experiences. Partners and community contributors can create source-specific parsers that map their email data to the schema. Get started Normalization Email Schema MS Learn Learn about normalization and ASIM Explore the EmailEvent implementation in Azure-Sentinel Deploy ASIM parsers Thank you to the ASIM engineering and partner teams who contributed to the schema, deployment path, validation, and release.
