rss.livelink.threads-in-node

Make system-generated LogARepublisher Threat Intelligence updates non-billable (_IsBillable = false)

mtwexp — Mon, 31 Aug 2026 00:26:47 GMT

Problem Statement:

Currently, Microsoft Sentinel regularly reruns an internal background process called LogARepublisher. This process periodically republishes existing Threat Intelligence data into the ThreatIntelIndicators table on an ongoing 7-to-10 day cycle to maintain freshness.

Because these system-generated updates write new records into the workspace, they are flagged as _IsBillable = true. This results in organizations paying multiple times for the exact same threat indicators over their lifecycle. In general, this is a small amount of data but can form a larger percentage of ingest/analytic cost for customers with low ingestion volumes, and becomes noticeable at scale when managing many Azure tenants.

Why This Matters:

Unintended Cost Allocation: Customers are being billed for automated, backend data-maintenance cycles triggered by Microsoft, rather than true new log ingestion or external feed consumption.

Artificial Volume Inflation: Large TI datasets can exponentially inflate monthly data volume metrics solely due to repeating republication, making budget forecasting unpredictable.

No Added Analytical Value: Rerunning the exact same indicators does not offer new security value or unique logs; it simply updates the timestamp metadata on a new row.

Proposed Solution:

Modify the backend pipeline so that when a record is ingested via LastUpdateMethod == "LogARepublisher", the system-generated metadata property _IsBillable is automatically set to false.

Customers should only be billed for the initial ingestion of a threat indicator, not for the automated system maintenance required to keep it fresh within the Sentinel ecosystem.

Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent

Robert_Moriarty — Tue, 11 Aug 2026 16:00:00 GMT

Overview

We previously announced the public preview of the Microsoft Sentinel connector builder agent via VS code extension, that helps developers build Microsoft Sentinel codeless connectors faster with low-code and AI-assisted prompts. This post walks through a hands-on lab using a mock Network Log API to demonstrate how the Sentinel connector builder agent simplifies building Codeless Connector Framework (CCF) pull connectors. Instead of manually creating ingestion infrastructure and configuration files, you’ll use a guided, conversational workflow in VS Code to generate connector artifacts, test them against a live API, and deploy them into Microsoft Sentinel. The lab focuses on the end-to-end experience ranging from API setup to validated connector deployment so you can see how quickly a working integration can be produced. For additional guidance beyond this lab, refer to our MS Learn documentation.

The Lab Environment

This lab is built around a mock Network Log API hosted as an Azure Function App. The purpose of the lab environment is to give us a live API that we can use to build, validate, and test the Sentinel CCF connector builder agent against end to end. The API exposes 50 synthetic network activity records that look and behave like a real product data source, including web traffic, DNS requests, blocked remote access attempts, malware command-and-control blocks, VPN activity, and other common network events. That makes it a useful stand-in for the type of telemetry many teams want to onboard into Microsoft Sentinel.

The API is intentionally shaped like the kind of source a customer might expose for telemetry retrieval. It uses API key authentication through the X-API-Key header, returns paginated results through a nextLink model, and provides a predictable response structure that the builder agent can map into a pull connector configuration.

The repo contains everything needed for the walkthrough. There is an ARM template to deploy the Function App, reference documentation for the API, and a sample connector package showing the generated polling config, table schema, DCR, and connector definition. The end goal of the lab is straightforward: use the builder agent to generate a CCF pull connector that ingests this API into the custom NetworkLogAPIGetNetworkLogs_CL table in Sentinel.

Prerequisites

Before starting, make sure you have the following:

Azure subscription -- with Contributor access on a resource group (for deploying the Function App) and Microsoft Sentinel Contributor access on a Sentinel-enabled workspace (for deploying the connector)

Microsoft Sentinel workspace -- an existing Log Analytics workspace with Sentinel enabled. See Onboard Microsoft Sentinel to a Log Analytics workspace for more information.

Azure CLI -- See How to install the Azure CLI for more information.

VS Code with the Microsoft Sentinel for Visual Studio Code extension installed.

GitHub Copilot -- with access to premium models. The connector builder agent requires Claude Sonnet 4.5 or 4.6, which uses Copilot premium model credits.

Lab Repository -- Once the aforementioned prerequisites are met, you can access the lab repository here: Azure-Sentinel/Tools/CCF-Connector-Builder-Agent-Accelerator at master · Azure/Azure-Sentinel

Deploying the Mock API

The full CLI commands for this section are available in the repo. For a simpler option, you can use GitHub Copilot to handle the deployment. Enter this prompt:

Follow the deployment instructions in Sentinel-CCF-Pull-Connector-Builder-Agent-Accelerator/agent-instructions.md. Let’s deploy the Network Log API and build a CCF pull connector.

At a high level, the setup is four steps: clone the repo, create a resource group, ensure you have a Sentinel-enabled workspace, and deploy the Function App using the included ARM template. The template takes two parameters: an ApiKey of your choice (the secret the CCF connector will use to authenticate) and your Log Analytics workspace resource ID for Application Insights. Deployment takes about two to three minutes and outputs the FunctionAppName and endpoint URLs you will need later.

Once deployed, verify the API is live:

curl -s -H "X-API-Key: <your-api-key>" \   "https://<functionappname>.azurewebsites.net/api/GetNetworkLogs?page=1&pageSize=3" </functionappname></your-api-key>

You should see a response like this:

The API also exposes an /api/RefreshData endpoint that regenerates the 50 sample records with fresh timestamps. This is useful later in the walkthrough when you want to produce new events and trigger an immediate ingestion cycle without waiting for the next polling interval:

curl -s -X POST -H "X-API-Key: <your-api-key>" \   "https://<functionappname>.azurewebsites.net/api/RefreshData" </functionappname></your-api-key>

Building the Connector with the Sentinel Connector Builder Agent

With the Microsoft Sentinel extension installed and GitHub Copilot running in agent mode, open a Copilot chat and enter a single prompt pointing at the API documentation file:

That is the entire invocation. The agent takes it from there. It works through a structured seven-step sequence: preparation, polling config, table schema, DCR, connector definition, package validation, and summary. The agent produces four files in a sentinel-connectors/NetworkLogAPI_CCF/ output folder:

NetworkLogAPI_PollingConfig.json – This is the API poller configuration. The agent reads the documentation and correctly identifies the GET /api/GetNetworkLogs endpoint, configures API Key authentication via the X-API-Key header, sets up NextPageUrl pagination using $.metadata.nextLink with a $.metadata.hasNextPage stop condition, and wires up the since query parameter for incremental delta pulls using the timestamp field. The RefreshData endpoint is correctly excluded, which the agent recognizes as a maintenance operation, not a security data stream.

NetworkLogAPI_Table.json – This is the custom Log Analytics table schema for NetworkLogAPIGetNetworkLogs_CL. All 20 fields from the API response are mapped to the correct column types, with timestamp promoted to TimeGenerated as the standard Sentinel time column.

NetworkLogAPI_DCR.json – This is the Data Collection Rule. This defines the stream declaration, the workspace destination, and the KQL transform that maps the raw snake_case API fields (sourceIp, destinationIp, threatIndicator, etc.) to their PascalCase table columns.

NetworkLogAPI_ConnectorDefinition.json – This is the connector UI configuration. This drives what the connector page looks like in Microsoft Sentinel: the title, description, prerequisite instructions, the BaseUrl and ApiKey input fields, sample KQL queries, and the connectivity status logic.

The only point where the agent paused for input was to propose a connector description and ask for confirmation before writing it to the file. Everything else such as endpoint selection, auth type, pagination pattern, schema mapping, KQL transform, cross-file consistency was selected autonomously.

To put that in perspective: without the agent, a developer building this connector from scratch would need to manually author four JSON files, understand the CCF schema for polling configs, DCRs, and connector definitions, write the KQL transform by hand, and validate that every cross-file reference lines up correctly. The agent compresses that work, typically hours of reading documentation, trial-and-error, and portal debugging, into a single prompt.

Testing the Connector

Before deploying anything to a Sentinel workspace, the Microsoft Sentinel connector builder agent lets you validate the generated polling config against the live API directly from your editor. Right-click the sentinel-connectors/NetworkLogAPI_CCF folder, select Microsoft Sentinel → Test Connector (Preview), and a Configuration Variables panel opens asking for the two template variables from the polling config: BaseUrl and apiKey. For other API patterns, there may be additional and different inputs. For example, apiKey input could be swapped with clientID and secret if the API supports OAUTH.

Enter the Function App base URL and your API key, and the test runner connects immediately. The panel shows a live polling session. Poll #1 returns HTTP 200 with 50 events, and a countdown timer shows when the next poll will fire. Switching to the Events tab displays the ingested records in a tabular view with columns for timestamp, severity, action, bytesIn, bytesOut, category, and the rest of the mapped fields fresh from the API. Additionally, there are tabs for Headers, Payload, and Response, which can be useful for verifying that your pollerconfig.json configuration provides the expected request to your api with a working response.

Data Extracted:

The Test Connector feature can be used to visualize the response data in a table format to verify that data will land in a Sentinel table based on your configuration.

Request from Poller:

The Test Connector feature can be used to validate the request and response headers that will go out to the API based on the generated poller configuration.

Request Response:
The Test Connector feature shows you the live response from the API with respect to the request going to the API based on the poller configuration.

This is a meaningful pre-flight check. It confirms that auth is working, the $.data events path resolves correctly, pagination is functional, and the polling interval fires as configured all before a single file is deployed to Azure. The most common connector configuration issues (wrong base URL, incorrect header name, mismatched JSON path) surface here in seconds rather than after a failed deployment and a 20-minute wait for Sentinel to attempt its first ingestion cycle. It is also the fastest way to troubleshoot if something goes wrong after deployment, far quicker than pushing changes to Azure and waiting for the connector to poll again.

Deploying and Enabling the Connector

With the connector tested and passing, deployment is the same right-click menu: right-click the sentinel-connectors/NetworkLogAPI_CCF folder, select Microsoft Sentinel → Deploy Connector (Preview). If you are not already signed in to Azure, the extension will prompt you to authenticate. The agent will also provide a clickbox in the chat window to invoke a connector deployment.

Right Click Deploy Connector:

UI Prompt Based Deploy Method:

Once signed in, a workspace picker lists all available Log Analytics workspaces across your subscriptions. Select the one with Sentinel enabled and click Deploy. The extension deploys all four files to the workspace in the correct order: table schema first, then DCR, polling config, and connector definition.

Once deployed, navigate to your Sentinel workspace via https://security.microsoft.com, go to Data Connectors, and find the Network Log API connector. The connector page shows the description, prerequisite notes, and the two credential fields generated by the agent: API Base URL and API Key. Enter your Function App base URL and API key and click Connect. The status updates to show the connector is connected and the deployment succeeded.

Note: Data will appear in the workspace within 5 to 30 minutes depending on the polling interval. Run this query in Log Analytics to confirm ingestion. Note that the agent derives the table name from the vendor name and endpoint, so yours may differ slightly from the example below. Check the agent's summary output or the NetworkLogAPI_Table.json file for the exact name:

NetworkLogAPIGetNetworkLogs_CL | sort by TimeGenerated desc | take 10

If you want to generate a fresh batch of events immediately rather than waiting for the next polling cycle, use the RefreshData endpoint to reset the sample records with new timestamps:

curl -s -X POST -H "X-API-Key: " \   "https://.azurewebsites.net/api/RefreshData"

Next Steps

If you want to go further:

Try it with your own API. The lab repo includes documentation on adapting the polling config, schema, and KQL transform to a real data source.
Review the CCF connector schema documentation to understand the full range of supported configurations: pagination patterns, auth types, incremental pull strategies, and delta filter expressions.
Explore the Microsoft Sentinel content hub to see how published connectors are structured and what the certification requirements look like for production submissions.

Conclusion

Following these steps, you saw how a working Sentinel connector can be generated, tested, and deployed in minutes rather than requiring days of manual configuration and infrastructure setup. If you are an ISV building a Sentinel integration and want hands-on support, Microsoft’s App Assure program is available to help. We partner with ISVs on connector development, validation, and deployment and provide guidance through implementation, testing, and readiness for production. You can get started by reaching out through our intake form.

See our other Sentinel connector feature’s hands-on labs

Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough

AI-powered playbook generator, now available to more customers

NoaCafri — Fri, 07 Aug 2026 19:28:40 GMT

We’re excited to announce we’re making it easier than ever to go from intent to action with the AI-powered playbook generator now available to more customers.

What’s new

All Microsoft Sentinel customers in Defender portal can now create AI-generated playbooks directly in their automation workflow. As part of this change, Security Copilot enablement is no longer required: playbook generator is now available to more teams out of the box and without any extra cost.

What playbook generator does

Playbook generator uses AI to turn what you want to automate into a working playbook. Instead of hand-building automation in python code, describe the response you need in natural language and get an editable playbook, its tests and documentation generated for you right inside the Microsoft Defender portal.

Faster response automation: go from idea to playbook in minutes.

Built into your workflow: find it under Automation › + Create › Playbook Generator.

Fully editable: generated playbooks are code-based, complete with tests, documentation and visual flow, that you can review and refine.

Who is it for

If you’re using Microsoft Sentinel in your Defender portal, the playbook generator is now within reach. This expansion brings AI-assisted playbook creation to significantly more security teams.

How to get started

Ensure you have the right permissions

To build and deploy generated playbooks, make sure You have the Automation Playbooks Unified RBAC permission with Read and Write access.

Open Microsoft Defender Portal and go to Automation.
Select + Create › Playbook Generator.
Describe the playbook you want to create.
Review, edit, and deploy.

Automatically created visual diagram of the playbook.Phyton code created by playbook generator.

Availability

General availability: Already available.
Cost: Included with Microsoft Sentinel - no additional charge.

Try Playbook Generator in your Microsoft Defender Portal today.

Smarter signals, broader coverage: UEBA anomalies on top of Behaviors layer and new data sources

SaraSamokovlija — Tue, 18 Aug 2026 18:39:45 GMT

Co-authors: Ron Shlomo and Ryan Smith

Security teams don't struggle with a lack of security signals. The real challenge is understanding which activity matters, why it stands out, and where to focus first.

Microsoft Sentinel's Behaviors layer already helps analysts transform raw security events into meaningful behavioral patterns. Today, we're making that experience both smarter and broader.

What if every behavior could immediately tell you not only what happened, but why it matters? We're bringing UEBA anomaly intelligence directly into the Behaviors layer, so every behavior now includes anomaly insights together with explainable context. At the same time, UEBA expands beyond identity signals to support network and cloud data sources, enabling richer behavioral insights across more of your environment and helping security teams detect suspicious activity wherever it occurs.

If you're new to these capabilities, we recommend reviewing our previous announcements on the UEBA expansion and the Behaviors public preview, which provide additional background on the Behaviors layer and its underlying UEBA capabilities.

What's new in Sentinel UEBA and Behaviors layer

Microsoft Sentinel’s Behaviors layer aggregates and sequences individual events into meaningful behavioral patterns, giving SOC teams the security context of who did what to whom and why it matters in one place, instead of sifting through raw telemetry in separated tables.

With this release, we're expanding the Behaviors layer. It now includes UEBA Anomalies and contextual enrichments directly within each behavior. In addition, the Behaviors layer now supports Fortinet logs via the CommonSecurityLog table. We're also expanding Classical UEBA beyond identity signals by adding support for network and cloud data sources: AWS GuardDuty, Check Point, Zscaler and Fortinet (via CommonSecurityLog). Together, these enhancements allow the SOC to receive a richer context and explainable anomaly detection for every behavior across a broader portion of the environment.

Adding context to every behavior—use case

The following example illustrates how UEBA Anomalies on Behaviors help analysts quickly identify suspicious activity by adding context to every behavior.

Scenario: Detecting a compromised FortiGate device

An attacker gains administrative access to a FortiGate firewall and begins making configuration changes to establish persistence and enable future access. Individually, each action may appear legitimate. Together, however, they form a potentially suspicious behavioral pattern. UEBA then layers anomaly insights and explainability on top of these Behaviors, providing the additional context needed to identify suspicious activity.

Examples of observed behaviors include:

Firewall administrator signs in from a new geographic location.
Configuration changes occur outside normal maintenance windows.
A new administrator account is created.
VPN settings or firewall rules are modified to enable new access paths.
Unusual outbound traffic is detected through the FortiGate device.

Rather than presenting these as isolated events, UEBA enriches each behavior with anomaly insights and explainable context. Analysts can immediately understand why the activity stands out. For example, because the administrator has never performed this combination of actions before, the changes occurred at an unusual time, and multiple high-risk modifications happened within a short period. This helps security teams quickly identify high-risk activity, reduce investigation time, and respond before attackers can expand their access within the environment.

KQL examples

//Query 1: Logon and Configuration Change by user for the first time BehaviorInfo | where Timestamp > ago(30d) | where ActionType == "BehaviorFortiGateReconfiguration" | where Insights has "FirstSeen" | extend AdditionalFields = todynamic(AdditionalFields) | extend Hostname = AdditionalFields.ApplianceId | extend User = AdditionalFields.ChangedBy[0] | extend uebaEnrichments = AdditionalFields ["ueba.enrichments"] | extend uebaInsights = todynamic(Insights).Explainability | project ActionType, Description, Categories, AttackTechniques, ServiceSource, DataSources, User, Hostname, AdditionalFields, uebaInsights, uebaEnrichments //Query 2: get HighVolumeAnomaly behaviors to detect high traffic for the suspicious host / IP BehaviorInfo | where Timestamp > ago(30d) | where DataSources has "CommonSecurityLog" | invoke GetAnomalousBehaviorsByValue( "<Hostname>", //Extracted from Hostname in query 1 "HighVolumeAnomaly")

Expanding visibility scross the environment—use cases

The following examples show how the new network data sources extend Behavioral analytics and UEBA Anomalies, helping uncover suspicious activity across more of your environment.

Scenario: Identifying suspicious web access with Zscaler telemetry

A user attempts to access a URL categorized as phishing, malware, spyware, or command-and-control. On its own, the event may appear as just another web-proxy log among thousands generated every day.

With Zscaler telemetry incorporated into behavioral analytics, UEBA identifies that the user has never accessed this high-risk URL category before and enriches the activity with user, destination, source IP, location, ISP, and threat intelligence context, helping analysts immediately understand why the event stands out. Rather than investigating an isolated web access event, analysts can quickly determine whether the activity indicates a phishing attempt or attacker-controlled infrastructure and respond before the compromise spreads.

KQL example

//Query 3: First-time high-risk web category access from an unusual location or ISP Returns phishing, malware, spyware, or C2 category hits that are new for the user and come from an unusual location or network. Check RequestURL and UrlCategory for the destination. BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "CommonSecurityLog" | where ActivityType == "UnusualHighRiskWebCategoryAccess" | where ActivityInsights.DeviceVendor == "Zscaler" | where ActivityInsights.DeviceProduct == "NSSWeblog" | extend UrlCategory = ActivityInsights.UrlCategory | extend RequestURL = ActivityInsights.RequestURL | extend ISP = DevicesInsights.ISP | extend ThreatIntel = DevicesInsights.ThreatIntelIndicatorType | extend RiskyCategory = ActivityInsights.FirstTimeUserAccessedHighRiskUrlCategory == True or ActivityInsights.FirstTimeHighRiskUrlCategoryObservedInTenant == True | extend UnusualLocation = ActivityInsights.FirstTimeUserConnectedFromCountry == True or ActivityInsights.FirstTimeConnectionFromCountryObservedInTenant == True or ActivityInsights.CountryUncommonlyConnectedFromByUser == True | extend UnusualISP = ActivityInsights.FirstTimeUserConnectedViaISP == True or ActivityInsights.ISPUncommonlyUsedByUser == True or ActivityInsights.IPRegOrgUncommonlyUsedByUser == True | where RiskyCategory and (UnusualLocation or UnusualISP or isnotempty(ThreatIntel))

The following example illustrates how Behaviors built on top of new network data source help analysts identify sensitive administrative activity that might otherwise appear routine.

Scenario: Identifying suspicious FortiGate configuration backups

A network administrator exports a FortiGate configuration backup. On its own, this action is common during maintenance, upgrades, or disaster recovery and is unlikely to trigger immediate investigation.

With Behaviors built on top of Fortinet telemetry, Microsoft Sentinel transforms this raw administrative event into a meaningful security context. Analysts can immediately see who performed the backup, which device was involved, how it was executed (GUI, API, RESTAPI, ssh or CLI), and whether the activity deviates from the user's normal behavior or occurred alongside other suspicious activity.

Instead of reviewing isolated firewall events, analysts can quickly determine whether the configuration export is part of legitimate administration or an early indicator of compromise, reconnaissance, or preparation for persistence.

KQL example

// Query 4: FortiGate configuration backup activity BehaviorInfo | where ActionType == "BehaviorFortiGateBackup" | extend ParsedData = parse_json(AdditionalFields) | extend Device = tostring(ParsedData.ApplianceId), User = tostring(ParsedData.Account), SourceIP = tostring(ParsedData.LoginSourceIP) | project TimeGenerated, Device, User, SourceIP, Description, AdditionalFields | order by TimeGenerated

Getting started

In the Microsoft Defender portal, make sure the Behaviors layer is enabled and supported data sources are connected
Baselines are built for approximately one week for high-quality anomalies.
Explore the insights column in the BehaviorInfo table in Advanced Hunting.
Enabling the new data sources for UEBA and Behaviors layer:

UEBA user interface.

We’d love to hear how your team is using these capabilities. Share your feedback to help us improve and expand coverage.

Why it matters

These updates represent another step in our commitment to making Behaviors and UEBA in Microsoft Sentinel more powerful, more explainable, and more broadly applicable across the environments your security team defends.

Public Preview: Nested API Support Comes to Microsoft Sentinel CCF

Robert_Moriarty — Fri, 07 Aug 2026 17:15:55 GMT

Microsoft Sentinel continues to evolve its capabilities to support an expanding ecosystem of partners and data integrations. Recent innovations include the Codeless Connector Framework (CCF) Push feature, the new Sentinel connector builder agent, and the CCF expansion to pull data from Azure Storage Blob. Each of these reflects our ongoing investment in making it easier for ISVs and developers to build scalable, high-fidelity data connectors that bring telemetry into Sentinel data lake.

Today, we are excited to announce another advancement in this journey – the public preview for Nested API support in CCF.

What is Nested API support and Why it Matters

Nested API support enables a pattern common across many ISV log sources, where a single polling cycle spans multiple dependent API calls: an initial call returns a list of records (such as alert IDs or case references), and one or more follow-up calls fetch the full detail for each record in that list.

This support allows CCF to accommodate the list-then-detail API pattern as it exists in many API designs, so that partners don’t need to restructure or adapt their endpoints. The result is broader integration coverage that allows partners to connect data sources whose APIs are naturally paginated across multiple calls, and then to ingest complete records into Microsoft Sentinel without building custom middleware.

Support for Nested API in the Microsoft Sentinel VS Code extension

This pattern is also available through the Visual Studio Code (VS Code) extension for Microsoft Sentinel connectors. The extension is an agentic tool that helps ISVs and partners build, test, and package data connectors more efficiently, providing a guided experience for bringing data into Microsoft Sentinel.

As part of its design, the extension enables developers to implement Nested API workflows, allowing connectors to orchestrate multi-step API calls and support APIs that require chained or dependent requests. To learn more, see the Sentinel connector builder agent blog and the Microsoft Learn documentation for implementation guidance.

Real-world adoption: Early ISV implementations

A growing set of solutions are already leveraging Nested API support to enable multi-step data retrieval scenarios. These early implementations demonstrate how partners are using this capability to structure connector workflows around their existing APIs. Some of the early adopters and their solutions are listed below.

BigID

BigID integrates with Microsoft Sentinel to extend data security posture management (DSPM) insights into security operations workflows. The solution brings visibility into sensitive, regulated, and critical data across cloud, SaaS, and on‑premises environments, helping security teams understand data‑related risk and exposure. Built on the Codeless Connector Framework (CCF), the integration can leverage capabilities such as Nested API retrieval to ingest more detailed, context‑rich records through multi‑step API calls, supporting more informed investigation and prioritization.

Cisco Email Threat Defense

Cisco Email Threat Defense integrates with Microsoft Sentinel to bring email‑borne threat detections into centralized security operations. The connector ingests all information that can be used as security signals, such as phishing and malware indicators, enabling teams to correlate email activity with broader incidents and improve investigation and response. Built on the Codeless Connector Framework (CCF), the integration supports advanced patterns like Nested API retrieval, allowing more detailed event context to be ingested through multi‑step API calls without requiring changes to the underlying data source.

Idira Audit

Idira® Audit by Palo Alto Networks integrates with Microsoft Sentinel to centralize visibility into privileged identity and access activity. By streaming detailed audit logs—covering system events, user actions, and administrative activity—into Sentinel, security teams can correlate identity‑driven risks with broader security telemetry. Built on the Codeless Connector Framework (CCF), the integration can leverage capabilities such as Nested Application Programming Interface retrieval to ingest more detailed, context‑rich records, supporting faster investigation and more effective response.

In addition to these early third-party adopters, some Microsoft-built connectors that also leverage this pattern are listed below:

Build with Nested APIs in Microsoft Sentinel

Developers and partners can begin leveraging Nested API support today as part of the Codeless Connector Framework. To get started, review the Microsoft Learn documentation for implementation guidance and explore existing connector configurations that demonstrate this pattern. You can also jump right in and explore building with mock data using our Nested API Lab.

As Microsoft Sentinel continues to expand its ecosystem, App Assure works closely with partners to help onboard and optimize integrations. If you are building or extending a connector and would like support, the App Assure team is available to help you get started. Reach out to us via our intake form.

Additional Sentinel Feature Public Preview Announcements

Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough

Robert_Moriarty — Wed, 05 Aug 2026 16:00:00 GMT

This post walks through building a Microsoft Sentinel Codeless Connector Framework (CCF) RestApiPoller connector that uses the nested API polling pattern. The nested pattern exists for a specific reason: many enterprise APIs do not return enriched records from a single call. Instead, they use a two-step model: a list endpoint that returns identifiers, followed by a detail endpoint that accepts one identifier and returns the full record. Without native support for this pattern, building a Sentinel connector for such an API means writing custom orchestration in code. The CCF nested pattern re places that with a JSON configuration that the engine handles directly.

The lab is built around a mock Contoso Incident API hosted as an Azure Function App. The purpose is to give you a live API you can deploy, inspect, and connect to Sentinel without needing a real product. Once deployed, you will walk through each of the four connector files that make up the integration (the poller config, the DCR, the table schema, and the connector definition) and see exactly how the two-call chain is wired together. By the end of the walkthrough, you will have a working connector ingesting enriched incident records into ContosoIncidents_CL in your Sentinel workspace.

Lab repository: CCF Pull Connector - Nested API Accelerator: clone the repository, then deploy the mock API and connector with a single Copilot prompt. See the README for full instructions. (link to be confirmed on merge)

Related documentation: CCF Nested API Polling Reference

Quick Start

Already familiar with CCF nested polling?

Complete these sections:

Prerequisites
Deploying the Mock API
Deploying the Sentinel Connector
Enabling and Verifying Data

The remaining sections explain how the nested polling configuration, KQL extraction, DCR transform, and connector artifacts work behind the scenes.

Prerequisites

Before starting, make sure you have the following:

Azure subscription with Contributor access on a resource group for deploying the Function App, and Microsoft Sentinel Contributor on a Sentinel-enabled workspace for deploying the connector
Microsoft Sentinel workspace: an existing Log Analytics workspace with Sentinel enabled (Quickstart: Onboard Microsoft Sentinel)
Azure CLI (Install the Azure CLI) installed and authenticated
VS Code with GitHub Copilot installed if you want to use the one-prompt agent deployment option
Lab repository: clone the CCF Pull Connector - Nested API Accelerator repository locally

The Lab Environment

The mock Contoso Incident API exposes exactly the two-endpoint pattern the nested connector is designed for. The list endpoint returns a set of incident identifiers scoped to a time window. The detail endpoint accepts a single identifier and returns the full enriched record for that incident. There is no way to get the full records in a single call; you have to ask for them one at a time.

A call to the list endpoint looks like this:

{ "incidents": [ { "incidentId": "INC-001" }, { "incidentId": "INC-002" }, { "incidentId": "INC-003" }, { "incidentId": "INC-004" }, { "incidentId": "INC-005" } ] }

And a call to the detail endpoint for INC-00 returns:

{ "incidentId": "INC-001", "title": "Suspicious login attempt", "severity": "High", "status": "Active", "affectedUser": "alice@contoso.com", "sourceIp": "198.51.100.42", "createdAt": "2026-05-30T14:22:00Z" }

So for every polling cycle the connector needs to call the list endpoint once, extract the five incidentId values, and then call the detail endpoint five times. That fan-out logic (taking a value from the first response and injecting it into the URL for each subsequent call) is what the nested step configuration handles. The repo contains everything needed for the walkthrough: an ARM template to deploy the Function App, the four connector artifact files, and a solution package that deploys the connector into Sentinel.

Deploying the Mock API

The quickest way to deploy is to open Copilot Chat in Agent mode in VS Code and paste:

Load and follow the deployment instructions at Tools/CCF-Pull-Connector-Nested-Accelerator/agent-instructions.md. Let's deploy a CCF nested API connector.

The agent reads the deployment instructions, collects the values it needs, generates names for anything you do not provide, and deploys end-to-end. The only manual action in the entire flow is clicking Connect in the Sentinel portal once the ARM template has been deployed.

If you prefer to deploy manually, the steps are straightforward. Create a resource group, deploy the Function App using the included ARM template, zip the MockApi/ folder and push the code, then retrieve the Function App API key:

az group create --name contoso-mock-api-rg --location eastus az deployment group create ` --resource-group contoso-mock-api-rg ` --template-file "Tools/CCF-Pull-Connector-Nested-Accelerator/MockApi/azuredeploy_MockApi.json" ` --parameters FunctionAppName=ContosoMockApi Location=eastus $outputs = az deployment group show ` --resource-group contoso-mock-api-rg --name azuredeploy_MockApi ` --query properties.outputs -o json | ConvertFrom-Json $functionAppName = $outputs.functionAppName.value $mockApiBaseUrl = $outputs.mockApiBaseUrl.value Compress-Archive -Path "Tools/CCF-Pull-Connector-Nested-Accelerator/MockApi/*" -DestinationPath contosoapi.zip -Force az functionapp deployment source config-zip --name $functionAppName --resource-group contoso-mock-api-rg --src contosoapi.zip $apiKey = (az functionapp keys list --name $functionAppName --resource-group contoso-mock-api-rg --query functionKeys.default -o tsv).Trim()

Once deployed, verify both endpoints are responding before moving on:

Invoke-RestMethod "$mockApiBaseUrl/incidents" -Headers @{"x-functions-key" = $apiKey} Invoke-RestMethod "$mockApiBaseUrl/incidents/INC-001/details" -Headers @{"x-functions-key" = $apiKey}

How the Nested Step Pattern Works

The entire two-call chain lives inside ContosoIncidents_PollerConfig.json. Here is the full config:

{ "type": "Microsoft.SecurityInsights/dataConnectors", "kind": "RestApiPoller", "properties": { "connectorDefinitionName": "ContosoIncidentsConnector", "dataType": "ContosoIncidents_CL", "dcrConfig": { "streamName": "Custom-ContosoIncidents_CL", "dataCollectionEndpoint": "{{dataCollectionEndpoint}}", "dataCollectionRuleImmutableId": "{{dataCollectionRuleImmutableId}}" }, "auth": { "type": "APIKey", "ApiKey": "{{ApiKey}}", "ApiKeyName": "x-functions-key" }, "request": { "apiEndpoint": "{{mockApiBaseUrl}}/incidents", "httpMethod": "GET", "queryWindowInMin": 5, "queryTimeFormat": "yyyy-MM-ddTHH:mm:ssZ", "startTimeAttributeName": "startTime", "endTimeAttributeName": "endTime", "headers": { "Accept": "application/json" } }, "response": { "eventsJsonPaths": [ "$.incidents" ], "format": "json" }, "stepInfo": { "stepType": "Nested", "nextSteps": [ { "stepId": "fetchIncidentDetails", "stepPlaceholdersParsingKql": "source | project res = parse_json(data) | project incidentId = res.incidentId" } ] }, "stepCollectorConfigs": { "fetchIncidentDetails": { "shouldJoinNestedData": false, "request": { "httpMethod": "GET", "apiEndpoint": "{{mockApiBaseUrl}}/incidents/$incidentId$/details", "headers": { "Accept": "application/json" } }, "response": { "eventsJsonPaths": [ "$" ], "format": "json" } } } } }

The request block at the top defines the parent call, the list endpoint. On every polling cycle the CCF engine calls GET /incidents with startTime and endTime query parameters derived from queryWindowInMin: 5. The response.eventsJsonPaths: ["$.incidents"] tells the engine where to find the data in the response; it walks to the incidents array and treats each element as a separate row.

Those rows do not go to the DCR. Instead, because stepInfo.stepType is set to "Nested", the engine passes each row to the stepPlaceholdersParsingKql expression before doing anything else.

The KQL That Links the Two Calls

This is the most important line in the entire connector:

source | project res = parse_json(data) | project incidentId = res.incidentId

Each row from the list response arrives as raw JSON in a column called data. The parse_json(data) call converts that string into a dynamic object so individual fields can be addressed. The final project extracts incidentId and gives it a column name. That column name, incidentId, is not arbitrary. It must exactly match the $incidentId$ token in the child endpoint URL. The engine reads the output of this expression, takes every value in the incidentId column, and substitutes it into the URL for the next step.

For the Contoso API this produces five values (INC-001 through INC-005), and the engine issues five parallel GET requests:

GET /api/incidents/INC-001/details GET /api/incidents/INC-002/details GET /api/incidents/INC-003/details GET /api/incidents/INC-004/details GET /api/incidents/INC-005/details

Each of those calls returns a full incident record. The eventsJsonPaths: ["$"] in the child response block captures the entire response body as a single event. Those five events are what get sent to the DCR stream, not the five lightweight rows from the list call.

shouldJoinNestedData

The shouldJoinNestedData: false setting on the child step tells the engine not to merge the parent row's fields into the child row before sending to the DCR. In this case the detail response already contains incidentId and all other required fields, so there is nothing to carry forward from the parent. If your list endpoint returns fields that are not present in the detail response (a category, a tenant identifier, a product namespace), setting this to true will merge them in automatically.

The DCR and the KQL Transform

The Data Collection Rule handles what happens to each detail response once it arrives at the Data Collection Endpoint. The streamDeclarations block defines the inbound schema (the shape of the data the CCF engine sends), and the transformKql maps it to the destination table columns.

The transform for this connector is:

source | extend TimeGenerated = now() | project TimeGenerated, IncidentId = ['incidentId'], Title = ['title'], Severity = ['severity'], Status = ['status'], AffectedUser = ['affectedUser'], SourceIp = ['sourceIp']

The extend TimeGenerated = now() sets the ingestion timestamp. The mock API returns a createdAt field on every detail record, but it is not used here; TimeGenerated reflects when the record was received by the pipeline rather than when the incident was created on the source system. The project operators rename each snake_case field from the API response to the PascalCase column names defined in the table schema.

The column names produced by transformKql must exactly match the column names in ContosoIncidents_Table.json. A mismatch causes rows to be silently dropped at ingestion with no error surfaced to the connector status page, which makes it one of the more frustrating issues to debug after the fact.

The Table Schema and Connector Definition

Before looking at the connector definition, it helps to understand what the table object itself is. ContosoIncidents_Table.json deploys a Microsoft.OperationalInsights/workspaces/tables resource, the same resource type that creates any custom log table in your Log Analytics workspace. Its schema block is an array of column definitions, each with a name, a type, and a description:

"schema": { "name": "ContosoIncidents_CL", "columns": [ { "name": "TimeGenerated", "type": "datetime", "description": "Ingestion timestamp." }, { "name": "IncidentId", "type": "string", "description": "Unique identifier of the incident (e.g. INC-001)." }, { "name": "Severity", "type": "string", "description": "Incident severity: Critical, High, Medium, or Low." } ] }

This is the definition that shows up when you query the table. Each column name becomes a field you can reference directly in KQL, and each column type determines how that field behaves when you filter or aggregate on it. TimeGenerated being a datetime is what lets you sort or filter with operators like ago() and between.

The table schema in ContosoIncidents_Table.json defines ContosoIncidents_CL with seven columns: TimeGenerated, IncidentId, Title, Severity, Status, AffectedUser, and SourceIp.

The connector definition in ContosoIncidents_ConnectorDefinition.json drives the portal UI. It defines the connector page title and description, the ingestion activity graph, the sample KQL queries that are surfaced to analysts directly from the connector page, and the connectivity check query that determines whether the connector shows as Connected or Disconnected in the Data Connectors blade. The two Textbox inputs in the instructionSteps block (mockApiBaseUrl and ApiKey) are what feed the {{template}} variables in the poller config when a user clicks Connect. Getting those input names right is what makes the credential handoff from the portal to the connector work without manual intervention.

Deploying the Sentinel Connector

With the mock API running, deploy the Sentinel connector solution using the included mainTemplate.json. The template creates the Data Collection Endpoint, the ContosoIncidents_CL table, the DCR, the poller config, and the connector definition in the correct dependency order.

If you would rather not use the CLI, you can deploy the same template through the Azure portal. Open the Custom deployment blade, choose "Build your own template in the editor," and paste in the contents of mainTemplate.json, then fill in the parameters (workspace, workspace-location, and so on) through the generated form instead of a parameters file. See Deploy template - Azure portal - Azure Resource Manager for the full walkthrough. The CLI steps below are the faster path if you already have the CLI authenticated, but the portal works just as well.

The workspace-location parameter requires special handling because the hyphen in the parameter name causes issues when passed inline to the Azure CLI. Write a parameters file first, then reference it with @:

@{ '$schema' = 'https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#' contentVersion = '1.0.0.0' parameters = @{ workspace = @{ value = '<your-workspace-name>' } 'workspace-location' = @{ value = '<region>' } } } | ConvertTo-Json -Depth 5 | Out-File deploy-params.json -Encoding utf8 az deployment group create ` --resource-group <sentinel-workspace-rg> ` --name mainTemplate ` --template-file "Tools/CCF-Pull-Connector-Nested-Accelerator/ContosoIncidents/Package/mainTemplate.json" ` --parameters "@deploy-params.json" ` --output table</sentinel-workspace-rg></region></your-workspace-name>

The workspace-location value must exactly match the region string returned by az monitor log-analytics workspace show --query location for your workspace.

Enabling and Verifying Data

The ARM deployment registers the connector definition but does not start data collection. To start polling you need to click Connect once in the portal. Navigate to your Sentinel workspace via security.microsoft.com, go to Data Connectors, and find Contoso Incidents (CCF Nested API Accelerator). If it is not immediately visible, click Refresh and wait two to three minutes for the deployment to propagate.

Open the connector page and under STEP 2 - Connect to the Contoso Mock API, enter the mockApiBaseUrl from the deployment output and the ApiKey retrieved earlier, then click Connect. The CCF engine begins polling immediately.

Allow five to ten minutes for the first poll cycle to complete, then confirm data is arriving:

ContosoIncidents_CL | sort by TimeGenerated desc | take 10

You should see five rows, one per mock incident, with all columns populated. From there you can use the sample queries built into the connector page to start exploring the data:

// High and Critical incidents ContosoIncidents_CL | where Severity in ('Critical', 'High') | sort by TimeGenerated desc // Active incidents with source IP ContosoIncidents_CL | where Status == 'Active' | project TimeGenerated, IncidentId, Title, Severity, AffectedUser, SourceIp

Adapting This Pattern to Your Own API

The nested pattern is reusable for any two-tier REST API. The changes needed to adapt the accelerator are mechanical: replace the parent endpoint and update eventsJsonPaths to point to your identifier array, rewrite the stepPlaceholdersParsingKql to extract your identifier field (the column name in the final project must match the $token$ in your child URL), replace the child endpoint URL, and update the DCR stream declaration, transform, and table schema to match your detail response fields.

The shouldJoinNestedData flag is worth thinking through for your specific case. If your list endpoint returns context that is not replicated in the detail response (a tenant ID, a data source label, a parent category), set it to true and those fields will be merged into every child row automatically before it reaches the DCR.

Next Steps

Review the CCF Nested API Polling Reference for the full specification of stepInfo, stepCollectorConfigs, shouldJoinNestedData, and multi-level nesting: CCF Nested API Polling Reference

Review the codeless connector documentation for the full range of supported auth types, pagination patterns, and incremental pull strategies: Create a codeless connector

Explore the Microsoft Sentinel content hub to see how published connectors are structured and what the certification requirements look like for production submissions.

Conclusion

Following these steps, you saw how a CCF nested API connector works at the configuration level: how the stepPlaceholdersParsingKql expression extracts identifier values from the list response, how those values are substituted into the child endpoint URL to produce per-record detail calls, and how the DCR transform maps the raw API fields into a clean Sentinel table. The pattern is deliberately simple to adapt: the KQL expression and the $token$ in the URL are the only two moving parts that link the two calls together.

If you are an ISV building a Sentinel integration and want hands-on support, Microsoft's App Assure program is available to help with connector development, validation, and readiness for production. You can get started by reaching out through our intake form.

What’s new in Microsoft Sentinel: July 2026

vkokkengada — Fri, 31 Jul 2026 16:00:00 GMT

Welcome back to What's new in Microsoft Sentinel. In July, Sentinel adds custom detections support in Sentinel repositories, so you can manage detections as code alongside your analytics rules, playbooks, parsers, and workbooks, authoring in GitHub and deploying through the CI/CD pipelines you already use. In Sentinel data lake, table insights brings table-level observability into the Microsoft Defender portal, helping you track ingestion volume, spot week-over-week changes, and catch connectors that have gone silent, all without running a single KQL query. Connector coverage also expands with GitHub Audit logs, Agari, and Airlock Digital, bringing more of the signals that matter to you into one place.

Read on for the details, and if you're joining us at Black Hat USA 2026, don't miss the keynote from Agentic Security CVP David Weston and other Microsoft Security activities at this event. Explore our resources at the end to go deeper.

Sentinel innovations:

Sentinel SIEM
Sentinel data lake

Sentinel SIEM

Custom detections support in Sentinel repositories [Public Preview]

Custom detections can be managed as code through Sentinel repositories, alongside analytics rules, playbooks, parsers, and workbooks, completing the detections-as-code workflow across the full Sentinel portfolio. Teams can author detections in GitHub, review through pull requests, and deploy via existing CI/CD pipelines or the Microsoft Security Bicep extension. Learn how to manage custom content with repository connections.

Behind the Build with Gigamon: Enriching Sentinel with network-derived telemetry

Learn how Gigamon's integration with Sentinel brings network-derived telemetry into your security investigations, correlated with the identity, endpoint, and cloud signals already in your workspace. By adding this runtime context, you can trace suspicious activity across environments and investigate threats that span traditionally siloed domains, with faster and more accurate investigations, higher-quality signal, and clearer visibility into encrypted and hybrid cloud traffic that logs alone often miss. Read the blog to explore the integration and what it means for your security operations.

Sentinel data lake

Table insights [Public Preview]

Table insights is a built-in monitoring view on the tables page in the Microsoft Defender portal that gives you table-level observability for your Sentinel workspace without running KQL queries or opening a separate workbook.

Table insights surfaces the signals you rely on most:

📊 Ingestion volume by tier – compare analytics versus data lake
📉 Day-over-week ingestion fluctuations – spot drops or spikes against the same day last week
🔝 Top 5 tables by daily ingestion volume – identify your biggest cost drivers at a glance
🕐 Last data received – catch connectors that stopped sending data
💰 Estimated daily ingestion cost – per-table cost to inform tier and retention decisions
⚠️ Volume anomaly – signed percentage change versus baseline to flag unusual behavior early

Figure 1: View all table insights and investigate your table behavior with Sentinel in the Defender portal.

Together, these signals help you spot collection failures early, so you can act before they turn into bigger problems. Learn more.

Connectors [Public Preview]

GitHub Audit logs (via Azure Storage Blob)

The GitHub Audit logs connector ingests GitHub Enterprise audit logs into Sentinel from Azure Blob Storage with near real-time latency, so you can view this data in workbooks, create custom alerts, and strengthen your investigations. This requires Audit log streaming to be set up on GitHub for an Enterprise. Learn how to stream audit logs.

Agari

The Agari Data connector allows ingesting logs from Agari APIs into Sentinel. This connector integrates with Agari Brand Protection (BP) and Phishing Defense (APD). It supports Data Collection Rules-based ingestion time transformations for efficient query execution.

Airlock Digital

Ingests Airlock Digital application control and execution events to strengthen endpoint threat detection and response.

Additional resources

Blogs and documentation:

Upcoming events:

Featured event: Aug 1–6, Black Hat USA 2026 (Mandalay Bay, Las Vegas)

Keynote with Agentic Security CVP David Weston
The end of rare: Defending when offense is cheap
Wednesday, Aug 5 | 9:15 AM – 10 AM
Main stage with Microsoft Security CVP Aarti Borkar and Microsoft Security Research VP Tanmay Ganacharya
Poisoned at the source: Inside Microsoft Threat Intelligence's hunt for supply chain attacks
Wednesday, Aug 5 | 2:30 PM – 3 PM
Main stage with Customer Success GM Wes Malaby
Mind the gap: Turning threat intelligence into decisive action with expert-led defense
Wednesday, Aug 5 | 11:25 AM – 11:45 AM
Mandalay Bay K with Principal Product Manager Naadia Sayed
Agentic security: What's next
Wednesday, Aug 5 | 11:15 AM – 12 PM
Microsoft Security Black Hat USA 2026 VIP mixer hosted by Microsoft Security CVP Aarti Borkar
Swingers at Mandalay Bay Resort – Register here
Wednesday, Aug 5 | 6 PM – 9 PM
Microsoft booth #2144 with live sessions, AMAs, and hands-on demos of our latest security innovations
Learn more in our Black Hat 2026 blog

Upcoming webinars:

Aug 6: Security Immersion Event: Into the Breach
Aug 13–14: Microsoft Virtual Training Day: Predict and Defend Against Cybersecurity Threats
Aug 19: Microsoft Security Immersion Event: Shadow Hunter
Aug 20: Microsoft Security Immersion Event: Agent Hackathon
Aug 25: Tech Brief: Modernize security operations with a unified platform

Stay connected

Check back each month for the latest innovations, updates, and events to ensure you’re getting the most out of Microsoft Sentinel. We’ll see you in the next edition!

Windows Forwarded Events connector with Windows Security Events NRT rules

enescalban — Sun, 26 Jul 2026 00:07:11 GMT

Hello,

We are testing Microsoft Sentinel using the official Windows Forwarded Events connector.

Environment

- Windows Server WEC

- Windows Event Forwarding

- Azure Arc

- Azure Monitor Agent

- Windows Forwarded Events connector

Everything works correctly.

Forwarded security events are successfully ingested into the WindowsEvent table.

For example:

- Event ID 1102

- Event ID 4732

However, the built-in Windows Security Events NRT Analytics Rules (Content Hub version 1.0.1) query only the SecurityEvent table.

Example:

NRT Security Event log cleared

SecurityEvent

| where EventID == 1102

As a result, forwarded events received through the Windows Forwarded Events connector never trigger these NRT rules.

Question:

Is this expected behavior?

Should Windows Forwarded Events customers use a different set of analytics rules (ASIM or other templates), or should these built-in NRT rules also support WindowsEvent?

Thank you.

Hunting AI Agent Configuration Drift with Microsoft Sentinel

Marcel_Graewer — Mon, 20 Jul 2026 12:28:46 GMT

Four KQL patterns for detecting instruction changes, new MCP servers, ownership changes, and organization-wide sharing

I recently authored and contributed four new Microsoft Sentinel hunting queries for detecting security-relevant configuration drift in AI agents. They have been reviewed, approved, and merged into Microsoft's public Azure-Sentinel repository.

I built the queries around four changes that can materially affect an agent's behavior, access, or exposure: instructions being modified, MCP servers being connected, owners being added, and sharing being expanded to the entire organization. Each modification may be legitimate, but each deserves enough context for a security team to verify that it was expected and authorized.

For a security operations team, the difficult question is often not what does this agent look like now? It is what changed since the last known state?

Microsoft Sentinel's AgentsInfo table provides inventory-style snapshots of AI agents and their associated configuration. That makes it useful for more than posture reporting. By comparing a recent snapshot with an earlier baseline, we can hunt for configuration drift that deserves investigation.

This post walks through four practical hunting scenarios:

Instructions changed on a previously published agent
A newly observed MCP server on an existing agent
An owner added to an MCP-enabled agent
Sharing expanded from a restricted scope to the entire organization

The complete hunting queries are available in Microsoft's public Azure-Sentinel repository. The focus here is the detection design behind them, the KQL patterns they share, and the investigation questions they help answer.

What I contributed

I wrote the four standalone hunting queries discussed in this article and submitted them to Azure/Azure-Sentinel in pull request #14702:

AI Agents - Instructions changed on previously published agent
AI Agents - Newly observed MCP server on existing agent
AI Agents - Owner added to MCP-enabled agent
AI Agents - Sharing expanded to organization-wide

The contribution went through several rounds of technical review. Across six commits, I aligned the queries with the unified AgentsInfo schema, added schema-tolerant IdentityInfo enrichment, improved entity mappings, bounded the identity lookback, expanded all owner values, and kept the ATT&CK mappings limited to scenarios where a precise technique could be defended. Repository collaborator v-atulyadav approved the final revision, and the four queries were merged into master on July 20, 2026.

This article explains the detection logic and engineering decisions behind that contribution rather than simply reproducing the final YAML files.

Why current-state queries are not enough

A current-state query can answer questions such as:

Which agents are published?
Which agents have MCP servers configured?
Which agents are shared with the organization?
Who owns a particular agent?

Those are important posture questions, but they do not tell us whether the state is new. An agent with an MCP server might have been reviewed and approved months ago. The same MCP server appearing for the first time today is a different security signal.

Configuration-drift hunting adds the missing time dimension. Instead of treating a risky-looking property as an event, it compares two states of the same agent and reports only meaningful transitions.

The common detection pattern

I used the same basic time model across all four hunts:

let lookback = 14d; let recent = 2d;

The latest snapshot observed during the last two days becomes the current state. The latest snapshot from the preceding portion of the 14-day lookback becomes the baseline.

Conceptually, the comparison looks like this:

let CurrentState = AgentsInfo | where Timestamp > ago(recent) | summarize arg_max(Timestamp, *) by AgentId | where LifecycleStatus != "Deleted"; let BaselineState = AgentsInfo | where Timestamp between (ago(lookback) .. ago(recent)) | where LifecycleStatus != "Deleted" | summarize arg_max(Timestamp, *) by AgentId; CurrentState | join kind=inner BaselineState on AgentId

Several details matter here:

arg_max(Timestamp, *) by AgentId selects the latest available state for each agent in the relevant time range.
The inner join restricts results to agents that exist in both periods. A newly created agent is therefore not automatically treated as configuration drift on an existing agent.
Deleted lifecycle snapshots are excluded so that a deletion record does not become the effective baseline or current configuration.
The two-day current window is operationally significant. To retain coverage, these hunts should run within two days of a change.

The 14-day and two-day values are practical defaults, not universal constants. Environments with different ingestion cadence or retention requirements can adjust them, but the current and baseline windows must remain non-overlapping.

Scenario 1: Instructions changed on a published agent

An agent's instructions define its default behavior, persona, and operating boundaries. Changing them can be part of normal development, but it can also weaken restrictions, redirect the agent's behavior, or modify how it uses connected capabilities.

The first hunt compares the current and previous instruction values only when the agent was published in both snapshots:

CurrentState | join kind=inner BaselineState on AgentId | where CurrentInstructions != PreviousInstructions | extend PreviousInstructionsHash = hash_sha256(PreviousInstructions), CurrentInstructionsHash = hash_sha256(CurrentInstructions), InstructionsLengthDelta = strlen(CurrentInstructions) - strlen(PreviousInstructions)

I deliberately chose to expose hashes and a length delta rather than returning both instruction bodies in plaintext. This confirms that a change occurred without unnecessarily spreading potentially sensitive prompts through query results, exports, or screenshots.

Useful investigation questions include:

Was the change associated with an approved development or release process?
Did the agent remain published while the instructions changed?
Were guardrails, declared tools, permissions, or sharing settings modified around the same time?
Do audit records identify an expected actor and change path?

The query maps well to an integrity-focused investigation. Its MITRE ATT&CK mapping is T1565.001 (Stored Data Manipulation), but the result is still a hunting lead rather than proof of malicious manipulation.

View the complete instruction-change query

Scenario 2: A newly observed MCP server

Model Context Protocol servers can extend an agent with external tools, data sources, or actions. From a defender's perspective, the important transition is not simply that an MCP server exists. It is that a server name appears in the current configuration but was absent from the baseline.

The query expands the dynamic McpServers array and builds a set of server names for each agent:

let CurrentMcp = CurrentRaw | mv-expand Mcp = McpServers | extend McpName = tostring(Mcp.name) | where isnotempty(McpName) | summarize CurrentMcpServers = make_set(McpName) by AgentI

It performs the same normalization for the baseline, then calculates the difference:

| extend AddedMcpServers = set_difference(CurrentMcpServers, BaselineMcpServers) | where array_length(AddedMcpServers) > 0

Using set_difference() avoids raising a result merely because the order of array elements changed. The hunt reports only MCP server names present in the current set and absent from the previous set.

An analyst should validate more than the displayed name:

Is the MCP integration part of the approved inventory?
What endpoint, authentication method, and permissions are associated with it?
Which tools or data can the server expose to the agent?
Was the integration introduced through an expected deployment path?
Did ownership, instructions, or sharing change in the same period?

I did not assign an ATT&CK technique to this query. Adding an MCP server does not, by itself, prove command execution, persistence, or a specific attacker behavior. Avoiding an overly broad mapping keeps the signal honest.

View the complete MCP-server query

Scenario 3: An owner added to an MCP-enabled agent

Ownership is a control-plane relationship. A newly added owner may be able to modify an agent's configuration, instructions, integrations, or publication state. The risk becomes more interesting when the agent already has MCP servers configured.

The hunt first limits the current state to MCP-enabled agents:

| where array_length(coalesce(McpServers, dynamic([]))) > 0 | project AgentId, Timestamp, Name, Platform, CreatedDateTime, CurrentOwners = coalesce(Owners, dynamic([])), McpServers

It then compares the owner arrays as sets:

| extend AddedOwners = set_difference(CurrentOwners, PreviousOwners) | where array_length(AddedOwners) > 0 | mv-expand AddedOwnerId = AddedOwners to typeof(string)

Expanding AddedOwners produces one row per newly observed owner. This is more useful than returning one opaque dynamic array because every added identity can be enriched, mapped, and investigated independently.

I kept the raw object identifier in the result even when identity enrichment fails:

| extend AddedOwnerUpn = AccountUpn, UnresolvedAddedOwnerId = iff(isempty(AccountUpn), AddedOwnerId, "")

That fallback matters. A missing UPN should not hide the underlying ownership change.

Investigation should establish:

Is the added owner an expected person, service identity, or administrative group?
Does the identity's role and business function justify control of this agent?
Was the owner added before other configuration changes?
Does the identity appear in related sign-in, audit, or privileged-access activity?
Should ownership be removed while the change is reviewed?

This query maps to T1098 (Account Manipulation) under Persistence and Privilege Escalation. As with the instruction-change hunt, the mapping frames an investigation hypothesis; it does not label every ownership change as malicious.

View the complete owner-change query

Scenario 4: Sharing expanded to the entire organization

An agent can move from a limited audience to organization-wide availability without changing its underlying tools or instructions. That transition can materially increase exposure, especially when the agent has MCP integrations or declared tools.

The hunt treats "*" in SharedWith as the organization-wide state. The current snapshot must contain it, while the baseline must not:

// Current state | where set_has_element(coalesce(SharedWith, dynamic([])), "*") // Baseline state | where not(set_has_element(coalesce(SharedWith, dynamic([])), "*"))

The result also counts MCP servers and declared tools:

| extend McpServerCount = array_length(coalesce(McpServers, dynamic([]))), DeclaredToolCount = array_length(coalesce(DeclaredTools, dynamic([]))) | extend HasElevatedCapabilities = McpServerCount > 0 or DeclaredToolCount > 0 | sort by HasElevatedCapabilities desc, Timestamp desc

I use HasElevatedCapabilities as a prioritization field, not a verdict. It brings agents with connected capabilities to the top of the result set so analysts can review the potentially larger blast radius first.

Questions for triage include:

Was organization-wide publication explicitly approved?
Is the agent intended for every user, or was a group-based scope expected?
What data sources, tools, and MCP servers can organization-wide users reach through it?
Do the instructions contain assumptions that were safe only for a restricted audience?
Were access reviews or user-acceptance tests completed before the expansion?

No ATT&CK mapping is assigned because a broader sharing scope is a security-relevant exposure change, but not a sufficiently precise adversary technique on its own.

View the complete sharing-scope query

Resolving owners without making the hunt schema-fragile

The Owners field contains identifiers. Human-readable identity context makes results easier to triage, and entity mappings make those identities more useful in Sentinel investigations.

I built a small, materialized IdentityInfo lookup that is shared by the four hunts:

let IdentityIdtoUPN = materialize( IdentityInfo | extend ResolvedAccountUpn = tostring( column_ifexists("AccountUpn", column_ifexists("AccountUPN", ""))), IdentityTimestamp = todatetime( column_ifexists("Timestamp", column_ifexists("TimeGenerated", datetime(null)))) | where IdentityTimestamp >= ago(lookback) | where isnotempty(AccountObjectId) and isnotempty(ResolvedAccountUpn) | summarize arg_max(IdentityTimestamp, ResolvedAccountUpn) by AccountObjectId | project AccountObjectId = tostring(AccountObjectId), AccountUpn = ResolvedAccountUpn);

There are three design choices worth noting:

column_ifexists() accommodates observed IdentityInfo naming variants without maintaining separate query versions.
The lookup is bounded by the same lookback period instead of scanning unbounded identity history.
arg_max() keeps the latest usable identity record for each object ID.

After enrichment, the queries map the account using the UPN components and the Entra object ID:

entityMappings: - entityType: Account fieldMappings: - identifier: Name columnName: OwnerAccountName - identifier: UPNSuffix columnName: OwnerAccountUPNSuffix - identifier: AadUserId columnName: OwnerId

The strong AadUserId identifier remains valuable even when display information changes. Microsoft Sentinel can use mapped entities in bookmarks and investigation experiences, so mapping the changed owner is more than cosmetic enrichment.

Turning a result into an investigation

These queries intentionally stop at the configuration transition. AgentsInfo tells us that two snapshots differ; it does not necessarily tell us who performed the change, through which interface, or whether the action was authorized.

A practical investigation workflow is:

Confirm that the two snapshots represent the expected agent and time period.
Review the exact changed property and the agent's current capabilities.
Identify the owner or newly added owner through IdentityInfo and Entra ID context.
Correlate the transition with the relevant audit source for actor attribution.
Check for related changes to permissions, tools, data sources, publication state, and sharing.
Validate the change against an approved request, release, or ownership process.
Restrict, unpublish, or revert the agent if the exposure cannot be justified.

Expected changes can still be useful findings. Repeated legitimate results may reveal that a deployment process lacks a stable change window, that ownership is managed through noisy automation, or that the hunt's timing needs to be aligned with release activity.

Tuning the hunts for your environment

Before operational use, consider the following adjustments:

Run cadence: Execute within the two-day current window. A daily cadence provides overlap without blending current and baseline periods.
Lookback: Increase the 14-day lookback only if snapshot history and query cost support it. A longer lookback does not compensate for missing the current window.
Known change windows: Add watchlists or environment-specific suppression logic for well-controlled automated deployments, while retaining enough context to audit the change.
Agent scope: Filter by platform, business unit, agent naming convention, or owner if different teams require separate triage queues.
Risk prioritization: Raise agents with sensitive declared data sources, powerful tools, privileged owners, or broad availability to the top of the result set.
Audit correlation: Keep attribution logic separate unless the audit source and join keys are stable in your environment. This makes the configuration-drift hunt reusable while allowing each organization to attach its own control-plane evidence.

Test with representative snapshots before treating any hunt as an operational control. In particular, validate array shapes for Owners, McpServers, and SharedWith, confirm the identity fields present in your workspace, and exercise both changed and unchanged states.

Using the queries

The four YAML definitions have been merged into the Hunting Queries/AI Agents folder of Microsoft's Azure-Sentinel repository. Each file contains the complete KQL, description, entity mappings, and ATT&CK mappings where a precise technique applies.

The broader pattern is reusable beyond these four scenarios: select a stable current snapshot, select a non-overlapping baseline, normalize dynamic properties into comparable sets, calculate the transition, and enrich only after the drift has been identified. That keeps the core detection explainable and gives the analyst the before-and-after context needed for a defensible investigation.

References

I authored the four hunting queries discussed in this article and contributed them to Microsoft's Azure-Sentinel repository as PR #14702. The complete implementations and review history are publicly available through the links above.

Sentinel - Defender XDR KQL Queries Library

GokselATAKAN — Sun, 19 Jul 2026 11:33:56 GMT

Hello all,

I’ve been building something over the past few weeks that I think the security community might find useful.

GoXDR is a searchable KQL query library for Microsoft Sentinel and Defender XDR. The name comes from a nickname my colleagues gave me (GoX) combined with XDR. I also picked up goxdr.fyi as a short and easy to remember domain for it.

You can check it out here: https://goxdr.fyi

The idea came from my own day to day work as someone working in IAM and SOC operations. I constantly find myself writing and refining KQL queries for threat hunting, detection engineering and incident investigation. Over time I realized I had a growing collection of queries that I kept going back to and I thought why not make these available to others?

It currently has 117 queries covering identity security, BEC/AiTM detection, NTLM and LDAP attack hunting, OAuth governance, AI/Copilot security, Sentinel alert trending, SOC performance metrics and more.

Some of these queries are ones I wrote from scratch based on real scenarios I encountered in production environments. Others are community queries I tested and validated in my own setup. Only the ones I found genuinely useful and that actually worked against real data made it in.

Each query comes with a description explaining what it detects and why it matters, along with severity levels, platform tags (Sentinel, XDR or both) and a copy button so you can paste it directly into Advanced Hunting or use it as the basis for an Analytics Rule.

The site is open source, hosted on GitHub Pages and licensed under CC BY 4.0. No sign-up, no paywall, no tracking. The source is available.

I’ll keep adding queries as new scenarios come up. If there’s enough interest I’m also considering adding Cortex XQL queries for Palo Alto environments.

Suggestions, feedback or ideas for new detections are always welcome. Feel free to reach out.

Thanks

Announcing the ASIM Parser Creation Agentic Experience

derricklee — Wed, 15 Jul 2026 16:00:00 GMT

Creating high-quality ASIM parsers has always required deep knowledge about source data and ASIM schemas, careful KQL design, and repeated validation cycles. That process is meaningful to understand the whole Sentinel ecosystem, but it can be slow when you are starting from raw source data and trying to get to a production-ready parser.

Today, we are introducing a new agentic experience available now as open source that helps security teams move faster: an AI-guided workflow for creating ASIM parsers end to end.

Why this matters

ASIM parsers are the normalization layer that makes detections, hunting, and analytics portable across data sources. They are foundational, but building them involves many steps:

Gathering source requirements and schema targets
Authoring a parameter-less and a parameterized ASIM parser
Validating schema conformance and data quality
Packaging the parsers into a GitHub pull request for open-source contributions

ASIM normalization is important because it gives security teams a common language across different products and log formats. Without normalization, every detection, hunting query, and workbook has to be rewritten per vendor table, which increases engineering effort and creates blind spots when data sources change. With ASIM, the same analytic logic can operate across multiple sources through consistent field names and semantics.

This directly improves security outcomes by enabling faster content reuse, easier cross-source correlation, and more reliable incident triage. It also reduces long-term maintenance costs, because teams update parsers at the query and mapping layer instead of rewriting detection content each time a connector changes.

The new agentic experience orchestrates those steps for you with clear checkpoints and repeatable outputs.

What is the ASIM parser creation agentic experience?

The experience is built around a specialized set of skills that work together as a workflow. Instead of using a single prompt and hoping for the best, the agent walks through parser creation as a structured process.

At the center is the orchestration skill that coordinates:

Requirement collection
Parser generation
Validation loops that test the parser schema and data outputs
Optional deployment to Log Analytics and PR packaging for Azure-Sentinel

Where can I find these skills?

If you have cloned or forked the Azure-Sentinel repository, the skills are already there! All you need is GitHub Copilot CLI to get started. For more information, you can visit the README or our Learn Docs.

Another way to access these skills is through our Microsoft Sentinel Visual Studio Code Extension. You can simply chat with GitHub Copilot with your intention to create ASIM parsers, and it will call its loaded skills.

What you can expect in practice

When you start with a request like "Create a new ASIM parser for my source table" the agent can:

Gather critical inputs
Build the initial ASIM parser from source requirements
Run schema and data validation
Refine the parser in a loop until error-level findings are resolved (or report remaining blockers)
Build the matching parameterized parser and re-validate
Help deploy or package your parsers into a PR to contribute to open-source

Where this helps most

This workflow is especially useful when:

Data is already flowing into Sentinel, but there are no supporting ASIM parsers yet
Migrating legacy parsing logic to ASIM conventions
Creating a parser needs to happen with almost no delay, without sacrificing validation confidence

It will also reduce onboarding time for analysts who are new to ASIM but comfortable with KQL and Sentinel operations.

Closing

The ASIM parser creation agentic experience is not about replacing engineering judgment. It is about amplifying it.

If you are building ASIM parsers today, now is the right time to pilot an agentic workflow and shape what comes next.

If you are new to ASIM, getting started with parsers is easier than ever. The guided agentic flow walks you through requirements, parser generation, and validation step by step, so you can learn the ASIM model while still producing useful, high-quality parser outputs quickly.

Building toward an Agentic SOC: A Portable, Autonomous Malware Investigation Agent

absharan — Mon, 13 Jul 2026 19:09:25 GMT

Modern Security Operations Centers are not short on tools. They are short on continuity. Analysts jump from alert consoles to data exploration, from enrichment to investigation, and from evidence gathering to response—often across multiple interfaces and disconnected workflows.

A single malware incident may begin in Microsoft Sentinel, require enrichment in Defender, depend on targeted KQL hunting, and end with manual response actions somewhere else. Every handoff adds friction. Every context switch slows triage. And every inconsistency increases the risk of missed signals or delayed containment.

To explore what an Agentic SOC could look like in practice, I built a portable, autonomous malware investigation agent: a user-invocable workflow that takes an incident from investigation to evidence correlation to verdict and, when appropriate, to action.

The goal is simple: one prompt, one workflow, and a full incident lifecycle that moves cleanly from Investigate to Decide to Act.

The Real Problem: SOC Work Is Still Too Fragmented

In a conventional malware investigation, even experienced analysts spend too much time stitching the workflow together:

Pivoting across Sentinel and Defender
Manually extracting entities
Writing and optimizing multiple KQL queries
Context switching between tools
Making decisions with incomplete evidence

The operational impact is familiar to every SOC team:

Increased MTTR
Analyst fatigue
Inconsistent investigation quality

This fragmentation is exactly what a unified Microsoft Sentinel and Defender experience is built to solve, and it is where such an investigation agent demonstrates its value.

The Approach: A Portable Agent for End-to-End Malware Investigations

The agent is designed to handle the full investigation loop—not just enrichment, not just summarization, and not just response orchestration.

End-to-end malware investigation
Evidence-based verdicting
SOC-ready summarization
Optional automated response

Because it is defined as a portable agent, the same investigation pattern can be reused across environments with consistent logic, standardized outputs, and controlled automation boundaries.

Standardized investigations
Repeatable execution
Controlled automation
Cross-environment portability

Architecture Overview (End-to-End Flow)

Visual 1: Agentic SOC Investigation Workflow

User / Analyst Input
“Investigate Incident”

↓

SOC AI Agent
Portable Investigator

↓

Microsoft Sentinel
SecurityIncident • SecurityAlert • Data Lake (KQL)

↓

Entity-Driven Queries
Device • User • File • IP

↓

Evidence Correlation

↓

Verdict + Summary
True Positive • False Positive • Benign True Positive

↓

Optional Actions
Comment • Tag • Isolate

How the Agent Works: A Practical Deep Dive

Prerequisites

VS Code with GitHub Copilot
Microsoft Sentinel MCP server (provides the Triage and Data Lake exploration tools the agent runs on)
Microsoft Defender for Endpoint data (for the Device* hunting tables)
API permissions for any response action (e.g. endpoint isolation)

1. Input & Trigger

The workflow starts with a simple natural-language prompt, for example:

Investigate Defender incident 1939

The input includes:

Defender Incident ID
Optional Sentinel workspace

2. Sentinel-First Investigation

The first design choice is deliberate: the agent starts from Sentinel as the investigation plane, within the Unified Defender Portal, where incidents are correlated across Sentinel and Defender, using it to retrieve incident structure, alert context, severity, timelines, and alert relationships before moving deeper.

Queries:

SecurityIncident
SecurityAlert

Extracts:

Severity
Timeline
Alert relationships

This ensures:

Consistent data plane
Reduced dependency on multiple APIs

3. Entity-Driven Correlation

Instead of launching broad hunts across the environment, the agent narrows the scope using the entities already present in the incident. That makes the investigation faster, cheaper, and more precise.

Extracts entities:

Device
User
File hash
IP/URL

Runs targeted queries only

Example tables:

DeviceProcessEvents
DeviceFileEvents
DeviceNetworkEvents

This is critical for:

Performance

Cost control

Precision

Visual 2: From Incident to Correlated Evidence

Incident	Alerts	Entities	Targeted Queries	Evidence
Incident 1939	Malware detection	device123 userA file.exe	DeviceProcessEvents DeviceFileEvents DeviceNetworkEvents	Correlated execution, origin, and network signals

4. Evidence-Based Verdict

Once the signals are correlated, the agent produces one of three explicit outcomes—grounded in evidence rather than guesswork.

True Positive
False Positive
Benign True Positive

The verdict is:

Based on evidence only
Not guess-driven
Not heuristic overreach

5. SOC-Ready Output Standardization

The final output is intentionally standardized so an analyst can review the outcome quickly, understand the reasoning, and decide what happens next.

One-line verdict
ASCII findings table
Analyst summary
Actions taken
Optional containment recommendation

Visual 3: Standardized Investigation Output

Verdict: True Positive
Category	Findings
Incident Details	Severity: High
Malware Details	Trojan X detected
Device Posture	Real-time protection enabled
User Context	Standard user
Observed Activity	Suspicious process tree
Recommendation	Isolation recommended

Summary

Malware execution confirmed.
Blocked by Defender.
No lateral movement observed.

Actions Taken

Comment added.
Tag applied.
Awaiting isolation decision.

Optional Response & Containment

If permissions are available, the agent can:

Add incident comments
Tag incidents
Update classification
Close incidents
Perform endpoint isolation (gated with human in the loop)

With strict safeguards:

Evidence-backed decisions
Permission validation
Audit traceability

Visual 4: Workspace Portability Logic

Decision Point	Outcome
Workspace provided?	Yes → Use the specified workspace.
Workspace provided?	No → Detect available workspaces.
Only one workspace available?	Yes → Use it automatically.
Multiple workspaces available?	Ask the user to select one.
Missing permissions?	Fall back to read-only behavior.

Security & Operational Rigor

The agent enforces:

No secret storage
Use of existing authentication context
Clear reports of missing permissions
Minimized unnecessary queries

Why This Matters for the Agentic SOC Journey

This solution demonstrates three core pillars of agentic SOC:

1. Deterministic AI Execution

Standardized workflow
Repeatable outcomes
Consistent investigation depth

2. Human-in-the-Loop Control

Analyst decides final actions
No blind automation
Clear explainability

3. End-to-End Closure Capability

This is the most important:

Not just detection
Not just enrichment

Full lifecycle:

Investigate
Decide
Act

What’s Next

This pattern can be extended to:

Identity investigations
Insider risk
Multi-cloud threat correlation
Security Copilot-driven SOC agents

Final Thoughts

Most SOC automation still stops too early—at playbooks, enrichment, or isolated workflow steps. What is still missing in many environments is a cohesive execution model that can carry an investigation from signal to decision without losing context along the way.

Playbooks
Alert enrichment
Partial workflows

This pattern points to something more powerful: composable, intelligent SOC agents that can operate across the full incident lifecycle while keeping humans firmly in control of high-impact actions.

If an agentic SOC is the destination, portable investigation agents are a practical and credible way to start building toward it today.

Get the agent, setup steps, and instructions on GitHub:

SOC Malware Investigator (Portable)SOC Malware Investigator (Portable)

Learn more

Microsoft Sentinel MCP server: https://learn.microsoft.com/azure/sentinel/datalake/sentinel-mcp-overview
Microsoft Sentinel data lake: https://learn.microsoft.com/azure/sentinel/datalake/sentinel-lake-overview
Advanced hunting (Defender device tables): https://learn.microsoft.com/microsoft-365/security/defender/advanced-hunting-overview

Sentinel - Defender for Cloud P2 Benefit

DaithiG — Mon, 06 Jul 2026 09:11:03 GMT

Hi all,

To receive the the benefit of the Sentinel / Defender for Cloud P2 500mb benefit is the following correct:

Enabled Defender for Cloud P2 on the server or via Azure Arc (these are mainly on-prem servers.

Create a DCR rule to collect events and send to our Sentinel Workspace.

Enable Defender on the Sentinel workspace (not subscription)

Defender for Servers is far more work than it should be!

Behind the Build with Gigamon: Enriching Microsoft Sentinel with Network-Derived Telemetry

Natee_Pretikul — Wed, 01 Jul 2026 17:51:59 GMT

Behind the Build is an ongoing series spotlighting standout Microsoft partner collaborations. Each edition dives into the technical and strategic decisions that shape real-world integrations—highlighting engineering excellence, innovation, and the shared customer value created through partnership.

Security teams today operate across an expanding set of signals, spanning identity, endpoint, cloud and application environments. Yet many organizations still lack sufficient visibility into how systems communicate across their infrastructure, creating gaps in detection, investigation, and response.

In this edition of Behind the Build, I spoke with Srinivas Chakravarty, vice president, cloud ecosystems at Gigamon, about how Microsoft and Gigamon collaborated to bring network-derived telemetry into Microsoft Sentinel, helping customers enrich security investigations with deeper runtime context and AI-driven insights.

The Evolution of Network Intelligence and Why It Matters

For more than twenty years, Gigamon has helped organizations access and operationalize network traffic across complex environments. Today, the Gigamon Deep Observability Pipeline, helps enable organizations to extract actionable network-derived telemetry across hybrid infrastructure, encrypted traffic, containers, and modern application environments.

That foundation makes the Gigamon Deep Observability Pipeline a strong complement to Microsoft Sentinel. Microsoft Sentinel brings together security telemetry from across the enterprise—including identity, endpoint, cloud, application, and network data sources—while Gigamon contributes enriched network-derived telemetry that provides additional runtime context into how systems, applications, and services communicate. Together, these signals can help organizations gain deeper insight for threat detection, investigation, and response.

As Srinivas put it: “You have logs, you have metrics, you have traces, but network telemetry completes the picture.” Together, these data sources provide deeper context for threat detection, investigation, and AI-driven analysis.

Gigamon and Microsoft partner to design end-to-end solutions for our shared customers, starting with how network traffic is captured, to how it is processed, and ultimately to how it is analyzed within Microsoft Sentinel. The first step in that pipeline is ensuring consistent, scalable visibility into traffic across environments.

Extending Visibility

Gigamon has been working alongside Microsoft’s Azure network virtual access point team to expand how customers access network traffic across Azure and hybrid environments. Customers can leverage the virtual network TAP in Azure environments alongside Gigamon telemetry capabilities across on-premises, cloud, and hybrid deployments.

This visibility layer is foundational to the broader architecture. The Gigamon Deep Observability Pipeline helps ensure organizations can access, optimize, and enrich network traffic before transforming it into actionable telemetry for downstream analysis in Microsoft Sentinel.

Turning Network Telemetry into Actionable Security Insights

The integration between Gigamon and Microsoft Sentinel is designed to maximize both fidelity and operational efficiency. Gigamon deep packet inspection capabilities extract and enrich nearly 6,000 metadata attributes from network traffic, transforming raw packets into curated telemetry designed for downstream analysis.

That telemetry is delivered into Microsoft Sentinel through a Codeless Connector Framework (CCF) push connector, where it can be correlated with identity, endpoint, and cloud telemetry. By bringing these signals together, organizations can more easily trace suspicious activity across their environments and investigate threats that span traditionally siloed domains.

Rather than overwhelming analysts with raw network data, the integration prioritizes actionable metadata that can be correlated across traditionally siloed domains. “When you bring this data into Sentinel, you’re no longer analyzing it in isolation, you’re correlating it across the entire estate,” said Srinivas.

Delivering Customer Value: A Unified Investigative Experience

While the technical architecture is important, the ultimate measure of success is the impact on customers. By combining Gigamon’s network intelligence with Microsoft Sentinel’s analytics and AI capabilities, organizations can gain a more complete view of their environments, one that helps reduce fragmentation and accelerate investigations.

“Customers are looking for a single investigative plane,” Srinivas explained. “When you bring all of this together, it can help significantly reduce the time to detect and respond.”

This helps manifest four key outcomes:

Accelerated investigations through correlation across network, identity, endpoint, and cloud telemetry
Improved signal quality through curated, high-value network-derived metadata
Greater operational efficiency through a unified investigation experience in Microsoft Sentinel
Enhanced visibility into encrypted, East-West, and hybrid cloud traffic activity that is often difficult to analyze through logs alone

By helping to address gaps that exist when using network or log data in isolation, the combined Gigamon and Microsoft solution can help SOC teams move more quickly from signal to action.

From Ingestion to Insight: Building with Agentic AI

Bringing telemetry into Microsoft Sentinel was only the first step. A major area of collaboration between Microsoft and Gigamon focused on leveraging Sentinel's AI and data platform capabilities to enable agentic workflows that can reason over enriched network-derived telemetry alongside broader security data.

“It’s truly working backwards from customers,” said Srinivas. “We are driven by what customers want and we help each other out, we unblock each other at every step of the way to make these joint solutions possible.”

The result is Gigamon's Security Posture Insight Agent, which leverages Microsoft Sentinel platform capabilities to enrich investigations with deep packet-derived evidence including JA4 fingerprints, decrypted TLS metadata, and lateral-movement flows. This can help give analysts faster access to runtime evidence that might otherwise require manual packet analysis and correlation across tools.

Expanding the Possibilities of the Platform

As the collaboration evolves, both teams see opportunities to expand the role of network-derived telemetry across emerging AI and hybrid cloud security use cases. Areas of potential exploration include AI application visibility, expanded runtime intelligence, and deeper integration between observability, security analytics, and AI-driven workflows.

“The platform approach will win, especially in an AI-driven world,” said Srinivas. “It’s about ecosystems coming together.”

That ecosystem mindset of bringing together best-in-class data, analytics, and AI is what enables organizations to stay ahead of increasingly complex threats.

Final Thoughts

This collaboration highlights what’s possible when strong engineering partnerships are grounded in customer outcomes. By combining network-derived telemetry from the Gigamon Deep Observability Pipeline with analytics and AI capabilities of Microsoft Sentinel, organizations can gain deeper runtime visibility, accelerate investigations, and improve AI-driven security operations.

As the partnership continues to evolve, Microsoft and Gigamon are working together to help customers build more unified, intelligent SOC experiences across increasingly complex hybrid cloud environments.

For software companies building on Microsoft Sentinel, the Gigamon collaboration also demonstrates how partners can leverage Microsoft App Assure’s Sentinel Advisory Service, a no-cost program that helps partners design secure, high-performance solutions on Microsoft Sentinel while accelerating time to market. From development to deployment, App Assure ensures your solution meets Microsoft’s standards while accelerating time to market. Ready to get started building a Sentinel solution? Submit a request to App Assure.

To read previous entries in our Behind the Build series, see below:

The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

Mohit_Kumar1 — Tue, 30 Jun 2026 16:00:00 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

The portal change was the easy part. The real upside is the operating model it unlocks—generative AI in every workflow, behavioral analytics across hybrid and multi-cloud, native threat intelligence, and SOC optimization recommendations that tell you exactly where to invest next.

If the first five parts of this series were about what changes and how to plan for it, this part is about what you get on the other side. Microsoft Defender is the only place where Security Copilot agents, the unified UEBA experience, native MDTI convergence, and the full SOC optimization recommendation engine come together—and each one moves a needle that classic Sentinel could not move alone.

None of these capabilities require a forced cutover. Most of them light up the moment a workspace is connected. The story is not “give up Sentinel for Defender”—it is “your existing investment now compounds with capabilities you did not have before.”

What this post covers

Security Copilot: embedded experience, standalone portal, and AI agents
UEBA: same engine, unified entity pages, new data sources, unified IdentityInfo schema
Threat intelligence: MDTI converged natively, richer STIX data model, actor-centric investigations
SOC optimization: from manual workbooks to personalized, cross-service recommendations
Persona implications, common misconceptions, a do-this-week checklist, and the series wrap-up

Security Copilot in Defender

Microsoft Security Copilot is a generative AI-powered security solution. Customers can interact with Security Copilot across their Sentinel and Defender data in Defender (embedded experience and agents) and the standalone copilot portal (securitycopilot.microsoft.com).

Core capabilities

Investigate and remediate threats; incident summarization, guided step-by-step response actions, triage complex alerts into actionable summaries
Build KQL queries and analyze scripts; natural language → KQL in advanced hunting, reverse engineer suspicious PowerShell, batch, and bash scripts
Understand risks and manage posture; prioritized risk insights, exposure context, and threat actor intelligence from Microsoft and open source
Develop reports for stakeholders; generate incident reports in natural language, tailored to audience tone and language

AI agents

Microsoft-built and partner-built agents are available through the Security Store in Defender, automating SOC tasks such as incident triage, access reviews, and vulnerability remediation. Custom agents can be built using agent builder, APIs, MCP, and Graph.

Transition considerations

The embedded experience of Security Copilot and agents are available in the Defender portal and not in the Azure portal.
No configuration migration needed; available once licensed.
Train SOC analysts on Security Copilot as part of Defender onboarding.

Why this lands well: Generative AI is not bolted on to the side of the SOC—it is embedded in the surfaces where work already happens. Triage, KQL authoring, scripted-attack analysis, and stakeholder reporting each get a copilot, and the agent marketplace means the catalog grows without you writing more code.

UEBA: Same engine, richer surface

Most User and Entity Behavior Analytics (UEBA) functionality carries over to Defender with minimal disruption—anomaly detection, behavioral baselines, and investigation priority scoring all continue to work. However, there are meaningful differences in how UEBA surfaces within the unified experience that analysts and engineering teams should understand before transitioning.

The Microsoft Sentinel UEBA behaviors layer transforms high-volume raw security logs into structured, plain-language behavioral summaries (“who did what to whom”), adding context such as MITRE ATT&CK mappings and entity relationships to improve investigation clarity and efficiency.

These behaviors are neutral activity summaries (not alerts), aggregating and sequencing events to help analysts detect patterns, hunt threats, and build simpler detections, ultimately speeding up investigation and response without requiring deep knowledge of underlying log sources.

What changes in Defender

The standalone entity behavior blade from the Azure portal is no longer available. Instead, UEBA insights are integrated directly into the unified entity pages under assets (accounts, hosts, mailboxes) and evidence (IPs, files, URLs). Users flagged with behavioral anomalies are automatically tagged with a “UEBA anomalies” label on the user page, showing confidence scores and anomaly counts—making it easier to prioritize investigation without navigating to a separate blade. Additionally, the incident graph now supports a “Go hunt” action on user entities that surfaces all related anomalies, and advanced hunting queries against UEBA-related tables display contextual banners suggesting joins with the anomalies table for richer results. Also, in Defender, UEBA now has behavior layers.

New data sources (Defender only)

After transitioning, UEBA gains access to additional data sources that are not available in the Azure portal: AAD managed identity sign-in logs, AAD service principal sign-in logs, AWS CloudTrail, device logon events, Okta single sign-on, and GCP audit logs. These expand behavioral baselines beyond traditional user sign-ins to cover service principals, multi-cloud activity, and device-level logon events—a significant uplift for organizations with hybrid or multi-cloud environments.

IdentityInfo table: Two flavors, now unified

The IdentityInfo table has historically existed in two separate versions: one populated by Microsoft Defender for identity (MDI) in advanced hunting, and another populated by Microsoft Sentinel’s UEBA engine in log analytics.

Important - Table-level RBAC on IdentityInfo: If Table-level RBAC has been delegated to the Sentinel IdentityInfo table, this permission model is not carried over to Defender. Table-level RBAC for the IdentityInfo table is not supported in the Defender portal. Review and update your workspace RBAC delegations before migrating to avoid unexpected access gaps. For details, see the Investigate with UEBA in the Defender portal section in the Microsoft documentation.

After onboarding to Defender, these merge into a unified IdentityInfo table that includes fields from both sources. If UEBA is enabled, the UEBA-specific columns—such as BlastRadius, GroupMembership, CompanyName, DeletedDateTime, EmployeeId, OtherMailAddresses, State, and Tags—are automatically visible in the unified schema. Without UEBA enabled, these columns are not available.

The key action item here is that the unified schema introduces field name differences that can break existing queries.

The following table maps old field names to the new unified schema:

Log analytics field	Unified schema field
AccountCloudSID	CloudSid
AccountCreationTime	CreatedDateTime
AccountSID	OnPremSid
AccountUPN	AccountUpn
AdditionalMailAddresses	OtherMailAddresses
MailAddress	EmailAddress
OnPremisesDistinguishedName	DistinguishedName
RiskState	RiskStatus
SAMAccountName	AccountName
SourceSystem	IdentityEnvironment
StreetAddress	Address
UserType	TenantMembershipType

Additionally, UserState and UserStateChangedOn no longer exist in the unified schema and must be removed from any queries that reference them.

Important caveat: Existing Sentinel analytic rules and workbooks that query IdentityInfo via the log analytics API continue to hit the Sentinel table in log analytics—they are not automatically redirected to the advanced hunting table. However, any queries executed in advanced hunting in Defender use the unified table. Teams should verify both query paths during transition.

Why this lands well: The same UEBA engine you already trust, now embedded in entity pages where investigations actually happen, fed by additional multi-cloud and identity data sources that simply do not exist on the Azure portal side.

Threat intelligence converged natively

Azure portal versus Defender at a glance

Aspect	Azure portal	Defender
Custom threat intelligence management	Sentinel’s threat intelligence blade for ingesting, viewing, and managing custom indicators (IOCs). Threat intelligence analytics rule matches against data sources automatically.	Defender’s threat intelligence blade is focused on Microsoft-curated intelligence integrated directly into the unified experience. Threat intelligence ingestion using STIX/TAXII is unchanged architecturally but is managed from the Defender UI rather than a standalone Sentinel experience. Customers can add/import their own threat intelligence using bulk file imports, or add new threat intelligence objects.
Microsoft threat intelligence	Threat intelligence analytics rule provides high-fidelity alerts using Microsoft’s domain, IP, and URL threat indicators across CEF, Syslog, OfficeActivity, AzureActivity, DNS.	Threat intelligence analytic rules are also present. Microsoft Defender threat intelligence (MDTI) converged into a unified experience in Defender, where threat intelligence is now surfaced natively across Defender and Microsoft Sentinel through threat analytics, investigations, and hunting workflows. Microsoft Threat Intelligence insights are embedded directly into incidents to provide enriched context and can also be accessed seamlessly through Security Copilot prompts. Security Copilot leverages Microsoft threat intelligence and non-Microsoft plugins.

Aspect

Azure portal

Defender

Custom threat intelligence management

Sentinel’s threat intelligence blade for ingesting, viewing, and managing custom indicators (IOCs). Threat intelligence analytics rule matches against data sources automatically.

Defender’s threat intelligence blade is focused on Microsoft-curated intelligence integrated directly into the unified experience. Threat intelligence ingestion using STIX/TAXII is unchanged architecturally but is managed from the Defender UI rather than a standalone Sentinel experience. Customers can add/import their own threat intelligence using bulk file imports, or add new threat intelligence objects.

Microsoft threat intelligence

Threat intelligence analytics rule provides high-fidelity alerts using Microsoft’s domain, IP, and URL threat indicators across CEF, Syslog, OfficeActivity, AzureActivity, DNS.

Threat intelligence analytic rules are also present. Microsoft Defender threat intelligence (MDTI) converged into a unified experience in Defender, where threat intelligence is now surfaced natively across Defender and Microsoft Sentinel through threat analytics, investigations, and hunting workflows.

Microsoft Threat Intelligence insights are embedded directly into incidents to provide enriched context and can also be accessed seamlessly through Security Copilot prompts. Security Copilot leverages Microsoft threat intelligence and non-Microsoft plugins.

Transition considerations

Continue managing custom threat intelligence feeds using Sentinel connectors and the threat intelligence experience for TAXII/STIX feeds
Keep the threat intelligence analytics rule enabled for automated indicator matching; resulting alerts can still flow into Defender incidents
Use MDTI context and Security Copilot prompts to enrich investigations
Threat intelligence is no longer Sentinel-only

In Defender, threat intelligence is:

Linked to Defender incidents
Visible in threat analytics
Usable in cross-product hunting

This is not possible in the Azure portal experience, which is Sentinel-scoped only.

MDTI convergence (native, not a connector)

MDTI is converged directly into Defender + Sentinel
Threat actor profiles, campaigns, and IOCs surface automatically
No separate MDTI portal or workflow is required

This convergence does not fully materialize in the Azure portal experience.

Richer STIX data model in Defender

Defender emphasizes richer relationships, such as:

ThreatIntelIndicators
ThreatIntelObjects
Actor ↔ tool ↔ infrastructure relationships

This enables actor-centric investigations, not just IOC matching.

Better correlation and investigation

Threat intelligence automatically enriches unified incidents
Indicators connect to affected endpoints, users, mail, and cloud workloads

Why this lands well: Threat intelligence stops being a side-product. Microsoft-curated intelligence and your custom feeds both flow into the same incident view, surface in threat analytics, and become huntable across Defender + Sentinel—with Security Copilot in the loop for enrichment.

SOC Optimization: From workbooks to recommendations

Azure portal versus Defender

Portal	SOC optimization model
Azure portal	No native SOC Optimization prior to May 2024. Customers used the MITRE ATT&CK coverage page (Preview) and community workbooks (Workspace Usage, Security Operations Efficiency) for manual, non-opinionated assessment No personalized recommendations; analysts had to interpret workbooks themselves Available in Azure portal (since May 2024 public preview)—same recommendation engine. However, the Azure portal provides Sentinel-only visibility and lags Defender in surfacing newer recommendation types and aggregation views, such as risk-based optimization and cross-service context Sunsets March 31, 2027, along with the rest of the Azure portal Sentinel UI
Defender	SOC optimization overview tile shows recent optimization activity, threat-based coverage tiers (low, medium, high), and ingestion trends Three GA recommendation types: data value (identify unused or low-value ingested data), threat-based coverage (close detection gaps against specific threats), and similar organizations (benchmarking) Preview capabilities: risk-based recommendations, AI-powered MITRE ATT&CK tagging, and unused columns detection Cross-service coverage: Unified view spans Sentinel + Defender workloads, not just Sentinel Recommendations API (Preview, 2024-01-01): GET/PATCH/triggerEvaluation for automation; scales for MSSPs. Permissions: Standard Sentinel RBAC (Reader to view, Contributor to action)

Transition considerations

Not Defender-exclusive: Core recommendation engine runs in both portals—no functionality loss for customers who transition early
Defender advantages: Cross-service coverage (Sentinel + Defender), richer overview tile, and Preview-only risk-based recommendations are Defender exclusives
Preview features evolving: Risk-based, AI MITRE tagging, and unused columns remain in Preview—verify GA status against “What’s new in Sentinel” before relying on them
Retire manual workbooks: Phase out reliance on the Workspace Usage and Security Operations Efficiency workbooks; SOC optimization supersedes them with personalized, actionable recommendations
Action tracking: Use the recommendations API to track which optimizations your team actions over time—useful for MSSPs reporting SOC maturity to customers

Why this lands well: You stop guessing what to improve. The engine tells you where coverage is weak, where ingestion is wasted, and how peer organizations are configured—and it does so across Sentinel + Defender, not just one product.

Persona implications

Persona	What this part means for you
SOC analyst	Security Copilot in-line for triage, incident summaries, KQL drafting, and script reverse-engineering. UEBA anomalies show up on the entity page itself, not a separate blade.
Threat hunter	Unified IdentityInfo, multi-cloud UEBA data sources, MDTI-enriched investigations, and natural-language-to-KQL all in one surface.
Detection engineer	Update IdentityInfo field names in existing queries; verify both log analytics and advanced hunting paths during transition.
SOC manager	SOC optimization gives you a personalized, cross-service action list. Retire the manual workbooks; track action rate through the recommendations API.
MSSP operator	SOC optimization recommendations API scales for MSSP reporting; agents from the Security Store help automate repetitive customer-facing SOC tasks.

Clearing up common misconceptions

“Security Copilot is only available in the standalone portal.”
It’s not. The embedded experience and agents are available inside Defender once licensed—no configuration migration needed.
“UEBA loses functionality after the transition.”
UEBA functionality remains. Anomaly detection, baselines, and priority scoring all carry over—and you gain multi-cloud and service-principal data sources that do not exist in the Azure portal experience.
“All my IdentityInfo queries will keep working unchanged.”
Partially. Sentinel analytic rules and workbooks hitting log analytics still work; Advanced hunting queries use the unified table with new field names—verify both paths during transition.
“MDTI needs a separate portal or connector.”
It doesn’t. MDTI is converged natively into Defender + Sentinel—threat actor profiles, campaigns, and IOCs surface automatically.
“SOC Optimization is Defender-only.”
The core engine runs in both portals. Defender adds cross-service coverage, the richer overview tile, and Preview-only recommendation types.
“Community workbooks for usage and efficiency are still the recommended path.”
Not anymore. SOC optimization supersedes them with personalized, actionable recommendations—phase the manual workbooks out.

Do this week

Enable the embedded experience in Defender and pilot incident summarization on one active incident if you are licensed for Security Copilot
Walk through the SOC optimization overview tile with your manager—pick one data-value and one threat-based recommendation to action this sprint
Inventory queries that reference the legacy log analytics IdentityInfo fields; map them against the unified schema field-name table and prioritize updates
Confirm UEBA is enabled where applicable so the additional unified-schema columns light up
Open the Defender threat intelligence pane and verify MDTI context is surfacing on at least one current incident
Try one natural-language-to-KQL prompt in advanced hunting via Security Copilot—a quick “aha” for the team
Evaluate at least one Microsoft-built or partner-built agent from the Security Store for a high-volume repetitive task if you are an MSSP

Closing the series

Six parts in, the picture should be clear: the Microsoft Sentinel transition to Defender is not a forced UI swap. It is the consolidation of SIEM and XDR into a single operating model—one incident queue, one detection rules view, one hunting surface, one governance plane, and a single AI-first toolchain.

Everything you have built carries forward. Analytics rules continue to fire. Playbooks continue to run. Workbooks continue to render. Your Azure RBAC continues to govern. And the new capabilities—XDR correlation, custom detections, Security Copilot, the data lake, UEBA on multi-cloud, MDTI convergence, SOC optimization—are the upside you collect for making the move.

March 31, 2027 sets the deadline. The adoption helper sets the starting line. Everything in between is yours to design—and this series exists so you can design it with confidence.

Read the rest of the series

Each part in this series stands alone—pick the angle that matters most to you, or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 4 – The governance shift: RBAC, URBAC, data lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multi-tenant patterns.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

What’s new in Microsoft Sentinel: June 2026

TomerBrand — Tue, 30 Jun 2026 16:43:18 GMT

Welcome back to What's new in Microsoft Sentinel. In June, Sentinel SIEM’s Advanced Security Information Model (ASIM) broadens its normalization, so one analytic rule can reach more sources with less per-source work and, additionally, two new ASIM schemas can now bring asset inventory and AI agent telemetry into common form. In Microsoft Sentinel data lake, the Agent Identities Asset Connector adds the identity context behind your AI agents, helping you see who owns an agent and what permissions it holds. In Sentinel MCP, graph tools help security teams investigate threats and optimize security coverage by visualizing relationships across identities, devices, alerts, and signals in a unified graph experience.

Read on for the details, and explore the resources at the end to go deeper.

Sentinel innovations:

Sentinel SIEM
Sentinel data lake
Sentinel MCP
Microsoft Security Store

Sentinel SIEM

Advanced Security Information Model (ASIM) parsers and schemas [Generally available]

The Advanced Security Information Model (ASIM) in Sentinel normalizes logs into common schemas, so one analytic rule can cover many sources without managing each native schema. ASIM coverage has expanded across more Azure services, broader AWS CloudTrail activity, and a range of third-party firewall, identity, and proxy products, so your detections reach more of your environment with less per-source work. Two schemas also join ASIM: Asset Entities normalizes asset inventory so you can correlate files and assets across investigations, and AI Agent Events normalizes telemetry from AI-driven workflows and autonomous agents. Browse the ASIM parsers on GitHub to explore, file issues, or contribute. Learn more in our blog.

Sentinel transition to Defender blog series

By March 31, 2027, all Microsoft Sentinel customers transition to Defender. This six-part series guides you through moving your Sentinel experience from the Azure portal to Defender, where SIEM, XDR, threat intelligence, AI, and automation come together in one experience. Your analytics rules, playbooks, workbooks, log analytics workspace, and access assignments all carry forward while the operational layer becomes more connected and intelligent. Starting early matters because you realize the benefits sooner, including a unified incident queue, cross-product correlation, Security Copilot, Sentinel data lake, and SOC optimization. Across the six-part blog series you get 1) the strategic shift, 2) the anatomy of incident and data changes, 3) detection and automation, 4) the governance shift across roles and access, 5) a readiness playbook with the adoption helper and cost guidance, and 6) a look at the AI-first SOC. Each part stands alone, so you can read in order or jump to what matters most to you.

Sentinel data lake

Agent Identities Asset Connector [Public preview]

The Agent Identities Asset Connector brings identity context for AI agents into Sentinel. Activity connectors like Agent 365 and Microsoft 365 Copilot already show you what AI agents do, but activity alone cannot tell you who owns an agent, what permissions it holds, or how it is governed. This connector fills that gap with four asset tables covering agent owners, agent identities, agent blueprints, and the service principals tied to those blueprints. Together they form a connected agent identity graph you can trace from owner to identity to blueprint to permissions to the resources an agent touches. Joining this asset data with activity data in Sentinel data lake lets you detect anomalous behavior relative to permissions, spot over-permissioned or misconfigured agents, and follow full execution chains for end-to-end traceability. To get started, install the Agent 365 and Microsoft 365 Copilot solutions in Content Hub and enable the asset and activity connectors. Learn more.

Sentinel MCP

Sentinel MCP graph tools [Public preview]

Microsoft Security Graph MCP tools, recently introduced in the Microsoft Sentinel MCP Server data exploration collection helps security teams investigate threats by exploring relationships between identities and device assets, and threat and activity signals ingested by data connectors and surfaced by analytic rules. Starting from an alert, analysts can follow the exposure path across connected entities — tracing lateral movement, understanding blast radius, and identifying configuration gaps — all from a single, interactive workspace. The tool provides a clear graph view that highlights dependencies and makes it easier to understand how content interacts across your environment. This helps security teams assess coverage, optimize content deployment, and identify areas that may need tuning or additional data sources. Executing graph queries via the MCP tools will trigger the graph meter. Learn more.

Microsoft Security Store

Partner testimonials from Adaquest and Glueckkanja

For partners like Adaquest and Glueckkanja, the Microsoft Security Store helps not only put their years of knowledge, understanding, and best practices into a scalable, packaged solution, it gives them the ability to democratize that expertise and take it to market globally. Security Store operationalizes their expertise as always-on defenses — discoverable, deployable, and driving real outcomes inside the tools that security teams rely on every day.

See how the Security Store is helping security teams act on threats faster with the right solutions and to be ready when it matters most:

Additional resources

Blogs and documentation:

Upcoming webinars and events:

July 15–16: Microsoft Virtual Training Day: Predict and Defend Against Cybersecurity Threats
July 22: Microsoft Security Immersion Event: Shadow Hunter
July 23-24: Microsoft Virtual Training Day: Introduction to Microsoft Security
July 28: Tech Brief: Modernize security operations with a unified platform
July 29: Security Immersion Event: Into the Breach

Stay connected

Check back each month for the latest innovations, updates, and events to ensure you’re getting the most out of Microsoft Sentinel. We’ll see you in the next edition!

Your readiness playbook: adoption helper, costs, APIs, and the checklist

Mohit_Kumar1 — Mon, 29 Jun 2026 16:00:00 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

The transition is not a project—it is a sequence of small, ordered decisions. Here is the readiness tool that scores your environment in minutes, the cost story you can take to finance, the API strategy that future-proofs your integrations, and the FAQ list that answers the questions your team is already asking.

Most transition anxiety comes from not knowing what you do not know. The Defender transition is mature enough that Microsoft has packaged the readiness work into a script, the cost work into an estimator, and the API work into a clear migration story—and the most common questions are already answered.

This part is the practical playbook. It does not introduce new architecture; it gives you the levers you can pull right now to know exactly where you stand, what it will cost, what to integrate with, and how to brief the people asking questions.

What this post covers

Defender adoption helper: a free readiness assessment with a visual dashboard
Cost story: identical Sentinel pricing, optional new capabilities, and the new estimator
The API strategy: SecurityInsights for workspace, Defender APIs for SOC, Graph security for the long run
FAQ list: the five questions every stakeholder asks, answered
Persona implications, common misconceptions, and a do-this-week checklist

Defender adoption helper

Overview

The Sentinel-Defender-helper-script is a PowerShell-based assessment tool designed to evaluate the readiness of Microsoft Sentinel workspaces before onboarding them into Microsoft Defender. It automates the discovery of potential compatibility issues, configuration gaps, and behavioral changes that organizations should address prior to the transition. The tool generates a structured CSV output that feeds an interactive HTML dashboard, providing security teams with a clear, visual summary of findings and actionable recommendations.

Important: This script is not an official Microsoft product or supported solution. No Microsoft Customer Services & Support (CSS) ticket can be raised for issues related to this tool, and bug fixing is not guaranteed beyond the author's willingness to maintain it. No rights can be derived from this solution—incorrect or missing information generated by this script may lead to customer production disruption. Test it before using it in production environment.

How it works

The tool operates in three phases:

Authentication

The operator authenticates against Microsoft Entra ID using one of two supported modes. In User mode, the script initiates an interactive device code flow through the browser, leveraging the well-known Azure PowerShell first-party client ID — no app registration is required. In app mode, a pre-configured service principal with a client secret is used for unattended execution. In both cases, the account must hold the Microsoft Sentinel Reader role on each target workspace.

Analysis

For each workspace defined in the sentinelEnvironments.json configuration file, the script calls the Azure Resource Manager REST APIs to inspect five areas:

Defender data – Queries the retention settings of 21 Defender tables (e.g., DeviceInfo, EmailEvents, IdentityLogonEvents). Tables with default 30-day retention do not need separate ingestion into Sentinel, whereas tables with extended retention (e.g., 730 days) must continue to be stored in the log analytics workspace.
Analytics rules – Examines every analytics rule for conditions that may cause issues after onboarding: Fusion engine enablement (Fusion is automatically disabled post-transition), rules that do not generate incidents (alerts become invisible in Defender), incident reopening settings (not supported in Defender—new incidents are created instead), custom alert grouping (overridden by the Defender XDR correlation engine), and Microsoft incident creation rules (deactivated after onboarding). Disabled rules are flagged as informational only.
Automation rules – Inspects automation rule triggers and conditions for deprecated or incompatible patterns: use of incident title instead of analytics rule name, use of incident provider instead of alert product name, dependencies on Fusion-generated incidents, reliance on the description field (removed from SecurityIncident after onboarding), the Updated By = Microsoft 365 Defender value (which becomes Other), and alert-based triggers (which will only fire for Sentinel-originated alerts post-transition).
Data lake region – Verifies whether the workspace region supports the data lake (Auxiliary tier) capability, checking against the list of currently supported Azure regions.
Table tiers – Enumerates all tables in the workspace and flags those using the basic tier, which must be converted to analytics or auxiliary before onboarding. Tables already on the auxiliary tier are noted as future data lake tables.

Output

All findings are collected into a flat CSV file (results.csv) with a consistent schema containing the row type (env, check, or score), workspace name, section, severity status, a human-readable message, and an optional sub-item identifier for grouping (e.g., the rule name). Per-section scores and a final readiness percentage are calculated automatically. The data lake checks are reported separately and do not affect the final readiness score.

Severity classification

Status	Meaning
Ok	No action required—the configuration is compatible with Defender.
Warning	Requires attention before onboarding—the configuration will cause a behavioral change or loss of functionality.
Informational	No action required and does not block migration (e.g., tables with default retention, disabled rules). Counts as passed in the final score.

Analyzing the findings

The generated CSV is loaded into the accompanying HTML dashboard (dashboard.html), which provides:

A multi-workspace overview with readiness scores and pie charts for each environment
Per-workspace detail panels that break down findings by section (Defender data, analytics, automation, data lake region, table tiers)
Multi-select filters to isolate Ok (Passed), Warning, or Informational findings
Grouped rule views—analytics and automation rules are grouped by name, with individual sub-checks shown underneath
Items overview cards summarizing the count and distribution of findings per section
Export to PDF—either per workspace or across all environments at once
Direct Azure portal links for each section, allowing operators to navigate directly to the relevant blade
A built-in knowledge base with recommendations mapped to official Microsoft documentation
A multitenant guidance tab covering access models (GDAP, Azure Lighthouse, B2B collaboration), MSSP best practices, and known limitations

Project contents

File	Description
DefenderAdoptionHelper.ps1	Main PowerShell script that performs the assessment via Azure REST APIs and generates the CSV output
dashboard.html	Self-contained interactive HTML dashboard that visualizes the CSV findings
sentinelEnvironments.json	Configuration file listing the Sentinel workspaces (subscription ID, resource group, workspace name) to be analyzed
results.csv	Generated output file consumed by the dashboard

Why this lands well: You go from “I think we are ready” to a percentage score and a list of named items in under an hour—with a knowledge base that links each finding to documentation. The hardest part of any migration is no longer the hardest part.

Cost story

Cost model

The Microsoft Sentinel pricing remains same for analytics tier data. The cost advantage of Defender comes from flexible billing and features (data lake, graph, MCP) that don’t exist in the Azure portal.
Use the new Sentinel cost estimator to analyze your data ingestion and retention cost.

Sentinel data lake can introduce variable cost, but in most environments, it reduces overall cost meaningfully—by letting you keep long-tail data in a cheaper tier instead of paying analytics-tier rates for data you rarely query.

Reference SKU table

SKU	Meter type	Price
Data lake ingestion	Data processed (GB)	$0.05 USD
Data processing	Data processed (GB)	$0.1 USD
Data lake query	Data analyzed (GB)	$0.005 USD
Advanced data insights	1 compute hour	$0.15 USD
Data lake storage	Data stored (GB/month)	$0.026 USD
Graph	1 compute hour	$3 USD

Why this lands well: Same analytics tier price, plus new tiers and capabilities that let you do things you simply could not do before. Run the estimator before you guess—most teams find the data lake reduces total spend once long-retention data is moved off the analytics tier.

The API strategy

The SecurityInsights API remains operational, but its coverage is scoped to Sentinel-specific resources and data. It does not surface Defender XDR incidents, Advanced Hunting data, or unified SecOps capabilities - meaning integrations built on it will lack access to the core unified experience.

Organizations relying on the SecurityInsights API should plan to migrate to the Microsoft Graph Security API as soon as possible. The Graph API provides unified coverage across Defender XDR incidents, Advanced Hunting, cases, and all emerging SecOps capabilities—areas the legacy Sentinel-only API does not expose. Migrating now reduces integration debt as Sentinel capabilities continue to consolidate into the unified Defender portal.

Common tasks

Create/update a Sentinel incident (workspace object): SecurityInsights incidents
List/manage Sentinel analytics rules: SecurityInsights alert rules
Integrate with unified incidents: Defender incidents API and Graph security incidents
Run Defender hunting programmatically: Graph security runHuntingQuery

Sentinel versus Defender versus Microsoft Graph security

Dimension	Microsoft Sentinel REST API (SecurityInsights)	Microsoft Defender APIs	Microsoft Graph security API
API surface	Azure resource manager (ARM) API under Microsoft.SecurityInsights	Product-specific REST APIs (/api/*) for Defender	Unified Microsoft Graph endpoint (/security/*)
Primary purpose	Workspace configuration and SIEM/SOAR management	Operational SOC actions in Defender	Unified security operations and automation across products
Typical usage	Infrastructure and content lifecycle management	Incident, alert, and detection operations	Cross-solution incident, alert, hunting, and threat intelligence integration
Scope of data	Sentinel-only (workspace-scoped)	Defender detections and signals	Aggregated signals across Defender + Sentinel
Incidents access	Sentinel incidents (Azure portal model)	Defender incident model	Unified incident model (Defender + Sentinel)
Alerts access	Analytic rule-generated alerts	Defender alerts	Unified alerts across providers
Detection management	Yes (analytic rules; automation rules)	Yes (custom detection rules)	No (read/act; no rule authoring)
Hunting	Yes (KQL via log analytics)	Yes (Advanced hunting)	Yes (Advanced hunting through runHuntingQuery)
Threat intelligence (IOCs)	Yes (TI CRUD; TAXII/STIX)	Limited	Yes (unified threat intelligence submission and investigation)
Automation and SOAR	Yes (logic apps playbooks; automation rules)	Limited native automation	Yes (event-driven workflows via Graph+ logic apps)
Authentication and permissions	Azure RBAC + Entra ID	Entra app permissions (Defender scopes)	Entra app permissions (Graph; unified RBAC)
Portal alignment	Azure portal (legacy Sentinel UX)	Microsoft Defender	Microsoft Defender
Multitenant/MSSP	Azure-subscription centric	Supported	Best fit through Graph + GDAP / MTO models
Strategic direction	Configuration and management API	Product API (still supported)	Strategic, long-term unified API

Microsoft Graph security API – Overview

The Microsoft Graph security API provides a unified interface and schema to integrate with security solutions from Microsoft and ecosystem partners; it federates queries to onboarded security providers and aggregates responses.

What you use it for (common SOC/platform scenarios)

Consolidate and correlate security alerts from multiple sources
Pull and investigate incidents and alerts from services that are part of or integrated with Microsoft Defender
Automate security tasks/workflows/reporting and send threat indicators (where applicable) into Microsoft products

Advanced hunting through Graph (high-value capability)

Graph security supports advanced hunting through runHuntingQuery, allowing you to run KQL on Microsoft 365 Defender advanced hunting tables and use results to enrich investigations.

Quotas/limits to keep in mind

Queries generally explore up to the past 30 days of data
Results can return up to 100,000 rows
You can make at least ~45 calls/min/tenant (varies by tenant size); requests can be throttled with HTTP 429 when resources are exhausted
If a request runs longer than 3 minutes, it times out
Query output has an overall 50 MB size limit

Why this lands well: You do not have to rewrite anything urgently. Keep using SecurityInsights for Sentinel workspace work, layer Defender APIs for operational SOC actions, and treat Microsoft Graph security as the strategic direction for anything new—a single endpoint that already federates across products.

FAQ list: Questions every stakeholder asks

“Is this transition mandatory?”

Yes, but you have time. After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in Microsoft Defender. All customers will be redirected to Defender for Sentinel security operations.

However, starting your transition now is strongly recommended to immediately access exclusive capabilities like Security Copilot, Sentinel data lake, and SOC optimization—features only available in Defender.

“Do I need to migrate my workspace?”

Workspace migration is not required. This is a common misconception. Your Sentinel workspace, log analytics workspace, and all data remain in their current Azure location. The transition is simply connecting your existing workspace to Defender for management.

Nothing about your data storage, retention, or access changes. You are not moving data—you are adding a new portal interface to the same underlying workspace.

“Will my costs change?”

There isn’t a cost change from the portal transition itself. Your Microsoft Sentinel pricing and billing model remains identical regardless of which portal you use. Data ingestion costs, commitment tiers, and log analytics charges all stay the same.

The only new potential costs are optional features available exclusively in Defender:

Security Copilot: Requires separate licensing if you want AI-powered investigation assistance
Sentinel data lake: Only incurs charges if you enable long-term retention beyond standard 90-day analytics tier

Standard Sentinel operations (data connectors, analytics rules, automation, hunting) have zero cost change from transitioning.

“Can I still use Azure portal?”

Yes, until March 31, 2027. During the transition period, you can use both portals simultaneously:

Azure portal for configuration management (data connectors, analytics rules, automation)
Defender for security operations (incidents, hunting, investigations)

Many organizations adopt a hybrid approach during transition: security analysts work primarily in Defender for day-to-day operations, while SOC engineers use the Azure portal for configuration and rule development.

After the March 2027 deadline, Sentinel security operations will only be available in Defender. However, the underlying Azure infrastructure (log analytics workspace, logic apps for playbooks) will remain accessible through the Azure portal for resource management.

“What if I use multiple workspaces?”

Multiple workspaces are fully supported. Defender has robust multi-workspace capabilities:

How it works:

Connect all your Sentinel workspaces to Defender (one-time setup per workspace)
Designate a primary workspace that feeds the unified incident queue
Use the workspace switcher in Defender to view or query other workspaces
Advanced Hunting can query across multiple workspaces simultaneously using the workspace function

For MSSPs managing customer tenants:

GDAP (granular delegated admin privileges) is now supported in Defender with MTO including Sentinel capabilities
Azure Lighthouse continues supporting cross-tenant workspace management
Each customer tenant’s workspaces can connect to Defender

Considerations:

Only the primary workspace contributes to the unified incident queue
Other workspaces are accessible for hunting, queries, and investigation but don’t merge incidents into the main queue
This prevents overwhelming analysts with incidents from test/dev workspaces while maintaining access to all data

Why this lands well: Every objection your stakeholders raise has a clean, source-grounded answer—mandatory but with runway, no data move, no surprise cost, two portals during transition, and full multi-workspace support.

Persona implications

Persona	What this part means for you
SOC manager	Run the adoption helper across all workspaces and use the dashboard to brief leadership with a readiness score, not a hunch.
Architect	Use the API comparison to plan your long-run integration story: SecurityInsights for workspace config, Defender APIs for SOC ops, Graph security as the strategic direction.
Finance/FinOps	Run the Sentinel cost estimator with current ingestion and retention numbers. Model what moving long-retention data from analytics to data lake does to monthly spend.
Integration engineer	Inventory existing SecurityInsights API consumers; decide which new integrations should be built on Graph security from the start.
Stakeholder/ Sponsor	Use the FAQ list as a one-pager for executives and security leadership—the five questions everyone asks, with grounded answers.

Clearing up common misconceptions

“This is a workspace migration.”
It isn’t. Your Sentinel and log analytics workspaces stay where they are—you connect them to Defender.
“Costs will go up automatically.”
Analytics tier pricing is unchanged. New cost only appears if you opt into Security Copilot or enable the data lake—and the lake often reduces total cost when long-retention data moves off the analytics tier.
“My API integrations will break on day one.”
SecurityInsights remains the API for Sentinel workspace operations. Defender APIs and Graph security extend the surface area—they do not replace what you have.
“I have to pick one portal.”
Until March 31, 2027, both portals are supported. Most teams run a hybrid model during transition.
“My multi-workspace setup will not work.”
It will. Multi-workspace is fully supported. Designate a primary for the unified queue and use the workspace switcher for the rest.
“I need an app registration to run the adoption helper.”
Not required. User mode uses the well-known Azure PowerShell first-party client ID through device code flow—no App Registration required. App mode is available for unattended runs.

Do this week

Clone the Defender adoption helper and run it across at least one production workspace; open the dashboard and walk the findings with your SOC team.
Take the warnings the adoption helper surfaces and create one tracking item per warning (analytics rule cleanup, automation rule cleanup, table tier conversions).
Run the Sentinel cost estimator with your current ingestion + retention numbers—model the lake scenario for long-retention tables.
Inventory which systems call the SecurityInsights APIs today; for any new integration starting this quarter, default to Microsoft Graph security.
Circulate the FAQ list (or a one-pager version of it) to executives and security leadership before they ask.
Confirm whether your primary workspace region supports the Sentinel data lake—it determines part of the tiering plan.
Calendar a transition kickoff for the next two weeks—the readiness work above gives you exactly the right inputs.

Continue the series

Each part in this series stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 4 – The governance shift: RBAC, URBAC, data lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multitenant patterns.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.

The governance shift: RBAC, URBAC, data lake, and MSSP

Mohit_Kumar1 — Thu, 25 Jun 2026 20:11:19 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

Governance is the silent dependency every transition trips on. Read about how roles, data tiering, and multi-tenant operations evolve in Defender, and why each change unlocks something your old model could not.

Detection engineers debate KQL. Architects debate roles. The Defender transition is interesting because it updates to simply both - but the governance changes are the ones that quietly determine whether your unified SOC actually works the way you designed it on the whiteboard.

The good news: everything is normal on day one. Your existing Azure RBAC assignments keep functioning. Your Sentinel data stays where it is. Your MSSP delegations remain intact. What changes is what is now possible: data-scoped permissions that are not tied to a single workspace, a tiered data model that lets you keep years of history without keeping years of analytics-tier cost, and a multi-tenant view that spans up to 100 customer tenants with a single sign-in.

This post walks through each governance shift, what carries forward, and what is genuinely new—from the perspective of the architect who has to sign off and the SOC lead who has to operate it.

What this post covers

Roles and personas: who owns what after the transition
From classic Azure RBAC to Unified RBAC (URBAC): coexistence, then convergence
The data lake as a governance construct: tiering, retention, residency
Multi-tenant management and the MSSP operating model
Persona implications, common misconceptions, and a do-this-week checklist

Roles and personas: nothing breaks on day one

Transitioning to Defender does not eliminate existing Azure RBAC assignments – all continue to function. Once URBAC is activated, it becomes the source of permissions/authorization. The unified platform introduces a new permissions model: Microsoft Defender XDR Unified RBAC (URBAC), which can coexist with or replace classic Azure RBAC for Sentinel access.

Once URBAC is enabled in Defender, URBAC becomes the source of permissions and not Azure RBAC. It is preferred to migrate the classic Sentinel roles to URBAC ones after onboarding the log analytic workspaces.

Before transitioning, SOC leads and identity administrators should review the full role matrix and persona assignments and understand which personas require updated assignments. Customers can import roles using the import wizard; this way there is no need to create URBAC roles manually.

Why URBAC is the upgrade: URBAC is data-scoped + cross-workspace, not tied to a single workspace boundary. Another benefit of migrating to URBAC is the use of Sentinel scoping with row-level RBAC. And finally, it allows you to manage all of your roles and permissions in a single holistic access management system.

Persona-by-persona view

Security analysts – Triage and investigate incidents using the unified incident queue; require the Security Operator unified RBAC role. Entra global roles are not required for incident triage across Defender and Sentinel—a custom Defender unified RBAC role provides the necessary permissions with more granular scoping.
Security engineers – Build detections, manage content, and onboard data; require Sentinel Contributor (see mapping with URBAC). For SOAR tasks, roles such as logic app Contributor and Microsoft Sentinel automation Contributor can still be managed and assigned to Security engineers using Azure RBAC
SOC managers / architects – Plan RBAC strategy and map existing Azure RBAC to URBAC; govern least-privilege access across workspaces
Automation – Execute playbooks and automation rules; the roles related to automation (Microsoft Sentinel automation Contributor, logic app Contributor, Microsoft Sentinel playbook Operator) post-transition are not yet supported through URBAC, but can still be managed using Azure RBAC
Service principals – Service principals are currently not supported in URBAC; assigning permissions to a service principal or GDAP user group is planned to go public preview soon. Do not enable URBAC if service principals are in use in Microsoft Sentinel in the Azure portal.

Why this lands well: Day One continuity for every existing role assignment, with a clear path to a more capable model. You choose when to flip URBAC on, the import wizard does the heavy lifting, and you get data-scoped, cross-workspace permissions you never had in classic Sentinel.

Azure RBAC and URBAC: coexistence, then convergence

The transition does not force a permissions cutover. Sentinel permissions currently configured keep working exactly as they do today. You can also use URBAC for Sentinel permissions, ensuring you can manage your access management for Defender and Sentinel in a single holistic access management system. Once you turn URBAC on, it becomes the source of truth for permissions instead of Azure RBAC.

How they compare

Dimension	Classic Azure RBAC (Sentinel)	Unified RBAC (URBAC) in Defender
Scope model	Workspace-bound—a role grants access to one log analytics workspace at a time. In addition, you can configure row and table level conditions	Workspace-bound and scoped; A role grants access to one or more log analytics workspaces at the time, while also providing row-level Sentinel scopes if desired
Permissions surface	Reader, Responder, Contributor (plus automation-specific roles like logic app Contributor, playbook Operator)	Reader, Responder, Contributor created through URBAC custom roles; classic roles map in through the import wizard
Source of truth	Source of permissions until URBAC is enabled	Once enabled in Defender, URBAC becomes the source of permissions—not Azure RBAC
Service principals	Fully supported	Not currently supported in URBAC—keep managing these through Azure RBAC, even when URBAC is enabled
Automation roles	Logic app Contributor, Microsoft Sentinel automation Contributor, playbook Operator	Not currently supported in URBAC—keep managing these through Azure RBAC
Row-level scoping	Possible through log analytics row-level or table-level conditions, but this does not propagate to Sentinel experiences	Sentinel scoping (row-level access) supported and propagates to experiences (alerts, hunting, incidents)

Transition considerations

Onboard the log analytics workspaces first, then move the classic Sentinel role assignments to URBAC
Use the import wizard rather than re-creating URBAC roles manually—it preserves your existing assignment intent
If you rely on service principals for any Sentinel access (CI/CD, automation, integrations), please be aware that these are not yet supported in URBAC. The import wizard will detect this and will import the roles, but not assign them to service principals. If the role only includes service principals in the assignment, it can't be imported. Track the URBAC roadmap and plan accordingly, this support will be available soon. You can continue to configure these in Azure RBAC for now, even when URBAC is enabled.
Keep automation-related role assignments in Azure RBAC—they are not supported through URBAC today.
When you enable URBAC and assign roles, they are synchronized back to Azure as well. For example, a Sentinel Reader role created in URBAC will also create the role in Azure RBAC. If you then change the role in Azure RBAC (instead of on URBAC), it can create a sync issue. Disabling and enabling the workspace on URBAC will resolve the issue. This does not affect scenarios where Azure RBAC is the only source of permissions (logic apps for example), but it is something to be aware of.
Take advantage of row-level RBAC and cross-workspace scoping where you previously had to compromise.

Why this lands well: You get a more capable permissions model without a forced cutover. Classic roles keep working, the import wizard handles the migration, and the new data-scoped model finally matches the way modern SOCs think about access.

Sentinel data lake as a governance construct

All data ingested into the analytics tier (log analytics workspace) is automatically mirrored into the Sentinel data lake tier when Sentinel data lake is enabled, ensuring a single authoritative copy of security data that can be queried using KQL, notebooks, and advanced hunting tools without duplicating ingestion pipelines.

Security architects should use Sentinel data lake for historical threat hunting, retroactive IOC matching, compliance retention, and AI-assisted investigations, while keeping latency-sensitive detections and alerts in the analytics tier. Use the Sentinel cost estimator to calculate your environment’s need and refer to the pricing table to know more.

What the data lake gives you

Supports interactive and async KQL queries across all connected Sentinel workspaces.
Query external data sources without moving data (Public Preview), including Microsoft Fabric, Azure Databricks, and Azure Data Lake Storage Gen2.

Transition considerations

Sentinel data lake must be provisioned in the same Azure region as the primary Sentinel workspace and is not available in all regions—check the latest geographical availability and data residency.
When Sentinel is accessed through Defender, processed and configuration data may follow Defender regional processing, which can differ from the log analytics workspace region.
Customer-managed keys (CMKs) are not supported for data stored in the Sentinel data lake; Microsoft-managed keys are used.
Compare the analytics tier and data lake tier when sizing your retention strategy.

Region availability note: Sentinel data lake is not available in all Azure regions. Validate availability for your primary workspace region before planning enablement—the supported regions list is the authoritative reference and is updated as new regions come online.

Why this lands well: You finally separate “hot” detection data from “warm/cold” investigation data without rebuilding pipelines. One copy of the truth, two tiers, KQL across both—and a clear regional/governance story you can take to your data protection officer.

Multitenant management and the MSSP operating model

MSSPs and large multitenant enterprises have always had to stitch together Lighthouse, GDAP, and per-workspace navigation. Defender does not eliminate those building blocks—but it does add a unified cross-tenant view that genuinely simplifies day-to-day operations.

Azure portal versus Defender for multitenant

Portal	Multi-tenant model
Azure portal	Azure Lighthouse for cross-tenant visibility through ARM delegation Multi-workspace incident view; analysts pivot between workspaces for deep investigation Cross-workspace KQL through workspace operator (recommended to limit up to 10 workspaces to avoid latency and timeout) Per-workspace Azure RBAC; no centralized cross-tenant role management
Defender	Multitenant management (MTO) unified view across up to 100 tenants with single sign-in Unified incident queue, cross-tenant advanced hunting (SIEM + XDR), and content distribution profiles Dual RBAC: Azure RBAC for data + unified RBAC (URBAC) for portal access, currently with B2B, with centralized management Critical: MTO does not replace Lighthouse—Lighthouse is still required to access Azure resources such as Azure policy and function apps GDAP for Sentinel in Public Preview

Transition considerations

Maintain Lighthouse: Do not remove existing delegations—Lighthouse is still required to access Azure resources such as Azure policy and function apps.
100-tenant limit: Large MSSPs may need multiple MTO configurations or prioritize active tenants. MSSPs can also leverage tenant groups to organize tenants collectively and switch multitenant view between groups. Microsoft hasn't published a timeline for raising this ceiling—monitor the Defender XDR release notes for updates
Tenant-boundary isolation: Correlation engine operates within tenant boundaries—incidents never merged across tenants.
Playbook distribution gap: Automation rules and playbooks (logic apps) are not currently supported as distributable artifacts through MTO content distribution profiles, but you do have the ability to run logic apps hosted on “home tenant” to run on “target tenant” without deploying the artifact.

Where partners and MSSPs add value

Managed security service providers (MSSPs) and Microsoft partners bring specialized expertise in planning and executing Sentinel transitions to Defender. Partners accelerate your transition timeline, reduce operational risk, and ensure your team maximizes the value of unified security operations from Day One.

Key advantages of working with a partner:

Transition expertise: Partners have hands-on experience transitioning multiple customer environments and can anticipate challenges specific to your industry, architecture, and security maturity level.
Multi-tenant complexity: MSSPs managing Sentinel for multiple customers can navigate enhanced GDAP delegation, Azure Lighthouse configurations, and cross-tenant workspace management.
Accelerated onboarding: Partners provide structured onboarding programs combining technical setup, SOC analyst training, and workflow optimization to minimize time to value.
Custom automation development: Partners can develop logic apps playbooks, custom analytics rules, and hunting queries tailored to your environment and threat landscape.
Ongoing optimization: Post-transition, partners offer SOC optimization services leveraging the enhanced capabilities in Defender including AI-powered recommendations, cost management, and detection coverage gap analysis.

To find Microsoft partners specialized in Sentinel and Defender, visit partner.microsoft.com or consult your Microsoft account team for recommendations.

Why this lands well: A single cross-tenant view that does not force you to abandon what you have. Lighthouse + GDAP + MTO each do a different job, and the unified incident queue across tenants is the kind of capability MSSPs have been asking for.

Persona implications

Persona	What changes for you
SOC analyst	Single security Operator URBAC role across workspaces; the day-to-day triage experience does not require knowing which workspace an alert came from.
Security engineer	Sentinel Contributor maps into URBAC for SIEM content; keep logic app Contributor and automation Contributor in Azure RBAC for SOAR work.
SOC manager/ architect	You own the URBAC migration plan, the tier-versus-lake retention strategy, and the multi-tenant access model. Use the import wizard to preserve existing intent.
Data protection officer	The data lake adds a tier with its own residency and encryption story (Microsoft-managed keys, regional availability). Document it as part of your data flow inventory.
MSSP operator	Unified incident queue across up to 100 tenants; Lighthouse, GDAP, and B2B each remain in the picture but for different purposes. Plan tenant groups and content distribution profiles early.

Clearing up common misconceptions

“Turning on URBAC breaks my existing Azure RBAC assignments.”
No. Classic Sentinel roles continue to function. URBAC becomes the source of permissions once enabled, but it can be migrated from your existing assignments using the import wizard.
“I have to move my Sentinel data into the data lake.”
No. Data ingested into the analytics tier is automatically mirrored into the data lake when the lake is enabled—a single authoritative copy, no duplicate ingestion.
“MTO replaces Azure Lighthouse for MSSPs.”
No. MTO and Lighthouse coexist—Lighthouse is still required for Azure resource access (Azure policy, function apps); MTO provides the unified cross-tenant SOC view.
“If I enable URBAC, my logic apps playbooks break.”
No. Automation-related roles (logic app Contributor, automation Contributor, playbook Operator) keep working under Azure RBAC.
“Data lake is available everywhere Sentinel is.”
No. The data lake must be in the same Azure region as the primary Sentinel workspace and is not available in all regions—always check the geographical availability list before planning.
“MTO will merge incidents across tenants.”
No. The correlation engine operates within tenant boundaries—incidents are never merged across tenants. MTO provides visibility and operational consistency, not cross-tenant correlation.

Do this week

Inventory who holds which classic Sentinel role (Reader, Responder, Contributor, Automation roles) and which identities are service principals.
Defer URBAC enablement and document the dependency if any service principals hold Sentinel access.
Stand up a test URBAC scope using the import wizard—validate that analyst, engineer, and architect personas see what you expect.
Confirm your primary Sentinel workspace region is on the Sentinel data lake supported regions list.
Decide the analytics tier versus data lake tier split: which tables you want hot for detection and which you want warm for hunting/compliance.
Map your existing Lighthouse + GDAP footprint to the MTO model if you operate multi-tenant, and identify tenants for an initial MTO configuration (under the 100-tenant cap).
Schedule the transition planning session now if you work with an MSSP or Microsoft partner to compress weeks of work and surface issues you would otherwise find in production.

Continue the series

Each part of this series stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.

A guide to innovating threat hunting with Microsoft Sentinel custom graph

Matt_Lowe — Wed, 24 Jun 2026 18:06:41 GMT

Microsoft Sentinel platform offers a growing list of tools and features, with graph being a cornerstone capability.

Sentinel graph is a relationship-first method for organizing and querying data within Microsoft Sentinel data lake. Activities amongst entities (users, devices, emails, IPs, applications, etc.) become a navigable structure that avoids a complex table structure. Rather than stitching together data and evidence via complex joins, users can follow multi-hop connections in order to understand insights such as blast radius, unseen pivots in malicious behavior, and investigative details that may not be as obvious within regular logs, all while visualizing these paths to assist in communicating evidence and findings.

This blog will walk through how to create custom graphs using GitHub Copilot chat experiences in Sentinel VS Code. And how to leverage out-of-the-box graph samples to build custom graphs addressing security outcomes. Custom graphs are available in public preview.

Prerequisites and Tooling

Sentinel data lake enabled in the tenant, this is where the data for the graph will be stored.
Users will need read/write permissions on Sentinel data lake data. And either security operator or security admin permissions to save a custom graph in the tenant.
Visual Studio Code (VS Code) will need to be installed, as it is essential for building and saving graphs.
The Jupyter notebook extension, Microsoft Sentinel extension, and GitHub Copilot extension will need to be installed from within VS Code. These are key pieces for configuring and managing graphs.
(Optional) Microsoft Sentinel MCP server if using MCP tools like the data exploration tool.

Building a new custom graph

The starting point is within Visual Studio Code (VS Code), where the custom graph will be built via GitHub Copilot and the Sentinel graph authoring tool. Make sure to have a GitHub account logged in within VS Code, then start a chat with Copilot via View > Chat. This will open a chat window on the right side of the screen.

Determining security telemetry for investigation

If unsure about which tables are available within the environment or the columns to focus on for hunting/investigations, turn to the Sentinel MCP server. With the Sentinel MCP server, users can explore the threat landscape within their environment as well as see which data sources currently exist within the Sentinel data lake. This process can be done using natural language with Copilot to obtain the information needed to perform the task at hand.

“List the most important tables within my Microsoft Sentinel data lake environment that would build a blast radius for a compromised user account. List the best columns to use for this scenario. Format the response as a table”

The tables and columns that can be used are now known. The next step is to use these tables to construct a custom graph with help from GitHub Copilot. For this example, a blast radius graph will be built to assist in reviewing the impact of compromised accounts within the environment:

“List the top 5 compromised or targeted accounts within my environment. List which types of attacks are involved with those accounts. Summarize the information into a simple to read table”

Given this response, there are a few options for going forward:

Return to the Microsoft Defender portal and attempt threat hunting/review this with other analysts
Ask Copilot to provide threat hunting queries or perform incident investigations for the top users who are most targeted
Build custom graphs to visualize threat data around the most targeted accounts

For this example, we will use option 3.

Building graph mappings with GitHub Copilot

To begin building a custom graph from scratch, a new prompt is submitted, this time tagging the Sentinel extension’s graph authoring tool. An example of the type of prompt to use is below:

“@Sentinel /graph-authoring I want to investigate the blast radius of a compromised user and what systems/ app/ devices that they accessed based on users authentication activity. Please use at least SignInLogs, NonInteractivelogs, DeviceLogon, Onprem AD logs, IdentityInfo, and AADRiskyUsers.

The graph should help investigate the following security outcomes:

What is the user's current risk level and risk score from Identity Protection?

Which applications and resources did a user authenticate to?

Are there sign-ins from risky IP addresses, Tor exit nodes, or anonymizers?

Are there non-interactive sign-ins from unexpected locations or devices?

Which machines did a user log on to locally/remotely (RDP)?

Which user accounts have been active on a compromised device?

A few guidance for data ingestion:

Ensure to filter out any data that has NULL or empty values for key Nodes and Edges
Filter all data for last 14 days
Do not map json arrays as Keys in Nodes or Edges”

Note: To ensure that the graph that is written matches the desired scenario, it helps to provide outcomes or guidance to the graph authoring tool.

If a Juypter notebook is not already open within the VS Code, Copilot will build a new notebook based on the prompt given. Once Copilot is done, select a kernel to run the notebook. This can be done from the top right of the Notebook:

Click on Select Kernel.
Click on Microsoft Sentinel.
Choose a pool option for the compute cluster.
Once a pool is picked, click on the run button next to one of the code cells to boot up the compute pool (this can take up to 5 minutes)
Once connected, users can either go through and click the run button next to the code cell to run the code or click the Run All button at the top of the Notebook.

For each cell in the Notebook:

Cell 2

This section of the notebook is for mporting the sentinel_graph library and configures Spark settings. This is essentially setting up the notebook environment for executing the rest of the code.

from sentinel_graph import notebook notebook.requires(sentinel_graph="0.3.8") spark.conf.set("spark.sql.parquet.datetimeRebaseModeInRead", "CORRECTED")

Cell 3

This section is performing more Sentinel specific configurations by defining which Sentinel workspace to use, which timerange to use, which tables to use, etc. This is defining which data sources should be considered when building the graph.

from pyspark.sql import functions as F from sentinel_lake.providers import MicrosoftSentinelProvider lake_provider = MicrosoftSentinelProvider(spark=spark) LOG_ANALYTICS_WORKSPACE = "Woodgrove-LogAnalyiticsWorkspace" # Auto-detected from the Microsoft Sentinel extension TARGET_USER = "ram723@int.zava-private.com" # Time filter — 7 days for broader blast radius context time_filter = F.col("TimeGenerated") >= F.expr("current_timestamp() - INTERVAL 7 DAYS") # --- IdentityInfo: user profile, roles, group memberships, risk --- df_identity_info = ( lake_provider.read_table("IdentityInfo", LOG_ANALYTICS_WORKSPACE) .filter(time_filter) .filter(F.lower(F.col("AccountUPN")) == TARGET_USER.lower()) ) # --- SigninLogs: interactive sign-ins to resources --- df_signins = ( lake_provider.read_table("SigninLogs", LOG_ANALYTICS_WORKSPACE) .filter(time_filter) .filter( (F.lower(F.col("UserPrincipalName")) == TARGET_USER.lower()) & (F.col("ResultType") == "0") # successful sign-ins ) )

Cell 4

This section is defining and building the nodes that will be used in the graph. The definitions include what events look like, which entities are involved, and how they are considered for each node type.

# 1. User node (the target user) user_nodes = ( df_identity_info .select( F.col("AccountUPN"), F.col("AccountDisplayName"), F.col("RiskLevel"), F.col("RiskState"), F.col("AssignedRoles"), F.col("GroupMembership"), F.col("BlastRadius"), F.col("Department"), F.col("JobTitle"), F.col("IsMFARegistered"), F.col("IsAccountEnabled") ) .distinct() .withColumn("AccountUPN", F.lower(F.col("AccountUPN"))) )

Cell 5

This section is building out the schema for the graph. The schema for a graph is taking the columns and details from the tables in cell 3 while also tying them to the nodes and edges built in cell 4.

# Build nodes first builder = ( GraphSpecBuilder.start() # === NODES === .add_node("User") .from_dataframe(user_nodes) .with_columns("AccountUPN", "AccountDisplayName", "RiskLevel", "RiskState", "AssignedRoles", "GroupMembership", "BlastRadius", "Department", "JobTitle", "IsMFARegistered", "IsAccountEnabled", key="AccountUPN", display="AccountUPN") # Then add edges and finalise into a GraphSpec spec = ( builder # === EDGES === .add_edge("AccessedInteractive") .from_dataframe(edge_user_resource_interactive) .source(id_column="UserUPN", node_type="User") .target(id_column="ResourceName", node_type="Resource") .with_columns("AppDisplayName", "TimeGenerated", "IPAddress", "ConditionalAccessStatus", "AccessType", "EdgeKey", key="EdgeKey", display="AccessType")

Cell 6

This cell will take the schema from cell 5 and will load it into the graph visual builder. This will give a sample of what the graphs made with this Notebook will look like. These samples are fully interactive and will give an example of how it will look within the Defender portal. For example:

Please note that the Authoring Agent may provide a different looking schema if following along with this example. The schema above is just meant to provide an example of what one will look like within a Notebook.

Cell 7

This cell is taking each of the following steps performed and is going to compile and build the graph based on the data from the Sentinel data lake. This may take a few minutes to perform.

With the custom graph built, the next step is to create a Graph Job to save the custom graph in the tenant for persistent use. If necessary, users can go back into the notebook to refine, expand, and improve the custom graph.

Publishing graph

Publishing a graph is the process of saving the graph in a tenant, allowing for the graph to be scheduled for recurring refreshes or as needed. This process saves the graph to the tenant and enables other SOC members to access this graph from within the Defender portal.

To publish a custom graph, this must go through a Graph Job. This option is available within the Notebook experience as a button near the top:

Clicking on the Create Scheduled Job button will open a new tab within VS Code with the jobs settings and the option to publish:

There are two types of job schedules:

On Demand: Saves the custom graph to the tenant and will persist the custom graph for 30 days. After 30 days, the graph will be auto deleted.
Scheduled: Saves the custom graph to the tenant and will rebuild with new security telemetry based on a user defined schedule.

Once everything is prepped, the custom graph can be published to the tenant by hitting the Submit button. Users can view and monitor the creation progress by finding the graph within the Sentinel extension navigation as it shows the graphs available for the environment:

Finding and selecting the custom graph will open up a new tab that shows details around the graph. This includes details around the name, creation status (creating, ready, etc), author, and publishing date.

Near the top, there are tabs for Job Details and Graph Query. These options allow the user to review the current Graph Job, make changes to the Graph Job, or query the graph within the notebook.

Querying the graph in Defender

Once the custom graph has been published and the creation status is Ready, users can query the new graph in the Defender Portal:

Expand the Microsoft Sentinel navigation.
Select Graphs.
Either find the card with the graph title or search for it within the menu.
Once found, click Query Graph to open it.

The graph will open in the schema view. The schema here is a visual representation of which nodes, edges, and relations are part of the graph. This is what was built in the notebook. To query it, a user can write GQL queries or use ones that are provided. For this example, a query provided in the Getting Started tab will be used. This is a generic query that will show everything in a graph:

// Visualize any graph MATCH (x)-[y]->(z) RETURN * LIMIT 100

More focused queries will yield more focused results. For example:

MATCH (n_user:User)-[e_ip:SignedInFrom]->(n_ip:IPAddress) MATCH (n_user)-[e_signin:InteractiveSignIn]->(n_app:Application) WHERE n_user.UserPrincipalName = 'ENTERUSERNAMHERE' AND n_ip.IPAddress = 'IPADDRESSHERE' RETURN n_user, e_ip, n_ip, e_signin, n_app

MATCH (n_user)-[x]->() MATCH (n_user)-[e_signin:InteractiveSignIn]->(n_app:Application) WHERE n_user.UserPrincipalName = 'ENTERUSERNAMEHERE' RETURN *

From here, a user can continue the hunt, remediate the concerns, escalate this for further attention and remediation, or refine the graph as needed.

Refining Graphs

Throughout the process, the custom graph may need to be updated for various reasons, including:

The scope of the hunt/investigation has expanded due to new information or the hypothesis being updated based on findings
The original hypothesis of the hunt was incorrect or needs to be changed
Important nodes are missing from the graph and need to be added

To achieve this, return to VS Code and use the GitHub Copilot chat experience to add new telemetry, nodes, edges, or properties in the existing graph.

The below example illustrates adding Azure resources as new assets by prompting the Sentinel graph authoring tool and instructing it on what needs to be added.

Running the cells of the Notebook will yield an updated graph that includes the new changes:

Graph samples in the Sentinel VS Code extension

To help with learning, building, and using Sentinel graph, there are 5 graph samples included in the Sentinel extension within VS Code.

These can be found by clicking on the Sentinel extension and looking under Notebook Samples > Graphs. Each graph included contains a Jupyter notebook containing the graph schema and mappings, as well as graph queries which can be run against the graph.

These graphs ingest certain security telemetry and expect them to already exist within the Sentinel lake instance that is being used. If needed, the graph mapping can be updated to include/ exclude security telemetry as needed. These graph samples are also located within the Sentinel GitHub repository.

Let’s look at one of the sample graphs – Phishing Email Killchain to understand how it can help during a security investigation.

Using a graph: phishing email kill chain scenario

Phishing is the number one initial access vector, yet investigating a phishing campaign requires correlating data across multiple Sentinel tables: EmailEvents, EmailUrlInfo, UrlClickEvents, EmailAttachmentInfo, DeviceFileEvents, and DeviceProcessEvents. Each table uses a different join key (NetworkMessageId, AccountUpn, SHA256, DeviceName), and analysts must stitch results together manually across several Defender portals.

The core question every SOC analyst needs to answer is: “Who received the email, clicked the URL, downloaded the attachment, and executed it on their device?” In KQL, answering this requires 5+ sequential queries and 30–60 minutes of manual correlation. The Phishing Email Kill Chain graph fuses all of these tables into a single connected structure with 10 node types and 12 edge types, making it possible to answer that question in seconds with a single GQL traversal. SOC teams can create this graph in their tenant and start investigating phishing campaigns using graph-powered insights.

Investigation with the Phishing Email Killchain graph

Multi-hop traversal. The full kill chain from email to endpoint execution is a 4-hop path: Email → Attachment → Process → Device. In KQL, each hop is a separate join with a different key column. In the graph, it’s one MATCH clause.

Structural detection. Campaign topology is visible as the graph’s shape — senders fanning out to emails, emails fanning out to users, shared URLs converging into hubs. These patterns are structural properties requiring no aggregation queries.

Click-exposure overlay. The graph overlays email delivery and URL click paths in a single view. An analyst instantly sees which users received a phishing email AND clicked the embedded URL — no separate UrlClickEvents join needed.

Example queries

Below are three queries from the published phishing_email_killchain graph that demonstrate these capabilities. Each query is a single GQL statement that replaces multiple KQL joins.

Query 1: Full Kill Chain — Email to Endpoint

This query traces the complete attack path: phishing email → malicious attachment → process execution → endpoint device. In KQL, this requires joining 4 tables with different keys and temporal proximity filtering.

MATCH (e:Email)-[ha:HasAttachment]->(att:Attachment) -[tp:TriggeredProcess]->(p:Process)-[od:OnDevice]->(d:Device) RETURN e, ha, att, tp, p, od, d LIMIT 10

Figure 1: Two complete kill chains — Invoice_Q3.xlsm → EXCEL.EXE → DESKTOP-FIN01 and DocuSign_Contract.pdf.exe → cmd.exe → DESKTOP-SALES02. Each path is one traversal replacing 4+ KQL joins.

Query 2: Campaign Topology — Sender to Email to User to URL

This query visualizes the full campaign structure: which senders sent which emails, who received them, and what URLs were embedded. The graph’s fan-out shape immediately reveals the blast radius and shared infrastructure.

MATCH (s:Sender)-[se:Sent]->(e:Email)-[re:ReceivedEmail]->(u:User), (e)-[cu:ContainsUrl]->(url:Url) RETURN s, se, e, re, u, cu, url LIMIT 10

Figure 2: Campaign topology — 2 senders, 2 emails fanning out to 9 users and 2 URLs. The shared URL node (c0ntoso-share...) receiving edges from both emails reveals coordinated campaign infrastructure.

Query 3: URL Click Exposure — Who Clicked the Phishing Links

This query shows which emails contained URLs and which users clicked them. The Email → URL → User click chain is a single traversal that replaces joining EmailUrlInfo with UrlClickEvents.

MATCH (e:Email)-[cu:ContainsUrl]->(url:Url)<-[cl:ClickedUrl]-(u:User) RETURN e, cu, url, cl, u LIMIT 10

Figure 3: Click exposure — 3 users clicked phishing URLs from 3 different emails. Each cluster shows Email → URL → User, instantly identifying click-through victims.

These are just 3 examples of what is possible when using GQL on a graph. Users can author their own GQL queries to run on this graph to show other possibilities.

Additional graph samples

As mentioned, the Phishing Email Killchain graph is one of five graph samples that are available today for use within the VS Code Sentinel Extension. The remaining graphs are:

Behavioral Attack Chain

Ingests data from the SentinelBehaviorInfo, SentinelBehaviorEntities, AlertInfo, AlertEvidence, ThreatIntelIndicators, and BehaviorAnalytics tables to model the relationships between different detections, MITRE tactics/techniques, entities, and threat intel to high different traversals that are difficult to do with just KQL alone.

Databricks Outbound Exfiltration

Ingests data from the DatabricksNotebook, DatabricksSecrets, DatabricksDBFS, DatabricksClusters, DatabricksJobs, DatabricksSQLPermissions, IdentityInfo, AADUserRiskEvents, and BehaviorAnalytics tables to map Databricks notebook and cluster activities to the identities used in order to enable detections of unusual outbound data movement, privilege escalation, and data exfiltration patterns.

DNS C2 Beaconing

Ingests data from the DeviceNetworkEvents, DeviceInfo, and ThreatIntelIndicators to model DNS resolution patterns to detect C2 beaconing and other malicious patterns.

OAuth Privilege Escalation

Ingests data from the EntraServicePrincipals, AADRiskyServicePrincipals, and AADServicePrincipalSignInLogs tables to trace OAuth consent chains, credential abuse, and privilege escalation paths to identify hub users, over-permissions identities, and backdoor patterns that may exist.

Closing

This blog showcased an example of how a custom graph can be made with data within Microsoft Sentinel data lake and the help of GitHub Copilot, investigating a phishing email kill chain situation, and how to leverage the several graph templates that are provided in Sentinel.

Get started today by using one of the template graphs, building your own graph, or by checking out the public documentation for Sentinel graph.

Note: Custom graph API usage for creating graph and querying graph will be billed according to the Sentinel graph meter.

Public Documentation: https://learn.microsoft.com/azure/sentinel/datalake/sentinel-graph-overview

GQL Reference: Graph Query Language (GQL) reference for Microsoft Sentinel graph (Preview) | Microsoft Learn

Planning graph Costs: Plan costs and understand pricing and billing - Microsoft Sentinel | Microsoft Learn

Reminder: Next Tuesday 6/23 at 9AM PST we will be hosting an 'Ask Microsoft Anything' session on Tech Community for the Sentinel SIEM Migration Experience!

Trevor_Rusher — Thu, 18 Jun 2026 22:25:31 GMT

Join us for a live demo and AMA on the Microsoft Sentinel SIEM migration experience. We’ll show how the experience helps teams move from legacy SIEMs like Splunk and QRadar into Microsoft Sentinel with a more guided, lower-friction path. We’ll cover what it does today, how it works, and the questions customers ask most, then open it up for live Q&A.

Link here: Ask Microsoft Anything: The Microsoft Sentinel SIEM Migration Experience

Hope to see you there!

rss.livelink.threads-in-node

Make system-generated LogARepublisher Threat Intelligence updates non-billable (_IsBillable = false)

Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent

Overview

The Lab Environment

Prerequisites

Deploying the Mock API

Building the Connector with the Sentinel Connector Builder Agent

Testing the Connector

Deploying and Enabling the Connector

Next Steps

Conclusion

AI-powered playbook generator, now available to more customers

What’s new

What playbook generator does

Who is it for

How to get started

Ensure you have the right permissions

Availability

Smarter signals, broader coverage: UEBA anomalies on top of Behaviors layer and new data sources

What's new in Sentinel UEBA and Behaviors layer

Adding context to every behavior—use case

Scenario: Detecting a compromised FortiGate device

Examples of observed behaviors include:

KQL examples

Expanding visibility scross the environment—use cases

Scenario: Identifying suspicious web access with Zscaler telemetry

KQL example

Scenario: Identifying suspicious FortiGate configuration backups

KQL example

Getting started

Why it matters

Public Preview: Nested API Support Comes to Microsoft Sentinel CCF

Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough

Quick Start

Prerequisites

The Lab Environment

Deploying the Mock API

How the Nested Step Pattern Works

The KQL That Links the Two Calls

The DCR and the KQL Transform

The Table Schema and Connector Definition

Deploying the Sentinel Connector

Enabling and Verifying Data

Adapting This Pattern to Your Own API

Next Steps

Conclusion

What’s new in Microsoft Sentinel: July 2026

Sentinel SIEM

Custom detections support in Sentinel repositories [Public Preview]

Behind the Build with Gigamon: Enriching Sentinel with network-derived telemetry

Sentinel data lake

Table insights [Public Preview]

Connectors [Public Preview]

GitHub Audit logs (via Azure Storage Blob)

Agari

Airlock Digital

Additional resources

Blogs and documentation:

Upcoming events:

Featured event: Aug 1–6, Black Hat USA 2026 (Mandalay Bay, Las Vegas)

Upcoming webinars:

Stay connected

Windows Forwarded Events connector with Windows Security Events NRT rules

Hunting AI Agent Configuration Drift with Microsoft Sentinel

What I contributed

Why current-state queries are not enough

The common detection pattern

Scenario 1: Instructions changed on a published agent

Scenario 2: A newly observed MCP server

Scenario 3: An owner added to an MCP-enabled agent

Scenario 4: Sharing expanded to the entire organization

Resolving owners without making the hunt schema-fragile

Turning a result into an investigation

Tuning the hunts for your environment

Using the queries

References

Sentinel - Defender XDR KQL Queries Library

Announcing the ASIM Parser Creation Agentic Experience

Why this matters