NCCS common mistakes
NCCS · Understand the traps and how to avoid them.
Treating the CIA triad as three interchangeable labels and picking 'Confidentiality' for any scenario involving stolen data, even when the loss is integrity (e.g., tampered transaction records) or availability (e.g., ransomware encryption).
Candidates memorize the acronym without mapping the actual harm described in the scenario to the property that was violated, and 'confidentiality' is the most familiar-sounding term.
What to do instead
Before answering, write one line: what did the attacker gain or destroy? If data was read, it is confidentiality; if altered, integrity; if unreachable or locked, availability. Practice with mixed scenarios where the breach is integrity-only (a forged invoice) to break the confidentiality reflex.
Classifying an attack by the tool used rather than by the mechanism. For example, labeling credential stuffing as 'brute force' or a watering-hole attack as 'phishing' because a link was involved.
Exam items use familiar words as distractors, and candidates match on the surface keyword instead of the defining mechanism (reused valid credentials vs. guessing; compromised trusted site vs. deceptive message).
What to do instead
Build a one-page mechanism table for the top 15 attack types: what the attacker needs, what makes it succeed, and one distinguishing tell. When two options seem plausible, ask which mechanism the scenario's details actually support.
Designing a perimeter answer that relies on a single control (e.g., 'install a firewall' or 'enable the IDS') when the scenario calls for defense in depth, or placing a control in the wrong architectural zone (putting an IPS outside the firewall or a honeypot inline with production traffic).
Candidates recall that firewalls and IDSs are security controls but not where they sit in the traffic path or what each layer compensates for, so they pick a plausible-sounding single control.
What to do instead
Sketch the reference path: internet, edge router, firewall, DMZ (public services), internal segmentation, endpoints. For each scenario, state which layer the threat crosses and select the control that acts at that layer, favoring layered answers when the question asks for the most complete mitigation.
Confusing the roles of IDS and IPS, or choosing 'block' behavior for a sensor deployed in monitor-only mode, and misreading the direction of ingress vs. egress filtering rules.
The acronyms differ by one letter and both are described as 'detecting' traffic; candidates also skim the deployment position stated in the stem and answer as if the device were inline.
What to do instead
Anchor on one sentence: IDS observes and alerts (passive, tap/SPAN), IPS sits inline and can drop. Then read the stem for placement words ('mirrored port', 'inline', 'between') and eliminate options that assume capabilities the stated placement cannot provide.
Recommending application whitelisting, full-disk encryption, or EDR as the primary answer for every endpoint question, regardless of whether the scenario is about preventing execution, protecting data at rest, or detecting behavior.
These are the most advertised endpoint controls, so they surface first in memory; candidates do not map the control to the specific failure mode described.
What to do instead
Classify the endpoint problem first: execution prevention (allowlisting, patching), data-at-rest protection (encryption, DLP), detection and response (EDR, logging), or hardening (baseline config, least privilege). Choose the control that addresses the stated failure mode, and note that EDR detects rather than blocks by default.
Treating authentication factors as 'something you know/have/are' only, and mislabeling MFA combinations such as password plus security question as multifactor, or calling a one-time code sent to the same phone a second factor when the phone is the enrolled device.
The three-category mnemonic is overlearned, and candidates do not check whether two prompts draw on genuinely independent channels.
What to do instead
For each option, label the exact channel: memory, physical possession, biometric, location, behavior. Two prompts from the same channel are single-factor. Also separate authentication (proving identity) from authorization (what is allowed) and from accounting (logging), since stems often test the boundary.
Choosing symmetric encryption for key exchange or asymmetric encryption for bulk data, and confusing hashing with encryption when the question is about password storage or integrity verification.
Candidates know AES is 'strong' and RSA is 'strong' but not the performance and key-distribution constraints that dictate which is used where, and hashing looks like encryption at a glance.
What to do instead
Memorize the division of labor: asymmetric for key exchange and signatures, symmetric for bulk data, hashing (with salt, slow KDF) for password storage, HMAC for integrity with a shared key. When an option says 'encrypt the password with AES', eliminate it because encryption is reversible.
Jumping from detection to eradication without containment, or answering incident-response questions with 'notify law enforcement' or 'restore from backup' as the first step regardless of where the scenario sits in the lifecycle.
Candidates memorize the phase names but not their order and purpose, and dramatic-sounding actions feel like strong answers.
What to do instead
Fix the sequence: preparation, identification, containment, eradication, recovery, lessons learned. Locate the scenario on that timeline before reading the options, then pick the action belonging to the current phase. Containment precedes eradication whenever the threat is still active.
Treating risk as a single number, or answering 'accept the risk' when the scenario requires transfer (insurance, contract), avoidance (stop the activity), or mitigation (apply a control), and confusing a vulnerability with a risk or a threat.
The four treatment options sound similar in prose, and candidates do not distinguish likelihood times impact from the mere existence of a weakness.
What to do instead
Define terms in one line each: threat (who/what can cause harm), vulnerability (the weakness), risk (likelihood and impact of exploitation), control (reduces one of those). Then match the scenario's stated constraint (cost, contract, regulatory ban) to the treatment that fits it, and remember residual risk remains after any control.
Assuming a cloud provider's compliance certification transfers to the customer, or answering cloud questions with 'the provider secures everything' instead of splitting responsibilities between provider and customer.
Marketing language around 'secure cloud' and shared-responsibility diagrams blur who patches what; candidates do not apply the model to the specific service type (IaaS, PaaS, SaaS).
What to do instead
For each scenario, name the service model and assign each layer: physical and hypervisor to the provider; OS, patching, identity configuration, and data classification to the customer in IaaS; narrowing customer scope as you move to PaaS and SaaS. State explicitly that provider certifications cover the provider's controls, not the customer's configuration.