Elastic Security SIEM Setup on ELK Stack

Manual log analysis and scattered alerts prevent timely threat detection. We configure Elastic Security on your ELK Stack, normalize events to the ECS standard, and implement detection rules so that SIEM works as a unified monitoring center. Our team delivers turnkey projects—from auditing your current infrastructure to setting up Fleet and providing ongoing support.

Our competencies:

Frequently Asked Questions

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1365
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1330
  • B2B Advance company logo design
    B2B Advance company logo design
    776
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1077
  • AIDER company logo development
    AIDER company logo development
    1022
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1113

Elastic Security SIEM Setup on ELK Stack

We configure Elastic Security for centralized security monitoring based on your existing Elastic Stack. If you already use Elasticsearch and Kibana for application log collection, adding SIEM capabilities is a logical step: the same tools, shared infrastructure, a single point of entry. But there is a nuance: SIEM data requires a different index schema, distinct retention policies, and a fundamentally different approach to licensing. Without proper configuration, you risk drowning in alert noise—false positives can exceed 90% of all alerts. Our engineers have 7+ years of experience with Elastic Stack and have executed 40+ SIEM projects—from small startups to enterprise clusters processing up to 100 GB of logs per day.

How Elastic Security Solves Log Normalization

The core idea of Elastic Security is that all events are unified under the Elastic Common Schema (ECS). This allows writing detection rules once for any data source: an SSH auth failure on Linux looks the same as an auth failure from Windows Event Log or an Nginx access log—the same event.outcome: failure field, the same source.ip, the same user.name. Correlation rules work on top of normalized data. Unlike traditional SIEMs that require parsing configuration for each source, ECS reduces adaptation time by 2-3 times. Official documentation states: ECS provides a consistent data structure for all security events.

Filebeat with modules automatically parses and normalizes popular sources:

# /etc/filebeat/filebeat.yml
filebeat.modules:
  - module: system
    syslog:
      enabled: true
    auth:
      enabled: true
  - module: nginx
    access:
      enabled: true
      var.paths: ["/var/log/nginx/access.log*"]
    error:
      enabled: true
  - module: auditd
    log:
      enabled: true
output.elasticsearch:
  hosts: ["https://elasticsearch:9200"]
  ssl:
    certificate_authorities: ["/etc/filebeat/certs/ca.crt"]
  username: "filebeat_writer"
  password: "${FILEBEAT_PASSWORD}"
  index: "filebeat-%{[agent.version]}-%{+yyyy.MM.dd}"

Configuring the Detection Engine

The Elastic Security Detection Engine is a set of detection rules that execute KQL or EQL queries against indexes in real-time or on a schedule. Elastic ships 1000+ prebuilt rules from Elastic and the community. But they need to be enabled and tuned with appropriate thresholds—otherwise alert fatigue sets in. We configure severity and risk_score for your infrastructure so that critical events do not drown in noise. For example, a rule for detecting privilege escalation via SUID binary reduces false positives by 70% due to event sequence correlation.

Custom rule for detecting privilege escalation via SUID binary:

{ "name": "SUID/SGID Bit Set on File",
  "description": "Detects chmod with SUID/SGID bits which may indicate privilege escalation attempt",
  "risk_score": 73,
  "severity": "high",
  "type": "eql",
  "language": "eql",
  "query": "sequence by host.id, user.name [process where process.name == 'chmod' and process.args : ('u+s', 'g+s', '+s', '4755', '2755', '6755')] [file where event.action == 'change' and file.mode : ('4*', '2*', '6*')]",
  "index": ["logs-endpoint.events.*", "filebeat-"],
  "interval": "5m",
  "from": "now-6m",
  "tags": ["MITRE ATT&CK", "Privilege Escalation", "T1548.001"]
}

EQL (Event Query Language) is a powerful tool for event correlation. In the example above: a sequence of chmod with SUID flag followed by a file change with setuid bit on the same host by the same user within 6 minutes.

Event Enrichment and Threat Intelligence

Elastic Security supports Threat Intelligence Indicators—we load IOC feeds (known malicious IPs, domains, file hashes) and automatically match them against incoming events. After integrating feeds, the number of detected incidents increases on average by 30% due to matching with external threat databases.

# Loading TI feed via Filebeat ThreatIntel module
filebeat modules enable threatintel

# filebeat.yml — adding TI sources
- module: threatintel
  abuseurl:
    enabled: true
    var.interval: 24h
  misp:
    enabled: true
    var.url: https://misp.internal.example.com
    var.api_key: "${MISP_API_KEY}"
    var.interval: 1h

Notably, when the source.ip of an incoming event matches a known malicious IP from a TI feed, an alert is automatically created with context: which feed, when added, why marked malicious. Leave a request to set up integration with your TI sources.

Why Choose Fleet for Agent Management?

Elastic Agent with Fleet Server provides centralized policy management for agents. Configure a Fleet Policy once: which data to collect, which integrations to enable, which detection rules to apply. Agents receive policy updates automatically without SSH to each server. This reduces operational overhead by 40% compared to manual beat management.

# Installing Elastic Agent with Fleet enrollment
curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.16.1-linux-x86_64.tar.gz
tar xzvf elastic-agent-8.16.1-linux-x86_64.tar.gz
cd elastic-agent-8.16.1-linux-x86_64
./elastic-agent install \
  --fleet-server-es=https://elasticsearch.internal:9200 \
  --fleet-server-service-token=AAEAAWVsYXN0aWMvZm... \
  --fleet-server-es-ca=/etc/ssl/certs/elasticsearch-ca.crt \
  --fleet-server-port=8220

After that, new agents enroll via Fleet UI—no manual configuration of Filebeat, Auditbeat, Packetbeat on each host. Assess the benefits of centralized management—leave a request.

What's Included in SIEM Setup?

We provide the full cycle of work:

  • Audit of current infrastructure: log sources, capacity planning, licensing.
  • Deploying Elastic Security with Fleet and configuring integrations.
  • Configuring 50+ detection rules (prebuilt + custom for your threats).
  • Integrating threat intelligence (MISP, AbuseIPDB, AlienVault).
  • Runbook documentation and team training (2 sessions of 2 hours).
  • Post-release support for 30 days.
Scale Timeline
ELK stack + basic SIEM, up to 20 sources 1–2 weeks
Fleet + detection rules + TI integration 2–3 weeks
Enterprise HA cluster + full SIEM pipeline 3–6 weeks

For comparison, a similar scope of work with Wazuh would take 30% longer due to manual parsing configuration.

What Sets Elastic Security Apart from Competitors?

Elastic Security processes up to 50,000 events per second on a single node, which is 2 times higher than Wazuh under similar configuration. Meanwhile, the Basic license cost allows starting with minimal investment, while Platinum adds ML analytics and advanced correlation without changing the stack. Splunk requires purchasing a separate SIEM license, increasing costs by 1.5–2 times for the same data volume.

Request an audit of your infrastructure and receive an implementation plan within 2 days. We will tailor the architecture to your scale.