A threat-intelligence platform becomes useful when analysts can answer three questions quickly: What is this? Why should I trust or restrict it? and What is the next defensible action? The Intelligence Library is designed for that path. It is the tenant-owned search and provenance view for normalized MISP, OpenCTI, and STIX 2.1 data.

The Intelligence Library complements the Threat Library and CTI Intake workflow. It helps you browse normalized source material, inspect provenance and relationships, assemble a bounded graph, and create a draft hunt candidate. It does not replace the analyst review that determines relevance, telemetry, hypothesis, expected evidence, or whether an item may enter automation.

Know which workspace answers which question

Use the Intelligence Library when you need to find and understand imported intelligence: indicators, observables, reports, malware, threat actors, campaigns, ATT&CK techniques, provider identifiers, tags, and relationships. Use the Threat Library and CTI Intake when you need to record the canonical analyst disposition and operating decision.

That separation protects provenance. Importing an entity does not make it relevant. Viewing an ATT&CK relationship does not make it applicable to the environment. Completing a review does not rewrite the source marking or automation policy. Creating a hunt candidate does not run a query or call an AI model.

Start with a precise search strategy

The fastest search is often a short exact fragment tied to the source: a report or event ID, provider object ID, domain, IP address, URL, hash, malware name, campaign label, threat-actor name, or ATT&CK technique such as T1059.

Then add filters deliberately:

  • Source narrows the result to one configured integration or file-import source.
  • Type distinguishes reports, indicators, observables, malware, actors, techniques, and other normalized entities.
  • Minimum confidence reduces low-confidence material without treating confidence as truth.
  • ATT&CK finds normalized technique mappings.
  • Tag, actor, campaign, or malware narrows the analytical context.
  • Status helps separate active, revoked, expired, or other lifecycle states.
  • Rows controls a bounded page size of 50, 100, or 250 results.

Apply one or two high-signal filters first. Over-filtering can hide useful related context; an unfiltered keyword can return too much noise. If a search returns nothing, clear Source and Type before broadening the term. Search totals and pagination remain server-calculated and tenant-scoped.

Read provenance before reading the graph

Open the entity detail and verify the provider, integration, import run, provider and source identifiers, source organization, original source reference, markings, distribution restrictions, confidence, lifecycle, validity window, and last-updated time.

These fields determine what the entity means and what you may do with it. An IOC without provenance may still be technically valid, but you do not know whether it is current, restricted, revoked, duplicated, or detached from the report that gives it meaning.

Pay special attention to:

  1. Marking and distribution. TLP and source restrictions control who may see the record and whether it can cross an external-AI boundary.
  2. Lifecycle. Revoked or expired items can remain valuable historical context but should not be treated as current instructions.
  3. Confidence. Confidence is a source assertion, not proof. Compare it with evidence, currentness, and relationship quality.
  4. Canonical source. Confirm which Event or Report the entity belongs to before selecting multiple entities for one candidate.
  5. Import state. A content change can supersede an earlier review, so verify that the review matches the current canonical artifacts.

Source managers can inspect bounded sanitized provider metadata when troubleshooting. That view is intentionally restricted and collapsed by default. Credentials and credential-shaped values should never appear in the entity page.

Use the relationship graph as a question, not a picture

The graph begins with a bounded one-hop view. Large indicator or observable branches are grouped so a high-volume report remains usable. Expand only the branch that helps answer the current analytical question.

A productive graph session has a purpose. For example:

  • Which observables are directly related to this report, and which relationship describes the link?
  • Which ATT&CK techniques are explicitly mapped, and are they relevant to the customer’s telemetry?
  • Does a domain connect to an infrastructure cluster, certificate, malware family, or campaign that changes priority?
  • Which relationships are unresolved, low confidence, restricted, or too old to support action?
  • Which visible entities belong in Hunt Context, and why?

Select a grouped observable card to expand that branch. Select an entity to merge its authorized one-hop relationships. Double-click an entity to open its detail. Use node type, relationship, minimum confidence, marking, and search filters to reduce the canvas. The accessible relationship table below the graph preserves exact values when visual labels are shortened.

The graph is intentionally bounded. An initial response can include up to 60 provider nodes and 120 edges; the merged browser view is capped at 100 nodes and 180 edges. A partial graph is not an error or proof that no other relationship exists. Refine filters, open a relevant group or entity, and use the bounded continuation when available.

Build Hunt Context from the graph safely

When the visible graph contains two or more ATT&CK techniques, Open Hunt Workflow can route the selected techniques to Attack Path Builder and carry eligible visible IOC nodes into editable Hunt Context. An IOC-focused item with zero or one visible technique can open Threat Hunter with the exact server-resolved indicator selection.

The handoff does not trust raw values from the URL. The server re-resolves selected entity IDs against the current tenant, user, permissions, lifecycle, marking, and provenance, deduplicates concrete IOC values, and preserves only the bounded selection. The signed handoff is tenant- and user-bound and expires after one hour.

Use the editable context to state why each IOC or technique belongs in the hunt, the expected telemetry, time range, likely entities, and limitations. Remove interesting but irrelevant nodes. A smaller context with a defensible reason is more useful than a large graph copied without analysis.

Create a hunt candidate without skipping CTI review

A reliable review-to-hunt workflow looks like this:

  1. Open the imported root entity and confirm source, currentness, marking, confidence, canonical Event or Report, and relevant relationships.
  2. Open or complete CTI Intake in the Threat Library. Record relevance, hypothesis, telemetry, expected evidence, limitations, and the analyst disposition.
  3. Return to the Intelligence Library and select entities from the same integration and the same canonical Event or Report.
  4. Select Create Hunt Candidate, choose the relevant telemetry platforms, record known limitations, and save the candidate as a draft.
  5. Review the candidate’s observables, ATT&CK mappings, expiration, provenance, and current review link.
  6. Promote the canonical review when policy and evidence support it, then open the candidate in Hunt Builder if the role has the required permission.
  7. Review the generated package separately before any approved query execution.

The candidate is a durable handoff, not an execution shortcut. Creation performs no query and no model call. Hunt Builder rechecks the current review and source policy before generation and again before execution.

Understand which intelligence may enter automation

Only complete, unrestricted TLP:CLEAR or TLP:WHITE native context is eligible to cross the external-AI boundary, and only when the configured source automation policy and canonical review permit it. TLP:GREEN, AMBER, RED, restricted, unknown-distribution, or truncated policy context remains local-review-only.

Bounded public feeds, demo sources, file imports, and other sources configured with deny_all can still support local search, entity review, graph exploration, and exact IOC Hunt Context. They cannot enter AI generation, Auto Triage, or automatic hunts. Saving a Reviewed disposition does not reclassify the source or override that policy.

This is an important operating distinction: useful local intelligence does not automatically become permissible model input or query authority.

Use source change and revocation correctly

Live MISP and OpenCTI content can change after an analyst review. When the canonical root changes, the prior review can be superseded and a new Draft created. Review the current content instead of assuming the prior disposition still binds.

Revocation and deletion also matter downstream. Current permissions, source lifecycle, revision, and hash are checked before retrieved citations or recommendations are shown. A retained excerpt should not remain visible merely because it was once part of an analysis.

If an imported entity appears incomplete, restricted, or inconsistent, pause the downstream workflow and ask a source manager to inspect the integration, import run, source policy, and raw bounded metadata. Do not repair provenance by copying labels, changing URL parameters, or manually asserting a more permissive classification.

Match permissions to the job

Typical responsibilities are intentionally separated:

  • intel:view opens the library, entity detail, relationships, and bounded graph.
  • hunt:save additionally permits direct creation of a draft hunt candidate.
  • hunt:view permits review of a saved candidate, while hunt:generate is required to enter Hunt Builder.
  • cti:review records CTI Intake dispositions.
  • intel:source:manage permits connection changes, tests, synchronization, file import, raw provider metadata, and restricted intelligence.
  • detection:manage governs review of CTI-derived private detection candidates.

Do not grant source-management authority merely so an analyst can browse the library. Restricted entities stay hidden from users without the relevant authority, and built-in Viewer access remains read-only.

A weekly intelligence operating cadence

  1. Review source health. Check synchronization, freshness, failures, current automation policy, and material content changes.
  2. Triage new roots. Prioritize current Events and Reports using source confidence, exploit or campaign relevance, business context, and telemetry readiness.
  3. Inspect relationships. Build a bounded graph around one analytical question and identify what is observed, inferred, restricted, or missing.
  4. Record the analyst decision. Complete CTI Intake with a testable hypothesis, expected evidence, platforms, and limitations.
  5. Create selective candidates. Promote only the observables and techniques that support a real hunt or detection question.
  6. Follow outcomes back. Use hunt, case, validation, and detection outcomes to refine source trust, hypotheses, and future prioritization.

Common problems and the fastest checks

  • No matches: clear Source and Type, then search an exact Event or Report ID or a shorter value fragment.
  • Create Hunt Candidate is absent: confirm the user has both intelligence view and hunt-save authority.
  • Entities cannot be selected together: confirm they belong to one integration and one canonical Event or Report.
  • The graph is partial: narrow the question, expand the relevant branch, or request the bounded continuation.
  • Open Hunt Workflow is disabled: confirm the role can generate hunts and that a visible technique or concrete IOC remains after filters.
  • Hunt Context opens but generation is blocked: check marking, distribution, completeness, source automation policy, and the current Reviewed or Promoted handoff.
  • The handoff expired: return to the source graph and create a fresh tenant- and user-bound selection.
  • A prior review no longer applies: check for changed canonical content and review the newest Draft.

Used well, the Intelligence Library is not a warehouse of indicators. It is the place where analysts preserve enough source truth to make downstream action reviewable. Search narrowly, read provenance first, expand relationships with a question, create candidates selectively, and let policy and human review control the move from intelligence to execution.