Set the intelligence workflow before deployment
OpenCTI represents cyber threat intelligence as connected entities and relationships using a STIX 2.1-aligned model. Analysts can relate reports, indicators, observables, malware, campaigns, threat actors, and other objects instead of treating a feed as an isolated list. That model is most useful when the team has decided how it will assess, enrich, publish, and retire intelligence.
Do not start by enabling every available source. Identify the consumers of intelligence, the operational decisions they make, the required freshness, and the handling restrictions that apply. A detection team may need selected indicators with clear confidence; an investigation team may need reports and relationships; an external-sharing workflow may need stricter markings. Those uses demand different curation.
Create a minimal first use case such as reviewing a report, relating its observables, assigning confidence and marking, and sending approved information to a defined destination. Test the complete path before expanding connectors. This shows whether fields, permissions, and analyst process line up.
Govern connectors and imported data
OpenCTI connectors can import, export, and enrich data. Each connector needs a source owner, credentials, schedule, permitted data handling, expected volume, failure action, and a review date. A connector that succeeds technically can still be wrong for the organisation if it imports unsuitable data, duplicates records, or exports markings beyond their allowed boundary.
Define confidence, markings, labels, retention, expiry, and duplicate-handling practices with analysts. Keep the source and assessment context when practical so a user can understand why an object exists. Automation should not erase the distinction between an unreviewed feed item and intelligence that an analyst has assessed for a specific decision.
Protect connector secrets and give each connector the least access it needs. Separate import, export, and enrichment permissions where supported by the design. Monitor connector failure, backlog, unexpected volume, and changes in source behaviour. An unnoticed failed connector can create a false sense that intelligence is current.
Plan the platform stack and security boundary
A production OpenCTI deployment relies on supporting services described in its current architecture and deployment documentation. Map persistent stores, queues or search components where configured, application services, connectors, ingress, identity, secrets, and backup targets. Give every part an owner. Threat intelligence is operationally sensitive even when individual feeds are public because the relationships and investigations can reveal internal priorities.
Put the application and administrative services behind controlled access. Map roles for analysts, administrators, connector operators, and any consumer system. Test a low-privilege account and document how external or partner access is approved. Network rules should restrict connector and integration paths to intended systems.
Upgrades deserve a lab or representative test. Verify login, a known investigation, connector behaviour, relevant APIs, and backup restoration. Record the application and supporting-service versions that passed. Do not change the platform stack and a wide connector set in one unobservable maintenance window.
Operate intelligence as a maintained service
Monitor application availability, connector status, ingestion backlog, persistent-storage health, search or query errors, authentication failures, and backup results. Pair platform signals with data-quality review: stale feeds, duplicate patterns, expired indicators, and objects missing markings are intelligence issues even if all containers report healthy.
Name operating ownership. Platform staff own availability and recovery; intelligence leads own curation standards and authorised sharing; connector owners own source suitability and credentials. During an incident, these roles reduce the chance that a technical team quietly restores a data set that the analysts no longer trust.
Handover should include architecture, access roles, connector register, data-handling rules, source contacts, backup and restore result, release record, and a list of known limits. Revisit it whenever a new sharing partner or connector changes the intelligence boundary.
OpenCTI deployment decisions
Use this table with analysts and platform owners.
| Area | Decision | Evidence |
|---|---|---|
| Use case | Which investigation or sharing workflow is first? | A complete reviewed object path. |
| Connectors | Which imports, exports, or enrichments are approved? | Connector register with owner, data boundary, and test. |
| Handling | How are confidence, markings, expiry, and distribution applied? | Written curation rules and analyst review. |
| Recovery | Which services and intelligence records return after an incident? | Isolated restore result and accepted limits. |
Questions to ask before connecting feeds
Should every feed item be shared automatically?
No. Sharing should reflect source terms, markings, confidence, policy, and the receiving team's use. Automation needs a defined review and failure path.
Why test connectors with a small scope?
A small test shows mappings, volume, duplicates, credential scope, error handling, and the operational value of a source before it reshapes a shared knowledge base.
What confirms recovery is useful?
Restore the agreed services in isolation, inspect an investigation and access roles, then state what data freshness or connector state recovery does not provide.
Roll out a governed intelligence platform
Choose consumers, first workflow, markings, confidence, identity, supporting services, and approved connectors.
Run a small ingestion and investigation, test roles, source handling, connector failure, API paths, backups, and restoration.
Review connector health, data quality, access, retention, release changes, and sharing arrangements on a scheduled basis.
Handover checks
Retain these records with the intelligence service.
Connector register
Every connector has source owner, credential boundary, data purpose, schedule, failure action, and review date.
Marking test
A restricted user and an integration path demonstrate that handling and sharing rules are applied as intended.
Restore test
The supporting services and agreed intelligence data have been restored in isolation with limits recorded.
