In Part 1 of this series, we walked through three specific problems SecureSky sees in almost every Sentinel environment we onboard: too much data, too many untuned rules, and a misunderstanding of what a SIEM is actually for.
This post zooms out.
Because those three problems are symptoms. The root cause is something different, and it explains why so many Sentinel environments aren’t just misconfigured, they’re fundamentally underperforming. Deployed, technically running, actively billing your Azure subscription, and delivering a fraction of the value they’re capable of.
In our experience, most Sentinel deployments are working at somewhere around half capacity. Here’s what that looks like, why it happens, and what it takes to fix it.
Data connectors are enabled with default settings — nobody has gone back to assess whether the ingestion configuration matches what the organization actually needs to see. Analytics rules are at default values, or the Microsoft library has been switched on wholesale without evaluation. UEBA (User and Entity Behavior Analytics) is either disabled entirely or enabled but not enriched with the organizational context that makes it meaningful. Automation rules are absent, meaning every repetitive analyst action is being done manually. Retention policies haven’t been touched from their defaults.
There’s another dimension to this that often gets overlooked: the age of the deployment itself. Sentinel has evolved significantly since its initial release, and Microsoft hasn’t slowed down. New capabilities, new connector types, and changes to how log data is structured have been rolling out continuously. M365 log ingestion alone has changed several times - the way Defender XDR data surfaces in Sentinel today is meaningfully different from how it worked two or three years ago. An organization running a Sentinel instance that was stood up in 2022 and hasn’t been actively maintained since has serious gaps in their Defender XDR log data coverage — not because anything broke, but because the platform moved forward and the deployment didn’t. Features that didn’t exist when the instance was configured are sitting unused. Connector changes that require re-evaluation were never re-evaluated. The customer is paying for capabilities they aren’t using because nobody went back to turn them on.
There’s nothing catastrophically wrong. It works. It generates incidents. It stores logs. But it doesn’t do the work it was designed to do.
The closest analogy we use internally: it looks like a renovation done by someone who ran out of time. The paint is on the walls, the deck is technically standing, but a professional eye can see immediately that the underlying work wasn’t done right. The problems aren’t always visible to the occupant. They show up later, and they compound.
Not rules. Not automation. Not UEBA. Data.
The reason is straightforward: every other layer of Sentinel depends on the quality of what’s coming in. If the ingestion is noisy, unscoped, or capturing the wrong events, tuning rules against it is an exercise in building on an unstable foundation. You’re calibrating detection logic against data that doesn’t accurately represent your environment.
Clean the data first. Scope each connector to what the organization actually needs, align ingestion to audit policies, eliminate redundant sources, and everything downstream gets easier. Rule tuning becomes more precise. UEBA behavioral baselines become more accurate. Automation rules can be written with confidence that the incidents triggering them are real.
This is unglamorous work. It doesn’t produce a visible dashboard metric or a moment someone can point to and call a win. But it’s the difference between a Sentinel environment that’s technically running and one that’s actually protecting you.
Intentional ingestion. Every data source was evaluated before being enabled. The events coming in reflect a deliberate decision about what the organization needs to detect and retrace - not a default setting that nobody changed.
Tuned analytics. The rules that are active have been evaluated against the environment. They fire on things that are genuinely anomalous. They don’t fire on things that are normal operations for the organization. When an incident appears in the queue, an analyst can trust it warrants attention.
UEBA enrichment. User and entity behavior baselines are active and populated with organizational context. When Sentinel flags behavioral anomalies, they’re calibrated against what normal actually looks like for that user, in that role, in that environment.
Automation rules doing the repetitive work. Triage steps that don’t require human judgment, for example entity enrichment, notification routing, or closing known-benign patterns, are automated. Analyst time is spent on decisions, not on process steps.
Retention policies set intentionally. How long data is retained in hot storage versus cold storage is a decision, not a default. It reflects the organization’s investigation needs, compliance requirements, and cost tolerance.
Log ingestion monitoring. This is a significant gap in most Sentinel deployments and one that rarely gets discussed. A fully operational environment doesn’t just ingest the right data - it knows when that data stops arriving. If a firewall stops sending logs, or a server agent goes silent, or a cloud connector drops, the security team needs to know immediately. Sentinel provides log feed workbooks, but workbooks alone aren’t a strategy. A full-capacity deployment has a defined approach for detecting ingestion gaps - understanding where you’re blind to log data because a source stopped reporting, not just where you’re covered. Without this, you can have a perfectly tuned environment that silently loses visibility to a critical data source and no one notices until an incident investigation reveals the gap.
None of this is exotic capability. All of it is available in the platform your organization is already paying for. The gap is almost never the license. It’s the engineering investment required to turn a deployment into a program.
That said, the pattern we’re describing isn’t rare. The conditions that produce a half-capacity deployment - meaing a platform that requires sustained engineering attention deployed as a side project, then left to run without dedicated ownership - are extremely common in mid-market organizations. The platform complexity is real. The staffing required to manage it well is real. And the gap between “deployed” and “working correctly” is almost always larger than organizations expect when they start.
That gap is the problem SecureSky exists to close.
This is Part 2 of a two-part series. Read Part 1: 3 Things We See in Almost Every Sentinel Environment That Shouldn’t Be There.
SecureSky is a Microsoft-recognized MXDR provider specializing in managed detection and response and Microsoft Sentinel. Contact us to talk through your current deployment.