Threat Intelligence Knowledge Graphs: When They Help and How to Design One

A knowledge graph is useful when analysts repeatedly ask who used which infrastructure, how campaigns overlap, what evidence supports an alias, or which assets connect to a threat. It is unnecessary when the need is simple storage, full-text search, or a small indicator list.

Start with three to five real questions and sample answers. If relationships, paths, changing identity, and time are central, a graph may earn its operating cost.

Model Claims, Not Just Things

Define a small controlled set of entity and relationship types. Separate an observed artifact from an assessed cluster, an external alias, and a real-world organization. Put provenance, observation and validity time, confidence, handling, and status on relationships where the claim lives.

Avoid one generic “related-to” edge; it hides the reason a connection exists.

Govern Identity and Time

Use stable internal IDs and retain source-specific labels. Resolve duplicates through explainable rules and analyst review; preserve merges and splits as reversible history. Model first seen, last seen, asserted date, and collection date separately.

Expire or downgrade volatile claims. A domain-address edge valid last year should not silently describe current control.

Pilot the Analyst Workflow

Load a bounded, provenance-rich dataset and answer the original questions. Test search, visualization, evidence inspection, corrections, access control, export, and performance. Include false-connection cases.

Compare investigation time and decision quality with the existing method. Use the infrastructure pivot guide to define relationship thresholds before scaling.