Threat Intelligence
Threat intelligence in System9 is the indicator and campaign surface that sits beside threat detection: where detection correlates events into alerts, intelligence manages the indicators of compromise (IOCs), campaigns and techniques those alerts are matched against. It runs on the same governed substrate as everything else, so an indicator carries its classification and its authorship the whole way, and every read and write is gated and recorded.
The reachable slice: a governed indicator surface
What is available today is the indicator-and-campaign machinery on a single cell, reached through the Security Operations console behind a node oversight gate:
- Indicator (IOC) lifecycle management over a durable indicator store, create, enrich, age and expire indicators across the common types (IP, domain, URL, hash, email, filename, registry key).
- Built-in enrichment of indicators from local context, without reaching out to an external service.
- Campaign tracking and a security knowledge graph connecting indicators, entities, campaigns and techniques, with technique mapping and relationship traversal over durable graph storage.
- A local indicator propagation engine that publishes, receives and manages propagated indicators with a confidence calculator, plus a periodic pruning worker that ages out expired propagated indicators so the working set stays bounded.
Every one of those reads and writes is authorized through a node oversight
permission gate (security.intel.read / security.intel.write), classified
under the classification ladder, and
recorded on the tamper-evident ledger.
How an indicator flows and is governed
Figure: the threat-intelligence flow. An indicator enters lifecycle management and enrichment (green), joins the knowledge graph, and is managed by the local propagation engine, with every step written to the tamper-evident ledger. The cross-cell sharing mesh (amber, dashed) is a fail-closed stub, and external feed ingestion (cyan, dashed) has no backend.
Table equivalent
| Element | Status | What is honest to say |
|---|---|---|
| IOC lifecycle management | Wired | Create, enrich, age and expire indicators on a durable store |
| Indicator enrichment | Wired | Local, built-in enrichment: no external call |
| Campaign tracking + knowledge graph | Wired | Indicators, entities, campaigns and techniques, with traversal |
| Propagation engine + pruning worker | Wired | Publishes, receives and prunes propagated indicators locally |
| Oversight + classification + audit | Wired | Every read/write gated, classified and recorded |
| Cross-cell intel sharing mesh | On the roadmap | Fail-closed stub; refuses to run unless stub-mode is acknowledged |
| Threat aggregator | On the roadmap | The second fail-closed stub worker in the same gate |
| External feed subscriptions (STIX/TAXII) | Wired | A stix_taxii connector type on the served connectors route, with a real TAXII fetcher and a per-connector health read |
Why the honest boundary is the right lead
A threat-intel product that quietly ships a non-functional sharing worker is worse than one that ships none: it reports "active" while no indicator ever crosses a cell, and every operator who trusts it is exposed. System9 makes that failure mode impossible to hide, the sharing worker refuses to construct itself unless an operator has explicitly acknowledged that it is a stub. So the claim we make is the claim we can stand behind: a governed, classified, audited indicator surface on the cell, with cross-cell sharing named as owed work rather than implied.
Across the deployment matrix
The reachable slice runs entirely on a single cell, the indicator store, enrichment, knowledge graph and propagation engine are local, so it holds sovereign and air-gapped with no coordinator, and it is unaffected by the loss of a network. That same locality is the boundary: because the cross-cell sharing mesh is not reachable, the multi-cell story is each cell governs its own indicators, not one shared intel picture across cells. On an air-gapped cell, external feeds are unreachable by definition, and a connected cell subscribes to them through the connectors route.
Related topics
- Threat detection, the OCSF + Sigma correlation surface that raises the indicators this manages.
- Incident response, what happens once an indicator drives a raised posture.
- Security Operations overview, the pipeline and console this sits in.
- Audit and tamper-evidence, the ledger every indicator read and write is recorded on.