CTSP study materials
CTSP study resources

CTSP common mistakes

CTSP · Understand the traps and how to avoid them.

Mistake 1

Treating the Pyramid of Pain as a strict ranking in which any hash or IP block is worthless, and dismissing indicator-based detection as 'not real intelligence'.

Candidates memorize the tiers as a slogan ('TTPs good, hashes bad') and then over-apply it, missing that low-level indicators remain operationally useful for immediate blocking, retro-hunting, and pivoting, and that the model describes cost-to-adversary, not detection value.

What to do instead

State each tier's actual trade-off: hashes/IPs are cheap for the adversary to change but fast and precise to deploy; TTPs are durable but require behavioral analytics and carry false-positive cost. On scenario questions, pick the indicator level that matches the question's time horizon and detection capability, and justify it explicitly.

Mistake 2

Conflating the intelligence cycle's 'direction' and 'collection planning' phases, or describing the cycle as strictly linear with no feedback loops.

Study guides present the cycle as a clean list, so candidates map any 'requirements' question to 'collection' and any 'priorities' question to 'dissemination', ignoring that direction sets prioritized requirements and that collection planning translates them into sources, schedules, and gaps.

What to do instead

Memorize the phase outputs: direction produces prioritized intelligence requirements and a collection plan; collection produces raw reporting; processing converts it to usable form; analysis produces assessments; dissemination delivers to consumers, whose feedback re-enters direction. When a stem mentions 'PIR' or 'priority', answer direction; when it mentions 'source selection, gaps, or coverage', answer collection planning.

Mistake 3

Attributing activity to a named actor or country based on a single shared tool, malware family, or IP address.

Public reporting frequently names actors, so candidates assume tool overlap equals identity. In practice, tools, infrastructure, and malware are shared, leased, leaked, or false-flagged, and the exam tests whether the candidate understands confidence levels and competing hypotheses.

What to do instead

Require convergence of multiple independent evidence types (infrastructure, tooling, targeting, timing, language/opsec artifacts) before naming an actor, and express findings with an explicit confidence statement. When a question offers 'shared malware' as the sole basis for attribution, treat it as insufficient and prefer the answer that states assessed confidence or an alternative hypothesis.

Mistake 4

Reading an actor profile as a static capability list and ignoring the distinction between capability, intent, and opportunity when prioritizing threats.

Actor dossiers are written as encyclopedic descriptions (aliases, tools, targets), so candidates answer prioritization questions by 'who is most famous' or 'who has the most advanced malware' rather than assessing relevance to the organization's sector, exposure, and the actor's demonstrated intent.

What to do instead

For each actor, extract four things: demonstrated capability, stated or observed intent, targeting pattern relevant to your sector/geography, and opportunity created by your exposure. Rank threats on that combination, and when a stem describes a low-capability actor with high intent against your exact sector, do not default to the advanced persistent threat.

Mistake 5

Proposing collection from a source without addressing legal authority, access, reliability, or the collection plan's stated requirements, and treating 'more feeds' as automatically better.

Candidates equate collection with tool acquisition and answer 'subscribe to another feed' or 'scrape the forum', skipping the evaluation step in which sources are judged on relevance, timeliness, reliability, and lawful access.

What to do instead

Evaluate every proposed source against four criteria: relevance to a named requirement, reliability and corroboration history, timeliness, and legal/ethical authority to collect. In scenario items, prefer the option that maps a source to a specific requirement and acknowledges a gap over the option that simply adds volume.

Mistake 6

Applying structured analytic techniques as decoration - naming ACH or a key-assumptions check but then presenting a single conclusion without documenting alternatives, evidence weighting, or the diagnostic value of each item.

Candidates learn technique names from glossaries and can define them, but exam items test whether they can run the technique: listing hypotheses, scoring evidence as consistent/inconsistent, and identifying which evidence actually discriminates between hypotheses.

What to do instead

Practice writing a short ACH matrix: hypotheses as columns, evidence as rows, cells marked consistent/inconsistent/not applicable, then identify the evidence with the highest diagnostic value and the hypothesis with the least inconsistency. On questions asking which technique fits, match the technique to the bias being countered (ACH for premature closure, key-assumptions check for inherited beliefs, devil's advocacy for consensus pressure).

Mistake 7

Treating an indicator match as proof of compromise, or conversely discarding low-fidelity indicators instead of enriching and scoring them.

Hunting workflows encourage 'search the IOC list', so candidates answer that a hit confirms infection. Real hunting requires context: an IP may be shared hosting, a hash may be a legitimate installer, and a domain may be sinkholed.

What to do instead

Score indicators on fidelity, freshness, and context before acting, and describe the hunt as hypothesis-driven: state the behavior being hunted, the data sources needed, and the expected benign explanations. When a stem shows a single indicator hit, the correct answer usually involves corroboration, enrichment, or scoping rather than immediate declaration of a breach.

Mistake 8

Assuming a threat intelligence platform automatically produces finished intelligence, and confusing TIP functions (ingestion, normalization, enrichment, correlation, dissemination) with analysis or with SIEM detection engineering.

Vendor marketing blurs platform boundaries, so candidates answer 'deploy a TIP' for problems that are analytical, process, or data-quality issues, and misassign functions such as deduplication and scoring to the wrong component.

What to do instead

Map each function to its system: TIP for ingestion, normalization, deduplication, scoring, and sharing; SIEM for log correlation and detection; SOAR for response orchestration. When an item describes poor indicator quality or unresolved duplicates, choose the TIP data-management answer; when it describes detecting behavior in logs, choose detection engineering.

Mistake 9

Writing dissemination products at the analyst's level of technical detail for every audience, or omitting the bottom line, confidence, and recommended action.

Candidates draft reports as evidence dumps because that mirrors how they consume technical reporting, forgetting that executives need impact and decision, while tactical teams need observables and detection guidance.

What to do instead

For each product, fix audience, decision, and format first: lead with a bottom-line assessment and confidence, then key judgments tied to the audience's decisions, then supporting detail. Produce separate tactical (observables, detection logic) and strategic (risk, trend, recommendation) versions rather than one blended document, and state explicitly what the recipient should do.

Mistake 10

Ignoring operational security and legal constraints during collection and sharing - for example recommending engagement with adversaries, collection from criminal forums without authorization, or redistribution of handling-caveated indicators.

Candidates focus on the intelligence value of a source and overlook that collection can create legal exposure, endanger sources, or violate sharing agreements marked with traffic-light protocol or similar handling restrictions.

What to do instead

Before recommending any collection or sharing action, check three gates: legal authority and organizational policy, source and analyst safety (attribution risk, persona separation, infrastructure), and handling restrictions on the data. In scenario items, prefer the option that preserves source protection and honors handling caveats, and route questionable activity to legal or the appropriate authority rather than acting directly.