Security Onion¶

Introduction¶

Security Onion is a free and open platform built by defenders for defenders. It includes network visibility, host visibility, intrusion detection honeypots, log management, and case management.

For network visibility, we offer signature based detection via Suricata, rich protocol metadata and file extraction using either Zeek or Suricata, full packet capture using either Stenographer or Suricata, and file analysis. For host visibility, we offer the Elastic Agent which provides data collection, live queries via osquery, and centralized management using Elastic Fleet. Intrusion detection honeypots based on OpenCanary can be added to your deployment for even more enterprise visibility. All of these logs flow into Elasticsearch and we’ve built our own user interfaces for alerts, dashboards, threat hunting, case management, and grid management.

Visibility¶

This section describes the various visibility sources Security Onion integrates with. It will cover both host and network visibility.

Security Onion integrates the ELK stack (Elasticsearch, Logstash, Kibana) as its core log management and analysis layer. Logstash ingests and normalizes logs and network events from sensors, parsers, and other monitoring components within Security Onion. It applies filters and enrichments to make disparate log formats uniform. Elasticsearch stores the processed data as indexed documents, enabling rapid searching and correlation across large volumes of network, host, and security logs. Kibana provides the visualization and query interface, giving analysts dashboards for intrusion detection alerts, full packet capture metadata, endpoint logs, and system telemetry. Together, this stack supports Security Onion’s role as a SIEM: collection, normalization, storage, search, correlation, and visualization of security events.

Elastic also provides an agent that is deployed on endpoints to forward logs and serve as EDR solution to generate alerts. It replaces some of the functionality that Filebeat previously offered and can forward Sysmon logs.

Host visibility¶

The endpoints in the network are used for experimentation into detection use cases. Therefore, they should forward as many logs as possible to Security Onion for further analysis into host visibility. This is achieved through deploying Elastic Agents, which function both as a log forwarder and alerting engine. This is managed through the Elastic Fleet.

Elastic Agent¶

With Elastic Agent you can collect all forms of data from anywhere with a single unified agent per host. One thing to install, configure, and scale. The Elastic Fleet is deploying an Elastic Agent policy named endpoints-initial to the endpoints. Agent policies dictate what data each agent will ingest and forward to Elasticsearch. This could be through the use of an HTTP, log file, or TCP-based input. The selected policy includes the following integrations:

endpoint_policy — Integrations included in the Elastic Agent policy `endpoints-initial` for endpoints.

Info

These integrations include the following data:

elastic-defend-endpoints: this is Elastic's EDR-like integration with an alerting engine and both free and paid features. However, it is not setup to replace Windows Defender as EDR as we want to ingest as many logs and alerts as possible and therefore not block any activity on the endpoints. It captures events on Windows (API, DLL and Driver Load, DNS, File, Network, Process, Registry, Security), MacOS (File, Process, Network), and Linux (File, Process, Network).
osquery-endpoints: this allows analysts to query information on the system directly through live or scheduled queries. It does not provide logs on a continuous basis.
system-endpoints: this collects logs from System instances and Windows Events (Application, Security, and System).
windows-defender: this collects custom Windows Event (Operational) logs. This integration was added manually.
windows-endpoints: this collects logs from the channels ForwardedEvents, Powershell, Microsoft-Windows-Powershell/Operational, and Microsoft-Windows-Sysmon/Operational.

Sysmon¶

System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network.

Sysmon is deployed on Windows hosts in the network following these instructions. It is using the highly verbose configuration made by Roberto Rodrigues (@Cyb3rWard0g) to ingest as many logs as possible.

Network visibility¶

Security Onion offers network visibility on various levels, ranging from metadata to full packet capture. Additionally, it provides automated captures file analysis.

Zeek¶

Zeek is a powerful network analysis framework that is much different from the typical IDS you may know. (Zeek is the new name for the long-established Bro system. Note that parts of the system retain the “Bro” name, and it also often appears in the documentation and distributions.)

Zeek captures a wide range of network metadata, including specific protocols such as DNS, HTTP, SSL. It can also extract files.

Suricata¶

Suricata is a free and open source, mature, fast and robust network threat detection engine. Suricata inspects the network traffic using a powerful and extensive rules and signature language, and has powerful Lua scripting support for detection of complex threats.

Suricata functions as a network intrusion detection system (NIDS).

Strelka¶

Strelka is a real-time file scanning system used for threat hunting, threat detection, and incident response. Based on the design established by Lockheed Martin’s Laika BOSS and similar projects (see: related projects), Strelka’s purpose is to perform file extraction and metadata collection at huge scale.

Strelka will automatically analyze files extracted by Zeek and Suricata. Alerts can be generated based on this analysis.

Analysis¶

Security Onion provides tools for the analyst through its Security Onion Console (SOC). This consists of a combination of custom and existing tools for analysts to analyze what Security Onion has captured and detected.

Kibana¶

Elastic Kibana acts as the Security Information and Event Management (SIEM) of the ELK stack. While Security Onion offers custom tools, the preferred tool for log analysis is Kibana because of its completeness.

Analytics¶

Kibana Analytics contains the pages used for searching logs with KQL queries. Logs are part of indices and data streams. Both can be used in queries, but data streams are more convenient. An index is rotated automatically when reaching a certain size and therefore the same type of data can be spread over multiple indices. Wildcards in your query can take care of this but data streams fix this issue as they provide a single named resource that acts as a front door to multiple indices. Therefore, data streams are more convenient to use.

Elastic Defend¶

Elastic Defend provides organizations with prevention, detection, and response capabilities with deep visibility for EPP, EDR, SIEM, and Security Analytics use cases across Windows, macOS, and Linux operating systems running on both traditional endpoints and public cloud environments.

Kibana contains a special integration for Elastic Defend. Here, security rules and their alerts can be managed. The out-of-the-box configuration of Elastic Defend only enables about 25 alerts. We enabled all 1260 to have full coverage. This can be done through `Kibana -> Security -> Rules -> Detection rules (SIEM) -> Select all x rules -> Bulk actions -> Enable. The queries for the rules will now run on a schedule. This does not severely impact performance.

More information for all available open-source Elastic Security rules (GitHub) can be found and searched for on this page.

KQL vs EQL

Kibana offers multiple query languages that can be used for searching logs and building alerts.

KQL is a filter query language. It matches documents based on field values, supports full-text search, and logical operators. It does not provide sequence or temporal correlation.

EQL is an event correlation language. It is designed for ordered event sequences, temporal relationships, and patterns over time. It can express constructs like sequence, until, and time windows, which KQL cannot. EQL is less flexible for free-form search but more powerful for behavioral detection.

KQL use cases

Ad-hoc searching in Discover for field values and text
Dashboards and visualizations that need fast filtering
Alerts or rules based only on static conditions like process.name: "powershell.exe" and process.args_count > 2
Investigations requiring flexible wildcard and fuzzy matching across multiple fields

EQL use cases

Detection of process chains such as explorer.exe → powershell.exe → rundll32.exe
Sequenced file and network events, e.g. a file write followed within 30s by an outbound connection
Behavioral rules that require temporal correlation (process A starts, then within X seconds process B starts)
Threat hunting patterns like persistence followed by privilege escalation