SC common mistakes
SC · Understand the traps and how to avoid them.
Choosing the control that is most technically impressive (e.g., full-disk encryption, MFA) when the stem asks which control best mitigates a specific business risk or which is the first/cost-effective step.
Candidates pattern-match to the 'strongest' security answer instead of the one that fits the stated risk, budget, or sequence in the scenario.
What to do instead
Before answering, underline the risk or objective in the stem and the constraint (cost, first step, most appropriate). Eliminate options that are technically strong but do not address that stated objective, and pick the one that maps directly to it.
Selecting 'accept the risk' or 'transfer the risk' before confirming that a control cannot reduce the risk to an acceptable level, or before confirming senior management sign-off.
Risk treatment options look interchangeable in isolation, and candidates forget that mitigation is evaluated first and acceptance requires the appropriate authority.
What to do instead
Apply a fixed decision order: can the risk be reduced to acceptable levels (mitigate)? If not, can it be transferred? Only then accept or avoid, and acceptance must be documented by the accountable business owner, not the security team alone.
Classifying data based only on its format (e.g., 'it is a spreadsheet, so it is confidential') rather than on who owns it and what harm disclosure would cause, and confusing data owner, data custodian, and data processor roles.
Data classification and role questions are worded to sound similar, and candidates answer from format intuition instead of the accountability model.
What to do instead
Memorize the role split: the owner (business) decides classification and access rules; the custodian implements and maintains controls; the processor handles data on the controller's behalf. Classify by sensitivity and impact of disclosure, then assign the role that matches the described responsibility.
Treating encryption at rest as sufficient for data in use or in transit, or assuming a given encryption mode protects integrity when it only provides confidentiality.
Candidates collapse 'encrypted' into 'secure' and do not map the control to the data state or the security property (confidentiality vs. integrity) the stem asks about.
What to do instead
For every data-protection question, identify the data state (at rest, in transit, in use) and the property required. Match the control to both; note that modes such as CBC provide confidentiality but need a separate MAC for integrity, while authenticated modes provide both.
Assuming a security model (Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash) enforces the wrong property, e.g., saying Bell-LaPadula prevents integrity violations or that Biba protects confidentiality.
The models are taught as a list and candidates remember names but not the direction of the rules (no read up vs. no write down).
What to do instead
Anchor each model to one property: Bell-LaPadula = confidentiality (no read up, no write down); Biba = integrity (no read down, no write up); Clark-Wilson = integrity via well-formed transactions and separation of duties; Brewer-Nash = conflict of interest. State the property first, then the rule.
Confusing the OSI layer at which a control operates, e.g., placing TLS, IPsec, or a switch/VLAN in the wrong layer, or calling a firewall a Layer 7 control when it filters on IP/port.
Candidates memorize layer numbers but do not map concrete protocols and devices to them under time pressure.
What to do instead
Build a one-line layer map and rehearse it: TLS/HTTP = Layer 7/6, TCP/UDP = Layer 4, IP/IPsec = Layer 3, Ethernet/MAC/VLAN = Layer 2. For each device or protocol in a stem, name its layer before evaluating the answer choices.
Choosing a network segmentation or architecture answer that blocks required business traffic, or assuming a DMZ or VLAN alone provides authentication and encryption.
Candidates equate 'segmented' or 'in a DMZ' with 'secure' without checking whether the design still supports the stated business flow or addresses the actual threat.
What to do instead
For architecture questions, verify two things: does the design still permit the required traffic, and does it address the specific threat named? Treat segmentation as a containment control, not an authentication or encryption control, and add the missing control explicitly.
Mixing up authentication factors and authorization models, e.g., calling a password plus a PIN multi-factor, or choosing RBAC when the stem describes attribute- or relationship-based decisions.
Candidates count credentials rather than factor categories, and the access-control models are easily confused because they all 'grant access.'
What to do instead
Count factors by category: something you know, have, are (plus location/behavior). Two items from the same category are single-factor. For authorization, map the stem: job function = RBAC, resource attributes and context = ABAC, pre-defined relationships = ReBAC, fixed lists = DAC, central policy = MAC.
Treating a vulnerability scan as a penetration test, or reporting scan output as proof of exploitability, and skipping the sampling/scope justification in assessment questions.
Candidates equate 'we scanned' with 'we tested,' and assessment-methodology questions reward precision about what each technique actually proves.
What to do instead
Keep the distinctions explicit: scans enumerate potential weaknesses; penetration tests validate exploitability with authorization and scope; code review finds implementation flaws. When sampling is described, confirm the sample is representative and documented before drawing conclusions.
Choosing 'review the logs' or 'notify management' as the first response to an active incident, or preserving evidence incorrectly by rebooting or cleaning a compromised host before capture.
Candidates default to documentation or escalation steps, and under pressure they forget that containment and evidence integrity come before remediation.
What to do instead
Apply the incident order: detect, contain (limit spread), preserve evidence per forensic procedure (order of volatility, chain of custody), eradicate, recover, then lessons learned. Escalation and logging happen in parallel but do not replace containment; never reboot or wipe before volatile evidence is captured.
Assuming input validation on the client side or parameterized queries alone solve injection, or picking a control that mitigates the symptom rather than the root cause in secure-coding questions.
Candidates conflate defense-in-depth layers and pick the most familiar control instead of the one that removes the vulnerability class.
What to do instead
Identify the vulnerability class first, then choose the control that removes it at the root: parameterized queries/prepared statements for SQL injection, output encoding for XSS, server-side validation as authoritative. Treat client-side checks and WAFs as supplementary layers, not the primary fix.