Hey folks! 👋 As someone who spends way too much time optimizing our security stack, I've been wondering about our Microsoft Defender for Endpoint setup. We've been on the E5 plan for a while, and I have this nagging feeling we might be paying for a bunch of features that are just... sitting there, unused.
I know the portal is feature-rich, but it’s easy to get stuck just using the core alerting and not tap into the advanced capabilities. For example:
- Are we actually using **advanced hunting** queries proactively, or just reacting to incidents?
- Is **device control** (like USB blocking) configured properly, or is it on default?
- What about **attack surface reduction rules**—are they all in audit mode, or actually blocking?
- Are we leveraging **automated investigation and remediation** effectively?
I’d love to hear how others audit their own usage. Do you have a checklist or a script that pulls configuration and activity data? I’m thinking we could compare notes on practical ways to measure "feature utilization."
For instance, here’s a quick PowerShell snippet I use to check the status of some ASR rules (you’d need the right modules/permissions):
```powershell
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
```
But that's just one tiny piece. How do you get a comprehensive view? Do you rely on the built-in reports, use the API, or something else? Any pitfalls you've run into when trying to validate if a feature is truly "on" and operational?
Clean code is not an option, it's a sanity measure.
That nagging feeling is probably your budget trying to escape. It's practically a feature of any vendor's top-tier plan, especially in the Microsoft ecosystem.
A checklist is a good start, but you'll likely find the answer is "no" for most advanced features. The real trick is determining if you even need them. We ran a similar audit and found automated investigation was creating more noise than value for our specific workflow. We turned it off and saved the sanity, if not the license cost.
You can pull all the config data you want, but the sales pitch is always that you need the *capability*, not that you'll use it. I'd be more interested in a script that maps features to actual, logged security events from the last quarter. If a feature has zero events tied to it, that's a conversation starter.
Beware of free tiers
Exactly. The sales pitch is always about coverage, not utilization.
> a script that maps features to actual, logged security events
That's the only proof that matters. But good luck getting clean logs out of those portals. Half the "features" log under generic service names. You'll spend more time correlating event IDs to SKU features than you ever did using the features.
We found one "core" feature that had logged three events in a year, all from a single engineer's test machine. The rest of the org? Zero. That's the conversation.
-- old school
Yeah, the mapping is brutal. I've been down that exact road.
You end up writing a log parser that's mostly heuristics and guesses. The vendor's documentation on which log event equals which paid feature is either non-existent or wrong. Your "proof" becomes a pile of assumptions, which gives the vendor an easy out.
We just stopped trying to prove it to ourselves and moved the conversation. Instead of "are we using feature X," we ask "what's the risk of *not* having feature X?" Let them prove we need it. The burden shifts. Usually they can't.
Don't panic, have a rollback plan.
That snippet won't tell you anything useful. You're checking if a rule *exists*, not if it's ever fired a block action. You need logs, not config.
Even if you get the logs, good luck. MDE doesn't exactly label events with "billed_feature: advanced_hunting". You'll be grepping through json for weeks to build a case.
The real answer is you're not using half of it. Nobody is. They sell you the toolbox and hope you never open most of the drawers.
If it ain't broke, don't 'upgrade' it.