CTAS common mistakes
CTAS · Understand the traps and how to avoid them.
When given a collection requirement, the candidate immediately lists data feeds and tools (new SIEM, commercial feed, dark web scraper) without first writing a decision-focused intelligence requirement stating the decision it supports, the consumer, and the indicators that would answer it.
Candidates conflate collection planning with requirements management; tool familiarity is easier to recall under time pressure than the discipline of priority intelligence requirements (PIRs), so the answer drifts to acquisition rather than requirements decomposition.
What to do instead
Before evaluating any source, restate the requirement as: decision to be made, decision-maker, question, indicators and observables, and a due date. Then map sources to indicators. Practice converting vague asks ('monitor the threat landscape') into measurable requirements with explicit indicators and confidence thresholds.
The candidate treats every source as equally credible and answers collection questions by maximizing volume ('ingest as many feeds as possible'), ignoring source reliability, corroboration, and the risk of poisoning or false positives.
Exam scenarios reward breadth-sounding answers, and candidates lack a memorized framework for grading sources; they also underestimate how unvetted feeds degrade analyst throughput and decision quality.
What to do instead
Apply an explicit source-grading scheme (reliability of source x credibility of information) and state corroboration rules. For any collection design, justify each source by coverage gap filled, latency, fidelity, and cost of false positives, and describe a sunset or review trigger for underperforming feeds.
Given raw logs or alerts, the candidate jumps straight to a conclusion ('this is APT-X') without documenting the analytic question, the evidence, alternative hypotheses, and the confidence level behind the judgment.
Candidates confuse a finished narrative with structured analysis; they have practiced writing summaries, not the reasoning trail, so the structured-technique step is omitted under exam time pressure.
What to do instead
Use a repeatable template: question, evidence with sourcing, hypotheses considered, indicators that would confirm or refute each, key assumptions, and a confidence statement. Practice applying at least one structured technique (ACH, key assumptions check, indicators/signposts) to each scenario and show the discarded hypotheses.
The candidate maps observed behavior to a single attack stage (for example labeling any PowerShell use as 'execution') and fails to trace the full lifecycle, including initial access, persistence, privilege escalation, and exfiltration, or to distinguish technique from procedure.
Candidates memorize isolated technique names without a lifecycle model, and ATT&CK-style labels are easy to pattern-match superficially; they also skip the question of what the adversary's objective implies for the defender.
What to do instead
For each scenario, build a stage-by-stage timeline and explicitly separate tactic (why), technique (how), and procedure (specific implementation). Ask what evidence is missing at each stage and what detection opportunity exists there. Practice with full intrusion narratives rather than single-event snippets.
When asked how to disseminate a finding, the candidate produces a technically detailed report for everyone, or sends a raw feed alert to executives, without tailoring content, timeliness, and classification to the audience and decision at hand.
Candidates optimize for showing technical knowledge rather than for the consumer's decision cycle; audience analysis and dissemination channel selection are rarely practiced, so a one-size-fits-all report feels complete.
What to do instead
For every dissemination question, identify the audience (tactical, operational, strategic), the decision they must make, the time window, and the required classification and handling caveats. Produce a short BLUF with confidence and recommended actions for decision-makers and a separate technical annex for responders.
The candidate assesses risk by listing threats and vulnerabilities without linking them to business assets, likelihood, impact, and risk appetite, and without prioritizing remediation by residual risk after existing controls.
Threat-centric thinking dominates candidate preparation; risk quantification (likelihood x impact, control effectiveness, residual risk) requires business context that candidates rarely rehearse, so answers stay at the level of 'this threat is severe'.
What to do instead
Anchor every strategic assessment to named business assets and processes, estimate likelihood and impact with stated assumptions, account for existing controls to derive residual risk, and rank items against the organization's risk appetite. State what would change the ranking.
The candidate proposes collection or sharing actions (dark web monitoring of employees, sharing indicators with third parties, retaining raw personal data) without addressing legal authority, privacy, consent, data handling, or sharing agreements.
Candidates treat legal and ethical constraints as an afterthought or a separate topic, and exam scenarios often bury the governance issue inside a technical question, so the candidate answers only the technical half.
What to do instead
Before recommending any collection or sharing action, state the legal basis and jurisdiction, privacy impact and minimization, retention limits, handling caveats (for example TLP), and required agreements. Practice spotting governance triggers: personal data, cross-border transfer, employee monitoring, and third-party sharing.
The candidate answers program questions with activity metrics (number of alerts, feeds ingested, reports written) rather than outcome metrics tied to program objectives, and proposes improvements without baselines or measurement plans.
Activity counts are easy to produce and look productive; candidates lack practice designing measures of effectiveness (detection coverage, time to detect, decision influence) and rarely think in terms of baselines and feedback loops.
What to do instead
For each program question, define the objective, then the outcome measure, the baseline, the data source, and the review cadence. Pair activity metrics with effectiveness and efficiency metrics, and describe how findings feed back into requirements and collection adjustments.
The candidate treats intelligence products as static deliverables and omits feedback from consumers, so requirements are never revised and collection is never re-prioritized after a product is delivered.
Candidates view the workflow as linear (requirements to collection to analysis to dissemination) and forget the feedback loop that closes the cycle; exam questions framed around a single deliverable encourage this.
What to do instead
Always close the loop explicitly: solicit consumer feedback, measure whether the product informed the decision, and feed results back into requirement revision and collection adjustment. Describe the review cadence and who owns each step.
The candidate describes adversary behavior using generic labels ('sophisticated actor', 'advanced malware') instead of specific, observable behaviors and indicators, and does not separate what is known from what is assessed.
Candidates use confident-sounding adjectives to compensate for uncertainty, and they have not practiced writing judgments with explicit confidence and sourcing, which is what the exam rewards.
What to do instead
Replace adjectives with observable facts and sourced assessments: what was observed, on which systems, with what timing, and what is inferred. Attach a confidence level and the basis for it, and flag gaps as collection requirements rather than filling them with speculation.