What’s new in Microsoft Sentinel: June 2026
Welcome back to What's new in Microsoft Sentinel. In June, Sentinel SIEM’s Advanced Security Information Model (ASIM) broadens its normalization, so one analytic rule can reach more sources with less per-source work and, additionally, two new ASIM schemas can now bring asset inventory and AI agent telemetry into common form. In Microsoft Sentinel data lake, the Agent Identities Asset Connector adds the identity context behind your AI agents, helping you see who owns an agent and what permissions it holds. In Sentinel MCP, graph tools help security teams investigate threats and optimize security coverage by visualizing relationships across identities, devices, alerts, and signals in a unified graph experience. Read on for the details, and explore the resources at the end to go deeper. Sentinel innovations: Sentinel SIEM Sentinel data lake Sentinel MCP Microsoft Security Store Sentinel SIEM Advanced Security Information Model (ASIM) parsers and schemas [Generally available] The Advanced Security Information Model (ASIM) in Sentinel normalizes logs into common schemas, so one analytic rule can cover many sources without managing each native schema. ASIM coverage has expanded across more Azure services, broader AWS CloudTrail activity, and a range of third-party firewall, identity, and proxy products, so your detections reach more of your environment with less per-source work. Two schemas also join ASIM: Asset Entities normalizes asset inventory so you can correlate files and assets across investigations, and AI Agent Events normalizes telemetry from AI-driven workflows and autonomous agents. Browse the ASIM parsers on GitHub to explore, file issues, or contribute. Learn more in our blog. Sentinel transition to Defender blog series By March 31, 2027, all Microsoft Sentinel customers transition to Defender. This six-part series guides you through moving your Sentinel experience from the Azure portal to Defender, where SIEM, XDR, threat intelligence, AI, and automation come together in one experience. Your analytics rules, playbooks, workbooks, log analytics workspace, and access assignments all carry forward while the operational layer becomes more connected and intelligent. Starting early matters because you realize the benefits sooner, including a unified incident queue, cross-product correlation, Security Copilot, Sentinel data lake, and SOC optimization. Across the six-part blog series you get 1) the strategic shift, 2) the anatomy of incident and data changes, 3) detection and automation, 4) the governance shift across roles and access, 5) a readiness playbook with the adoption helper and cost guidance, and 6) a look at the AI-first SOC. Each part stands alone, so you can read in order or jump to what matters most to you. Sentinel data lake Agent Identities Asset Connector [Public preview] The Agent Identities Asset Connector brings identity context for AI agents into Sentinel. Activity connectors like Agent 365 and Microsoft 365 Copilot already show you what AI agents do, but activity alone cannot tell you who owns an agent, what permissions it holds, or how it is governed. This connector fills that gap with four asset tables covering agent owners, agent identities, agent blueprints, and the service principals tied to those blueprints. Together they form a connected agent identity graph you can trace from owner to identity to blueprint to permissions to the resources an agent touches. Joining this asset data with activity data in Sentinel data lake lets you detect anomalous behavior relative to permissions, spot over-permissioned or misconfigured agents, and follow full execution chains for end-to-end traceability. To get started, install the Agent 365 and Microsoft 365 Copilot solutions in Content Hub and enable the asset and activity connectors. Learn more. Sentinel MCP Sentinel MCP graph tools [Public preview] Microsoft Security Graph MCP tools, recently introduced in the Microsoft Sentinel MCP Server data exploration collection helps security teams investigate threats by exploring relationships between identities and device assets, and threat and activity signals ingested by data connectors and surfaced by analytic rules. Starting from an alert, analysts can follow the exposure path across connected entities — tracing lateral movement, understanding blast radius, and identifying configuration gaps — all from a single, interactive workspace. The tool provides a clear graph view that highlights dependencies and makes it easier to understand how content interacts across your environment. This helps security teams assess coverage, optimize content deployment, and identify areas that may need tuning or additional data sources. Executing graph queries via the MCP tools will trigger the graph meter. Learn more. Microsoft Security Store Partner testimonials from Adaquest and Glueckkanja For partners like Adaquest and Glueckkanja, the Microsoft Security Store helps not only put their years of knowledge, understanding, and best practices into a scalable, packaged solution, it gives them the ability to democratize that expertise and take it to market globally. Security Store operationalizes their expertise as always-on defenses — discoverable, deployable, and driving real outcomes inside the tools that security teams rely on every day. See how the Security Store is helping security teams act on threats faster with the right solutions and to be ready when it matters most: Watch: Adaquest unlocks faster response times for customers (testimonial) Watch: Glueckkanja builds agents with purpose (testimonial) Additional resources Blogs and documentation: The Advanced Security Information Model (ASIM) Process Event normalization schema reference How BlueVoyant's ASIM-First Strategy Simplifies Threat Detection in Microsoft Sentinel Migrate Sentinel to Defender – Why It Is a Security Architecture Decision, Not Just a Portal Change Connect Microsoft Sentinel to the Microsoft Defender portal Agent 365 connector: Monitor, hunt, and investigate AI agent activity in Microsoft Sentinel Get started with Microsoft Sentinel MCP server Upcoming webinars and events: July 15–16: Microsoft Virtual Training Day: Predict and Defend Against Cybersecurity Threats July 22: Microsoft Security Immersion Event: Shadow Hunter July 23-24: Microsoft Virtual Training Day: Introduction to Microsoft Security July 28: Tech Brief: Modernize security operations with a unified platform July 29: Security Immersion Event: Into the Breach Stay connected Check back each month for the latest innovations, updates, and events to ensure you’re getting the most out of Microsoft Sentinel. We’ll see you in the next edition!A guide to innovating threat hunting with Microsoft Sentinel custom graph
Microsoft Sentinel platform offers a growing list of tools and features, with graph being a cornerstone capability. Sentinel graph is a relationship-first method for organizing and querying data within Microsoft Sentinel data lake. Activities amongst entities (users, devices, emails, IPs, applications, etc.) become a navigable structure that avoids a complex table structure. Rather than stitching together data and evidence via complex joins, users can follow multi-hop connections in order to understand insights such as blast radius, unseen pivots in malicious behavior, and investigative details that may not be as obvious within regular logs, all while visualizing these paths to assist in communicating evidence and findings. This blog will walk through how to create custom graphs using GitHub Copilot chat experiences in Sentinel VS Code. And how to leverage out-of-the-box graph samples to build custom graphs addressing security outcomes. Custom graphs are available in public preview. Prerequisites and Tooling Sentinel data lake enabled in the tenant, this is where the data for the graph will be stored. Users will need read/write permissions on Sentinel data lake data. And either security operator or security admin permissions to save a custom graph in the tenant. Visual Studio Code (VS Code) will need to be installed, as it is essential for building and saving graphs. The Jupyter notebook extension, Microsoft Sentinel extension, and GitHub Copilot extension will need to be installed from within VS Code. These are key pieces for configuring and managing graphs. (Optional) Microsoft Sentinel MCP server if using MCP tools like the data exploration tool. Building a new custom graph The starting point is within Visual Studio Code (VS Code), where the custom graph will be built via GitHub Copilot and the Sentinel graph authoring tool. Make sure to have a GitHub account logged in within VS Code, then start a chat with Copilot via View > Chat. This will open a chat window on the right side of the screen. Determining security telemetry for investigation If unsure about which tables are available within the environment or the columns to focus on for hunting/investigations, turn to the Sentinel MCP server. With the Sentinel MCP server, users can explore the threat landscape within their environment as well as see which data sources currently exist within the Sentinel data lake. This process can be done using natural language with Copilot to obtain the information needed to perform the task at hand. “List the most important tables within my Microsoft Sentinel data lake environment that would build a blast radius for a compromised user account. List the best columns to use for this scenario. Format the response as a table” The tables and columns that can be used are now known. The next step is to use these tables to construct a custom graph with help from GitHub Copilot. For this example, a blast radius graph will be built to assist in reviewing the impact of compromised accounts within the environment: “List the top 5 compromised or targeted accounts within my environment. List which types of attacks are involved with those accounts. Summarize the information into a simple to read table” Given this response, there are a few options for going forward: Return to the Microsoft Defender portal and attempt threat hunting/review this with other analysts Ask Copilot to provide threat hunting queries or perform incident investigations for the top users who are most targeted Build custom graphs to visualize threat data around the most targeted accounts For this example, we will use option 3. Building graph mappings with GitHub Copilot To begin building a custom graph from scratch, a new prompt is submitted, this time tagging the Sentinel extension’s graph authoring tool. An example of the type of prompt to use is below: “@Sentinel /graph-authoring I want to investigate the blast radius of a compromised user and what systems/ app/ devices that they accessed based on users authentication activity. Please use at least SignInLogs, NonInteractivelogs, DeviceLogon, Onprem AD logs, IdentityInfo, and AADRiskyUsers. The graph should help investigate the following security outcomes: What is the user's current risk level and risk score from Identity Protection? Which applications and resources did a user authenticate to? Are there sign-ins from risky IP addresses, Tor exit nodes, or anonymizers? Are there non-interactive sign-ins from unexpected locations or devices? Which machines did a user log on to locally/remotely (RDP)? Which user accounts have been active on a compromised device? A few guidance for data ingestion: Ensure to filter out any data that has NULL or empty values for key Nodes and Edges Filter all data for last 14 days Do not map json arrays as Keys in Nodes or Edges” Note: To ensure that the graph that is written matches the desired scenario, it helps to provide outcomes or guidance to the graph authoring tool. If a Juypter notebook is not already open within the VS Code, Copilot will build a new notebook based on the prompt given. Once Copilot is done, select a kernel to run the notebook. This can be done from the top right of the Notebook: Click on Select Kernel. Click on Microsoft Sentinel. Choose a pool option for the compute cluster. Once a pool is picked, click on the run button next to one of the code cells to boot up the compute pool (this can take up to 5 minutes) Once connected, users can either go through and click the run button next to the code cell to run the code or click the Run All button at the top of the Notebook. For each cell in the Notebook: Cell 2 This section of the notebook is for mporting the sentinel_graph library and configures Spark settings. This is essentially setting up the notebook environment for executing the rest of the code. from sentinel_graph import notebook notebook.requires(sentinel_graph="0.3.8") spark.conf.set("spark.sql.parquet.datetimeRebaseModeInRead", "CORRECTED") Cell 3 This section is performing more Sentinel specific configurations by defining which Sentinel workspace to use, which timerange to use, which tables to use, etc. This is defining which data sources should be considered when building the graph. from pyspark.sql import functions as F from sentinel_lake.providers import MicrosoftSentinelProvider lake_provider = MicrosoftSentinelProvider(spark=spark) LOG_ANALYTICS_WORKSPACE = "Woodgrove-LogAnalyiticsWorkspace" # Auto-detected from the Microsoft Sentinel extension TARGET_USER = "ram723@int.zava-private.com" # Time filter — 7 days for broader blast radius context time_filter = F.col("TimeGenerated") >= F.expr("current_timestamp() - INTERVAL 7 DAYS") # --- IdentityInfo: user profile, roles, group memberships, risk --- df_identity_info = ( lake_provider.read_table("IdentityInfo", LOG_ANALYTICS_WORKSPACE) .filter(time_filter) .filter(F.lower(F.col("AccountUPN")) == TARGET_USER.lower()) ) # --- SigninLogs: interactive sign-ins to resources --- df_signins = ( lake_provider.read_table("SigninLogs", LOG_ANALYTICS_WORKSPACE) .filter(time_filter) .filter( (F.lower(F.col("UserPrincipalName")) == TARGET_USER.lower()) & (F.col("ResultType") == "0") # successful sign-ins ) ) Cell 4 This section is defining and building the nodes that will be used in the graph. The definitions include what events look like, which entities are involved, and how they are considered for each node type. # 1. User node (the target user) user_nodes = ( df_identity_info .select( F.col("AccountUPN"), F.col("AccountDisplayName"), F.col("RiskLevel"), F.col("RiskState"), F.col("AssignedRoles"), F.col("GroupMembership"), F.col("BlastRadius"), F.col("Department"), F.col("JobTitle"), F.col("IsMFARegistered"), F.col("IsAccountEnabled") ) .distinct() .withColumn("AccountUPN", F.lower(F.col("AccountUPN"))) ) Cell 5 This section is building out the schema for the graph. The schema for a graph is taking the columns and details from the tables in cell 3 while also tying them to the nodes and edges built in cell 4. # Build nodes first builder = ( GraphSpecBuilder.start() # === NODES === .add_node("User") .from_dataframe(user_nodes) .with_columns("AccountUPN", "AccountDisplayName", "RiskLevel", "RiskState", "AssignedRoles", "GroupMembership", "BlastRadius", "Department", "JobTitle", "IsMFARegistered", "IsAccountEnabled", key="AccountUPN", display="AccountUPN") # Then add edges and finalise into a GraphSpec spec = ( builder # === EDGES === .add_edge("AccessedInteractive") .from_dataframe(edge_user_resource_interactive) .source(id_column="UserUPN", node_type="User") .target(id_column="ResourceName", node_type="Resource") .with_columns("AppDisplayName", "TimeGenerated", "IPAddress", "ConditionalAccessStatus", "AccessType", "EdgeKey", key="EdgeKey", display="AccessType") Cell 6 This cell will take the schema from cell 5 and will load it into the graph visual builder. This will give a sample of what the graphs made with this Notebook will look like. These samples are fully interactive and will give an example of how it will look within the Defender portal. For example: Please note that the Authoring Agent may provide a different looking schema if following along with this example. The schema above is just meant to provide an example of what one will look like within a Notebook. Cell 7 This cell is taking each of the following steps performed and is going to compile and build the graph based on the data from the Sentinel data lake. This may take a few minutes to perform. With the custom graph built, the next step is to create a Graph Job to save the custom graph in the tenant for persistent use. If necessary, users can go back into the notebook to refine, expand, and improve the custom graph. Publishing graph Publishing a graph is the process of saving the graph in a tenant, allowing for the graph to be scheduled for recurring refreshes or as needed. This process saves the graph to the tenant and enables other SOC members to access this graph from within the Defender portal. To publish a custom graph, this must go through a Graph Job. This option is available within the Notebook experience as a button near the top: Clicking on the Create Scheduled Job button will open a new tab within VS Code with the jobs settings and the option to publish: There are two types of job schedules: On Demand: Saves the custom graph to the tenant and will persist the custom graph for 30 days. After 30 days, the graph will be auto deleted. Scheduled: Saves the custom graph to the tenant and will rebuild with new security telemetry based on a user defined schedule. Once everything is prepped, the custom graph can be published to the tenant by hitting the Submit button. Users can view and monitor the creation progress by finding the graph within the Sentinel extension navigation as it shows the graphs available for the environment: Finding and selecting the custom graph will open up a new tab that shows details around the graph. This includes details around the name, creation status (creating, ready, etc), author, and publishing date. Near the top, there are tabs for Job Details and Graph Query. These options allow the user to review the current Graph Job, make changes to the Graph Job, or query the graph within the notebook. Querying the graph in Defender Once the custom graph has been published and the creation status is Ready, users can query the new graph in the Defender Portal: Expand the Microsoft Sentinel navigation. Select Graphs. Either find the card with the graph title or search for it within the menu. Once found, click Query Graph to open it. The graph will open in the schema view. The schema here is a visual representation of which nodes, edges, and relations are part of the graph. This is what was built in the notebook. To query it, a user can write GQL queries or use ones that are provided. For this example, a query provided in the Getting Started tab will be used. This is a generic query that will show everything in a graph: // Visualize any graph MATCH (x)-[y]->(z) RETURN * LIMIT 100 More focused queries will yield more focused results. For example: MATCH (n_user:User)-[e_ip:SignedInFrom]->(n_ip:IPAddress) MATCH (n_user)-[e_signin:InteractiveSignIn]->(n_app:Application) WHERE n_user.UserPrincipalName = 'ENTERUSERNAMHERE' AND n_ip.IPAddress = 'IPADDRESSHERE' RETURN n_user, e_ip, n_ip, e_signin, n_app MATCH (n_user)-[x]->() MATCH (n_user)-[e_signin:InteractiveSignIn]->(n_app:Application) WHERE n_user.UserPrincipalName = 'ENTERUSERNAMEHERE' RETURN * From here, a user can continue the hunt, remediate the concerns, escalate this for further attention and remediation, or refine the graph as needed. Refining Graphs Throughout the process, the custom graph may need to be updated for various reasons, including: The scope of the hunt/investigation has expanded due to new information or the hypothesis being updated based on findings The original hypothesis of the hunt was incorrect or needs to be changed Important nodes are missing from the graph and need to be added To achieve this, return to VS Code and use the GitHub Copilot chat experience to add new telemetry, nodes, edges, or properties in the existing graph. The below example illustrates adding Azure resources as new assets by prompting the Sentinel graph authoring tool and instructing it on what needs to be added. Running the cells of the Notebook will yield an updated graph that includes the new changes: Graph samples in the Sentinel VS Code extension To help with learning, building, and using Sentinel graph, there are 5 graph samples included in the Sentinel extension within VS Code. These can be found by clicking on the Sentinel extension and looking under Notebook Samples > Graphs. Each graph included contains a Jupyter notebook containing the graph schema and mappings, as well as graph queries which can be run against the graph. These graphs ingest certain security telemetry and expect them to already exist within the Sentinel lake instance that is being used. If needed, the graph mapping can be updated to include/ exclude security telemetry as needed. These graph samples are also located within the Sentinel GitHub repository. Let’s look at one of the sample graphs – Phishing Email Killchain to understand how it can help during a security investigation. Using a graph: phishing email kill chain scenario Phishing is the number one initial access vector, yet investigating a phishing campaign requires correlating data across multiple Sentinel tables: EmailEvents, EmailUrlInfo, UrlClickEvents, EmailAttachmentInfo, DeviceFileEvents, and DeviceProcessEvents. Each table uses a different join key (NetworkMessageId, AccountUpn, SHA256, DeviceName), and analysts must stitch results together manually across several Defender portals. The core question every SOC analyst needs to answer is: “Who received the email, clicked the URL, downloaded the attachment, and executed it on their device?” In KQL, answering this requires 5+ sequential queries and 30–60 minutes of manual correlation. The Phishing Email Kill Chain graph fuses all of these tables into a single connected structure with 10 node types and 12 edge types, making it possible to answer that question in seconds with a single GQL traversal. SOC teams can create this graph in their tenant and start investigating phishing campaigns using graph-powered insights. Investigation with the Phishing Email Killchain graph Multi-hop traversal. The full kill chain from email to endpoint execution is a 4-hop path: Email → Attachment → Process → Device. In KQL, each hop is a separate join with a different key column. In the graph, it’s one MATCH clause. Structural detection. Campaign topology is visible as the graph’s shape — senders fanning out to emails, emails fanning out to users, shared URLs converging into hubs. These patterns are structural properties requiring no aggregation queries. Click-exposure overlay. The graph overlays email delivery and URL click paths in a single view. An analyst instantly sees which users received a phishing email AND clicked the embedded URL — no separate UrlClickEvents join needed. Example queries Below are three queries from the published phishing_email_killchain graph that demonstrate these capabilities. Each query is a single GQL statement that replaces multiple KQL joins. Query 1: Full Kill Chain — Email to Endpoint This query traces the complete attack path: phishing email → malicious attachment → process execution → endpoint device. In KQL, this requires joining 4 tables with different keys and temporal proximity filtering. MATCH (e:Email)-[ha:HasAttachment]->(att:Attachment) -[tp:TriggeredProcess]->(p:Process)-[od:OnDevice]->(d:Device) RETURN e, ha, att, tp, p, od, d LIMIT 10 Figure 1: Two complete kill chains — Invoice_Q3.xlsm → EXCEL.EXE → DESKTOP-FIN01 and DocuSign_Contract.pdf.exe → cmd.exe → DESKTOP-SALES02. Each path is one traversal replacing 4+ KQL joins. Query 2: Campaign Topology — Sender to Email to User to URL This query visualizes the full campaign structure: which senders sent which emails, who received them, and what URLs were embedded. The graph’s fan-out shape immediately reveals the blast radius and shared infrastructure. MATCH (s:Sender)-[se:Sent]->(e:Email)-[re:ReceivedEmail]->(u:User), (e)-[cu:ContainsUrl]->(url:Url) RETURN s, se, e, re, u, cu, url LIMIT 10 Figure 2: Campaign topology — 2 senders, 2 emails fanning out to 9 users and 2 URLs. The shared URL node (c0ntoso-share...) receiving edges from both emails reveals coordinated campaign infrastructure. Query 3: URL Click Exposure — Who Clicked the Phishing Links This query shows which emails contained URLs and which users clicked them. The Email → URL → User click chain is a single traversal that replaces joining EmailUrlInfo with UrlClickEvents. MATCH (e:Email)-[cu:ContainsUrl]->(url:Url)<-[cl:ClickedUrl]-(u:User) RETURN e, cu, url, cl, u LIMIT 10 Figure 3: Click exposure — 3 users clicked phishing URLs from 3 different emails. Each cluster shows Email → URL → User, instantly identifying click-through victims. These are just 3 examples of what is possible when using GQL on a graph. Users can author their own GQL queries to run on this graph to show other possibilities. Additional graph samples As mentioned, the Phishing Email Killchain graph is one of five graph samples that are available today for use within the VS Code Sentinel Extension. The remaining graphs are: Behavioral Attack Chain Ingests data from the SentinelBehaviorInfo, SentinelBehaviorEntities, AlertInfo, AlertEvidence, ThreatIntelIndicators, and BehaviorAnalytics tables to model the relationships between different detections, MITRE tactics/techniques, entities, and threat intel to high different traversals that are difficult to do with just KQL alone. Databricks Outbound Exfiltration Ingests data from the DatabricksNotebook, DatabricksSecrets, DatabricksDBFS, DatabricksClusters, DatabricksJobs, DatabricksSQLPermissions, IdentityInfo, AADUserRiskEvents, and BehaviorAnalytics tables to map Databricks notebook and cluster activities to the identities used in order to enable detections of unusual outbound data movement, privilege escalation, and data exfiltration patterns. DNS C2 Beaconing Ingests data from the DeviceNetworkEvents, DeviceInfo, and ThreatIntelIndicators to model DNS resolution patterns to detect C2 beaconing and other malicious patterns. OAuth Privilege Escalation Ingests data from the EntraServicePrincipals, AADRiskyServicePrincipals, and AADServicePrincipalSignInLogs tables to trace OAuth consent chains, credential abuse, and privilege escalation paths to identify hub users, over-permissions identities, and backdoor patterns that may exist. Closing This blog showcased an example of how a custom graph can be made with data within Microsoft Sentinel data lake and the help of GitHub Copilot, investigating a phishing email kill chain situation, and how to leverage the several graph templates that are provided in Sentinel. Get started today by using one of the template graphs, building your own graph, or by checking out the public documentation for Sentinel graph. Note: Custom graph API usage for creating graph and querying graph will be billed according to the Sentinel graph meter. Public Documentation: https://learn.microsoft.com/azure/sentinel/datalake/sentinel-graph-overview GQL Reference: Graph Query Language (GQL) reference for Microsoft Sentinel graph (Preview) | Microsoft Learn Planning graph Costs: Plan costs and understand pricing and billing - Microsoft Sentinel | Microsoft Learn
Introducing New Additions to Microsoft Sentinel Normalization and ASIM
TL;DR: New ASIM parsers for Azure Firewall, Key Vault, AWS CloudTrail (EC2, S3, IAM), and 10+ third-party products. Two new schemas — Asset Entities and AI Agent Events. Plus changelogs on GitHub and a heads-up on an upcoming breaking change in ProcessEvent parsers. What's New Security teams deal with logs from dozens of sources, each with its own schema. This painpoint makes it harder to write detections that work everywhere. The Advanced Security Information Model (ASIM) solves this by normalizing logs into a common schema, so a single analytic rule can cover a wide variety of sources without worrying about the source schema. Over the past few months, we have shipped a wave of new parsers, schemas, and improvements to ASIM. Here's everything you need to know. ASIM Parsers Azure Firewall Azure Firewall logs were previously only supported from the AzureDiagnostics table. Now, we support the dedicated resource-specific tables: Table ASIM Schema AZFWDnsQuery DNS AZFWNetworkRule NetworkSession AZFWApplicationRule WebSession Azure Key Vault Logs that are going to both AzureDiagnostics and resource-specific table AZKVAuditLogs are now normalized in the Audit Event schema. Azure Synapse SQL and Azure SQL Database Logs that are going to both AzureDiagnostics and resource-specific table SQLSecurityAuditEvents are now normalized to the Audit Event schema. Azure Traffic Analytics We have added support for the NTANetAnalytics table from Azure Traffic Analytics under the Network Session schema. AWS CloudTrail AWS CloudTrail previously only mapped to the Authentication schema. Now, you can correlate EC2, S3, and IAM activity through ASIM alongside your Azure telemetry: AuditEvent — Normalized EC2 events FileEvent — Normalized S3 events UserManagement — Normalized IAM and Cognito events Additional Parser Support We have also integrated the following third-party sources into ASIM: Authentication — Normalize sign-in and identity events for cross-source threat detection. CheckPoint Smart Defense Cisco IOS Cisco ISE Fortinet FortiGate Okta (OktaSystemLogs) Palo Alto — PAN-OS Palo Alto — Global Protect VMware vCenter Web Session — Normalize proxy and web gateway traffic. Cisco Umbrella Proxy Logs New ASIM Schemas We have created two new schemas to expand support new use cases. Asset Entities — Provides a normalized view of asset inventory data, enabling you to correlate files and assets across detections and investigations. AI Agent Events — Normalizes telemetry from AI-driven workflows and autonomous agents. Other Changes GitHub Changes Changelogs for every ASIM parser have been created to better help you understand updates and bug fixes we have implemented. As an example, here is the change log for the Authentication ASIM unifying parser. View Changelog Breaking Changes While aligning our ProcessEvent parsers to the official documentation, we found a naming inconsistency in the _Im_ProcessCreate function: Documentation specifies the parameter as targetusername_has Deployed parsers used targetusername What we changed: Both parameter names are now accepted. What you need to do: Update your analytic rules and queries to use targetusername_has. The legacy targetusername parameter will be deprecated in Summer 2026. What's Next We are continuing to expand ASIM with new parsers and schema capabilities to make detection authoring and log correlation even more powerful. BlueVoyant is also investing heavily in the ASIM ecosystem, building parsers that enhance detection coverage for their customers. See how they are using ASIM to operationalize detections. Want to get involved? Browse the ASIM parsers on GitHub, file issues, or contribute your own. We'd love to hear your feedback.The Worm in the Supply Chain: How Defender for Endpoint and Sentinel for SAP BTP Caught Shai-Hulud
On 29 April 2026, malicious versions of multiple SAP ecosystem npm packages were briefly published, creating a supply-chain exposure for SAP Cloud Application Programming (CAP) development environments and CI/CD pipelines. For a brief window that morning, affected developers have executed a credential-stealing payload on a workstation or, in higher-impact cases, within a CI/CD pipeline. SAP developers don't usually think of themselves as a juicy npm target. CAP, BTP, Fiori - that's enterprise turf, not crypto-stealer type territory – Until it is. Join me for the ride. See our latest click-video for an even more dynamic experience of SAP compromises. Affected packages and scope Four official npm packages from the SAP development ecosystem were published in malicious versions that day. Security researchers are calling the campaign "Mini Shai-Hulud" - the little cousin of the worm family that has been chewing its way through open-source registries for months. So, the "mini" part is a generous description in my opinion. Shai-Hulud has wriggled directly into the SAP supply chain, and that detail alone deserves a pause... SAP CAP is now interesting enough to have become a target. Four packages, all wearing legitimate SAP branding, all quietly swapped for evil twins: @cap-js/sqlite v2.2.2 @cap-js/postgres v2.2.2 @cap-js/db-service v2.10.1 mbt v1.2.48 These packages are not peripheral dependencies. The @cap-js/* modules are part of the SAP CAP Model used across custom development on SAP BTP, while mbt is the Cloud MTA Build Tool commonly embedded in CI/CD workflows that package and deploy Multi-Target Applications to BTP and on-premises environments. At roughly 930,000 weekly downloads, the combined exposure created meaningful downstream attack surface. The good news: SAP spotted the compromise fast, yanked the bad versions, and shipped clean replacements. The official guidance lives in SAP Security Note 3747787 - which carries the list of indicators of compromise, file hashes, and mitigation steps. Enough theory and evidence talk! Now, SHOW ME the detection! When the worm stirs beneath the sand, weak defenses vanish first. Observed telemetry in Microsoft Security products See below excerpt of Microsoft Defender for Endpoint from a compromised developer machine. The worm was neutralized immediately. Check the detection time (same day of release): Windows Defender AV detected malware ToString: DefenderDetection: File: /Users/User***/Projects/dara-api-manager-ui/node_modules/mbt/File***.js, Sha256: *** [Trojan:JS/SPchnStlr.BB], BlockingStatus: Prevented, BlockingStatusPriority: 900 DetectionTime: 2026-04-29 11:52:11Z DetectorName: Microsoft.Cyber.ObservationDetectors.DefenderConcreteDetector Observations (2): DefenderObservation Description: Defender detected and quarantined 'Trojan:JS/SPchnStlr.BB' in file 'File***.js' ThreatCategory = Trojan, ThreatFamily = SPchnStlr, How the Threat Actors Operationalized the Stolen Data The compromise allowed harvesting GitHub tokens, AWS/Azure/GCP secrets, npm credentials, Kubernetes config, SSH keys, .npmrc and .git-credentials files, and CI/CD environment variables. The hackers created a public GitHub repository on the victim’s own account, tagged with the description “A Mini Shai-Hulud has Appeared“ to exfiltrate their reaping. Within hours, more than a thousand such repositories were visible in public GitHub search. For additional views on the topic check out the blogs of our Sentinel for SAP partners: Onapsis, Pathlock, and SecurityBridge. Containment and Impact Reduction If you were not as lucky as the developer using Defender for Endpoint and VS Code, you need end to end monitoring of your landscape in and around SAP. Once the worm is loose with cloud tokens it may appear in various unexpected places. Microsoft Sentinel Solution for SAP covers your ERP crown jewels, your SAP BTP landscape and allows informed correlation with the rest of your IT estate. Microsoft’s correlation engine: ensures traceability automatic attack disruption and just-in-time hardening of potential attack paths. Developers using the cloud-based IDE SAP Business Application Studio are out of reach by Defender for Endpoint but profit from threat monitoring through Sentinel for SAP BTP integrating SAP BTP’s malware scanner the same way. See this in action in this click-video and in below screenshot. SOC analysts get actionable insights and tailored guidance from Security Copilot once SAP BTP signals are added to the Microsoft incident graph - no matter where the threat involving SAP originates from. Getting Started with Sentinel Solution for SAP Rollout of Sentinel for SAP BTP can happen immediately. Learn more from our deployment guide. Check out the security content reference for more info out-of-the-box detections. Sentinel for SAP which covers your ERP solutions and more, requires configuration of SAP Integration Suite as intermediary step. Learn more from our deployment guide. Check out the security content reference for more info out-of-the-box detections Final Words This incident illustrates how far the SAP BTP attack surface now extends and why patching alone is insufficient once malicious code reaches developer tooling and build infrastructure. Effective defense also requires telemetry, correlation, and response coverage across SAP and non-SAP environments. See you out there folks! #Kudos to Mahesh Mandva and Cameron Gardiner on riding shai-holud with me. Feel free to reach out to talk more about SAP Cyber Security. Cheers, Martin Useful Links SAP Note 3747787 with mitigation guide Mini Shai-Hulud: Multi-Ecosystem Developer Supply Chain Attack – Lab Space Click-Demo for SAP Cyber Security with Microsoft Sentinel for SAP Security Content | Microsoft Learn Sentinel for SAP BTP Security Content | Microsoft LearnWhat’s new in Microsoft Sentinel: May 2026
Welcome to the May edition of What's new in Microsoft Sentinel. This month’s updates focus on unified role-based access control (RBAC), ecosystem breadth, AI-agent security, and high-assurance identity. RBAC and row-level scoping are now generally available, giving security teams a single, granular permissions model across Sentinel and the Microsoft Defender portal and enabling multi-team SOC collaboration. The Sentinel connector catalog has passed 400 connectors, expanding coverage across Microsoft and third-party data sources and helping customers and partners onboard new data faster with the Codeless Connector Framework (CCF). The Agent 365 connector, now in public preview, brings AI agent telemetry into Sentinel data lake as first-class standardized signals so you can monitor agent behavior alongside identity, endpoint, and cloud activity. Finally, Entra Verified ID partner integrations in Microsoft Security Store are now generally available, delivering high‑assurance identity verification that makes account recovery after compromise far safer and significantly reduces the risk of re‑compromise. Read on for the full list of updates across Sentinel in May. Sentinel innovations: Sentinel SIEM Sentinel data lake Microsoft Security Store Sentinel SIEM Unified role-based access controls and row level scoping [Generally available] Sentinel now delivers general availability of two powerful access management capabilities: Unified RBAC and row-level data scoping. Together, these innovations provide a consistent, end-to-end model for controlling who can access data and what actions they can take — extending unified permissions management across the Defender portal while enabling granular, row-level visibility within a single Sentinel workspace. With Unified RBAC, organizations can simplify and centralize permissions across security workloads, reducing operational overhead, while row-level scoping enables secure collaboration across multiple teams by ensuring users only see data aligned to their role or scope. This milestone unlocks more scalable, multi-team SOC operations without the need for workspace segmentation, helping us to advance toward fully unified, granular access control across Microsoft Security. Tenant groups [Public preview] Managing security across multiple tenants just got simpler. Tenant Groups in the Microsoft Defender multi-tenant portal (MTO) give managed security service providers (MSSPs), cloud service partners (CSPs), and multi-tenant security teams a flexible way to organize tenants into logical groupings such as customer segment, geography, or operational priority, and instantly switch views with a single click. This streamlined experience reduces noise, improves investigation focus, and aligns to how teams actually work, all while respecting existing permissions and access controls. Learn more. Out-of-the-box integrations for Sentinel automation [Public preview] Out-of-the-box (OOTB) integrations for Sentinel automation brings a centralized catalog to easily discover, configure, and manage both Microsoft and third-party integrations. With simple, authentication-based setup, users can quickly add integrations and seamlessly incorporate them into playbooks. The experience places OOTB and custom integrations side by side, with enhanced with smart search, recommendations, and duplicate prevention to streamline automation workflows end to end. Learn more. UEBA enhancements [Public preview] Microsoft Sentinel UEBA continues to evolve with improvements that simplify management and expand detection coverage. A dedicated UEBA tab view in the Sentinel settings page consolidates UEBA and behaviors settings, making configuration easier to find and manage. Learn more. UEBA insights and anomalies now support the OktaV2_CL table alongside the existing Okta_CL table, extending anomalous activity and anomalous MFA failures detections to customers using the newer Okta connector format, without requiring new anomaly types. Learn more. UEBA extends GCP Audit Logs coverage with five anomaly detections for login activity, privileged actions, resource deployments, secret/KMS key access, and infrastructure usage. Learn more. Together, these updates make UEBA easier to operate while extending its visibility into identity and behavior signals from additional cloud and identity providers. Read the latest blog from the Microsoft Defender Research Team to learn more about Microsoft Sentinel UEBA and binary feature stacking, which uses clear binary signals to help establish behavioral context and inform investigation and detection decisions. Threat Intelligence – TAXII Export connector [Generally available] Sentinel supports threat intelligence export through the built-in Threat Intelligence – Trusted Automated Exchange of Intelligence Information (TAXII) Export connector, giving customers a standards-based way to share curated Structured Threat Information Expression (STIX) objects with supported TAXII 2.1 platforms. Configured from the Defender portal, the connector handles destination setup and intelligence delivery to external platforms. The capability supports cross-organization intelligence sharing for collective defense and centralized management in multi-tenant environments, with use cases across government, critical infrastructure, and large distributed organizations. Additional enhancements are planned, including more export options and expanded destination support. Learn more. Decision-stage resources for SIEM migration to Sentinel The AI-powered SIEM migration experience helps teams analyze detections, identify required data sources and connectors, and plan a phased move to Sentinel. But, customers still need help turning that analysis into a clear decision. To support that step, we’re introducing two new customer-facing resources: the Sentinel SIEM Migration Decision and Planning Guide, which explains the migration journey, outputs, and decision checkpoints before execution, and the Decision-Stage Customer FAQ, which answers common questions around disruption, cost, dual running, detection coverage, and delivery support. Together, these resources help make migration conversations more concrete and move teams more quickly from evaluation to a clearer, lower-risk next step. Learn more: Read the blog: AI-powered SIEM migration experience announcement Download the guide: Decision and planning guide Download the FAQ: Decision-stage customer FAQ Learn more: SIEM migration experience documentation Register for live AMA (Jun 23 at 9am PT): Live Microsoft Tech Community AMA on SIEM migration Sentinel data lake 400+ Sentinel data connectors The Sentinel connector catalog now includes 400+ connectors, providing broad, ready-to-deploy coverage across Microsoft and third-party data sources. Customers can flexibly ingest security data into Microsoft Sentinel analytics tier or the data lake tier. The Codeless Connector Framework (CCF) and VS code-based connector builder agent enables partners and customers to onboard new data sources faster and scale the catalog. Discover connectors in the Sentinel Content hub within the Defender portal or build custom connectors when needed. Learn more. Agent 365 connector [Public preview] Agent 365 connector streams AI agent telemetry from Agent 365 into Sentinel data lake, giving SOC teams visibility into agent behavior alongside identity, endpoint, and cloud signals. With the Agent 365 connector in place, Sentinel data lake becomes the system of record for agent security, turning activity such as data exposure or access drift into first-class security signals that analysts can correlate, hunt across, and investigate. Telemetry is normalized and to mapped to standard Advanced Security Information Model (ASIM) schemas, ready for analytics and detections, and end-to-end investigations can run through KQL, graph, and MCP-powered workflows. Install the connector with a single click from Sentinel Content Hub in the Defender portal. Learn more. CCF support for Azure Blob Storage [Public preview] Sentinel Codeless Connector Framework (CCF) supports Azure Blob Storage as a data source, providing an ingestion pattern designed for high-volume security data. Partners and customers can build CCF connectors that read from Blob Storage through a durable architecture that buffers spikes, handles backpressure, and reduces data loss risk during outages or throttling, making ingestion more reliable for variable or distributed pipelines. The pattern broadens compatibility with partners already streaming logs to Azure as part of their audit data delivery, with Cloudflare and Netskope as early adopters. App Assure further provides engineering-backed support for designing, validating, and remediating the Azure Blob Storage CCF connector integration. Learn more. Data filtering and splitting [Generally available] At RSAC, we announced built‑in filtering and splitting capabilities in Microsoft Sentinel, which is now generally available. As security teams ingest more data, it is important to optimize security data pipeline by controlling what data is ingested and in which tier. With filtering and splitting natively integrated into the Defender portal, security teams can shape data before it reaches Sentinel, without switching tools or managing custom JSON files. Using simple KQL‑based transformations directly in the UI, you can filter low‑value events and intelligently route data, making ingestion optimization faster, more intuitive, and easier to manage at scale. Filtering at ingest time allows you to remove low‑value or benign events to reduce noise, lower unnecessary processing, and ensure high‑signal data drives detections and investigations. Splitting enables intelligent routing of data between the analytics tier and the data lake tier based on relevance and usage. Together, these capabilities help you balance cost and performance while scaling data ingestion sustainably as your digital estate grows. Learn more. Transition your Sentinel connectors to the Codeless Connector Framework (CCF) [Action required] Azure has announced that the legacy Azure Data Collection API will be deprecated on September 14, 2026. Sentinel recommends customers review existing connectors and upgrade to the latest Codeless Connector Framework (CCF) versions to ensure continued access to the newest Sentinel capabilities. CCF delivers a fully managed SaaS experience with built-in health monitoring, centralized credential management, and improved performance. This enables partners and customers to onboard new data sources faster and at scale. Microsoft Security Store Entra Verified ID partner integrations via Security Store [Generally available] Security Store helps organizations secure one of the most critical steps in incident response: safe account recovery after compromise. Once a SOC team detects and contains a potential account takeover (ATO), restoring access requires high confidence that the user is legitimate. Through partner integrations with IDEMIA, AU10TIX, CLEAR, 1Kosmos, and WhoAmI, customers can extend Entra Verified ID with high-assurance identity verification (such as document and biometric checks) to validate users during recovery, onboarding, or helpdesk workflows. This helps replace weaker fallback methods that attackers often exploit, enabling SOC and IT teams to safely restore access while reducing risk of re-compromise. Learn more. Purview Data Security Triage Agent in Defender [Public preview] Security Store powers how customers discover and activate data security agents across Defender and Microsoft Purview, starting with the Data Security Triage Agent. This capability delivers AI-generated summaries and prioritization of Data Loss Prevention (DLP) alerts directly into Defender XDR, helping security teams reduce noise and focus on the incidents that matter most. By unifying discovery and activation through Security Store, customers can deploy data security agents in fewer steps and enable more integrated workflows across threat and data protection surfaces. Learn more. Additional resources Blogs and documentation: From idea to production: Building Security Store Advisor with an agentic SDLC Upcoming webinars: June 4: End-to-End Security in the Age of Agentic AI June 10: Deploy, optimize, and implement threat protection with Sentinel June 10: Security Foundations for AI Adoption June 24: Modern Security Made Simple: Stay Ahead of Threats with Sentinel Upcoming events: June 2–3: Microsoft Build, San Francisco (and free online) CEO Satya Nadella Day 1 keynote 90+ sessions, Microsoft Security experts onsite Register: build.microsoft.com 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!
Agent 365 connector: Monitor, hunt, and investigate AI agent activity in Microsoft Sentinel
As enterprises scale the use of AI agents, SOC teams need visibility into AI agent behavior. The Agent 365 connector, now in public preview, streams rich agent telemetry from Agent 365 into Microsoft Sentinel data lake. Agent activity, such as agent data exposure or access drift, is surfaced alongside other security data, giving SOC teams a unified view across digital environments. AI Agent actions are correlated with agent identity, endpoint, and cloud signals, enabling analysts to run end‑to‑end investigations using KQL, graph, and MCP-powered workflows. Why this matters for organizations By centralizing security and AI agent telemetry in Sentinel data lake, organizations establish a unified control plane for securing AI agents. This enables security teams to analyze agent activity in context with broader signals and investigate using familiar Sentinel tools. This unlocks the ability for SOCs to detect risky or anomalous agent behavior early, understand impact quickly, and respond with speed and confidence. As AI agents take on real operational responsibility, this level of visibility is critical to prevent blind spots, reduce risk, and ensure agents operate safely at enterprise scale. End‑to‑end visibility into AI agent behavior: A centralized view of AI agent behavior allows AI agents to be treated as first-class entities alongside users, identities, endpoints, and workloads. Advanced hunting with KQL: Hunt using KQL to proactively uncover unusual AI agent execution patterns, sensitive actions, or activity without clear human context. These hunts help surface potential risk early using the same workflows already used for other security data. Analyzing blast radius and impact with Sentinel graph: Security teams can correlate AI agent activity with identities, endpoints, and cloud resources to understand blast radius and potential impact during an investigation. By pivoting across related entities in Sentinel, analysts can assess how agent actions connect to the broader environment and support deeper, end‑to‑end investigations. Querying agent data through MCP: Use MCP to surface agent observability data through AI assistants, letting analysts pull agent telemetry into investigation workflows alongside other Sentinel data. Agent 365 connector key capabilities Install the Agent 365 connector with a single click using Sentinel Content Hub in the Defender portal. Once enabled, two capabilities come online automatically: Unified agent telemetry across Agent 365 agent experiences: Rich Agent 365 agent telemetry streams into Sentinel data lake, ready to analyze alongside identity, endpoint, and cloud signals using familiar SOC workflows. ASIM unified schema for AI agent observability: Agent 365 agent observability data is normalized into an ASIM-aligned schema so it is consistent, queryable, and ready for analytics and detections. With the connector in place, Sentinel data lake becomes the system of record and the control plane for Agent 365 agent security—turning agent behavior into first-class security signals across SecOps workflows like hunting, investigation, detection engineering, and response. Use cases Prevent sensitive data exposure from misconfigured agents When an AI agent is granted broader access than intended, a crafted prompt could override safeguards and expose confidential data. With agent telemetry, security teams can trace the full execution path—from prompt to tools to data access—to quickly identify the root cause and contain the exposure. Detect and control agent access drift over time As agents take on new tasks, their permissions can expand beyond the original scope, often without clear visibility. Agent telemetry enables continuous behavioral baselining, making it easier to spot abnormal access patterns early and prevent privilege misuse before it escalates. Uncover hidden lateral movement across agent workflows Agents often collaborate and delegate tasks across systems, creating complex chains of execution that are difficult to track. Agent telemetry provides visibility into these interactions, mapping delegation paths and helping teams understand and limit the potential blast radius. Defend against prompt injection and manipulation attacks Attackers can craft prompts to override agent instructions and manipulate behavior. By capturing prompts and reasoning flows, agent telemetry enables detection of these attacks and provides the context needed to investigate and remediate quickly. Accelerate SOC investigations with end-to-end visibility When an agent is involved in a security alert, understanding its actions can be challenging. Agent telemetry correlates prompts, identities, tools, and data access into a unified timeline, giving SOC teams the clarity needed to investigate faster and respond with confidence. Strengthen governance and compliance for AI agents Organizations need visibility into what agents exist and what data they can access. Agent telemetry provides a comprehensive audit trail of agent activity and access patterns, supporting compliance reporting and policy enforcement. Enable proactive threat hunting on agent behavior Security teams need to stay ahead of emerging risks as agent usage grows. Agent telemetry enables advanced hunting across agent activity, helping detect anomalies, uncover patterns, and identify threats before they impact the organization. Get started with Agent 365 connector Getting started is straightforward. In the Microsoft Defender portal, navigate to Microsoft Sentinel Open Content hub and search for Agent 365 Install the Agent 365 Connector (if not already installed) Open the connector page and select Connect to begin ingestion Once connected, AI agent telemetry starts flowing into Sentinel, ready for hunting, investigation, and response. Data ingestion and analytics are billed using existing Sentinel meters. Learn more Find the Agent 365 data connector | Microsoft Learn Discover and manage Sentinel out-of-the-box content | Microsoft Learn Connect data sources to Sentinel by using data connectors | Microsoft Learn Sample KQL queries for Sentinel data lake | Microsoft Learn Watch the Sentinel data lake video playlist | Microsoft Security Get started with Sentinel data lake | Microsoft LearnExtending Sentinel Data Integration: Azure Blob Storage Support for CCF Connectors
As organizations scale their security operations, the ability to ingest, process, and analyze high volumes of data reliably becomes increasingly critical. Microsoft Sentinel continues to expand its ecosystem through the Codeless Connector Framework (CCF), enabling ISVs to build and deliver integrations with Sentinel faster while simplifying deployment for customers. Today, CCF extends even further with support for Azure Blob Storage, introducing a new pattern for how data can be delivered into Sentinel. Expanding Connector Patterns with Azure Blob Storage CCF has traditionally enabled connectors that integrate directly with partner APIs and data sources. With this latest enhancement, ISVs can now build connectors that read data from Azure Blob Storage—unlocking new flexibility in how security data is collected and delivered. In this model, an ISV writes data to an Azure Blob Storage account. The Sentinel connector then reads from that storage layer, using Azure-native components such as Event Grid and storage queues to process events and forward them through data collection rules (DCR) into Log Analytics workspace. This approach introduces a durable data layer between the data source and Sentinel, enabling more resilient and scalable ingestion scenarios. Why a durable data layer matters By leveraging Azure Blob Storage as part of the ingestion pipeline, CCF connectors gain important operational advantages. This architecture allows data to be buffered and processed asynchronously, helping manage fluctuations in data volume and ensuring consistent delivery. Key benefits include: Resilience: Buffers spikes and handles backpressure to maintain steady ingestion Improved Compatibility: Supports widely adopted Azure Blob-based log streaming, enabling seamless integration with partners that already use Azure for audit data delivery Data protection: Reduces risk of data loss during outages or throttling Scalability: Supports high-volume ingestion scenarios across tenants Flexibility: Enables architectures that can support multiple SIEMs or data consumers Together, these capabilities make CCF Azure Blob Storage based connectors a strong fit for partners managing large, variable, or distributed data pipelines. Partner adoption Early partners are already taking advantage of this capability to modernize their integrations and support evolving customer needs. Cloudflare Cloudflare integrates with Microsoft Sentinel using the Codeless Connector Framework (CCF) to bring Cloudflare log data into centralized security operations workflows. The connector ingests Cloudflare logs—delivered via Logpush to Azure Blob Storage—into Sentinel for analysis, enabling security teams to correlate web, network, and application activity with other security signals. By combining Cloudflare’s global threat visibility with Sentinel analytics and automation, this integration supports more effective threat detection, investigation, and incident response across Cloudflare‑protected environments. Netskope Web Transaction Events Netskope integrates with Microsoft Sentinel to provide detailed visibility into web and cloud activity across users, applications, and SaaS services. The connector ingests Netskope web transaction logs into Sentinel—leveraging Azure Blob Storage as a staging layer for log streaming and ingestion—to enable near real‑time analysis of user behavior, policy violations, and potential threats. By combining Netskope’s inline web inspection with Sentinel’s analytics and correlation capabilities, this integration helps security teams detect risky activity, investigate incidents, and strengthen monitoring across modern cloud environments. These integrations demonstrate how Azure Blob Storage support can simplify ingestion architectures while improving reliability and scalability for customers. Here is what our partners say about the functionality. Cloudflare: Netskope: Get started Developers can begin building CCF Azure Blob Storage -enabled connectors today using the guidance on Microsoft Learn. This documentation provides step-by-step instructions for configuring storage, processing events, and connecting data to Sentinel. In the unlikely event that you encounter any issues in building or updating your connector, App Assure is here to help. We are an engineering-backed team committed to supporting customers and software development companies throughout their journey with Sentinel to streamline integration and accelerate time to market. Reach out to us via our intake form for assistance.What’s new in Microsoft Sentinel: April 2026
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. 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. 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. 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. 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. 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: Featured blog: App Assure launches its Sentinel Advisory Service Agentic use cases for developers on Microsoft Sentinel The Unified SecOps Transition: Why It Is a Security Architecture Decision, Not Just a Portal Change What's new in Microsoft Defender – April 2026 Webinars and training: Featured webinar: Powering the Agentic SOC with Scott Woodgate, General Manager, Microsoft Threat Protection Featured training: Introducing the Microsoft Sentinel Training Lab. Hands-On Security Operations in Minutes Beyond KQL – Unlocking SOC Insights with Sentinel data lake Jupyter Notebooks Hyper scale your SOC: Manage delegated access and role-based scoping in Microsoft Defender 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
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 Running notebooks on the Microsoft Sentinel data lake - Microsoft Security | Microsoft Learn Microsoft Sentinel data lake Microsoft Sentinel Provider class reference | Microsoft Learn Getting Started with Data Wrangler in VS Code Beyond KQL: Unlocking SOC Insights With Sentinel data lake Jupyter Notebooks | Microsoft Virtual Ninja Training
Enforce Cost Limits on KQL Queries and Notebooks in the Microsoft Sentinel Data Lake
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.
