Cisco 300-220 CBRTHD common mistakes
Cisco 300-220 CBRTHD · Understand the traps and how to avoid them.
Treating the CIA triad and the AAA framework as interchangeable labels, so when a scenario describes stolen credentials being reused, the candidate answers 'availability' or 'integrity' instead of recognising a broken authentication/authorisation control.
Both frameworks are taught as memorised acronym lists early in study, and the candidate never builds a decision rule for mapping a described incident to the specific pillar or control that failed.
What to do instead
For each pillar and each AAA element, write one sentence describing what a failure looks like in observable terms (e.g., integrity failure = unauthorised modification of data at rest or in transit; authentication failure = a principal is accepted without proof of identity). Practise by reading 20 short incident blurbs and labelling the failed property before looking at the options.
Classifying every encrypted or obfuscated attack as 'evasion' and every plaintext attack as 'not evasion', instead of separating the delivery/exploitation technique from the defence being bypassed.
Candidates conflate the attacker's tool category with the defensive layer it defeats, so a plaintext attack that defeats a signature engine by fragmentation or protocol ambiguity gets mislabelled.
What to do instead
Build a two-column table: attack technique on the left, specific defence bypassed on the right (signature, reputation, sandbox, proxy, segmentation). For each row, state whether the bypass depends on encryption, fragmentation, protocol normalisation differences, or timing. Test yourself by describing a bypass and naming the control it defeats.
Answering monitoring questions by naming a tool (SIEM, NetFlow, IDS) rather than the telemetry source and detection logic that would actually surface the described activity.
Vendor-oriented study material encourages product-name recall, and exam items that describe a behaviour expect the data source (e.g., DNS query logs, endpoint process telemetry, proxy logs) plus the analytic that would fire.
What to do instead
For each major attack behaviour (credential dumping, lateral movement, data staging, beaconing), write the exact log source, the field(s) that carry the signal, and the correlation rule in plain language. Rehearse answering 'which data source and which condition' before naming any product.
Ignoring the time dimension in correlation questions: assuming a single alert proves compromise, or that events must occur in the same second to be related.
Candidates read each event in isolation and do not consider baseline windows, dwell time, or the ordering of events across hosts and network sensors.
What to do instead
Practise writing detection logic with explicit windows (e.g., five failed authentications from one source within ten minutes followed by one success). For each scenario, state the baseline, the deviation, and the acceptable time window, then decide whether the evidence supports a single event or a sequence.
Confusing what endpoint telemetry can and cannot show, e.g., expecting a host-based sensor to reveal full packet payloads, or expecting process-creation logs to capture fileless in-memory activity without additional sources.
Candidates memorise 'EDR sees everything on the host' without learning the granularity of each telemetry class (process, file, registry, network connection, memory, driver load).
What to do instead
Map each telemetry class to the questions it can answer and the blind spots it leaves. For a given behaviour (e.g., reflective code loading, scheduled task persistence, service creation), list which host data sources provide evidence and which require memory analysis, network capture, or audit policy changes.
Reading a process tree or parent-child relationship backwards, or treating a legitimate system binary as inherently benign regardless of its parent, path, and command line.
Candidates focus on the executable name and ignore lineage, working directory, user context, and arguments, which is exactly where living-off-the-land abuse hides.
What to do instead
For every suspicious-process question, state four things before choosing: parent process, full image path, user context, and command-line arguments. Practise with common system utilities and describe the parent/argument combinations that are anomalous versus expected in a normal administrative workflow.
Treating a network intrusion analysis question as a signature-matching exercise and missing the protocol-level detail (TCP flags, sequence behaviour, DNS record types, HTTP header anomalies) that distinguishes the described activity.
Candidates skim the packet or flow description looking for a familiar attack name instead of parsing the mechanics that the question actually turns on.
What to do instead
Rehearse protocol fundamentals that appear in analysis items: TCP handshake and teardown flag sequences, RST behaviour, DNS query/response structure and record types, HTTP request smuggling indicators, and common tunnelling patterns. For each, write what normal looks like so the anomaly is obvious.
Assuming encrypted traffic is opaque and therefore unanalysable, so questions about command-and-control over TLS get answered with 'no visibility' rather than with metadata-based detection.
Candidates equate 'encrypted' with 'invisible' and forget that SNI, certificate attributes, JA3-style fingerprints, flow volume, timing, and beacon periodicity remain observable.
What to do instead
List the metadata available without decryption for TLS, DNS, and other encrypted protocols, and describe one detection idea per field (e.g., rare SNI values, self-signed certificate reuse, regular inter-arrival times). Practise identifying beaconing from flow timing alone.
Answering policy and procedure items with what is technically best rather than what the stated policy, role, or escalation path requires, e.g., recommending immediate containment when the documented procedure mandates notification and evidence preservation first.
Candidates with hands-on instincts prioritise remediation, and they have not internalised that incident response questions test adherence to defined roles and sequence.
What to do instead
Memorise the phases and the decision points between them: detection, validation, scoping, containment, eradication, recovery, lessons learned. For each phase, state who authorises the transition and what artefact must be produced. Practise scenario questions by first asking 'what does the procedure require next', then evaluating technical options.
Confusing data classification, retention, and handling requirements with access-control enforcement, so questions about where evidence or sensitive data may be stored get answered with a permission model instead of a handling rule.
Classification and access control are studied as separate chapters and the candidate never links them, even though handling rules derive from classification and drive retention and destruction decisions.
What to do instead
Build a matrix of classification level against permitted storage location, encryption requirement, retention period, and destruction method. Then, for evidence handling, add chain-of-custody requirements (who touched it, when, hash verification) and practise mapping a described action to the specific rule it violates.