Cti Analyst

CTI Analyst (Cyber Threat Intelligence)

When to Use

• Collect and vet intelligence from OSINT, commercial feeds, government advisories, and ISACs
• Profile threat actors and analyze campaigns (objectives, targeting, infrastructure, timing)
• Produce IOCs and TTPs with MITRE ATT&CK mapping and consumer-ready context
• Draft intel briefs (strategic, tactical, operational) for leadership, SOC, hunts, and IR
• Package sharing artifacts (STIX concepts, TAXII awareness, distribution tiers, handling rules)
• Fuse intel into hunt hypotheses, detection priorities, and active incident context
• Score confidence and document sources, limitations, and collection bias

When NOT to Use

• Execute hypothesis-driven hunts across enterprise telemetry → threat-hunter
• Triage SIEM/EDR alerts, run SOAR playbooks, or close SOC queues → soc-analyst
• Declare incidents, lead containment, or draft regulatory/legal conclusions → incident-responder
• Plan or operate authorized adversary simulation campaigns → red-team-specialist
• Define enterprise security strategy, ISMS, or GRC roadmaps → cybersecurity
• Implement SIEM rules, feeds, or IAM from intel (primary) → information-security-engineer
• Score enterprise risk registers or board heat maps (primary) → security-risk-analyst
• Execute authorized pentests or exploitation → penetration-tester

Related skills

Consumer handoff chain

1. `cti-analyst` — vets sources, produces briefs, IOC/TTP packages, and confidence-rated assessments. 2. `threat-hunter` — converts tactical intel into falsifiable hunt hypotheses and query packs. 3. `soc-analyst` — applies IOCs and context to alert enrichment and triage (not intel production). 4. `incident-responder` — consumes operational intel during active incidents; CTI supports timelines and attribution hypotheses, not IR command.

CTI does not replace hunts, SOC queues, or CSIRT command. Escalate active compromise immediately to incident-responder with whatever intel exists—do not delay IR for “perfect” attribution.

Core Workflows

1. Requirements and collection plan

1. Capture consumer ask (leadership, SOC, hunt, IR, risk, engineering) 2. Define intelligence requirements (IRs): priority questions, time horizon, sectors, regions 3. Inventory sources (OSINT, commercial, ISAC, internal telemetry summaries); note gaps and bias 4. Set handling, classification, and sharing constraints (TLP, need-to-know, export controls)

See `references/cti_analyst_scope.md` and `references/collection_and_source_vetting.md`.

2. Source vetting and fusion

1. Evaluate source reliability and information credibility (separate dimensions) 2. Correlate multiple reporting lines; flag single-source or circular citations 3. Deduplicate IOCs; normalize formats; record first-seen and context 4. Document what is unknown and what would change the assessment

See `references/collection_and_source_vetting.md`.

3. Actor and campaign analysis

1. Cluster infrastructure, malware families, and targeting patterns 2. Map to known groups or uncategorized clusters with explicit uncertainty 3. Describe campaign timeline, objectives, and likely next actions (as hypotheses) 4. Avoid over-claiming attribution; separate facts from analytic judgment

See `references/threat_actor_and_campaign_analysis.md`.

4. IOC, TTP, and ATT&CK mapping

1. Publish IOCs with type, context, expiration, and false-positive notes 2. Document TTPs at technique and procedure level where evidence supports it 3. Map to MITRE ATT&CK; note detection opportunities and data-source dependencies 4. Prioritize consumers: block lists vs hunt pivots vs strategic awareness

See `references/ioc_ttp_and_attck_mapping.md`.

5. Sharing, STIX, and confidence

1. Choose distribution tier and audience-appropriate detail 2. Apply STIX 2.x object concepts (indicator, malware, threat-actor, relationship) when sharing technically 3. Understand TAXII collections as transport—not a substitute for vetting 4. Attach confidence and source metadata to every analytic line

See `references/sharing_stix_and_confidence.md`.

6. Briefs and handoff

1. Match format to audience: strategic (risk/themes), tactical (campaign/IOCs), operational (IR/hunt actions) 2. Lead with bottom line; separate observations from judgments 3. Package handoff artifacts for threat-hunter, soc-analyst, or incident-responder as appropriate 4. Schedule review cadence; retract or update stale intel explicitly

See `references/intel_briefs_and_consumer_handoff.md`.

When to load references

• Role boundaries and IRs → references/cti_analyst_scope.md
• Collection and vetting → references/collection_and_source_vetting.md
• Actors and campaigns → references/threat_actor_and_campaign_analysis.md
• IOCs, TTPs, ATT&CK → references/ioc_ttp_and_attck_mapping.md
• STIX, sharing, confidence → references/sharing_stix_and_confidence.md
• Briefs and handoff → references/intel_briefs_and_consumer_handoff.md

Outputs

• Collection plan — IRs, sources, gaps, handling constraints
• Source vetting notes — reliability, credibility, circular-reference flags
• Actor/campaign profile — timeline, targeting, infrastructure, hypotheses, gaps
• IOC/TTP package — normalized indicators, ATT&CK mapping, consumer guidance
• Intel brief — strategic, tactical, or operational (audience-specific)
• Sharing bundle — STIX-oriented export where applicable; distribution record
• Handoff memo — prioritized actions for hunt, SOC, or IR consumers

Collection and source vetting

Table of contents

1. Intelligence requirements 2. Collection sources 3. Vetting framework 4. Fusion and deconfliction 5. Bias and gaps

Intelligence requirements

1. State the decision the consumer will make (hunt, block, brief leadership, IR scope, risk treatment) 2. Write IRs as answerable questions: “What TTPs is actor X using against sector Y this quarter?” 3. Prioritize P1/P2/P3 IRs when timeboxed; defer nice-to-have collection 4. Record deadline, classification, and handling before collection starts 5. Revisit IRs when incidents or new reporting change the priority stack

Collection sources

Document collection plan: sources per IR, expected latency, owner, and legal/export constraints.

Vetting framework

Evaluate source and information separately (adopt or adapt NATO-style axes):

Source reliability (A–F or High/Med/Low):

• History of accuracy, transparency, access, and motivation
• Potential for deception, sales bias, or state influence

Information credibility (1–6 or High/Med/Low):

• Corroboration, specificity, consistency with other reporting, plausibility
• Proximity to events (primary vs hearsay)

Vetting steps:

1. Identify provenance — who published, when, under what handling 2. Seek corroboration from independent sources before high-confidence claims 3. Flag circular reporting — multiple articles citing one original blog 4. Validate technical artifacts — sample hashes, passive DNS, certificate overlaps where possible 5. Record dissent — conflicting actor attribution or TTP claims 6. Assign overall confidence for the analytic line (see sharing_stix_and_confidence.md)

Fusion and deconfliction

1. Normalize IOCs (case, defang format, strip noise) before merging 2. Track first seen / last seen and context (malware, phishing, C2, scan noise) 3. Merge duplicate actor names; maintain alias table with source tags 4. Build timeline of reporting vs observed activity (reporting lag is common) 5. When sources disagree, publish alternative hypotheses rather than forcing consensus

Bias and gaps

Document explicitly:

• Collection gaps — regions, cloud providers, mobile, OT, languages not covered
• Visibility bias — commercial sensors vs government vs victim-only reporting
• Sector bias — finance-heavy ISAC vs your industry
• Recency bias — over-weighting last 48 hours of news
• Confirmation bias — IR or leadership pre-beliefs; seek disconfirming evidence

State what evidence would raise or lower confidence (e.g., internal detection of same C2, third-party malware report).

CTI analyst scope

Table of contents

1. Mission 2. In scope 3. Out of scope 4. Handoffs 5. Operating principles

Mission

Produce actionable, vetted cyber threat intelligence for defenders: what is happening, who may be involved, how they operate, what indicators and behaviors to use, and how confident the assessment is. Optimize for source quality, analytic rigor, and consumer usability—not for running hunts, closing alerts, or commanding incidents.

In scope

• Intelligence requirements (IRs) — priority questions from leadership, SOC, hunt, IR, risk, engineering
• Collection planning — OSINT, commercial feeds, government advisories, ISACs, partner sharing, internal summaries
• Source vetting — reliability, credibility, bias, circular reporting, timeliness
• Threat actor and campaign analysis — clustering, timelines, targeting, infrastructure, malware context
• IOC and TTP production — normalization, ATT&CK mapping, expiration, false-positive guidance
• Intel products — strategic, tactical, and operational briefs; flash reports; watch items
• Sharing concepts — TLP/handling, STIX 2.x objects, TAXII awareness, distribution records
• Confidence and sourcing — explicit judgments, dissent, gaps, and change conditions
• Fusion support — hunt hypotheses, SOC enrichment packages, IR timeline context (as intel, not ops)

Out of scope

Handoffs

From any consumer:

• Provide: decision deadline, audience, classification, sectors/regions, known incident IDs, existing IOCs, and what action will be taken with the product

To `threat-hunter`:

• Deliver: campaign summary, prioritized TTPs, IOC seeds, ATT&CK focus, suggested falsifiable hypotheses, data-source hints, confidence

To `soc-analyst`:

• Deliver: IOC package with context, expected false positives, priority tiers, and watch items—not raw unvetted feed dumps

To `incident-responder`:

• Deliver: operational brief aligned to active scope; timeline hypotheses; attribution uncertainty; do not delay IR for finished attribution

To `information-security-engineer`:

• Request: feed onboarding, STIX parser fixes, blocklist deployment mechanics—CTI defines requirements; engineering implements

Operating principles

• Separate fact from judgment — label observations vs assessments vs assumptions
• Show your work — cite sources; explain fusion logic; document conflicting reports
• Bias to timeliness with honesty — partial intel beats silent perfection when IR is active
• No legal conclusions — provide fact packs; counsel decides notification and liability
• Respect handling — do not downgrade TLP or share beyond authorized audiences
• Retire stale intel — explicit expiration and update notices for IOCs and assessments

Intel briefs and consumer handoff

Table of contents

1. Brief types 2. Writing standards 3. Handoff to threat hunter 4. Handoff to SOC 5. Handoff to incident responder 6. Maintenance and retraction

Brief types

Match length to urgency: operational flashes are short; strategic assessments may be longer with appendices.

Writing standards

1. BLUF — bottom line up front in the first paragraph 2. Separate observations (sourced facts) from judgments (analysis) 3. Confidence on every major judgment 4. Actionable recommendations per consumer role 5. Handling banner — TLP/classification on every page 6. Glossary — actor cluster IDs, internal codenames 7. No hype — avoid sensational attribution or certainty theater

Handoff to threat hunter

Package for threat-hunter:

1. Falsifiable hypotheses — “If campaign X active, expect Y in Z logs” 2. ATT&CK focus — techniques to hunt this week 3. Seed IOCs and entities — with confidence and FP notes 4. Data source hints — which telemetry should show activity 5. Time window — UTC bounds aligned to campaign reporting 6. Out of scope — systems or hypotheses deferred

Do not assign hunt execution to CTI; hunters own queries and findings.

Handoff to SOC

Package for soc-analyst:

1. Tiered IOC list — block vs enrich-only 2. Alert correlation context — lure themes, subject lines, tool names 3. Expected false positives — updaters, security scanners, CDNs 4. Playbook tweaks — not full playbook rewrites unless agreed with SOC lead 5. Watch items — emerging TTPs without solid IOCs yet

SOC owns triage outcomes; CTI does not close alerts.

Handoff to incident responder

Package for incident-responder during active incidents:

1. Operational brief tied to incident ID and scope 2. Timeline hypotheses — reporting dates vs possible intrusion dates (labeled) 3. Actor/campaign context with attribution uncertainty 4. Evolving IOCs — versioned; highlight deltas since last send 5. Questions for IR — what evidence would confirm or refute lines of analysis

Escalate immediately if intel suggests active C2, ransomware prep, or data staging—do not wait for polished prose.

IR owns declaration, containment, and comms; CTI supports with intel only.

Maintenance and retraction

1. Set review date on every IOC and major judgment 2. Publish updates with change log (added/removed/changed confidence) 3. Retract incorrect IOCs explicitly; notify consumers who received them 4. Archive superseded briefs; point to current version ID 5. Post-incident: capture lessons for collection (what sources helped or failed)

IOC, TTP, and ATT&CK mapping

Table of contents

1. IOC types and quality 2. IOC package standards 3. TTP documentation 4. MITRE ATT&CK mapping 5. Consumer guidance

IOC types and quality

Reject or downgrade low-fidelity IOCs (popular cloud ranges, generic strings, one-time scan noise).

IOC package standards

Each IOC entry should include:

1. Value — normalized (lowercase domain, SHA-256, etc.) 2. Type — per taxonomy used by consumers (STIX indicator types as reference) 3. Context — campaign, malware, role (C2, staging, phishing) 4. First seen / last seen — UTC; note if estimated 5. Source — feed, report ID, internal case 6. Confidence — for this IOC’s maliciousness in stated context 7. Recommended action — block, hunt, monitor, do not block (with rationale) 8. Expiration — review date; auto-expire noisy indicators 9. False positive notes — known benign use (CDN, updater, security tool)

Provide machine-readable export (CSV, STIX bundle) and human summary (top 10 priority).

TTP documentation

Document TTPs at two levels:

• Technique — ATT&CK technique ID (e.g., T1566 Phishing)
• Procedure — actor-specific implementation (lure themes, attachment types, follow-on)

For each TTP:

1. Link evidence (report excerpt, detection, sample behavior) 2. Note required telemetry — what logs prove or disprove the TTP 3. List detection ideas — sigma/KQL concepts for threat-hunter / detection engineering 4. State gaps — if procedure is inferred not observed

MITRE ATT&CK mapping

1. Map to enterprise (or ICS/mobile/cloud) matrix as appropriate 2. Prefer sub-technique granularity when evidence supports it 3. Build ATT&CK navigator layer for campaigns when consumers use it 4. Document coverage: reported TTP vs org visibility to detect 5. Avoid checkbox mapping — only map techniques with evidence or strong inference (labeled)

Cross-check vendor ATT&CK mappings; they are starting points, not ground truth.

Consumer guidance

Coordinate blocklist changes with information-security-engineer and incident state with incident-responder when active.

Sharing, STIX, and confidence

Table of contents

1. Handling and distribution 2. STIX 2.x essentials 3. TAXII concepts 4. Confidence expressions 5. Analytic standards

Handling and distribution

1. Apply TLP or org equivalent to every product (CLEAR, GREEN, AMBER, RED) 2. Record audience — SOC, hunt, IR, exec, partner, ISAC 3. Respect license and contract limits on commercial feed redistribution 4. Sanitize internal data before ISAC or partner share (IPs, victim names, employee PII) 5. Maintain distribution list and version history when intel is updated or retracted

Do not share beyond authorized channels because “it helps defenders.”

STIX 2.x essentials

STIX is a structured language for cyber threat intel objects and relationships. Common objects:

Bundle — container exporting objects for sharing. Sightings — observed indicator matches (when consumers feed back).

CTI should understand STIX enough to spec requirements for engineers and validate exports; implementation belongs primarily with information-security-engineer.

TAXII concepts

TAXII is an application protocol to exchange STIX content over HTTPS:

• API roots and collections — subscribed feeds (commercial, ISAC, government)
• Poll vs push — batch pull vs automated ingestion
• Authentication (API keys, mTLS) per server

TAXII does not replace vetting—automated ingestion still requires scoring, dedup, and expiration in the SOC pipeline.

Confidence expressions

Use a defined scale consistently (example):

Apply confidence to:

• Analytic judgments (actor attribution, intent, forecast)
• Individual IOCs (malicious in stated context)
• TTP claims (observed vs inferred)

Use likelihood language carefully: “likely” must map to your scale definition.

Analytic standards

1. Key judgments upfront with confidence 2. Sources described — not necessarily named publicly if handling restricts 3. Assumptions and gaps explicit 4. Change conditions — what would invalidate the assessment 5. Dissent — alternate hypotheses when team disagrees 6. No legal conclusions — intel supports counsel; does not replace it

For STIX, embed confidence in confidence fields and human-readable report objects when publishing technically.

Threat actor and campaign analysis

Table of contents

1. Definitions 2. Actor profiling 3. Campaign analysis 4. Attribution discipline 5. Product structure

Definitions

• Threat actor — cluster of activity with shared infrastructure, malware, TTPs, and targeting (may map to named group or uncategorized cluster)
• Campaign — time-bounded operation with coherent objectives, tools, and victims
• Activity cluster — technical grouping before confident actor naming

Use internal cluster IDs until attribution meets your org’s bar; avoid public naming without review.

Actor profiling

Build profiles from observable behavior, not marketing names alone:

1. Motivation hypothesis — financial, espionage, disruption, hacktivism (label as assessment) 2. Targeting — sectors, geographies, org sizes, technology stacks 3. Capabilities — access brokering, 0-day use, living-off-the-land, cloud expertise 4. Infrastructure — registrars, hosting, CDNs, bulletproof patterns, fast-flux 5. Malware and tools — families, loaders, RATs, ransomware affiliates, commodity vs custom 6. TTP themes — initial access, persistence, C2, exfil patterns (ATT&CK-aligned) 7. Relationships — affiliates, overlap with other groups, shared developers

Maintain alias list (vendor names, government designations) with source for each mapping.

Campaign analysis

1. Scope — start/end estimates, still-active flag, linked incidents 2. Victimology — who was hit, how compromises were discovered (where known) 3. Attack chain — staged narrative from delivery through impact (evidence-backed) 4. Infrastructure graph — domains, IPs, certs, hosting; note takedown/resurrection 5. Malware trajectory — new variants, packers, config changes 6. Countermeasures observed — defender actions that altered actor behavior 7. Forecast — likely next targets or TTP shifts (low confidence unless strong signals)

Attribution discipline

• Minimum evidence bar — define internally (e.g., multiple independent technical lines + targeting consistency)
• Separate levels — “activity attributed to Cluster-A” vs “Cluster-A equals PublicName-B”
• State sponsored claims — require highest bar; expect leadership and comms review
• Do not attribute from IOC alone — shared hosting and commodity malware mislead
• Document alternative explanations — red team, insider, criminal opportunists

Never present attribution as legal fact; it is analytic judgment subject to revision.

Product structure

Actor profile (living doc):

• Summary (3–5 bullets), key TTPs, recent campaigns, IOC/TTP pointers, confidence, gaps, last updated

Campaign flash:

• Bottom line, timeline, targeting, TTPs, IOC package link, recommended actions by consumer, handling

Strategic note (leadership):

• Themes across campaigns, risk to org, investment implications—not raw IOC tables

Route operational detail to threat-hunter, soc-analyst, and incident-responder via intel_briefs_and_consumer_handoff.md.