Elastic Security

Elastic Security is the security analytics and detection platform from Elastic N.V. (NYSE: ESTC), founded in 2009, headquartered in Mountain View, California. Elastic is a search and observability company whose core product is the Elastic Stack: Elasticsearch® (the distributed search engine), Kibana® (the visualization and exploration layer), Beats (the data collection agents), and Elastic Agent (the unified agent). Elastic Security is the security-specific application layer on top of the Elastic Stack. It is not a separate product. It is a set of applications, detection rules, ML models, and workflows that run on the same Elasticsearch cluster that powers the organization's log management, APM, and observability workloads.

This architectural distinction is critical. In a Splunk deployment, the SIEM is the product. In a Sentinel deployment, the SIEM is the product. In an Elastic Security deployment, the SIEM is an application on a search platform. The same Elasticsearch cluster that stores and indexes security logs also stores and indexes APM traces, infrastructure metrics, application logs, and custom data. The security team and the engineering team share the same data platform, the same query engine, and the same visualization layer. The isolation between security and engineering is a logical boundary (roles, indices, access controls), not a physical boundary (separate clusters, separate vendors, separate licensing).

For a DevOps-heavy organization where the SOC and SRE operate as one team, this shared platform is a genuine operational advantage. A security investigation that requires context from application logs, infrastructure metrics, and deployment events is a single query on a single platform. No data export. No separate SIEM. No integration pipeline.

For a traditional SOC where security and engineering are separate organizations with separate tooling, the shared platform is a governance challenge. The security team needs isolation from the engineering team's data. The engineering team needs to not accidentally expose security data. The role-based access controls, index-level permissions, and data classification policies must be rigorously enforced. The platform supports this. The operational overhead of enforcing it is real.

Elastic is a public company (NYSE: ESTC). Financial stability is verifiable through earnings reports. The company's core business is the search and observability platform. Security is a growth vector, not the core product. The same strategic question applies as with Datadog: is the security vertical receiving the R&D investment that a security-first company allocates to its core product?

The deployment model is flexible. Elastic Cloud (SaaS, fully managed) or self-managed (on-prem, private cloud, hybrid). The self-managed option is a differentiator: for organizations with data sovereignty requirements, air-gapped environments, or regulatory constraints that prohibit SaaS, Elastic Security can run entirely within the organization's infrastructure. No other platform in this review offers a true self-managed option at the same level of maturity.

| Deployment Flexibility | Elastic Cloud (SaaS) or self-managed (on-prem, private cloud, hybrid, air-gapped). | The only platform in this review with a true self-managed option at production maturity. For data sovereignty, air-gapped, or regulatory-restricted environments, this is the differentiator. No other platform in this review offers the same level of self-managed control. | | Index Lifecycle Management (ILM) | Hot → Warm → Cold → Frozen, automated rollover, alias routing, shard optimization. | The ILM is the most granular storage tiering in this review. The Cold and Frozen tiers use S3-compatible object storage, reducing long-term retention costs. The Frozen tier requires rehydration for search, adding latency. |

Top 10 per category. † marks Elastic-specific strengths.

A. Identity & Access Control: Login success/failure; account lockout/MFA rejection; password change/reset; role/permission change; privileged service account activation; OAuth/SAML token anomaly; conditional access policy bypass; MFA registration; privileged session initiation; † UDM-mapped identity event correlation: sign-in anomaly + privilege escalation + data access, all using UDM field names (user.name, action, event.kind), consistent across all Elastic Security detection rules

B. File, App & Cloud Storage: File create/modify/delete; API key rotation; cloud bucket policy change; DB query on restricted tables; PAM session; first-time object storage access; mass download; container image pull from non-approved registry; Git permission elevation; † UDM-mapped file event: file.hash, file.path, file.action consistent across endpoint, cloud, and SaaS sources, enabling cross-source file correlation without field mapping

C. Network Flow: Src/Dst IP/port/protocol/duration/bytes; DNS query/response; TLS handshake; HTTP transaction; VPC Flow Logs; DNS tunneling; non-standard TLS ports; multi-connection fan-out; cross-region transfer; † Packetbeat (Beat) network discovery and protocol decoding: application-layer protocol identification (HTTP, DNS, TLS, MySQL, PostgreSQL) at the network layer, not just L3/L4 flow metadata

D. Endpoint/Email/Gateway: Executable hash block; macro document; C2 beacon; fileless execution; sandbox rejection; new scheduled task; SUID binary creation; registry persistence; email gateway failure; † Elastic Defend (EDR) native: process tree visualization, memory inspection, file tracking, and network activity per process, all queryable in the same Kibana Security timeline

E. Exploit & Attack: Buffer overflow; SQLi/XSS (CRS 4.25); exploit kit hit; RCE via CVE; lateral movement; cloud metadata access; IAM privilege escalation; container escape; DNS exfiltration; † Elastic Detection Rules: MITRE ATT&CK®-mapped rules with severity, risk score, and UDM field references, published in the Elastic Rules Repository and queryable across all Elastic Security data sources

F. Behavioral/UEBA: Impossible travel; egress spike; off-hours access; privilege escalation without ticket; service account interactive session; new API consumer; IAM role first-time assumption; authentication method change; data access breadth expansion; † Elasticsearch ML: population anomaly detection, classification, and regression models running on the cluster, configurable per user, per host, or per entity, with model retraining on a schedule

Collectors. Beats family (Filebeat, Winlogbeat, Packetbeat, Auditbeat) or the unified Elastic Agent. Syslog, HTTP, Kafka, S3/GCS/Azure Blob. No SNARE® or Splunk UF required. In a self-managed deployment, the Beats/Agent infrastructure is the organization's responsibility: sizing, patching, monitoring, and scaling.

Filtering. Ingest Pipelines (Grok, dissect, remove_field, script processors, conditional routing). Source-side filtering at the Beat/Agent configuration level.

Deduplication. No pre-ingest deduplication. Ingest pipeline processors handle transformation, not dedup. ML baselines deprioritize benign repetition. Alert aggregation groups related events. Raw events remain queryable.

Storage and Compute. Elasticsearch cluster. ILM: Hot → Warm → Cold → Frozen. Hot: SSD, fast search. Warm: HDD, reduced compute. Cold: S3-compatible, lower cost. Frozen: S3, lowest cost, rehydration required for search. In Elastic Cloud, the cluster is managed. In self-managed, the organization sizes, scales, and maintains the nodes.

Scale: >10K EPS. Beats and Elastic Agent handle high-velocity ingestion with async batching, TLS, and compression. In Elastic Cloud, the cluster auto-scales. In self-managed, the organization provisions additional data nodes. At enterprise scale, the Elasticsearch cluster is the bottleneck in self-managed deployments: shard count, heap memory, and disk I/O require dedicated tuning.

Failure Modes. In self-managed deployments, the Elasticsearch cluster is the single point of failure. A node failure, a disk failure, or a shard corruption can take down the search capability. The cluster's resilience depends on the organization's replica count, node count, and monitoring. In Elastic Cloud, AWS/Azure/GCP handles the infrastructure. The failure mode shifts to cost: Elasticsearch clusters are expensive to run at scale, and the $/GB for self-managed (or Elastic Cloud) can exceed the consumption-based pricing of Splunk Cloud or Sentinel.

Ingest Pipelines (Grok, dissect, script, conditional routing). UDM (Universal Data Model) as the primary schema. OCSF and CIM mapping via ingest transforms. The UDM standardization is a differentiator: source.ip, dest.ip, user.name, event.kind, event.action are consistent across all Elastic Security detection rules, reducing the field mapping burden for SOC analysts. In a multi-tool SOC, UDM is becoming the emerging standard alongside CIM.

ESQL (SQL-like) and Query DSL / Lucene. Full-text search, aggregations, joins, subqueries. Timeline visualizer (the primary hunting tool), Detection Rules, ML anomaly views. Kibana dashboards: drag-and-drop, role-based, real-time. Notebooks for investigation runbooks. BI: REST API, Power BI, Tableau®, S3/CSV export.

The ESQL language is the most approachable in this review for analysts with SQL experience. The Query DSL is more powerful but verbose. The combination covers the range from simple log searches to complex multi-index forensic queries.

Detection is from the Elastic Defend EDR (endpoint), CRS 4.25 or vendor-proprietary WAF (network), identity audit correlation, and cloud audit logs. The Detection Rules library is curated by Elastic's security team and mapped to MITRE ATT&CK®. The ML models (population anomaly, classification, regression) run on the Elasticsearch ML runtime.

SOAR is the gap. Elastic Security does not have a native SOAR engine. Alert actions are triggered via integrations (ServiceNow, Jira, Slack, Webhooks) and Stack Connectors. For complex multi-step orchestration (isolate host + block IP + disable user + open ticket + notify on-call), the workflow is assembled from individual integration calls, not from a unified playbook engine. A third-party SOAR platform (Cortex, Phantom, Sentinel) is required for full orchestration. This is the most significant SOAR gap in this review.

The free-stack context applies. The detection primitives are commodity. The Elastic premium buys the UDM standardization, the ML runtime on the cluster, the Timeline visualizer, the detection rules library, and the deployment flexibility (self-managed option). For an organization with data sovereignty requirements or air-gapped environments, the self-managed option is the differentiator that no other platform in this review matches.

| Deployment | Elastic Cloud (SaaS) or self-managed (on-prem, private cloud, hybrid, air-gapped). | | Runtime | Java-based Elasticsearch cluster. In Elastic Cloud: managed. Self-managed: organization-sized. | | Identity & Auth | SAML/OIDC. RBAC/ABAC. | | Network | Outbound TLS 1.2+. Inbound for Beats/syslog. | | Storage | ILM: Hot → Warm → Cold → Frozen. S3-compatible for Cold/Frozen. | | EOL / Migration | No EOL. Active development. Self-managed and SaaS are both supported forward.

Elastic Cloud: consumption-based (search + data + AI nodes, $/GB storage). Self-managed: infrastructure cost (CPU, RAM, storage) + Elastic license (Basic free, Standard, Platinum, Enterprise tiers).

Self-managed is cheaper at equivalent scale but requires dedicated engineering for cluster management. Elastic Cloud is more expensive but eliminates the infrastructure overhead. Search: unlimited within cluster capacity. No per-query fees. ILM tiers: Hot (bundled or $/GB), Warm (lower $/GB), Cold/Frozen (S3 rates, $0.01–$0.03/GB/month). Frozen requires rehydration.

Elastic Cloud: US, EU, APAC, additional regions. Self-managed: any region. SOC 2 Type II, ISO 27001, FedRAMP Moderate (verify), GDPR/CCPA, HIPAA, PCI-DSS. 200+ security integrations, 4,000+ platform integrations. UDM. Detection Rules. ML runtime. REST API. OpenSearch compatibility (Elasticsearch is the original; OpenSearch is the AWS fork). Professional services: Elastic partners, architecture reviews.

The open-source detection layer (Falco, Wazuh, Lynis, CrowdSec, Coraza/CRS, ClamAV, Chkrootkit) is not natively integrated. Beats can collect the logs. The correlation and detection are the SOC team's responsibility or a third-party SOAR's.

Named (Elastic-Specific): Capital One, Ford, Visa, Disney, Warner Bros. Discovery, Intuit, Salesforce, Atlassian, Discord, Shopify, DoorDash, Netflix, Spotify, Roblox, VMware.

MSSP/Big-4 excluded. A significant portion are Elastic Stack observability customers who enabled the Security application. Order does not indicate scale.

Strengths: Self-managed deployment option (unique in this review). UDM standardization. ILM granularity (4 tiers vs. 2–3 for most). ESQL approachability. Shared platform with observability. Detection Rules library. ML runtime on-cluster.

Weaknesses: No native SOAR engine (the most significant gap in this review). Self-managed requires dedicated engineering. ML models are configurable but less automated than purpose-built UEBA. Security is a growth vector, not the core business (search/observability is). Detection rules library is smaller than Splunk ES Content or Sentinel Analytic Rules.

Elastic Security is the strongest choice for organizations with data sovereignty requirements, air-gapped environments, or a DevOps-heavy culture where security and engineering share a data platform. The self-managed deployment option is unique in this review. The UDM standardization and ILM granularity are genuine differentiators.

The SOAR gap is the primary weakness. For a SOC that needs full multi-step orchestration without a third-party SOAR, Elastic Security is not sufficient. For a SOC that uses a dedicated SOAR platform (Cortex, Phantom, Sentinel) and needs a flexible, standards-based detection and analytics layer, Elastic Security is a strong fit.

Ideal buyer: Data sovereignty or air-gapped environment. DevOps-heavy culture. 500–10,000 endpoints. Existing Elastic Stack deployment. SOC team of 5–30. Ingestion 0.5–2 TB/day.

Key RFP: SOAR integration architecture (which third-party SOAR, how are playbooks executed). ILM cost model for 7-year retention. Self-managed vs. Elastic Cloud TCO comparison at the organization's volume. Detection rules count and MITRE ATT&CK® coverage. 3–5 referenceable customers with deployment context (self-managed vs. cloud).

Red flags: A TCO model that omits the ML node cost or the ILM Cold/Frozen tier cost. A SOAR answer of "we integrate with third-party SOAR" without specifying the integration depth and the playbook execution model.

IBM QRadar (On-Premises)