Security Onion upgrades and support services

What upgrades and support involve

A running Security Onion grid needs three kinds of ongoing work after the first build: platform upgrades run with soup, detection content updates, and checks that the grid still works afterward. Upgrades are triggered by new releases, such as 3.3.0, published September 11, 2026, and by end-of-life dates. Security Onion 2.3 reached end of life on April 6, 2024, and 2.4 reaches end of life on October 1, 2026, so teams still on 2.4 have a fixed deadline to plan around.

Rehearse each upgrade on a test grid that matches production in version, deployment type and node roles, so manager, sensor, search and receiver behavior can be compared before a change reaches live traffic. Detection content changes on its own cycle: NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka should be reviewed for modify, suppress and threshold changes that must survive the update. Confirm with your own environment which custom rules and tuning exist before the upgrade starts.

Airgapped grids depend on update media. The ISO carries packages and NIDS, YARA and Sigma rules, and soup updates from newer ISO media in airgap mode. Someone must obtain, verify and transfer that media on a schedule that matches the release plan. Ask who controls the transfer, how media are checked before import, and what the documented recovery path is if an update fails partway through.

Post-upgrade verification should confirm that the Console loads, Detections rules are present and alerting, Elastic Fleet agents check in, Suricata and Zeek are capturing on each sensor, and search nodes are indexing. The architecture documentation notes that search nodes stop indexing when they cannot reach the manager, so confirm manager connectivity first. Whether to run this loop in-house or buy a retainer depends mainly on the team's Linux and Security Onion skills and on how many nodes the grid has. A small standalone grid run by experienced staff can often be handled internally, while a distributed grid with several sensors and search nodes adds coordination work that a retainer can absorb.

What the work includes

Each engagement ends with upgrade records, a tested runbook, a maintenance calendar and handover notes. Support terms that come with Security Onion Pro are set by Security Onion Solutions and differ from the work listed here, so confirm them directly with the vendor.

Upgrade planning and release review

Review each Security Onion release note against your grid's deployment type, hardware and installed components before scheduling work. Confirm the target version and your end-of-life exposure, since 2.4 reaches end of life on October 1, 2026. Record which changes touch sensors, search nodes or the manager.

Matching test grid

Build or confirm a test grid that matches production in node roles, operating system version and sensor interfaces, so the upgrade is rehearsed on the same layout. Where a full copy is not practical, agree in writing which behaviors the smaller grid can prove and which must be checked in production. A grid with a different node count can hide ordering and dependency problems.

Staged soup upgrades with rollback points

Run soup in stages inside an agreed change window, with a rollback point captured on each node before its stage begins. Agree the node order in the runbook, keeping in mind that search nodes stop indexing if they cannot reach the manager's Redis service. Define the rollback procedure for each node type before the run starts.

Detection rule and component updates

Plan updates to NIDS rules in Suricata, Sigma rules in ElastAlert and YARA rules in Strelka on their own cycle, separate from platform upgrades. Review modified, suppressed and threshold-tuned rules against each update so local tuning survives the change. Test rule changes on the matching test grid before they reach production sensors.

Airgap update media handling

On networks without internet access, soup updates from newer ISO media, so the media must be obtained, verified and moved through your approved transfer process before the window opens. Confirm which packages and NIDS, YARA and Sigma rule sets the new ISO carries and whether they match the rules you run. Keep a dated media log for each node.

Post-upgrade checks and runbook

After each stage, check sensor capture and log flow, search node indexing and manager health before returning the grid to operations. Write these checks, the rollback steps and the escalation contacts into an operations runbook, then test that runbook on the matching test grid. Revise it with each release.

What drives effort and duration

This table lists the factors that change Security Onion upgrade effort and how to reduce each one, and no duration figures are supplied, so ask for a scoped timeline in writing.

Driver	Why it raises effort	How to reduce it
Node count and roles	Each manager, search, sensor and receiver node needs its own upgrade, configuration check and validation.	Confirm roles in writing and remove unused nodes so the grid matches the detection plan.
Distributed or standalone design	A distributed grid has more components and needs a set upgrade order across roles.	Document the upgrade order for each role before the window. Standalone nodes are simpler but offer no pipeline redundancy.
Matching test grid	Without a test grid, the first full run of the upgrade happens on production systems.	Build a test grid with the same roles, versions and rule sets, and run the upgrade there first.
Airgap or internet-connected update path	Airgap installs need new ISO media for each update, which adds transfer, verification and approval steps.	Confirm how media reaches the enclave and schedule imports with the security team in advance.
Custom Suricata, Sigma and YARA detections	Each custom rule, suppression and threshold must be checked for expected alert output after the upgrade.	Keep rules in version control and maintain an inventory of rule counts and owners before the upgrade.
Current version and distance from target	Older installs may need intermediate steps. Security Onion 2.4 reached end of life on October 1, 2026, per the EOL documentation.	Confirm the upgrade path from your installed version to the target release in writing before planning.
Oracle Linux 9 status	Version 3 supports only Oracle Linux 9. Other distributions need a fresh install, which adds migration work.	Confirm the operating system on every node early, and plan the packet capture change if moving from 2.4.
Change windows and approval steps	Approval gates, freeze periods and rollback sign-off add calendar time beyond the technical work.	Agree the window, rollback criteria and approvers at the start, and record them in the change ticket.
Pro features needing re-validation	OIDC single sign-on, FIPS mode and OS STIG compliance each need testing after an upgrade to confirm they still work.	Enable Pro features only where required, and list each one in the test plan with expected results.

Project phases and outputs

The sequence moves a Security Onion grid from a known version and inventory to a rehearsed, verified and repeatable upgrade cycle, with a written record at each step.

Inventory the grid and check versions
Record every manager, search, sensor and receiver node, its OS, Security Onion version, hardware, network interfaces and capture configuration, along with the current rule and component state. The output is an inventory sheet that the rest of the work is measured against. The step is done when each node is listed and the installed version is confirmed on the node itself, not only from memory or a dashboard.
Review release and end-of-life status
Compare the installed version with the current tagged release and the published end-of-life dates for each line. Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024, per the project's EOL documentation. Confirm the supported upgrade paths for your distribution, since 2.4 moves to 3 in place only on Oracle Linux 9. The output is a short release review that names the target version and any rebuild decision.
Build or validate the test grid
Stand up a test grid that matches production in topology, OS, Security Onion version, sensor placement type and integrations such as log sources and SSO. Where the production grid is air-gapped, confirm the test grid can take the same ISO media and rule set. The output is a validated test grid record listing any intentional differences. Ask your partner to explain every difference, because untested gaps are where upgrades fail.
Rehearse the upgrade and log findings
Run the full upgrade on the test grid using the same commands and order planned for production, including the soup update path. Record each error, manual step, timing observation and post-upgrade issue in a rehearsal report. The output is that report plus a revised runbook. The rehearsal is complete when a second run from the revised runbook finishes without unplanned manual intervention.
Execute the production change window
Agree a change window with the operations owners, confirm rollback criteria and backups, and capture the current state of each node. Upgrade in stages, running soup on the manager first and then the remaining nodes in the order the rehearsal established, with soup runs watched and logged at each stage. The output is a signed change record with start and end times, node-by-node results and any deviations from the runbook.
Verify ingest, detections and console access
Check that every sensor still sees traffic, that search nodes are indexing and that logs arrive from each configured source. Confirm that NIDS, Sigma and YARA detections load and fire against a known test event, that rule and component updates apply, and that analysts can sign in to the Console with the expected roles. The output is a verification checklist with evidence attached. Store it with the change record.
Set up the recurring update cycle
Define how the grid will receive rule updates, component updates and future releases, including who approves each cycle, where the test grid fits, how airgap media is delivered where applicable and how the change record is kept. The output is a written update runbook and a calendar of review points. Agree whether ongoing support is handled in-house, through a retainer or through Security Onion Pro support, and record that decision in the runbook.

Which parts teams keep and which they outsource

This table compares which Security Onion upgrade and support tasks your staff should own and which a partner can carry under a project or retainer, with the skills each task needs.

Task	Keep in-house	Outsource to a partner	Skills needed
Release tracking	A named owner reads release notes and end-of-life dates for your grid version	Watches new tagged releases and flags what each one changes for your build and upgrade plan	Linux administration, reading Security Onion release and end-of-life documentation
Test grid build	Approve test hardware, network placement and data sizing that match production	Builds a matching test grid on your chosen infrastructure and documents every difference from production	Linux administration, Elastic and Suricata knowledge, hypervisor or cloud access
Soup execution	Your staff run soup on production inside an approved change window	Prepares the run sheet, rehearses the upgrade on test and supports the production run	Linux administration, grid topology knowledge, change control with a rollback plan
Detections content updates	SOC analysts review rule changes, tuning and suppressions before they go live	Applies content updates on test, records what changed and drafts tuning proposals for review	SOC analyst review of Suricata, Sigma and YARA detections in the Detections interface
Airgap media transfer	Your security team controls approved update media, integrity checks and entry into the enclave	Prepares the update package and a transfer procedure for your security team to approve	Media handling policy, Linux administration, understanding of airgap update workflow
Verification	Staff confirm grid health, sensor traffic and alert flow after each upgrade	Runs scripted post-upgrade checks and records results against your written acceptance list	Elastic and Suricata knowledge, Linux administration, network visibility checks
Runbook writing	Owners keep runbooks current for your network, accounts and approval paths	Drafts upgrade, rollback and recovery runbooks from the procedure proven on test	Technical writing, Security Onion architecture knowledge, change control practice
On-call response	Your SOC or infrastructure on-call handles grid outages and alert pipeline failures	A retainer can cover response for severity levels and hours agreed in writing	Linux administration, Elastic troubleshooting, incident handling
Vendor escalation	Staff hold the support relationship and decide when to open a case with the vendor	Prepares diagnostics and case summaries for your team to submit, if the scope includes it	Log and diagnostic collection, knowledge of your Security Onion edition and support entitlements

What goes wrong and how to prevent it

Most upgrade problems on a Security Onion grid come from a small set of predictable causes. Each card names the check that catches the problem before analysts notice it.

Upgrading production untested

An upgrade that has never run on a grid built like yours can fail on the node roles, hardware or network paths that differ. Build a test grid with the same node types, Security Onion version and data sources, run the upgrade there first, and check the Console, sensor traffic and search results before touching production.

Skipping the manager-down check

When the manager is down, search nodes stop indexing because they cannot reach Redis on the manager, so events can queue without being searchable. Before and after each upgrade, confirm every search node is indexing and the manager services return to a healthy state. Receiver nodes add pipeline redundancy only if you designed them in beforehand.

Out-of-date versions and airgap media

Security Onion 2.4 reaches end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024, so a grid on either line stops receiving project fixes. In airgap sites, soup updates only from newer ISO media, so stale media leaves the grid behind. Check the end-of-life page and the date of your media at every planning cycle.

Detection updates that flood analysts

New NIDS, Sigma or YARA content can fire heavily on your traffic the day it is enabled. Stage updates on the test grid, compare alert volume against a baseline from production, and add suppressions or thresholds in the Detections interface before analysts see the new alerts. Name who approves enabling new rules.

Losing custom detection content

Custom Suricata, Sigma and YARA content, along with the tuning built on it, is your work and must survive an upgrade intact. Inventory and export it before the upgrade, then compare the rule set and suppressions afterward. Confirm with the vendor documentation how custom content is handled for your target version.

Pro SSO or FIPS settings broken

Pro features such as OIDC single sign-on, FIPS mode and STIG settings are configuration-heavy and can stop working after an upgrade or settings change. After each change, sign in through the identity provider with each analyst role, confirm FIPS and STIG settings match the approved state, and record the results as evidence for your change record.

How the work changes by starting point

Security Onion 2.4 reached end of life on October 1, 2026. A 2.4 grid on Oracle Linux 9 is the 2.4 starting point that can upgrade to version 3, but only after full packet capture moves from Stenographer to Suricata.

Packet capture: Plan the move from Stenographer to Suricata before the upgrade, and decide how existing captured data will be kept or retired.
Operating system: Confirm Oracle Linux 9 on every node, including sensors and search nodes.
Hardware: Compare each node against the version 3 minimums in the hardware documentation.
Testing: Rehearse the upgrade on a matching test grid before touching production.
Who does the work: Usually the internal platform or security engineering team, sometimes with a partner who runs the test grid and checks.

What the client needs to provide

Before a partner can scope a Security Onion upgration or support engagement, the client needs to hand over a small set of facts. The most useful starting point is an accurate node inventory: every manager, search, sensor and receiver node, with its current Security Onion version, operating system, hardware and role in the grid. Version drift between nodes is one of the first things that changes an upgrade plan, so confirm the versions on each node rather than relying on the last deployment record. Next, supply network diagrams that show how sensors send data to the manager and how analysts and nodes reach the console. The diagrams should mark each firewall, proxy and host group rule on those paths. Upgrades that look simple on paper often stall because a sensor cannot reach the manager after a change, and an accurate path map lets the scope list the specific checks to run before and after each step. Change windows and approvers matter as much as technical detail. Name the windows when each node can be taken out of service, who signs off each change, and who can call a rollback. Also state the update source: internet access to the upstream release channel, or ISO media for an airgapped grid, where the reader must confirm which newer ISO and rule set will be carried in.

Access is the next dependency. Confirm how the delivery team will reach the manager and each node through an approved path, such as a jump host or bastion, and which accounts and keys will be used. Where the grid runs in a segment without internet access, confirm how media is transferred and who handles it. A test grid or budget for one is the most direct way to reduce upgrade risk. Ask whether a matching test grid exists with the same deployment type and similar hardware, or whether the client will fund a temporary one. Also provide the list of custom detections, suppressions, thresholds and log sources, since these are the items most likely to break or need review after an update. Finally, decide retention and storage settings to be kept, and name owners for approvals, analyst review of detection changes and on-call cover during the change window. Named people shorten scoping because every open decision otherwise becomes a question that waits on someone who has not been identified yet.

Common questions about upgrades and support

How much does a Security Onion upgrade or support retainer cost?

DeployOpen does not publish a price list, so a quote follows from the written scope. One-time work includes inventory, building a test grid that matches production, rehearsing the upgrade, the production change window, validation and handover documentation. Recurring work under a retainer covers items such as rule updates, release review and scheduled upgrades. Costs rise with the number of manager, search and sensor nodes, airgapped installs, custom Suricata, Sigma and YARA content and the number of test cycles. Ask for a quote that lists deliverables, assumptions and exclusions.

How long does a Security Onion upgrade take?

This page does not give an upgrade duration, and the written scope sets it. Duration depends on the deployment type and node count, whether a 2.4 installation needs a rebuild or an in-place move to version 3, how much custom content must be retested, and how long your change windows and approvals take. Ask for a schedule tied to named milestones, and confirm the upgrade path in the Security Onion documentation and on your own test grid before you commit to a production date.

Can our own team upgrade Security Onion without a partner?

Yes, a capable internal team can upgrade Security Onion alone. The work needs Linux administration on the distribution you run, working knowledge of the Security Onion components and the soup update tool, the ability to build a test grid that matches production, and time to review release notes, test detections and plan rollback. The usual constraint is time for testing and scheduling more than command-line work. A partner adds planning, rehearsal and verification capacity, which matters most for large grids or teams with other duties.

What do we need to provide for an upgrade engagement?

Plan to provide administrative access to every grid node, the current configuration and custom detection content, a network map, and the change windows you can offer. You also need a test grid that matches production as closely as possible, a named owner who approves rollback, and sign-off from the teams that depend on alerts. For airgapped sites, provide the ISO media and rule packages you intend to load. Your analysts should also confirm after each step that detections still fire, since only they can judge that against your environment.

Does Security Onion Pro support replace a partner?

No, Pro support does not replace a partner, because the two cover different work. Security Onion Pro is a paid edition sold on 1 to 5 year terms that includes professional support from Security Onion Solutions, along with features such as OIDC single sign-on, FIPS mode and OS STIG compliance. That support addresses the product itself. A partner scope covers your environment, including planning, testing, customization, upgrades and operations. Confirm support terms, response expectations and exclusions directly with Security Onion Solutions.

Is Security Onion 3.3.0 the right target for our upgrade?

Version 3.3.0 is the latest tagged release on GitHub, published September 11, 2026, so it is a natural candidate to evaluate. Confirm that it is the right target by reading its release notes, checking that your operating system is supported (version 3.0.0 supports only Oracle Linux 9), testing it on a matching grid and verifying that your detections and integrations still work. The latest release does not automatically fit your schedule, so choose the target version after testing.

What should we do about Security Onion 2.4 end of life on October 1, 2026?

Plan the move before October 1, 2026, when 2.4 reaches end of life. If your 2.4 installation runs on Oracle Linux 9, it can upgrade to version 3 after you move full packet capture from Stenographer to Suricata. Installations on other distributions need a fresh install of version 3, so plan for rebuilding nodes and migrating configuration and detections. Version 2.3 already reached end of life on April 6, 2024, so check whether any older nodes remain in the grid. Start with an inventory of distributions, nodes and custom content.

How DeployOpen delivers upgrades and support

DeployOpen plans, rehearses and documents Security Onion upgrades inside infrastructure you control, including airgapped networks. Each upgrade and any ongoing support is agreed in writing before work starts.

How we scope

Inventory grid roles, deployment type and operating system on each node before choosing an upgrade path.
Agree the written scope for each upgrade, covering target version, nodes, test grid and handover documents.
Confirm whether the work is one-time, a retainer for ongoing support, or both before the engagement starts.

How we build

Stand up a matching test grid so each soup upgrade is rehearsed before it reaches live sensors and search nodes.
Test detections, dashboards and log sources on the test grid, and record which rule and component updates change behavior.
For airgapped grids, prepare newer ISO media and run soup in airgap mode from that media.

How we hand over

Document each upgrade with versions before and after, node order, checks run, rollback points and settings changed.
Give your team a runbook for routine rule and component updates, including who approves each change.
Walk your operators through the grid health checks to run after each upgrade window.

How we support

Cover rule and component update cycles on a retainer, with each update tested on the matching test grid first.
Plan a path off Security Onion 2.4 before its October 1, 2026 end-of-life date, including any move to version 3.
Agree in writing which tasks DeployOpen covers and which fall under Security Onion Pro professional support.

Security Onion upgrades and support