CTI roles focus on understanding adversaries — who they are, how they operate, and what they're after. These questions cover intel types, analysis frameworks, and how to turn raw threat data into actionable output for your organization.
Tactical intel is IOCs — IPs, domains, file hashes, email senders. Machine-consumable, short shelf life, consumed by security tools and L1/L2 analysts who need to know if a specific artifact is malicious right now.
Operational intel is adversary TTPs — what techniques does this group use, what's their typical attack chain, what tooling do they favor? More durable than tactical (doesn't rotate daily), consumed by detection engineers and IR teams to build or tune detections.
Strategic intel is high-level risk analysis — which threat actors are targeting your industry, what geopolitical trends affect your risk profile, how has the threat landscape shifted over the past year? Consumed by CISOs and board members to inform security investment decisions and risk appetite.
The Diamond Model structures intrusion analysis around four vertices: Adversary, Capability, Infrastructure, and Victim — connected by edges that capture relationships between them.
The model's core value is pivoting: if you observe one vertex, you can reason about the others. If you identify a piece of infrastructure (a C2 IP), you can search for other campaigns using that IP, which may reveal additional victims or a shared adversary. If you know a capability (a specific malware family), you can look for other infrastructure that deploys it.
It complements the Cyber Kill Chain by giving you a structured way to tie together disparate pieces of intel about the same actor across multiple incidents, rather than treating each intrusion in isolation.
David Bianco's Pyramid of Pain captures this. At the base: hash values — highly specific and high-confidence, but trivial for attackers to change by recompiling. IP addresses — moderate value, easy to rotate in hours. Domain names — slightly harder to replace. TTPs at the apex — the most durable because they describe how attackers achieve their objectives, which requires retraining and new capabilities to change.
A strong IOC is specific, fresh (hours or days old, not months), corroborated by multiple independent sources, and tied to behavioral context that makes it meaningful in your environment.
A weak IOC is aged, widely shared across dozens of public feeds (meaning the attacker has had time to rotate), from a single un-corroborated source, or generic enough to produce high false-positive rates if deployed in your tooling.
STIX (Structured Threat Information eXpression) is a standardized JSON-based language for representing threat intelligence objects — indicators, threat actors, campaigns, TTPs, relationships, and courses of action. It gives intel a common schema so different organizations and tools can represent the same information consistently.
TAXII (Trusted Automated eXchange of Indicator Information) is the transport protocol — essentially an API specification that defines how STIX content is published and consumed between threat intel platforms and organizations.
Together they enable automated, machine-readable intel sharing across vendors, ISACs, and organizations without manual translation or format conversion. Without them, intel sharing is a spreadsheet email chain.
The Intelligence Cycle is the framework for producing actionable intelligence from raw data. Six phases:
Direction: Define the intelligence requirements — what questions need answering? ("Are there active threats targeting our payment processing systems?")
Collection: Gather raw data from sources — open-source (OSINT), commercial feeds, information sharing groups, internal telemetry.
Processing: Normalize, filter, and translate raw data into a usable form — deduplicating IOCs, parsing feeds, translating foreign-language reports.
Analysis: Turn processed data into finished intelligence with context, assessment of confidence, and implications for the organization.
Dissemination: Deliver finished intel to the right audience in the right format — a CISO needs a one-pager, a detection engineer needs YARA rules.
Feedback: The requester evaluates whether the intel answered their question and tells the analyst what to improve — closing the loop for the next cycle.
TTP-based detection identifies adversary behavior patterns — the techniques and procedures an attacker uses to achieve their objectives — rather than static artifacts like IP addresses or file hashes.
The advantage: attackers can rotate a C2 IP in an hour and generate a new malware hash in minutes. But they cannot easily change how they achieve credential dumping, lateral movement, or exfiltration. Those behaviors require retraining, new capabilities, and operational change — all of which take time and money.
A detection built on "PowerShell spawning cmd.exe, which spawns a network connection to a non-standard port" will catch an attacker regardless of what specific tools they use or what IP they're calling back to. That's far more durable than a blocklist of IPs that's stale within 24 hours.
Confidence assessment considers several factors:
Source reliability: Is this a trusted commercial vendor? A known-good ISAC member? An anonymous forum post? Source track record matters.
Source independence: Are multiple sources reporting the same indicator independently, or is everyone citing one original source? Widely-shared intel that's actually one source cited 50 times looks more corroborated than it is.
Timeliness: Is this IOC hours old or months old? Is this TTP fresh from a recent intrusion, or from a 2019 report about an actor that may have changed TTPs since?
Specificity: Precise, actionable details (a specific malware family hash plus behavioral indicators) are higher confidence than vague descriptions ("may be associated with nation-state activity").
Many intel programs use structured confidence scoring (High / Medium / Low with explicit reasoning) to communicate this clearly to consumers.
Assess relevance first. Does this actor target your industry, geography, or technology stack? If it's a report about an actor that targets healthcare systems and you work for a manufacturing company, it goes in the file — don't spend analysis time on irrelevant intel.
If relevant: extract TTPs, not just IOCs. Map the techniques to your detection stack using ATT&CK Navigator. Identify coverage gaps — are there techniques in this actor's playbook that you have no detection for?
Brief detection engineering on gaps and what rules to build or tune. Brief your CISO or risk owner on the actor's relevance to your organization's risk profile.
Import IOCs last — with expiry dates and confidence tagging. Mass-importing IOCs into your blocklist without context is the most common CTI mistake. It creates alert noise and gives a false sense of coverage.
Lead with relevance and impact — why should they care? Give a clear risk statement before any technical description: "This ransomware group has hit three companies in our sector in the past 60 days using a phishing-to-VPN-credential-theft chain. We have coverage gaps in two of their four primary techniques."
Quantify where you can: incident count, affected industries, known ransom demands, timeline of recent activity. Avoid jargon — "T1566.001 spearphishing attachment" means nothing to a CFO; "targeted email with malicious PDF attachment" does.
Close with a clear ask: "We need budget for XDR tool X to close this detection gap" or "We're recommending a targeted phishing simulation for the finance team." Give them a decision, not just information.
Keep it to 5 minutes maximum for a verbal briefing. One page for written.
Map the TTPs to your detection stack using ATT&CK Navigator. Identify which techniques in the actor's playbook you have solid detection for, which you have partial coverage on, and which you have nothing for. The gap map is your output.
Check historical logs against the actor's known IOCs and behavioral signatures — have you had any prior contact with this actor without knowing it?
Brief detection engineering on the gaps, prioritized by technique frequency and impact. Work with them to build or tune detection rules.
Import IOCs into your tooling with expiry dates. Set a 30-day review — stale IOCs produce noise.
Brief the CISO on the actor, their relevance to your organization, what you're doing about it, and whether you need additional resources. Subscribe to feeds that track this actor going forward.
Don't immediately block or escalate based on a single low-confidence indicator — that's how you generate false positives that erode trust in the intel program.
Corroborate first: Look for supporting evidence in other data sources. Is the host in question showing other suspicious behavior? Are there SIEM alerts, EDR detections, or anomalous network patterns near the same host or timeframe?
Contextualize the indicator: How old is it? How many sources reported it? What's the original source's reliability track record? Is this IP a Tor exit node or a known proxy service that many benign users also traverse?
If supporting evidence emerges, escalate to the SOC and treat as a confirmed alert. If no corroboration, mark as "observe" rather than "block" — continue monitoring for 24-48 hours before closing. Document your reasoning either way.