# Elastic Security: Open-Source SIEM and Endpoint Protection
Elastic Security is a unified security platform built on the Elastic Stack (Elasticsearch, Logstash, Kibana, and Beats) that provides security information and event management (SIEM), endpoint protection, and threat hunting capabilities within a single, open-source-friendly architecture. It exists because security teams need a scalable, cost-effective way to ingest, normalize, and analyze enormous volumes of log and telemetry data from heterogeneous environments. Proprietary SIEM solutions often impose per-gigabyte ingestion pricing that becomes prohibitive at enterprise scale, and they frequently lock analysts into rigid workflows. Elastic Security removes those constraints by giving practitioners direct control over data pipelines, detection logic, and visualization, while still providing production-grade reliability and a rich library of prebuilt detection rules aligned to MITRE ATT&CK.
---
Elastic Security is the security-focused product layer that sits atop the Elastic Stack, combining SIEM capabilities with endpoint detection and response (EDR) through the Elastic Agent and Endpoint Security integration. At its core, it is a data platform: raw logs and telemetry are ingested, parsed into Elastic Common Schema (ECS) format, indexed in Elasticsearch, and made queryable in real time through Kibana's Security application.
It is important to distinguish Elastic Security from several adjacent concepts. Elastic Security is not a standalone intrusion detection system (IDS) such as Snort or Suricata, although those tools can feed data into it. It is not a vulnerability scanner; it does not perform active probing of networked assets. It is not a managed detection and response (MDR) service; it is a platform that security teams operate themselves or through a managed service provider. It is also not synonymous with the broader Elastic Stack, which serves observability, search, and analytics use cases that have nothing to do with security.
Elastic Security exists in several deployment variants. The self-managed (on-premises) variant gives organizations full data sovereignty and is common in regulated industries. Elastic Cloud, the vendor-hosted SaaS offering, reduces operational burden and provides automatic version management. A third variant combines Elastic Cloud with Elastic's managed detection and response service, called Elastic Security Managed Services, which adds a human analyst tier. For endpoint protection specifically, the Elastic Agent with the Endpoint Security integration provides antivirus, ransomware protection, and behavioral detection capabilities that function even when the endpoint is not connected to the central Elasticsearch cluster.
---
Elastic Security operates through four primary technical layers: data collection, normalization, detection, and investigation.
Data Collection
Data enters the platform through multiple mechanisms. The Elastic Agent is a single, unified agent installed on endpoints that consolidates log collection, endpoint security, and integration with cloud services into one process, replacing the older model of deploying separate Beats agents (Filebeat, Winlogbeat, Packetbeat, and others) for each data type. Agents communicate with a Fleet Server, a central management plane that handles agent enrollment, policy assignment, and remote configuration updates at scale.
For infrastructure and network data, organizations continue to deploy standalone Beats or use Logstash as an intermediary pipeline that transforms, filters, and enriches records before indexing. Logstash is particularly valuable when ingesting from legacy syslog sources, custom application logs, or third-party security tools through vendor-provided integrations.
Elastic provides more than 300 prebuilt integrations covering cloud providers (AWS CloudTrail, Azure Activity Logs, Google Workspace), network devices (Palo Alto, Cisco ASA, Fortinet), identity providers (Okta, Active Directory), and endpoint operating systems. Each integration includes ingest pipelines that parse raw log formats into ECS-compliant fields.
Normalization via Elastic Common Schema
ECS is the foundational data model that makes cross-source correlation possible. When a Windows Security Event log and an Okta authentication log both record a login event, ECS maps both to common field names (user.name, source.ip, event.outcome) regardless of their original format. This normalization means that a detection rule written once can apply across all data sources without per-source customization, which is a significant operational advantage over SIEM platforms that maintain separate parsers and field mappings per product.
Detection Engine
The detection engine evaluates incoming data against a library of rules, producing alerts that appear in the Security application's Alerts view. Rules operate in several modes. Query-based rules run KQL (Kibana Query Language) or EQL (Event Query Language) searches on a schedule, typically every one to five minutes. EQL is particularly powerful for behavioral detection because it supports sequences: an analyst can write a rule that fires only when process creation, network connection, and file write events occur in a defined order within a specified time window, which dramatically reduces false positives compared to single-event rules.
Machine learning rules apply anomaly detection jobs to user behavior, network traffic, or process activity. When a user who normally authenticates from Chicago suddenly authenticates from an unrecognized country at 03:00, the ML job generates an anomaly score that can trigger an alert or enrich a related alert with context.
Threat intelligence rules match incoming events against indicator lists (IP addresses, file hashes, domains) stored in Elasticsearch itself, ingested via TAXII feeds or custom uploads. This allows immediate correlation of observed events against known-bad indicators without leaving the platform.
Investigation and Response
The Security application provides timeline views that reconstruct event sequences chronologically across all data sources. Analysts can pivot from an alert to view all network connections, process executions, file modifications, and authentication events associated with a user or host within a defined time window. This approach eliminates the need to query multiple tools or correlate events manually across different consoles.
Case management functionality allows analysts to document findings, assign alerts to team members, and track investigation progress through to resolution. Integration with external ticketing systems (JIRA, ServiceNow) ensures that security workflows align with broader organizational incident response processes.
For response actions, Fleet management enables analysts to isolate compromised endpoints, collect forensic artifacts, or deploy response scripts remotely through the Elastic Agent without requiring separate EDR tooling or direct system access.
Concrete Scenario: Detecting a Credential Harvesting Attack
Consider a scenario where an attacker uses a spearphishing email to deliver a malicious Office document that executes a PowerShell cradle to download and run Mimikatz. The detection sequence unfolds as follows. The Elastic Endpoint Security integration detects the suspicious child process spawned by WINWORD.EXE and generates a process creation event. An EQL sequence rule matches this against a known pattern: parent process is an Office application, child process is PowerShell, and within 60 seconds a network connection is made to a non-corporate external IP. The rule fires an alert tagged to MITRE ATT&CK technique T1566.001 (Spearphishing Attachment) and T1059.001 (PowerShell). Simultaneously, a memory protection feature in Elastic Endpoint detects Mimikatz's characteristic LSASS access pattern and terminates the process. The analyst sees both alerts in the timeline view, can pivot immediately to the affected host's full process tree, network connections, and file system changes, and can isolate the host from the Fleet console without leaving Kibana.
Configuration Considerations
Index lifecycle management (ILM) policies are essential for controlling storage costs. Hot-warm-cold-delete tiers allow recent data (hot) to reside on fast SSD nodes for rapid querying, while older data moves progressively to cheaper storage. For a typical enterprise ingesting 100 GB per day, defining ILM policies from day one prevents unmanageable index bloat within weeks.
Role-based access control (RBAC) in Elasticsearch should be configured to limit which analysts can view which data indices, which users can modify detection rules, and which accounts have administrative access to Fleet. Analysts should never operate with cluster-level administrative privileges during daily work.
---
Without a functional SIEM and endpoint protection platform, security teams operate reactively rather than proactively. Threats that persist for days or weeks go undetected because there is no continuous analysis of log data. When an incident is eventually discovered, the absence of historical telemetry makes forensic reconstruction nearly impossible, leading to incomplete root cause analysis and repeated compromises.
The 2020 SolarWinds supply chain attack illustrated the consequences of inadequate SIEM visibility. Numerous organizations had the network traffic and authentication logs that would have revealed the anomalous lateral movement and data staging behaviors associated with the SUNBURST backdoor. However, those logs were either not being collected, not being correlated, or not being reviewed. Organizations that had mature SIEM deployments with strong baselining of privileged account behavior detected the anomalies; many others did not discover the compromise until FireEye and Microsoft published indicators of compromise weeks after the fact.
Elastic Security matters for several specific operational reasons. First, its open detection rule library on GitHub means that when new threat intelligence becomes available, community-contributed rules can be deployed within hours rather than waiting for a vendor patch cycle. Second, the ECS normalization model means that onboarding a new data source does not require rebuilding detection logic. Third, the cost model is fundamentally different from proprietary SIEM platforms: organizations pay for compute and storage rather than per-gigabyte ingestion, which removes the perverse incentive to reduce log collection in order to control licensing costs.
The financial impact becomes clear when comparing enterprise deployments. A large organization ingesting 1TB per day would pay approximately $3.6 million annually for a traditional SIEM at standard per-gigabyte rates. The same organization could operate a comprehensive Elastic Security deployment for a fraction of that cost, reallocating budget from software licensing to additional analyst hiring or enhanced security tooling.
A common misconception is that Elastic Security is appropriate only for large enterprises with dedicated security engineering teams. In practice, the managed cloud offering and prebuilt detection content lower the barrier significantly. A small security operations team of three to five analysts can deploy a functional SIEM covering cloud infrastructure, endpoints, and identity within days using official documentation and prebuilt integrations. The more accurate constraint is not team size but data engineering maturity: organizations that lack experience managing distributed systems may find index tuning, ILM policy design, and cluster sizing non-trivial to get right initially.
A second misconception is that enabling the endpoint protection component is sufficient on its own. Endpoint telemetry without SIEM correlation misses attack paths that traverse multiple systems. Defense in depth requires both layers working together.
---
The Center for Defensive Action (CDA) approaches Elastic Security through the Predictive Defense Intelligence (PDI) methodology, which operates on a single operational principle: see the threat before it sees you. Within the Threat Intelligence and Detection (TID) domain of the Planetary Defense Model, Elastic Security serves as the primary telemetry aggregation and correlation platform that makes predictive detection possible rather than reactive.
CDA's approach diverges from standard deployments in several operational specifics. Most organizations deploy Elastic Security with its default detection rules enabled and treat alert triage as the primary workflow. CDA treats the detection rule library as a starting point, not a destination. CDA analysts perform threat modeling against the organization's specific technology stack and threat actor profile, then author custom EQL sequence rules that reflect the actual attack paths an adversary would take to achieve their objectives in that environment. This means detection logic is specific rather than generic, which reduces false positive volume and increases analyst confidence in alerts.
CDA also prioritizes threat hunting as a scheduled, proactive activity rather than an ad hoc response to alerts. Analysts run structured hunts in Elasticsearch using time-bounded queries that look for low-and-slow behaviors, such as periodic beaconing to uncommon external destinations or incremental exfiltration patterns that fall below single-event alert thresholds. EQL's sequence matching capability is central to these hunts, enabling analysts to identify multi-step attack behaviors across days of telemetry.
On the data engineering side, CDA establishes tiered data collection policies aligned to asset criticality. High-value assets (domain controllers, privileged workstations, critical servers) receive full verbose logging with short retention on hot nodes. Lower-criticality assets receive summary logging with longer cold-tier retention. This architecture ensures that the most important telemetry is always available for rapid querying during an active investigation without inflating overall infrastructure costs.
Finally, CDA integrates Elastic Security with external threat intelligence platforms (such as MISP or OpenCTI) via TAXII, ensuring that newly published indicators of compromise are automatically available as threat intelligence match rules within 24 hours of publication. This closes the gap between intelligence publication and operational detection.
---
---
---