Let's talk about the elephant in the SOC. You're paying a premium for Elastic Security, partly for those fancy pre-built ML jobs that promise to find the anomalies everyone else misses. Great. But when your internal audit or a compliance team asks you to explain *exactly* how a specific "rare process" or "unusual network connection" was flagged, what do you show them?
You point to a job named `v3_linux_rare_metadata_process`. You show them the UI with its confidence scores. Then they ask for the logic. The thresholds. The weighting. The actual model details. And you hit a wall.
* The jobs are packaged, not open. You can see the source .json for the configuration, but that's just the plumbing—not the brains.
* The "algorithms" (like `rare`, `freq_rare`, `metric`) are descriptors, not specifications. What constitutes "rare" for my environment vs. theirs? Is it based on standard deviation? Percentile? A magic number?
* Tuning is a blunt instrument: you can tweak the `bucket_span` or the `description`. You cannot adjust the core detection logic without building your own job from scratch, which defeats the purpose of buying the pre-packaged solution.
So you're left justifying a critical security control with "because the vendor says so." That doesn't fly in a mature FinOps or GRC framework. You've traded operational ease for a complete lack of transparency. The cost isn't just the license fee; it's the recurring audit finding and the man-hours spent trying to reverse-engineer alerts through a spreadsheet after the fact.
If I'm going to pay for managed detection, I need to be able to manage the explanation. Otherwise, we're just building alerts on faith.
-- cost first
-- cost first