If you’ve been in the Defender XDR portal, you might have noticed some new badges and banners hinting that Microsoft Defender now comes with native case management:
The feature was also part of the ISOC announcement and is now rolling out in public preview to Defender customers. Microsoft also published a message center post:
Microsoft Defender is introducing native Case Management to help security teams investigate and resolve threats faster while reducing tool sprawl. MC1477993
Sometimes SOC teams handle incidents in Defender but track the actual work, such as ownership, tasks, SLAs and handover notes, in separate tools. These can be ticketing systems or sometimes even Jira, while other teams use dedicated SOAR solutions. Many of those also have a sunset date, like Palo Alto XSOAR in 2029 1. So Microsoft keeps up the pace and adds incident management capabilities under the name of cases. Cases aim to bring work back from external tools directly into the Defender portal.
Case types # Case management currently supports two case types:
Incident cases (preview): Created by the service from correlated incident activity. During this phase, each incident case maps one-to-one to an incident.2 Generic cases: Created manually to track SecOps work outside the incident workflow, for example, a threat hunt, a hardening follow-up or an audit request. Microsoft recommends incident cases as the new experience for managing incidents. The legacy incident experience remains available during the preview.3
AI decision models are the new kids on the block, with TypeSafe AI’s Jev,1 Cloudflare’s Clef,2 and Microsoft-Decision-1.3 Frontier models are powerful for complex analysis and generating text, but automation often needs smaller answers: which category, which queue, or whether to escalate. Decision models focus on these bounded tasks, returning structured choices and probabilities without generating free-form text. This can reduce latency and cost while giving AI-based workflows outputs they can act on directly. Probability thresholds can then determine whether to proceed, request another evaluation, or hand the decision to a human in the loop.
In short:
An AI decision model reads an input and returns an answer from a set you define (an option, a score, or the probability that something is true), with a calibrated probability for every allowed answer, in one pass and without generating text. - System One Models4
So I was curious to test the Microsoft-Decision-1 model and better understand how it works in an experiment related to SecOps and incident automation.
My Experiment # When alert volumes are high, SOC teams tend to prioritize medium- and high-severity alerts and use automation to triage or close lower-severity alerts. I tested whether Microsoft-Decision-1 could identify alerts worth escalating or recommend a lower severity based on the alert and included alert evidence. These outcomes could support incident reviews by highlighting alerts that are worth another look or support detection engineering to adjust a detection’s severity level.
All too often, my baseVISION (IR) colleagues and I find compromised cloud accounts where many security ‘signals’ were missed—both from a prevention and detection perspective. In this blog post, I want to share some motivation and tips to help you adopt Entra ID Protection risk-based Conditional Access policies to increase your tenant’s security posture, and ensure you don’t miss the next obvious account breach.
Real-world motivation # Anyone who has seen an AiTM campaign in the wild will probably notice the following details from the Entra ID sign-in logs of a compromised account:
ResourceDisplayName: OfficeHome UserAgent: axios/1.13.2 The problem? Even though Entra ID Protection flagged the sign-in as ‘High’ risk, the user could still sign in because MFA automatically remediated the sign-in risk (userPassedMfaDrivenByRiskBasedPolicy).
The bummer? # The environment had a Conditional Access policy in place that would have blocked users with high sign-in risk, but the policy was only in report-only mode, so the user could sign in without any issues.
Recently I observed an interesting behavior after setting up a Microsoft Booking page. After creating the booking page, I suddenly got an e-mail to an automatically created mail alias with the same name as the booking page. This made me curious and I wanted to understand the behavior behind this, and if this could be abused by attackers to impersonate users in Exchange online. In this blog post, I want to share my findings and some tips on how to detect and prevent this kind of abuse in your environment.
Microsoft Booking # Microsoft describes the Bookings capabilities as part of Microsoft 365:
“A simpler way to organize schedules and manage appointments.”
Booking pages can be either of type ‘personal’ or ‘shared’:
Personal booking pages provide a handy option for users to create their own booking page, which is automatically linked to their calendar and allows others to book appointments with them. This is a great feature for users who want to share their availability and allow others to easily schedule meetings.
The shared booking pages allow teams to provide a booking experience for services hosted by a team and come with a special mailbox and calendar.
With the Unified Security Operations Platform (USOP), Microsoft introduces Unified Detections - a single detection framework spanning both Sentinel and Defender XDR data. Pair this with native Sentinel Data Lake ingestion for XDR tables, and you have a compelling cost-optimization story. But is it ready for prime time? Let’s dive into the capabilities, current limitations, and what it means for your detection strategy.
Architecture Overview # Previous Detection Architecture # In the ‘previous’ architecture, detections were created and managed separately for Microsoft Sentinel and Microsoft Defender XDR. This often led to overhead in terms of ‘where to create the detection’. Let’s take the use-case of IoC (Indicators of Compromise) based detections. Previously, if a security team wanted to create a detection based on IoCs imported via TAXII into Sentinel and the DeviceNetworkEvents table, they would need to ingest the DeviceNetworkEvents data into Sentinel as well and create the detection rule there. Furthermore, many MSSPs leveraged this pattern to create custom detections for their customers across Defender Advanced Hunting Data.
As part of the USOP onboarding, the following effects come into play, marked with an asterisk above: