Security Onion endpoint visibility with Elastic Agent

Security Onion bundles several components into one platform: the Security Onion Console, Elasticsearch, Suricata, Zeek and Elastic Fleet agents. Of these, Fleet is the control point for endpoint visibility. It is where agent policies are created, edited and assigned to enrolled agents, and it is the place to check whether an endpoint is healthy and running the policy you intended. Before you deploy anything to a Windows, Linux or macOS host, confirm that you understand this split: the network sensors watch traffic, while Fleet governs what runs on the endpoints themselves.

Elastic Agent is the software installed on each endpoint. Its job in this stack is to collect host logs and ship them to the Security Onion search infrastructure, where they are indexed next to the Zeek and Suricata records. The agent does not make detection decisions on its own. It follows the policy it was given, which lists the data sources and integrations to enable. Ask your Security Onion deployment team to confirm which integrations are supported on each operating system you plan to cover, because coverage differs by platform and by release, and the documentation for your installed version is the authority.

Osquery live queries are the interactive query capability that Fleet can run against enrolled endpoints. An analyst can ask a question of a host, such as which processes are listening on a port or which users are logged in, and receive an answer without waiting for logs to arrive. Whether Osquery is available, and which platforms it covers in your version, should be confirmed for each operating system in your estate. Treat live queries as an investigation aid. They do not replace continuous log collection, and their results depend on the endpoint being online and enrolled at the time of the query.

Policies are assigned to groups of endpoints rather than to individual machines, so one policy change can affect every host in a group. When an administrator edits a policy, the change does not reach agents instantly. It is delivered when each agent checks in with Fleet, which means different hosts may run the old and new settings for a period. This has practical consequences. A broken integration in a shared policy can stop log collection across many systems at once, and an overly broad group can send unwanted data to the search nodes.

Plan policy ownership before rollout. Decide who may create and edit policies, who approves changes to shared groups, how Windows, Linux and macOS hosts are separated into groups, and how a rollback would be applied and verified. Record the owner of each group and the process for testing a change on a small set of hosts first. Teams that settle these questions early tend to find that Fleet becomes a predictable control point rather than a source of surprise changes during an incident.

Correlation between host telemetry and network records only works when three things line up: clocks, host names and IP-to-host records. Get those right before the first incident, because during an investigation there is rarely time to discover that a workstation's address changed last week or that one log source records times in local time while another uses UTC. The section below walks through an illustrative investigation to show where each dependency matters.

Illustrative investigation. An analyst opens a Suricata alert in the Security Onion Console for an outbound connection from an internal address to an external host on an uncommon port. The alert carries a source IP, destination IP, port, timestamp and rule identifier. The first pivot is from that source IP to the host that held the address at the alert time. That lookup depends on DHCP lease history, static address records or the asset inventory in your environment, not on the alert alone. Record which source you used so the finding can be reproduced.

Next, the analyst checks Zeek connection records (conn logs) for the same source and destination within a window around the alert. Zeek shows whether the session was short or long lived, how many bytes moved and whether earlier connections to the same destination existed. On the host side, the analyst reviews process activity from Elastic Agent data for the same window, looking for the process that owned a socket to that destination. Because the Elastic Agent data and Zeek data come from different collectors, the join is only as reliable as the timestamps on both sides. Confirm the time zone and clock source on each sensor, manager and endpoint before trusting an offset of a few seconds.

Name consistency is the second dependency. Endpoints enrolled in Fleet should report a host name that matches the name your asset records and DNS use, or the analyst will need a manual mapping table during the case. Decide which identifier is canonical (host name, device identifier or a managed asset ID) and document how DHCP-assigned addresses map to it. Review that mapping at a set interval, since stale records are a common cause of attributing activity to the wrong machine.

Finally, treat Security Onion Console detections as part of the same evidence set. NIDS rules managed in the Detections interface are loaded into Suricata and can be modified, suppressed or threshold-tuned, so a quiet alert may reflect a suppression someone added months earlier. Confirm which rule version fired, who last changed it and whether the analyst workflow includes checking the detection's tuning history before drawing conclusions from host data. Agree on this review step in the runbook and test it with a tabletop exercise before you rely on it.

Do not call an Elastic Agent rollout finished when agents appear as installed. Finish it when a defined set of checks passes on every pilot endpoint and the results are written down. These checks confirm that Fleet, the agents, the policy and the Security Onion pipeline are all doing their part. Set the pass criteria yourself before the pilot starts. Vendor defaults and example thresholds are a starting point, not an acceptance standard for your environment.

Start in Fleet. Every pilot endpoint should show as healthy, with its agent enrolled in the intended agent policy and its check-in current. Then confirm the expected event types for each operating system. Windows, Linux and macOS hosts produce different data streams, and an agent can report as healthy while a data stream is silent because an integration is disabled or a log path is wrong. Write the expected data streams for each operating system in your coverage list and compare them against what reaches the Security Onion Console for each host.

Next, prove end to end delivery. Generate a known test event on each host, such as a logon, a process start or a file creation made under a test account, and search for it in the Security Onion Console within a window you state in advance. Record the time the event was generated, the time it appeared, and whether it matched the host name and fields you expected. Then check correlation: pick a Zeek or Suricata record for a connection involving the test host and confirm the host log and the network record can be linked by the same address, time and identity fields. If that link fails, your investigation workflow has a gap even when ingestion succeeds.

Also test the control path. Make a small, reversible change to an agent policy, such as adding a data stream or changing a collection setting, and confirm that the change reaches the agents on the pilot hosts within your stated window. Revert it and confirm again. This shows that policy management works before you depend on it during an incident. The coverage list should be a documented table per endpoint class, such as domain controllers, servers, workstations and macOS laptops, showing the expected agents, data streams, test results and owners.

Repeat these checks after Security Onion upgrades, Elastic Agent version changes and any policy edit that touches collection. Upgrades can change field names, data stream behavior or parsing, so a passing check from last month is not evidence for today. Ask the vendor and your own change records to confirm what changes in each release, and rerun the tests that cover those areas. Keep the retest results with the change record so auditors and responders can see when coverage was last verified.