SSCP common mistakes
SSCP · Understand the traps and how to avoid them.
Treats the question as 'which option is most secure' and picks the strongest-sounding control, ignoring constraints the stem explicitly states (budget, 24x7 uptime, user retraining, limited staff).
Candidates carry habits from hands-on technical exams where maximum hardening is always the correct answer; SSCP is written from a management perspective where the right answer is the control that fits the stated risk and business constraints.
What to do instead
Before selecting, underline the constraint words in the stem ('limited budget', 'must stay available', 'no additional headcount') and eliminate any option that violates them, then choose the option that addresses the stated risk at proportionate cost.
Labels a control by its technology rather than its function, for example calling an intrusion detection system 'preventive' or calling firewall log review 'corrective'.
Lists of control types are memorized as vocabulary instead of as a decision rule, so under time pressure the candidate maps by association (IDS = security = preventive).
What to do instead
Ask one question per option: does it stop the event before it happens (preventive), notice it during or after the event (detective), or restore service afterwards (corrective/recovery)? Deterrent discourages an attempt; compensating substitutes for a control that cannot be applied.
Chooses MAC whenever the scenario mentions 'sensitive' or 'high security', even when the stem actually describes access decided by the data owner or granted by job role.
MAC is taught as the 'strongest' model, so perceived strength is used as the tiebreaker instead of the access mechanism the scenario describes.
What to do instead
Identify who decides access: the resource owner's discretion = DAC; system-enforced labels and clearances = MAC; assignment by job function = RBAC; policy evaluated against attributes such as department, time, and location = ABAC. Match the described mechanism, not the perceived strength.
Ranks risks by gut feel and skips the quantitative chain, mixing up SLE, ARO, and ALE or reporting an annualized figure as a per-event loss.
The formulas are memorized as letters without units, so under pressure asset value and single loss expectancy blur together and the annual number gets reported as a single-event loss.
What to do instead
Write units beside every term before computing: AV = value of the asset, EF = fraction lost per event, SLE = AV x EF (loss per event), ARO = events per year, ALE = SLE x ARO (loss per year). Sanity-check that the answer is annual and cannot exceed the asset value unless multiple events per year are expected.
Mislabels risk responses, calling insurance 'mitigation', calling a documented 'do nothing' decision 'avoidance', or calling outsourcing a system 'acceptance'.
The four responses are learned as synonyms for 'handle the risk' rather than being distinguished by who ultimately absorbs the loss.
What to do instead
Assign by loss bearer: stop the activity = avoid; reduce likelihood or impact with controls = mitigate; shift the financial consequence to a third party through insurance or contract = transfer; formally acknowledge and fund the exposure = accept. A control that reduces impact but leaves the loss in-house is still mitigation, not transfer.
In an incident scenario, jumps straight to eradication (reimage, rebuild, patch) or to notifying outside parties, skipping containment and evidence preservation.
'Fix it fast' instincts from operations work, combined with answer options that look decisive and technical, pull selection away from the procedural first step.
What to do instead
Order the options: detect/validate, contain (isolate while preserving evidence), eradicate, recover, lessons learned. If the stem mentions legal action, insider involvement, or forensics, containment must capture volatile data before anything is wiped, reimaged, or powered off.
Powers off or reimages a suspect host before capturing memory, or collects disk images without recording hashes and hand-off details.
Shutdown feels like the safe, tidy response, and chain-of-custody paperwork feels like administrative overhead rather than an admissibility requirement.
What to do instead
Capture in order of volatility (registers and cache, RAM and running processes, network connections, disk, logs and backups and archives), hash each image at the point of capture, and record who handled it, when, and where it went. Change power state only under documented authority.
States that a digital signature provides confidentiality, or proposes asymmetric encryption as the method for encrypting bulk data transfers.
Signature and encryption both involve keys with math behind them, so their guarantees get merged; the performance gap between RSA/ECC and AES is under-weighted.
What to do instead
Map the guarantees: signing = hash plus the sender's private key, giving integrity, authentication, and nonrepudiation but no confidentiality. Encrypting to a recipient uses the recipient's public key and is computationally expensive, so bulk data travels under a symmetric session key that asymmetric cryptography only wraps and distributes.
Treats AH and ESP as interchangeable, assumes IPsec always provides encryption, and ignores transport versus tunnel mode.
Protocol names are memorized as a block of 'secure networking' facts instead of as a comparison table with a confidentiality column.
What to do instead
Build a two-column table: AH gives integrity and data-origin authentication with no confidentiality; ESP gives confidentiality plus integrity and authentication. Transport mode protects the payload between hosts; tunnel mode protects the entire packet between gateways. Answer from the table rather than from 'IPsec means encrypted'.
Recommends a network appliance (firewall, WAF, IDS) as the primary fix when the stem describes an application-layer defect such as SQL injection or cross-site scripting.
Perimeter controls are the most familiar tool, and a compensating device feels like a complete answer, but the question asks for the most effective control, not any helpful one.
What to do instead
For injection and script flaws the primary controls are server-side input validation plus parameterized queries or context-aware output encoding; a WAF is defense in depth only. Network devices cannot fix a defect that exists in the code.