Cisco 350-201 CBRCOR common mistakes
Cisco 350-201 CBRCOR · Understand the traps and how to avoid them.
Treating the NIST IR lifecycle phases as a fixed linear sequence, so that when asked what happens after a detection is validated the candidate picks 'eradication' instead of containment, or skips preparation entirely when the scenario starts mid-incident.
Most candidates memorise the phase names as a list and never map them to concrete artifacts (playbooks, evidence logs, comms trees, lessons-learned reports). Exam stems often describe a mid-flight situation, which exposes the missing mapping.
What to do instead
Build a one-page table with each phase in its own row: goal, typical inputs, typical outputs, and two example artifacts (e.g., Preparation = IR plan, contact roster, jump bag; Containment = isolation decision record, snapshot before wipe). Practice classifying 20 short scenario snippets into phases and justify each placement in one sentence.
Choosing 'block the source IP at the firewall' as the containment action for every alert, including cases describing credential misuse from a legitimate internal host or a compromised SaaS account.
IP blocking is the most familiar control and feels decisive. Candidates default to it without checking whether the source address is meaningful (NAT, cloud egress, roaming user, shared proxy) or whether the activity is authenticated rather than network-based.
What to do instead
Before selecting a containment action, answer three questions: is the actor identified by IP, by credential, or by host? what is the blast radius of the control? can the attacker trivially evade it? For credential-based incidents the primary containment is session/token revocation and password reset, with IP blocking as a secondary, time-boxed measure.
Confusing detection engineering concepts: describing a SIEM correlation rule as 'an IOC feed', or claiming a signature-based IDS will catch living-off-the-land behaviour such as encoded PowerShell invoked by a signed binary.
Vendor marketing blurs the line between signatures, IOCs, behavioural analytics, and anomaly detection, and candidates study tool names rather than the detection logic each technique can and cannot express.
What to do instead
Learn the detection-method taxonomy explicitly: atomic IOC matching, stateful correlation across events, behavioural/TTP analytics (e.g., unusual parent-child process lineage), and statistical baselining. For each, write one thing it reliably detects and one blind spot. Practise reading an alert description and naming which method produced it and why the others would miss it.
Reading an alert's severity field as the incident priority, and recommending escalation purely because the SIEM label says 'high', while ignoring asset criticality and data sensitivity described in the stem.
Triage training often centres on the console's colour coding. The exam instead tests whether the candidate can contextualise severity with business impact, and candidates skip that reasoning step.
What to do instead
Use an explicit triage formula in practice: technical severity x asset criticality x data classification x confidence of the detection. When answering, state the contextual factors from the stem that raise or lower priority, and note that a 'low' signature hit on a domain controller can outrank a 'high' hit on a lab VM.
Jumping to eradication (reimaging, deleting files, killing processes) before volatile evidence is captured, and then being unable to answer the exam question about what should have been collected first.
Under time pressure the instinct is to 'fix it'. Candidates also underestimate which artifacts are volatile: they forget running-process memory, network connections, ARP cache, and logged-in sessions disappear on reboot.
What to do instead
Memorise an order-of-volatility checklist and apply it to every scenario: memory and live connections, then logs and command history, then disk images, then configuration and backups. In answers, name at least two specific artifacts to preserve and the tool or command that captures them before any destructive step.
Treating MITRE ATT&CK technique IDs as trivia to be recalled rather than as a mapping exercise, so the candidate cannot say which tactic a described behaviour belongs to or which data source would reveal it.
Candidates memorise a handful of famous technique numbers but never study the tactic columns or the data-source mappings, so they cannot translate a narrative ('scheduled task created to relaunch a payload') into tactic, technique, and detection source.
What to do instead
For each of the enterprise tactics, list two representative techniques and, for each, the telemetry that exposes it (e.g., scheduled task creation = Windows event logs and task scheduler operational logs). Drill by reading a short intrusion narrative and writing the tactic sequence plus one detection source per step.
Misreading network evidence in packet or flow descriptions: calling a completed TCP three-way handshake a 'half-open scan', or interpreting a high volume of SYN packets without ACKs as normal browsing traffic.
Candidates learn scan names as vocabulary without linking them to the packet-level pattern that defines them, and they rarely practise reading flow records or capture summaries.
What to do instead
Learn each scan and behaviour by its packet signature: full connect (SYN, SYN-ACK, ACK), SYN scan (many SYNs, RST or no response, no completed handshake), XMAS/NULL/FIN flag anomalies, and volumetric versus slow-and-low patterns. Practise by sketching the flag exchange for each and matching it to a one-line flow description.
Answering malware questions by naming a family or a sandbox verdict instead of describing behaviour, so the response cannot explain persistence, command-and-control channel, or why the sample evaded the sandbox.
Threat-intel reporting encourages family-name thinking, and candidates assume the exam wants a label. The exam more often tests behavioural analysis and evasion reasoning.
What to do instead
For any sample description, produce four lines: initial execution vector, persistence mechanism, C2 protocol and destination pattern, and one evasion technique (e.g., sleep patching, environment checks, living-off-the-land binaries). Practise on public sandbox-style behavioural summaries and write the four lines without using a family name.
Confusing vulnerability management outputs with incident response inputs: recommending 'run a vulnerability scan' as the response to an active exploitation alert, or treating a CVSS score as proof the vulnerability is being exploited.
Both disciplines use scanners and severity scores, so candidates conflate detection of a weakness with detection of an attack. The exam tests whether the candidate can distinguish exposure from exploitation.
What to do instead
Separate the two workflows in notes: vulnerability management identifies and prioritises weaknesses in advance; incident response confirms and contains active misuse. In scenarios, look for exploitation evidence (web logs showing crafted requests, child processes spawned by the vulnerable service, outbound connections after the request) before escalating, and cite that evidence explicitly.
Writing incident documentation and communication answers that omit the audience and the legal/regulatory trigger, e.g., proposing to notify customers immediately without checking contractual or statutory timelines, or briefing executives with packet captures.
Technical candidates focus on evidence and remediation and treat communication as an afterthought, so they miss the exam's questions about escalation paths, data-breach notification thresholds, and evidence-handling obligations.
What to do instead
Prepare a communication matrix: who is informed (SOC lead, CISO, legal, privacy officer, regulator, customers, law enforcement), at what trigger, within what timeframe, and in what format (executive summary versus technical timeline). For each scenario, identify the data types involved and state whether a notification obligation is plausibly triggered and which team decides.