Cyber threat intelligence is not an indicator feed.
It is a decision-support discipline. The value of a CTI function is not measured by how many reports it reads, how many hashes it stores, or how many technique IDs it maps. It is measured by whether the organization makes better security decisions because the intelligence function reduced uncertainty at the right time.
The first mistake in CTI operations is treating collection as the beginning of the workflow. Collection is not the beginning. The requirement is. A collection plan without a requirement becomes a stream of artifacts that someone later has to justify.
A good CTI operation begins by asking what problem needs to be solved. Is the team trying to detect an active intrusion, understand an extortion campaign, prioritize a vulnerability, protect an executive, investigate fraud infrastructure, support legal action, or brief leadership on risk? Each problem requires a different collection plan, different confidence threshold, and different product format.
Ground the operation in shared standards.
Standards do not replace judgment. They make judgment easier to explain, exchange, and defend when intelligence moves between teams.
Threat information sharing
NIST SP 800-150
Use this as the baseline for trust, agreements, source handling, operational controls, and the decision to share at all.
Incident response alignment
NIST SP 800-61r3
Use this to make intelligence useful before, during, and after incidents, not just as a reporting function after the fact.
Handling and dissemination
FIRST TLP 2.0
Use TLP before distribution so every recipient understands how far the intelligence can travel and how it should be protected.
Structured exchange
OASIS STIX/TAXII
Use structured objects when indicators, malware, infrastructure, sightings, campaigns, and relationships need to move across tools.
Behavior mapping
MITRE ATT&CK
Use ATT&CK to describe adversary behavior, detection opportunity, and control gaps. Do not use it as decoration for a report.
Machine-speed sharing
CISA AIS
Use automated sharing only when the content, handling, scope, and confidence are strong enough for machine-to-machine exchange.
Put every task inside the intelligence cycle.
Requirements, collection, processing, analysis, dissemination, and feedback are not interchangeable. They are different standards of work.
01
Requirement
Define the decision, stakeholder, risk scenario, time window, and intelligence gap before collection begins.
02
Collection
Collect from internal telemetry, incidents, open sources, trust communities, vendor reporting, malware analysis, and exposure data only when each source has a purpose.
03
Processing
Normalize observables, preserve raw evidence, deduplicate records, attach source metadata, and separate observed facts from analytic judgments.
04
Analysis
Convert processed data into judgments about adversary behavior, infrastructure, capability, targeting, opportunity, and likely impact.
05
Dissemination
Package intelligence for the audience, apply handling instructions, and distribute through a channel that matches the risk and sensitivity.
06
Feedback
Track whether detections fired, whether the intelligence changed a decision, and which requirements should be retired, rewritten, or escalated.
Requirements are the control plane.
A requirement should be written before collection begins, reviewed before analysis begins, and updated after feedback returns.
Requirement frame
Decision owner
Name the person or team that will act on the answer. If no one owns the decision, the request is not ready.
Requirement frame
Intelligence question
Write the requirement as a question that reduces uncertainty. Do not write it as a demand for every possible indicator.
Requirement frame
Risk scenario
Connect the question to an intrusion scenario, fraud pattern, exposure concern, geopolitical event, vendor risk, or executive decision.
Requirement frame
Time window
Define whether the product is tactical, operational, or strategic. A 30-minute incident need and a quarterly board need are not the same workflow.
Requirement frame
Source boundary
State which sources are authorized, which are excluded, and what legal, contractual, privacy, or OPSEC restrictions apply.
Requirement frame
Success criteria
Define what a useful answer looks like before collection begins. The team should know what would satisfy, revise, or close the requirement.
Evidence discipline
Preserve the record before shaping the story.
Processing is where weak CTI programs lose defensibility. A raw source record should not disappear after enrichment, summarization, or clustering. The original observation is the anchor that lets an analyst explain why a finding exists.
Treat indicators as evidence fragments, not conclusions. An IP address, domain, hash, wallet, selector, or malware family name is useful only when it is tied to source context, time, confidence, and the behavior it helps explain.
STIX and TAXII can help when structured objects need to move across platforms, but structure alone does not create intelligence. The structure has to carry provenance, relationships, sightings, confidence, and handling instructions.
Operational gate
Source gate
Every source has a reason to be collected, a reliability expectation, and a defined boundary. Volume is not the same as coverage.
Operational gate
Evidence gate
Raw records, timestamps, query terms, hashes, screenshots, enrichment outputs, and source URLs are preserved before analysis changes the shape of the data.
Operational gate
Processing gate
Selectors, entities, dates, infrastructure, malware names, vulnerabilities, and actor aliases are normalized before any conclusion is written.
Operational gate
Confidence gate
Every analytic claim has a confidence level, and low-confidence leads are labeled as leads rather than findings.
Operational gate
Action gate
The output tells detection, incident response, vulnerability management, leadership, legal, or fraud teams what decision it supports.
Operational gate
Feedback gate
The team records whether the intelligence was used, whether it was timely, and what collection gap still remains.
Analysis is where data becomes judgment.
The analyst is not just summarizing what sources said. The analyst is assessing what the evidence means, what remains uncertain, what action is justified, and what would change the assessment. This is the point where CTI must be careful with confidence, attribution, and implied urgency.
MITRE ATT&CK mapping should describe behavior, not decorate a report. A technique ID is useful when it clarifies what the adversary did, what telemetry should show, what detection logic can be written, and which control gap is exposed.
Attribution should be treated as a judgment, not a brand label. If the evidence supports malware family, infrastructure pattern, tooling overlap, language marker, targeting profile, or operational method, say that. If it does not support a named actor, do not force one.
Make analytic standards explicit.
A CTI product should read clearly, but it should also show how the analyst reached the assessment.
Analysis standard
Claim discipline
Each paragraph should make one claim, show the evidence behind it, and separate fact from assessment.
Analysis standard
Confidence language
Confidence should reflect source reliability, evidence quality, corroboration, recency, and analytic uncertainty.
Analysis standard
Competing hypotheses
A serious CTI product considers alternative explanations, especially when attribution, intent, or future action is being assessed.
Analysis standard
Behavior before labels
Actor names are less important than the behavior observed. Detection teams can act on behaviors even when attribution is unresolved.
Analysis standard
Impact translation
The assessment should translate technical activity into business risk, operational exposure, user harm, or executive decision context.
Analysis standard
Review record
The final product should preserve who reviewed it, what changed, what uncertainty remains, and when the requirement should be revisited.
03 / Dissemination
Send different products for different decisions.
Dissemination is not posting the same report to every channel. FIRST TLP exists because intelligence has handling constraints. A high-quality product still fails if it reaches the wrong audience, arrives without context, or lacks instructions for use.
A detection engineer needs behavior, telemetry, logic, and validation notes. A senior executive needs exposure, likelihood, business impact, confidence, and decision options. A legal or investigations team needs preserved evidence, source context, and review history. The format should follow the decision.
Deliverable
Executive risk note
A short decision memo for leadership that explains the threat, exposure, confidence, likely impact, and recommended action.
Deliverable
Detection package
A package of behaviors, indicators, logic, assumptions, false-positive notes, and validation criteria for detection engineering.
Deliverable
Hunt hypothesis
A testable statement about adversary behavior, where it should appear in telemetry, and what evidence would confirm or reject it.
Deliverable
Incident support brief
A time-sensitive brief that explains what is known, what is suspected, what is unknown, and which response decisions are waiting on intelligence.
Deliverable
Indicator feed
A structured feed for machine consumption only when indicators are validated, scoped, time-bound, and distributed with correct handling.
Deliverable
Strategic assessment
A longer assessment that connects campaigns, capabilities, targeting, geopolitical or criminal context, and organizational exposure.
Agentic CTI should accelerate evidence work, not replace judgment.
Agents can enrich, compare, cluster, draft, translate, and test. The analyst still owns confidence, attribution, risk, and release.
Agent role
Enrichment agent
Expands observables with passive DNS, certificates, malware reports, vulnerability context, abuse records, and internal telemetry references.
Agent role
Correlation agent
Clusters related records by shared infrastructure, selector reuse, temporal pattern, language, tooling, hosting, or victimology.
Agent role
Drafting agent
Turns structured notes into audience-specific drafts while preserving source references and uncertainty markers.
Agent role
Detection agent
Translates behaviors into hunt hypotheses, detection logic drafts, telemetry requirements, and validation notes for engineering review.
Agent role
Review agent
Checks claims against cited evidence, flags unsupported attribution, searches for missing context, and asks for confidence justification.
Agent role
Memory agent
Maintains requirements, prior findings, retired assumptions, source reliability notes, and feedback from previous intelligence cycles.
04 / Operating rhythm
A 72-hour rhythm keeps urgent CTI grounded.
01
0 to 4 hours
Frame the request
Confirm the decision owner, write the intelligence question, define sensitivity, and decide whether the request is tactical, operational, or strategic.
02
4 to 12 hours
Collect and preserve
Collect from scoped sources, preserve raw evidence, record collection paths, and avoid premature attribution while the evidence base is thin.
03
12 to 24 hours
Process and enrich
Normalize records, enrich observables, compare internal and external sources, and identify what is confirmed, probable, possible, or unresolved.
04
24 to 48 hours
Analyze and review
Build hypotheses, map behavior, challenge assumptions, record confidence, and run review before the product is released.
05
48 to 72 hours
Disseminate and measure
Send the right product to the right audience, track whether it changed a decision, and record what the next requirement should become.
Closing principle
A mature CTI program is not louder. It is more selective.
It collects less irrelevant data, preserves more context, produces fewer unsupported claims, and closes the feedback loop faster. The best checklist is not a box-ticking exercise. It is an operating discipline that makes every intelligence product easier to use, challenge, and improve.
Build with Stratir