Self-hosted Sumo Logic alternative for air-gapped networks

Why a self-hosted Sumo Logic alternative is needed for air-gapped networks

For a site or regulated network that cannot send logs to a public cloud, the path is a self-hosted stack, with OpenSearch for the search and log store and Wazuh for the security detection layer, because Sumo Logic is delivered as SaaS only. The question is no longer whether Sumo Logic's features are needed, but which components will run inside your boundary and who keeps them current. The ownership changes at Splunk, Microsoft Sentinel and QRadar are not the driver here. What matters is the deployment model, since every one of those products still depends on a connection to a vendor-operated service or on a vendor release channel that your network may not be able to reach.

Three decisions need to be made before any design work starts. The first is the search and log store: which OpenSearch version you will run, how many nodes and how retention is split across hot and older data, and whether you will use the Security plugin for role-based access, audit logs and TLS between nodes. The second is the security detection layer: whether Wazuh agents, the Wazuh server and the Wazuh indexer will provide alerting, file integrity monitoring and vulnerability detection, and which compliance views you need. The third is the offline update process, which is usually the hardest to get right. Confirm with each vendor whether the installer and the rule or vulnerability content can be fetched from media you carry in, and whether the offline repository must be refreshed on a schedule.

Before committing, ask your team to confirm three points with your environment in mind: which installation methods work with no internet access, whether vulnerability data can come from an offline repository instead of an online threat intelligence service, and how your change control process will verify each package crossing the boundary. Requirements such as NERC CIP-013-2 expect procurement processes to address software integrity and authenticity, so plan that check as part of the update workflow. The Wazuh offline installation guide lists the supported offline path for the security layer.

What an isolated network requires from a log platform

A log platform on an isolated network has to run, receive updates and be administered without a path to the internet. The four constraints below connect to one another: every package that crosses the boundary must be verified, every administrative session must be controlled, and the data must remain on-site for the whole retention period.

No outbound internet dependency

A self-hosted stack must start, index, alert and render dashboards with no call to a public endpoint. Wazuh publishes an offline installation guide, and Security Onion supports full installs from its ISO, so both can be planned for isolated networks. Check every component in your design, including vulnerability feeds and rule sets, and confirm that none of them phones home by default. Ask each vendor which features need connectivity and which have an offline path.

Verified packages across the boundary

Each package, rule update and container image carried into the enclosure needs an integrity and authenticity check before it is installed. NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches, which is the control behind this check. Record the hash, the source and the approver for every transfer. Confirm how the vendor signs its packages and how you validate those signatures offline.

Controlled remote access to the monitor

Vendor and engineer access to the log platform is a path into the network, so it must go through a controlled point. NERC CIP-005-7 requires Interactive Remote Access to high and medium impact BES Cyber Systems to pass through an Intermediate System with encryption and multi-factor authentication, and to allow detection and disabling of active vendor sessions. Whether your environment falls under CIP applies to your own asset classification. The OpenSearch Security plugin offers TLS, role-based access control and audit logs, which you can use inside that boundary.

Logs that never leave the site

When logs are the evidence trail, the storage location, backup copies and replicas all have to sit inside the enclosure. Keep indices, alert history, agent configuration and dashboards on local storage, and restrict who can export them. Document where each data type lives, including snapshots, and confirm that the chosen platform does not send telemetry or crash reports to an external service. Ask the vendor to list every outbound destination its software can contact.

Upgrades that are staged offline

A log platform on an isolated network receives patches later than a connected one, so the upgrade path becomes a planned process. Security Onion's soup tool updates from newer ISO media in airgap mode, and OpenSearch patches versions in maintenance with bug fixes and security patches. Plan a recurring intake schedule, a test environment that receives each release first, and a rollback plan. Ask your vendor how long each release line receives security fixes.

Which option fits which monitoring job

OpenSearch is the closest self-hosted match to Sumo Logic's general log analytics. It is licensed under the Apache License, Version 2.0, was forked from Elasticsearch 7.10.2 and Kibana 7.10.2, and keeps wire compatibility with Elasticsearch 7.10 REST APIs. For application logs, infrastructure logs and ad hoc search, it covers indexing, search, dashboards and alerting, but the query language, saved searches and dashboards must be rebuilt rather than copied across.

Query translation: Sumo Logic queries do not run unchanged. Plan to rewrite the most used searches and dashboards by hand.
Licensing: All OpenSearch project software is Apache 2.0, and the FAQ does not describe a paid edition. Support contracts are a separate, optional purchase.
Upgrades: Versions move through maintenance, and rolling upgrades are documented from Elasticsearch 6.x and 7.10. Schedule upgrades inside your change window and test them on a copy of the cluster first.
Access control: The Security plugin supplies SAML, OpenID Connect, LDAP and Kerberos authentication, role-based and field-level security, and audit logs. Confirm that these meet your internal review requirements.
Operating burden: You own sizing, shard management, backups and capacity growth. Sumo Logic hides these tasks, so staff time is the main gap.

Before committing, confirm which Sumo Logic dashboards and alerts your teams use daily, and check that OpenSearch Dashboards covers them without custom plugins.

Security Onion fits sites that need network traffic visibility on an isolated segment. It is a free Linux distribution for threat hunting, security monitoring and log management, and it bundles Suricata, Zeek and the Elastic Stack. Its repository is under the Elastic License 2.0, and Security Onion Pro is a separate paid tier.

Airgap install: The ISO carries packages along with NIDS, YARA and Sigma rules, so a full install does not need internet access.
Controlled updates: The soup tool applies updates from newer ISO media in airgap mode. Each update must be verified before it crosses the boundary.
Network focus: It is strongest for packet and protocol visibility. It is not a general application log platform, so it complements OpenSearch or Wazuh rather than replacing them.
Licensing check: The Elastic License 2.0 terms differ from Apache 2.0. Have legal review them if you plan to redistribute or embed the stack.
Sensor placement: Taps or span ports, and the sizing of sensor hardware, depend on your traffic volumes and must be specified in your own design.

Confirm with your network team whether packet capture is permitted on the segment and how long captured data may be retained.

How OpenSearch, Wazuh and Security Onion meet the constraint

This table compares OpenSearch, Wazuh and Security Onion on license, offline installation, update path, access control and gaps for a network that cannot send logs to a public cloud. Read each row as a question to confirm in writing with the vendor or project before you commit. The main takeaway is that all three can be self-hosted, but offline support and access control details differ and must be verified in your own environment.

Criterion	OpenSearch	Wazuh	Security Onion
License	Apache License 2.0 for all project software; the OpenSearch FAQ describes no paid edition	GNU GPL version 2, with an exception permitting linking with OpenSSL	Elastic License 2.0 for the repository; Security Onion Pro is a paid tier
Offline install support	Documents Docker, Helm, tarball, RPM, Debian, Ansible and Windows installs; confirm the package set you need can be staged offline	Publishes an offline installation guide for systems without internet connectivity	Full installs without internet access from the ISO, which carries packages and NIDS, YARA and Sigma rules
Update path	Rolling upgrades from Elasticsearch 6.8.0 to 7.10.2 and from 7.10 to OpenSearch; confirm how new packages reach isolated nodes	Patch releases in the 4.14 line; you move packages across the boundary and verify them yourself	The soup tool updates from newer ISO media in airgap mode, so each update arrives as a media transfer
Vulnerability data offline	Not applicable as a core feature; depends on the security tooling you add	Uses an offline vulnerability repository in place of the Wazuh CTI platform	Depends on the rule and signature sets carried on the ISO and later media
Authentication	Security plugin supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token backends	Single sign-on is documented in the Wazuh user manual; confirm the provider you need works without outside connectivity	Inherits the access model of its bundled components; confirm integration with your directory service
Access control and audit	Role-based access control, document-level and field-level security, field masking, impersonation, audit logs and TLS	Role and user administration in the dashboard; confirm granularity against your separation-of-duties needs	Access control depends on the bundled components; confirm audit coverage for your assessor
Compliance views	Not included; build dashboards and reports yourself	Prebuilt dashboards for PCI DSS, GDPR, HIPAA and NIST 800-53	Not described as a compliance reporting product; confirm with the project
Known gaps for this constraint	Confirm whether any feature you need sits in a paid add-on or a later major version	Agentless devices depend on syslog and API probing; confirm coverage for isolated OT or legacy hosts	Scope is threat hunting and monitoring; plan separate log storage and retention

How to install and update OpenSearch and Wazuh without internet access

This sequence takes OpenSearch and Wazuh from a connected staging network to a running, authenticated, offline cluster with a repeatable process for bringing updates across the boundary.

Stage packages and images on a transfer medium
On a connected staging host, the platform team downloads the OpenSearch distribution (tarball, RPM or Debian package, or container images), the Wazuh packages named in the Wazuh offline installation guide, agent packages for every operating system in scope, and any rules or vulnerability data the offline repository needs. Container images are pushed to a private registry or saved to an archive. Keep a manifest listing each file, its version and its checksum. Done when the manifest matches the transfer media contents and every file is readable from a clean directory. Confirm exact artifact names against the current OpenSearch install documentation and the Wazuh release notes before downloading, because versions change on a regular cadence.
Verify integrity before crossing the boundary
The security team checks each artifact's published checksum and signature against values obtained from the upstream project, not from the same download page as the file. They record the verification results in the manifest and sign the manifest itself. This supports the supply chain control in NERC CIP-013-2 for utilities, and comparable vendor verification expectations elsewhere. Done when every artifact passes verification, failures are quarantined, and the signed manifest is stored with the transfer media. Ask your auditor which evidence format they accept for this step.
Install the OpenSearch cluster offline
Inside the isolated network, the platform team installs OpenSearch from the verified tarball, RPM or Debian package, or pulls images from the internal registry. On Kubernetes, the OpenSearch Kubernetes Operator or Helm chart is run from mirrored images. Each node gets TLS certificates issued by your internal certificate authority, and the cluster is formed as a set of nodes with distinct roles. Done when the cluster health endpoint reports green or yellow as expected for your replica settings, and each node joins the cluster with the expected role. Keep the OpenSearch version identical across nodes for the initial build.
Install Wazuh with its offline guide
The team follows the Wazuh offline installation guide for the indexer, server and dashboard, using the packages staged earlier. Where vulnerability detection is needed, they load an offline vulnerability repository instead of relying on the Wazuh Cyber Threat Intelligence platform, which requires connectivity. The Wazuh server can be deployed as a cluster for horizontal scaling if volume requires it. Done when the dashboard loads over HTTPS, the server reports its components as running, and a test event appears in the indexer. Record which vulnerability data set was loaded and when, so the reader can judge its currency.
Connect Wazuh agents and log sources
The team deploys Wazuh agents to endpoints from the internal package repository or a file share, enrolling each agent against the Wazuh server. Network devices that cannot run agents are configured to send syslog to the server, and agentless monitoring is set up where the vendor API allows it. Agents are checked against the server's agent list, and their software inventory begins to populate. Done when every in-scope agent shows as active, syslog sources appear with their expected event counts, and an agent restart is verified to reconnect without internet access.
Configure TLS and authentication
The identity team connects the OpenSearch Security plugin to the directory in use, such as LDAP or Active Directory, or to SAML or OpenID Connect where a provider is reachable inside the network. Roles are mapped to groups, and audit logging is enabled. For Wazuh, the team configures single sign-on as described in the Wazuh single sign-on documentation, or uses local accounts only where directory integration is unavailable. Confirm that the identity provider's metadata or endpoints are reachable from the cluster without internet routes. Done when a test user with a read-only role can log in, an administrator role can change configuration, and failed logins appear in the audit log.
Set up a repeatable offline update cycle
The operations team creates a standing process: on a fixed schedule set by the team, they check the OpenSearch releases page and the Wazuh release notes for new patches, stage the new packages with the same manifest and verification steps, and apply them to a test copy of the stack first. OpenSearch minor releases arrive roughly every eight weeks and maintenance releases carry security patches, while Wazuh 4.14 patch releases arrive about every one to two months. Rolling upgrades are used for OpenSearch clusters, and a rollback snapshot is taken before each change. Done when the first update has been applied to the test environment, its results are documented, and the production change window is recorded. Ask your vendor or DeployOpen for a written scope covering who performs each cycle and how long support is retained.

How updates reach an air-gapped OpenSearch and Wazuh stack

Nothing in an air-gapped stack updates on its own, so every release is a deliberate import. The team needs a connected staging zone where new packages are downloaded, checked and signed off, then carried across the boundary on approved media. Each import should record the version, the checksum or signature verification result, and the person who approved it. That record also serves the software integrity verification that NERC CIP-013-2 expects for vendor software and patches, if your organization is subject to it. Before you start, confirm your own patch window with the operations and security owners, because the staging and transfer steps add lead time to every update.

For OpenSearch, the release calendar sets the rhythm. The project targets a new minor version about every eight weeks, with 3.8.0 released on August 4, 2026 and 3.9.0 on September 29, 2026. A release line stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and during maintenance it receives bug fixes and security patches but no new features. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release. Check the OpenSearch releases page before each planning cycle, because a cluster on an end-of-life line has no upstream fixes to import.

Wazuh and Security Onion follow the same import discipline with different cadences. The current Wazuh line is 4.14, and its patch releases in 2026 arrived on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October, roughly every one to two months, so plan for several imports a year. The Wazuh offline installation guide describes how to bring packages into a disconnected network, and its vulnerability detection should point at an offline vulnerability repository you maintain. Security Onion uses the soup tool, which updates from newer ISO media in airgap mode, so each release arrives as a new image that you verify and mount. Confirm end-of-life dates for every component against its release page, and record which version each node runs in your asset inventory.

What assessors and regulators ask to see for an isolated log platform

An air-gapped log platform is judged on what it can prove, not only on what it does. The cards below list the records assessors usually request for an OpenSearch and Wazuh deployment, and what each one should show. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any attestation.

Offline bill of materials

Keep a complete inventory of every package, container image, rule set and vulnerability feed carried into the isolated network, with its version and source. For OpenSearch and Wazuh this covers the indexer, server, dashboard, agents and any Security Onion or Wazuh content bundles. Check that the list matches what is actually installed, because drift between the inventory and the running hosts is a common finding.

Hash verification logs for each transfer

Each media transfer across the isolation boundary should carry a record of checksums or signatures, the person who verified them, and the result. Relevant controls cover verifying software integrity and authenticity before deployment, which is the reason this step matters for vendor software and patches. Ask the team to show logs for every transfer, including rejected files.

OpenSearch access control configuration

Export the Security plugin configuration that defines roles, role mappings, users and authentication backends, such as LDAP or Active Directory, SAML or OpenID Connect. Assessors will look for least-privilege roles, field-level or document-level restrictions on sensitive log fields, and TLS for node and client traffic. Record who approved each change and keep the exported files under version control.

OpenSearch audit log settings

Show that audit logging is enabled for the cluster, where the audit records are written, and who can read them. Auditors usually test whether administrative actions, failed logins and changes to security configuration appear in the trail. Confirm that audit records are themselves forwarded to a location that the cluster administrators cannot quietly edit.

Wazuh compliance dashboard evidence

The Wazuh dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. Export these views on a set schedule, along with the rule and decoder versions that produced them, so a reviewer can trace a finding back to a specific configuration. Be clear that the dashboard shows monitoring results, and that meeting a framework requires the organization's own controls and assessment.

Update and patch cycle records

Keep a dated log of each update, the source ISO or bundle used, the test results and the rollback plan. OpenSearch releases and Wazuh 4.14 patch releases arrive on their own schedules, so the record should show which versions were in maintenance and which were applied. Record the review decision for each release, including those deferred, so the gap between release and deployment is explained.

Questions buyers ask before an air-gapped log platform project

What drives the cost of a self-hosted air-gapped log platform?

The main cost drivers are staff time, hardware for the indexer and storage, the offline transfer process and outside support. Staff time is the largest recurring item because someone must run upgrades, patches, backups and monitoring on a network that cannot pull updates on its own. Hardware cost rises with daily volume and retention, since indexed log data grows with both. The offline transfer process adds effort each time packages, rules and vulnerability data cross the isolation boundary, and the NERC CIP-013-2 supply chain requirement for verifying software integrity and authenticity is one reason regulated sites budget for that checking. Software licenses for OpenSearch and Wazuh carry no fee, but confirm whether any commercial support tier is needed. Ask every quote to separate one-time build work from recurring operations.

How long does an air-gapped log platform project take?

Duration depends on scope, not on a fixed template. The main variables are the number of log sources, how many agents must be deployed, how many dashboards, alerts and compliance views must be rebuilt, the number of environments (test, staging and production), and how quickly the client's change process approves each step. An air-gapped build also needs time for the offline transfer path to be tested, including how signed packages and rule updates are verified before they enter the enclave. DeployOpen agrees a fixed scope and timeline in writing before work starts, so ask for the milestones and the dependencies on your own teams in that document.

What must our team provide before the work starts?

Your team should provide a log source inventory, network diagrams showing where the isolated segment begins and ends, the hardware or virtual machine capacity you approve, and the expected daily volume and retention periods. You also need named owners for the offline transfer process, identity integration (SAML, OpenID Connect, Active Directory or LDAP), TLS certificate issuance, and access approvals. Provide the list of compliance frameworks you must evidence, and the search and alerting use cases your analysts rely on today. Missing inputs in these areas are the most common reasons a fixed-scope plan changes.

Can our own engineers install this using the official offline guides?

Yes, for teams with Linux administration and security tooling experience. Wazuh publishes an offline installation guide for systems without internet connectivity, and Security Onion documents full installs without internet access, with its soup tool updating from newer ISO media in airgap mode. OpenSearch offers tarball, RPM, Debian, Docker, Helm and Ansible install paths. The difficult part is rarely the first install. It is the ongoing work: rehearsing offline updates, keeping rules and vulnerability data current, sizing the indexer cluster, configuring the security plugin's roles and audit logs, and documenting evidence for an assessor. If your team has no capacity for that cycle, ask DeployOpen for a scoped implementation followed by a support retainer.

How do we bring historical data over from Sumo Logic?

Plan historical data as a separate path from live forwarding. Sumo Logic lets users with the Download Search Results capability export up to 100,000 rows of search results as CSV from the browser, and larger exports require multiple searches over shorter time ranges. That limit makes browser exports suitable for specific investigations, reports or evidence sets, not a full archive. Forwarding of newly ingested logs can go to your own storage, but it does not replay the past. For regulated retention, decide which indices, time ranges and fields must be preserved, export them in batches, verify record counts and hashes, and load them into a clearly labeled historical index. Confirm retention obligations with your compliance team before deleting anything in the source service.

How does DeployOpen scope fixed-price work for an air-gapped build?

DeployOpen works from a written scope in which the deliverables, environments, timelines and responsibilities are agreed before work begins, and most engagements are fixed-scope on that basis. A quote follows from that scope, and DeployOpen does not publish a price list. The scope should name the systems being deployed, the log sources and agents covered, the offline transfer procedure to be built and tested, the historical data approach, the documentation handed over, and any post-go-live support. Ask for changes to be handled as written change requests, and ask what happens if your environment differs from the assumptions in the scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, so confirm which independent assessor will review them.

Which compliance standards can a self-hosted Wazuh deployment support?

Wazuh includes prebuilt dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53, along with file integrity monitoring and vulnerability detection. These views help organize evidence, but they do not make a deployment compliant on their own. For operational technology or utility environments, the NERC CIP-005-7 requirement on Interactive Remote Access through an Intermediate System, and the NERC CIP-013-2 supply chain requirement on software integrity, both shape how the log platform itself is built and administered. Ask your assessor which controls they will test, and ask DeployOpen to map those controls to configuration and evidence, since DeployOpen prepares that material but independent auditors issue the findings.

Moving data from Sumo Logic into an isolated stack

Plan the data move around two Sumo Logic paths that cover different slices of your data. Data forwarding ships newly ingested logs to an object store such as S3 or GCS, so it only carries data from the point you turn it on forward. Browser CSV exports cover history, but Sumo Logic lets users with the Download Search Results capability export up to 100,000 rows per search, so larger exports need multiple searches over shorter time ranges. Before the cutover, confirm with your Sumo Logic administrator which of your sources forward cleanly, which indexes hold the retention you must keep, and how many searches a full historical export would take in practice. The Search Job API path is covered on the export page, so this section focuses on the sequence.

The cutover plan should dual-ship from collectors wherever your network allows it. Configure the existing Sumo Logic collectors to send to the new stack in parallel with the current pipeline, so both systems receive the same events during an overlap period. For an isolated network, the same idea applies at the boundary: a one-way transfer host or diode that carries approved log files inward is the only path, and every package or rule set crossing it should be verified for integrity and authenticity as your procurement controls require. Where dual-shipping is not possible, accept a gap and document it, because the historical CSV export cannot fill a window that was never forwarded. For the mechanics, follow the sibling migration pages rather than this one. The OpenSearch migration page covers installation and index setup, while the Sumo Logic to Wazuh migration page covers agents, rules and compliance reporting. Use those guides to set your steps, then confirm in your own environment whether the target agents and collectors can reach the isolated stack and how often you need to pull offline updates into it.

Risks to plan for in an offline deployment

An air-gapped SIEM stops receiving updates automatically, so every package, rule and patch must cross the boundary by hand. The four risks below connect at that transfer point: what gets carried in, how it is checked, whether the cluster can be upgraded safely, and whether detection content still covers what the managed service once did.

Stale packages after long gaps

An offline OpenSearch cluster and Wazuh server only get fixes when someone brings new media across the boundary. Between transfers, security patches for the indexer, dashboard and agents fall behind upstream. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so a quarterly transfer can miss several of them. Confirm the transfer cadence with your change board, and track the current 4.14 patch level against the Wazuh release notes.

Unverified software entering the boundary

Every package, container image, rule set and vulnerability feed carried across an isolated network is a path for unverified code. Verify checksums and signatures on each artifact before import, and keep a record of who approved each transfer. The NERC CIP-013-2 supply chain control expects procurement processes to address integrity and authenticity of vendor software and patches, which is a useful model even outside the power sector. Ask your team to document the verification steps for the Wazuh offline guide and the OpenSearch tarballs.

No tested rolling upgrade path

A single OpenSearch cluster has no spare capacity to absorb an upgrade failure, and an air-gapped site cannot easily pull a fix back in. OpenSearch supports rolling upgrades from Elasticsearch 6.0 through 7.10 indices, and it targets a new minor version about every eight weeks. Version 1 reached end of life on May 6, 2025. Rehearse each upgrade on a copy of the cluster with the same index mappings and plugins, and confirm the exact upgrade path in the migration guide before you schedule production work.

Gaps in managed detection content

Sumo Logic's managed detection content does not transfer automatically when you move to a self-run stack. Your team must identify which rules, parsers, dashboards and monitors the old service supplied, then rebuild or replace them in Wazuh rules and OpenSearch dashboards. Offline sites also need the rule sets carried in the transfer, which the Security Onion airgap model shows as a bundled practice for NIDS, YARA and Sigma content. Inventory the Sumo Logic detections you rely on and confirm which ones have an equivalent before you decommission the old service.

What to confirm with vendors and your environment before committing

Start with offline support in the exact edition you plan to run. Vendors often gate air-gapped deployment behind paid tiers, so get written confirmation that the edition, license and support terms you select cover disconnected installs. For Wazuh, confirm that the offline installation guide and an offline vulnerability repository match the release line you intend to deploy. For OpenSearch, confirm which install method your security team accepts (tarball, RPM, Debian, Docker, Helm or the Kubernetes Operator) and whether any plugins you need are included in the offline bundle. For Security Onion, confirm which ISO and rule set versions your site will receive.

Next, size the platform against your real numbers. Measure your sustained daily ingest, peak rates, event sizes and the retention periods your regulators and internal policy require, then ask the vendor or your integrator to produce a sizing model from them. Ask who pays for hardware in your environment, whether the Wazuh server and indexer will run as clusters, and how storage grows over the retention window. Confirm your compliance mapping in the same way: the Wazuh dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, so check which control objectives in your framework those views actually satisfy and which you must build yourself.

Finally, agree the update path your security team will accept before go-live. In an isolated network, every package, rule set and vulnerability feed arrives on media that someone must verify, so document how signed artifacts are checked for integrity and authenticity. Confirm the release cadence you will follow for OpenSearch minor versions and Wazuh 4.14 patch releases, how long each version stays in maintenance, and who applies security patches inside your change window. Ask your vendors to commit in writing to how they supply updates for disconnected sites, and record the answer in your supply chain procurement records, including for NERC CIP-013-2 if it applies to you.

How DeployOpen deploys OpenSearch and Wazuh under air-gap constraints

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For a Sumo Logic replacement, we start from the network boundary, the log sources and the evidence your assessors will ask for, then build an OpenSearch and Wazuh stack that runs without internet access.

How we scope

We agree in writing which log sources, retention periods and detection use cases the engagement covers.
We map the air-gap boundary, including how packages, rules and vulnerability data cross into the isolated network.
Most engagements are fixed-scope, with deliverables and timelines agreed before work starts; ongoing support is available as a retainer.

How we build

We install OpenSearch and Wazuh from offline media in your environment, using the deployment methods each project documents.
We configure authentication, role-based access and TLS for node and client traffic before any production logs arrive.
We set up the offline vulnerability repository and test that agent inventories correlate with it without outbound connections.

How we hand over

We document the architecture, the transfer procedure for each package and rule update, and the verification steps performed at the boundary.
We deliver rebuilt searches, dashboards and compliance views, with the configuration kept under version control in your environment.
We run security testing against the deployed stack where scoped, and prepare control evidence for your independent auditors, who issue any reports.

How we support

We plan upgrades around the OpenSearch and Wazuh release and maintenance cycles, so each update is staged and checked before it crosses the boundary.
We back up indices and configuration, and document restore steps for your operations team.
Ongoing upgrades, patch cycles and continuous testing are available as retainers, based on the written scope.