The Sentinel migration mental model question: what's actually retiring vs what isn't?
Something I keep seeing come up in conversations with other Sentinel operators lately, and I think it's worth surfacing here as a proper discussion. There's a consistent gap in how the migration to the Defender portal is being understood, and I think it's causing some teams to either over-scope their effort or under-prepare. The gap is this: the Microsoft comms have consistently told us *what* is happening (Azure portal experience retires March 31, 2027), but the question that actually drives migration planning, what is architecturally changing versus what is just moving to a different screen, doesn't have a clean answer anywhere in the community right now. The framing I've been working with, which I'd genuinely like to get other practitioners to poke holes in: What's retiring: The Azure portal UI experience for Sentinel operations. Incident management, analytics rule configuration, hunting, automation management: all of that moves to the Defender portal. What isn't changing: The Log Analytics workspace, all ingested data, your KQL rules, connectors, retention config, billing. None of that moves. The Defender XDR data lake is a separate Microsoft-managed layer, not a replacement for your workspace. Where it gets genuinely complex: MSSP/multi-tenant setups, teams with meaningful SOAR investments, and anyone who's built tooling against the SecurityInsights API for incident management (which now needs to shift to Microsoft Graph for unified incidents). The deadline extension from July 2026 to March 2027 tells its own story. Microsoft acknowledged that scale operators needed more time and capabilities. If you're in that camp, that extra runway is for proper planning, not deferral. A few questions I'd genuinely love to hear about from people who've started the migration or are actively scoping it: For those who've done the onboarding already: what was the thing that caught you most off guard that isn't well-documented? For anyone running Sentinel across multiple tenants: how are you approaching the GDAP gap while Microsoft completes that capability? Are you using B2B authentication as the interim path, or Azure Lighthouse for cross-workspace querying? I've been writing up a more detailed breakdown of this, covering the RBAC transition, automation review, and the MSSP-specific path, and the community discussion here is genuinely useful for making sure the practitioner perspective covers the right edge cases. Happy to share more context on anything above if useful.New Blog Post | Automated Detection and Response for Azure WAF with Sentinel
Full article: Automated Detection and Response for Azure WAF with Sentinel - Microsoft Community Hub Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities. SQL injection and Cross-site scripting are among the most common attacks. Preventing such attacks in application code is challenging. It can require rigorous maintenance, patching, and monitoring at multiple layers of the application topology. A WAF solution can react to a security threat faster by centrally patching a known vulnerability, instead of securing each individual web application. Azure Web Application Firewall (WAF) is a cloud-native service that protects web apps from common web-hacking techniques. This service can be deployed in a matter of minutes to get complete visibility into the web application traffic and block malicious web attacks. Integrating Azure WAF with Microsoft Sentinel (Cloud Native SIEM/SOAR solution) for automated detection and response to threats/incidents/alerts would be an added advantage and reduces the manual intervention needed to update the WAF policy. In this blog, we will discuss about WAF detection templates in Sentinel, deploying a Playbook, and configuring the detection and response in Sentinel using these templates and the Playbook. Original Post: New Blog Post | Automated Detection and Response for Azure WAF with Sentinel - Microsoft Community HubNew Blog Post | The Easy Way to Get the ARM Deployment Template for a Microsoft Sentinel Solution
The Easy Way to Get the ARM Deployment Template for a Microsoft Sentinel Solution - Azure Cloud & AI Domain Blog (azurecloudai.blog) If you need the deployment (ARM) template for any Microsoft Sentinel Solution, there’s an easy in the UI to way to obtain it. The ARM template will allow you to deploy the Solution using your favorite DevOps method. Once you locate the Solution you want install, begin the actual, normal installation process. When you get to the end of the Solution installation wizard, instead of choosing to go ahead and allow the Solution to be installed, click or tap the “Download template for automation” link. This takes you to a page where the template has been auto generated for you where you can download it, add it to your ARM template library, or deploy it directly from here. You can also use this page to adjust any of the parameters, variables, or resources for the template. Original Post: New Blog Post | The Easy Way to Get the ARM Deployment Template for a Microsoft Sentinel Solution - Microsoft Community Hub
Sentinel Cost Optimization Series - Part 1 - Data prioritization
* There are graphs in this post, but I can't seem to upload/insert them; please visit the link in each part to see the picture. Problem statement Data prioritization is an issue that any SIEM or data gathering and analysis solution must consider. The log that we collect to SIEM is typically security-related and capable of directly creating alerts based on the event of that log, such as EDR alerts. However, not all logs are equally weighted. For example, the proxy log only contains the connections of internal users, which is very useful for investigation, but it does not directly create alerts and has a very high volume. To demonstrate this, we categorize the log into the primary log and secondary log based on its security value and volume. https://i.ibb.co/d4CzxCH/sentinel-cost-optimize-p1-1.png The metadata and context of what was discovered are frequently contained in the primary log sources used for detection. However, secondary log sources are sometimes required to present a complete picture of a security incident or breach. Unfortunately, many of these secondary log sources are high-volume verbose logs with little relevance for security detection. They aren’t useful unless a security issue or threat search requires them. On the current traditional on-premise solution, we will use SIEM alongside a data lake to store secondary logs for later use. https://i.ibb.co/kyc96Dx/sentinel-cost-optimize-p1-architect-onpremise.png Because we have complete control over everything, we can use any technology or solution, making it simple to set up (Eg. Qradar for SIEM and ELK for data lake). However, for cloud-naive SIEM, this becomes more difficult, particularly with https://azure.microsoft.com/en-gb/products/microsoft-sentinel/. Microsoft Sentinel is a cloud-native security information and event manager (SIEM) platform that includes artificial intelligence (AI) to help with data analysis across an enterprise. To store and analyze everything for Sentinel, we typically use Log Analytics with the Analytics Logs data plan. However, this is prohibitively expensive, costing between $2.00 and $2.50 per GB ingested per day depending on the Azure region used. Current Solution Storage Account (Blob Storage) To store these secondary data, the present approach uses https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction. Blob storage is designed to hold large volumes of unstructured data, which implies it does not follow a certain data model or specification, such as text or binary data. This is a low-cost option for storing large amounts of data. The architecture for this solution is as follows: https://i.ibb.co/YhDJvJ8/sentinel-cost-optimize-p1-architect-blob.png However, Blob Storage has a limitation that is hard to ignore. The data in Blob Storage is not searchable. We can circumvent this by using as demonstrated in https://docs.microsoft.com/en-us/azure/search/search-blob-storage-integration, but this adds another layer of complexity and pricing that we would prefer to avoid. The alternative option is to use https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/externaldata-operator?pivots=azuredataexplorer, but this is designed to obtain small amounts of data (up to 100 MB) from an external storage device, not massive amounts of data. Our Solution High-Level Architecture Our solution used Basic Logs to tackle this problem. https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overview#log-data-plans-preview is a less expensive option for importing large amounts of verbose log data into your Log Analytics workspace. The Basic log also supports a subset of KQL, making it searchable. To get the log into the Basic Log, We need to use a Custom table generated with the Data Collection Rule (DCR)-based logs ingestion API. The structure is as follows: https://i.ibb.co/2hZ6Gpx/sentinel-cost-optimize-p1-architect.png Our Experiment In our experiment, we use the following component for the architecture: Component Solution Description Source Data VMware Carbon Black EDR Carbon Black EDR is an endpoint activity data capture and retention solution that allows security professionals to chase attacks in real-time and observe the whole attack kill chain. This means that it captures not only data for alerting, but also data that is informative, such as binary or host information. Data Processor Cribl Stream Cribl helps process machine data in real-time - logs, instrumentation data, application data, metrics, and so on - and delivers it to a preferred analysis platform. It supports sending logs to Log Analytics, but only with the Analytics plan. To send the log to the Basic plan, we need to set up a data collection endpoint and rule, please see Logs ingestion API in https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-ingestion-api-overview for additional information on how to set this up. And we also use a Logic App as a webhook to collect the log and send it to the Data collection endpoint. The environment we use for log generation is as follows: Number of hosts: 2 Operation System: Windows Server 2019 Number of days demo: 7 The number of logs we collected for our test environment are: Basic Log generated: 30.2 MB Alerts generated: 16.6 MB https://i.ibb.co/HYXyDYL/sentinel-cost-optimize-p1-2.png The cost is based on the East US region, the currency is the USD, and the Pay-As-You-Go Tier was used to determine the number saved using the generated data with 1000 hosts and 30 days retention period. The calculation using only Analytic Log Table Ingestion Volume (GB) Cost per GB (USD) Total cost per day (USD) Total cost per retention period (USD) Host number Retention (Days) Cb_logs_Raw_CL 2.16 2.3 4.96 148.84 1000 30 Cb_logs_alert_CL 1.19 2.3 2.73 81.81 1000 30 Total 7.69 230.66 If we use Analytic Log with Storage Account Table Ingestion Volume (GB) Cost per GB (USD) Total cost per day (USD) Total cost per retention period (USD) Host number Retention (Days) Cb_logs_Raw_CL 2.16 0.02 0.04 1.29 1000 30 Cb_logs_alert_CL 1.19 2.3 2.73 81.81 1000 30 Total 2.77 83.11 If we use Analytic Log with Basic Log Table Ingestion Volume (GB) Cost per GB (USD) Total cost per day (USD) Total cost per retention period (USD) Host number Retention (Days) Cb_logs_Raw_CL 2.16 0.5 1.08 32.36 1000 30 Cb_logs_alert_CL 1.19 2.3 2.73 81.81 1000 30 Total 3.81 114.17 Now let’s compare these 3 solutions together and get an overall look altogether. Only Analytic Log Analytic Log with Storage Account Analytic Log with Basic Log Cost calculated $230.66 $83.11 $114.17 Searchable Yes No Yes but cost $0.005 per GB Retention Up to 2,556 days (7 years) 146,000 days (400 years) Up to 2,556 days (7 years) Limitation Even though the Basic Log is an excellent choice for ingesting hot data, it does have some limitations that are difficult to overlook: The retention period is only 8 days, and this retention can’t be increased, after that, it will either be deleted or archived KQL language access is limited, for a list of what operators can be used, please see https://learn.microsoft.com/en-us/azure/azure-monitor/logs/basic-logs-query?tabs=portal-1#kql-language-limits There is a charge for interactive queries ($0.005/GB-scanned) This is the first post in this Sentinel Cost Optimization series. I hope this helps you have another choice to consider when setting up and sending your custom log to Sentinel.New Blog Post | Introduction to Machine Learning Notebooks in Microsoft Sentinel
Read the full blog post here: Introduction to Machine Learning Notebooks in Microsoft Sentinel It has never been harder to keep hybrid environments secure. Microsoft’s Security Research teams are observing an increasing number and complexity of cybercrimes occurring across all sectors of critical infrastructure, from targeted ransomware attacks to increasing password and phishing campaigns on email, according to the Microsoft Digital Defense Report. The 2022 Cost of Insider Threats reported that threat incidents have risen by over 44% in the last two years, with associated costs exceeding $15.38M per incident per year, up by a third in the preceding years. The report also concluded that there has been a 10.3% increase in the average time taken to contain an incident, from 77 days to 85 days. Advanced tools, techniques, and processes used by threat actor groups allow them to counter obsolete defences and scale their attack campaigns to a broad range of victims, from government organisations to for-profit enterprises. Original Post: New Blog Post | Introduction to Machine Learning Notebooks in Microsoft Sentinel - Microsoft Tech CommunityNew Blog Post | Microsoft Sentinel customizable machine learning based anomalies Generally Available
Microsoft Sentinel customizable machine learning based anomalies is Generally Available - Microsoft Tech Community Security analysts can use anomalies to reduce investigation and hunting time, as well as detect new and emerging threats. Typically, these benefits come at the cost of a high benign positive rate, but Microsoft Sentinel’s customizable anomaly models are tuned by our data science team and trained with the data in your Microsoft Sentinel workspace to reduce, providing out-of-the box value. If security analysts need to tune them further, the process is simple and requires no knowledge of machine learning. Read this blog to find out which capabilities were supported in Public Preview and how to tune anomalies: Democratize Machine Learning with Customizable ML Anomalies - Microsoft Tech Community In this blog, we will discuss how customizable machine learning based anomalies have improved since Public Preview. Original Post: New Blog Post | Microsoft Sentinel customizable machine learning based anomalies Generally Available - Microsoft Tech CommunityNew Blog Post | Create and delete incidents in Microsoft Sentinel
Create and delete incidents in Microsoft Sentinel - Microsoft Tech Community During the everyday work of the SOC, suspicious and malicious events surface from many sources. Events which are identified by SIEM and XDR systems are aggregated into alerts, and those alerts become incidents. However, at times a possible security breach is reported by other means - such as a phone call, an email, hunting results or a customer request. Those incidents need to be documented when it has been reported, partially investigated, or even resolved. As part of our journey to build better incident management capabilities in Microsoft Sentinel, we would like to announce the "Manual incident creation" feature, along with the "delete incident" capability. With the "manual incident creation" feature, analysts can now create an incident manually in the Sentinel portal and also by using the new "Create incident (preview)" LogicApp action (joining the already existing ability to create an incident through the API). If an incident was mistakenly logged, or is an exact duplicate of another incident, it can now be deleted from the grid using the new "delete" option or using an API - leaving only audit information in the Log Analytics table. Two playbooks templated are available in the template gallery, allowing out of the box incident creation using email template and Microsoft Forms - thus reducing the time between the SOC learning about the incident and the time the incident is logged in Sentinel. Original Post: New Blog Post | Create and delete incidents in Microsoft Sentinel - Microsoft Tech Community
New Blog Post | Anomali Limo Feeds for Microsoft Sentinel to Expire for Good
https://rodtrent.com/8bh I’m sure there’s some organizational reason why Anomali wants to detach itself from maintaining these feeds. If you use these feeds for Microsoft Sentinel demos, consider querying the ThreatIntelligenceIndicator table for the Limo feeds and exporting the results to save them for later for when the active feed dries up. ThreatIntelligenceIndicator | where SourceSystem contains "Limo" You can then use our new functionality to import flat files into ThreatIntelligence and reuse the continually stale indicators.New Blog Post | Microsoft Sentinel this Week – Issue #72
https://rodtrent.com/w9i I want to mention one thing this week. This community is, in part, fueled by the LinkedIn community group. So, if you’re looking for more content than just our weekly time together in this newsletter, you should join the group on LinkedIn. There’s a lot of additional engagement there, including the ability to ask questions and get answers pretty quickly. LinkedIn community group: https://rodtrent.com/rjp?utm_campaign=Microsoft%20Sentinel%20this%20Week&utm_medium=email&utm_source=Revue%20newsletter The community group membership continues growing by leaps and bounds so there’s always someone available to engage with.New Blog Post | Microsoft Sentinel this Week - Issue #62
Microsoft Sentinel this Week - Issue #62 | Revue (getrevue.co) Happy Friday all! Welcome to the 62nd issue of our fine Microsoft Sentinel newsletter. There’s lots of great content this week (as usual some would say) and only a couple additional things to highlight. … First off, of all places, I’m driving to Ft. Wayne, Indiana on Saturday. I’ll be driving 3 hours to make my session time for BSides Security Ft. Wayne. This is an annual security conference held at Sweetwater Sound. If you’re not familiar, Sweetwater is one of the largest music equipment distributors in the US. I’ve never been there before, but my youngest son (the drummer in the band, Urbania) loves the place and visits a couple times a year. So, I’m really looking forward to talking about SOC Efficiency with this group. Wish me luck! And if you happen to be attending this thing, let me know. Due to the 3-hour drive each way, I probably won’t be hanging around for too long after I deliver my session. And even if you can’t join in-person, you can join virtually: Live Chat: https://lnkd.in/gmUUxwMg Live Stream: https://lnkd.in/g9M5rbfi … We have a YAMS (Yet Another Microsoft Survey) this week. Help us help you! Feedback for Microsoft Sentinel Tutorials The Microsoft Sentinel engineering team is looking to improve and increase the list of Microsoft Sentinel tutorials that you can find at https://docs.microsoft.com/azure/sentinel/, under the section Tutorials (see picture in the first question). The tutorials are created to help customers who are either at the initial steps of their Microsoft Sentinel deployments, or expanding them, and who are looking for guidance on securing their most important scenarios. Respond here: https://cda.ms/4jM … Before leaving you to the newsletter content, I have one more big note. The Must Learn KQL learning series is an unequivocal success but more needs to be done. I outline in a recent post the number of completion certificates I’ve handed out already and while that number is wonderful, more people need to get the message how important learning KQL really is. So, the Must Learn KQL book is now available on Amazon! Kindle version: https://amzn.to/3MyMOOS Paperback: https://amzn.to/3sN8ajE Hardcover: https://amzn.to/3yOAFRS This gives it a much wider audience and like everything that’s part of this learning series, any and all profit goes directly to St. Jude Children’s Research Hospital. I owned and sold an eBook publishing company (NetImpress) way back in 2004-2005 before even Amazon had concocted its own eBook production methods. It was revolutionary at the time and most of what our company did had to be invented. And, while many of the same things I learned through NetImpress are still valid and useful today, there are many aspects that have changed or just didn’t exist. Developing and delivering Must Learn KQL series has been a pioneering experience on all the nuances of producing a learning series in this manner and I suspect others will take notice and begin duplicating my efforts. There are some other things to tweak, but I do know that I’ll be doing it again with another series in the very near future. Stay tuned. … That’s it for now. Have a wonderful weekend and week ahead. Talk soon. -Rod Original Post: New Blog Post | Microsoft Sentinel this Week - Issue #62 - Microsoft Tech Community
