DSST Cybersecurity common mistakes
DSST Cybersecurity · Understand the traps and how to avoid them.
Choosing the control that 'stops' an attack instead of the one that detects or records it, whenever a question asks for monitoring, logging, or audit evidence.
Candidates pattern-match on the attack name (phishing, SQL injection) and pick the blocking control, ignoring the verb in the stem. DSST stems often ask which control provides accountability or evidence, where preventive controls are wrong.
What to do instead
Underline the outcome verb in every stem (prevent, detect, record, deter, recover) before reading options. Build a four-column table - preventive, detective, corrective, deterrent - and place every named control (WAF, IDS, SIEM, CCTV, guard, backup restore) into it. Eliminate options whose category does not match the verb.
Treating input validation and output encoding as interchangeable, or selecting validation as the fix for cross-site scripting.
Both are described as 'sanitizing input' in study material, so candidates collapse them. In practice validation constrains what is accepted; encoding neutralizes data at the point of rendering, which is what stops script execution in another user's browser.
What to do instead
Memorize the pairing: server-side input validation for injection into interpreters (SQL, command, LDAP); context-aware output encoding for XSS; parameterized queries for SQL injection specifically. When a stem mentions 'reflected back to other users' or 'browser executes', the answer is encoding or a Content Security Policy, not validation.
Answering authentication questions with authorization concepts, for example naming role-based access control when the stem asks how a user proves identity.
The two are taught together as 'authn/authz', and questions about multi-factor login, password storage, or session tokens get answered with permission models. The distractor set usually includes both, so the wrong-domain answer looks plausible.
What to do instead
Ask one question first: is the subject proving who they are (authentication: passwords, tokens, certificates, biometrics, MFA factors) or what they may do (authorization: ACLs, RBAC, ABAC, least privilege)? Sort each option into one bucket before evaluating quality. If the stem mentions 'identity', 'credential', or 'login', discard every permission-model option.
Miscounting authentication factors, e.g., calling a password plus a security question two-factor, or a password plus a PIN two-factor.
Candidates count the number of steps or prompts rather than the number of distinct factor categories. Knowledge-based questions and a second memorized secret are both 'something you know'.
What to do instead
Label each credential as knowledge, possession, or inherence. MFA requires two or more different categories. Password plus security question = one category (knowledge). Password plus authenticator app code = knowledge plus possession = MFA. Apply the same test to every scenario option.
Mapping every regulation to the wrong control family - for example citing PCI DSS for health data, HIPAA for payment cards, or GDPR for a purely internal US system with no EU data subjects.
All frameworks are remembered as 'compliance rules' without their scope triggers. Exam stems deliberately include the scope detail (cardholder data, protected health information, EU residents) as the deciding clue.
What to do instead
Memorize scope triggers, not just names: PCI DSS = cardholder data; HIPAA = protected health information in the US; GDPR = personal data of EU data subjects regardless of company location; SOX = financial reporting controls for public companies; GLBA = consumer financial information. Read the data type in the stem first, then select the framework.
Confusing a policy, a standard, a procedure, and a guideline, and picking 'policy' for any governance question.
These are presented as a hierarchy of documents, and candidates remember only that policy is 'the top'. Stems that ask what document states a mandatory technical requirement or a step-by-step instruction then get the wrong answer.
What to do instead
Anchor on function: policy = management intent and mandatory high-level rules; standard = mandatory specific requirements (e.g., AES-256, 12-character minimum); procedure = step-by-step instructions; guideline = recommended, non-mandatory. Ask whether the stem describes intent, a measurable requirement, a sequence of steps, or advice.
Placing a firewall or IDS where it cannot see the traffic, or expecting a network control to stop an attack that occurs inside an encrypted or application-layer channel.
Candidates treat firewalls as universal blockers and forget that a network IDS on a switched segment sees only traffic it is fed, and that a host-based control is needed for encrypted or local activity.
What to do instead
For each scenario, ask: what path does the traffic take, is it encrypted, and where is the sensor placed? Use network firewalls for segment and port control, host-based firewalls and HIDS for endpoint and encrypted traffic, WAF for HTTP application attacks, and network taps or SPAN ports for visibility. Choose the control that can actually observe or block the described flow.
Selecting a detective or compensating control as the primary answer for physical perimeter protection, such as choosing CCTV over mantrap or badge-controlled doors when the stem asks how to prevent tailgating.
Physical security options are all familiar, and candidates pick the most visible technology. They also overlook low-tech controls like mantraps, turnstiles, and visitor escort policies that directly address the stated threat.
What to do instead
Identify the threat first: tailgating, shoulder surfing, dumpster diving, piggybacking. Then match: mantrap or turnstile for tailgating, privacy screens and clean-desk for shoulder surfing, cross-cut shredding for dumpster diving. Reserve cameras and logs for after-the-fact detection and evidence questions.
Ranking vulnerabilities by raw CVSS base score alone, ignoring exploitability context, asset criticality, and whether a compensating control already exists.
CVSS is the most memorable number in vulnerability management, so candidates treat the highest score as automatically the top priority. Real prioritization also weighs exposure, data sensitivity, and known exploitation.
What to do instead
Use a two-step rule: first filter by whether the asset is internet-facing and holds sensitive data; then weigh severity, exploit availability, and existing mitigations. A medium-severity flaw on an internet-facing payment server can outrank a critical flaw on an isolated lab host. When a stem supplies context, the context decides, not the score.
Describing risk treatment as 'eliminate the risk' or 'accept after scanning', and confusing risk avoidance, mitigation, transfer, and acceptance.
The four treatment options sound similar and candidates default to 'fix it'. Stems that describe insurance, outsourcing, or a documented decision to tolerate a low risk are testing the distinctions.
What to do instead
Match verbs to treatments: avoidance = stop the activity; mitigation/reduction = apply controls; transfer = insurance or contractual shift; acceptance = documented, signed-off tolerance with rationale. Note that a vulnerability scan does not treat risk; it informs the decision. Look for the sign-off or contract language in the stem.