Module 1 · Cyber Threat Intelligence Fundamentals 🔒

Cyber Threat Intelligence (CTI) is the discipline of collecting, analyzing, and applying information about threats to inform security decisions. Done well, it tells defenders which threats matter to them, how those threats operate, and what to do about them. Done poorly, it is a subscription to overpriced threat feeds nobody reads. This module covers what CTI actually is, the four levels of intelligence, the intelligence cycle, and the mistakes most programs make.

The four levels of threat intelligence

• Strategic: long-term, business-oriented. “Ransomware groups are increasingly targeting Indian financial services; we should prepare for that.” Consumed by executives, boards, CISOs
• Operational: campaign-level detail. “Qakbot campaign delivering Cobalt Strike via ISO attachments; targets US healthcare this month.” Consumed by SOC managers, IR team leads
• Tactical: TTP-level. “Qakbot uses regsvr32 to execute the initial stager; hunt for regsvr32 with URL-like arguments.” Consumed by detection engineers, threat hunters
• Technical: IOCs. “This IP is command-and-control for Qakbot.” Consumed by automated tools (SIEM, EDR, firewalls)

Programs fail when they conflate these. A feed of IOCs is not strategic intelligence. A report on geopolitical trends is not SOC-actionable. Build your program across all four, with different workflows for each.

The intelligence cycle

1. Direction: what questions does the organisation need answered? (“Are we a plausible target for state actors?”)
2. Collection: gather raw data from sources (OSINT, paid feeds, internal telemetry, peer sharing)
3. Processing: structure, deduplicate, translate, normalize
4. Analysis: turn data into assessments — “this is likely APT29 based on TTP overlap”
5. Dissemination: get intelligence to the people who can act on it, in a format they can consume
6. Feedback: were the answers useful? Refine direction; loop

Most CTI programs skip direction and feedback. They collect because data is available, then wonder why nobody reads the output.

Sources of intelligence

Open-source (OSINT)

• CISA advisories, NCSC advisories, CERT-In advisories
• Vendor blog posts (CrowdStrike, Mandiant, Microsoft, Kaspersky, SecureList)
• Twitter/X threat researcher community
• GitHub — proof-of-concept repos, IOC repos, detection rule repos
• Dark web forums (via commercial access or academic research)
• MISP communities — threat-sharing platforms

Paid / commercial

• Mandiant Threat Intelligence — deep APT coverage, expensive
• CrowdStrike Falcon Intel — strong adversary tracking, integration with their EDR
• Recorded Future — strong dark-web and open-source fusion
• Intel 471 — underground criminal ecosystem focus
• Flashpoint — dark-web-centric
• Group-IB, Cybereason, Sophos X-Ops — regional / mid-tier options

Internal sources

Often overlooked — the richest CTI is your own:

• SIEM detections (what actually fires against us?)
• IR reports from past incidents
• Red team engagement findings
• Honeypot data
• Penetration test results

Peer sharing

• ISACs — Information Sharing and Analysis Centers by sector. FS-ISAC (financial), H-ISAC (health), etc. India: RBI’s intent for a banking ISAC has been discussed for years; participation varies
• Private trust groups — industry peers sharing informally via closed Slack/Signal
• MISP instances — technical indicator exchange protocol

Attribution — careful ground

Attribution is the analytic claim that threat X is behind activity Y. Hard to do well:

• TTPs overlap is suggestive, not conclusive — actors copy each other’s techniques
• Infrastructure overlap stronger — shared VPS ranges, certs
• Code overlap strongest — unique malware families, reused modules
• Geopolitical context is frame-dependent and easily spoofed (false flag operations)

Good attribution is probabilistic: “assessed with moderate confidence to be UNC2452, based on TTP overlap and shared C2 infrastructure.” Avoid absolute claims unless you have conclusive evidence. Mis-attribution can drive bad defensive decisions and invite diplomatic complications.

Diamond Model — a reasoning tool

Four vertices describe an intrusion:

• Adversary — who
• Capability — what tools/malware
• Infrastructure — where (IPs, domains)
• Victim — target

Pivots along edges: “given this adversary, what other infrastructure?” or “given this capability, which adversaries use it?” Useful framework for CTI analysts and for structuring intelligence reports.

Metrics that actually track CTI value

• Consumer satisfaction — do SOC analysts / IR / leadership find the output useful? Survey regularly
• Detection coverage gained — how many new detections did intelligence drive this quarter?
• Time saved in IR — did pre-existing context shorten response time on real incidents?
• Predictive hits — did we warn about something before it happened?

Avoid vanity metrics: number of IOCs ingested, number of reports published. Those tell you nothing about impact.

Common program mistakes

1. Tool before people: buying a TIP (Threat Intelligence Platform) before having analysts who can use it
2. No direction: consuming everything; no answer to “what are we trying to know?”
3. No dissemination: analysts writing reports nobody reads because the format and channel are wrong for the audience
4. No feedback: never asking consumers whether intelligence was useful; no way to improve
5. Confusing TI with TIP: TIP is the platform; TI is the work. Platform without process is shelf-ware

Starting a CTI function

For a team considering starting:

1. Hire one analyst (not a platform). Ideally someone with IR background
2. Identify 3 “priority intelligence requirements” (PIRs) from stakeholders
3. Establish weekly reporting cadence: one-page, PIR-aligned
4. Measure: did the reports drive any action? What would make them more useful?
5. Expand only when the above is working

What the next modules cover

Module 2 covers OSINT collection practically — tools, techniques, operational security for researchers. Module 3 introduces the Pyramid of Pain and IOC lifecycle — which indicators matter most. Module 4 dives into MITRE ATT&CK as the de facto framework for TTP communication. Module 5 is the capstone — intel-driven threat hunting.