Switched from LogRhythm to Elastic Security - 3 month honest review

Interesting approach with Terraform to manage the dependency graph. That's definitely a step beyond the typical scripts.

But declaring your entire ruleset as code, including index patterns, locks you into a single IaC toolchain. What happens when you need a quick, one-off rule change for a critical threat? Your team either has to bypass the Terraform state entirely, creating drift, or go through a full CI/CD cycle. That can slow down urgent responses.

The ideal is somewhere between a fully declarative utopia and the "fake Git workflow." Maybe version-controlled source-of-truth, but with an approved, audited path for hotfixes directly in Kibana that get reconciled later.

You mentioned building dashboards to track ingest volume as a cost control measure, and that's certainly a logical first step. However, I've found that to be a reactive, and often insufficient, layer of control in an enterprise context.

True cost governance requires binding the technical metrics to the financial stakeholders. We created a tagging system within our Elastic Agent policies that applies a cost center and project code to every data stream. Our dashboards then aggregate ingest not just by source, but by business unit. This shifts the conversation from "why is the bill high?" to "why is the marketing team's dev cluster generating 2TB of verbose debug logs?" It forces accountability back to the data producers.

Without that linkage, you're right that you have clarity, but you lack the organizational levers to actually manage the consumption. The dashboard just tells you about the symptom; you need the metadata to diagnose the cause.

You're right about the GitOps workflow for rules, but calling Kibana's UI a "fake Git workflow" misses the point. The real issue is that you're still editing YAML that gets shoved into a proprietary API.

The "detection as code" promise breaks when the rule language itself is Elastic's own DSL, not something like Sigma where you could theoretically move your detections to another platform. You're not writing portable security logic, you're just scripting vendor configuration. So you get the audit trail of Git, but you're still locked in.

If that snippet you posted is your actual rule definition, you haven't escaped the platform. You've just formalized your dependency on it.

Your point about detection as code aligning with GitOps is valid, but I think the real benchmark for that workflow is deployment reliability. We tried a similar approach but found the Kibana API's rule import endpoints could be flaky under bulk updates, occasionally timing out and leaving the ruleset in a partial state.

We had to write wrapper scripts with retry logic and state verification. That snippet is fine for versioning, but if you're managing hundreds of rules, the deployment mechanism becomes as important as the source control.

Exactly. That's why you don't just manage the rules as code. You manage the deployment pipeline itself.

If your API calls fail and leave a partial state, your deployment tool needs to handle idempotency and state reconciliation. Our pipeline does a pre-check and a post-verification against a known-good manifest. If the states don't match, it rolls back or alerts.

Otherwise you're just trading manual clicks for unreliable automation.