rss.livelink.threads-in-node

What’s new in Microsoft Sentinel: April 2026

vkokkengada — Thu, 30 Apr 2026 20:59:31 GMT

Welcome to the April 2026 edition of What's new in Microsoft Sentinel. April brings a broad set of updates, with RSAC 2026 announcements rolling out alongside new features. Highlights include cost limit enforcement to prevent runaway query costs, curated open-source intelligence in Threat Analytics, and new data connectors for CrowdStrike, Imperva, AWS, and Logstash. Together, these innovations help security teams control costs, stay ahead of emerging threats, and broaden visibility without added complexity.

Read on to learn what's new with Sentinel.

What's new

OSINT reports in Threat Analytics [Preview]

Customers can now consume curated OSINT articles alongside Microsoft-authored Threat Analytics reports, all in one place. (OSINT, or open-source intelligence, is any information readily available to the public.) These OSINT articles come enriched, as detailed in the following list, to help security teams move quickly from awareness to action.

What’s included:

Curated OSINT articles derived from trusted open-source research

Clear summaries with links back to original sources

Extracted indicators of compromise (IOCs)

Mapped MITRE ATT&CK tactics and techniques

Microsoft enrichment, analysis, and recommended actions (when available)

By bringing OSINT directly into Threat Analytics, we’re reducing context switching, improving analyst efficiency, and helping customers operationalize open-source intelligence faster within their Defender workflows. Learn more.

Cost limit enforcement for KQL queries and notebooks [Preview]

Sentinel data lake cost policies do more than just send an alert when usage gets too high. You can set hard limits for KQL queries, jobs, and notebook sessions that block new work once a threshold is exceeded, eliminating surprise bills from runaway queries or heavy workloads. For example, instead of finding out about cost spikes after you run large queries against the data lake tier, enforcement stops further queries before the damage is done. Anything already running still finishes normally, and you get clear messaging about what happened and what to do next. You can lift guardrails temporarily, adjust thresholds, or disable enforcement on the fly. Learn more.

Figure 1: Create cost management policies in the Microsoft Defender portal to automatically block new queries and jobs when usage limits are exceeded

Sentinel data connectors

With 380 Sentinel data connectors, customers achieve broad visibility into complex digital environments and can expand their security operations effectively. Below are the latest updates.

CrowdStrike API Connector [Generally Available]

The CrowdStrike API Connector ingests logs from CrowdStrike APIs into Sentinel, fetching details on hosts, detections, incidents, alerts, and vulnerabilities from your CrowdStrike environment.

Imperva Cloud WAF [Preview]

The Imperva Cloud WAF data connector ingests Imperva logs into Sentinel through AWS S3 buckets, giving you visibility into web application traffic and threats detected by your Imperva deployment for monitoring, investigation, and threat hunting in Sentinel.

AWS Elastic Load Balancer (ELB) [Preview]

This connector allows you to ingest AWS Elastic Load Balancer (ALB, NLB, and GLB) logs into Sentinel. These logs contain detailed records for requests handled by your load balancers, including client IPs, latencies, request paths, and status codes. These logs are useful for monitoring traffic patterns, investigating anomalies, and ensuring security compliance.

Logstash Output Plugin [Preview]

For organizations that rely on Logstash to collect from on-premises, legacy, or air-gapped environments, the Sentinel Logstash Output Plugin has been rebuilt in Java to align with Microsoft's Secure Future Initiative (SFI) and provide improved security and long-term maintainability. The plugin uses the Azure Monitor Logs Ingestion API with Data Collection Rules (DCRs), giving you full schema control and the ability to ingest directly into Sentinel data lake as well as standard Sentinel tables. Learn more.

Sentinel data federation [Preview]

Sentinel data federation enables unified visibility and security analytics across federated and ingested data, without compromising data governance. Security teams can quickly query data in Microsoft Fabric, Azure Data Lake Storage (ADLS) Gen2, and Azure Databricks directly from Sentinel, no data movement required. This approach allows teams to explore data broadly through federation, then selectively ingest what matters most into Sentinel to unlock advanced detections, automation, and AI‑powered analytics. Learn more.

Figure 2: Federated data appears alongside native Sentinel tables for unified investigation and hunting

Sentinel cost estimation tool [Preview]

Customers and partners can confidently estimate Sentinel costs using the cost estimation tool. With meter-level guidance, you can model ingestion across analytics and data lake tiers, compare retention options, and estimate compute costs. Built‑in projections of up to three years offer transparency into spend, making it easier to plan, optimize, and share estimates. Try the Sentinel Cost Estimator.

Figure 3: A guided, meter-level Sentinel cost estimator with three-year projections helps organizations model data growth, predict spend, and plan Sentinel adoption with confidence.

Microsoft Entra and Azure Resource Graph (ARG) connector enhancements [Preview]

Enable new Entra assets (EntraDevices, EntraOrgContacts) and ARG assets (ARGRoleDefinitions) in existing asset connectors, expanding inventory coverage and powering richer, built‑in graph experiences for greater visibility.

Create workbook reports directly from the data lake [Preview]

Sentinel workbooks can directly run on the data lake using KQL, enabling you to visualize and monitor security data straight from the data lake. By selecting the data lake as the workbook data source, you can create trend analysis and executive reporting.

Custom graphs [Preview]

Custom graphs let you model relationships unique to your organization using data from Sentinel data lake, non-Microsoft sources, and federated data sources, all powered by Fabric. Instead of stitching together dozens of tables manually, you can build graphs that surface blast radius, trace attack paths, map privilege chains, and spot structural outliers like unusually broad access or anomalous email exfiltration. You can generate custom graphs using AI-assisted coding in the Microsoft Sentinel VS Code extension, persist them via a schedule job, and access them in the graphs experience in the Defender portal. Run Graph Query Language (GQL) queries, visualize results, and interactively traverse the graph to the next hop with a single click. These graphs also provide the knowledge context that enables AI-powered agent experiences to work more effectively, speeding investigations and helping you move from disconnected alerts to confident decisions at scale. Custom graph API usage for creating and querying graphs is billed according to the Sentinel graph meter. Learn more.

Figure 4: Query, visualize, and traverse custom graphs with the graph experience in Sentinel

MCP entity analyzer [General availability]

Entity analyzer provides reasoned, out-of-the-box risk assessments that help you quickly understand whether a URL or user identity represents potential malicious activity. It analyzes data across threat intelligence, prevalence, and organizational context to generate clear, explainable verdicts you can trust. Entity analyzer integrates with your agents through Sentinel MCP server connections to first-party and third-party AI runtime platforms, or with your SOAR workflows through Logic Apps. It also serves as a trusted foundation for the Defender Triage Agent, delivering more accurate alert classifications and deeper investigative reasoning. Entity analyzer is billed based on Security Compute Units (SCU) consumption. Learn more about entity analyzer and MCP billing.

Figure 5: Entity analyzer delivers explainable, multi-signal risk assessments for URLs and user identities directly within your investigation workflow

Sentinel MCP graph tool collection [Preview]

Graph tool collection helps security teams visualize and explore relationships between identities and device assets, threats, and activity signals ingested by data connectors and alerted by analytic rules. The tool provides a clear graph view that highlights dependencies and configuration gaps, which makes it easier to understand interactions across environments. This tool helps security teams assess coverage, optimize content deployment, and identify areas that may need tuning or additional data sources—all from a single, interactive workspace. Executing graph queries via the MCP tools triggers the graph meter.

Claude MCP connector [Preview]

Anthropic Claude can connect to Sentinel through a custom MCP connector, giving you AI-assisted analysis across your Sentinel environment. Microsoft provides step-by-step guidance for configuring a custom connector in Claude that securely connects to a Sentinel MCP server. With this connection you can summarize incidents, investigate alerts, and reason over security signals while keeping data inside Microsoft's security boundary. Access to large language models (LLMs) is managed through Microsoft authentication and role-based controls, supporting faster triage and investigation workflows while maintaining compliance and visibility.

CVEs of interest in the Threat Intelligence Briefing Agent [Preview]

The Threat Intelligence Briefing Agent delivers curated intelligence based on your organization’s configuration, preferences, and unique industry and geographic needs. The agent surfaces Common Vulnerabilities and Exposures (CVEs) of interest, highlighting vulnerabilities actively discussed across the security landscape and assessing their potential impact on your environment for more timely threat intelligence insights. The agent automatically incorporates internet exposure data powered by the Sentinel platform to surface threats targeting technologies exposed in your organization. Together, these enhancements help you focus faster on the threats that matter most, without manual investigation.

Additional resources

Blogs and documentation:

Webinars and training:

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!

Use Data Wrangler to Streamline Your Microsoft Sentinel data lake Notebook Development

David Hoerster — Wed, 29 Apr 2026 19:18:17 GMT

One of the many exciting features of the Microsoft Sentinel data lake is a built-in advanced analytics engine, powered by Apache Spark. This Spark cluster has access to data that is within Sentinel data lake, and can work with this data through Jupyter notebooks in Visual Studio Code. As with any coding effort, creating the right data set can be an iterative process, and sometimes making those changes purely through code can be a little tricky. Wouldn't it be great if you could visualize the distribution of your data, apply some actions to shape and refine it, and then translate those actions to code? Well, you can do that with the Data Wrangler extension in VSCode in conjunction with the Sentinel data lake's MicrosoftSentinelProvider class. This blog will walk you through how to enable Data Wrangler in VSCode, how to use some of its functionality, and incorporating refinement actions back into your data lake notebook.

Scenario

The dataframe that is being built will be sourced from SignInLogs but will be used in a later algorithm. I need to clean up some of the columns by replacing missing values with default values, removing rows meeting certain criteria, and creating some categorical columns for later machine learning tasks.

Initial DataFrame

An essential data structure that you use in Jupyter notebooks is a DataFrame. A DataFrame is an in-memory representation of your data, like a database table that has columns and rows.

Let's start with a basic DataFrame that contains some sign-in events from the SigninLogs table from the data lake. The returned data is useful, but for our later investigations we will need to "clean" the data by removing some missing values, renaming columns, creating true/false columns for analysis, and some other operations. In our notebook cell, we'll perform the following actions.

Initial Includes

Before you can use the Sentinel data lake in your notebook, you need to include the proper class from the sentinel_lake.providers module. This module contains a class named MicrosoftSentinelProvider that provides functions that let you read from and write to the data lake. We also will be using a few other Python libraries in our example, and this would look like the following:

from sentinel_lake.providers import MicrosoftSentinelProvider from pyspark.sql.functions import col, from_json from pyspark.sql.types import StructType, StructField, StringType, IntegerType import pandas as pd from datetime import datetime, timedelta

Variable Definitions

Our sample will pull the last 30 days of SigninLogs from the data lake in order to assist with the investigation. This will be a variable that is defined once in the notebook and can be used elsewhere if needed. The same will be done for the name of the workspace in the data lake that will be queried, since the read_table and save_as_table functions can take the workspace name as a parameter and I only want to define the name once and avoid typos with multiple calls.

In addition is a very important step where we instantiate our connection to the Sentinel data lake. The "spark" variable we pass to the MicrosoftSentinelProvider class is a global variable representing your Spark session. The variable sentinel_provider exposes the read_table and save_as_table functions that enable reading from and writing to the data lake.

one_month_ago = datetime.now() - timedelta(days=30) workspaceName = "YOUR_WORKSPACE_NAME" sentinel_provider = MicrosoftSentinelProvider(spark)

Replace "YOUR_WORKSPACE_NAME" with the name of the Sentinel workspace that you will be working with in the data lake.

Complex Type Definitions

Part of our query of SigninLogs will return complex types that contain name/value pairs. The LocationDetails and Status columns have nested values like city and state for LocationDetails and errorCode and failureReason for Status. To be able to easily access those nested values, the use of a StructType allows us to define that structure and we'll use this when retrieving the DataFrame.

location_schema = StructType( [ StructField("city", StringType(), True), StructField("state", StringType(), True), StructField("countryOrRegion", StringType(), True), ] ) status_schema = StructType( [ StructField("errorCode", IntegerType(), True), StructField("failureReason", StringType(), True), StructField("additionalDetails", StringType(), True), ] )

Dataframe Definition

We now have the parts needed to make a call to create a DataFrame for the last 30 days of data from the SigninLogs table in the lake. Our code to define the DataFrame uses our time definition as a filter for TimeGenerated, defines a handful of columns that we want returned, breaking down our complex types using the StructTypes defined earlier, and retrieves those nested column names as individual DataFrame columns.

signin_events_df = ( sentinel_provider.read_table("SigninLogs", workspaceName) .filter(col("TimeGenerated") >= one_month_ago) .filter(col("UserPrincipalName") != "") .select( col("TimeGenerated"), col("AppDisplayName"), col("IPAddress"), col("IsRisky"), col("RiskState"), col("RiskLevelAggregated"), col("RiskLevelDuringSignIn"), col("ConditionalAccessStatus"), col("ClientAppUsed"), col("IsInteractive"), col("UserType"), col("MfaDetail"), col("LocationDetails"), col("Status"), ) .withColumn("loc", from_json(col("LocationDetails"), location_schema)) .withColumn("status", from_json(col("Status"), status_schema)) .select( "*", col("loc.city").alias("City"), col("loc.state").alias("State"), col("loc.countryOrRegion").alias("Country"), col("status.errorCode").alias("ErrorCode"), col("status.failureReason").alias("FailureReason"), col("status.additionalDetails").alias("AdditionalDetails"), ) .drop("loc", "status") )

Final Code (for now)

Putting all of these steps together results in the following code for our cell that retrieves the last 30 days of SigninLogs into a DataFrame.

Running that cell and then calling show() on the resulting DataFrame produces the following output:

It's great data, but not the most visually appealing. It would be nice to have a cleaner looking table. That's where Data Wrangler can help right away.

Install Data Wrangler

Data Wrangler is a VSCode extension that's published by Microsoft. You can find it from the VSCode Marketplace by searching for "Data Wrangler". Installing the extension is quick and only requires Python 3.8 or higher to be installed on your machine.

Data Wrangler View of a DataFrame

Data Wrangler, by default, works natively with Pandas DataFrames. Pandas is an open-source Python library that is very popular with data scientists for data analysis and manipulation. When working with the MicrosoftSentinelProvider class, the DataFrame returned is a PySpark DataFrame. We can easily convert our PySpark DataFrames to Pandas DataFrames by calling `.toPandas()` on that DataFrame.

That's a much cleaner looking table. Clicking the ellipsis in the bottom right of the table and selecting "Show column insights" changes the view to provide a quick glance of the distribution of the data:

Now, just by glancing at the column headers, you can quickly assess the distribution of data in the DataFrame. You can see that 7% of conditional access attempts failed, that a number of sign-in events were for Security Copilot, and 30% of the sign-in events came from just three IP addresses.

Wrangling Your Data

A cleaner table view with data distribution statistics is nice, but the real power of Data Wrangler allows you to shape and refine your data for use elsewhere in your notebook. In the simple DataFrame we have created, let's perform some data cleansing steps so that you can more easily filter and join this DataFrame with other DataFrames later in my analysis. Upon first glance at the DataFrame there are a few data cleansing tasks to perform, namely:

Remove rows that have non-usable UserType values of -1
Create a true/false column for whether the user is a Member or Guest, and drop the original UserType column
Fill in column values that have missing data with a default value
Filter out sign ins to the My Profile page

Let's get started by opening Data Wrangler by clicking the Data Wrangler icon in the lower left corner of the DataFrame.

Data Wrangler will open in a new tab in VS Code. There's a lot going on in this tab, with the left-hand pane having sections for an operations toolbox, a data summary panel that lists some stats about your DataFrame, and cleaning steps that keeps track of the changes you have made to your DataFrame. The rest of the page is split in two, with the DataFrame view taking up the majority of real estate and the operation preview pane at the bottom.

We'll spend most of our time in the operations pane, but we'll also use the operation preview pane to do some additional tasks. Let's dive in.

Task 1: Remove Rows

Looking at the DataFrame grid, I can see the UserType column has some rows with a value of "-1". I don't want those in my DataFrame, so we can remove them using a filter.

Selecting Filter in the Operations panel allows me to enter my criteria. I want to exclude rows that have a "-1" for UserType. I'll enter that and if I wait a few seconds, my DataFrame will update allowing me to preview the change.

I unchecked the "Keep matching rows" checkbox, so my filter is excluding rows that match my criteria of UserType "Equal to" the value "-1". In the DataFrame, UserType is highlighted and I see that -1 is now not part of the DataFrame. Below the DataFrame, in the operation preview, I can see the Python code that makes this change. And in the Cleaning Steps pane, I see my Filter step is present. I can accept this change by clicking the Apply button in the Operations pane.

Once I do that, my DataFrame is updated with my Filter operation. Everything being done by Data Wrangler is done in a sandbox, so these steps do not affect my original DataFrame...at least not yet. (We'll get to that.) Let's make a few more changes.

Task 2: One-Hot Encoded Columns

I want to be able to filter on UserType later on in my notebook, but I don't want to do string comparisons. I'd rather filter on a simple binary column. That's where One-Hot columns are useful. I'd like to have a column for IsMember and one for IsGuest. Each column will be a 0 or a 1 (false or true) and allows me to quickly filter instead of doing string comparisons. Let's create those columns.

In the Operations pane, expand Formulas and select One-hot encode. The panel will switch so you can enter the column you're targeting. Select UserType, and in a few seconds, you'll see your DataFrame update with a preview of the new columns.

Notice the new columns created (UserType_Guest and UserType_Member) are in green. The UserType column is in red and will be dropped. Clicking Apply accepts these changes, and you'll see the updated DataFrame.

You can rename the new columns by selecting the Rename column operation under Schema. In this case, we'll rename the new columns to be IsMember and IsGuest, and accept the changes. Your Data Wrangler tab should look similar to the below image.

Task 3: Provide Default Values for Missing Data

Scanning through the DataFrame, we can see that the FailureReason and AdditionalDetails columns have a number of missing values. We would prefer to have a value in a cell rather than missing values. Filling in default values for missing values is another operation. Under Find and Replace in the Operations pane, select Fill missing values. You can set a default value for multiple columns in one swoop with this operation.

I'm setting the same default value ("N/A") for both columns in one operation. The columns in red are the old values; the columns in green are the new values. Again, if this looks good, hit the Apply button and the DataFrame is updated.

Task 4: Use Copilot to Create Operations

One last update that we wanted to make was to filter out rows where the target application was "My Profile". We've already created a filter operation earlier, but this time, we'll use Copilot to generate the operation. In the Operation Preview pane, below your DataFrame, there's a text box where you can type a prompt. Enter something like "For the column AppDisplayName, filter out the rows where the value is equal to My Profile". Hit Enter, and Copilot thinks for a few seconds and will display the code in the preview pane along with a modal dialog stating that the preview is paused. Since this change was generated by Copilot, you need to review the code before accepting the change.

If the code looks good, click the Run code link in the modal and your DataFrame will go back to preview mode. You'll see the filtered out rows highlighted, and if this all looks good, click Apply to accept the operation.

Using Copilot to help create operations can be very helpful if you know what you want to do, but aren't sure what the operation is called, such as a One-Hot Encoding. But you should always examine the code generated before accepting it.

Applying the Changes to Our Notebook

We've created a number of operations and our DataFrame looks great, but how can we translate these operations back to our original notebook? Data Wrangler makes that easy by allowing you to export your operations back into the source notebook.

Once you're satisfied with your changes, click the Export to notebook button above your DataFrame.

This action will take all of the operations you created and create a new cell in your Jupyter notebook, right below the one where you kicked off the Data Wrangler tab, Your operations will be contained within a local function and a copy of your DataFrame will be sent to the function. The result of the function will be a new DataFrame that you can then work with throughout the rest of your notebook.

Since this is all code, you can change variable names or even the structure of the generated code. Personally, I like to change the DataFrame names from the generic "df" and "df_clean" to something more meaningful, and even the local function can be renamed to a more meaningful function name. This way, if others are working on the same notebook, they have a better understanding of what is happening in the code. It may look like this:

def clean_signin_info(df): # Filter rows based on column: 'UserType' df = df[~(df["UserType"] == "-1")] # One-hot encode column: 'UserType' insert_loc = df.columns.get_loc("UserType") df = pd.concat( [ df.iloc[:, :insert_loc], pd.get_dummies(df.loc[:, ["UserType"]]), df.iloc[:, insert_loc + 1 :], ], axis=1, ) # Rename column 'UserType_Guest' to 'IsGuest' df = df.rename(columns={"UserType_Guest": "IsGuest"}) # Rename column 'UserType_Member' to 'IsMember' df = df.rename(columns={"UserType_Member": "IsMember"}) # Replace missing values with "N/A" in columns: 'FailureReason', 'AdditionalDetails' df = df.fillna({"FailureReason": "N/A", "AdditionalDetails": "N/A"}) return df signin_events_pandas_df = signin_events_df.toPandas() cleaned_signin_events_df = clean_signin_info(signin_events_pandas_df) cleaned_signin_events_df.head()

And my resulting DataFrame will have all of my cleaning steps applied.

Start Using Data Wrangler Today

You can get started using Data Wrangler with your Sentinel data lake notebooks today and explore all of the data wrangling tasks you can do with it. The Data Wrangler extension is available in the VS Code Marketplace and is free to download and use. It works well with the Microsoft Sentinel extension that you use with your Sentinel data lake notebook tasks, so install it today and start wrangling the data lake. Happy wrangling!

Resources

Introducing the Microsoft Sentinel Training Lab. Hands-On Security Operations in Minutes

AndreasKapetaniou — Thu, 23 Apr 2026 08:50:24 GMT

A huge thanks to Paul Kew - this lab wouldn't have been possible without his contributions.

Security operations is one of those things that’s hard to learn from slides alone. You need to feel what it’s like to triage a multi-stage incident, tune a noisy detection rule, or trace an attacker pivoting from an endpoint to the cloud. That’s exactly why we built the Microsoft Sentinel Training Lab.

What Is It?

The Sentinel Training Lab is an open-source, deploy-in-minutes training environment that gives you a fully functional Microsoft Sentinel workspace loaded with realistic attack telemetry. One click deploys everything - pre-recorded data from six different security products, custom detection rules that fire real incidents, workbooks, watchlists, and playbooks.

No need to set up agents, configure connectors, or simulate attacks yourself. The lab does all of that for you so you can focus on what matters: learning how to detect, investigate, and respond.

What’s Inside?

The lab simulates a multi-stage attack that spans six data sources — just like what a real SOC analyst would encounter:

CrowdStrike — endpoint detections (malware execution, credential dumping)
Palo Alto Networks — firewall logs (port scans, data exfiltration, C2 traffic)
Okta — identity events (account takeover, MFA manipulation)
AWS CloudTrail — cloud activity (IAM escalation, backdoor accounts)
GCP Audit Logs — cloud infrastructure abuse (service account creation, firewall changes)
MailGuard365 — email security (phishing campaigns bypassing filters)

All of this data feeds into 22 custom detection rules that automatically generate a unified, multi-stage incident in Microsoft Defender XDR - with correlated alerts, entity graphs, and a full kill chain mapped to MITRE ATT&CK.

The Exercises

The lab comes with 16 guided exercises covering the full spectrum of security operations:

Getting Started

Onboarding — Set up your workspace and deploy the lab in under 30 minutes
Exercise 1 — Explore your data with Advanced Hunting and create your first detection rule
Exercise 2 — Enable Microsoft Defender Threat Intelligence and query IOCs
Exercise 3 — Visualise your detection coverage on the MITRE ATT&CK matrix
Exercise 4 — Automate incident enrichment with automation rules

Detection Engineering

Exercise 5 — Cross-platform device isolation (CrowdStrike alert → MDE response)
Exercise 6 — Tune port scan detection thresholds
Exercise 7 — Detect Okta MFA factor manipulation
Exercise 8 — Enrich detections with watchlists

Operations & Cost Management

Exercise 9 — Monitor ingestion costs and configure threshold policies
Exercise 10 — Manage table tiers and retention settings

Data Lake

Exercise 11 — Create KQL jobs to aggregate data lake telemetry
Exercise 12 — Compare real-time vs data lake detection approaches
Exercise 13 — Interactive Jupyter notebook investigations

Advanced

Exercise 14 — 10 AI-powered prompts demonstrating the Sentinel MCP Server
Exercise 15 — Federate external data from ADLS Gen2
Exercise 16 — Split transformation to route data between Analytics and data Lake tiers

What Makes This Different?

Feature	What it means for you
One-click deployment	Deploy to Azure button — no manual configuration
Realistic multi-source data	Six security products generating correlated incidents
22 detection rules	Pre-built rules that fire real XDR incidents with entity mapping
MITRE ATT&CK coverage	10 tactics covered across the attack chain
Data lake exercises	KQL jobs, notebooks, federation, and split transformations
MCP Server prompts	AI-powered investigation with GitHub Copilot
Cost management	Threshold policies and tier optimisation guidance

Getting Started

Ready to try it? Here’s all you need:

An Azure subscription (free trial works)
Owner or Contributor role on the subscription
A Microsoft Sentinel workspace onboarded to Defender XDR

Then head to the repo, follow the Onboarding guide and click Deploy to Azure:

The deployment takes about 30 minutes. After that, your workspace will have ingested data, detection rules firing incidents, and all 16 exercises ready to go.

Open Source & Community

The entire lab is open source under the Azure/Azure-Sentinel repository. Contributions, feedback, and ideas are welcome. If you find something that could be better, open an issue or submit a PR.

We built this lab because we believe the best way to learn security operations is by doing. We hope it helps you — whether you’re defending your first tenant or your hundredth.

Get started now - Azure-Sentinel/Tools/Microsoft-Sentinel-Training-Lab/README.md at master · Azure/Azure-Sentinel

Sentinel RBAC in the Unified portal: who has activated Unified RBAC, and how did it go?

AnthonyPorter — Tue, 21 Apr 2026 06:04:28 GMT

Following the RSAC 2026 announcements last month, I have been working through the full permission picture for the Unified portal and wanted to open a discussion here given how much has shifted in a short period.

A quick framing of where things stand. The baseline is still that Azure RBAC carries across for Sentinel SIEM access when you onboard, no changes required. But there are now two significant additions in public preview: Unified RBAC for Sentinel SIEM itself (extending the Defender Unified RBAC model to cover Sentinel directly), and a new Defender-native GDAP model for non-CSP organisations managing delegated access across tenants.

The GDAP piece in particular is worth discussing carefully, because I want to be precise about what has and has not changed. The existing limitation from Microsoft's onboarding documentation, that GDAP with Azure Lighthouse is not supported for Sentinel data in the Defender portal, has not changed. What is new is a separate, Defender-portal-native GDAP mechanism announced at RSAC, which is a different thing. These are not the same capability. If you were using Entra B2B as the interim path based on earlier guidance, that guidance was correct and that path remains the generally available option today.

A few things I would genuinely like to hear from practitioners:

For those who have activated Unified RBAC for a Sentinel workspace in the Defender portal: what did the migration from Azure RBAC roles look like in practice? Did the import function bring roles across cleanly, or did you find gaps particularly around custom roles?
For environments using Playbook Operator, Automation Contributor, or Workbook Contributor role assignments: how are you handling the fact those three roles are not yet in Unified RBAC and still require Azure portal management? Is the dual-management posture creating operational friction?
For MSSPs evaluating the new Defender-native GDAP model against their existing Entra B2B setup: what factors are driving the decision either way at your scale?

Writing this up as Part 3 of the migration series and the community experience here is directly useful for making sure the practitioner angle is grounded.

Enforce Cost Limits on KQL Queries and Notebooks in the Microsoft Sentinel Data Lake

shubh_khandhadia — Wed, 15 Apr 2026 20:26:56 GMT

Security teams face a constant tension: run the advanced analytics you need to stay ahead of threats, or hold back to keep costs predictable. Until now, Microsoft Sentinel let you set alerts to get notified when data lake usage approached a threshold — useful for awareness, but not enough to prevent budget overruns.

Today, we're excited to announce threshold enforcement for KQL queries and notebooks in the Microsoft Sentinel data lake. With this release, you can go beyond notifications and automatically block new queries and jobs when your configured usage limits are exceeded. Your analysts keep working confidently, and your budgets stay protected.

What's new

Previously, the Configure Policies experience in Microsoft Sentinel let you set threshold-based alerts for data lake usage. You'd receive an email notification when consumption approached a limit — but nothing stopped usage from continuing past that point.

Now, you can enable enforcement on those same policies. When enforcement is turned on and a threshold is exceeded, Microsoft Sentinel blocks new queries, jobs, and notebook sessions with a clear "Limit exceeded" error. No more surprise cost spikes from runaway queries or analysts who mistakenly run heavy workloads against data lake data.

Enforcement is supported for two data lake capability categories:

Data Lake Query — interactive KQL queries and KQL jobs (scheduled and ad hoc)
Advanced Data Insights — notebook runs and notebook jobs

How it works

Consistent controls across KQL queries and notebooks

Cost controls are enforced consistently across Sentinel data lake workloads, regardless of how analysts access the data. The same policy applies whether someone is running a quick investigation or executing a long-running job.

Controls apply to:

Interactive KQL queries in the data lake explorer in the Defender portal
KQL jobs, including scheduled and ad-hoc jobs
Notebook queries run through the Microsoft Sentinel VS Code extension
Notebook jobs running as background or scheduled workloads

This ensures advanced analytics remain powerful — but predictable and governed.

Clear enforcement without disruption

Enforcement is applied at execution and validation boundaries — not retroactively. This means:

Queries or jobs already running are not interrupted. In-flight work completes normally.
New queries, jobs, or notebook sessions are blocked once limits are exceeded.
Failures occur early (for example, during validation), avoiding wasted compute.

From an analyst's perspective, enforcement is explicit and consistent. Clear messaging appears in query editors, job validation responses, and notebooks when limits are reached — so your team always understands what happened and what to do next.

How to set it up

Prerequisites

To configure enforcement policies, ensure you have the necessary permissions that are outlined here: Manage and monitor costs for Microsoft Sentinel | Microsoft Learn.

Where to access

Navigate to Microsoft Sentinel > Cost management > Configure Policies in the Microsoft Defender portal (https://security.microsoft.com).

Step-by-step configuration

In Microsoft Sentinel > Cost management, select Configure Policies.
Select the policy you want to edit (Data Lake Query or Advanced Data Insights).
Enter the total threshold value for the policy.
Enter an alert percentage to receive email notifications before the threshold is reached.
Enable the Enforcement toggle to block usage after the threshold is exceeded.
Review your settings and select Submit.

Once enforcement is active, administrators receive advance notifications as usage approaches the threshold. If circumstances change — for example, during an active breach — you can adjust the threshold, disable enforcement temporarily, or modify the policy to give your SOC the room it needs to respond without being blocked.

Real-world scenario: Preventing unexpected cost spikes

Consider a large SOC that ingests roughly 6 TB of data per day, with 1 TB going to the Sentinel Analytics tier and the remaining 5 TB going to the Sentinel data lake. Analysts are proactively hunting for threats, performing investigations, and running automation. Tier 3 analysts are also running Jupyter Notebooks against the Sentinel data lake to build graphs, execute queries, and automate incident investigation and remediation with code.

Last month, the SOC experienced a cost spike after a newly hired analyst ran large, frequent queries against data lake data — mistakenly thinking it was Analytics tier. The SOC manager needs to prevent this from happening again.

With enforcement now available, the SOC manager can navigate to Microsoft Sentinel > Cost management > Configure Policies in the Defender portal and set up two policies:

A Data Lake Query policy to cap data processing for KQL queries

An Advanced Data Insights policy to cap notebook compute consumption

With these policies in place, the SOC manager gets notified in advance when consumption approaches the threshold while having confidence that the thresholds set will be enforced to prevent unexpected consumption and cost. Analysts can continue their day-to-day work without worrying about accidental overages. Should a breach scenario demand more capacity, the SOC manager can quickly adjust or temporarily disable the policies — keeping the team unblocked while maintaining overall budget governance. Outside of a breach scenario, should the same SOC analyst generate large amounts of data scanned, the threshold will take action and prevent queries from being performed.

Learn more

With enforceable KQL and notebook guardrails, Microsoft Sentinel data lake helps security teams scale advanced analytics with confidence. You can control usage in production and keep investigations moving — without tradeoffs between visibility, analytics, and budget.

To get started, visit the documentation: Manage and monitor costs for Microsoft Sentinel | Microsoft Learn

We'd love to hear your feedback. Share your thoughts in the comments below or reach out through your usual Microsoft support channels.

Running KQL queries on Microsoft Sentinel data lake using API

Zeinab Mokhtarian Koorabbasloo — Tue, 14 Apr 2026 17:15:33 GMT

Co-Authors: Zeinab Mokhtarian Koorabbasloo and Matthew Lowe

As security data lakes become the backbone of modern analytics platforms, organizations need new ways to operationalize their data. While interactive tools and portals support data exploration, many real-world workflows increasingly require flexible programmatic access that enables automation, scale, and seamless integration.

By running KQL (Kusto Query Language) queries on Microsoft Sentinel data lake through APIs, you can embed analytics directly into automation workflows, background services, and intelligent agents, without relying on manual query execution.

In this post, we explore API based KQL query execution, review some of the scenarios where it delivers the most value, and what you need to get started.

Why run KQL queries on Sentinel data lake via API?

Traditional query experiences, such as dashboards and query editors, are optimized for human interaction. APIs, on the other hand, are optimized for systems.

Running KQL through an API enables:

Automation-first analytics
Repeatable and scheduled insights
Integration with external systems and agents
Consistent query execution at scale

Instead of asking “How do I run this query?”, our customers are asking “How do I embed analytics into my workflow?”

Scenarios where API-based KQL queries add value

Automated monitoring and alerting

SOC teams often want to continuously analyze data in their lake to detect anomalies, trends, or policy violations.

With API-based KQL execution, they can:

Run queries as part of automated workflows and playbooks
Evaluate query results programmatically
Trigger downstream actions such as alerts, tickets, or notifications

This turns KQL into a signal engine, not just an exploration tool.

Powering intelligent agents

AI agents require programmatic access to data lakes to retrieve timely, relevant context for decision making. Using KQL over an API allows agents to:

Dynamically query data lake based on user intent or system context
Retrieve aggregated or filtered results on demand
Combine analytical results with reasoning and decision logic

In this model, KQL acts as the analytical retrieval layer, while the agent focuses on orchestration, reasoning, and action.

Embedding analytics into business workflows

Many organizations want analytics embedded directly into CI/CD and operational pipelines. Instead of exporting data or duplicating logic, they can:

Run KQL queries inline via API
Use results as inputs to other systems
Keep analytics logic centralized and consistent

This reduces drift between “analytics code” and “application code.”

High-level flow: What happens when you run KQL via API

At a conceptual level, the flow looks like this:

A client authenticates to Microsoft Sentinel data lake platform.
The client submits a KQL query via an API.
The query executes against data stored in the data lake.
Results are returned in a structured, machine-readable format.
The client processes or acts on the results.

Prerequisites

To run KQL queries against the Sentinel data lake using APIs, you will need:

A user token or a service principal
Appropriate permissions to execute queries on the Sentinel data lake. Azure RBAC roles such as Log Analytics reader or Log Analytics contributor on the workspace are needed.
Familiarity with KQL and API based query execution patterns

Scenario 1: Execute a KQL query via API within a Playbook

The following Sentinel SOAR playbook example demonstrates how data within Sentinel data lake can be used within automation. This example leverages a service principal that will be used to query the DeviceNetworkEvent logs that are within Sentinel data lake to enrich an incident involving a device before taking action on it.

Within this playbook, the entities involved within the incident are retrieved, then queries are executed against the Sentinel data lake to gain insights on each host involved. For this example, the API call to the Sentinel data lake to retrieve events from the DeviceNetworkEvents table to find relevant information that shows network connections with the host where the IP originated from outside of the United States.

As this action does not have a gallery artifacts within Azure Logic Apps, the action must be built out by using the HTTP action that is offered within Logic Apps. This action requires the API details for the API call as well as the authentication details that will be used to run the API. The step that executes the query leverages the Sentinel data lake API by performing the following call: POST https://api.securityplatform.microsoft.com/lake/kql/v2/rest/query. The service principal being used has read permissions on the Sentinel data lake that contains the relevant details and is authenticating to Entra ID OAuth when running the API call.

NOTE: When using API calls to query Sentinel data lake, use 4500ebfb-89b6-4b14-a480-7f749797bfcd/.default as the scope/audience when retrieving a token for the service principal. This GUID is associated with the query service for Sentinel data lake.

The body of the query is the following:

{ "csl": "DeviceNetworkEvents | where TimeGenerated >= ago(30d) | where DeviceName has '' | where ActionType in (\"ConnectionSuccess\", \"ConnectionAttempted\", \"InboundConnectionAccepted\") | extend GeoInfo = geo_info_from_ip_address(RemoteIP) | extend Country = tostring(GeoInfo.country), State = tostring(GeoInfo.state), City = tostring(GeoInfo.city) | where Country != 'United States' and RemoteIP !has '127.0.0.1' | project TimeGenerated, DeviceName, ActionType, RemoteIP, RemotePort, RemoteUrl, City, State, Country, InitiatingProcessFileName | order by TimeGenerated desc | top 2 by DeviceName", “db”: “WORKSPACENAMEHERE – WORKSPACEIDHERE” }

Within this body, the query and workspace are defined. “csl” represents the query to run against the Sentinel data lake and “db” represents the Sentinel workspace/lake. This value is a combination of the workspace name – workspace ID. Both of these values can be found on the workspace overview blade within Azure.

NOTE: The query must be one line in the JSON. Multi-line items will not be seen as valid JSON.

With this, initial investigative querying via Sentinel data lake has been done the moment that the incident is triggered, allowing the SOC analyst responding to expediate their investigation and validating that the automated action of disabling the account was justified. For this Playbook, the results gathered from Sentinel data lake were placed into a comment and added to the incident within Defender, allowing SOC analysts to quickly review relevant details when beginning their work:

Scenario 2: Execute a KQL query via API in code

The following Python example demonstrates how to use a service principal to execute a KQL query on the Sentinel data lake via API. This example is provided for illustration purposes, but you can also call the API directly via common API tools. Within the code, the query and workspace are defined. “csl” represents the query to run against the Sentinel data lake and “db” represents the Sentinel workspace/lake. This value is a combination of the workspace name – workspace ID. Both of these values can be found on the workspace overview blade within Azure.

You also need to use a token or a service principal.

import requests import msal # ====== SPN / Entra app settings ====== TENANT_ID = "" CLIENT_ID = "" CLIENT_SECRET = "" # Token authority AUTHORITY = f"https://login.microsoftonline.com/{TENANT_ID}" # ---- IMPORTANT ---- # Most APIs use the resource + "/.default" pattern for client-credentials. # Try this first: SCOPE = ["4500ebfb-89b6-4b14-a480-7f749797bfcd/.default"] # ====== KQL query payload ====== KQL_QUERY = { "csl": "SigninLogs| take 10", "db": " workspace1-12345678-abcd-abcd-1234-1234567890ab ", "properties": { "Options": { "servertimeout": "00:04:00", "queryconsistency": "strongconsistency", "query_language": "kql", "request_readonly": False, "request_readonly_hardline": False } } } # ====== Acquire token using client credentials ====== app = msal.ConfidentialClientApplication( client_id=CLIENT_ID, authority=AUTHORITY, client_credential=CLIENT_SECRET ) result = app.acquire_token_for_client(scopes=SCOPE) if "access_token" not in result: raise RuntimeError( f"Token acquisition failed: {result.get('error')} - {result.get('error_description')}" ) access_token = result["access_token"] # ====== Call the KQL API ====== headers = { "Authorization": f"Bearer {access_token}", "Content-Type": "application/json" } url = "https://api.securityplatform.microsoft.com/lake/kql/v2/rest/query" # same endpoint response = requests.post(url, headers=headers, json=KQL_QUERY) if response.status_code == 200: print("Query Results:") print(response.json()) else: print(f"Error {response.status_code}: {response.text}")

In summary, you need the following parameters in your API call:

Request URI: https://api.securityplatform.microsoft.com/lake/kql/v2/rest/query

Method: POST

Sample payload:

{ "csl": " SigninLogs | take 10", "db": "workspace1-12345678-abcd-abcd-1234-1234567890ab", }

Limitations and considerations

The following considerations should be considered when planning to execute KQL queries on a data lake:

Service principal permissions

When using a service principal, Azure RBAC roles can be assigned at the Sentinel workspace level. Entra ID roles or XDR unified RBAC role are not supported for this scenario. Alternatively, user tokens with Entra ID roles can be used.

Result size limits
Queries are subject to limits on execution time and response size. Review Microsoft Sentinel data lake query service limits when designing your workflows.

Summary

Running KQL queries on Sentinel data lake via APIs unlocks a new class of scenarios, from intelligent agents to fully automated analytics pipelines. By decoupling query execution from user interfaces, customers gain flexibility, scalability, and control over how insights are generated and consumed.

If you’re already using KQL for interactive analysis, API access is the natural next step toward production grade analytics.

Happy hunting!

Resources

Run KQL queries on Sentinel data lake: Run KQL queries against the Microsoft Sentinel data lake - Microsoft Security | Microsoft Learn
Service parameters and limits: Microsoft Sentinel data lake service limits - Microsoft Security | Microsoft Learn

Microsoft Sentinel data federation: Expand visibility while preserving governance

chaitra_satish — Tue, 14 Apr 2026 16:11:29 GMT

Security data volumes are growing faster than ever, but visibility across the entire digital estate hasn’t kept pace. As organizations expand across cloud, hybrid, and SaaS environments, critical security-relevant data is increasingly stored across multiple data stores due to governance and compliance requirements.

Microsoft understands this reality. Microsoft Sentinel data federation now in public preview, is designed to meet customers where their data already lives, while preserving governance. Powered by Microsoft Fabric, customers can federate data from Microsoft Fabric, Azure Data Lake Storage (ADLS) Gen 2, and Azure Databricks into Sentinel data lake—without copying or duplicating the data. Security teams can analyze data in place, unifying detections, investigations, and hunting across a broader digital estate, while data owners retain full ownership and policies remain intact.

Sentinel data federation benefit

Data federation ensures security data remains at its source while appearing seamlessly alongside native Sentinel data in the Sentinel data lake.

This allows security teams to work with governed data confidently—without duplicating data or disrupting existing data ownership and compliance models.
Using familiar Sentinel tools such as KQL hunting, notebooks, and custom graphs, teams can correlate signals, investigate incidents, and hunt across federated and ingested data in a unified experience. Analysts can seamlessly connect signals across domains and accelerate investigations.
By running analytics on federated data first, customers can evaluate which datasets consistently deliver security value. Over time, high‑value data can be ingested into Sentinel data lake to unlock deeper detections, automation, and AI‑driven insights.

Sentinel data federation allows security teams to start broad, stay governed, and scale security analytics with clarity.

Customer use cases enabled by Sentinel data federation

Cross-domain threat hunting across the enterprise

With Sentinel data federation, Sentinel becomes the orchestration layer for advanced security analytics, not just a repository for ingested data.

By querying external data sources in place, security teams can:

Run single KQL threat hunts that span Sentinel-native tables and federated data sources.
Correlate security signals with business, identity, fraud, and application telemetry that may never be ingested into Sentinel.
Perform investigations across years of historical data without migrating or reshaping it.

This enables SOC teams to move beyond siloed investigations and uncover patterns that only emerge when data is analyzed across the full digital estate.

“Microsoft leads the market in cloud‑native SIEM. Now with support for data federation, Sentinel is enabling security teams to analyze security data wherever it lives, preserving governance. For customers and managed security providers alike, this marks a pivotal shift in what a modern cloud SIEM can enable."

— Micah Heaton | Strategy Leader at BlueVoyant

AI-ready tooling for advanced security analytics

By extending Sentinel’s security knowledge layer across federated data, customers can:

Leverage Sentinel custom graphs and AI/MCP tools to run analytics across federated and ingested data together.
Deliver immediate investigative value to SOC teams by enriching incidents with broader context.
Enable data scientists and advanced analysts to perform iterative threat discovery without copying or staging massive datasets into the Sentinel data lake.

This approach allows customers to apply advanced analytics and AI techniques to security problems at scale, while preserving governance and avoiding unnecessary data movement.

Data federation as a path to deeper Sentinel value

Data federation is not a replacement for ingestion, it’s a governance-first approach.

Many customers follow a natural progression:

Federate data to explore and investigate
Identify high-value signals through real investigations
Ingest valuable security data into Sentinel data lake overtime
Unlock detections, automation, and AI-powered insights at scale

This approach helps customers realize Sentinel value earlier while setting them up for long-term success.

Learn more

How to Ingest Microsoft Intune Logs into Microsoft Sentinel

PaulineMbabu — Fri, 10 Apr 2026 16:00:00 GMT

For many organizations using Microsoft Intune to manage devices, integrating Intune logs into Microsoft Sentinel is an essential for security operations (Incorporate the device into the SEIM). By routing Intune’s device management and compliance data into your central SIEM, you gain a unified view of endpoint events and can set up alerts on critical Intune activities e.g. devices falling out of compliance or policy changes. This unified monitoring helps security and IT teams detect issues faster, correlate Intune events with other security logs for threat hunting and improve compliance reporting. We’re publishing these best practices to help unblock common customer challenges in configuring Intune log ingestion. In this step-by-step guide, you’ll learn how to successfully send Intune logs to Microsoft Sentinel, so you can fully leverage Intune data for enhanced security and compliance visibility.

Prerequisites and Overview

Before configuring log ingestion, ensure the following prerequisites are in place:

Microsoft Sentinel Enabled Workspace: A Log Analytics Workspace with Microsoft Sentinel enabled; For information regarding setting up a workspace and onboarding Microsoft Sentinel, see: Onboard Microsoft Sentinel - Log Analytics workspace overview. Microsoft Sentinel is now available in the Defender Portal, connect your Microsoft Sentinel Workspace to the Defender Portal: Connect Microsoft Sentinel to the Microsoft Defender portal - Unified security operations.
Intune Administrator permissions: You need appropriate rights to configure Intune Diagnostic Settings. For information, see: Microsoft Entra built-in roles - Intune Administrator.
Log Analytics Contributor role: The account configuring diagnostics should have permission to write to the Log Analytics workspace. For more information on the different roles, and what they can do, go to Manage access to log data and workspaces in Azure Monitor.

Intune diagnostic logging enabled: Ensure that Intune diagnostic settings are configured to send logs to Azure Monitor / Log Analytics, and that devices and users are enrolled in Intune so that relevant management and compliance events are generated. For more information, see: Send Intune log data to Azure Storage, Event Hubs, or Log Analytics.

Configure Intune to Send Logs to Microsoft Sentinel

Sign in to the Microsoft Intune admin center.
Select Reports > Diagnostics settings. If it’s the first time here, you may be prompted to “Turn on” diagnostic settings for Intune; enable it if so. Then click “+ Add diagnostic setting” to create a new setting:
Microsoft Intune Diagnostics settings page – Add diagnostic settings.
- Select Intune Log Categories. In the “Diagnostic setting” configuration page, give the setting a name (e.g. “Microsoft Sentinel Intune Logs Demo”). Under Logs to send, you’ll see checkboxes for each Intune log category. Select the categories you want to forward. For comprehensive monitoring, check AuditLogs, OperationalLogs, DeviceComplianceOrg, and Devices. The selected log categories will be sent to a table in the Microsoft Sentinel Workspace.
  Microsoft Intune Diagnostics settings page – Log categories.
Configure Destination Details – Microsoft Sentinel Workspace. Under Destination details on the same page, select your Azure Subscription then select the Microsoft Sentinel workspace.

Microsoft Intune Diagnostics settings page - Destination details.
Save the Diagnostic Setting. After you click save, the Microsoft Intune Logs will will be streamed to 4 tables which are in the Analytics Tier. For pricing on the analytic tier check here: Plan costs and understand pricing and billing.

Microsoft Intune Diagnostics settings page – Saved Diagnostic settings.

Verify Data in Microsoft Sentinel.

After configuring Intune to send diagnostic data to a Microsoft Sentinel Workspace, it’s crucial to verify that the Intune logs are successfully flowing into Microsoft Sentinel. You can do this by checking specific Intune log tables both in the Microsoft 365 Defender portal and in the Azure Portal. The key tables to verify are:

IntuneAuditLogs
IntuneOperationalLogs
IntuneDeviceComplianceOrg
IntuneDevices

Microsoft 365 Defender Portal (Unified)

Azure Portal (Microsoft Sentinel)

1. Open Advanced Hunting: Sign in to the https://security.microsoft.com (the unified portal). Navigate to Advanced Hunting.
– This opens the unified query editor where you can search across Microsoft Defender data and any connected Sentinel data.

2. Find Intune Tables: In the Advanced hunting Schema pane (on the left side of the query editor), scroll down past the Microsoft Sentinel Tables. Under the LogManagement Section Look for IntuneAuditLogs, IntuneOperationalLogs, IntuneDeviceComplianceOrg, and IntuneDevices in the list.

Microsoft Sentinel in Defender Portal – Tables

1. Navigate to Logs: Sign in to the https://portal.azure.com and open Microsoft Sentinel. Select your Sentinel workspace, then click Logs (under General).

2. Find Intune Tables: In the Logs query editor that opens, you’ll see a Schema or tables list on the left. If it’s collapsed, click >> to expand it. Scroll down to find LogManagement and expand it; look for these Intune-related tables: IntuneAuditLogs, IntuneOperationalLogs, IntuneDeviceComplianceOrg, and IntuneDevices

Microsoft Sentinel in Azure Portal – Tables

Querying Intune Log Tables in Sentinel – Once the tables are present, use Kusto Query Language (KQL) in either portal to view and analyze Intune data:

Microsoft 365 Defender Portal (Unified)

Azure Portal (Microsoft Sentinel)

In the Advanced Hunting page, ensure the query editor is visible (select New query if needed). Run a simple KQL query such as:

IntuneDevice | take 5

Click Run query to display sample Intune device records. If results are returned, it confirms that Intune data is being ingested successfully. Note that querying across Microsoft Sentinel data in the unified Advanced Hunting view requires at least the Microsoft Sentinel Reader role.

Microsoft Sentinel in the Microsoft Defender Portal - Advanced hunting query.

In the Azure Logs blade, use the query editor to run a simple KQL query such as:

IntuneDevice | take 5

Select Run to view the results in a table showing sample Intune device data. If results appear, it confirms that your Intune logs are being collected successfully. You can select any record to view full event details and use KQL to further explore or filter the data - for example, by querying IntuneDeviceComplianceOrg to identify devices that are not compliant and adjust the query as needed.

Microsoft Sentinel in the Azure Portal - Sentinel logs query.

Once Microsoft Intune logs are flowing into Microsoft Sentinel, the real value comes from transforming that raw device and audit data into actionable security signals.
To achieve this, you should set up detection rules that continuously analyze the Intune logs and automatically flag any risky or suspicious behavior. In practice, this means creating custom detection rules in the Microsoft Defender portal (part of the unified XDR experience) see [https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules] and scheduled analytics rules in Microsoft Sentinel (in either the Azure Portal or the unified Defender portal interface) see:[Create scheduled analytics rules in Microsoft Sentinel | Microsoft Learn].

These detection rules will continuously monitor your Intune telemetry – tracking device compliance status, enrollment activity, and administrative actions – and will raise alerts whenever they detect suspicious or out-of-policy events. For example, you can be alerted if a large number of devices fall out of compliance, if an unusual spike in enrollment failures occurs, or if an Intune policy is modified by an unexpected account. Each alert generated by these rules becomes an incident in Microsoft Sentinel (and in the XDR Defender portal’s unified incident queue), enabling your security team to investigate and respond through the standard SOC workflow. In turn, this converts raw Intune log data into high-value security insights: you’ll achieve proactive detection of potential issues, faster investigation by pivoting on the enriched Intune data in each incident, and even automated response across your endpoints (for instance, by triggering playbooks or other automated remediation actions when an alert fires).

Use this Detection Logic to Create a detection Rule
IntuneDeviceComplianceOrg | where TimeGenerated > ago(24h) | where ComplianceState != "Compliant" | summarize NonCompliantCount = count() by DeviceName, TimeGenerated | where NonCompliantCount > 3

Additional Tips: After confirming data ingestion and setting up alerts, you can leverage other Microsoft Sentinel features to get more value from your Intune logs. For example:
- Workbooks for Visualization: Create custom workbooks to build dashboards for Intune data (or check if community-contributed Intune workbooks are available). This can help you monitor device compliance trends and Intune activities visually.
- Hunting and Queries: Use advanced hunting (KQL queries) to proactively search through Intune logs for suspicious activities or trends. The unified Defender portal’s Advanced Hunting page can query both Sentinel (Intune logs) and Defender data together, enabling correlation across Intune and other security data. For instance, you might join IntuneDevices data with Azure AD sign-in logs to investigate a device associated with risky sign-ins.
- Incident Management: Leverage Sentinel’s Incidents view (in Azure portal) or the unified Incidents queue in Defender to investigate alerts triggered by your new rules. Incidents in Sentinel (whether created in Azure or Defender portal) will appear in the connected portal, allowing your security operations team to manage Intune-related alerts just like any other security incident.
- Built-in Rules & Content: Remember that Microsoft Sentinel provides many built-in Analytics Rule templates and Content Hub solutions. While there isn’t a native pre-built Intune content pack as of now, you can use general Sentinel features to monitor Intune data.

Frequently Asked Questions

If you’ve set everything up but don’t see logs in Sentinel, run through these checks:
1. Check Diagnostic Settings
  1. Go to the Microsoft Intune admin center → Reports → Diagnostic settings.
  2. Make sure the setting is turned ON and sending the right log categories to the correct Microsoft Sentinel workspace.
2. Confirm the Right Workspace
  1. Double-check that the Azure subscription and Microsoft Sentinel workspace are selected.
  2. If you have multiple tenants/directories, make sure you’re in the right one.
3. Verify Permissions
4. Make Sure Logs Are Being Generated
  1. If no devices are enrolled or no actions have been taken, there may be nothing to log yet.
  2. Try enrolling a device or changing a policy to trigger logs.
5. Check Your Queries
  1. Make sure you’re querying the correct workspace and time range in Microsoft Sentinel.
  2. Try a direct query like:
    IntuneAuditLogs | take 5
6. Still Nothing?
  1. Try deleting and re-adding the diagnostic setting.
  2. Most issues come down to permissions or selecting the wrong workspace.
How long are Intune logs retained, and how can I keep them longer?
1. The analytics tier keeps data in the interactive retention state for 90 days by default, extensible for up to two years. This interactive state, while expensive, allows you to query your data in unlimited fashion, with high performance, at no charge per query: Log retention tiers in Microsoft Sentinel.

We hope this helps you to successfully connect your resources and end-to-end ingest Intune logs into Microsoft Sentinel. If you have any questions, leave a comment below or reach out to us on X @MSFTSecSuppTeam!

Estimate Microsoft Sentinel Costs with Confidence Using the New Sentinel Cost Estimator

shubh_khandhadia — Thu, 09 Apr 2026 22:26:18 GMT

One of the first questions teams ask when evaluating Microsoft Sentinel is simple: what will this actually cost? Today, many customers and partners estimate Sentinel costs using the Azure Pricing Calculator, but it doesn’t provide the Sentinel-specific usage guidance needed to understand how each Sentinel meter contributes to overall spend. As a result, it can be hard to produce accurate, trustworthy estimates, especially early on, when you may not know every input upfront. To make these conversations easier and budgets more predictable, Microsoft is introducing the new Sentinel Cost Estimator (public preview) for Microsoft customers and partners.

The Sentinel Cost Estimator gives organizations better visibility into spend and more confidence in budgeting as they operate at scale.

You can access the Microsoft Sentinel Cost Estimator here: https://microsoft.com/en-us/security/pricing/microsoft-sentinel/cost-estimator

What the Sentinel Cost Estimator does

The new Sentinel Cost Estimator makes pricing transparent and predictable for Microsoft customers and partners. The Sentinel Cost Estimator helps you understand what drives costs at a meter level and ensures your estimates are accurate with step-by-step guidance.

You can model multi-year estimates with built-in projections for up to three years, making it easy to anticipate data growth, plan for future spend, and avoid budget surprises as your security operations mature. Estimates can be easily shared with finance and security teams to support better budgeting and planning.

When to Use the Sentinel Cost Estimator

Use the Sentinel Cost Estimator to:

Model ingestion growth over time as new data sources are onboarded
Explore tradeoffs between Analytics and Data Lake storage tiers
Understand the impact of retention requirements on total spend
Estimate compute usage for notebooks and advanced queries
Project costs across a multi‑year deployment timeline

For broader Azure infrastructure cost planning, the Azure Pricing Calculator can still be used alongside the Sentinel Cost Estimator.

Cost Estimator Example

Let’s walk through a practical example using the Cost Estimator. A medium-sized company that is new to Microsoft Sentinel wants a high-level estimate of expected costs. In their previous SIEM, they performed proactive threat hunting across identity, endpoint, and network logs; ran detections on high-security-value data sources from multiple vendors; built a small set of dashboards; and required three years of retention for compliance and audit purposes. Based on their prior SIEM, they estimate they currently ingest about 2 TB per day.

In the Cost Estimator, they select their region and enter their daily ingestion volume. As they are not currently using Sentinel data lake, they can explore different ways of splitting ingestion between tiers to understand the potential cost benefit of using the data lake.

Their retention requirement is three years. If they choose to use Sentinel data lake, they can plan to retain 90 days in the Analytics tier (included with Microsoft Sentinel) and keep the remaining data in Sentinel data lake for the full three years.

As notebooks are new to them, they plan to evaluate notebooks for SOC workflows and graph building. They expect to start in the light usage tier and may move to medium as they mature. Since they occasionally query data older than 90 days to build trends—and anticipate using the Sentinel MCP server for SOC workflows on Sentinel lake data—they expect to start in the medium query volume tier.

Note: These tiers are for estimation purposes only; they do not lock in pricing when using the Microsoft Sentinel platform.

Because this customer is upgrading from Microsoft 365 E3 to E5, they may be eligible for free ingestion based on their user count. Combined with their eligible server data from Defender for Servers, this can reduce their billable ingestion.

In the review step, the Cost Estimator projects costs across a three-year window and breaks down drivers such as data tiers, commitment tiers, and comparisons with alternative storage options. From there, the customer can go back to earlier steps to adjust inputs and explore different scenarios. Once done, the estimate report can be exported for reference with Microsoft representatives and internal leadership when discussing the deployment of Microsoft Sentinel and Sentinel Platform.

Finalize Your Estimate with Microsoft

The Microsoft Sentinel Cost Estimator is designed to provide directional guidance and help organizations understand how architectural decisions may influence cost. Final pricing may vary based on factors such as deployment architecture, commitment tiers, and applicable discounts. We recommend working with your Microsoft account team or a Security sales specialist to develop a formal proposal tailored to your organization’s requirements.

Try the Microsoft Sentinel Cost Estimator

Start building your Microsoft Sentinel cost estimate today: https://microsoft.com/en-us/security/pricing/microsoft-sentinel/cost-estimator.

Introducing the New Microsoft Sentinel Logstash Output Plugin (Public Preview!)

JamesAde — Mon, 06 Apr 2026 22:28:06 GMT

Many organizations rely on Logstash as a flexible, trusted data pipeline for collecting, transforming, and forwarding logs from on-premises and hybrid environments. Microsoft Sentinel has long supported a Logstash output plugin, enabling customers to send data directly into Sentinel as part of their existing pipelines. The original plugin was implemented in Ruby, and while it has served its purpose, it no longer meets Microsoft’s Secure Future Initiative (SFI) standards and has limited engineering support. To address both security and sustainability, we have rebuilt the plugin from the ground up in Java, a language that is more secure, better supported across Microsoft, and aligned with long-term platform investments.

To ensure a seamless transition, the new implementation is still packaged and distributed as a standard Logstash Ruby gem. This means the installation and usage experience remains unchanged for customers, while benefiting from a more secure and maintainable foundation.

What's New in This Version

Java‑based and SFI‑compliant

Same Logstash plugin experience, now rebuilt on a stronger foundation. The new implementation is fully Java‑based, aligning with Microsoft’s Secure Future Initiative (SFI) and providing improved security, supportability, and long-term maintainability.

Modern, DCR‑based ingestion
The plugin now uses the Azure Monitor Logs Ingestion API with Data Collection Rules (DCRs), replacing the legacy HTTP Data Collection API (For more info, see Migrate from the HTTP Data Collector API to the Log Ingestion API - Azure Monitor | Microsoft Learn). This gives customers full schema control, enables custom log tables, and supports ingestion into standard Microsoft Sentinel tables as well as Microsoft Sentinel data lake.

Flexible authentication options
Authentication is automatically determined based on your configuration, with support for:

Client secret (App registration / service principal)

Managed identity, eliminating the need to store credentials in configuration files

Sovereign cloud support: The plugin supports Azure sovereign clouds, including Azure US Government, Azure China, and Azure Germany.

Standard Logstash distribution model
The plugin is published on RubyGems.org, the standard distribution channel for Logstash plugins, and can be installed directly using the Logstash plugin manager, no change to your existing installation workflow.

What the Plugin Does

Logstash plugin operates as a three-stage data pipeline: Input → Filter → Output.

Input: You control how data enters the pipeline, using sources such as syslog, filebeat, Kafka, Event Hubs, databases (via JDBC), files, and more.

Filter: You enrich and transform events using Logstash’s powerful filtering ecosystem, including plugins like grok, mutate, and Json, shaping data to match your security and operational needs.

Output: This is where Microsoft comes in. The Microsoft Sentinel Logstash Output Plugin securely sends your processed events to an Azure Monitor Data Collection Endpoint, where they are ingested into Sentinel via a Data Collection Rule (DCR).

With this model, you retain full control over your Logstash pipeline and data processing logic, while the Sentinel plugin provides a secure, reliable path to ingest data into Microsoft Sentinel.

Getting Started

Prerequisites

Logstash installed and running

An Azure Monitor Data Collection Endpoint (DCE) and Data Collection Rule (DCR) in your subscription

Contributor role on your Log Analytics workspace

Who Is This For?

Organizations that already have Logstash pipelines, need to collect from on-premises or legacy systems, and operate in distributed/hybrid environments including air-gapped networks.

To learn more, see: microsoft-sentinel-log-analytics-logstash-output-plugin | RubyGems.org | your community gem host

Accelerate Agent Development: Hacks for Building with Microsoft Sentinel data lake

MitchellGulledge — Thu, 02 Apr 2026 21:37:47 GMT

As a Senior Product Manager | Developer Architect on the App Assure team working to bring Microsoft Sentinel and Security Copilot solutions to market, I interact with many ISVs building agents on Microsoft Sentinel data lake for the first time. I’ve written this article to walk you through one possible approach for agent development – the process I use when building sample agents internally at Microsoft. If you have questions about this, or other methods for building your agent, App Assure offers guidance through our Sentinel Advisory Service.

Throughout this post, I include screenshots and examples from Gigamon’s Security Posture Insight Agent.

This article assumes you have:

An existing SaaS or security product with accessible telemetry.
A small ISV team (2–3 engineers + 1 PM).
Focus on a single high value scenario for the first agent.

The Composite Application Model (What You Are Building)

When I begin designing an agent, I think end-to-end, from data ingestion requirements through agentic logic, following the Composite application model.

The Composite Application Model consists of five layers:

Data Sources – Your product’s raw security, audit, or operational data.
Ingestion – Getting that data into Microsoft Sentinel.
Sentinel data lake & Microsoft Graph – Normalization, storage, and correlation.
Agent – Reasoning logic that queries data and produces outcomes.
End User – Security Copilot or SaaS experiences that invoke the agent.

This separation allows for evolving data ingestion and agent logic simultaneously. It also helps avoid downstream surprises that require going back and rearchitecting the entire solution.

Optional Prerequisite

You are enrolled in the ISV Success Program, so you can earn Azure Credits to provision Security Compute Units (SCUs) for Security Copilot Agents.

Phase 1: Data Ingestion Design & Implementation

Choose Your Ingestion Strategy

The first choice I face when designing an agent is how the data is going to flow into my Sentinel workspace. Below I document two primary methods for ingestion.

Option A: Codeless Connector Framework (CCF)
- This is the best option for ISVs with REST APIs. To build a CCF solution, reference our documentation for getting started.
Option B: CCF Push (Public Preview)
- In this instance, an ISV pushes events directly to Sentinel via a CCF Push connector. Our MS Learn documentation is a great place to get started using this method.

Additional Note:

In the event you find that CCF does not support your needs, reach out to App Assure so we can capture your requirements for future consideration. Azure Functions remains an option if you’ve documented your CCF feature needs.

Phase 2: Onboard to Microsoft Sentinel data lake

Once my data is flowing into Sentinel, I onboard a single Sentinel workspace to data lake. This is a one-time action and cannot be repeated for additional workspaces.

Onboarding Steps

Go to the Defender portal.
Follow the Sentinel Data lake onboarding instructions.
Validate that tables are visible in the lake.
See Running KQL Queries in data lake for additional information.

Phase 3: Build and Test the Agent in Microsoft Foundry

Once my data is successfully ingested into data lake, I begin the agent development process. There are multiple ways to build agents depending on your needs and tooling preferences. For this example, I chose Microsoft Foundry because it fit my needs for real-time logging, cost efficiency, and greater control.

1. Create a Microsoft Foundry Instance

Foundry is used as a tool for your development environment. Reference our QuickStart guide for setting up your Foundry instance.

Required Permissions:

Security Reader (Entra or Subscription)
Azure AI Developer at the resource group

After setup, click Create Agent.

2. Design the Agent

A strong first agent:

Solves one narrow security problem.
Has deterministic outputs.
Uses explicit instructions, not vague prompts.

Example agent responsibilities:

To query Sentinel data lake (Sentinel data exploration tool).
To summarize recent incidents.
To correlate ISVs specific signals with Sentinel alerts and other ISV tables (Sentinel data exploration tool).

3. Implement Agent Instructions

Well-designed agent instructions should include:

Role definition ("You are a security investigation agent…").
Data sources it can access.
Step by step reasoning rules.
Output format expectations.

Sample Instructions can be found here: Agent Instructions

4. Configure the Microsoft Model Context Protocol (MCP) tooling for your agent

For your agent to query, summarize and correlate all the data your connector has sent to data lake, take the following steps:

Select Tools, and under Catalog, type Sentinel, and then select Microsoft Sentinel Data Exploration. For more information about the data exploration tool collection in MCP server, see our documentation.

I always test repeatedly with real data until outputs are consistent. For more information on testing and validating the agent, please reference our documentation.

Phase 4: Migrate the Agent to Security Copilot

Once the agent works in Foundry, I migrate it to Security Copilot. To do this:

Copy the full instruction set from Foundry
Provision a SCU for your Security Copilot workspace. For instructions, please reference this documentation.
- Make note of this process as you will be charged per hour per SCU
- Once you are done testing you will need to deprovision the capacity to prevent additional charges
Open Security Copilot and use Create From Scratch Agent Builder as outlined here.
Add Sentinel data exploration MCP tools (these are the same instructions from the Foundry agent in the previous step).
- For more information on linking the Sentinel MCP tools, please refer to this article.
Paste and adapt instructions.

At this stage, I always validate the following:

Agent Permissions – I have confirmed the agent has the necessary permissions to interact with the MCP tool and read data from your data lake instance.
Agent Performance – I have confirmed a successful interaction with measured latency and benchmark results.

This step intentionally avoids reimplementation. I am reusing proven logic.

Phase 5: Execute, Validate, and Publish

After setting up my agent, I navigate to the Agents tab to manually trigger the agent. For more information on testing an agent you can refer to this article.

Now that the agent has been executed successfully, I download the agent Manifest file from the environment so that it can be packaged.

Click View code on the Agent under the Build tab as outlined in this documentation.

Publishing to the Microsoft Security Store

If I were publishing my agent to the Microsoft Security Store, these are the steps I would follow:

Finalize ingestion reliability.
Document required permissions.
Define supported scenarios clearly.
Package agent instructions and guidance (by following these instructions).

Summary

Based on my experience developing Security Copilot agents on Microsoft Sentinel data lake, this playbook provides a practical, repeatable framework for ISVs to accelerate their agent development and delivery while maintaining high standards of quality. This foundation enables rapid iteration—future agents can often be built in days, not weeks, by reusing the same ingestion and data lake setup.

When starting on your own agent development journey, keep the following in mind:

To limit initial scope.
To reuse Microsoft managed infrastructure.
To separate ingestion from intelligence.

What Success Looks Like

At the end of this development process, you will have the following:

A Microsoft Sentinel data connector live in Content Hub (or in process) that provides a data ingestion path. 
Data visible in data lake. 
A tested agent running in Security Copilot.
Clear documentation for customers.

A key success factor I look for is clarity over completeness. A focused agent is far more likely to be adopted.

Need help?

If you have any issues as you work to develop your agent, please reach out to the App Assure team for support via our Sentinel Advisory Service . Or if you have any other tips, please comment below, I’d love to hear your feedback.

Microsoft Sentinel MCP Server with external AI models (Claude) for natural language investigations

mcasgrain — Wed, 22 Apr 2026 21:35:29 GMT

Security teams are increasingly exploring how AI assistants support them in investigating incidents, asking questions, and exploring their data. At the same time, controlling how data is accessed remains critical. Today, we’re sharing how Sentinel can support a third-party AI assistant like Claude through a new integration approach using Sentinel’s Model Context Protocol (MCP) server, while continuing to rely on Microsoft Entra ID for enterprise grade authentication and access control. This approach uses Microsoft Sentinel with Entra ID to let third-party AI tools access Sentinel data.

Why this matters

Sentinel customers can explore security data using natural language to assist investigations, while preserving strict tenant isolation and access controls, without managing app registrations or shared secrets. AI third-party assistants like Claude can access Sentinel through Microsoft’s existing security infrastructure. When a query is made, the assistant calls the Sentinel MCP server, which enforces authentication via Entra ID before returning data. This Claude third-party connector is now available. Click here for detailed guidance.

Resources

Use the Microsoft Sentinel MCP connector in ChatGPT or Claude Code
Use the Microsoft Sentinel MCP connector in ChatGPT or Claude - Microsoft Security | Microsoft Learn

Sentinel MCP overview
What is Microsoft Sentinel MCP server's tool collection? - Microsoft Security | Microsoft Learn
Get started with Sentinel MCP
Get started with Microsoft Sentinel MCP server - Microsoft Security | Microsoft Learn

Stuck looking up a watchlist value

MrD — Wed, 01 Apr 2026 14:25:42 GMT

Hiya,

I get stuck working with watchlists sometimes.

In this example, I'm wanting to focus on account activity from a list of UPNs.

If I split the elements up, I get the individual results, but can't seem to pull it all together.

=====================================================

In its entirety, the query returns zero results:

let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey;

let OpName = dynamic(['Reset password (self-service)','Reset User Password','Change user password','User reset password','User started password reset','Enable Account','Change password (self-service)','Update PasswordProfile','Self-service password reset flow activity progress']);

AuditLogs

| where OperationName has_any (OpName)

| extend upn = TargetResources.[0].userPrincipalName

| where upn in (ServiceAccounts) //<=This is where I think I'm wrong

| project upn

=====================================================

This line on its own, returns the user on the list:

let ServiceAccounts=(_GetWatchlist('ServiceAccounts_Monitoring'))| project SearchKey;

=====================================================

This section on its own, returns all the activity

AuditLogs

| where OperationName has_any (OpName)

| extend upn = TargetResources.[0].userPrincipalName

| where upn contains "username" //This is the name on the watchlistlist - so I know the activity exists)

====================================================

I'm doing something wrong when I'm trying to use the watchlist cache (I think)

Any help\guidance or wisdom would be greatly appreciated!

Many thanks

Security Copilot Integration with Microsoft Sentinel - Why Automation matters now

Marcel_Graewer — Tue, 31 Mar 2026 13:09:01 GMT

Security Operations Centers face a relentless challenge - the volume of security alerts far exceeds the capacity of human analysts. On average, a mid-sized SOC receives thousands of alerts per day, and analysts spend up to 80% of their time on initial triage. That means determining whether an alert is a true positive, understanding its scope, and deciding on next steps. With Microsoft Security Copilot now deeply integrated into Microsoft Sentinel, there is finally a practical path to automating the most time-consuming parts of this workflow.

So I decided to walk you through how to combine Security Copilot with Sentinel to build an automated incident triage pipeline - complete with KQL queries, automation rule patterns, and practical scenarios drawn from common enterprise deployments.

Traditional triage workflows rely on analysts manually reviewing each incident - reading alert details, correlating entities across data sources, checking threat intelligence, and making a severity assessment. This is slow, inconsistent, and does not scale.

Security Copilot changes this equation by providing:

Natural language incident summarization - turning complex, multi-alert incidents into analyst-readable narratives
Automated entity enrichment - pulling threat intelligence, user risk scores, and device compliance state without manual lookups
Guided response recommendations - suggesting containment and remediation steps based on the incident type and organizational context

The key insight is that Copilot does not replace analysts - it handles the repetitive first-pass triage so analysts can focus on decision-making and complex investigations.

Architecture - How the Pieces Fit Together

The automated triage pipeline consists of four layers:

Detection Layer - Sentinel analytics rules generate incidents from log data
Enrichment Layer - Automation rules trigger Logic Apps that call Security Copilot
Triage Layer - Copilot analyzes the incident, enriches entities, and produces a triage summary
Routing Layer - Based on Copilot's assessment, incidents are routed, re-prioritized, or auto-closed

(Forgive my AI-painted illustration here, but I find it a nice way to display dependencies.)

+-----------------------------------------------------------+ | Microsoft Sentinel | | | | Analytics Rules --> Incidents --> Automation Rules | | | | | v | | Logic App / Playbook | | | | | v | | Security Copilot API | | +-----------------+ | | | Summarize | | | | Enrich Entities | | | | Assess Risk | | | | Recommend Action| | | +--------+--------+ | | | | | v | | +-----------------------------+ | | | Update Incident | | | | - Add triage summary tag | | | | - Adjust severity | | | | - Assign to analyst/team | | | | - Auto-close false positive| | | +-----------------------------+ | +-----------------------------------------------------------+

Step 1 - Identify High-Volume Triage Candidates

Not every incident type benefits equally from automated triage. Start with alert types that are high in volume but often turn out to be false positives or low severity. Use this KQL query to identify your top candidates:

SecurityIncident | where TimeGenerated > ago(30d) | summarize TotalIncidents = count(), AutoClosed = countif(Classification == "FalsePositive" or Classification == "BenignPositive"), AvgTimeToTriageMinutes = avg(datetime_diff('minute', FirstActivityTime, CreatedTime)) by Title | extend FalsePositiveRate = round(AutoClosed * 100.0 / TotalIncidents, 1) | where TotalIncidents > 10 | order by TotalIncidents desc | take 20

This query surfaces the incident types where automation will deliver the highest ROI. Based on publicly available data and community reports, the following categories consistently appear at the top:

Impossible travel alerts (high volume, around 60% false positive rate)
Suspicious sign-in activity from unfamiliar locations
Mass file download and share events
Mailbox forwarding rule creation

Step 2 - Build the Copilot-Powered Triage Playbook

Create a Logic App playbook that triggers on incident creation and leverages the Security Copilot connector. The core flow looks like this:

Trigger: Microsoft Sentinel Incident - When an incident is created

Action 1 - Get incident entities:

let incidentEntities = SecurityIncident | where IncidentNumber == <IncidentNumber> | mv-expand AlertIds | join kind=inner (SecurityAlert | extend AlertId = SystemAlertId) on $left.AlertIds == $right.AlertId | mv-expand Entities | extend EntityData = parse_json(Entities) | project EntityType = tostring(EntityData.Type), EntityValue = coalesce( tostring(EntityData.HostName), tostring(EntityData.Address), tostring(EntityData.Name), tostring(EntityData.DnsDomain) ); incidentEntities

Note: The <IncidentNumber> placeholder above is a Logic App dynamic content variable. When building your playbook, select the incident number from the trigger output rather than hardcoding a value.

Action 2 - Copilot prompt session:

Send a structured prompt to Security Copilot that requests:

Analyze this Microsoft Sentinel incident and provide a triage assessment: Incident Title: {IncidentTitle} Severity: {Severity} Description: {Description} Entities involved: {EntityList} Alert count: {AlertCount} Please provide: 1. A concise summary of what happened (2-3 sentences) 2. Entity risk assessment for each IP, user, and host 3. Whether this appears to be a true positive, benign positive, or false positive 4. Recommended next steps 5. Suggested severity adjustment (if any)

Action 3 - Parse and route:

Use the Copilot response to update the incident. The Logic App parses the structured output and:

Adds the triage summary as an incident comment
Tags the incident with copilot-triaged
Adjusts severity if Copilot recommends it
Routes to the appropriate analyst tier based on the assessment

Step 3 - Enrich with Contextual KQL Lookups

Security Copilot's assessment improves dramatically when you feed it contextual data. Before sending the prompt, enrich the incident with organization-specific signals:

// Check if the user has a history of similar alerts (repeat offender vs. first time) let userAlertHistory = SecurityAlert | where TimeGenerated > ago(90d) | mv-expand Entities | extend EntityData = parse_json(Entities) | where EntityData.Type == "account" | where tostring(EntityData.Name) == "<UserPrincipalName>" | summarize PriorAlertCount = count(), DistinctAlertTypes = dcount(AlertName), LastAlertTime = max(TimeGenerated) | extend IsRepeatOffender = PriorAlertCount > 5; userAlertHistory

// Check user risk level from Entra ID Protection AADUserRiskEvents | where TimeGenerated > ago(7d) | where UserPrincipalName == "<UserPrincipalName>" | summarize arg_max(TimeGenerated, RiskLevel), RecentRiskEvents = count() | project RiskLevel, RecentRiskEvents

Including this context in the Copilot prompt transforms generic assessments into organization-aware triage decisions. A "suspicious sign-in" for a user who travels internationally every week is very different from the same alert for a user who has never left their home country.

Step 4 - Implement Feedback Loops

Automated triage is only as good as its accuracy over time. Build a feedback mechanism by tracking Copilot's assessments against analyst final classifications:

SecurityIncident | where Tags has "copilot-triaged" | where TimeGenerated > ago(30d) | where Classification != "" | mv-expand Comments | extend CopilotAssessment = extract("Assessment: (True Positive|False Positive|Benign Positive)", 1, tostring(Comments)) | where isnotempty(CopilotAssessment) | summarize Total = dcount(IncidentNumber), Correct = dcountif(IncidentNumber, (CopilotAssessment == "False Positive" and Classification == "FalsePositive") or (CopilotAssessment == "True Positive" and Classification == "TruePositive") or (CopilotAssessment == "Benign Positive" and Classification == "BenignPositive") ) by bin(TimeGenerated, 7d) | extend AccuracyPercent = round(Correct * 100.0 / Total, 1) | order by TimeGenerated asc

For this query to work reliably, the automation playbook must write the assessment in a consistent format within the incident comments. Use a structured prefix such as Assessment: True Positive so the regex extraction remains stable.

According to Microsoft's published benchmarks and community feedback, Copilot-assisted triage typically achieves 85-92% agreement with senior analyst classifications after prompt tuning - significantly reducing the manual triage burden.

A Note on Licensing and Compute Units

Security Copilot is licensed through Security Compute Units (SCUs), which are provisioned in Azure. Each prompt session consumes SCUs based on the complexity of the request. For automated triage at scale, plan your SCU capacity carefully - high-volume playbooks can accumulate significant usage. Start with a conservative allocation, monitor consumption through the Security Copilot usage dashboard, and scale up as you validate ROI. Microsoft provides detailed guidance on SCU sizing in the official Security Copilot documentation.

Example Scenario - Impossible Travel at Scale

Consider a typical enterprise that generates over 200 impossible travel alerts per week. The SOC team spends roughly 15 hours weekly just triaging these. Here is how automated triage addresses this:

Detection - Sentinel's built-in impossible travel analytics rule flags the incidents
Enrichment - The playbook pulls each user's typical travel patterns from sign-in logs over the past 90 days, VPN usage, and whether the "impossible" location matches any known corporate office or VPN egress point
Copilot Analysis - Security Copilot receives the enriched context and classifies each incident
Expected Result - Based on common deployment patterns, around 70-75% of impossible travel incidents are auto-closed as benign (VPN, known travel patterns), roughly 20% are downgraded to informational with a triage note, and only about 5% are escalated to analysts as genuine suspicious activity

This type of automation can reclaim over 10 hours per week - time that analysts can redirect to proactive threat hunting.

Getting Started - Practical Recommendations

For teams ready to implement automated triage with Security Copilot and Sentinel, here is a recommended approach:

Start small. Pick one high-volume, high-false-positive incident type. Do not try to automate everything at once.
Run in shadow mode first. Have the playbook add triage comments but do not auto-close or re-route. Let analysts compare Copilot's assessment with their own for two to four weeks.
Tune your prompts. Generic prompts produce generic results. Include organization-specific context - naming conventions, known infrastructure, typical user behavior patterns.
Monitor accuracy continuously. Use the feedback loop KQL above. If accuracy drops below 80%, pause automation and investigate.
Maintain human oversight. Even at 90%+ accuracy, keep a human review step for high-severity incidents. Automation handles volume - analysts handle judgment.

The combination of Security Copilot and Microsoft Sentinel represents a genuine step forward for SOC efficiency. By automating the initial triage pass - summarizing incidents, enriching entities, and providing classification recommendations - analysts are freed to focus on what humans do best: making nuanced security decisions under uncertainty.

Feel free to like or/and connect :)

Webinar Cancellation

emilyfalla — Mon, 30 Mar 2026 21:40:40 GMT

Hi everyone!

The webinar originally scheduled for April 14th on "Using distributed content to manage your multi-tenant SecOps" has unfortunately been cancelled for now. We apologize for the inconvenience and hope to reschedule it in the future.

Please find other available webinars at: http://aka.ms/securitycommunity

All the best,

The Microsoft Security Community Team

Your Sentinel AMA Logs & Queries Are Public by Default — AMPLS Architectures to Fix That

veesamprabhukiran — Wed, 25 Mar 2026 23:19:39 GMT

When you deploy Microsoft Sentinel, security log ingestion travels over public Azure Data Collection Endpoints by default. The connection is encrypted, and the data arrives correctly — but the endpoint is publicly reachable, and so is the workspace itself, queryable from any browser on any network.

For many organisations, that trade-off is fine. For others — regulated industries, healthcare, financial services, critical infrastructure — it is the exact problem they need to solve.

Azure Monitor Private Link Scope (AMPLS) is how you solve it.

What AMPLS Actually Does

AMPLS is a single Azure resource that wraps your monitoring pipeline and controls two settings:

Where logs are allowed to go (ingestion mode: Open or PrivateOnly)
Where analysts are allowed to query from (query mode: Open or PrivateOnly)

Change those two settings and you fundamentally change the security posture — not as a policy recommendation, but as a hard platform enforcement. Set ingestion to PrivateOnly and the public endpoint stops working. It does not fall back gracefully. It returns an error. That is the point.

It is not a firewall rule someone can bypass or a policy someone can override. Control is baked in at the infrastructure level.

Three Patterns — One Spectrum

There is no universally correct answer. The right architecture depends on your organisation's risk appetite, existing network infrastructure, and how much operational complexity your team can realistically manage. These three patterns cover the full range:

Architecture 1 — Open / Public (Basic)
No AMPLS. Logs travel to public Data Collection Endpoints over the internet. The workspace is open to queries from anywhere. This is the default — operational in minutes with zero network setup.
Cloud service connectors (Microsoft 365, Defender, third-party) work immediately because they are server-side/API/Graph pulls and are unaffected by AMPLS. Azure Monitor Agents and Azure Arc agents handle ingestion from cloud or on-prem machines via public network.

Simplicity: 9/10 | Security: 6/10
Good for: Dev environments, teams getting started, low-sensitivity workloads

Architecture 2 — Hybrid: Private Ingestion, Open Queries (Recommended for most)
AMPLS is in place. Ingestion is locked to PrivateOnly — logs from virtual machines travel through a Private Endpoint inside your own network, never touching a public route. On-premises or hybrid machines connect through Azure Arc over VPN or a dedicated circuit and feed into the same private pipeline.
Query access stays open, so analysts can work from anywhere without needing a VPN/Jumpbox to reach the Sentinel portal — the investigation workflow stays flexible, but the log ingestion path is fully ring-fenced. You can also split ingestion mode per DCE if you need some sources public and some private.
This is the architecture most organisations land on as their steady state.

Simplicity: 6/10 | Security: 8/10
Good for: Organisations with mixed cloud and on-premises estates that need private ingestion without restricting analyst access

Architecture 3 — Fully Private (Maximum Control)
Infrastructure is essentially identical to Architecture 2 — AMPLS, Private Endpoints, Private DNS zones, VPN or dedicated circuit, Azure Arc for on-premises machines. The single difference: query mode is also set to PrivateOnly.
Analysts can only reach Sentinel from inside the private network. VPN or Jumpbox required to access the portal. Both the pipe that carries logs in and the channel analysts use to read them are fully contained within the defined boundary.
This is the right choice when your organisation needs to demonstrate — not just claim — that security data never moves outside a defined network perimeter.

Simplicity: 2/10 | Security: 10/10
Good for: Organisations with strict data boundary requirements (regulated industries, audit, compliance mandates)

Quick Reference — Which Pattern Fits?

Scenario	Architecture
Getting started / low-sensitivity workloads	Arch 1 — No network setup, public endpoints accepted
Private log ingestion, analysts work anywhere	Arch 2 — AMPLS PrivateOnly ingestion, query mode open
Both ingestion and queries must be fully private	Arch 3 — Same as Arch 2 + query mode set to PrivateOnly

One thing all three share: Microsoft 365, Entra ID, and Defender connectors work in every pattern — they are server-side pulls by Sentinel and are not affected by your network posture.

Please feel free to reach out if you have any questions regarding the information provided.

What caught you off guard when onboarding Sentinel to the Defender portal?

AnthonyPorter — Tue, 24 Mar 2026 23:51:42 GMT

Following on from a previous discussion around what actually changes versus what doesn't in the Sentinel to Defender portal migration, I wanted to open a more specific conversation around the onboarding moment itself.

One thing I have been writing about is how much happens automatically the moment you connect your workspace. The Defender XDR connector enables on its own, a bi-directional sync starts immediately, and if your Microsoft incident creation rules are still active across Defender for Endpoint, Identity, Office 365, Cloud Apps, and Entra ID Protection, you are going to see duplicate incidents before you have had a chance to do anything about it.

That is one of the reasons I keep coming back to the inventory phase as the most underestimated part of this migration. Most of the painful post-migration experiences I hear about trace back to things that could have been caught in a pre-migration audit: analytics rules with incident title dependencies, automation conditions that assumed stable incident naming, RBAC gaps that only become visible when someone tries to access the data lake for the first time.

A few things I would genuinely love to hear from practitioners who have been through this:

- When you onboarded, what was the first thing that behaved unexpectedly that you had not anticipated from the documentation?

- For those who have reviewed automation rules post-onboarding: did you find conditions relying on incident title matching that broke, and how did you remediate them?

- For anyone managing access across multiple tenants: how are you currently handling the GDAP gap while Microsoft completes that capability?

I am writing up a detailed pre-migration inventory framework covering all four areas and the community experience here is genuinely useful for making sure the practitioner angle covers the right ground.

Happy to discuss anything above in more detail.

Sentinel datalake: private link/private endpoint

munterweger — Mon, 23 Mar 2026 11:40:25 GMT

Has anyone already configured Sentinel Datalake with a private link/private endpoint setup? I can't find any instructions for this specific case.

Can I use the wizard in the Defender XDR portal, or does it require specific configuration steps?

Or does it require configuring a private link/private endpoint setup on the Datalake component after activation via the wizard?

RSAC 2026: What the Sentinel Playbook Generator actually means for SOC automation

Marcel_Graewer — Sun, 22 Mar 2026 12:22:31 GMT

RSAC 2026 brought a wave of Sentinel announcements, but the one I keep coming back to is the playbook generator. Not because it's the flashiest, but because it touches something that's been a real operational pain point for years: the gap between what SOC teams need to automate and what they can realistically build and maintain.

I want to unpack what this actually changes from an operational perspective, because I think the implications go further than "you can now vibe-code a playbook."

The problem it solves

If you've built and maintained Logic Apps playbooks in Sentinel at any scale, you know the friction. You need a connector for every integration. If there isn't one, you're writing custom HTTP actions with authentication handling, pagination, error handling - all inside a visual designer that wasn't built for complex branching logic. Debugging is painful. Version control is an afterthought. And when something breaks at 2am, the person on call needs to understand both the Logic Apps runtime AND the security workflow to fix it.

The result in most environments I've seen: teams build a handful of playbooks for the obvious use cases (isolate host, disable account, post to Teams) and then stop. The long tail of automation - the enrichment workflows, the cross-tool correlation, the conditional response chains - stays manual because building it is too expensive relative to the time saved.

What's actually different now

The playbook generator produces Python. Not Logic Apps JSON, not ARM templates - actual Python code with documentation and a visual flowchart. You describe the workflow in natural language, the system proposes a plan, asks clarifying questions, and then generates the code once you approve.

The Integration Profile concept is where this gets interesting. Instead of relying on predefined connectors, you define a base URL, auth method, and credentials for any service - and the generator creates dynamic API calls against it. This means you can automate against ServiceNow, Jira, Slack, your internal CMDB, or any REST API without waiting for Microsoft or a partner to ship a connector.

The embedded VS Code experience with plan mode and act mode is a deliberate design choice. Plan mode lets you iterate on the workflow before any code is generated. Act mode produces the implementation. You can then validate against real alerts and refine through conversation or direct code edits. This is a meaningful improvement over the "deploy and pray" cycle most of us have with Logic Apps.

Where I see the real impact

For environments running Sentinel at scale, the playbook generator could unlock the automation long tail I mentioned above. The workflows that were never worth the Logic Apps development effort might now be worth a 15-minute conversation with the generator. Think: enrichment chains that pull context from three different tools before deciding on a response path, or conditional escalation workflows that factor in asset criticality, time of day, and analyst availability.

There's also an interesting angle for teams that operate across Microsoft and non-Microsoft tooling. If your SOC uses Sentinel for SIEM but has Palo Alto, CrowdStrike, or other vendors in the stack, the Integration Profile approach means you can build cross-vendor response playbooks without middleware.

The questions I'd genuinely like to hear about

A few things that aren't clear from the documentation and that I think matter for production use:

Security Copilot dependency: The prerequisites require a Security Copilot workspace with EU or US capacity. Someone in the blog comments already flagged this as a potential blocker for organizations that have Sentinel but not Security Copilot. Is this a hard requirement going forward, or will there be a path for Sentinel-only customers?
Code lifecycle management: The generated Python runs... where exactly? What's the execution runtime? How do you version control, test, and promote these playbooks across dev/staging/prod? Logic Apps had ARM templates and CI/CD patterns. What's the equivalent here?
Integration Profile security: You're storing credentials for potentially every tool in your security stack inside these profiles. What's the credential storage model? Is this backed by Key Vault? How do you rotate credentials without breaking running playbooks?
Debugging in production: When a generated playbook fails at 2am, what does the troubleshooting experience look like? Do you get structured logs, execution traces, retry telemetry? Or are you reading Python stack traces?
Coexistence with Logic Apps: Most environments won't rip and replace overnight. What's the intended coexistence model between generated Python playbooks and existing Logic Apps automation rules?

I'm genuinely optimistic about this direction. Moving from a low-code visual designer to an AI-assisted coding model with transparent, editable output feels like the right architectural bet for where SOC automation needs to go. But the operational details around lifecycle, security, and debugging will determine whether this becomes a production staple or stays a demo-only feature.

Would be interested to hear from anyone who's been in the preview - what's the reality like compared to the pitch?

How Granular Delegated Admin Privileges (GDAP) allows Sentinel customers to delegate access

Yossi Basha — Thu, 16 Apr 2026 14:40:52 GMT

Simplifying Defender SIEM and XDR delegated access

As Microsoft Sentinel and Defender converge into a unified experience, organizations face a fundamental challenge: the lack of a scalable, comprehensive, delegated access model that works seamlessly across Entra ID and Sentinel’s Azure Resource Manage creating a significant barrier for Managed Security Service Providers (MSSPs) and large enterprises with complex multi-tenant structures.

Extending GDAP beyond CSPs: a strategic solution

In response to these challenges, we have developed an extension to GDAP that makes it available to all Sentinel and Defender customers, including non-CSP organizations. This expansion enables both MSSPs and customers with multi-tenant organizational structures to establish secure, granular delegated access relationships directly through the Microsoft Defender portal. This is now available in public preview.

The GDAP extension aligns with zero-trust security principles through a three-way handshake model requiring explicit mutual consent between governing and governed tenants before any relationship is established. This consent-based approach enhances transparency and accountability, reducing risks associated with broad, uncontrolled permissions. By integrating with Microsoft Defender, GDAP enables advanced threat detection and response capabilities across tenant boundaries while maintaining granular permission management through Entra ID roles and Unified RBAC custom permissions.

Delivering unified management of delegated access across SIEM and XDR

With GDAP, customers gain a truly unified way to manage access across both Microsoft Sentinel and Defender—using a single, consistent delegated access model for SIEM and XDR. For Sentinel customers, this brings parity with the Azure portal experience: where delegated access was previously managed through Azure Lighthouse, it can now be handled directly in the Defender portal using GDAP. More importantly, for organizations running SIEM and XDR together, GDAP eliminates the need to switch between portals—allowing teams to view, manage, and govern security access from one centralized experience. The result is simpler administration, reduced operational friction, and a more cohesive way to secure multi-tenant environments at scale.

How GDAP for non-CSPs works: the three-step handshake

The GDAP handshake model implements a security-first approach through three distinct steps, each requiring explicit approval to prevent unauthorized access.

Step 1 begins with the governed tenant initiating the relationship, allowing the governing tenant to request GDAP access.

Step 2 shifts control to the governing tenant, which creates and sends a delegated access request with specific requested permissions through the multi-tenant organization (MTO) portal.

Step 3 returns to the governed tenant for final approval.

The approach provides customers with complete visibility and control over who can access their security data and with what permissions, while giving MSSPs a streamlined, Microsoft-supported mechanism for managing delegated relationships at scale.

Step 4 assigns Sentinel permissions.

In Azure resource management, assign governing tenant’s groups with Sentinel workspaces permissions (in the governed tenant), selecting the governing tenant’s security groups used in the created relationship.

Learn more here: Configure delegated access with governance relationships for multitenant organizations - Unified se…