Why network security monitoring for air-gapped networks is a different build
On an isolated enclave in critical infrastructure, a classified environment or an OT zone where no traffic may leave, the practical answer is Security Onion's ISO-based airgap mode as the main platform for a full network security monitoring stack, with Suricata and Zeek as the sensing engines. The build differs from a connected deployment in three places: software arrives on offline media rather than from package mirrors, rule sets are moved across the boundary by hand and verified, and every packet capture and log stays on local storage that you must size in advance. Security Onion's ISO carries packages and NIDS, YARA and Sigma rules, and its soup tool updates the platform from newer ISO media in airgap mode, so your change process for updates becomes a media transfer and integrity check process.
Two decisions need legal and procurement review before design starts. The Security Onion repository is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved open source, so your counsel should confirm that the terms fit your use, including any restrictions on offering it as a service. The paid Security Onion Pro edition adds features that matter in restricted networks, including LUKS data-at-rest encryption, FIPS mode, OS STIG compliance and OIDC single sign-on to the Console. Confirm with the vendor which of these your assessor or accreditation authority expects, and whether they must be present on day one or can follow a documented plan.
Plan the storage and the update path together. Packet capture and metadata accumulate on disk without any cloud tier to offload to, so retention periods, capture scope and disk capacity have to be set against the evidence your assessor needs. Ask your partner to document the sizing assumptions for each sensor, and to run a restore test from offline backup. Also confirm the hardware platform: Security Onion supports only x86-64 processors, and the minimum sensor specification is published in the hardware documentation. Build the offline update cycle, rule import procedure and retention schedule into the runbook before the first sensor goes live.
Which requirements shape an air-gapped monitoring build
This table maps the regulatory and standards requirements most likely to affect an isolated sensor build to what each one asks for and what it means offline. Which rows apply depends on your sector, so confirm scope with your compliance lead before designing storage, transfer and logging.
| Requirement | What it asks for | What it means for the offline build |
|---|---|---|
| 45 CFR 164.312 audit controls (HIPAA) | Record and examine activity in systems containing ePHI, plus unique user identification and transmission security | Packet capture that may hold ePHI needs encrypted local storage, sensor and analyst activity logged locally, and a retention plan that stays inside the enclave |
| 16 CFR 314.4 logging and encryption (FTC Safeguards Rule) | Monitor and log activity of authorized users, encrypt customer information in transit and at rest | Sensor, manager and search node logs must be kept on the isolated network, and disk encryption must cover capture and metadata stores |
| NERC CIP-005-7 interactive remote access (BES) | Interactive remote access to high and medium impact systems passes through an intermediate system with encryption and multi-factor authentication | Any vendor or engineer who updates or inspects sensors from outside the perimeter must use the approved intermediate system, and the monitoring build must not create an unmanaged remote path |
| NERC CIP-013-2 supply chain (vendor software integrity) | Procurement processes verify software integrity and authenticity of vendor software and patches | Every ISO, package and rule set carried across the gap needs recorded checksum or signature verification before import, with the transfer steps documented |
| Security Onion airgap update path (vendor guidance) | Full installs and updates run from newer ISO media in airgap mode | Schedule transfers as a controlled change: confirm the ISO source, verify it, apply it in a test enclave where possible, and keep the previous media for rollback |
| Sector applicability (all regimes) | Which laws and standards apply depends on the organization's sector, contracts and asset classification | Confirm with your compliance lead which rows apply before sizing storage, choosing encryption methods or writing the transfer procedure |
Which open source platforms fit an isolated network and why
Air-gapped monitoring turns every tool choice into a question about offline installs, update media and local storage. The options below differ mainly in how much they bundle, how they take updates across the boundary, and which operating system and license terms they carry.
Security Onion as a bundled platform
Security Onion combines Suricata, Zeek, Elasticsearch and Suricata-based full packet capture in one distribution, which reduces the number of components your team must integrate and patch on the isolated side. Its ISO carries packages along with NIDS, YARA and Sigma rules, and the soup tool updates from newer ISO media in airgap mode. Check that your hardware is x86-64, since the platform supports only that architecture, and that version 3.x runs on Oracle Linux 9. Confirm the Elastic License 2.0 terms with your legal team before you redistribute or embed the platform.
Suricata and Zeek as standalone sensors
Running Suricata and Zeek without Security Onion suits a team that already operates its own log pipeline and wants raw protocol logs and alerts in its own format. You take on the work of packaging both engines for offline install, staging rule sources such as Emerging Threats or custom signatures, and building storage and indexing locally. Both are open source, Suricata under GPL-2.0 and Zeek under a BSD-style license, which simplifies licensing review. Confirm which rule and script updates you can stage across the gap before you commit to this path.
Wazuh for host telemetry beside the sensors
Wazuh publishes an offline installation guide for systems without internet connectivity, which makes it a candidate for collecting host logs and file integrity data next to network sensors. Its vulnerability detection can use an offline vulnerability repository instead of the online threat intelligence service, so the feed you load must be refreshed by hand through the transfer process. Use it to correlate host events with network alerts, not to replace the sensors. Confirm which vulnerability content and agent versions your offline process will support before you plan the rollout.
Security Onion 2.x lifecycle risk
Security Onion 2.4 reached end of life on October 1, 2026, so existing 2.x sensors will stop receiving support updates. Installations on Oracle Linux 9 can upgrade to 3 after moving full packet capture from Stenographer to Suricata, while other distributions need a fresh install. Plan the migration window, the replacement hardware and the re-tuning of detections before the isolated zone falls out of support. Confirm the upgrade path with the vendor for your specific distribution and version.
Vault licensing for in-scope key material
If the isolated network also holds secrets, certificates or keys that protect sensor or log storage, the secrets platform choice affects licensing. HashiCorp Vault 1.15.0 and later uses the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. Compare it with open alternatives such as OpenBao, which is licensed under MPL-2.0, before you standardize. Confirm the license terms, support options and offline update process with the vendor for your version.
Offline Kubernetes and private registries
If your analysis or log stack runs on Kubernetes inside the isolated zone, the cluster must be built without internet access. The kubeadm tool can pre-fetch control plane images with kubeadm config images pull, and the --image-repository flag points kubeadm init at a private registry. Every image, chart and dependency must be mirrored and signed before it crosses the boundary, which also supports the software integrity checks that energy and critical infrastructure rules expect. Confirm which add-ons and operators your monitoring stack requires, since each one adds images to transfer.
How rule sets, packages and sensor data cross the gap
Every item that enters an isolated network should follow one one-way transfer pattern: Security Onion ISO media, Suricata and Zeek packages, and NIDS, Sigma and YARA rule sets are built or downloaded on a connected staging side, checked for integrity and authenticity, carried across on approved media, and imported on the isolated side. The staging side never receives data back from the sensors. Record each transfer with the hash of the artifact, the source, the person who verified it and the date, because NERC CIP-013-2 expects procurement processes to address verification of software integrity and authenticity, and the same record serves other frameworks. Confirm with your own security team which media types and transfer procedures are approved for your zone before the first import.
Security Onion updates on an air-gapped sensor run through the soup tool, which the Security Onion airgap documentation describes as updating from newer ISO media in airgap mode. Plan each upgrade as a scheduled change: stage the new ISO, verify it, apply it in a maintenance window and confirm that sensors, manager and search nodes return to a healthy state. Because the manager coordinates search nodes, a manager outage stops indexing, so sequence the manager first in a distributed deployment. Rule updates follow the same route. Use the Detections interface in the Security Onion Console to manage NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka. Every modify, suppress and threshold change to a NIDS rule should carry a reason, an owner and a reviewer, and your SIEM or case system should retain those records so tuning decisions can be reconstructed later.
How an air-gapped NSM rollout runs, phase by phase
The sequence moves a sensor design from paper into a validated, tuned and documented monitoring capability on an isolated network, with each phase producing an artifact the next phase depends on.
Scope enclaves and tap or span points
The DeployOpen team and the client's network engineers map each isolated enclave, its boundary devices and the links where traffic can be copied without disrupting operations. The team records which segments carry traffic that matters, which protocols they use and whether any link is too busy for a span. The output is an approved sensor placement diagram with a tap or span point named for each enclave. The step is complete when the asset owners of every enclave have signed off on where sensors connect.
Confirm hardware against Security Onion minimums
Before any hardware is ordered or staged, the team checks each planned node against the published Security Onion hardware requirements for standalone, manager, search and sensor roles. Security Onion supports only x86-64 processors, so the check confirms processor architecture first, then cores, memory, storage and network interface count per role. The client's procurement team confirms lead times and supply chain acceptance for each component. The output is a bill of materials that matches the documented minimums, and a sign-off that the hardware can be delivered into the isolated site.
Build the offline transfer and verification process
Every file that crosses the air gap, including ISO images, rule updates, packages and signatures, moves through a written transfer procedure. The procedure defines who may stage media, how each file is hashed and verified against a value obtained from the publisher, where media is scanned, and who approves entry. This is the control that supports software integrity checks expected under NERC CIP-013-2 where that standard applies. The output is an approved transfer procedure with a log template, tested once on a non-production media set before the first production transfer.
Install from ISO and validate sensor capture
The team installs the Security Onion ISO on the planned nodes using the airgap method, then selects the deployment type that fits the design, with Distributed being the recommended production layout. After installation, the team generates test traffic on each tap or span, confirms that Suricata alerts and Zeek logs are created, and checks that packet capture writes to disk as expected. Packet loss is measured at peak expected load on each sensor. The output is a validated sensor for each enclave with recorded test results and a known gap list.
Load and tune the rule baseline
The rule sets shipped on the ISO, including NIDS, YARA and Sigma content, are loaded into the Security Onion Console Detections interface. The analysts run the sensors for an agreed observation period, review the alerts that fire, and apply modify, suppress and threshold changes to NIDS rules, plus custom filters for Sigma rules, with each change documented. Changes that depend on the operational context of an enclave are reviewed by the asset owner. The output is a tuned rule baseline, a change log and a list of rules deliberately disabled with reasons.
Set local retention and storage sizing
Retention periods for full packet capture, Zeek logs and alert records are set according to the client's policy, the applicable regulation and the storage available on each node. Because there is no cloud tier, the team models storage growth from the measured capture rate during validation and confirms that the search node can hold the agreed retention. The team also sets the procedure for purging data at end of life. The output is a written retention schedule, a storage model tied to measured traffic, and a tested purge job that removes data as documented.
Test backup, restore and document the update cycle
The team restores a configuration backup and a sample of stored data to a clean node to prove that recovery works without internet access. It then documents the update cycle: how a newer ISO is staged, how the soup update tool is run in airgap mode, how rule updates are verified, and how the Security Onion release lifecycle is tracked so that end-of-life dates are not missed. The output is a tested restore record and an operations runbook that the client's own staff can follow, with a named owner for each recurring task.
How local storage sizing changes without cloud services
Full packet capture stores the raw traffic that Suricata sees on the sensor, so it is the largest storage driver in an air-gapped deployment. With no cloud tier to offload older data, every byte kept must fit on local disks inside the isolated network, and the retention window is bounded by that capacity. Packet capture is most useful when analysts need to reconstruct a session after an alert, but it also means the stored data itself needs protection.
- Link speed: Sustained throughput on the monitored link sets the write rate. Peak traffic matters more than averages, because a short burst can fill disks faster than the daily mean suggests.
- Traffic profile: Large file transfers, backups and video inflate capture volume far more than interactive protocols, so sizing should use measured traffic from the client's own segments.
- Retention period: The number of days the organization's policy requires packet data to be kept sets the total size. Investigation needs and any regulatory retention rules should be written down before the calculation.
- Disk layout: Plan for usable capacity after the operating system, indexes and reserved space, not raw disk size.
- Hardware minimums: The Security Onion hardware docs list minimums for standalone, manager, search and sensor nodes, but these are floors, not storage calculations.
Before committing hardware, confirm the sizing method with the vendor or partner and check that it is based on measured traffic rather than a generic figure.
Metadata-only retention keeps the protocol logs that Zeek produces, such as connection, DNS, HTTP, TLS and file summaries, and discards the packet payloads. The stored volume is far smaller than full capture, which makes longer retention practical on local disk. The trade-off is that analysts can see who talked to whom, when and how, but cannot replay the exact content of a session.
- Log volume: Zeek output depends on the protocols seen and the number of connections, so measure log growth on the client's segment rather than assuming a ratio.
- Indexing overhead: If logs are sent to a search node, the index adds disk use on top of the raw files, and that overhead should be included in the estimate.
- Retention period: Longer metadata retention is often feasible on the same disks, which can support historical hunts that full capture could not reach within the same space.
- Protocol selection: Enabling or disabling Zeek scripts changes the log set, so the storage estimate must match the configuration that will run in production.
- Limits: Metadata cannot confirm payload content, so organizations with strict evidence requirements may still need some packet data.
Ask the partner to show the measured log growth per day on a comparable segment and the disk impact of the planned index settings.
A hybrid design keeps full packet capture for a short, defined window and retains Zeek metadata for a longer period. This matches many isolated environments, where recent sessions need full detail for triage while older activity is still searchable for trend analysis and hunting. Because both data types share the same local disks, the design must allocate space explicitly so that one does not starve the other.
- Separate budgets: Set a capacity limit for packet capture and a separate limit for logs and indexes, so that a traffic spike cannot consume the metadata window.
- Capture window: The number of days of full packet data is a policy decision tied to incident response and the organization's own requirements.
- Rotation behavior: Confirm how the sensor overwrites old capture files when space runs out, and whether alerts are raised when that happens.
- Monitoring of disk use: Track disk consumption on every sensor and search node, since a full disk can stop capture or indexing without a visible error to analysts.
- Upgrade space: Leave headroom for ISO-based updates and rule set imports, which must be staged on the same isolated systems.
When reviewing the design, ask for written capacity limits per data type and the procedure for what happens when each limit is reached.
Deployment patterns for isolated enclaves
Air-gapped sensor deployments fall into a few recurring layouts, and the right one depends on how many enclaves you run, how much downtime the SOC can tolerate and whether each trust zone needs its own data. The cards below describe four patterns, the architecture trade-off each carries and what your team must be able to operate on its own without outside connectivity.
Single standalone node
A standalone node runs manager, search and sensor functions on one box, which suits one small enclave with a limited analyst group. The Security Onion hardware docs list a standalone minimum of 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, but storage for packet capture usually sets the real size. Check that one host can keep up with peak traffic on the monitored link, because a single failure takes out detection for the whole enclave. Confirm that your team can rebuild the node from ISO media alone.
Distributed manager, sensor and search
The distributed design separates a manager node, one or more sensor nodes and one or more search nodes, and it is the recommended design for production. Sensors stay close to the tap or span, while search nodes hold indexed data for analysts. The architecture docs note that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Your team should plan manager availability, backup of its configuration and a tested restore path inside the enclave.
Receiver nodes for pipeline redundancy
Receiver nodes add redundancy and load balancing to the event pipeline between sensors and the rest of the deployment. They matter when one ingest path cannot be allowed to stop, for example on a monitored link with heavy traffic or a SOC that expects continuous coverage. Receivers do not remove the manager dependency for indexing, so the design still needs a documented plan for manager failure. Ask for a failover test that shows how events queue and resume after a receiver is lost.
Separate enclave per trust zone
Running a separate Security Onion deployment for each trust zone keeps monitoring data, rule tuning and access rights apart when zones have different classifications or owners. This pattern costs more hardware and analyst time, but it avoids moving packet capture across a boundary that may itself be restricted. Each enclave needs its own update path, which means its own ISO media and a documented chain of custody for each rule set. Confirm with your security authority whether a shared console or aggregated alerts are permitted between zones.
What auditors and assessors ask to see from an air-gapped sensor
This table lists the evidence items an assessor typically requests for an isolated Suricata and Zeek deployment, the component that produces each item, and where the evidence usually goes missing. Read each row as a question to answer before the assessment starts, not after. The main takeaway is that offline operation shifts evidence from vendor portals to your own change records, so every transfer and tuning decision needs its own paper trail.
| Evidence item | Produced by | What the assessor checks |
|---|---|---|
| Sensor and rule inventory with versions | Security Onion console and deployment records for Suricata, Zeek and rule sets | Installed versions match the approved baseline, and every NIDS, YARA and Sigma rule set has a known source ISO and date |
| Offline transfer records with integrity checks | Change log for each ISO or package carried across the gap, plus hash verification output | Each media import has a named owner, a checksum recorded before and after transfer, and an approval reference |
| Update history from airgap media | soup update logs and the ISO version applied on each node | Updates came from newer media that was verified, and the node versions after each update are documented |
| Alert and tuning history | Detections interface change records for NIDS suppressions, thresholds and modified rules | Each suppression or threshold change has a reason, an approver and a date, and no alert class was silenced without review |
| Retention configuration | Security Onion settings for Suricata full packet capture and log storage, plus disk utilization records | Retention periods match the policy, and the sensor shows what is kept, for how long and where it is stored locally |
| Access logs for manager and analysts | Manager node authentication logs, console audit records and local account records | Each analyst has a unique account, access is limited to the roles needed, and logins and privilege changes are recorded |
| Restore test results | Backup process output and documented restore exercises for the manager and search nodes | A restore was performed on separate hardware, the result was recorded, and the restored sensor resumed collection |
What do teams ask before running NSM on an isolated network?
Can a small security team run network monitoring on an air-gapped network without outside help?
Yes, many small teams can run a single Security Onion deployment themselves, but the workload depends on how much tuning, rule management and offline update handling the network requires. Security Onion supports full installs without internet access, since its ISO carries packages and NIDS, YARA and Sigma rules. The ongoing work is alert tuning, managing rules on the Detections interface, and moving media across the boundary for each update. Teams without analysts who can read Suricata and Zeek output usually bring in a partner for the first rollout and the tuning period. Ask any partner to state in writing which tasks they perform and which stay with your staff.
How long does an air-gapped NSM rollout take, and what drives the timeline?
The timeline depends on the number of sites, the sensor count, the network design and how many approvals the change process requires. Security Onion recommends the Distributed deployment type for production, with a manager node, sensor nodes and search nodes, so a multi-site design has more hardware, more firewall and boundary decisions, and more testing than a single standalone node. Offline media transfer and change approvals in a controlled zone often take longer than the technical install. Any partner should give a written schedule tied to a written scope, and you should ask which milestones depend on your change board or on access windows.
What does the organization need to provide for taps, change approvals and staff time?
Plan for physical access to the monitored segments, approved change windows and named staff who can act on the findings. Sensors need a tap or span point with two network interfaces on a standalone node, and Security Onion's hardware documentation lists minimums of 2 NICs for a sensor, a standalone node and a combined design. Monitoring a control or isolated network usually means a change request for each tap, plus a review of how the sensor will be managed inside the zone. Your team also needs time to review alerts, approve rule changes and record decisions. Ask the partner to list every access, approval and staff dependency before work begins.
What drives the cost of an air-gapped NSM deployment?
The main cost drivers are sensor hardware, taps and network changes per site, storage for packet capture and metadata, and the time spent on tuning and analysis. Hardware follows from the minimum specifications for each role: Security Onion's documentation lists 4 cores and 12 GB RAM for a sensor, 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 24 GB RAM and 200 GB storage for a standalone node, and it supports only x86-64 processors. Storage grows with the capture window you choose. Security Onion Pro is a paid edition on 1 to 5 year terms that adds features such as LUKS encryption, FIPS mode, OIDC single sign-on and professional support, so ask whether any of these are required. Request a quote that separates one-time hardware and setup from recurring license, support and tuning effort.
Can Security Onion be updated fully offline in an air-gapped environment?
Yes, Security Onion documents an airgap mode in which the soup update tool updates the platform from newer ISO media. You download the release image outside the boundary, verify it, transfer it through your approved media process, and run the update from that media. The process should be rehearsed on a lab copy first, because each release can change the platform components and the upgrade path. Note that Security Onion 2.4 reached end of life on October 1, 2026, and that 2.4 installations on Oracle Linux 9 can upgrade to 3 only after full packet capture moves from Stenographer to Suricata, while other distributions need a fresh install. Confirm the supported path for your version and distribution before you plan the cutover.
How do we get rule updates and threat intelligence across the boundary?
Rule sets reach an isolated network by the same controlled media process used for platform updates, and each batch should be checked before it is loaded. Security Onion's ISO includes NIDS, YARA and Sigma rules, and its Detections interface lets you modify, suppress and set thresholds on Suricata rules and add custom filters to Sigma rules. Rule updates from outside sources need a documented review, a hash or signature check, and a record of who approved the import. For control environments, NERC CIP-013-2 requires supply chain processes that address verification of software integrity and authenticity for vendor software and patches, which is the control behind checking every package that crosses the boundary. Ask your partner how each import is validated and logged.
How much local storage do we need for packet capture on an isolated sensor?
Storage depends on the traffic rate, the number of hours of full packet capture you keep, and how much metadata you retain for search. Security Onion now uses Suricata for full packet capture after version 3.0.0, which replaced Stenographer, so retention settings and disk layout should be checked against that design. Because the network is isolated, all storage and analysis happen on local disks, so sizing errs toward headroom for peak traffic and for log growth. Ask the partner to show the sizing calculation, the assumed traffic rate, the retention period and the disk layout for each node, and to state how the sensor behaves when storage fills.
What to ask an implementation partner for an isolated deployment
Start with the transfer process, because every package that crosses the gap is a supply chain decision. Ask how the partner verifies the Security Onion ISO, the Suricata and Zeek packages and the NIDS, YARA and Sigma rule sets before they enter the enclave: which checksums or signatures are compared, who performs the comparison, and where the result is recorded. Ask who holds the offline signing keys, who approves each transfer, and whether those approval records are kept in a form your auditors can sample. Under NERC CIP-013-2, the supply chain procurement process must address verification of software integrity and authenticity, so this answer belongs in your evidence file, not in the partner's memory.
Next, pin down the upgrade path. Security Onion 2.4 reached end of life on October 1, 2026, so ask whether your installation is on 2.4 and, if so, which migration route the partner proposes. The partner should explain how soup will be run from newer ISO media in airgap mode, how a failed update is rolled back, and what happens to Suricata full packet capture if the move to Suricata from Stenographer requires a fresh install on your distribution. Ask for a written plan with a dated list of deliverables, and ask for the scope and deliverables to be agreed in writing before any work starts.
Finally, test the recovery story on the hardware you will actually run. Ask how the partner sizes local storage for packet capture and metadata, and which traffic measurements they need first: peak bandwidth per tap, average packet rate, retention period and the share of traffic that is encrypted. Ask how rules are tuned without internet feeds, who authors suppressions and thresholds, and how they are reviewed. Then ask for a restore test on isolated hardware, run from backups stored inside the enclave, with the restore time and any gaps recorded. Confirm each of these in the written scope rather than accepting a verbal assurance.
