Operate Actionable Threat Intelligence

Operating objective

Threat intelligence must answer an owned security question. Examples include which identity attack behavior should a detection cover, which exposed dependency needs urgent remediation, which observed infrastructure should analysts search for, or which adversary capability changes a recovery exercise. Collection volume is not the objective.

Create a priority intelligence requirement with the decision, asset, time horizon, consumer, acceptable confidence, available response, and review date. A requirement without an owner or available action is research, not an operational intelligence service.

Signals and evidence

Use internal incidents and telemetry, peer exchange, vendors, researchers, public reports, vulnerability authorities, and structured sharing based on the requirement. Record source, original source when known, collection time, confidence, handling restriction, scope, affected products and versions, observed versus inferred claims, and expiry.

Normalize observables without removing meaning. Preserve full context for domains, addresses, certificate values, account patterns, user agents, process behavior, authentication methods, and ATT&CK techniques. Separate an indicator of compromise from a behavior hypothesis. Test whether an indicator appears in benign infrastructure before using it for alerting or blocking.

Response and recovery

1. Define the intelligence question from an owned asset, threat model, or incident need.
2. Select sources that can answer it and document their access, bias, delay, and failure modes.
3. Deduplicate reports by underlying source, not by publisher count.
4. Evaluate confidence, relevance, scope, handling, and expiry.
5. Map the information to local assets, identities, routes, software, controls, and evidence sources.
6. Choose a bounded action: patch, harden, detect, hunt, challenge, block, contain, exercise, monitor, or accept.
7. Validate the action on local data and include positive, negative, stale, spoofed, and missing-context cases.
8. Publish only the fields and personal data required by the recipient.
9. Remove or downgrade expired intelligence and verify that downstream controls follow the change.
10. Measure whether the action changed coverage, time, priority, analyst effort, or incident outcome.

Design tradeoffs and residual risk

Rapid sharing improves time to action and spreads incorrect or sensitive information faster. Rich context supports analysis and increases privacy, handling, and storage cost. Automated blocking is fast and lets an attacker or bad source cause denial of service. Behavior-based analytics age better than infrastructure indicators and require more local evidence and analyst skill.

Residual risk includes unreported threats, deliberate deception, circular reporting, infrastructure shared with benign users, source compromise, collection bias, and local assets that are absent from inventory.

Pomerium boundary

Pomerium can supply local request, route, identity, policy, and decision evidence. This evidence can validate an external claim or support a hunt. Operators own intelligence collection, source evaluation, structured exchange, enrichment, privacy controls, analytic logic, and downstream action. Pomerium does not consume STIX feeds or identify an adversary.

Exercise

Choose a report about identity or access abuse. Write one priority intelligence requirement. Trace every material claim to its original source where possible. Mark observation, inference, confidence, handling, affected versions, and expiry.

Test one indicator and one behavior hypothesis against local staging data. Build a detection or hunt that preserves route, subject, resource, action, and time. Show one benign collision and state why the result should alert, enrich, challenge, block, or do nothing.

Evaluation checklist

• Does each collection activity answer a named decision with an owner and review date?
• Are original source, observation, inference, confidence, handling, scope, and expiry distinct?
• Does each action map to an owned local asset and a tested response?
• Can stale, spoofed, shared, or circular information cause harm?
• Did the intelligence measurably improve a decision or security outcome?