Start with the traffic question
Security Onion planning begins with what traffic an analyst needs to observe and where it travels. A sensor only sees traffic deliberately delivered through a tap, mirror, virtual switch path, or other engineered visibility point. Draw network segments, critical services, encryption boundaries, remote access paths, and expected blind spots before placing sensors.
Do not describe a deployment as full network visibility unless the map proves it. East-west traffic, cloud paths, encrypted flows, unmanaged networks, and remote endpoints each need explicit treatment.
Design the sensor and storage path
Use current Security Onion documentation to select sensor and management architecture appropriate to the environment. Map traffic delivery, management access, time synchronisation, sensor health, storage, analyst access, and any packet-capture retention. Packet data and derived network metadata can be sensitive; restrict access and state retention.
Measure traffic volume and bursts at the proposed collection point. Mirror oversubscription, packet loss, insufficient disk, and a blocked management path all create evidence gaps.
Validate a controlled segment
Begin with one meaningful network segment. Confirm the sensor receives expected traffic, timestamps align, a known safe DNS or connection event is searchable, access roles work, and storage growth matches observation. Record what was intentionally not visible.
For an illustrative test, send a controlled request between two test systems and verify it through the analyst workflow without using sensitive production traffic.
Operate the visibility boundary
Monitor sensor health, capture loss indicators, traffic changes, storage, search behaviour, access failures, and configuration changes. Give network engineers, security analysts, and platform operators separate responsibilities. Changes to switching, cloud routing, or service placement can remove visibility without changing the Security Onion application.
Exercise recovery using the documented persistence boundary and test that an authorised analyst can reach a representative search after restoration.
Planning record
Keep sensor placement reviewable.
| Area | Decision | Evidence |
|---|---|---|
| Coverage | Which paths are delivered to each sensor? | Network diagram and controlled observation. |
| Capacity | What traffic and retention is supported? | Measured volume and storage record. |
| Access | Who may administer or investigate? | Role test. |
| Gaps | Which paths remain unseen? | Reviewed exception list. |
Questions to test
Does a mirror show all traffic?
Only traffic configured to reach that mirror, within its capacity. Validate with controlled observations.
Can encrypted traffic still provide value?
Network metadata and other sensors may still be useful, but be precise about the evidence available and its limits.
What triggers a redesign?
New network segments, cloud routing, traffic growth, capture loss, or a changed investigation requirement.
Plan, observe, maintain
Map traffic, gaps, owners, access, storage, and recovery.
Validate a controlled segment with safe test traffic and role checks.
Review paths, sensor health, loss, storage, access, and network changes.
Handover checks
Keep evidence with the network-security record.
Coverage map
Collection points and visibility gaps are documented.
Safe observation
A controlled event is visible through the analyst path.
Capacity evidence
Traffic and retention assumptions are measured.
