Solving Tool Sprawl: The CISOs Guide to Efficient and Effective Security Operations

The trap inside the word "consolidation"

Every security leader drowning in tools eventually reaches for the same word: consolidation. And almost everyone hears it wrong. Matt, LimaCharlie's lead solutions engineer, opened this first session of a four-part CISO series by killing the fantasy before it could form. There is no single tool that swallows everything, brings your analysts down to one login, and makes the sprawl disappear. He would love it if that product existed. It does not, and pretending otherwise is how teams end up with one more dashboard than they had before.

The honest version of the problem is harder. Matt cited an April 2024 survey finding that firms run between 60 and 75 security tools on average, then reframed that number in a way that should make anyone who has worked an incident uncomfortable: those are 60 to 75 telemetry sources. He was careful to say he did not mean a little SIEM data duplication or a data lake everyone forgot to decommission. He meant 60 to 75 real tools in the stack, each holding information an analyst genuinely might need and almost certainly does not have time to open. A separate CISO survey from early 2024 made the consequence concrete. Among teams using three or more tools to detect and prioritize vulnerabilities, the single biggest obstacle was prioritization itself. Too many sources, no clarity on where the best data lived, and no practical way to correlate alerts across them.

Measure the stretch before you "fix" it

What makes the talk more than a complaint is that Matt handed leaders two ratios to measure the problem rather than feel it. The first is the analyst-to-tool ratio. A SOC of ten analysts facing seventy tools runs at seven to one, and he was insistent that this number is not abstract. Seven tools per analyst means seven dashboards, seven logins, seven permission sets, seven MFA prompts, and a context switch every time someone has to chase a signal from one place to another. The second is the analyst-to-telemetry ratio, which is where alert fatigue and analysis paralysis actually live. You can be comfortable with seven tools per analyst and still be buried by the volume those tools generate.

The reason these ratios matter is the gap they expose. Matt kept returning to one window: the time it takes an analyst to correlate an alert in one platform against a related signal sitting in another. That window, he argued, is exactly where adversaries find success. The more places telemetry is scattered, the wider that window grows, and no amount of tooling closes it if every source demands a separate trip.

For MSSPs and MDRs, this is not a thought experiment. These ratios compound across every tenant. A provider does not inherit one organization's sprawl, it inherits all of them at once, which means the analyst-to-telemetry math is also a direct read on margin and on whether the team can respond before the window closes.

Treat every source as first-class, and rip out nothing

The architectural point underneath all of this is a quiet rejection of how most SOCs are built. The standard pattern puts EDR or XDR at the center as the primary detection driver, and everything else gets dumped into a SIEM or a lake "just in case we need it." Matt's objection is that those secondary sources are frequently the high-fidelity ones. He spent much of his career on email compromise cases, and the through line of his argument is that many intrusions and breaches never touch an endpoint agent at all. The signal lived in email access logs, in mailbox rule changes, in identity systems, in cloud telemetry. Treating those as second-tier storage means treating the most likely place an adversary lives as an afterthought.

His fix is not to replace EDR or invalidate what a team already does. It is to elevate identity tools, source code management, network data, and cloud telemetry to the same first-class status as endpoint data, so a detection can be written against any of them inside one platform. That is what consolidation actually means in his framing: not one dashboard, but the right points of consolidation, pulling the analyst-to-dashboard ratio down from ten or fifteen toward three or four, as close to one to one as the organization's staple playbook tools allow.

The identity example showed why a consolidation point has to do more than collect. Enterprises accumulate clouds, identity providers, IAM, Active Directory, and MFA through mergers and convenience, and cloud-native logging only goes so far before it asks you to upgrade a license tier. Matt described LimaCharlie sitting in the middle of that mess with a full year of retention included, every source normalized as first-class telemetry, and a bidirectional capability that does not just read but writes back. When an account does something the team does not sanction, the platform can issue a command to the cloud provider, the SaaS app, the identity provider, or Active Directory to lock the resource down. The pairing is the point. Retention gives you historical threat hunting and post-incident triage, normalization gives you detection across everything, and the return path gives you response, all from one place instead of a spreadsheet stitched together from five logins.

The argument the session is really making is that sprawl is a posture problem disguised as a procurement problem. You cannot buy your way to fewer tools, and you should not try to rip out the staples your compliance and playbooks depend on. What you can do is stop letting the long tail rot in a lake, treat every source as something worth detecting on, and measure the stretch with numbers honest enough to act on. For a provider carrying that complexity across many customers, that shift is the difference between drowning in telemetry and operating on it.