# Elastic Security: Open-Source SIEM and Endpoint Protection
Elastic Security is a unified security platform built on the Elastic Stack, combining Security Information and Event Management (SIEM), endpoint detection and response (EDR), and cloud security monitoring into a single, open-core solution. It exists because security teams need scalable, high-fidelity visibility across their entire environment without the punishing per-gigabyte pricing that dominates commercial SIEM alternatives. The platform solves three persistent problems simultaneously: log ingestion at scale, endpoint telemetry collection, and analyst workflow management. By anchoring on Elasticsearch as a distributed search and analytics engine, Elastic Security allows organizations to ingest, correlate, and investigate security data volumes that would be cost-prohibitive in licensed-per-GB products. The open-source foundation means teams can inspect, extend, and adapt the platform rather than accepting a vendor's black-box logic.
---
Elastic Security is a security operations platform built on top of the Elastic Stack, which consists of Elasticsearch (the distributed search and indexing engine), Kibana (the visualization and analyst interface), Logstash (the data processing pipeline), and the Beats family of lightweight data shippers. The Security application within Kibana serves as the primary analyst workspace, providing alert management, timeline investigation, case management, and rule creation.
The platform is open-core rather than fully open source. The core ingestion, search, and detection engine is freely available under the Elastic License 2.0 and Server Side Public License. Advanced features including machine learning anomaly detection, automated response actions, and platinum-tier threat intelligence integrations require a commercial subscription.
Elastic Security exists to solve the fundamental SIEM affordability problem. Traditional commercial SIEMs charge per gigabyte of daily log ingest, creating a perverse economic incentive where organizations reduce logging to control costs. This leaves security teams with insufficient visibility during the exact moment they need comprehensive telemetry to detect sophisticated attackers. Elastic Security's infrastructure-based pricing model (compute and storage costs, not data volume) eliminates this tradeoff, enabling organizations to log comprehensively without financial penalties.
The platform fits into the security architecture as the central correlation and investigation layer. It ingests logs from firewalls, domain controllers, endpoints, cloud services, and network devices. It normalizes these disparate data sources into the Elastic Common Schema (ECS). It applies detection rules to identify suspicious patterns. It surfaces alerts to analysts through a unified interface. It preserves investigation timelines for incident response and forensics.
Elastic Security is not a managed detection and response (MDR) service. It is software that security teams operate themselves, either on-premises or via Elastic Cloud. This distinction matters: Elastic Security requires skilled operators to configure detection rules, tune alert thresholds, and manage infrastructure. Organizations without in-house security engineering capacity should evaluate whether they have the staffing to run it effectively before deployment.
---
Data Ingestion Architecture
Elastic Security begins with data collection through a unified agent architecture. The Elastic Agent is the current-generation collector that replaces the older individual Beats agents (Filebeat, Winlogbeat, Auditbeat, Packetbeat) under central management through Fleet, which is embedded in Kibana. When an administrator deploys an Elastic Agent to a Windows endpoint, they assign it an Agent Policy that specifies which integrations to activate: Windows event logs, Sysmon, DNS query logs, and Elastic Defend (the endpoint security component). Fleet pushes that policy to the agent, which begins shipping telemetry to Elasticsearch over a compressed, authenticated connection.
For network devices, firewalls, and systems that cannot run an agent, Logstash or Filebeat can receive syslog streams, parse them with grok patterns or Elastic Common Schema processors, and index them into Elasticsearch. ECS normalization is critical: it ensures that a source IP address from a Cisco firewall log and a source IP from a Windows Security event log share the same field name (source.ip). Without this normalization, cross-source correlation queries would be brittle and manual.
The ingestion pipeline automatically enriches events with geolocation data for IP addresses, threat intelligence feeds for known indicators, and asset inventory context from configuration management databases. This enrichment happens at index time, not query time, maintaining search performance even across terabyte-scale datasets.
Detection Engine Mechanics
Once data is indexed, detection runs through multiple parallel mechanisms: pre-built detection rules, custom rules authored by the security team, machine learning anomaly detection, and threshold-based alerting.
Elastic maintains a public GitHub repository of detection rules mapped to MITRE ATT&CK techniques. These rules are written in the Elastic Query Language (EQL) or Kibana Query Language (KQL) and cover techniques including credential dumping (Mimikatz execution), lateral movement via PsExec, and scheduled task abuse. An administrator imports these rules into the Security app and enables them selectively based on the organization's environment.
EQL is particularly powerful for multi-event sequence detection. A rule that detects a parent process (cmd.exe) spawning a child process (powershell.exe) which then makes a network connection within a 30-second window requires sequence logic that flat log searches cannot express. EQL handles this natively:
sequence by process.entity_id with maxspan=30s
[process where process.name == "cmd.exe"]
[process where process.parent.name == "cmd.exe" and process.name == "powershell.exe"]
[network where process.name == "powershell.exe"]This type of behavioral chain detection is how Elastic Security catches attacks that evade signature-based tools.
Machine Learning Integration
Paid tiers include unsupervised machine learning jobs that baseline normal behavior and surface statistical anomalies. A relevant job is the rare_process_by_host job, which identifies processes running on a host for the first time relative to a 14-day training window. If an attacker runs a custom implant on a workstation where that binary has never executed, the ML job generates an anomaly score. Analysts review these scores in the Security app alongside rule-based alerts.
The DGA (Domain Generation Algorithm) detection job identifies suspicious DNS queries that match algorithmically generated domain patterns commonly used by malware for command and control communication. Rather than maintaining blocklists of specific domains, the ML model detects the entropic characteristics of generated domains.
Endpoint Detection and Response Integration
Elastic Defend, the endpoint component, provides prevention, detection, and response capabilities that integrate directly with the SIEM layer. Prevention capabilities include malware blocking, ransomware protection, memory-based attack prevention (process injection, DLL hollowing), and behavioral prevention for credential access techniques.
Detection telemetry includes process creation with full command line arguments, network connections, file modifications, registry changes, and Windows API calls. This granular visibility feeds into EQL rules that correlate endpoint activity with network logs, authentication events, and cloud activity.
Response actions can be triggered directly from the Security app: isolating a host from the network, terminating a process, deleting a file, or suspending a process. An analyst can isolate a compromised workstation while maintaining the Elastic Agent connection for continued investigation. This operational capability means incident response does not require separate tools or loss of telemetry during containment.
Investigation Workflow
When an alert triggers, analysts open it in the Timeline view, which presents all related events in chronological order. The timeline automatically includes events from the same host, user, and IP address within a configurable time window. Analysts can expand the scope by adding fields (process.parent.executable, source.ip) to see related activity across the environment.
Case management functionality tracks investigation progress, assignee responsibility, and external ticket integration. Cases can include multiple alerts, investigation notes, and response actions. ServiceNow and Jira integrations create tickets automatically when cases reach specific criteria.
A Concrete Attack Scenario
A threat actor compromises a user's endpoint through a phishing email containing a malicious Office document. The document executes a macro that runs PowerShell to download and execute a Cobalt Strike beacon. The attacker then performs credential dumping and lateral movement to a domain controller.
Elastic Security detects this attack through multiple detection layers:
The analyst opens the initial alert, sees the full attack timeline, and isolates both the initial compromised workstation and the domain controller while initiating credential reset procedures for affected accounts.
---
Organizations without a functioning SIEM operate with systematic blind spots that attackers exploit. Modern attack campaigns unfold over days or weeks, involving reconnaissance, lateral movement, credential harvesting, and data staging. Each phase leaves evidence in logs: DNS queries for reconnaissance domains, authentication failures during credential stuffing, unusual process execution during lateral movement, and large data transfers during exfiltration. Without a platform to collect, normalize, and correlate these logs, security teams only discover intrusions after primary objectives are achieved or when external parties notify them.
The economic argument for infrastructure-cost SIEM is concrete and measurable. Commercial SIEMs that charge per gigabyte of daily ingest can cost $50,000 to $500,000 annually for a mid-size enterprise with comprehensive logging. Organizations respond to this pricing by implementing log filtering, reducing retention periods, or simply accepting coverage gaps. These cost-driven decisions create the exact blind spots that sophisticated attackers depend on.
A documented consequence of SIEM economic constraints was visible in the 2020 SolarWinds supply chain compromise. Many affected organizations lacked the log retention depth to reconstruct attacker activity beyond 30-90 days, because they had reduced log volumes to control SIEM licensing costs. Post-incident forensics required log data that had been pruned or never collected. Organizations running infrastructure-cost SIEM models had better forensic fidelity because they had no financial incentive to delete data.
Elastic Security's infrastructure-based cost model eliminates this perverse incentive. Teams can ingest DNS query logs, full Windows event logs, endpoint telemetry, and cloud service logs without per-gigabyte penalties. The result is detection fidelity that scales with actual security needs rather than budget constraints.
However, deploying Elastic Security is not equivalent to achieving security outcomes. The platform is tooling, not a program. An organization can have Elastic Security running perfectly and still miss attacks because detection rules are not tuned, alerts are not investigated, or no one is responding to findings. The tool enables visibility; it does not produce security by existing.
A second critical misconception is that the free tier provides production-ready security operations capability. The absence of machine learning anomaly detection, advanced response actions, and threat intelligence integrations in the free tier limits the platform's ability to catch novel attacks that have no rule signature. Organizations evaluating deployment tiers should assess their detection engineering maturity honestly: teams with strong EQL rule development skills can accomplish significant detection coverage on the free tier; teams that need automated baselining to compensate for limited analyst capacity should budget for paid subscriptions.
---
CDA approaches Elastic Security through the Threat Intelligence and Defense (TID) domain of the Planetary Defense Model, with methodology grounded in Predictive Defense Intelligence (PDI): see the threat before it sees you.
The conventional deployment pattern for Elastic Security in most organizations is reactive. Teams install the stack, enable default rules, and wait for alerts. This approach treats the platform as a generic log aggregator rather than a threat-specific detection engine. CDA's PDI methodology inverts this sequence entirely.
Before deploying a single agent or writing a single rule, CDA conducts a threat profile assessment for the client environment. This assessment identifies which adversary groups target the client's industry, geography, and technology stack. It catalogs the specific TTPs (Tactics, Techniques, and Procedures) most relevant based on current threat intelligence from MITRE ATT&CK, CISA advisories, commercial feeds, and CDA's proprietary intelligence collection. This threat profile drives every subsequent configuration decision.
For example, if a client operates in critical manufacturing and threat intelligence indicates active targeting by a group using Cobalt Strike with named-pipe C2 communications, CDA deploys Elastic Security with specific EQL rules covering named-pipe creation by unusual parent processes, DNS queries matching Cobalt Strike's default user agent strings, and process injection techniques common to that beacon family. The detection posture is aligned to the actual threat, not to a generic rule library.
CDA implements detection coverage mapping as a continuous operational practice. Every Elastic detection rule is tagged to its corresponding MITRE ATT&CK technique and sub-technique. Coverage is visualized using the ATT&CK Navigator, which produces a heat map showing which adversary techniques have detection coverage versus which represent blind spots. This artifact is reviewed monthly and updated after each significant threat intelligence development. Coverage gaps drive either new rule development or compensating control recommendations.
On the response side, CDA configures Elastic's automated response playbooks for high-confidence detections: automatic host isolation for confirmed ransomware behavioral indicators, automatic process termination for known offensive tool signatures, and automatic case creation for credential access anomalies. This reduces dwell time by eliminating the delay between alert generation and initial response for well-understood threat scenarios, while preserving analyst review for lower-confidence or novel detections.
The PDI principle operationalized through Elastic Security means that clients detect adversary activity during the reconnaissance, resource development, or initial access phases of the attack lifecycle. They are not responding to incidents that have already achieved primary objectives. They are stopping attacks before they become incidents.
---
---
---