Most threat intelligence programmes collect far more indicators than they can relate to actors, campaigns, techniques and their own incidents, so analysts end up with lists instead of knowledge. OpenCTI, developed by Filigran, is an open source platform that stores threat intelligence as a STIX 2.1 knowledge graph, so every indicator, malware family, intrusion set and ATT&CK technique is an entity with typed relationships. This guide explains the data model, connectors, access controls and deployment dependencies, how to feed SIEM and SOAR from it, what the Community and Enterprise editions include, and how to secure the many connector tokens it relies on. It is written for CTI analysts, SOC engineers and the platform teams who run OpenCTI, and is based on the OpenCTI documentation, the GitHub repository and Filigran's product pages.
Key takeaways
- A graph, not a list: OpenCTI models STIX 2.1 domain objects, cyber observables and relationships as nodes and edges, so analysts can pivot from a hash to the malware, actor and technique behind it.
- Connectors do most of the work: external import, enrichment, file import, file export and stream connectors bring data in and push it to SIEM, SOAR and EDR tools.
- Every connector is a machine identity: each one authenticates with a platform user's API token, so give each its own service account, the Connector role and a stored, rotated token.
- Markings and confidence are access controls: allowed markings, max shareable markings and max confidence levels per group decide who sees and who can overwrite what.
- Know the licence boundary: the Community Edition is Apache 2.0; audit logs, playbooks, organisation segregation and UI-based SSO configuration sit in the separately licensed Enterprise Edition.
What the tool does
OpenCTI is a web application with a GraphQL API that stores and visualises technical and non-technical threat information. Its knowledge schema is based on STIX 2.1: STIX Domain Objects (attack patterns, malware, threat actors, intrusion sets, campaigns), STIX Cyber Observables (IP addresses, domain names, file hashes) and STIX Relationship Objects (relationships and sightings). The documentation's own example links the intrusion set APT28 to the malware Drovorub with a "uses" relationship. OpenCTI extends STIX with extra types such as cryptocurrency wallets, user agents, channels, events and narratives, and relationships such as "amplifies" and "publishes".
Core concepts
| Concept | What it does | Why it matters |
|---|---|---|
| Knowledge graph | Entities as nodes, typed relationships as edges | Analysts answer "what else is linked to this" instead of searching flat lists |
| Containers (reports, groupings, cases) | Group entities and observables around a source or investigation | Keeps provenance: which report said APT28 used this domain |
| Marking definitions | TLP and custom markings on objects | Groups have allowed markings (what they can see) and max shareable markings (what they can share) |
| Reliability | Trust in a source, defaulting to the NATO Admiralty scale (for example "B - Usually Reliable") | Separates trust in the source from trust in the claim |
| Confidence | Credibility of a piece of information, 0 to 100, labelled by Admiralty, Objective or Standard templates | A user whose max confidence is below an entity's confidence cannot update or delete it |
| Custom dashboards | Widget-based views, private to the creator until shared with View, Edit or Manage access | Widgets respect each viewer's data rights; dashboards export and import as JSON |
TLP 2.0 from FIRST (TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN, TLP:CLEAR) is the usual marking set, and in OpenCTI markings are enforced through group settings, so a group that is not allowed TLP:RED does not see TLP:RED objects. See the STIX and TAXII Guide for the underlying standard.
Connector types
| Type | Direction | Examples |
|---|---|---|
| External import | Pulls from an outside source, converts to STIX 2.1, imports through workers | MITRE ATT&CK, MISP, open and commercial feeds |
| Internal enrichment | Runs on new objects or on request and returns a STIX bundle with more context | Observable reputation and passive DNS lookups |
| Internal import file | Extracts entities from uploaded files such as reports or STIX files | PDF reports, STIX bundles |
| Internal export file | Exports data to CSV or STIX 2.1 JSON | Analyst exports for partners |
| Stream | Consumes the live event stream to feed third party tools, some bi-directional | SIEM, XDR and EDR integrations that push back sightings or alerts |
Filigran states that more than 400 connectors exist, naming Splunk, Microsoft Sentinel, CrowdStrike and Tanium among the export and stream targets.
Defender use cases
- Central CTI knowledge base: import ATT&CK, sector advisories and vendor reports, then relate them to your own incidents so the team can see which actors and techniques recur. See the Threat Intelligence Guide.
- Indicator distribution to detection: stream connectors push indicators to the SIEM and EDR, and bi-directional connectors return sightings, closing the loop on which indicators actually fire. See the SIEM Guide.
- SOAR enrichment: playbooks in a SOAR query OpenCTI's GraphQL API for context on an observable during triage. See the SOAR and Security Automation Guide.
- Threat-informed hunting: start from an intrusion set relevant to your sector, list its attack patterns and build hunts and detections for the techniques you cannot yet see. This is where behaviour outlasts indicators; see the Indicators of Compromise vs Indicators of Attack Guide and the Threat Hunting Guide.
- Working with MISP communities: the MISP connector imports events, optionally creating a report per event, filtered by tags and start date, on a polling interval. Many teams use MISP for exchange and OpenCTI for analysis. See the MISP Threat Sharing Guide.
- Incident case management: track incidents and response cases in the same graph as the intelligence that explains them. See the Incident Response Guide.
Deployment and safe use
OpenCTI can be deployed with Docker Compose (Docker Swarm for scaling), manually from release packages, or with community-maintained Helm charts and Terraform; Filigran also offers the Enterprise Edition as SaaS. The documentation recommends running every component, including dependencies, in containers or on managed cloud services in production.
| Component | Role | Settings the docs call out |
|---|---|---|
| Platform (Node.js) | Web UI and GraphQL API, port 8080 in Docker, 4000 in a manual install | 8 GB default memory limit, changed with NODE_OPTIONS=--max-old-space-size |
| Elasticsearch or OpenSearch | Primary data store and search | Set vm.max_map_count on the host; Filigran recommends thread_pool.search.queue_size=5000; memory via ES_JAVA_OPTS |
| RabbitMQ | Message queue between connectors and workers | max_message_size = 536870912, consumer_timeout = 86400000 |
| Redis | Cache and event stream | Stream defaults to 2 million entries, around 8 GB of memory |
| S3-compatible storage | Uploaded files and exports | MinIO or a fork such as Silo |
| Workers | Python processes that write queued bundles into the platform | Scale the number of workers with ingestion volume |
| Connectors | Separate containers per integration | OPENCTI_URL and OPENCTI_TOKEN |
A phased rollout
- Write intelligence requirements first: which actors, sectors and technologies matter, and which consumers (SOC, IR, leadership) need what. Without them the graph fills with unused feeds.
- Stand up a non-production stack: generate
OPENCTI_ADMIN_TOKENas a UUID withuuidgen(the container will not start otherwise), set a strongOPENCTI_ADMIN_PASSWORDandOPENCTI_ENCRYPTION_KEY, keep them in a secrets store rather than a committed.envfile, and put the UI behind TLS. - Design groups and markings: define groups with roles, allowed markings, max shareable markings and max confidence before inviting users. Use SSO for people.
- Add connectors one at a time: start with ATT&CK and one or two trusted sources, watch queue depth and worker throughput, then add more. Each connector gets its own service account.
- Pilot one detection stream: push a filtered indicator set to a test SIEM index in alert-only mode and measure false positives before production.
- Back up and plan rollback: snapshot the Elasticsearch or OpenSearch data and S3 volumes before upgrades; roll back an upgrade by restoring the snapshot with the previous image versions, and roll back a noisy connector by stopping its container and deleting what it imported.
Connector tokens and service accounts
OpenCTI's connector documentation is explicit: use a dedicated user for each connector, named in the form "[C] Name of the connector", place it in the default Connectors group with the Connector role, and generate a token for it. OpenCTI supports service accounts, technical users with no password that cannot log in through the UI and authenticate only by API token. Connectors exchange the token for a short-lived JWT, and since OpenCTI 6.6.0 token connections do not create persistent sessions. Export file connectors are the exception: they act on behalf of the requesting user and need an administrator account with bypass capability, so protect that token most carefully.
- One token per connector: a leaked shared token would let an attacker write false intelligence into every consumer downstream.
- Limit API capabilities: programmatic access requires the "Allow token usage" and "API usage with authorization headers" capabilities; grant them only to accounts that need them.
- Store and rotate: keep tokens in a vault and inject them at runtime. See the Secrets Management Guide and the Service Account Security Guide.
- Set confidence for connectors: a connector's max confidence decides whether it can overwrite analyst-curated objects. Keep feed connectors below analyst levels.
Detection and hardening value
OpenCTI supports NIST CSF 2.0 ID.RA-02 and DE.AE-07, NIST SP 800-53 PM-16 and PM-16(1), RA-10 Threat Hunting and SI-4 System Monitoring, and ISO/IEC 27001:2022 Annex A control 5.7 Threat intelligence.
| Control area | OpenCTI capability | Framework reference |
|---|---|---|
| Receive and record threats | Import connectors, reports, knowledge graph | CSF ID.RA-02, ID.RA-03; ISO 27001 A.5.7 |
| Share intelligence automatically | Stream and export connectors | SP 800-53 PM-16(1) |
| Integrate into analysis | SIEM, SOAR and EDR enrichment | CSF DE.AE-07; SP 800-53 SI-4 |
| Hunting | Actor to technique pivots, ATT&CK mapping | SP 800-53 RA-10 |
| Protect the platform | Roles, capabilities, service accounts, markings | SP 800-53 AC-6, IA-5 |
| Audit | Activity monitoring (Enterprise Edition) | SP 800-53 AU-2 |
What to monitor: API use by connector tokens from unexpected hosts (ATT&CK T1078 Valid Accounts), creation of new tokens or administrator users, changes to group markings and confidence, RabbitMQ queue depth and worker errors, and Elasticsearch or OpenSearch cluster health. Without the Enterprise Edition's activity monitoring, rely on reverse proxy and container logs for API access records.
Metrics:
- Share of indicators pushed to detection tools that receive at least one sighting.
- Percentage of high priority intrusion sets with mapped attack patterns and a detection for each.
- Connector ingestion lag (source publication to availability in the graph).
- Number of internal incidents linked to actors or campaigns in the graph.
- Percentage of connector accounts that are dedicated service accounts with rotated tokens.
Track these against the Threat Intelligence Maturity Model.
Common failure patterns
- Feed hoarding: dozens of import connectors with no requirements, filling the graph and the SIEM with unread indicators.
- Shared admin token: every connector configured with the admin token from the compose file, so any one compromised container controls the platform.
- Undersized dependencies: skipping
vm.max_map_countor Redis memory sizing, which shows up as stalled queues and failed ingestion. - Confidence left flat: feeds overwrite analyst assessments because every account has the same max confidence.
- Assuming Enterprise features: planning audit logging or organisation segregation on the Community Edition, where they are not included.
Alternatives
| Option | Strength | When it fits |
|---|---|---|
| OpenCTI Community Edition | STIX 2.1 knowledge graph, all open source connectors, Apache 2.0 | Teams with engineering capacity that want analysis depth without licence cost |
| OpenCTI Enterprise Edition | Adds activity monitoring, playbooks, organisation segregation, authorised members, full text indexing, AI features, PIRs and UI SSO configuration | Multi-tenant or regulated deployments that need audit and segregation; free for development, research and charities, included in Filigran SaaS |
| MISP | Peer to peer sharing with distribution levels and sharing groups | Exchanging indicators with ISACs and CERTs. See the MISP Threat Sharing Guide. |
| Commercial threat intelligence platforms | Bundled premium content, scoring and vendor support | Large programmes with budget. See the Threat Intelligence Platform Buyer's Guide. |
| SIEM native threat intelligence | No extra platform | Small teams consuming a handful of feeds |
Licensing: OpenCTI is open core. The Community Edition is Apache License 2.0; Enterprise Edition code lives in the same repository under the OpenCTI Enterprise Edition License, and files without an EE licence header are Community Edition. On-premises Enterprise use requires a Filigran agreement. Check the current edition pages before you rely on a feature.
Practitioner checklist
- Document intelligence requirements before enabling import connectors.
- Generate the admin token as a UUID, store all bootstrap secrets in a vault and remove them from compose files.
- Create one "[C]" service account per connector in the Connectors group, with its own token.
- Protect export connector accounts, which need administrator bypass, as the most privileged tokens.
- Define groups with allowed markings, max shareable markings and max confidence before onboarding users.
- Size Elasticsearch or OpenSearch, RabbitMQ and Redis to the documented settings and monitor queue depth.
- Pilot stream connectors to the SIEM in alert-only mode and measure sightings and false positives.
- Snapshot data volumes before every upgrade and test restores.
- Confirm which features you rely on are Community or Enterprise Edition.
Standards and references
- OpenCTI Documentation: Data Model
- OpenCTI Documentation: Installation
- OpenCTI Documentation: Connectors
- OpenCTI Documentation: Users and Role-Based Access Control
- OpenCTI Documentation: Reliability and Confidence
- OpenCTI Documentation: Enterprise Edition
- GitHub: OpenCTI Platform repository
- FIRST: Traffic Light Protocol (TLP) 2.0
Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Intelligence Platform Buyer's Guide · Threat Intelligence Maturity Model · Indicators of Compromise vs Indicators of Attack Guide · STIX and TAXII Guide