Why an air-gapped SIEM deployment differs from a connected one
In a regulated or critical environment, logs often must stay inside an isolated network, so the SIEM cannot pull packages, rules or vulnerability data from the internet. Security Onion and Wazuh both support offline installation, so the platform choice is rarely the blocker. The hard work is the update path: how packages, detection content and vulnerability data reach the isolated network, who approves each media transfer, and how the team proves what was carried across the boundary. Security Onion's airgap model ships its ISO with packages and NIDS, YARA and Sigma rules, and its soup tool updates from newer ISO media. Wazuh's offline guide pairs with an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Both need a repeatable media workflow before go-live.
Offline support is not evenly distributed across vendors. Several platforms outside this stack list air-gapped deployment as a paid-edition feature, including Mattermost in its Enterprise Advanced plan and Metabase on its Enterprise plan, so a license line item can appear late in procurement. Confirm in writing, for each component you plan to run (the SIEM, its dashboards, any threat intelligence or SOAR add-ons), whether offline installation and offline updates are included in the edition you are buying, and whether the license needs periodic online validation. Ask the implementation partner to show the offline install and an update cycle on a lab copy before you commit.
Sizing also changes when there is no online fallback. Plan for the full ingest, retention and rule set on site, because a missed update window or a failed disk cannot be patched from the internet the next day. Security Onion's hardware minimums are a floor, not a production design, and its architecture docs note that search nodes stop indexing if the manager goes down. Confirm spare capacity, spare hardware and the on-site operator skills needed to run the update cycle, and record who signs off each transfer. Those decisions set the operating cost of an isolated SIEM more than the software license does.
Which requirements shape an air-gapped SIEM build
This table maps each requirement to the build decision it drives in an isolated SIEM, the evidence an assessor will ask for, and where builds usually fall short. Read each row as a question to answer before hardware is ordered. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
| Requirement | Build decision it drives | Evidence an assessor expects | Where builds usually fail |
|---|---|---|---|
| HIPAA 45 CFR 164.312 audit controls | Keep the SIEM and its log store inside the boundary, size local retention to the review cycle, and restrict who can query logs that may contain ePHI | Log retention settings, samples of recorded activity in ePHI systems, and records showing that activity was examined | Retention sized for storage alone, with no documented review of logs that are kept locally |
| HIPAA 45 CFR 164.312 access control and unique user identification | Give each analyst a named account in the console and separate roles for viewing, tuning and administration | Account list, role assignments, and proof that shared or default accounts were removed | Default administrator accounts left active after the isolated install |
| FTC Safeguards Rule 16 CFR 314.4 multi-factor authentication | Require MFA for console and administrative logins, using a method that works without internet access, such as a locally hosted authenticator | Configuration evidence showing MFA enforced on every account that can reach the SIEM | MFA enforced for the dashboard but not for the operating system or the indexer administration path |
| FTC Safeguards Rule 16 CFR 314.4 logging of authorized user activity | Collect administrator and analyst actions from the SIEM itself, not only from monitored endpoints | Audit records of SIEM logins, configuration changes and rule edits, with a review trail | Logging of endpoints configured, while changes made inside the SIEM are not recorded |
| NERC CIP-005-7 remote access (where applicable) | Route any vendor or engineer access for offline updates through an intermediate system with encryption and MFA, and disable sessions when not in use | Remote access architecture diagram, MFA records, and session detection and disablement procedures | Update vendors connecting directly over a temporary link that was never documented |
| NERC CIP-013-2 software integrity and authenticity (where applicable) | Verify hashes and signatures of every ISO, package, rule set and vulnerability feed before it crosses the isolated boundary | Media transfer log, verification records for each file, and the vendor source for each update | Updates copied to the network without a recorded hash check or chain of custody |
| Offline rule and feed updates | Set a schedule for importing new media, define who approves imports, and keep a dated record of each rule and vulnerability data version | Import logs, version history of detection content, and records of tuning changes | Rule sets that age silently because no one owns the update cycle |
| Local retention and offline data integrity | Store audit logs on the SIEM host with access controls and protect them from change by the people they record | Retention policy, access logs for the log store, and integrity controls over stored events | Administrators able to delete or alter logs they also generate |
How rule, feed and software updates cross the isolation boundary
The update cycle is the real operating model of an air-gapped SIEM, so plan it before the first install. Every package, ISO and vulnerability data set is vetted outside the enclave, hashed, recorded in a change log with its source and hash, moved through an approved transfer path, and only then applied inside. Assign a named owner for each step and keep the record, because the same log becomes evidence when an assessor asks how software entered the boundary. Confirm with your media-transfer team how sanitization and chain-of-custody steps are logged before you commit to a schedule.
For Security Onion, the update path is media-driven. The ISO carries packages and NIDS, YARA and Sigma rules, and the soup tool updates the deployment from newer ISO media in airgap mode, according to the Security Onion airgap documentation. Confirm the exact soup procedure for your installed version against that guide, and verify that your release line is still supported: Security Onion 2.4 reached end of life on October 1, 2026, so a 2.4 estate on Oracle Linux 9 needs a planned move to 3.x. For Wazuh, the offline installation guide covers systems without internet connectivity, and vulnerability detection can read an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Confirm how that repository is refreshed, how often it is rebuilt, and how agents' software inventories are matched against it.
NERC CIP-013-2 supplies the control logic behind every package check. It requires supply chain procurement processes that address verification of software integrity and authenticity for vendor software and patches, so each hash comparison and signature check should be written into the procedure and tied to a responsible role. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months. Build a standing monthly intake window, decide in advance which patches are security-critical and need an out-of-cycle transfer, and ask your implementation partner how they will test each package on a staging copy before it crosses the boundary.
Which open-source SIEM platforms fit an isolated network
Only a few open-source SIEM platforms ship offline installation paths and update methods that suit a network with no internet route. Each option below differs in how it arrives on site, how its detection content gets updated and which hardware and operating system it expects, so the choice should follow the update process you can run.
Security Onion air-gapped ISO
Security Onion supports full installs on networks without internet access. Its ISO carries the packages along with NIDS, YARA and Sigma rules, and the soup tool applies later updates from newer ISO media in airgap mode. The platform runs on x86-64 only, and the 3.x line runs on Oracle Linux 9. Confirm that your hardware is x86-64 and that your team accepts the Elastic License 2.0 before you commit, since that license is source-available rather than OSI-approved.
Wazuh offline installation
Wazuh publishes an offline installation guide for systems without internet connectivity. Its components are the indexer, which stores alerts, the server, which analyzes agent data with decoders and rules, the dashboard and the agents on endpoints. Licensed under GPL-2.0, it is easier to review for license purposes. Vulnerability detection can use an offline vulnerability repository in place of the Wazuh CTI platform, so confirm how that repository is built, signed and moved across the boundary.
Security Onion node layout
Security Onion's Distributed deployment, with a manager, sensors and search nodes, is the recommended design for production. The architecture docs state that search nodes stop indexing when the manager is down because they cannot reach Redis. In a segmented network, plan for that dependency, add receiver nodes where pipeline redundancy matters, and size each role separately against the published minimums.
Offline rule and detection updates
Air-gapped SIEM rule updates depend on the platform. Security Onion's Detections interface manages NIDS rules in Suricata, Sigma rules in ElastAlert and YARA rules in Strelka, and it supports tuning with suppression and thresholds. Wazuh rule and CTI content arrives through its own update channel. Before selecting, verify which content each platform can refresh from media, how often that content is published and who approves each import.
Pro options to confirm
Security Onion Pro is a paid edition sold on 1 to 5 year terms. It adds OIDC single sign-on to the Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance and professional support. Treat these as options to confirm against your requirements, not as included features. Ask the vendor whether Pro features work in a disconnected deployment and whether licensing or activation requires any outbound connection.
Hardware and sizing on site
Security Onion supports only x86-64 processors. Published minimums are 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, and 4 cores with 16 GB RAM for a manager or search node. Because no cloud resources are available, the storage plan and retention period must be fixed before the hardware order. Confirm with the vendor how these minimums change at your ingest rate, since minimums are not production sizing.
How the rollout proceeds from staging to on-site cutover
The sequence moves the SIEM from scoped requirements to a tested offline media kit, a validated on-site install and a rehearsed update cycle, so the enclave team can run the platform without internet access after handover.
Scope log sources and enclave boundaries
DeployOpen works with the enclave owner, network team and SOC lead to list every log source that must reach the SIEM, including firewalls, domain controllers, hypervisors and OT or control system devices where they exist, and to define which network segments the SIEM and its sensors may touch. The output is a written scope document with an inventory of sources, the data flows that cross the boundary, and the agreed deployment type. Confirm with the vendor which Security Onion deployment type and which Wazuh components fit the segment design before the scope is signed.
Size on-site hardware against node minimums
Before any hardware is ordered or shipped, the team checks the expected sensor count, traffic volume and retention needs against the published minimum specifications for each Security Onion role, which include 4 cores and 24 GB RAM for a standalone node, 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor. Security Onion supports only x86-64 processors, and production designs are normally distributed rather than standalone. The output is a bill of materials and a rack plan that the site can accept, plus a list of hardware questions for the vendor to answer in writing.
Build the offline media kit in staging
In a connected staging lab, DeployOpen builds the platform images, the Security Onion ISO, the Wazuh offline packages and the offline vulnerability repository, then copies them to approved transfer media with checksums recorded. The team verifies package integrity and authenticity against vendor-published values before anything is carried across the boundary, which is the control NERC CIP-013-2 describes for vendor software. The output is a versioned media kit with a manifest and a signed record of who verified each item.
Test the kit in a disconnected lab
The media kit is installed in a lab that has no route to the internet, using the same procedures planned for the site. The test confirms that the Security Onion install completes from the ISO, that Wazuh installs from the offline guide, that agents enroll, and that alerts and dashboards populate from a sample of log sources. Any step that reaches outward is treated as a defect. The output is a tested runbook with recorded errors, the fixes applied and a sign-off from the enclave owner.
Install and validate on site
On site, DeployOpen's engineers install the manager, search, sensor and Wazuh components from the verified media, connect the approved log sources and confirm time synchronization, storage, access control to the console, and alert routing inside the enclave. Each source is checked for events arriving and parsing correctly, and the Detections interface is checked to confirm that the expected NIDS, Sigma and YARA rules are loaded. The output is a validation record covering each source, each component and each rule set, which the client keeps as installation evidence.
Rehearse the first offline update cycle
Before handover, the team runs one full update cycle using a newer media kit built in staging, following the Security Onion airgap process for updating from newer ISO media and the Wazuh offline steps for package and vulnerability data updates. The rehearsal records how long each step takes on this hardware, what needs to be backed up first and how to roll back if the update fails. The output is a dated update log and a tested rollback procedure, so the first real update is a repetition rather than a first attempt.
Hand over runbooks and train operators
DeployOpen delivers the operating runbooks for daily health checks, alert tuning, log source onboarding, media intake and verification, backup and restore, and update cycles, then walks the SOC and platform staff through each one on the installed system. Open items, known limitations and the vendor support route for security patches are written into the handover pack. The sequence closes when the client's named operators have performed a restore and an update step themselves and signed off the handover.
How the components sit inside the enclave
An air-gapped SIEM is two stacks that share one boundary: Security Onion for network and host detection, and Wazuh for endpoint and log analytics. Both need an offline update path, and both depend on a small set of nodes that must be placed and protected deliberately before the first alert fires.
Distributed Security Onion roles
The Distributed deployment type separates a manager node, one or more sensor nodes and one or more search nodes, and it is the design the vendor recommends for production. Receiver nodes can be added for pipeline redundancy and load balancing. Confirm the node count against your traffic and retention targets, because the search tier only works while the manager is reachable.
Manager dependency risk
The Security Onion architecture docs state that if the manager goes down, search nodes stop indexing because they cannot reach Redis. In an enclave with no external fallback, a manager outage is a blind spot for every sensor behind it. Plan manager high availability, monitor the manager first, and document the recovery steps your operators will run during an outage.
Wazuh indexer, server and dashboard
The Wazuh indexer stores alerts as a full-text search and analytics engine, the Wazuh server decodes and applies rules to agent data, and the dashboard provides the web interface. The server can run as a cluster for horizontal scaling and manages agent configuration remotely. Size the indexer for retention, since it holds the data your investigations and audits depend on.
Agents and agentless syslog sources
Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX endpoints inside the enclave. Devices that cannot run an agent, such as firewalls and some control equipment, can send syslog to the server and be probed through their APIs. Confirm the vendor's approval for any agent installed on operational or regulated systems before deployment.
Trust boundary and enclave edge
Every component inside the enclave should sit on the same side of one defined boundary, with explicit rules for what crosses it. Logs leave the enclave only through approved paths, and no SIEM node should accept inbound connections from outside it. Document the boundary in your network diagrams, and have your assessor confirm it matches what the firewalls actually enforce.
Offline repository and transfer station
Packages, rule sets and vulnerability data arrive on media and are verified at a transfer station on the boundary before they reach the offline repository used by the SIEM nodes. Wazuh vulnerability detection can use an offline repository in place of the Wazuh CTI platform. Record hashes and signatures for every import so you can show what was loaded and when.
What auditors ask for from an offline SIEM and where it comes from
This table lists the evidence an assessor is likely to request for an air-gapped SIEM, the component or process that produces each item, and the gap that most often leaves it missing. Read it as a checklist to set up before go-live, not after the first audit request. DeployOpen prepares this evidence, while independent auditors and certification bodies assess it.
| Evidence item | Produced by | What to confirm before go-live |
|---|---|---|
| Media transfer log for each ISO, package and rule bundle | Your transfer procedure and the removable media register | Who approved each import, which cross-domain path was used and when it crossed the boundary |
| Hash records for ISO and rule packages | Hash computed on the source side and re-verified inside the enclave | Algorithm and hash values are recorded in the change ticket, and verification output is retained |
| Signature or provenance check for vendor packages | Verification step run before installation, using vendor-published keys | Which keys are trusted, how key distribution was verified, and who can change the trust store |
| Update change records for soup and Wazuh package upgrades | Your change management system, with console and manager logs as supporting records | Pre- and post-update version of each component, rollback plan and test results |
| Offline vulnerability data refresh record | Wazuh offline vulnerability repository load, tied to the agent software inventory | Date of the last data load, source snapshot used and who signed off the refresh |
| Audit log retention and access records | Wazuh indexer and Security Onion log storage, plus host audit logs | Retention period for SIEM logs themselves, protection from change and a list of administrators who can read or delete them |
| MFA evidence for console access | Identity provider or console authentication logs, and any Pro edition SSO configuration | Which accounts use MFA, how tokens are issued offline and how access reviews are documented |
| Sizing records for on-site hardware | Design document and capacity tests, compared with vendor minimum requirements | Daily ingest estimate, retention tier, node counts and the date the sizing was last reviewed |
What does an air-gapped SIEM deployment cost and need?
What drives the cost of an air-gapped SIEM deployment?
Cost is driven mainly by hardware on site, the staging lab, media handling, paid editions and the labor of repeated offline update cycles. The software itself can be free to download under its license, but the sensors, manager, indexer and search nodes must be bought, racked and powered inside your boundary. Each offline update also needs a clean copy of packages and rules to be staged, checked and carried across. Ask any partner to split the quote into one-time items (hardware, lab build, initial install, initial content load) and recurring items (update cycles, rule and feed refreshes, support). Hardware sizing should follow the minimum requirements in the Security Onion hardware docs and the ingest you plan to onboard.
Do paid editions need to be bought for air-gapped support?
Not always, but it depends on the product and edition. Security Onion supports full installs on networks without internet access, and its ISO carries packages and NIDS, YARA and Sigma rules, so the free platform can be installed offline. Wazuh publishes an offline installation guide and an offline vulnerability repository option. Other vendors gate offline operation behind paid tiers: Mattermost lists air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Metabase offers it only on its Enterprise plan. Confirm in writing which features, support terms and update channels your chosen edition includes offline, and whether any add-on such as Security Onion Pro is needed for capabilities like OIDC single sign-on or FIPS mode.
Can a small security team run an air-gapped SIEM on its own?
A small team can run it if it has someone comfortable with Linux administration, package and rule handling, and the SIEM's own query and tuning tools. The harder part is the offline update cycle, which repeats: each new release or content set must be obtained from outside, verified, moved through approved media and applied in order, while the team keeps alerts running. Security Onion's soup tool updates from newer ISO media in airgap mode, which keeps the procedure defined but still manual. Wazuh's offline installation guide follows a similar pattern. Decide early who owns each update, who covers the on-call gap, and whether a partner will hold a retainer for upgrades and support.
How long does an air-gapped SIEM deployment take?
Duration depends on scope: the number of sites, sensor count, log sources to onboard, detection content to load and whether a staging lab must be built first. No fixed timeline applies to every environment, so ask for a written schedule tied to a written scope before work starts. Scope items that usually extend the schedule include hardware procurement and delivery into a secured facility, approval cycles for media transfer, and validation of the first offline update. DeployOpen plans and implements most work on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work begins.
What does our organization need to provide for an offline SIEM project?
Prepare the inputs before the first workshop, because they set the design and the schedule. The main items are:
- Network diagrams showing each enclosed zone, its connections and where sensors can tap traffic
- A log source list with systems, versions, event volumes and owners
- Sizing data, including expected daily ingest and how long logs must stay searchable
- Approvals for media transfer, including who may carry media in and out, how media is scanned, and where it is logged
- Access rules for the staging lab and the production boundary
For energy and other OT environments, the boundary rules in NERC CIP-005-7 may also shape where the SIEM and its remote access sit. Confirm these requirements with your compliance lead before design begins.
How do the offline update and media transfer steps affect supply chain risk?
Each package, rule set and vulnerability data file carried across the isolated boundary is a supply chain event, so the transfer process needs verification built in. NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches, and the same principle applies to any framework you follow. Plan for checksum or signature verification of every package, a documented chain of custody for media, and a test install in the staging lab before production use. Confirm with your vendor or partner how release signatures are published and how they can be checked offline.
What breaks if the SIEM falls behind on offline updates?
Detections, vulnerability data and platform fixes age while the system stays on an older state, so the SIEM can miss newer threats and known vulnerabilities. For Wazuh, vulnerability detection correlates agent software inventory with data from an offline repository, so stale data produces stale findings. For Security Onion, NIDS, YARA and Sigma rule sets only improve when newer ISO media is applied. Set a cadence for content refreshes separate from platform upgrades, and record which content version was live at each date so that auditors can see the detection coverage that applied at the time. Also check support status: Security Onion 2.4 reached end of life on October 1, 2026, so older lines can leave you without fixes.
What does the offline installation process cost in time for each update cycle?
No researched figure for offline update effort is available for this page, so use your own staging lab measurements as the baseline. Ask your partner to estimate the labor per cycle in writing, broken into staging, verification, transfer, application, testing and rollback, and to state which parts are fixed in the scope and which are billed as work requests. Also ask how many update cycles a year the quote assumes, since the recurring labor depends on release frequency and how many components you run. Wazuh has shipped 4.14 patch releases roughly every one to two months in 2026, so use that cadence as a planning input rather than a commitment.
Questions to put to an implementation partner for an isolated SIEM
Start with the offline media kit, because every later update depends on it. Ask the partner how they build the kit, which packages, rules and vulnerability data it carries, and how they test it on a network that matches yours before it crosses the boundary. Ask how each artifact is verified: which checksums or signatures they check against the vendor's published values, who performs the check, and where the verification record is stored. Ask how they handle the update cadence, including how often they expect to ship a kit, how a Security Onion update moves from newer ISO media through the soup tool in airgap mode, and how Wazuh offline vulnerability data is refreshed. Confirm the cadence is written into the scope, and that the partner can tell you what happens when a patch lands between two kits.
Ask how hardware is sized on site before anything is ordered. Security Onion publishes minimum requirements per node role, but a production design depends on your ingest and retention, so ask for the sizing worksheet, the assumptions behind it and the node layout, including whether the design is Distributed with a manager, sensors and search nodes. Ask what happens if the manager node fails. The Security Onion architecture documentation notes that search nodes stop indexing when they cannot reach Redis on the manager, so ask how the partner plans manager recovery, backups and any redundancy they will build, and whether the runbook is tested. Finally, ask how they prove update history to an auditor: which change records, package manifests, hash logs and approval tickets they produce, how long they keep them, and what support is included after go-live, including who applies each kit and at what fixed cost or retainer.
