Cambridge SC common mistakes
Cambridge SC · Understand the traps and how to avoid them.
When asked to select the best control for a given threat, the candidate picks the control that is technically strongest (e.g., AES-256 encryption) rather than the one that directly addresses the threat's root cause (e.g., input validation for injection).
Candidates equate 'strongest' with 'best' and overlook that controls must map to the specific threat vector and risk context. The exam often presents plausible but misaligned controls to test risk-based thinking.
What to do instead
For every control question, first identify the threat and the asset's exposure. Then ask: does this control prevent, detect, or mitigate that specific threat? Eliminate controls that are strong but irrelevant. Practice with scenarios where multiple controls are valid but only one addresses the root cause.
In authentication scenarios, the candidate recommends multi-factor authentication (MFA) as a universal fix without considering the factor types or the specific attack (e.g., recommending SMS OTP against phishing).
MFA is a buzzword; candidates memorize 'MFA is good' but not the nuances of factor strength and phishing resistance. They fail to distinguish between knowledge, possession, and inherence factors and their susceptibility to real-time relay attacks.
What to do instead
Memorize the phishing resistance hierarchy: FIDO2/WebAuthn > push with number matching > TOTP > SMS/email OTP. For each authentication question, identify the attack (phishing, replay, MITM) and select the factor that resists it. Practice mapping attacks to factor properties.
When selecting a cryptographic algorithm or mode, the candidate chooses based on key length or popularity (e.g., choosing RSA-4096 over ECC P-256 for a mobile device) without considering performance, key size, or use-case constraints.
Candidates often memorize 'bigger is better' and ignore that ECC provides equivalent security with smaller keys, better performance, and lower power consumption. They also overlook mode-specific issues like ECB vs. CBC.
What to do instead
Learn the equivalence table (e.g., RSA-3072 ≈ ECC P-256 ≈ 128-bit symmetric). For each scenario, note constraints: device power, bandwidth, legacy compatibility. Reject ECB for any multi-block data. Practice questions that force a trade-off between security and operational constraints.
In network security questions, the candidate confuses the OSI layer of a control (e.g., placing a WAF at layer 3/4 instead of layer 7) or misidentifies the function of a device (e.g., saying a proxy provides encryption).
Candidates memorize device names but not their layer or primary function. They also conflate similar devices (IDS vs. IPS, firewall vs. WAF) and fail to map controls to the layer where the attack occurs.
What to do instead
Create a table mapping common controls (firewall, IDS/IPS, WAF, proxy, load balancer) to OSI layers and primary security functions. For each scenario, identify the attack layer (e.g., SQLi at layer 7) and select the control that operates at that layer. Avoid controls that are layer-mismatched.
In secure development questions, the candidate recommends a general secure coding practice (e.g., 'validate input') without specifying the context (e.g., output encoding for XSS, parameterized queries for SQLi) or the development phase (e.g., threat modeling at design).
Candidates treat secure coding as a checklist of generic practices and fail to link specific vulnerabilities to specific mitigations. They also ignore the SDLC phase where a control is most effective.
What to do instead
Build a vulnerability-to-mitigation map: SQLi → parameterized queries; XSS → output encoding; CSRF → anti-CSRF tokens; buffer overflow → bounds checking. For each question, identify the vulnerability and the phase (design, code, test) and choose the most specific, phase-appropriate control.
In incident response questions, the candidate jumps to containment or eradication before completing identification or scoping, or confuses the order of the incident response lifecycle phases.
Candidates memorize the phases (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) but under pressure they prioritize action over analysis. They also forget that containment can be short-term (isolate) vs. long-term (patch).
What to do instead
Memorize the phase order and the goal of each. For every scenario, ask: have we fully identified the scope? If not, the next step is identification, not containment. Practice questions where premature containment causes evidence loss or incomplete remediation.
In governance and risk questions, the candidate treats risk acceptance as a technical decision or selects a risk treatment (mitigate, transfer, avoid, accept) without considering the organization's risk appetite or regulatory requirements.
Candidates focus on technical controls and forget that risk decisions are business decisions. They also confuse risk transfer (insurance) with risk avoidance (stopping the activity) and miss that acceptance must be documented and authorized.
What to do instead
For each risk scenario, identify the asset, threat, vulnerability, and impact. Then determine the treatment based on risk appetite: if risk is within appetite, accept (with sign-off); if not, mitigate, transfer, or avoid. Remember that acceptance requires management approval and documentation.
In privacy questions, the candidate applies security controls (e.g., encryption) as a substitute for privacy principles (e.g., data minimization, purpose limitation) or confuses anonymization with pseudonymization.
Candidates conflate privacy with security and assume encryption solves privacy. They also misunderstand that pseudonymized data can be re-identified and is still personal data under regulations like GDPR.
What to do instead
Learn the distinction: anonymization irreversibly removes identifiability; pseudonymization replaces identifiers but allows re-identification with additional info. For privacy scenarios, prioritize data minimization, purpose limitation, and consent. Use encryption as a security safeguard, not a privacy compliance measure.
When answering questions about access control models, the candidate selects the model based on the scenario's surface description (e.g., 'role-based' because job titles are mentioned) without verifying the core mechanism (e.g., MAC uses labels, DAC uses owner discretion, RBAC uses roles, ABAC uses attributes).
Candidates memorize model names but not their defining characteristics. They are easily distracted by keywords like 'role' or 'attribute' that appear in scenarios but do not determine the model.
What to do instead
Memorize the defining question for each model: DAC-who owns the resource? MAC-what is the classification label? RBAC-what is the user's role? ABAC-what attributes (user, resource, environment) are evaluated? For each scenario, identify the decision mechanism, not the vocabulary.
In cryptography questions, the candidate confuses hashing with encryption or digital signatures with encryption, and selects a hash for confidentiality or encryption for integrity.
Candidates see 'secure' and 'protect' and default to encryption. They forget that hashing provides integrity, not confidentiality, and that digital signatures provide authentication and non-repudiation, not confidentiality.
What to do instead
Memorize the security services: encryption → confidentiality; hash → integrity; digital signature → authentication, integrity, non-repudiation; HMAC → integrity and authenticity. For each scenario, identify the required service and select the primitive that provides it. Practice distinguishing 'protect from reading' (encrypt) vs. 'detect tampering' (hash).