Full Tank, Wrong Fuel

There is a preflight check in the Robinson R-44 that every student pilot learns to hate because it seems redundant. You already know the tanks are full. You watched them get topped off. But you still pull a fuel tester from your flight bag, drain a sample from each sump, and hold it up to the light. You are not checking quantity. You are checking contamination. Avgas is blue. Jet-A is clear. If that sample looks wrong, it does not matter how full the tanks are. Full is not the same as ready.

I think about that check constantly when I walk into a conversation about SIEM deployments.

The expensive failure pattern in enterprise security is not "we had no budget." The organizations that scare me most are the ones with generous budgets, modern platforms, healthy-looking dashboards, and quietly trimmed data sources. The instrument panel shows green. The tank is full. The fuel is wrong.

Here is what actually happens. A security team procures a SIEM, goes through a lengthy implementation, and then hits a cost wall. Log volume pricing on most platforms is not subtle. Every new data source is a negotiation. Every high-volume feed is a budget conversation with someone who does not attend your incident review meetings. So the team starts making triage decisions. The noisy endpoint telemetry gets filtered. The authentication logs from the legacy system get sampled, not fully ingested. The network flow data gets trimmed to stay under the license cap. Each individual decision looks reasonable in isolation. Collectively, they hollow out the thing you just spent seven or eight figures to build.

The breach still happens. The detection still fails. And the post-incident review reveals that the relevant signal was never in the SIEM because someone upstream decided that log volume was a cost problem, not an investigation problem.

This is the full tank, wrong fuel failure. And it is far more common than the zero-budget story.

I have been in government cybersecurity long enough to watch this pattern repeat. The procurement cycle favors platforms. A modernization effort gets funded, the contract gets signed, and the implementation gets celebrated. But the ongoing cost of feeding that platform at full fidelity is a different line item, often funded at a different time, by a different process, through different people. The tool exists. The data budget does not keep pace. Nobody announces the gap. The dashboard still shows ingestion rates. The ingestion rates just no longer reflect your actual environment.

What makes this dangerous is the confidence it generates. An organization that knows it has no SIEM is at least honest about its visibility problem. An organization that has a SIEM with degraded inputs has the worst of both worlds: real cost, false assurance. The analysts trust the platform. The leadership trusts the dashboard. The adversary trusts neither and works in the gaps.

The aviation parallel holds because it describes the same cognitive trap. A pilot who runs a dry tank is immediately aware of the problem. A pilot who takes off on contaminated fuel may not know anything is wrong until the engine quits at altitude. Ignorance is uncomfortable. False confidence is fatal.

The detection engineering piece makes this worse. Most of the SIEM failure stories I have encountered share a second pathology: the platform got bought, but the detection logic never got built. Compliance-driven use cases went in first because compliance has deadlines and auditors. Custom detections for the actual threat environment went in the backlog because those require skilled people, sustained investment, and operational maturity that no contract covers. So the organization ends up with a very expensive log repository that generates compliance reports and almost nothing else. The alerts that fire are the vendor defaults. The vendor defaults are not tuned to your environment. The signal-to-noise ratio degrades. The analysts learn to ignore the queue.

Now you have three compounding problems: trimmed data sources, absent custom detections, and analyst fatigue trained into the workflow. And the dashboard still looks fine.

The fix is not more budget, at least not primarily. The fix is honest accounting about what the SIEM is actually ingesting versus what your environment actually generates. That number is almost never surfaced clearly. Most organizations can tell you their daily ingest volume. Very few can tell you what percentage of their total log-generating asset inventory is represented in that volume. Those are different questions. The first one describes what you have. The second one describes what you are missing.

I push for coverage maps. Not dashboards, not ingest metrics: a literal accounting of which systems are sending logs, at what fidelity, with what retention. Then compare that map to your asset inventory and your threat model. The gaps are your actual risk posture, not whatever the executive summary says.

The other piece is separating the data cost conversation from the security outcome conversation. When a platform vendor or an internal finance team trims your log volume, they are making a security decision. They are just not being told that is what they are doing. The CISO's job is to make that explicit. Not adversarially, just clearly. "This filter removes authentication telemetry from this system class. If we experience a credential-based intrusion targeting those systems, we will not have the data to reconstruct the timeline." That sentence belongs in the budget memo, not the post-incident report.

Full tanks and green instruments feel like safety. Sometimes they are. But in a cockpit or a security operations center, the discipline is checking what is actually flowing through the system, not just confirming that the gauges are lit.

Drain the sump. Hold it up to the light. Know what you are actually flying on.