Two MDO field reports every IT security lead should read
The post Two MDO field reports every IT security lead should read appeared first on Blog.
Tyler Swinehart, Director of Global IT & Security at IRONSCALES, has been publishing the kind of LinkedIn pieces I wish more practitioners would write.
Two MDO field reports every IT security lead should read
The post Two MDO field reports every IT security lead should read appeared first on Blog.
Tyler Swinehart, Director of Global IT & Security at IRONSCALES, has been publishing the kind of LinkedIn pieces I wish more practitioners would write. No vendor angle. No positioning. Just “here’s what I learned the hard way operating this thing in production, and here’s what nobody told me until it was too late.”
His last two posts are about Microsoft Defender for Office, specifically Explorer and Quarantine. If you operate MDO, you should read both. They’re under 10 minutes each, and they’ll save you hours the next time you’re deep in a phishing investigation wondering why your search results don’t add up.
I’ll resist the urge to recap them (Tyler explains his own work better than I will). But read both back to back and a pattern emerges. Native email security tooling has a transparency problem, and it shows up in the operational moments that vendor roadmaps never plan for.
The Explorer post: search that “works” but doesn’t tell you what it’s doing
Tyler’s first piece walks through MDO Explorer’s filtering limits. No regex. No OR statements. No “starts with” operator. Weird Unicode behavior that quietly drops matches. And a 30-day log retention cap that nobody mentions until someone asks you for 45-day-old logs and you have nothing to show. His workaround is KQL through Advanced Hunting Queries, which is the right answer if you’re willing to learn another query language.
Read the full post here: Microsoft Defender for Office Explorer (the stuff nobody tells you until it’s too late)
The strategic read is this. Explorer’s UI gives you a confidence interval Microsoft never actually promised. You search for a sender, get results, and assume you’ve seen everything that matches. You haven’t. Special characters might have dropped matches. The “contains” operator is doing fuzzy work you can’t see. The 30-day window is invisible until it bites you. The product is doing its job. It just isn’t telling you what its job actually is.
This pattern shows up across the native security category. Tools get built for the median use case and quietly fail the edge cases that matter most during an active investigation.
The Quarantine post: a product that disagrees with you and won’t say why
Tyler’s second piece opens with a department head asking why a contract email never arrived. Quarantined as “High Confidence Phish.” No notification. No scoring breakdown. No indicator list. Just gone.
Read the full post here: MDO Quarantine (the stuff nobody tells you until you’re debugging a policy that quietly does nothing)
Then it gets worse. Microsoft hides the quarantine console entirely if you don’t have the right RBAC role (no grayed-out menu, no helpful “you need access” hint, just nothing). The submission workflow has two paths, neither well documented, neither carrying an SLA. Quarantined emails vanish after 30 days with no extension, no delegation, no archive. And the headline finding, which security admins should print and tape to their wall: preset security policies silently override your custom configurations with no warning, no conflict indicator, no UI signal that anything is being ignored.
You can spend an afternoon debugging quarantine behavior that isn’t doing what your custom policy says it’s doing, only to discover Microsoft picked a different policy and didn’t bother to mention it.
The thread between both posts
Both pieces describe products that work exactly as designed and fail their operators anyway. The detection logic is competent. The interface is usable. The features ship. What’s missing is the operational transparency that lets a security team trust the tool, debug it when it misbehaves, and explain its decisions to the business.
Most vendor evaluations underweight this dimension (mine included, in different ways). We benchmark catch rates, detection coverage, AI sophistication. We rarely benchmark whether a Tier 1 analyst can figure out why something happened, whether a custom policy is actually running, whether a search returned everything it should have, or whether last quarter’s logs are still available when legal asks for them.
Closing that gap means treating transparency as a feature in its own right, with its own roadmap, its own success metrics, and its own UX investment.
What to do with this
Two takeaways, depending on where you sit.
If you operate MDO: read both posts. Audit your preset policy stack against your custom configs (Tyler’s finding there alone could save you a week of confused troubleshooting). Get your KQL skills sharp enough to run real Advanced Hunting Queries when Explorer hits its limits. Forward your MDO logs somewhere with retention longer than 30 days before someone asks you for historical data.
If you evaluate email security tools: add operational transparency to your eval criteria. Ask vendors how analysts surface why a verdict was reached, how they validate that custom policies are actually applied, and how they expose log retention. The answers will tell you more than another detection benchmark will.
Tyler’s LinkedIn is here if you want to follow along. He’s writing more of these. They’re worth your time.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Audian Paxson. Read the original post at: https://ironscales.com/blog/two-mdo-field-reports-every-it-security-lead-should-read
About Author
