Engineer Information Security common mistakes
Engineer Information Security · Understand the traps and how to avoid them.
Treating the PRC Cybersecurity Law, Data Security Law, and Personal Information Protection Law as one interchangeable statute, so answers about notification deadlines, data classification duties, or cross-border transfer approval cite the wrong law or the wrong authority.
Candidates memorize the three laws as a single block of dates and penalties because they were enacted close together, and never separate which law governs which obligation. Under time pressure they default to whichever law they read most recently.
What to do instead
Build a one-page matrix with rows for each law and columns for scope, key obligations, responsible regulator, breach notification timing, and penalty range. For each practice question, first name the asset type (network logs, important data, personal information) and only then select the statute. Drill 20 questions where two laws plausibly apply and justify the rejection.
Applying textbook TCP/IP layering to a described attack and mislabeling the layer, for example calling ARP spoofing a network-layer attack or classifying a SYN flood as an application-layer denial of service.
Layer models are learned abstractly and candidates match on the word 'attack' rather than on the protocol field being manipulated. Vendor terminology in incident descriptions further blurs the boundary.
What to do instead
For every attack you study, write the exact protocol and header field it abuses next to the OSI layer. Practice with a fixed table: ARP and MAC flooding at layer 2, IP fragmentation and ICMP at layer 3, SYN and session hijacking at layers 4-5, TLS stripping and HTTP request smuggling at layers 6-7. Re-sort a shuffled list of 40 attacks weekly until the mapping is automatic.
Choosing a firewall or IDS placement that blocks legitimate traffic or leaves a segment unprotected, such as putting a screened subnet host behind the internal firewall only, or placing an inline IPS where the design calls for passive monitoring.
Candidates memorize 'DMZ between two firewalls' as a slogan without reasoning about traffic direction, trust boundaries, and failure modes. They also confuse detection with prevention under exam wording.
What to do instead
Redraw each reference architecture from memory and annotate every permitted flow with source, destination, and port. For each device, state whether it is inline or passive and what happens to traffic if it fails open versus closed. Answer placement questions by tracing one specific packet end to end rather than recalling the diagram.
Assuming UNIX file permissions alone control access, ignoring setuid/setgid bits, sticky bits, ACLs, and the difference between effective and real UID, which leads to wrong conclusions about privilege escalation paths.
Most candidates practice with basic chmod and umask problems and never internalize how the kernel evaluates credentials at exec time. The exam phrases escalation scenarios that hinge on exactly this detail.
What to do instead
Work through the kernel permission check step by step for a setuid binary: real UID, effective UID, saved UID, and file mode. Practice reading ls -l output including the s, S, and t positions and predicting the result of executing each file as a non-root user. Include one ACL example and one capability example per study session.
Conflating database authentication with authorization and then ignoring row-level and column-level controls, so answers grant access based on a login succeeding rather than on the privilege model actually enforced.
Application-level login is the visible part of database access, while GRANT, roles, views, and row security are abstract. Candidates also carry over the assumption that a DBA account is equivalent to an application account.
What to do instead
For each scenario, separate three questions: who authenticates, what object is touched, and which privilege or policy permits it. Practice writing GRANT and REVOKE statements and predicting results, then repeat with a view using definer versus invoker rights. Add one question per session on inference attacks or SQL injection bypassing the privilege layer entirely.
Recommending input validation as the sole fix for injection and cross-site scripting, without addressing output encoding, parameterized queries, or context-specific escaping, and then picking the wrong mitigation for the described context.
Validation and sanitization are the terms candidates see most, so they become a default answer. The exam distinguishes stored, reflected, and DOM-based flaws where the correct control differs by sink.
What to do instead
Map each vulnerability class to its primary control in a table: parameterized queries for SQL injection, context-aware output encoding for XSS, allowlist validation for command injection, and CSRF tokens plus SameSite cookies for CSRF. For each practice scenario, identify the sink first, then select the control that operates at that sink.
Mixing up symmetric and asymmetric roles in a protocol, for example using a public key to encrypt a large payload for confidentiality, or claiming a digital signature provides confidentiality rather than integrity, authentication, and non-repudiation.
Candidates memorize key pairs as 'public encrypts, private decrypts' without learning which property each direction provides or why hybrid encryption exists. Key management questions then compound the error.
What to do instead
Write the four operations explicitly and label each with the security property it delivers: encrypt with recipient public key, decrypt with recipient private key, sign with sender private key, verify with sender public key. Then explain in one sentence why TLS uses asymmetric operations only for key exchange and authentication and symmetric ciphers for bulk data. Practice ten questions that ask which property a given construction provides.
Performing qualitative risk calculation by multiplying likelihood and impact but then treating the numeric score as a precise monetary figure, or confusing inherent risk with residual risk when recommending treatment.
Risk matrices look quantitative, so candidates skip the step of stating the scale and the assumptions. The exam tests whether the answer reflects controls already in place versus the untreated exposure.
What to do instead
Before computing, write down the scale definition and whether the question asks for inherent or residual risk. State explicitly that a 5x5 score is ordinal and cannot be summed across assets. For each scenario, list existing controls, compute residual exposure, and only then choose a treatment option from avoid, mitigate, transfer, or accept.
Treating log collection and alerting as sufficient incident response, skipping containment, eradication, and lessons-learned phases, or choosing an eradication action that destroys forensic evidence before containment is complete.
Monitoring tools dominate study material, so detection feels like the whole job. Candidates also answer the intuitively satisfying action (wipe and rebuild) instead of the sequenced one.
What to do instead
Memorize the response lifecycle as an ordered checklist and, for every scenario, write which phase the described action belongs to before answering. Practice questions that offer two plausible actions, one preserving evidence and one restoring service, and justify the order using the containment-first rule. Include one tabletop walkthrough of a ransomware case from detection to post-incident review.
Adopting emerging technology terms such as zero trust, confidential computing, or homomorphic encryption as complete answers without stating the specific control they replace or the assumption they remove, so the answer sounds current but does not resolve the scenario.
Buzzwords appear frequently in vendor and news material, and candidates substitute familiarity for mechanism. They cannot say what trust anchor or threat model each technology actually changes.
What to do instead
For each emerging topic, write three lines: the assumption it removes, the mechanism that enforces it, and one limitation. For zero trust, that means no implicit network trust, per-request authentication and authorization, and dependence on strong identity. For confidential computing, that means trusting the host no longer grants data access, enforced by hardware enclaves, limited by attestation and side-channel risk. Answer scenario questions by naming the mechanism, not the label.