Why air-gapped sites need a self-hosted Anomali alternative
If your disconnected site is reviewing its ThreatStream AirGap renewal or licensing, the core question is this: MISP and OpenCTI can both run without internet access, but feed updates must be carried across the gap by a controlled process, and that process is the part you have to design, staff and audit. Neither platform removes the need to move indicators, rules and software packages into an isolated network. What changes is who owns that transfer and how much of it you can inspect. Anomali publishes a datasheet for ThreatStream AirGap, but the facts available to us do not describe its feature set, update mechanism or support terms, so confirm those details with Anomali in writing before comparing them with a self-hosted design.
Start by listing what the disconnected site actually consumes today: commercial feeds, community sharing feeds, rule sets for network detection, and the platform updates themselves. For each item, write down the source, the transfer method, the person who approves it and the record that proves what was imported. MISP's features cover export to Suricata, Snort and Zeek formats, and OpenCTI connects to MISP and MITRE ATT&CK, so the offline design needs to decide which of these flows are required and which can be removed from the boundary. Ask Anomali which parts of AirGap run locally and which still depend on a cloud service, because the answer determines whether your existing detections keep working during a long disconnection.
The controls that govern the transfer should be decided before any platform is installed. NERC CIP-013-2 requires supply chain processes that address verification of software integrity and authenticity for vendor software and patches, and the same logic applies to threat feeds and platform releases carried across an isolated boundary. Plan for hash verification, a documented transfer media chain, and a staging host that is separate from production. If you are subject to NERC CIP-005-7, check how remote access and the Electronic Security Perimeter apply to the update path, since any maintenance session that crosses the boundary must be controlled as well. Before you request a quote, ask for an offline installation and update procedure, not just a feature list.
What an air-gapped threat intelligence stack must do
A disconnected threat intelligence platform has to work without a live path to the internet, bring feeds and software in through a controlled gate, limit who can reach it remotely, and share intelligence without relying on a cloud service. The cards below set out these requirements, the decisions behind them, and what to confirm before choosing between MISP and OpenCTI.
No runtime internet dependency
Every component the platform needs at run time must be inside the boundary: the application, database, cache, search index, object storage and any enrichment lookups. Many commercial feeds and enrichment calls assume outbound access, so teams should list each outbound call a platform makes and confirm whether it can be disabled. For OpenCTI, that means the search, queue, cache and storage services plus the connectors. For MISP, check which feed fetchers and integrations are optional. Document the result as a dependency inventory before procurement.
Controlled import of updates
Feed content, container images, packages and rules all cross the gap on media or a transfer host, and each import is a point where tampering can enter. Build a repeatable intake step that verifies hashes and signatures, records what was imported and when, and keeps the previous known-good set available for rollback. This is the control that NERC CIP-013-2 addresses for vendor software and patches, and similar intake checks are expected in other sectors. Ask each vendor how it publishes signed releases and checksums.
Software integrity and authenticity checks
Before anything enters the enclave, the team should confirm that the artifact comes from the publisher and matches what the publisher released. Keep a bill of materials for the platform stack, including MISP or OpenCTI, their database and search components, and the connectors. Repeat the check on every upgrade. The MISP download page lists several install routes, including Docker images and packages, so decide which route will be mirrored into the enclave and who signs off on it. OpenCTI LTS releases also need a license key, which should be tracked as an operational dependency.
Remote access through an intermediate system
If vendors or analysts reach the platform from outside the enclave, all interactive remote access should pass through a single intermediate system with encryption and multi-factor authentication. NERC CIP-005-7 sets this pattern for bulk electric system cyber systems, and it is a sound baseline elsewhere. Teams should also be able to detect and end active vendor sessions quickly. For OpenCTI, check single sign-on options and whether they are in the Enterprise Edition. For MISP, confirm which authentication plugins fit your identity provider.
Sharing without live connectivity
A disconnected site still has to exchange indicators with partners, which means sharing must work on a schedule or through an approved transfer. MISP synchronizes events and attributes between instances with granular sharing controls, so a site can exchange data with a peer through a controlled link. OpenCTI supports TAXII and streams, but whether those channels can be run offline or through a gateway depends on your design. Ask each vendor how sharing is authorized, logged and revoked when the link is not always up.
Regulatory scope and evidence
NERC standards apply only to bulk electric system operators and their registered entities. Other sectors cite their own controls, such as NIST SP 800-82 Rev. 3 for operational technology or CMMC requirements for defense contractors under 32 CFR Part 170, so confirm which framework governs your site before designing controls. DeployOpen can prepare systems and evidence for an assessment, but independent auditors issue any audit report or certification. Ask your assessor early which evidence they expect from the import process and access logs.
Which open-source option fits which offline role
This table compares MISP and OpenCTI for disconnected sites on install paths, dependencies, connectors, sharing and licensing, and notes where Anomali's own offline options sit. Read each row as a question to answer for your environment, then confirm the open items before you commit to a platform.
| Decision area | MISP | OpenCTI |
|---|---|---|
| Install paths offline | Ubuntu 24.04 installer for MISP 2.5, plus Docker images, RPM packages, an Ansible role and a Puppet module. Mirror the chosen path's packages into the enclave first. | Container-based deployment with the platform, workers and connectors. Stage all images and packages in your internal registry before the isolation boundary. |
| Core dependencies | MySQL or MariaDB, or PostgreSQL through the newer database migration system in 2.5, with Redis. Confirm which database your team will support long term. | Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. More moving parts to patch offline. |
| Feed and connector behavior offline | Feeds are imported as files or pulled through a sync peer you host. Plan a controlled transfer process for every feed update. | Connectors for import, enrichment, export and stream consumption run as services. Those that call external sources will fail silently unless you disable or point them internally. |
| Sharing between disconnected sites | Granular distribution levels and sharing groups, with synchronization between MISP instances inside the enclave or with trusted partners. | Sharing relies on STIX 2 objects, TAXII-style exchange and platform segregation. Confirm the workflow for moving bundles across the boundary. |
| Licensing for offline features | AGPL-3.0 for the software, with taxonomies and galaxies under CC0 1.0 or BSD-2-Clause. Review AGPL obligations if you modify and expose the service. | Community Edition under Apache 2.0. Audit logs, playbooks, organization segregation, AI insights and SSO for OpenID, LDAP, SAML and certificate or header authentication need the Enterprise Edition License. |
| Authentication in an enclave | Authentication plugins, including OidcAuth, can connect to your internal identity provider. Confirm the plugin fits your IdP before deployment. | SSO is an Enterprise Edition feature. Plan for local accounts or another method if the Enterprise license is not in scope. |
| Anomali AirGap and ThreatStream on-premises | Commercial product. Confirm terms, supported features, update delivery method and license scope directly with Anomali before relying on either. | Commercial product. Confirm terms, supported features, update delivery method and license scope directly with Anomali before relying on either. |
| Adjacent infrastructure: offline Kubernetes or Security Onion | Not a substitute for the TIP. Needed only if the host platform, sensors or detection content also run in the enclave. Confirm supported offline update paths for each. | Kubernetes offline builds use kubeadm image lists and a private registry. Security Onion supports airgap updates through its soup tool. Confirm these fit your hosting model. |
How feed updates cross the gap without internet access
Feed updates reach an isolated MISP or OpenCTI instance only if your team builds the transfer path itself. The usual model uses a connected staging host that pulls feeds, taxonomies and galaxy data, verifies every package, and then carries the verified set through an approved media or cross-domain path into the enclosed network. The staging host is the only place where outbound internet access exists, so its hardening, logging and change control matter as much as the isolated platform. Record a hash for each artifact on the staging host, keep the manifest with the transfer, and have the receiving side re-verify those hashes before import. Your transfer procedure should name who approves each batch, which media is permitted, and how rejected packages are quarantined.
Licensing affects what you can move and how you document it. MISP taxonomies and galaxies are licensed under CC0 1.0 Universal or the 2-clause BSD license, separate from the AGPL-3.0 license on the MISP software, so your transfer record should cover both. For OpenCTI, any connector that pulls from an external source must be configured to read from a local mirror inside the enclosed network, otherwise it will fail or attempt outbound calls. Inventory every connector, its upstream source and its target mirror before go-live, and confirm that each connector can run without internet access in your version of the platform.
The researched facts do not describe a built-in offline synchronization mechanism for either MISP or OpenCTI, so do not assume one exists. Ask each project how its current release expects updates to be applied in a disconnected environment, check the MISP download page and the OpenCTI deployment overview for supported procedures, and confirm the answer against the exact version you plan to run. Also confirm with your own security and compliance team how the transfer path satisfies your change management and software integrity requirements before any production data crosses the gap.
How to deploy MISP or OpenCTI inside an isolated network
This sequence takes a disconnected site from a written scope to a MISP or OpenCTI instance that receives vetted intelligence updates through a controlled transfer process. Each step ends with a check you can record as evidence.
Confirm constraints and scope in writing
The security owner, the network team and the intelligence lead agree in writing which platform is in scope, which data classes will cross the boundary, who approves each transfer and which feeds are required. Record the target network zones, the number of isolated sites and whether any site has a path for removable media. Confirm with your own compliance team whether the boundary falls under a control framework such as NERC CIP-005-7 or CIP-013-2, since those set requirements for remote access and for verifying vendor software before it enters a protected environment. Done means a signed scope document exists and names a single owner for transfers.
Build the offline image and package set
On a connected build host, the engineering team collects every artifact the platform needs: for MISP 2.5, the installer packages, Docker images, or RPM packages the chosen install path requires; for OpenCTI, the platform, worker and connector container images plus dependency images for Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO. Push the images into a private registry inside the enclave so cluster nodes never pull from the internet. Where Kubernetes is used, kubeadm can list and pull control plane images in advance and point at the private registry. Done means a manifest lists every image tag and package, and each item resolves from the internal registry on a test node with outbound access blocked.
Install and harden the platform
The platform team installs MISP 2.5 or OpenCTI on hosts or a cluster inside the isolated zone, then applies the hardening baseline the security team approves: restricted administrative access, TLS with internal certificates, locked-down database and queue ports, and disabled outbound connectors. Confirm MISP 2.5 is the starting line, because MISP 2.4 is end of life and receives security fixes only. For OpenCTI, plan the LTS line deliberately: LTS releases are distributed as container images but require a specific LTS license key, so procure that key before the build step. Done means the health checks pass and a port scan from the isolated network shows no unexpected listeners.
Establish the staging-to-isolated update procedure
Define how new content reaches the enclave: updates are downloaded and verified on a staging system with internet access, each file is hashed with an agreed algorithm, the hashes are checked against the publisher's published values, and the verified bundle crosses through the approved transfer path. Inside the enclave, the import process recomputes hashes before ingestion and logs the result. Security Onion's documented airgap approach, in which updates come from newer ISO media, is a useful model for how a supported update path should look. Done means a written procedure, a transfer log template and one dry run in which a tampered test file is rejected.
Configure authentication for users
Choose how analysts sign in. MISP offers an OIDC authentication plugin, and its README describes the configuration on the 2.5 branch, so confirm the identity provider inside the enclave can reach the plugin's endpoints. OpenCTI supports several authentication methods, but SSO for OpenID, LDAP, SAML, certificate and header authentication is listed as an Enterprise Edition feature, so confirm the licensing before designing around it. Enforce strong credentials and multi-factor authentication for administrators. Done means test accounts with each role can log in, and a denied login for an unauthorized role is recorded in the logs.
Re-point SIEM and firewall consumers
Connect the local consumers that act on intelligence. For MISP, the exports include Suricata, Snort, Zeek and RPZ formats, so generate those feeds and point the sensors at the internal distribution endpoint. For OpenCTI, use the connectors that match your stack, such as the MISP, TheHive or MITRE ATT&CK connectors, and confirm each one can reach only the internal services it needs. Update SIEM content pipelines and firewall policy objects to read from the new source and retire the old one in a controlled cutover. Done means a known test indicator flows from the platform to a sensor or SIEM rule and generates a detection.
Run a full test update cycle
Execute one complete cycle end to end: build a small bundle on the staging side, verify its hashes, transfer it across the boundary, import it, confirm the new indicators appear in the platform, and confirm the detections update on the consumers. Repeat with a deliberately corrupted bundle to prove rejection. Measure the elapsed time of each stage so the operations team has a baseline for planning, and record the results as evidence for the assessment file. Done means the cycle is documented with timestamps, hash results and screenshots, and the operations owner signs off before live feeds are enabled.
Evidence assessors and regulators ask for
An assessor reviewing an offline threat intelligence deployment will want to see where the boundary sits, how data crosses it, and whether the platform is patched and recoverable. The cards below list the records to assemble before the review. DeployOpen prepares this evidence for your environment, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do.
Approved architecture and trust boundary
Document the isolated network, the MISP or OpenCTI hosts, the transfer workstation or media station on the boundary, and every interface that carries data in or out. Show which systems are inside the boundary and which are outside, and who may approve each change. Assessors will check whether the diagram matches the running network, so walk it against live configuration before the review. Reference the electronic security perimeter requirements in NERC CIP-005-7 if your sector applies them.
Update transfer procedure and logs
Record each batch of feed updates, platform packages and rule sets that crosses the gap: who requested it, who approved it, the source, the transfer medium and the import result. Keep the logs from the import host and the transfer workstation together, with timestamps that can be matched. A written procedure that matches what operators actually do is worth more than a generic one. Confirm how MISP and OpenCTI logs are retained in your environment.
Package integrity and provenance records
For every transfer, keep checksums or signatures, the source URL or repository, and the release identifier of each artifact. This is the evidence behind the software integrity and authenticity check that NERC CIP-013-2 asks supply chain processes to address, and the same record helps any assessor trace an indicator or rule back to its origin. Verify packages on the high side before they are installed, and store the verification output with the transfer log.
Version and patch records
Keep a current inventory of the MISP and OpenCTI versions, their dependencies, and the operating system, with the date each patch was applied and the test result. MISP 2.5 is the recommended line for new deployments, and MISP 2.4 is end of life with security fixes only. OpenCTI Community releases are date-versioned and LTS releases carry their own license key, so record which line you run and how long it stays supported.
Access and authentication configuration
Document who holds administrator, publisher and read-only roles on each platform, how users authenticate inside the boundary, and how sharing groups and organization segregation are configured. If you use an identity provider, record its connection settings and the review cadence for accounts. Assessors often ask for a sample of accounts with their approvals, so keep that list current. Confirm which SSO methods your chosen OpenCTI edition supports before you commit to a design.
Backup and restore test results
Keep dated backup jobs for the database, object storage and configuration, along with the restore test that proves they work. For OpenCTI, the restore set spans Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO, so a test that restores only one component does not show recoverability. Record the time taken, the data verified and any gaps found. Ask your team to confirm the recovery objectives they must meet, since those depend on your own requirements.
Questions buyers ask before choosing an air-gapped alternative
What drives the cost of running MISP or OpenCTI offline compared with a ThreatStream AirGap subscription?
The cost is a set of components rather than one licence line. With MISP, the software is free under AGPL-3.0, so the main costs are the servers, storage, the internal or contracted time to install and patch, and the time analysts spend curating feeds. With OpenCTI Community Edition, the software is Apache 2.0, but the platform depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, each of which needs hardware and maintenance. Recurring costs include hardware refresh, updates, and connector upkeep. One-time costs include design, build, hardening and the first offline transfer procedure. Ask any vendor or partner to split the quote into hardware, one-time build, recurring support, and feed curation, and to state which edition and licence keys are assumed. Anomali's prices are not covered here; obtain them from Anomali directly so the two sides can be compared line by line.
How long does an offline threat intelligence deployment take, and what changes the timeline?
The timeline depends mainly on scope, the size of the platform you choose, and how long transfer approvals take. Scope includes how many platforms, data sources, connectors and integrations (SIEM, firewall, TIP sharing) must work offline. Sizing follows the documented OpenCTI requirements: the platform needs at least 2 cores and 8 GB RAM, Elasticsearch or OpenSearch needs 2 cores, 8 GB RAM and 16 GB SSD, and there should be at least one platform node for every 3 workers. Those minimums grow with data volume and user count. Transfer approvals are often the longest step, because every package and feed bundle crossing the boundary may need a security review. Ask the provider for a written schedule with milestones, the assumptions behind it, and the approvals they expect you to obtain.
What does an air-gapped build need from our own team?
Your team needs to supply access and decisions that an outside provider cannot make for you. This includes network and firewall owners who define the isolated enclave, a security owner who approves the transfer process, and the people who will run the platform after handover. Expect requests for a host or virtual machine build standard, identity provider details if SSO is required, and a named owner for feed selection and sharing agreements. Engineers should also plan for a staging environment where software and container images are built and verified before they cross the boundary. Ask the provider which roles they expect from you, how many hours each role should reserve, and which decisions must be made before the build starts.
Can our internal team run an air-gapped MISP or OpenCTI deployment alone?
A capable internal team can do it alone if it has Linux administration, container and database skills, and time to operate the stack. The harder parts are not the install itself but the ongoing work: keeping images and packages current through a controlled transfer process, testing upgrades in staging, and maintaining connectors. MISP offers an installer for Ubuntu 24.04 and other install methods, which helps a small team, but OpenCTI has more moving parts, including workers, RabbitMQ and search. Consider whether your team can cover on-call and upgrades for the full lifetime of the platform. Many organizations split the work: internal staff own operations and analysts, while an external provider handles the build, hardening, documentation and a retainer for upgrades.
Do threat feeds stay current without internet access, and what must we supply?
Feeds stay current only if someone brings updates across the gap on a schedule. Each transfer carries new feed data, software updates and rule sets from a connected staging system into the isolated network. Security Onion, for example, updates from newer ISO media in airgap mode, which shows the general pattern: a verified media or package bundle is moved in, then applied. For MISP, check which feeds and taxonomies you are permitted to use, since taxonomies and galaxy data carry their own licences separate from the AGPL software. For OpenCTI, confirm the licence terms of each connector and any enterprise features you depend on. You must supply the feed subscriptions, the transfer procedure, and the cadence you accept. Ask the provider how each bundle is verified before it is applied.
How does software integrity checking work across an isolated boundary?
Every package, container image and feed bundle that crosses the boundary should be checked for integrity and authenticity before it is installed. NERC CIP-013-2 is an example of a control that asks for verification of vendor software and patches in supply chain processes, and similar expectations appear in many other frameworks. In practice, this means signed or checksummed artifacts, a documented record of what was transferred, and a staging step that reproduces the install in a test environment. Confirm with your auditor which controls apply to your sector before you design the process, because the evidence you need depends on the framework. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification.
What should a quote for an air-gapped threat intelligence build include?
A useful quote lists scope, deliverables and timelines in writing before work starts, since most DeployOpen engagements are fixed-scope. Ask for the components in scope (MISP, OpenCTI, supporting services such as databases, search and object storage), the connectors and integrations to be configured, and the hardening, backup and documentation deliverables. Request a separate line for the offline transfer procedure, the staging environment, and any compliance evidence work. State which assumptions the quote depends on, such as sizing, data volume, and the approvals the client will obtain. Finally, ask what is one-time and what recurs, including retainers for upgrades, support and continuous testing. DeployOpen does not publish a price list, so a quote follows from the written scope.
What the open-source stack covers and what it leaves to you
The open-source stack covers the platform, the sharing mechanics and the data model, but it does not come with a curated commercial feed marketplace. The public facts for MISP and OpenCTI do not show an equivalent of Anomali's feed catalog, so feed sourcing, vetting, curation and licensing become your responsibility. Before you commit, inventory every feed your detections depend on, confirm the license terms for each one, and confirm whether any feed can be carried across the gap in an air-gapped setup. MISP ships default intelligence feeds and shareable taxonomies and galaxies, which are licensed separately from the AGPL-3.0 software license under CC0 1.0 Universal or the 2-clause BSD license, so check each dataset's terms on its own. Expect to spend ongoing analyst time on deduplication, scoring and expiry of indicators.
Partner sharing is where MISP is strongest on paper. MISP synchronizes events and attributes between instances, and its distribution levels and custom sharing groups let you limit what each partner sees, down to individual attributes. In an air-gapped site, synchronization with the outside world is replaced by controlled transfer, so decide early which sharing groups you will keep and who approves each import. OpenCTI supports TAXII collections and live streams for exchange, but confirm which ingestion paths your partners use before designing around them. OpenCTI Enterprise Edition adds audit logs, playbooks, organization-based segregation, full text indexing, AI insights and SSO options, and these are governed by the separate OpenCTI Enterprise Edition License, so get that license reviewed by your legal team before you rely on any of those features.
Finally, plan the operational work that the vendor normally absorbs. You are responsible for the platform hosting, backups, upgrades and access control, and for proving those controls to an assessor. For a MISP deployment, confirm the installation path you will use, since the project lists Ubuntu 24.04 with its installer, Docker images, RPM packages, Ansible and Puppet as options, and check which release line your change control approves. For OpenCTI, the Community Edition is Apache 2.0, while LTS releases require a specific license key, so budget for that key and its renewal. Ask your integrator to document who approves feed imports and sharing changes, because those decisions carry most of the risk in a disconnected environment.
How DeployOpen deploys MISP and OpenCTI under air-gap constraints
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including disconnected networks. For an air-gapped threat intelligence stack, we start with what the isolated site needs to receive, verify and act on, then build the transfer path and the platform around that requirement.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which feeds, sharing partners and SIEM or firewall integrations must work offline.
- We confirm whether MISP, OpenCTI or both fit the sharing and analysis needs of the enclosed network.
How we build
- We design the offline update path, including how feed bundles and platform packages cross the isolation boundary.
- We test package integrity and authenticity checks at each transfer step before any content enters the enclosed network.
- We size and deploy the platform components, such as databases, search and storage, and test detections against sample data.
How we hand over
- Handover includes architecture, runbooks for offline updates and recovery, and the configuration record for each component.
- We document the transfer procedure and evidence trail so your security and compliance teams can review each import.
- Test results and open items are delivered in writing, with the client's own staff trained to run the procedure.
How we support
- Ongoing support, upgrades, backups and continuous testing are available as retainers.
- Upgrade planning covers platform release cycles and the license terms of the edition you choose.
- Confirm with your team and vendors which features your chosen edition supports offline before the scope is signed.
