CND common mistakes
CND · Understand the traps and how to avoid them.
When a stem describes an attack (e.g., ARP poisoning) but asks for the defensive control, the candidate selects the tool or technique that performs the attack instead of the countermeasure.
Attack knowledge is rehearsed as a list of tools/techniques, so the strongest-matching keyword in memory wins even when the question pivots from offense to defense mid-stem.
What to do instead
For every attack you study, build a three-column row: how it works, the observable artifact or log evidence, the specific control that stops or detects it. Practice answering the same scenario twice, once as 'what is happening' and once as 'what do we do'.
The candidate reaches for remediation (rebuild the host, restore from backup) as the first action in a scenario where the scope is still unknown or evidence has not been collected.
Operational instinct favors speed, and 'make the alert stop' feels like the responsible answer; the ordering discipline of containment, evidence preservation, then eradication is not internalized.
What to do instead
Before answering any response question, check the stem for the words 'scope unknown', 'still spreading', or 'evidence'. If any are present, containment or preservation outranks eradication. Memorize the standard phase order and apply it as a filter to every option.
The candidate chooses disk imaging first on a live machine, or answers that the original media should be returned to the owner immediately after acquisition.
Disk images are the most familiar forensic artifact, so they dominate memory; the order of volatility and chain-of-custody handling of originals are learned as trivia rather than as a decision rule.
What to do instead
Memorize the order of volatility from most to least transient (registers/cache, RAM and network state, swap and temp files, disk, remote logs, archival media) and drill the rule that the original evidence stays in custody while working copies with verified hashes are used for analysis.
The candidate answers business continuity items by swapping RTO and RPO, or treats the maximum tolerable downtime as interchangeable with the recovery objective.
The acronyms look alike and are usually memorized as a list of definitions rather than as answers to different questions (how long can we be down vs how much data can we lose).
What to do instead
Attach each metric to the question it answers: RTO = maximum acceptable outage duration, RPO = maximum acceptable data loss measured backward from the incident, MTD = outage beyond which harm is unacceptable, MTBF = reliability. Rewrite each definition as 'this tells you how much ___ you can afford to lose' and test yourself with short numeric scenarios.
The candidate answers perimeter questions by assigning blocking duties to a passive sensor, or expects full application-layer payload inspection from a device that only sees headers and flow records.
Vendor marketing blurs the lines between IDS, IPS, firewall, WAF, proxy, and NGFW, and candidates learn product categories by name rather than by placement and capability.
What to do instead
Build a decision grid with three axes: inline versus passive, signature versus anomaly/behavior, and OSI layer inspected. Then place each device class in the grid. Any option that claims a passive sensor drops traffic, or that a flow record reveals payload content, is automatically wrong.
The candidate cannot say which data source would answer a given question, e.g., choosing full packet capture to identify the volume of traffic to a host, or choosing NetFlow to recover the contents of a transferred file.
Monitoring is studied as a list of tools and log types rather than as a mapping from investigative question to evidence source, and specific event identifiers are memorized without context.
What to do instead
Write a source-to-question table: flow records for who talked to whom and how much; packet capture for content and protocol detail; authentication logs for identity; host telemetry for process ancestry. Memorize a small set of high-value Windows event IDs (successful and failed logon, special privileges assigned, process creation, account creation, log cleared) and what each proves.
The candidate applies a Windows-centric control to a Linux or IoT question, for example answering an IoT hardening question with an endpoint detection agent deployment or answering a Linux question with Group Policy.
The endpoint domain spans four very different platforms, but study time concentrates on Windows, so the default answer becomes a Windows control.
What to do instead
Maintain a platform-by-control matrix with separate columns for Windows, Linux, mobile, and IoT. Flag where a control is unavailable rather than approximate: constrained IoT devices usually get network segmentation, credential changes, and firmware controls instead of agents.
The candidate picks a technical mechanism to solve a governance-shaped question, such as answering a question about reducing insider risk with a firewall rule when the intended answer is a background check, separation of duties, or awareness training.
Controls are memorized by name without being classified, so category (administrative, technical, physical) and function (preventive, detective, corrective, compensating) are not used to filter options.
What to do instead
Practice classifying every control you meet on two axes: category and function. When a stem mentions policy, personnel, or process, prefer administrative options; when it mentions enforcement at a device or in software, prefer technical options.
The candidate treats encryption and hashing as interchangeable, choosing hashing to protect confidentiality or encryption to prove integrity, and mixes up input validation with output encoding when answering injection questions.
Both pairs are frequently described together in study material, so the distinctions collapse into 'crypto' and 'sanitization' as single blurred concepts.
What to do instead
Map each mechanism to the property it provides: encryption for confidentiality, hashing for integrity, digital signature for integrity plus authenticity and non-repudiation. For injection, separate the trust boundary: validate input where it enters, encode output where it is rendered, and parameterize queries at the database layer.
The candidate answers cloud questions as if the provider secures everything, or answers wireless questions by picking a pre-shared-key mode when the scenario describes per-user authentication and revocation requirements.
Shared responsibility and virtual networking abstractions are new material layered on top of familiar on-premises models, and wireless security modes are remembered by strength ranking rather than by deployment requirement.
What to do instead
Draw the responsibility split for IaaS, PaaS, and SaaS side by side so the boundary is explicit, and distinguish stateful host-level filtering from stateless subnet-level filtering. For wireless, match the mode to the requirement: pre-shared key for small single-key deployments, enterprise authentication with per-user credentials where individual revocation and accounting are needed.