OpenCTI security hardening

In OpenCTI, access is decided by the markings on each object and the groups that each user, API token and connector belongs to. Markings are STIX marking definitions attached to entities, relationships and observables, most often TLP levels or custom statements your team defines. A group carries the markings it may read and the capabilities it may exercise, so an identity can see an object only when its group covers every marking on that object. Tokens and connectors authenticate as identities too, so their group membership decides what they can read and write. Before relying on this model, confirm in your version's administration documentation how group-to-marking rules are configured and whether a group can be limited to read-only access.

A marking applied at ingestion is only as good as the rules that enforce it. Three failure modes appear repeatedly. The first is the unmarked import: an object that arrives without a marking can fall back to a default visibility broader than the team intended, so test imports with no marking and check which groups can see the result. The second is the over-privileged connector: a connector token placed in a broad administrative group can create, edit or delete data well beyond its feed. Give each connector its own group with only the capabilities it needs. The third is inconsistent marking. One feed may set a TLP level on every indicator while another leaves the field blank, and enrichment connectors may propagate or drop markings differently. Write a marking standard for each connector and check a sample from every feed against it.

Organization-based data segregation, an Enterprise Edition feature according to Filigran's Enterprise Edition documentation, changes the picture because it adds ownership by organization on top of markings. That matters when several teams or partner organizations share one instance and must not see each other's material by default. It also means your access design has two layers that must agree, and a permissive rule in one layer can be undermined by an incomplete rule in the other. Confirm exactly how your edition evaluates markings, organization ownership and group capabilities together, including how objects with no organization are treated and whether sharing settings override segregation. Do not assume the Community Edition enforces these rules the same way.

Verify the model before sensitive data arrives. Create a test account for each group and a test token for each connector, then load sample objects at every marking level, with and without markings. Record what each identity can read, create, edit and delete, and repeat the check after every upgrade, since permission behavior can change between releases. Ask the people accountable for intelligence handling to approve the marking standard in writing, because a configuration that passes a technical test can still disagree with how your organization classifies its sources. Keep the test results as evidence for your access review.

The purpose of this section is to turn each hardening control into a test with a stated expected result, run against the deployed environment and recorded as evidence. Start with access. Send unauthenticated requests to the web application and the GraphQL API and confirm both refuse them. Sign in with an account outside the group that owns a restricted dataset and confirm that object does not appear in search, entity views or API responses. Create an API token for a test user, revoke it in the platform, and confirm the next request made with that token fails. Keep the request, the response and the timestamp for each case.

Connector tokens need their own tests because connectors often run unattended for long periods. For each connector token, attempt actions outside the role it was issued for, such as creating or deleting entity types or writing to a group it should not reach. Each attempt should be refused. Next, test the network boundary. From a host outside the private network, attempt to open connections to Elasticsearch or OpenSearch, Redis, RabbitMQ, the S3-compatible object store and any management interface of each. The expected result is no route, or a refused connection. Only the platform's own ingress should be reachable from users' networks, and you should confirm that against your firewall rules rather than assume it.

Next, check transport and access rules. Validate the platform's TLS certificate chain and hostname from a client that does not trust any private shortcuts, then attempt connections using older protocol versions and weak cipher suites. Each downgrade attempt should fail. For marking-based access, create test intelligence carrying a restricted marking, owned by a group, and confirm that users outside that group cannot see it through the UI, search, graph views, exports or the API. Finally, perform administrative actions, token creation and revocation, and a sign-in failure. Confirm each appears in the audit log with the actor and time. Audit logs and organization-based segregation are Enterprise Edition features, so confirm your licence covers them before you plan these tests.

The fail-safe check matters as much as the happy path. Simulate the identity provider being unreachable, an expired or missing platform certificate, and an unavailable secrets store, one at a time, during a controlled window. In each case the expected result is that sign-in is refused and the platform does not serve content through a weaker route. Review the configuration for fallbacks you may have enabled without noticing, such as local users, proxy header authentication or client certificate settings alongside SSO. Confirm with your version's documentation how the platform behaves when a strategy fails, and record what you observe.

After these checks, commission an independent penetration test or security assessment of the deployed environment. Ask the tester to cover authentication bypass, authorization between groups, marking leakage, connector token scope, exposed dependencies and TLS configuration, and agree the scope and rules of engagement in writing before testing begins. Internal checks show that your controls behave as designed, while an independent tester looks for the paths you did not think to test. Retest every finding after remediation, and keep the report with your change records. DeployOpen performs application, infrastructure and API security testing, but the assessor should be separate from the team that configured the platform.

Hardening only holds if someone checks it on a schedule. Start by setting a fixed review cadence for OpenCTI audit logs and the API token inventory, with a named owner for each. Audit logs and activity monitoring are part of the Enterprise Edition, so confirm your license covers them before you design the review process. During each review, check which accounts created tokens, which connectors use them, whether any token belongs to someone who has left, and whether any token has broader access than its connector needs. Record the findings in a short, dated log so the review itself becomes part of your operating evidence.

Rotation and patch tracking come next. Rotate connector and API tokens, RabbitMQ and Redis credentials, S3 access keys and TLS certificates on a schedule your change process approves. Test each rotation in a non-production environment first, because some connectors need a restart to pick up new credentials. Track the running OpenCTI version alongside Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO versions. Note that OpenCTI LTS releases receive only critical bug and security fixes after stabilization, while non-LTS releases ship from daily to weekly. Decide in advance who triages each release, how quickly security fixes are applied, and how you confirm that your LTS license key remains valid.

Backups must cover every stateful dependency, not only the platform. Plan to back up the Elasticsearch or OpenSearch indices, the object storage that holds uploaded files and exports, and the configuration needed to rebuild the platform. Decide whether Redis and RabbitMQ state must be preserved or can be rebuilt, and document that decision. Encrypt backups at rest and in transit, and store encryption keys separately from the backup copies. Confirm the backup and restore procedure for each component against its vendor documentation. Then run restore tests on a regular schedule in an isolated environment, and verify that the platform starts, data counts match and stored files open correctly.

Documentation is what lets an auditor or a new engineer understand the system. Maintain a configuration baseline that records authentication settings, network boundaries, TLS settings and role assignments. Keep the marking taxonomy in a versioned file, so every marking used for sensitive intelligence has a documented owner and purpose. Maintain a connector credential inventory that lists each connector, the token it uses, its permitted scope and its owner. Add an exception register for every deviation from the baseline, with the reason, the compensating control, an approver and a review date. Confirm your own change-control and evidence requirements before you finalize these records. DeployOpen can prepare the runbooks, baseline and evidence, but independent auditors and certification bodies issue audit reports and certifications.