Security Onion security hardening starts with the monitoring system itself
Hardening Security Onion comes before trusting it with evidence. The platform combines the Security Onion Console, Elasticsearch, Suricata, Zeek, Elastic Fleet agents and Suricata full packet capture in one free, open Linux distribution from Security Onion Solutions. Those components hold full packet data, alert content and analyst credentials in one place. A compromise of a manager, a search node or a sensor therefore exposes sensitive investigation material, and it can also reveal what your defenders can and cannot see. Before the grid is declared ready, the security team should treat the monitoring system as a production asset with its own threat model, change control and configuration evidence. Decide now who owns that review and when it happens.
The hardening work covers several layers. At the network level, host firewall rules and host group rules should limit which systems can reach the Console, Elasticsearch and the traffic between nodes, and each rule should be documented against a node role. At the access level, console access control decides who can sign in, what analysts can change and how privileged accounts are created and removed. Some controls sit in the paid Pro edition: LUKS data-at-rest encryption, FIPS mode, OS STIG compliance and OIDC single sign-on. Air-gapped deployments need a controlled path for install media, packages and rule updates. Packet data protection covers where captured traffic is stored, who can query it and how long it stays. Confirm each item against the current documentation before writing it into a plan.
What makes this harder than it looks is the distributed design. Security Onion's recommended production layout separates a manager node, sensor nodes and search nodes, and those nodes depend on each other. A firewall rule that is correct for one role can block ingestion or search elsewhere. The architecture documentation notes that search nodes stop indexing when they cannot reach the manager, so a rule mistake can look like a platform outage. Pro-only options add a second dimension. Teams on the free edition rely on operating system controls for disk encryption, FIPS posture and STIG alignment, so those controls need their own build, verification and drift checks. Validate every change on a grid that matches production, and record the result before it goes live.
Licensing belongs in this review as well. The Security Onion repository is licensed under the Elastic License 2.0, which is source-available and is not an OSI-approved open-source license. Legal and procurement teams should read the license terms against how the organization plans to use, modify and operate the software, and should not assume that open-source norms apply. Pro is a separate paid edition sold on 1 to 5 year terms, so choosing it is also a procurement decision. Before the design review, produce three things: a list of exposed ports and the rules that govern them, an inventory of Console accounts and roles, and a written decision on which controls will come from Pro and which from the operating system.
Which Security Onion parts need hardening
A Distributed Security Onion grid spreads the work across a manager, sensors and search nodes, and each part is reachable from a different set of people and networks. Hardening starts by mapping which surfaces analysts, sensors and update paths can reach, then treating the most exposed and most valuable components first.
Manager node
The manager coordinates the grid, hosts the control plane and holds the configuration that every other node depends on. Per the Security Onion architecture docs, if the manager goes down, search nodes stop indexing because they cannot reach Redis. Check which administrative paths reach it, restrict SSH and management access to named admin networks, and confirm how it is patched during updates.
Security Onion Console
The Console is the web interface analysts use to hunt, triage alerts and manage detections, so it is the main place where user activity meets the platform. Review how accounts are created and removed, which roles can edit detections, and where the Console is exposed. Confirm with the vendor which access controls are available in the free edition and which require Security Onion Pro.
Search nodes
Search nodes hold indexed events and serve queries from analysts and the Console. Their hardening work covers storage permissions, which networks can query them and how they receive data from the manager and sensors. Plan the firewall rules between search nodes, the manager and analyst subnets so that only required ports are open.
Elasticsearch
Elasticsearch stores the events, alerts and metadata that the grid produces, so exposed or misconfigured indices create a direct data exposure risk. Review its authentication, transport and HTTP settings, and confirm that it is not reachable from outside the management network. Ask the vendor how Elasticsearch is configured in the release you deploy.
Sensor nodes and capture
Sensors sit on monitored network segments, run Zeek and Suricata, and hold full packet capture. They see hostile traffic by design, so they should accept almost no inbound connections and should send data only to the manager and search nodes. Confirm how sniffing interfaces are isolated from management interfaces and who can read captured packet data on disk.
Elastic Fleet agents and host OS
Elastic Fleet agents collect logs from endpoints and other systems, and each agent holds credentials that can reach the grid. Version 3 runs only on Oracle Linux 9, so the host operating system needs its own baseline covering packages, SSH, time sync, audit logging and disk encryption choices. Confirm agent enrollment controls and the update path for each host before go-live.
Security Onion security hardening choices and their trade-offs
This table compares the main hardening choices for a Security Onion grid, the free edition option against the Pro option, and what each one makes harder to run day to day. Read each row for the decision, when it fits and the operational load it adds. The main takeaway is that Pro controls shift work toward key management, identity integration and assessor evidence, so the choice should follow your access, encryption and accreditation requirements.
| Decision | When it fits | What it costs operationally |
|---|---|---|
| Free edition local console accounts versus Pro OIDC single sign-on | Free edition fits small teams with a few named analysts where local accounts are acceptable under your policy. Pro OIDC fits organizations that require central identity, joiner and leaver control and role assignment through an existing provider. | Local accounts mean password lifecycle, removal of departed analysts and manual access reviews on each grid. OIDC moves authentication to your identity provider, so you must maintain client configuration, group-to-role mapping and provider outage procedures. Confirm the supported providers with Security Onion Solutions before design. |
| OS-level disk encryption versus Pro LUKS data-at-rest encryption | OS-level encryption fits when your platform team already standardizes full-disk encryption on Oracle Linux 9 hosts. Pro LUKS fits when the product itself must provide the encryption layer and you want it managed as part of the Security Onion build. | OS-level encryption adds passphrase or key handling at boot, which affects unattended reboots and remote recovery. LUKS adds key custody, backup of key material and a tested recovery path, and a lost key can make captured data and indexes unreadable. Ask who holds the keys and how rotation is performed. |
| Standard mode versus Pro FIPS mode and OS STIG compliance | Standard mode fits environments without a federal or contractual cryptographic module requirement. FIPS mode and STIG alignment fit public sector, defense-adjacent and regulated environments that must show a configured baseline to an assessor. | FIPS and STIG settings can break agents, packages or integrations that were tested only in standard mode, so every upgrade needs regression testing. Evidence collection becomes recurring work: baseline scans, exception records and proof that settings remain applied after soup updates. Confirm the STIG version and scope with the vendor. |
| Online updates versus airgap installs with soup using newer ISO media | Online updates fit grids with controlled outbound access to package sources and rule feeds. Airgap installs with soup fit networks without internet access, where updates arrive as newer ISO media that is verified and staged inside the enclave. | Airgap operation adds an offline patch cycle: media must be obtained, checked, transferred and tested before rules and packages reach production. Rule and component currency can lag behind online deployments, so you need a documented schedule and a change record for each import. Confirm the airgap update procedure for your target version. |
| Cloud marketplace images versus on-premises ISO | Marketplace images fit teams that deploy into AWS, Azure or Google Cloud and want the platform built from a provider catalog. The ISO fits data centers, air-gapped sites and environments where the hardened build must follow your own image pipeline. | Marketplace images tie hardening to the provider's image lifecycle, the cloud account's network and key services, and provider-side patch timing, which your change process must track. ISO installs put OS build, disk layout, kernel hardening and hypervisor configuration on your team, so you must keep a golden build record and rebuild evidence for each grid. |
| Packet capture and console exposure controls | Restricting console access and capture retrieval fits every deployment, because captured traffic can contain credentials and business data. Scope the controls to the manager, search and sensor roles that hold or serve that data. | Host group rules, firewall policy and restricted capture export must be reviewed whenever analysts, sensors or integrations change. Access logs and firewall change records become the evidence an assessor asks for, and they require someone to review them on a set schedule. |
Security Onion security hardening sequence from install to handover
This sequence takes a Security Onion grid from a planned install to a documented handover with network exposure, console access, disk encryption, update path and packet capture protection each verified. Each step ends with a check that the reader can repeat, so the handover record shows what was tested rather than what was intended.
Confirm deployment type and hardware
Confirm the deployment type (Import, Evaluation, Standalone or Distributed) and the design for production, which the architecture docs recommend as Distributed with a manager, sensors and search nodes. Check every node against the hardware docs for x86-64 processors, core count, memory, storage and NIC count for its role. For 3.x, confirm the operating system is Oracle Linux 9, because 3.0.0 supports no other distribution. The output is a signed-off hardware sheet per node. The check is that each host's recorded specs match the minimums for its role, with any gap raised before installation.
Decide network placement for each node
Assign the manager, search, receiver and sensor nodes to network segments before any firewall rules are written. Sensors belong on the monitored network with a dedicated sniffing interface, while the manager and search nodes belong on a management segment that analysts and approved administrators can reach. Record which subnets are approved to reach each management port. The output is a placement diagram tied to the hardware sheet. The check is that a test host in an unapproved subnet cannot reach the manager's management interface, which should fail on a port scan.
Apply host firewall and host group rules
Write host firewall rules for each node so it accepts only the traffic its role requires, such as sensor-to-manager communication and analyst access to the Console. Use the Security Onion host group settings where your version supports them, and confirm in the release documentation which rules the installer manages and which you maintain. Keep the rule set in version control. The check is a port scan run from an unapproved subnet against each node, which should show only the closed or filtered result, and a scan from an approved subnet, which should show only the expected services.
Restrict console access and assign analyst roles
Remove or disable default and shared accounts, then create named Console accounts with the least role each analyst needs. In the free edition, access uses local console accounts, so set password policy and lockout behavior in line with your identity standards. If you need OIDC single sign-on, that is a Pro feature to confirm in your quote. The output is an account register with role assignments reviewed by the owner. The check is that a deliberately locked test account is rejected at login, and that a read-only analyst cannot reach administrative pages.
Decide and apply disk encryption
Choose between LUKS data-at-rest encryption, which the Security Onion Pro page lists as a Pro feature, and an OS-level encryption method that you have confirmed with the distribution vendor and your own key management process. Record who holds the passphrases or keys, how they are recovered, and how a rebuilt node will be unlocked. Apply the method to the data volumes holding indexed events and captured packets. The check is that the encrypted volumes show as encrypted in the storage listing, and that a live boot without the key cannot read event or capture data.
Select FIPS and STIG posture where required
Decide whether your assessment requires FIPS mode or an operating system STIG baseline. The Security Onion Pro page lists FIPS mode and OS STIG compliance as Pro features, so confirm availability and scope with the vendor before you rely on them. Map each required control to the evidence it will produce, such as the kernel FIPS flag and a benchmark scan report. Note that DeployOpen prepares controls and evidence but does not issue certifications. The check is that the kernel reports FIPS enabled on each node where it is required, and that the benchmark scan output is saved with the handover record.
Plan the airgap or online update path
Choose whether nodes will update from the internet or from ISO media in airgap mode. The airgap docs state that the ISO carries packages and NIDS, YARA and Sigma rules, and that the soup tool updates from newer ISO media. Document who approves media, how it is transferred and verified, and how often rule and package updates are applied on a matching test grid before production. The check is a test update run in your chosen mode that completes on a non-production grid, with the resulting version and rule set recorded and no outbound connection attempts from production nodes.
Protect packet capture storage and retention
Suricata now provides full packet capture in 3.x, replacing Stenographer, so treat the capture store as sensitive data. Set the capture location on encrypted storage, restrict read access to the service account and approved analysts, and set a retention period that your policy supports. Confirm disk-full behavior so capture cannot silently stop or overwrite evidence without an alert. The output is a retention and access statement for the capture store. The check is that a non-approved local account cannot read the capture directory, and that a test alert fires when storage reaches the threshold you configured.
Record the configuration for handover
Compile one handover record covering the hardware sheet, placement diagram, firewall and host group rules, account register, encryption method and key custody, FIPS and STIG decisions, update path, and capture retention settings. Store configuration files and the scan results in version control with dated entries. The record is complete when the operations owner has reviewed it and signed for each item. The check is that a second engineer can rebuild one node from the record alone and reproduce the port scan and login results from the earlier steps.
What drives hardening effort and cost in a Security Onion grid
This table lists the main drivers of hardening work for a Security Onion grid, how each one changes effort, and how to keep it manageable. Read the rows as a checklist for scoping a quote, and ask for each driver to be stated as a separate line item. The main takeaway is that most of the effort sits in one-time design and evidence work, while recurring effort depends on how many roles, accounts and test grids you carry.
| Driver | Effect on effort | How to keep it down |
|---|---|---|
| Node count across manager, search and sensor roles | Each node needs its own firewall rules, host group settings, patch path and evidence. Search nodes lose indexing when they cannot reach the manager, so manager reachability rules need extra review. | Standardize node builds and keep role-specific rules in one reviewed policy. Confirm the reference architecture with Security Onion documentation before adding nodes. |
| Number of analyst accounts and identity provider integration | Local console accounts need individual access reviews. Single sign-on with OIDC is a Security Onion Pro feature, so confirm entitlement and role mapping before design starts. | Limit console roles to named duties. Use group-based role assignment where your identity provider supports it, and confirm the Pro entitlement for SSO first. |
| Compliance requirements such as FIPS or STIG evidence | FIPS mode and OS STIG compliance are Security Onion Pro features. Each control needs configuration settings, test results and evidence captured before and after changes. | Decide early which controls are in scope, and map them to your assessor's requirements. Ask DeployOpen to prepare evidence, while independent auditors issue any assessment outcome. |
| Airgap update logistics | Airgap installs rely on newer ISO media and the soup tool for updates, so each update needs media transfer, verification and a change record inside the isolated network. | Agree a fixed media cadence with the owner of the transfer process. Keep a rollback plan and a matching test grid before each update window. |
| Packet capture volume and retention | Full packet capture in Suricata grows with link speed and retention period. Higher volume raises storage sizing, encryption workload, access control scope and the data handling rules that apply to captured content. | Set retention by documented need, limit capture to segments that justify it, and confirm sizing with the hardware documentation for your link speed. |
| Number of test grids needed to validate changes | Firewall, encryption, FIPS and STIG changes can break ingestion or upgrades, so each change needs a comparable test environment. Fewer test grids usually means more risk on production. | Keep one test grid that matches production in OS, role layout and version. Scale test effort to the changes in each cycle rather than maintaining several copies. |
| One-time work: baseline, firewall design, encryption setup, documentation | Front-loaded work covering the hardened baseline, host group firewall design, LUKS encryption where Pro is licensed, and the operating runbook. It is paid once but sets the scope of everything after it. | Write the scope in a fixed-scope agreement with named deliverables. Ask each quote to separate baseline, firewall, encryption and documentation lines. |
| Recurring work: rule reviews, patch cycles, access reviews | Firewall and detection rule reviews, operating system and Security Onion patch testing, and periodic account reviews repeat for the life of the grid. Frequency depends on your change policy and assessment cycle. | Set review frequencies in the runbook, automate reporting where possible, and decide whether this work stays in-house or moves to a support retainer. Ask what each retainer covers in writing. |
How hardening changes by deployment model
A standalone deployment runs every Security Onion role on a single node: the Console, Elasticsearch, Suricata, Zeek, Elastic Fleet and full packet capture all share one host. Because there are no separate roles to isolate, the host itself is the main control boundary, so operating system hardening and access control on that one machine carry more weight than they would in a distributed grid. Security Onion's own documentation positions standalone as a fit for smaller environments and evaluation, while distributed is the recommended production design.
What to plan for:
- Host controls: Restrict local and SSH access, apply the operating system baseline you use elsewhere, and limit which administrators can reach the Console.
- Console access: Local console accounts are the only option in the free edition, so define account ownership, password policy and removal steps before go-live.
- Sensor interfaces: Keep monitoring interfaces without IP addresses and out of management paths, because one host both captures traffic and serves the Console.
- Packet capture storage: Full packet data lives on the same disks as indexed data, so protect and restrict the capture directory as sensitive material.
- Failure impact: A single host outage stops detection and investigation together, so document a rebuild path and backup approach.
Confirm with Security Onion Solutions which host hardening steps the current release expects on a single node before you apply your own baseline.
A distributed deployment separates a manager node, one or more sensor nodes and one or more search nodes. Hardening here is mostly about the communication paths between roles, since each role trusts the others to carry traffic and coordination data. The Security Onion architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis. That behavior shapes both your firewall rules and your failure planning.
What to plan for:
- Manager reachability: Allow only the sensor, search and administrative flows the architecture requires between the manager and each node, and deny everything else by default.
- Search node dependency: Treat loss of manager connectivity as an indexing outage, not just a console outage, and alert on it.
- Receiver nodes: The architecture docs describe receiver nodes for pipeline redundancy and load balancing when the manager is down, so decide whether that design fits your recovery targets.
- Segmentation: Place sensors, the manager and search nodes in zones that match their trust levels, and log administrative sessions to each.
- Node sizing: Undersized search nodes fail in ways that look like security events, so monitor resource use alongside security alerts.
Confirm the exact ports and protocols with the current architecture documentation for your release before writing firewall rules.
Security Onion supports full installs on networks without internet access. The ISO carries the packages and the NIDS, YARA and Sigma rules needed for the install, and the soup update tool can update from newer ISO media in airgap mode. Hardening in this model centers on controlling what enters the network, verifying media, and keeping rule content current without outbound connections.
What to plan for:
- Media control: Define who may bring ISO media across the boundary, how it is checked before use, and where copies are stored.
- Rule updates: Detection content only changes when newer media is imported, so set a cadence and record which rule versions each grid runs.
- Update path: Use soup from newer ISO media for both packages and rules, and test each media set on a matching lab grid first.
- No external dependencies: Confirm that nothing in your Console, agent or logging configuration tries to reach the internet, and document the exceptions.
- Access to packet data: Because updates and analysis happen inside a closed network, restrict who can export captured traffic to removable media.
Confirm with Security Onion Solutions which airgap media sets are published for your release and how the rule content inside each set is versioned.
Security Onion is available in the AWS, Azure and Google Cloud marketplaces alongside the ISO for on-premises installs. In a cloud deployment, much of the network boundary is defined outside the operating system, in security groups or network security rules, and in the account that owns the instances. Hardening therefore covers both the instance and the cloud control plane that governs it.
What to plan for:
- Security groups: Limit inbound access to the Console and administrative ports to known administrator networks, and restrict node-to-node traffic to the flows the grid needs.
- Sensor traffic: Confirm how mirrored or captured traffic reaches sensors in your cloud network design, since cloud networks do not provide physical span ports.
- Account controls: Restrict who can create, modify or delete instances, security groups and storage, and log those actions in the cloud provider's audit service.
- Storage encryption: Review how disks and snapshots holding indexed and captured data are encrypted and who can access snapshots.
- Marketplace images: Record the image version you launch and plan how you will apply later updates.
Confirm the cloud-specific hardening steps for each provider with the Security Onion vendor, since marketplace images and provider features change.
How to harden Security Onion console access, packet data and secrets
Security Onion holds a detailed record of your network, so the console, the management interfaces, the packet store and the credentials behind them all need controls. The cards below cover each area in the order a hardening pass usually works through them, and note where the Pro edition changes the options.
Control console accounts
The free edition relies on local Console accounts, so the first task is to inventory who holds one, assign each analyst the role their work needs, and remove accounts for people who have left or changed teams. OIDC single sign-on is a Pro feature, so if your identity provider must govern access, confirm that requirement before you plan the rollout. Review the account list on a fixed schedule.
Restrict host firewall rules
Limit which networks and hosts can reach the manager and sensor management interfaces, and keep those paths separate from the sniffing interfaces that receive mirrored traffic. Build host group rules from a list of administrator workstations and jump hosts rather than broad internal ranges. Test each rule from an allowed and a blocked source before you treat the boundary as enforced.
Protect packet data at rest
Full packet capture stores raw traffic that can include credentials, session content and personal data. LUKS data-at-rest encryption is a Pro feature, while encryption in the free edition depends on the operating system disk encryption method your team selects, which you must confirm for your release. Decide the storage location, the disk layout and who can mount or read the capture volumes.
Secure packet capture backups
Backups of search and capture data copy the same sensitive content to another location, so they need the same access limits and encryption as the source. Record where each backup goes, who can restore it, and how restores are logged. Packet captures can contain sensitive content, so set access limits that match the data classification your organization assigns to that traffic.
Handle credentials and API keys
Service passwords, Elastic Fleet enrollment material, notification integration keys and any API tokens are the paths into the grid. Store them in a managed secrets location instead of configuration files or shared notes, restrict who can read them, and plan rotation with a record of when each credential last changed. Confirm with Security Onion which secrets the installer generates and which you must replace.
Verify the update chain
Before you apply an update, confirm that the ISO media or update package you use is the signed release you intended to download, and check the checksum against the published value. Use the soup process from matching media for both connected and airgapped grids, and record the version before and after each change. Test the verification steps on a non-production grid first.
How to test that Security Onion hardening works and fails safely
Each hardening control needs a test that could fail, and the first set covers reachability and access. Scan every node from outside its approved network, using a host that the firewall rules and host group definitions do not trust, then compare the open ports with what your design document says each node should expose. Run the same scan from inside the approved group to confirm that the expected paths still work, because a rule set that blocks everything passes the outside scan and still breaks the grid. Save the output for each node so you can compare it after every change. Then attempt console login with an account that is not on the approved list and with an account that has been disabled. Both should be refused, and both attempts should appear in the logs you collect. Confirm which login path your edition uses, since local console accounts in the free edition are handled differently from OIDC single sign-on in Pro.
Next, test the analyst roles by signing in as each role and attempting the actions it should not have. An analyst who should only read detections should fail when trying to modify, suppress or set thresholds on a NIDS rule in the Detections interface, which is where NIDS, Sigma and YARA rules are changed. Check that a role without a data scope cannot return events outside that scope. For disk encryption, if you use the Pro LUKS option, reboot a test node and confirm the data volume stays locked until the unlock method is supplied. Then run the lost disk case: remove a drive from a test node or copy its disk image, and attempt to read the data without the key. Ask the vendor to confirm the recovery procedure for your setup before you rely on it, because the unlock and recovery steps depend on how the volume was built.
The fail-safe checks matter more than the normal path. Stop the manager on a test grid and observe what the search nodes do. The architecture documentation states that search nodes stop indexing when they cannot reach Redis, so the questions are whether they stop cleanly, whether sensors keep capturing to local storage during the outage, and whether the backlog reaches the search nodes after the manager returns. Restart the manager and confirm that ingest recovers without manual re-pointing of sensors or receivers. Next, make the identity provider unreachable in a Pro test environment and see how the console behaves. Confirm whether a break-glass path exists, whether it is limited to named emergency accounts, and whether its use is logged. Finally, apply a deliberately wrong firewall rule to one host group and check that the mistake is visible in your monitoring and that you can reverse it from a documented procedure.
The airgap and packet data checks come last. Build a test node from the ISO on a network with no internet route, confirm that the installation completes, and then run the soup update from a newer ISO copied onto the isolated network. Verify that the update finishes without any outbound connection and that the detection rules and packages on the node match the new media. For full packet capture, confirm where Suricata writes captured data, who can read that location, and whether it sits under the same encryption and access controls as your event data. Ask the vendor to confirm how long captured data is kept and how it is purged, and check that behavior on your own test node instead of assuming the default.
What to monitor, back up, patch and document after hardening
This table lists the recurring tasks that keep a hardened Security Onion grid defensible, with the action and review trigger for each. Read each row as an owner assignment, since the trigger matters as much as the task, so set cadences in your change, patch and access policies. The main takeaway is that your version and operating system path determines which hardening steps still apply.
| Area | What to do | How often to review |
|---|---|---|
| Console and access logs | Forward Console authentication, admin and detection change events to your central log store. Confirm which Security Onion logs are included and how long they are retained. | After each change window and during access reviews |
| Firewall rule drift | Compare host group and firewall rules against the hardening baseline. Investigate any rule added outside an approved change record. | After every change, and on the schedule your change policy sets |
| Account and role reviews | Confirm each Console account maps to a current role and remove unused local accounts. Pro SSO users follow the identity provider's lifecycle controls. | At your access review cycle and whenever staff change roles |
| OS and Security Onion patching with soup | Apply OS and Security Onion updates with soup on a matching test grid first. Record component versions and rule sets after each run. | Per your patch policy and each new release or security advisory |
| Airgap media refresh | For airgapped grids, obtain newer ISO media and update with soup in airgap mode. Verify media checksums before transfer into the enclave. | When new media is released and before each planned patch window |
| Configuration and key backup with restore testing | Back up configuration and any LUKS or other encryption key material. Store keys separately from data backups and test restores on a non-production system. | Back up after each change, and test restores on a set schedule |
| Packet capture retention | Set Suricata full packet capture retention to match your data handling policy. Confirm storage thresholds so capture loss is detected, not silent. | At each storage capacity check and when sensor load or retention changes |
| Hardening baseline document | Record approved settings, host group rules, accounts, versions and exceptions, each with an owner and a reason. Keep it aligned with the running grid. | On every approved change, and before any internal or external assessment |
| Version and end-of-life planning | Plan around 2.4 end of life on October 1, 2026 and 2.3 end of life on April 6, 2024. Version 3 supports only Oracle Linux 9, so the upgrade path changes hardening scope. | At each planning cycle and when the Security Onion EOL page or release notes change |
Security Onion hardening questions buyers ask before hiring help
Can Security Onion be hardened without buying Pro?
Yes, most hardening work sits outside Pro. Host firewall and host group rules, console access control, and the placement of sensors and search nodes on your network are configured in the free edition, so a team can reduce exposure without a paid license. Pro changes what you can show an assessor. It adds OIDC single sign-on, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, and professional support. Confirm exactly which settings your installed version exposes in the Security Onion documentation before you plan changes, because platform support and end-of-life dates differ between the 2.4 and 3.x lines.
What does Security Onion Pro add and when is it worth it?
Pro is a paid edition sold on 1 to 5 year terms. It adds OIDC single sign-on to the Console, LUKS encryption of stored data, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant, and professional support. It is worth evaluating when a written requirement points to one of those features, such as central identity enforcement, encryption of data at rest, a FIPS or STIG baseline from an assessor, or vendor support for a production grid. If none of those apply, the free edition with documented hardening may meet your need. Ask the vendor for current Pro pricing and terms, since DeployOpen does not set or publish that price.
How much extra work does hardening add to a deployment?
Hardening adds work in proportion to how many components you must change and how much evidence you must produce. The main drivers are the node roles in your design, since a standalone node is one target while a distributed grid with manager, sensor and search nodes is several. Other drivers include whether the grid runs connected or in airgap mode, the identity provider and role mapping you need, the number of controls named in your compliance baseline, and whether you have a test grid that matches production. Change windows, the number of analyst roles that need new access, and the documentation an assessor expects also add effort. No fixed figure applies across environments, so ask for a scope that lists each driver as a separate line.
Can our own team harden Security Onion internally?
Often yes, if your team already runs Linux hardening, host firewalls and identity administration, and can test changes without disrupting ingest. The gaps tend to appear in Security Onion specifics: how each setting behaves during upgrades, how the manager and search nodes depend on each other, and how a change on one node affects the rest of the grid. Version constraints also matter. Security Onion 3.0 supports only Oracle Linux 9. Plan a test grid, keep a written change record for each control, and assign one person to own the upgrade path. If those pieces are missing, a fixed-scope engagement can cover the gap while your team learns the platform.
What do you need from us to start hardening work?
Start with a network diagram that shows where the manager, search nodes and sensors sit, which VLANs carry management, capture and analyst traffic, and where firewalls and taps are placed. If you plan SSO, add identity provider details, including provider type, metadata and how groups map to analyst roles. Provide your compliance requirements, the control list your assessor will use, and any internal security baseline. You also need access to test nodes that mirror production, agreed change windows, and named owners who can approve changes. Confirm these inputs before kickoff so scoping does not stall on missing information.
How long does Security Onion hardening take to complete?
Scope drives the timing more than anything else. A single standalone node with a documented baseline takes less time than a distributed grid that also needs SSO, encryption, FIPS or STIG controls, a test grid and evidence collection. Other factors include how many systems need change approval, how many test rounds your team requires, and how quickly test nodes and access are provided. DeployOpen does not publish a fixed duration for this work. Most engagements are fixed-scope, so the timeline, deliverables and milestones are written into the scope before work starts, and the quote follows that written scope. Ask for dated milestones tied to each deliverable.
Can a partner prepare assessment evidence without issuing an audit report?
Yes. DeployOpen prepares systems, controls and evidence for compliance assessments. Typical evidence includes configuration records, firewall and host group rule exports, role and access lists, change records and test results, organized so an assessor can review them. DeployOpen does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that determination. Before work starts, ask your assessor which evidence formats and sampling approach they accept, and map each evidence item to the control it supports. That mapping is easy to skip when evidence is gathered after the fact, so build it into the scope from the start.
How DeployOpen works on this
DeployOpen scopes Security Onion hardening as a fixed-scope engagement inside your own infrastructure, covering the console, host firewall rules, access control and captured packet data. The work is agreed in writing before it starts, and ongoing support is available as a retainer afterward.
How we scope
- Confirm the deployment type, such as distributed with a manager, sensor and search nodes, and which hosts each hardening control applies to.
- Record which Security Onion Pro features are in or out of scope, including OIDC sign-on, LUKS, FIPS mode and OS STIG compliance.
- Agree whether the grid runs with internet access or as an airgap install, since rule and update handling differs.
How we build
- Write host group and firewall rules that limit which networks can reach the Console, manager and search nodes.
- Set console access control, including local accounts in the free edition or the agreed sign-on option in Pro.
- Configure protection for captured packet data and test that hardening changes do not stop ingestion or detection.
How we hand over
- Deliver a configuration record covering firewall and host group rules, console access settings and packet data handling.
- Provide test results showing which controls were checked, how they were checked, and any items left open.
- Walk your administrators through routine checks, change steps and the items that must be re-verified after each upgrade.
How we support
- Offer a retainer that re-checks hardening settings after upgrades, rule updates and node additions.
- Review changes to the scope in writing, with any added work priced from a revised quote.
- Coordinate with your own security team and any independent auditor when compliance evidence is needed.
