Recorded Future alternative for air-gapped networks

Recorded Future alternative for air-gapped networks: what the constraint requires

A security team on a classified or OT network has no route to Recorded Future's API or TAXII service, so nothing can be pulled live. The practical answer is MISP or OpenCTI, self-hosted inside the enclave and fed by a controlled transfer of exported risk lists in CSV or STIX. The platform is the easier half of the decision. Both products install on infrastructure you already control, and their storage, APIs and sharing controls do not need an internet connection. The harder questions are how each file is approved, who carries it across the boundary, who verifies it, and who answers for a list that is stale or wrong.

The supplied facts do not confirm a Recorded Future offline product or an export path designed for isolated networks, so confirm these points with the vendor before any design work: which risk lists can be downloaded without a live session, whether STIX content can be exported in full or only in increments, whether the subscription terms allow derived data to be stored on isolated systems, and whether any enrichment can run without a callback. The platform side has its own dependencies. OpenCTI needs Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, and all of them, along with connector images and container packages, must be installed from media that crossed the boundary. Missing one of these blocks the whole deployment.

Ownership is the decision that most often goes unassigned. Name a data owner who approves what may cross, a transfer operator who moves the media, a verifier who checks hashes and signatures before import, and a platform administrator who loads the data. NERC CIP-013-2 requires supply chain processes to address verification of software integrity and authenticity for vendor software and patches, and the same discipline fits every package and list carried into the enclave. For OT environments, NIST SP 800-82 Rev. 3 is a useful reference for how to scope that boundary. Illustratively, a weekly CSV transfer that nobody owns will quietly become a monthly one, and the team will not notice until an analyst relies on an outdated indicator.

What an air-gapped network requires from threat intelligence

An air-gapped network changes how intelligence arrives, not what it is for. Each requirement below connects the isolated platform, the transfer path and the people who run it, so the risk lists that cross the boundary remain trusted and traceable.

No outbound internet path

The MISP or OpenCTI host must have no route to external feeds, the Recorded Future API or TAXII endpoints. Every update therefore arrives as a file on approved media or through a one-way transfer point. Confirm with your network team that the platform's DNS, package mirrors and container registries resolve only to internal sources, and that any update tooling is configured for offline use before go-live.

Integrity of every transferred package

Each file, container image and rule set crossing the boundary needs a recorded hash and an authenticity check before import. NERC CIP-013-2 is one example in OT: its supply chain procurement expectations cover verifying the integrity and authenticity of vendor software and patches. Ask your vendors for signed artifacts and keep the verification output with the transfer record.

Controlled vendor remote access

If a vendor needs to reach the isolated platform, the session should pass through an intermediate system with encryption and multi-factor authentication, as NERC CIP-005-7 describes for high and medium impact BES Cyber Systems. Your team also needs a way to detect and disable active vendor sessions. Where no vendor access is needed, document that decision so auditors see it was deliberate.

Traceable record of imported data

Intelligence in an isolated network is only as useful as your ability to show what entered and when. Log each import with the source file name, hash, export timestamp, the person who carried it and the import result in MISP or OpenCTI. These records support incident reviews and the evidence your compliance assessors will ask for.

OT security context for the transfer

NIST SP 800-82 Rev. 3 is the reference guide for operational technology security, and it frames how an intelligence system should sit beside control networks without becoming a path into them. Use it to decide who may move data across the boundary, which systems may consume the output, and how the platform itself is patched and monitored. Confirm its scope with your OT and security owners.

Which open-source platform fits an isolated enclave

MISP is a good fit when the enclave needs to store indicators, correlate them and export them to local tools with little infrastructure. It is licensed under AGPL-3.0, is associated with CIRCL, and its software and taxonomy or galaxy data carry separate licenses, so each can be reviewed on its own terms. Because it has a REST API described in OpenAPI and the PyMISP library, transferred data can be imported and exported by scripts that run entirely inside the boundary.

Export formats: MISP exports STIX 1 and 2, CSV, OpenIOC and NIDS rules for Suricata, Snort and Zeek, which suits sensors and firewalls inside the enclave.
Sync between instances: Events and attributes can synchronize between MISP instances, so a classified site and a higher-trust site can share selected content under granular sharing controls.
Install path: The download page recommends Ubuntu 24.04 with the provided installer for MISP 2.5, with Docker images, Ansible roles, Puppet modules and RPM packages as alternatives.
Offline packages: Confirm which installer dependencies, PHP packages and feed sources must be mirrored before the first build, since the installer expects package repositories.
Trade-off: MISP does not carry a graph model of the kind OpenCTI offers, so relationship analysis depends on correlation and galaxies.

Confirm with your own team whether the enclave will run the installer from an internal mirror or from a prebuilt image.

What is lost without live enrichment on an air-gapped network

Live enrichment and TAXII polling stop at the gap, so every indicator in MISP or OpenCTI is only as current as the last transfer. Lookups that query an external service at the moment an analyst or a SIEM rule fires will return nothing useful inside the enclave. Ask your Recorded Future account team which of your current workflows depend on live API calls, and list them against the transfer schedule. Any detection that assumes a score or risk rating was refreshed within hours needs a documented freshness limit and an owner who knows when that assumption breaks.

What remains is substantial. Stored indicators, their context and their relationships stay in MISP or OpenCTI and are searchable offline. Correlation keeps working on whatever is already in the instance, so new internal sightings from local sensors can still match older imported attributes. Sharing inside the enclave is handled by distribution levels and sharing groups in MISP, or by organization segregation in OpenCTI Enterprise Edition, so different teams see only what they should. Exports such as the CSV, STIX, Suricata, Snort and Zeek formats described on the MISP features page let local SIEM and firewall tools consume the data without a live connection.

What the open platforms do not replace is Recorded Future's own proprietary collection and analyst reporting. MISP and OpenCTI store and organize what you import, but they do not produce new collection. Confirm with Recorded Future, in writing, whether its risk lists, reports and collections can be delivered as offline files for your classification or OT environment, how often, and under what license terms. Also confirm whether any delivered content is restricted from being redistributed inside the enclave, since that affects who can receive it through MISP sharing.

How to deploy MISP or OpenCTI inside an air-gapped enclave

This sequence moves MISP or OpenCTI from a staging network into an isolated enclave with a verified offline install set, a private registry, a first imported dataset, and a rehearsed restore. Each step ends with a check the enclave owner can confirm before moving on.

Build the offline install set on staging
On a connected staging network, the platform owner assembles everything the enclave will need. For MISP 2.5, that means the installer and its OS packages for Ubuntu 24.04, or the Docker images, RPM packages, Ansible role or Puppet module if your standard uses those. For OpenCTI, it means the platform, worker and connector container images plus the dependency images for Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO. Record every image digest and package version in a manifest. The step is done when a second person can read the manifest and match each item to a file in the transfer set.
Scan and verify the transfer set
Before anything crosses the boundary, the security team checks each artifact. Verify published checksums or signatures against the vendor's download pages, scan images and packages with the tools your policy approves, and confirm that the manifest matches the files. This is the control that NERC CIP-013-2 addresses for verifying software integrity and authenticity, if it applies to your environment. The step closes with a signed transfer record listing what was approved, by whom, and on which date.
Carry the set across the air gap
Move the approved set through your documented transfer process, such as a one-way data diode, a controlled removable media procedure, or a cross-domain solution, depending on the enclave's accreditation. Keep the transfer media and manifest together and log the handover. Confirm with your security authority which transfer method is permitted for each classification level. The step is complete when the enclave holds the set and the manifest hash matches the staging copy.
Stand up a private registry and install
Inside the enclave, load the container images into a private registry, then install from that registry rather than public sources. For Kubernetes-hosted OpenCTI, the kubeadm documentation covers listing and pulling control plane images in advance with kubeadm config images list and kubeadm config images pull, and pointing kubeadm init at your registry with the --image-repository flag. For MISP, run the installer or Docker deployment against the local package mirror. Confirm that the first login works, that the services report healthy, and that no step attempts an outbound connection. Keep a record of the outbound-denied test result.
Import the first intelligence export
Bring in the first dataset as a transferred export, such as Recorded Future risk lists in CSV or STIX, converted or loaded into MISP or OpenCTI with the connectors or import tools each platform provides. MISP accepts STIX and CSV imports, and OpenCTI structures its data on STIX 2. Check the object counts against the source export and sample records for correct types, timestamps, and confidence values. Tag the imported data with its origin and handling marking so analysts can see where it came from. The step is done when the counts reconcile and the sample check passes.
Set update cadence and assign roles
Agree in writing how often each feed or export crosses the boundary, who prepares it, who approves it, and who imports it. Assign separate owners for staging, transfer, verification and platform administration, and make sure no single person holds all four. Configure platform accounts and access groups to match, and enable whatever audit logging your edition provides. Record the cadence in the operations runbook. The step is complete when each role has a named owner and the runbook has been approved by the system owner.
Rehearse backup and restore inside the enclave
Take a backup of the database, search index, object storage and configuration, then restore it to a separate environment inside the enclave. For OpenCTI, this covers Elasticsearch or OpenSearch, MinIO and the configuration secrets. For MISP, include the MySQL or MariaDB database and file storage. Time the restore, check that logins, indicator counts and sharing settings come back intact, and record what had to be fixed by hand. Confirm your restore procedure also works for the offline update packages, since you will rely on them after the next transfer. The step is done when a restore has been tested and the findings are filed.
Confirm vendor offline guidance for other tools
Where the enclave also runs adjacent tools, check their own offline documentation before planning their transfers. Security Onion, for example, documents full installs without internet access and updates from newer ISO media in airgap mode, and Wazuh publishes an offline installation guide. Use these as examples of how vendors describe airgap installs, then ask MISP or OpenCTI maintainers and your integrator to confirm which steps apply to your chosen version. The step is complete when each adjacent tool has a documented update path that matches the transfer process approved in the earlier steps.

Evidence assessors ask for under an isolated-network control set

Under an isolated-network control set, an assessor wants to see what crossed the air gap, who approved it, what software received it, and how the receiving instance was configured. The five items below connect those questions to a MISP or OpenCTI deployment. DeployOpen prepares this evidence; independent auditors and certification bodies issue any opinion on it.

Transfer logs with hashes

Each transfer record should list the file name, the export time, the source system, the destination system and a cryptographic hash of the file as it left the source side. Record the hash again on arrival so the two values can be compared. Assessors use this pair to confirm that nothing changed in the media between the two sides. Ask your team to confirm which hash algorithm your review process accepts before the first transfer.

Approved import list

Keep a written list of the feed types, risk list exports and STIX bundles that may cross the boundary, with the source, owner and purpose of each. Anything not on the list should be rejected at the import step. In MISP or OpenCTI, the list should match the connectors and import jobs that are enabled on the receiving side, so the evidence and the configuration agree.

Software bill and version record

For MISP or OpenCTI, record the exact product version, the operating system, the database and search components, and each installed plugin or connector. For MISP, the current recommended line is 2.5, and the project lists Ubuntu 24.04 with its installer as the recommended path. For OpenCTI, record whether you run a regular release or an LTS line, since LTS releases need a specific license key. Also keep the package hashes you verified before import, which relates to the software integrity expectations in NERC CIP-013-2.

Access and sharing configuration

Export the user roles, authentication settings, sharing groups and distribution levels from the receiving instance on a schedule. Assessors will ask who can see imported intelligence and who can push it onward. For MISP, this covers sharing groups and synchronization settings. For OpenCTI, it covers organization segregation and the authentication method, such as SSO, which is a Enterprise Edition feature. Keep dated snapshots so you can show the configuration in force at any past date.

Approval and performer records

Each transfer needs a named requester, a named approver who is independent of the person who performed it, and a named operator who carried the media across. Record the date, the reason and any exception granted. These records show who holds the transfer process, which is the question most often left open when a team relies on one administrator. Confirm with your own security office how many approvers your policy requires.

Questions teams ask before an air-gapped threat intelligence build

Can our own team run the cross-domain transfer, or do we need outside help?

Your team can run the transfer if it has someone who owns the process, the tooling and the approval trail, but many organizations start with outside help to design it. The work is a repeatable pipeline: export from the connected side, validate and hash the files, scan them, carry them across under your data transfer policy, then import into MISP or OpenCTI on the isolated side. Each step needs a named owner. Ask a partner to document the procedure, set up the import jobs and test a full cycle with your security office watching, then decide which steps stay in-house. Under a fixed-scope engagement, the deliverables and handover are written down before work starts.

What drives the effort of an air-gapped threat intelligence build?

Effort rises with the size of the enclave, the number of feeds, the number of sharing partners and the depth of OT integration. A single enclave with one feed and one import path is far simpler than several enclaves with multiple feeds, each feeding detection tools. Sharing partners add trust rules and sharing groups that must be configured and reviewed. OT integration adds change control and testing on systems where a failed update has operational consequences. Ask for each of these as a separate line in the written scope so you can see which items you can remove.

What recurs after go-live in an air-gapped threat intelligence platform?

Three things recur. First, transfer cycles: every update of risk lists or feeds goes through the same export, check and import path, so the cadence is an ongoing operating cost. Second, patching: MISP and OpenCTI, their databases and their supporting services need updates delivered as media or packages across the boundary. Third, licensing and upgrades: OpenCTI LTS releases require a specific LTS license key to use, and MISP 2.5 and later releases need upgrade planning, since the project recommends MISP 2.5 for new deployments and the 2.5.47 release introduced a new database migration system. Confirm the key and upgrade process with the vendor before you plan the cycle.

Should we choose MISP or OpenCTI for an isolated network?

Choose MISP if the main job is collecting, correlating and distributing indicators, with fine-grained sharing and direct export to tools such as Suricata, Snort, Zeek and firewalls. Choose OpenCTI if the main job is a structured knowledge graph on the STIX 2 model, with connectors, a GraphQL API and relationships across reports and actors. Many teams run both: MISP handles the indicator exchange and OpenCTI holds the analyst view. Note that OpenCTI runs on several supporting services, including Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO, which adds components to transfer, patch and back up. MISP's stack is lighter, built on PHP, MySQL or MariaDB and Redis.

What should we ask for in a fixed-scope quote for this build?

Ask for a written scope that names each enclave, each feed or risk list, each import path, each sharing partner and each OT system in scope. Request the deliverables in plain terms: installed platform, documented transfer procedure, validated import jobs, tested rollback and a handover to your operators. Ask how software integrity checks on carried packages are performed, how the transfer is logged, and who approves each cycle. Confirm which items are one-time work and which are ongoing retainers for upgrades, testing and support. Also ask who holds the OpenCTI LTS key or MISP upgrade responsibility after handover.

How do transfer integrity checks relate to our supply chain controls?

Integrity checks on everything crossing an isolated boundary are a direct way to meet supply chain expectations for vendor software and patches. For utilities, NERC CIP-013-2 covers verification of software integrity and authenticity in supply chain procurement processes. Your transfer procedure should record a hash for each file, a scan result, the approver and the import timestamp. Confirm with your auditor which evidence they expect, since DeployOpen prepares controls and evidence for assessments but does not issue audit reports or certifications.

What do we lose without live enrichment on an air-gapped network?

You lose live lookups against external services, so indicators are only as current as the last transfer. Enrichment that depends on connected sources must be replaced by scheduled exports, and the age of each list should be visible to analysts. Expect slower reaction to new indicators and less context for items that arrived after the last cycle. Plan the cadence around your risk tolerance and confirm with your intelligence provider which exports and TAXII collections are allowed for offline use under your agreement.

Who maintains the transfer, and who pays for it

Every crossing of the air gap needs four named roles, and in a small team one person may hold more than one of them. The staging operator pulls the Recorded Future exports on a connected machine, records what was pulled and when, and places the files on approved media. The reviewer checks each package before it leaves the staging side: file hashes, format validation of the CSV or STIX content, and a scan for anything that should not cross the boundary. The enclave owner imports the package into MISP or OpenCTI inside the isolated network and keeps the import log. The platform owner patches the MISP or OpenCTI stack, rebuilds the offline dependencies and decides when a new release is brought across. Naming these people in writing before the first transfer is the cheapest control you will buy, because it shows an auditor who signed each step.

Recurring costs are mostly people time and media handling. Each cycle consumes staging and review hours, the cost of approved removable media and its custody and destruction, and the time the enclave owner spends reconciling imports with existing events. How often you cycle drives this cost more than anything else, so ask your team to price a daily, weekly and monthly cadence against the risk lists you actually use. One-time costs are the build and hardening: the isolated MISP or OpenCTI host, the offline package mirror, the signing and verification procedure, and the runbooks. Platform work on OpenCTI is heavier, since it needs Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage all carried across in the same way, while MISP can often be installed from its own packages. Confirm both figures against your own environment before you budget.

Cost moves up with the number of enclaves, the number of feeds, the strictness of your accreditation, and whether the platform owner must also rebuild dependencies for each release. It moves down when the transfer is automated on the staging side, when the reviewer step uses a repeatable checklist, and when releases are batched on a planned schedule. For any quote, ask the provider to separate one-time build and hardening from annual maintenance, to state who performs each of the four roles, and to show how patch and dependency updates are carried across the boundary. If a regulator or your own policy sets the control expectations, confirm with the assessor which evidence they will want from each role.

Setting an update cadence the enclave can keep

This sequence sets how often each intelligence feed crosses the air gap and how often the platforms inside are upgraded, so the cadence matches both the speed of risk change and the approval capacity of the enclave. The result is a written schedule that the transfer team, the approvers and the platform owners all accept.

Classify each feed by how fast its risk changes
The threat intelligence lead sorts every feed that will cross the boundary into groups based on how quickly its contents go stale. Indicators tied to active campaigns or known exploited vulnerabilities age fastest, while reports on actor tradecraft or long-lived infrastructure age more slowly. Each feed gets a named category and a draft cadence. The step is done when every feed on the intake list has a category signed off by the threat intelligence lead and the enclave security owner.
Measure the enclave approval capacity
The enclave security owner and the transfer approver document how often a cross-domain import can be reviewed, scanned and accepted in practice. This includes staff availability, change windows, and any sign-off the accreditation authority requires for media or file transfers. A cadence faster than this capacity will create a backlog of unreviewed data, so the approval rhythm sets the upper limit. The step is done when the approval calendar is written down and agreed.
Match each feed to a transfer rhythm
Combine the risk categories with the approval calendar to assign each feed a transfer frequency. Fast-moving indicator lists go on the most frequent slot the approvers can sustain, and slow-moving reference material goes on a less frequent slot. Where a feed cannot be carried on a regular slot, record it as on-demand with a stated trigger, such as a confirmed incident. The step is done when the schedule lists every feed, its slot, and its trigger for early delivery.
Plan platform upgrades on a separate track
The platform owner sets the upgrade cadence for MISP and OpenCTI apart from the feed cadence, because upgrades carry their own testing and approval. OpenCTI non-LTS releases ship from daily to weekly, and its LTS releases come every 6 months with one year of support each, so the team should decide whether to follow the LTS line or a faster stream. MISP 2.5 is the recommended line for new deployments, so an enclave instance should start there. The step is done when the upgrade track names the release line for each platform and the owner who approves it.
Confirm the support lifecycle of each release line
Before fixing the upgrade track, the platform owner checks the published support windows for the chosen OpenCTI and MISP lines, and confirms whether an LTS license key is required for the chosen OpenCTI line. A release line that is near end of support forces an upgrade under time pressure, which the enclave may not be able to schedule. Ask the vendor or project to confirm the dates in writing where the public documentation is unclear. The step is done when each platform has a documented support end point and a key holder.
Write the cadence into the transfer procedure
The transfer team adds the feed schedule, upgrade track and emergency trigger to the written transfer procedure that the enclave already uses for media or file imports. Each entry names the source, the expected format, the scanning step and the approver. The procedure should also state what happens when a scheduled slot is missed, so the platform is not left running on stale data without anyone knowing. The step is done when the procedure is approved and a copy sits with the accreditation documentation.
Review the cadence against observed staleness
After the first cycles, the threat intelligence lead compares the age of indicators in the enclave platform with the age of the same data outside the boundary, and records any incident where stale data affected a decision. The review also checks whether approvers are clearing the transfers on time. Changes to the cadence go through the same approval path as the original schedule. The step is done when the review record names each change made and the reason for it.

How DeployOpen builds the transfer and the platform

An air-gapped intelligence program only works when the enclave scope, the transfer path, the platform and the people who run them are designed together. DeployOpen treats these as one fixed-scope piece of work, agreed in writing before any build starts.

Planning the enclave scope

We start by mapping which networks, OT segments and classified enclaves will receive intelligence, which data classes may cross the boundary, and who approves each import. The output is a written scope that names the MISP or OpenCTI instances, the transfer points and the owners on each side. Ask for this scope to be signed off by your security and compliance leads before any hardware or software is ordered.

Implementing MISP or OpenCTI

We install the chosen platform inside your own environment, using the installer or container method your team already supports. For OpenCTI this includes Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, all sized to the documented dependencies. Confirm which version and install path you will standardize on before the build begins.

Building the transfer and its checks

We design the path that carries CSV, STIX or MISP JSON files across the air gap, including file naming, staging, malware scanning and hash verification at each hop. Each imported batch is logged with its source, date and checksum so the receiving team can prove what crossed. Ask how your change control process will approve each transfer.

Hardening the platform

We apply hardening to the operating system, databases, message queues and web tier, and configure authentication through the identity source your organization already uses. Access is limited by role and, for OpenCTI, by organization segregation where your licensing allows it. Confirm with your assessor which hardening baseline they will test against.

Backup and recovery

We set up scheduled backups of the database, search indexes, object storage and configuration, and test a restore on a separate host. Because the enclave may not reach external backup services, backups stay inside the boundary and are copied only under the same transfer controls. Ask for a documented recovery time target that your own team has agreed to.

Documentation and evidence

We write the runbooks, architecture diagrams, transfer procedures and control evidence that auditors and internal reviewers ask for. Evidence is prepared to support assessments, but DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations.

Testing and operator training

We test the transfer path, access controls and platform behavior, and train the analysts and administrators who will run imports and sharing. Testing can include security testing of the platform and of the transfer workflow. Ask which tests are in your fixed scope and which would move to a retainer.

Ongoing support and upgrades

Upgrades, connector maintenance, patch handling and periodic transfer reviews are available as a retainer after handover. This matters because MISP and OpenCTI both release frequently, and each upgrade must be re-tested inside the enclave. Ask for the retainer scope in writing so the upgrade cadence and response expectations are clear before you sign.