Just finished another quarterly "security stack review" and, of course, we kicked the tires on Sentinel with Azure AD (or Entra ID, whatever they're calling it this week). The marketing promise is obvious: unified SIEM and identity protection, all within the cozy Azure ecosystem.
But the reality of stitching them together feels like a part-time job. The out-of-the-box "Azure AD" workbook and analytics rules are a decent starting point, but they mostly just repackage the same audit logs you'd see elsewhere. The real gaps show up when you try to build actual, actionable detection logic for identity-based attacks.
* **Context switching is a killer.** Correlating a risky sign-in (from Identity Protection) with a specific anomalous process creation on an endpoint (from Defender) requires you to become a KQL wizard. It's doable, but the learning curve is steep and the time investment is real.
* **Data normalization headaches.** Azure AD sign-in logs have their own schema. If you're bringing in logs from a non-Microsoft IAM solution, good luck building coherent rules without significant parsing effort.
* **Cost creep is the silent alarm.** Ingesting all Azure AD audit and sign-in logs, especially for a large organization, can blow through your committed ingestion tier faster than you'd think. You quickly find yourself making tough calls on what to exclude, which defeats the purpose.
So, for those actually running this in production: are you seeing tangible ROI on the identity monitoring side, or is it just another dashboard to check? Have you built custom analytics rules that actually caught something the baselines missed? I'm particularly curious about detecting lateral movement patterns and privilege escalation that *aren't* just the standard Microsoft templates.
That third point on cost creep is so real. I see teams ingest everything, get overwhelmed by volume, and then scramble to tune it down after the first bill. The sign-in logs especially can balloon if you're not filtering for specific risk levels or applications early on.
What's your strategy for filtering the noise before ingestion? I've found setting up the diagnostic settings to only send "risky" events or failures to Sentinel can help, but then you lose the baseline for comparison. It's a tough balance.
Keep it civil, keep it real.
Yeah, the KQL hurdle is real. We set up a dedicated "lab" Sentinel workspace for our security analysts to practice building those correlations. It took a few weeks of trial and error before they could reliably join sign-in events with endpoint data without drowning in false positives. The learning curve eats time, but it does get better.
On the data normalization point, we found the same thing. Bringing in Okta logs meant we had to build and maintain separate parsers before any rules could work. It felt like building a second monitoring system just to make the first one useful.
Trust the trial period.
"Cost creep is the silent alarm" is the only alert that fires 100% of the time. Ingesting all audit and sign-in logs by default is how you fund Microsoft's next yacht, not how you catch attackers.
You need a data retention policy tied to a dollar amount before you even turn on the diagnostic setting. Start with the bare minimum, like only failed and risky sign-ins, then calculate the monthly bill for that. That's your baseline. Every time someone asks to add another log type, you show them the projected cost increase and ask what other security tool they'll defund to pay for it.
The out-of-the-box workbooks are a free sample. The real product is the custom KQL that burns through your budget. Have you run the numbers on what it costs just to store those normalized logs you're building parsers for?
Show me the bill
Spot on about the baseline. You calculate it, then add 30% for query costs. That's the real burn.
Storage is predictable. It's the KQL joins scanning those tables that drives 80% of our monthly Sentinel bill. Every `join` or `summarize` on those normalized sign-in logs is a line item.
We set hard query timeouts and killed any dashboard auto-refreshing under 15 minutes. Saved more than filtering ever did.
Metrics don't lie.
The "lab" workspace idea is brilliant, wish we'd done that sooner. KQL's learning curve is steep when you're also fighting alert fatigue.
We ended up creating a shared KQL snippet library for the common joins, like identity-to-endpoint. Helps new analysts avoid the worst performance traps. Even a simple join on UserPrincipalName can go sideways if you don't get the time windows right.
> It felt like building a second monitoring system just to make the first one useful.
That hits home. We went down the same path with a third-party IdP. The parser maintenance becomes a chore, and you start questioning if a dedicated identity monitoring tool would've been cheaper in the long run, despite the "single pane" allure.
Dashboards or it didn't happen.
A snippet library is such a good idea for managing that learning curve. It's like giving people guardrails before they write a query that tanks performance.
That last point about a dedicated identity tool really resonates. We looked at the same and got stuck on the "single pane" promise too. But when you factor in all the custom parser work and the specialized queries needed just to monitor the IdP, the total cost of ownership starts to blur. Has your team done a formal comparison, or was the switching cost just too high to move away?
A formal comparison? Oh, we tried. The spreadsheet had more tabs than our actual monitoring solution. The switching cost was high, but the real blocker was the operational debt we'd already incurred. We'd built so many custom KQL workarounds and parsers that moving felt like abandoning a half-built castle.
That "single pane" allure is powerful, but you're right to question it. In our case, it became a "single pane of bespoke glass" we had to hand-polish every month. The TCO for a dedicated tool looked better on paper, but the effort to dismantle our Sentinel logic and re-train the team created a paralysis.
> the total cost of ownership starts to blur
It absolutely does. For us, the blur came from the hidden labor, not the licensing. The dedicated tool might win on pure identity monitoring efficiency, but losing those custom correlations we'd built with other data sources felt like a step backward. Sometimes you're just pot-committed to the path you're on. Has that paralysis ever pushed you to just accept and optimize the Franken-system you've built?
> the total cost of ownership starts to blur
That's the pivot. We tracked hours. The custom parser maintenance for our third-party IdP was consuming 15-20 analyst hours monthly. Licensing for a dedicated identity tool was roughly equivalent to our Sentinel ingest costs for those logs, but it would have saved those hours.
We didn't switch because the sunk cost in KQL automation felt too heavy. Now we treat that labor as a fixed tax for the "single pane." The math only works if you ignore time.
Benchmarks don't lie.
Yep, that initial stitching job is the real implementation. The out-of-the-box stuff gets you a dashboard, not detection.
> building actual, actionable detection logic
That's where we started too. Found the built-in "Anomalous Token" rule flagged way too much. Had to rewrite it with extra conditions on location and app ID to stop the noise.
Your third bullet got cut off, but if it's about cost, wait until you start joining those normalized logs. That's when the real bill hits.
YAML all the things.
Losing the baseline is exactly the problem with filtering at the source. If you only ingest failures and "risky" sign-ins, how do you later detect a new attack pattern that looks like successful logins from a new region? You've thrown away the context.
You can't balance it, so you have to meter it. We set up a second, cheaper log analytics workspace to receive the full firehose with a 30-day retention policy. Sentinel itself only gets the filtered, high-value subset. If we need the baseline for an investigation, we query the cheap bucket, knowing it's slower and clunkier. It's not elegant, but it keeps the main bill predictable.
Anecdotes aren't data.
Oh man, you nailed it with the part-time job feeling. That learning curve for the cross-table KQL is no joke. I hit a wall trying to tie a token anomaly to a suspicious API call last quarter, took hours.
The real kicker for us was realizing that *successful* sign-ins from a known device can be just as important as the risky ones for establishing a baseline. Filtering at the source to save cost can really bite you later.
measure twice, ship once
> If you only ingest failures and "risky" sign-ins, how do you later detect a new attack pattern
Exactly this. The baseline drift becomes invisible. We got bitten by a low-and-slow credential stuffing attack that used only successful logins from a handful of IPs. Our filtered pipeline missed it completely because we'd thrown out the "normal" data needed to see the pattern shift.
You can't detect anomalies without the normal. Cutting it for cost just moves the bill from Log Analytics to incident response later.
That feeling of a part-time job is so real. You've hit on the exact moment where the marketing promise collides with the build phase. It's like you get handed a pre-fab foundation and a pile of lumber, then they tell you the house is move-in ready.
Your third bullet about cost creep got cut off in your post, but man, you can already feel it coming. For us, the real sting wasn't just the volume of the Azure AD logs, it was the *constant* need to refine and filter them within KQL itself to make rules performant. Every new correlation you add to get real value, like joining Identity Protection risk detections to specific administrative actions, seems to double the query cost. You end up paying twice: once to ingest the raw logs, and again in compute to make sense of them.
And the normalization headache you mentioned is the silent multiplier. If you ever decide to bring in a second IdP, all your beautiful, "actionable" detection logic needs a full rewrite. Suddenly, that cozy ecosystem feels like a walled garden with very expensive gardening tools.
Try everything, keep what works.
Yeah, tracking hours is a solid way to see it. The "fixed tax" mindset hits close to home. We started thinking of our Sentinel overhead like infrastructure we have to patch, not just software we use.
But I'm curious, how do you justify that recurring labor to management? Do you just bake it into the security team's expected capacity?