What a Security Onion implementation involves
Security Onion is a free and open Linux distribution for threat hunting, enterprise security monitoring and log management. It combines the Security Onion Console, Elasticsearch, Suricata, Zeek, Elastic Fleet agents and Suricata full packet capture. A production deployment is therefore a planning and build project, not a software install. The work covers where sensors sit and what they see, how the grid is laid out, how long data is kept, which endpoints and log sources send data in, and how detections are tuned so analysts see useful alerts from the first day.
Teams usually start this work for one of four reasons: a new monitoring program, a move off an end-of-life version, an audit finding that calls for network visibility or log retention, or a new SOC being built. The trigger shapes the scope. An audit finding may need evidence of coverage and retention within a fixed window, while a new SOC needs staffed workflows and a tuning backlog. Before design begins, confirm the target version. Security Onion 2.4 reached end of life on October 1, 2026, and the Oracle Linux 9 requirement in version 3 affects the operating system choice.
Security Onion documents four deployment types: Import, Evaluation, Standalone and Distributed. Distributed, with a manager node, one or more sensor nodes and one or more search nodes, is the recommended design for production. Standalone suits a single-site lab or small pilot, but it does not separate capture, indexing and management, so it rarely fits a production monitoring program. Choosing Distributed early sets the hardware count, network segmentation and tap plan that every later section depends on.
Most organizations split the work between an internal team and an outside partner. Internal teams with Linux, network and detection engineering skills can build a pilot themselves. Outside help is more common when the grid must go live on a fixed date, when sensor placement needs a network survey, or when detections must be tuned to a specific environment. Ask any partner to show the written scope for sensors, grid roles, retention and tuning, and state which of these the internal team will own after handover.
What the work includes
A fixed-scope Security Onion implementation usually produces the artifacts below. Several depend on your network diagrams, hardware and monitoring goals, so confirm those inputs before the scope is written.
Network placement design
A written map of where each sensor sees traffic, which taps or SPAN ports feed it, and which segments are covered or deliberately left out. It depends on your network diagrams, switch and firewall topology, and the traffic paths you want visibility into, such as east-west and egress. Ask for the design to be approved before hardware is ordered.
Node inventory by role
A list of every manager, search and sensor node with its role, CPU, memory, storage and NIC count, checked against the minimum hardware requirements for each role. Hardware you already own shapes this list, so confirm the servers, NICs and link speeds available before the inventory is final.
Built and verified grid
A distributed Security Onion grid installed on your chosen platform, with each node confirmed to be healthy and receiving traffic. Verification covers node connectivity and sensor data flow. Confirm which platform you will use (ISO on-premises, or a supported cloud marketplace image) and whether the environment is airgapped, since that changes the build steps.
Configured retention settings
Retention periods and storage allocations for logs, alerts and captured packets, set against the storage in your node inventory. Retention is the main driver of storage cost, so the agreed periods should be written next to the disk sizing. Confirm required retention with your security, legal and compliance owners before the build.
Enrolled Elastic Fleet agents
Elastic Fleet agents enrolled on the endpoints and log sources agreed in scope, with each source's data confirmed in the Console. Only the sources listed in the written scope are included. Ask for the source list, its owners, and any hosts that need special access or change windows.
Initial detection set and tuning baseline
An starting set of Suricata NIDS rules, Sigma rules and YARA rules enabled in the Detections interface, plus a recorded baseline of alert volume with the suppressions and thresholds applied. Rule choice depends on your threat model and the traffic you see. Ask for the baseline to be documented so later tuning can be measured against it.
Handover documentation
Runbooks covering the grid layout, node roles, retention settings, detection changes, access accounts, backup and upgrade steps, and the known limits of the design. Ask who receives the documentation, whether it is kept in your own repository, and how it is updated after upgrades or changes.
What drives cost and duration
This table lists the scope factors that most change the effort and recurring cost of a Security Onion grid, with guidance on how to keep each one under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Link speed and monitored segments | Higher throughput and more monitored segments need more sensors, more NICs and more capture storage, and each tap or SPAN feed adds cabling and validation work. | Confirm which segments carry the traffic you need to see, start with north-south and critical east-west links, and size sensors for measured peak throughput rather than nominal link speed. |
| Number of search nodes and retention | Search nodes hold indexed data, so retention length and daily volume set storage, memory and disk growth over time. | Define retention by data type, separate full packet capture from logs, and ask the vendor or partner to confirm sizing against your measured daily ingest. |
| Number of sites and airgapped networks | Each site adds sensors, connectivity and local operations, and airgapped installs require offline media and a controlled update process. | Consolidate sensors where network design allows, and confirm early whether any site needs airgap mode so update media and rule delivery are planned once. |
| Number of log sources and agents | Each log source needs parsing, field mapping and agent deployment and testing, and new sources add ongoing maintenance as products change. | Prioritize sources tied to detections you intend to run, and confirm which Elastic Fleet integrations your sources need before scoping. |
| Volume of detection tuning | Noisy Suricata, Sigma and YARA alerts consume analyst time, and suppression and threshold work grows with the number of rules enabled. | Enable a focused rule set first, review top alerters over an agreed period, and agree a tuning backlog with a fixed number of rules in scope. |
| Integration with existing SIEM or ticketing | Forwarding alerts to a current SIEM or ticketing system needs connectors, field mapping and testing of each handoff path. | List every downstream system and its expected data format in the scope, and limit the first phase to one or two integrations. |
| Edition choice (free versus Pro) | Pro adds OIDC single sign-on, FIPS mode, OS STIG compliance, LUKS encryption and professional support, each with its own configuration and validation effort. | Decide which Pro features are required by policy before scoping, and ask for the Pro subscription term and price in the written quote rather than assuming them. |
| Hardware minimums | The published minimums are floors for lab or small deployments, not sizing advice for production traffic or retention. | Ask for a sizing review based on your measured throughput, retention period and search load, and compare that result with the minimums. |
Implementation phases and outputs
The sequence moves from confirming where traffic can be seen to a handed-over grid that analysts have tested against real investigations.
Confirm traffic paths and tap options
We map the network segments you want visible, the paths east-west and egress traffic take, and whether each point supports a network tap or a SPAN port. Your network team confirms switch and firewall capabilities. The output is a sensor placement plan listing each capture point, its link speed and the access method, signed off in writing before design begins.
Design architecture and size nodes
We choose the deployment type for production, normally a distributed design with a manager, search nodes and sensor nodes, and size each role against the link speeds and retention targets from discovery. Hardware is checked against the vendor minimums and your own data volumes. The output is an architecture document with a node inventory, sizing rationale and a list of open questions for your team to confirm.
Build the test or staging grid
We install a grid that matches the production design on non-production hardware or cloud accounts, using the same OS, node roles and network paths where possible. Your team receives access and a short runbook. The check that closes this step is a working pipeline from a sample sensor to the console, confirmed by a documented test run.
Build production and place sensors
We deploy the production manager, search and sensor nodes and connect the agreed taps or SPAN feeds, following the change windows your team sets. We verify that traffic reaches each sensor and that packet capture writes to disk as designed. The output is a production grid with a validated sensor inventory and a record of each capture point's status.
Configure retention and agents
We set index and packet capture retention to the periods your policy defines, configure Elastic Fleet agents on the endpoints and servers in scope, and confirm log source integrations. Storage growth is measured over an agreed window. The output is a retention schedule, an agent deployment record and a storage forecast that your team can review.
Establish detection baseline and tuning
We enable the NIDS, Sigma and YARA rule sets, record which alerts fire during normal operations, and apply suppressions and thresholds for known benign traffic using the Detections interface. Each change is logged with a reason. The output is a documented baseline, a tuning log and a list of rules you chose to keep disabled and why.
Verify with analysts and hand over
Your analysts run agreed hunting and investigation scenarios against the grid, and we fix gaps in dashboards, searches and access roles they find. We then deliver operating documentation, backup and restore notes and training on the console. The closing output is a signed verification report and a handover package that names owners for ongoing rule, upgrade and capacity decisions.
What usually goes wrong
Most Security Onion grids that disappoint do not fail at install. They fail in placement, sizing, ownership and version choice, and each of these is cheaper to settle before hardware is ordered.
Sensors that only see north-south traffic
A sensor on the internet edge shows inbound and outbound flows but misses lateral movement between internal hosts. Before purchasing hardware, map which segments, VLANs and east-west paths each sensor will see. Confirm tap or SPAN coverage for each one, and ask the vendor or integrator to show that coverage in the written scope.
Storage sized below retention needs
Full packet capture and Elasticsearch indexes consume disk faster than many teams expect, and undersized storage cuts retention short without any warning in the console. Model daily ingest per sensor from your observed traffic, then multiply by the retention window your investigations require. Ask for that calculation in the quote.
Search indexing stops when the manager fails
The architecture docs state that if the manager goes down, search nodes stop indexing because they cannot reach Redis. A single-manager design therefore pauses investigation data during a manager outage. Decide whether receiver nodes for pipeline redundancy belong in scope, and document the recovery steps your team will follow.
Alert floods from untuned detections
Enabling every NIDS, Sigma and YARA rule on day one produces alert volume that analysts cannot triage. Plan a baseline period where noisy rules are reviewed and then suppressed or given thresholds in the Detections interface. Budget analyst time for this tuning as part of the rollout, not as an afterthought.
Unclear ownership of rules and tuning
When no named person approves changes to suppressions, thresholds and custom Sigma filters, tuning drifts and detections quietly stop matching what the organization needs. Assign owners for NIDS rules, Sigma rules and YARA rules before go-live. Record who approved each suppression and when it should be reviewed.
End-of-life version chosen as the base
Security Onion 2.3 reached end of life on April 6, 2024, and 2.4 reaches end of life on October 1, 2026. Building a new grid on either version creates a near-term migration project. Confirm the current supported release, its required operating system, and the upgrade path with the vendor before you commit to a base image.
One-time and recurring costs
This table separates the costs of building a Security Onion grid from the costs of running it, names who is paid in each case, and lists what to request in a quote.
| Cost component | Who is paid | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Scoping and grid design | DeployOpen or your architects | One-time | Sensor placement, node roles, retention and airgap needs drive effort. Ask for a written design with node list and assumptions. |
| Hardware or cloud instances | Hardware vendor, cloud provider or your procurement | One-time for hardware, recurring for cloud | Link speed, sensor count and retention set node sizes. Ask for the sizing basis, not only the instance list. |
| Build, installation and integration | DeployOpen or your platform team | One-time | Number of sensors, taps or SPAN changes, log sources and SSO setup. Ask for the build sequence and acceptance tests. |
| Initial detection tuning | DeployOpen or your SOC analysts | One-time, then ongoing | Noise levels in your traffic and the rule sets enabled. Ask how many tuning cycles are included. |
| Storage growth and retention | Storage vendor or cloud provider | Recurring | Packet capture and log volume grow with traffic. Ask for projected storage by retention period. |
| Hosting, power and network | Your data center or cloud provider | Recurring | Instance uptime, rack space and bandwidth for mirrored traffic. Confirm these with your infrastructure team. |
| Analyst and tuning upkeep | Your SOC staff | Recurring | Alert volume, new detections and suppressions. Estimate hours with your SOC lead. |
| Security Onion Pro subscription | Security Onion Solutions, on terms set by the vendor | Recurring, 1 to 5 year terms | Pro pricing is set by the vendor on the terms described on its Pro page. Confirm current pricing and term options directly. |
| Upgrades and ongoing support | DeployOpen retainer, Pro support or your team | Recurring | Upgrade frequency and test grid needs. Ask what the retainer covers versus Pro support. |
| Internal skills and training | Your staff time and training providers | Recurring | Staff turnover and the number of analysts who must operate the grid. Plan for cross-training. |
How the work changes by environment
A standalone pilot runs the full stack on one node. The Distributed design, which the architecture documentation recommends for production, splits that work across a manager, sensor nodes and search nodes, so the move is mainly re-scoping and re-placing components.
- Hardware: Each role has its own minimum sizing in the hardware documentation, so the pilot node is unlikely to be reused for a single role without checking it against those minimums.
- Sensor placement: Sensors move to the points where taps or SPAN feeds were validated during the pilot, which usually needs a network change window.
- Data and tuning: Confirm in writing whether pilot data, rules and tuning carry over, and who signs off the cutover.
- Dependencies: The manager becomes a central dependency, so the availability design needs planning before go-live.
Security Onion 3.0.0 supports only Oracle Linux 9, so a new build on that release has one operating system path. Builds on other distributions fall outside that support position, so the team should confirm the supported option in writing before buying hardware.
- Baseline reuse: An existing Oracle Linux 9 hardening baseline, patch standard and image pipeline can often be reused, subject to confirmation against the release notes.
- Packet capture: Version 3 uses Suricata for full packet capture in place of Stenographer, so storage and capture tuning from older builds need to be rechecked.
- Other distributions: Earlier releases on other distributions follow a fresh install path, so confirm the version and its support status before design begins.
- Effort driver: Teams that already run Oracle Linux 9 spend less time on OS preparation, while teams building that baseline from scratch add that time to the schedule.
Security Onion is offered in the AWS, Azure and Google Cloud marketplaces and as an ISO for on-premises installs. The software is the same product, but the surrounding work differs in network visibility, cost model and who operates the underlying hardware.
- Sensor visibility: Cloud sensors depend on how traffic is mirrored or routed inside the provider network, which is a separate design task from physical taps and SPAN ports.
- Sizing: The minimum hardware figures in the documentation still set the floor for instance size, storage and network interfaces, so confirm the chosen instance types meet them.
- Recurring costs: Compute, storage and data transfer are billed by the cloud provider each period, while the ISO path shifts recurring cost to hardware, data center space and refresh cycles.
- Image versions: Confirm how marketplace image versions are published and how they match the upgrade process and test grid your team runs.
On an airgapped network, the ISO carries both the platform and its detection content. Security Onion documents full installs without internet access, and its update tool can apply newer ISO media in airgap mode, so updates become a controlled media workflow.
- Content currency: NIDS, YARA and Sigma rules arrive with the media, so the age of each ISO sets how current detections are on day one.
- Transfer process: Plan how media is approved, checked and moved across the boundary, which usually involves security and change teams.
- Update cadence: Each update needs newer media, so schedule it as a planned task within your upgrade test cycle.
- Integrity checks: Confirm with your accreditation authority the method accepted for verifying media and packages after each import.
- Operations: Node sizing is unchanged, but the management path and jump hosts need design, because nodes cannot reach external repositories.
A team leaving another network security monitoring or SIEM tool brings existing detections, dashboards and analyst habits that will not map directly to the new platform. The install is usually the smaller share of effort, and content translation and parallel running take the most time.
- Detection inventory: List existing rules and alerts, then decide which move to Suricata, Sigma or YARA content and which retire, since the Detections interface manages each type differently.
- Parallel running: Plan a period where both tools see the same traffic, so analysts can compare alert volume and coverage before cutover.
- Log sources: Map each source to an Elastic agent integration or sensor feed, and identify which sources need new collection work.
- Analyst workflow: Retraining, runbooks and case handling in the Console often take longer than the installation.
- Migration path: If the source is Security Onion 2.4, the separate migration topic covers upgrade and rebuild options.
What you need to provide
Before any sizing or pricing work starts, the client supplies a set of inputs that determine the grid design, the hardware or cloud footprint and the effort. Most quotes change materially when these inputs change, so the scope document should record each one with an owner and a date. The items below are the ones that move the quote most. Network diagrams and link speeds. The diagrams show where traffic crosses segments, data centers, cloud VPCs and internet egress. Link speeds set the sensor count and interface sizing, because a sensor must keep up with peak traffic on the links it watches. Ask for measured peak throughput, not nominal link capacity, and confirm which segments carry encrypted or high-volume traffic.
Tap or switch access and capture locations. Each sensor needs a monitoring point, either a network tap, a SPAN or mirror port, or a virtual traffic mirror in cloud environments. Confirm who can install taps, whether change control permits switch configuration changes, and how many monitoring points are available at each site. Missing access usually adds sensors, cabling and site visits, which increase both the one-time work and the schedule.
Approved hardware or cloud accounts. Security Onion supports only x86-64 processors, and the documented minimums differ by role: standalone, manager, search and sensor nodes each have their own core, memory, storage and NIC requirements. Tell us whether hardware is purchased by you, already in inventory, or provisioned in an approved AWS, Azure or Google Cloud account. Procurement lead times and cloud account approvals often set the start date more than the build does.
Expected log sources, retention and packet data classification. List the firewalls, identity providers, endpoints and cloud logs you expect to onboard, along with required retention for alerts, logs and full packet capture. Retention is the largest driver of storage cost. Packet capture carries the most sensitive content, so the data classification decision determines encryption, access groups and whether captures may leave the site.
Named owners and change windows. Name one owner for detection tuning, one for analyst workflow and one for the change board. Detection tuning is ongoing work that the implementation does not finish, and unowned tuning is the most common cause of alert fatigue after go-live. Record the change windows for sensor deployment and any planned upgrade freezes, since these set the number of cutover attempts.
Edition decision. Decide between the free edition and Security Onion Pro before the build begins. Pro adds OIDC single sign-on, LUKS encryption, FIPS mode, OS STIG compliance and professional support, and it is sold on 1 to 5 year terms. Each of these changes the configuration, the test plan and the recurring license cost, so confirm the choice in writing. Ask the vendor for current Pro pricing directly.
Frequently asked questions
What drives the cost of a Security Onion deployment?
Scope drives most of the cost: how many sensors and taps you need, how many manager, search and sensor nodes the grid requires, and how long you keep data. Hardware or cloud instances for each node role are recurring costs, while design, installation, detection tuning and training are usually one-time work. Sensor placement matters because the number of network segments and link speeds determine how many sensors and how much packet storage you need. Ask for a written quote that lists each node role, its sizing basis, the retention period, and which items are one-time versus recurring.
How long does a Security Onion implementation take?
The timeline depends on the written scope, which is agreed before work starts, so the duration comes from that plan. The main drivers are the number of sensor sites, whether the network has taps or needs SPAN port configuration, the grid design (standalone, distributed or airgapped), how much detection tuning and dashboard work is included, and how quickly your team provides access, change windows and approvals. Ask for a schedule with milestones for each phase and a list of the client dependencies behind each one.
Can our own team deploy Security Onion without a partner?
Yes, a team with Linux, networking and security operations skills can install Security Onion itself, since the project is free and documented. The harder parts are sensor placement, sizing for link speed, distributed grid design, Suricata and Elastic tuning, and keeping upgrades tested. Plan for staff who can own the grid after go-live, including patching, rule updates and the soup upgrade process. A partner is useful when you want the design reviewed, the build delivered on a fixed scope, or the work completed on a set timeline.
Is the free edition of Security Onion enough for our team?
The free edition covers core monitoring, hunting and detection, so many teams can run it without a license fee. Security Onion Pro is a paid edition sold on 1 to 5 year terms that adds OIDC single sign-on, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. Choose Pro if your policy requires those controls or vendor support. Confirm current Pro pricing directly with Security Onion Solutions.
Can Security Onion run on an airgapped network?
Yes. Security Onion supports full installs on networks without internet access. The ISO carries the packages along with NIDS, YARA and Sigma rules, and the soup update tool can apply updates from newer ISO media in airgap mode. You still need to plan how new media is verified, transferred and approved, and how rule content is refreshed on a schedule your policy allows. Confirm the current airgap steps for your version in the vendor documentation before committing to a design.
What happens to the Security Onion grid after go-live?
After go-live, the grid needs ongoing operation: monitoring node health, applying upgrades with soup, updating rules, managing retention and reviewing alert noise. Architecture matters here, because if the manager goes down, search nodes stop indexing when they cannot reach Redis. Plan manager availability and receiver nodes for pipeline redundancy. Assign an owner for each task and test upgrades on a matching test grid first. Support can be handled in-house, through Pro support, or through a DeployOpen retainer scoped in writing.
How DeployOpen delivers Security Onion work
DeployOpen plans, implements, hardens, documents and supports Security Onion inside your own infrastructure, including cloud accounts, data centers or airgapped networks. Engagements start with a written, fixed scope so sensor placement, node sizing, retention and cost assumptions are agreed before any build begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope covers which network segments get sensors, taps or SPAN feeds, and where each sits in the grid.
- We size manager, search and sensor nodes against your traffic and retention targets, and state the assumptions behind each figure.
How we build
- Deployment type is chosen against your needs, with Distributed as the design usually compared for production grids.
- We install on the platform and hardware you provide, checking it against Security Onion's published minimum requirements.
- Detection content from the Detections interface (Suricata, Sigma and YARA) is configured and tuned, and tested against your traffic before go-live.
How we hand over
- You receive documentation covering the grid layout, node roles, retention settings and the sensor placement decisions made.
- Runbooks cover routine checks, rule tuning steps, and what to do when a manager or search node becomes unavailable.
- Your team is walked through the Console, the Detections interface and the upgrade procedure so they can operate the grid independently.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Upgrade planning covers version lifecycle dates, such as the end-of-life dates published for older releases, and a test grid where possible.
- Where you need Security Onion Pro features or professional support from the vendor, we confirm licensing and terms with you directly.
