NISP L1 PT common mistakes
NISP L1 PT · Understand the traps and how to avoid them.
When a question describes a scenario (a phishing email, a lost laptop, a suspicious login), answering with the general security principle that sounds most virtuous - 'apply least privilege', 'raise awareness', 'encrypt everything' - instead of the control that actually addresses the described event.
Candidates revise broad slogans and recall them fastest under time pressure, so the most familiar-sounding option wins over the option that fits the specific facts. The exam deliberately offers several true statements, only one of which is the correct response to the scenario.
What to do instead
Before reading the options, write the one-line incident in your own words and ask 'what is the next action or the control that directly stops this?'. Then eliminate any option that is a general principle rather than a match to the facts. Practise by taking twenty scenario stems and forcing yourself to name the trigger, the asset and the desired outcome before looking at choices.
Treating 'security awareness training' as the answer to every human-factor question, including questions about policy enforcement, disciplinary process, or technical controls against social engineering.
Awareness is the most frequently repeated message in entry-level material, so it becomes a default answer. Candidates do not distinguish between reducing likelihood (training) and enforcing or detecting (policy, technical filtering, verification procedures).
What to do instead
Build a small table of human-factor controls with their role: training (reduces likelihood), simulated phishing (measures), policy and sanctions (enforces), technical mail filtering and MFA (prevents or limits). When a stem asks for prevention, detection or enforcement, pick from the matching column.
Confusing the OSI layer at which a device or attack operates - calling a switch a Layer 3 device, placing ARP spoofing at Layer 3, or describing a SYN flood as an application-layer attack.
Layer numbers are memorised as a list without being tied to concrete protocols and devices, so recall collapses when the question presents a real protocol or attack rather than the layer name.
What to do instead
Learn one anchor per layer with a device and an attack: Layer 2 Ethernet/ARP and switches with MAC flooding and ARP spoofing; Layer 3 IP and routers with IP spoofing and fragmentation attacks; Layer 4 TCP/UDP with SYN floods and port scans; Layer 7 HTTP/DNS with SQL injection and DNS tunnelling. Recite the anchors until each layer immediately brings its protocol, device and attack to mind.
Mixing up the roles of a stateful firewall, an IDS and an IPS - saying an IDS blocks traffic, or that a firewall detects application-layer attacks because it inspects packets.
All three are described as 'network security devices' in introductory material, and their differences are stated once and then blurred. Candidates also assume 'inspects traffic' means 'understands applications'.
What to do instead
Memorise the decision each device makes: firewall permits or denies by rule and connection state; IDS copies traffic and alerts only; IPS sits inline and drops. Add where each is placed (perimeter, span port or tap, inline) and note that application awareness requires deep packet inspection or a proxy, not a basic packet filter.
Answering endpoint questions with network controls - recommending a firewall rule or network segmentation when the question is about malware execution, patching or removable media on a single host.
Candidates default to the perimeter because perimeter controls are taught first and feel comprehensive. They miss that the stem is scoped to one machine and asks for a host-level action.
What to do instead
Circle the scope word in the stem (host, endpoint, user device, server) before choosing. Keep a host-control list: EDR/antivirus, host firewall, patch management, application allow-listing, disk encryption, USB control, least-privilege local accounts. If the stem is host-scoped, only accept answers from that list.
Confusing vulnerability scanning with penetration testing, or treating a scan report as proof that a system is exploitable, and therefore choosing 'exploit confirmed' or 'no risk' answers.
Both activities produce findings about weaknesses, and the outputs look similar in a report. Candidates do not separate automated detection of a known weakness from human-verified exploitation and business-impact assessment.
What to do instead
Fix the distinction in one sentence each: a scan matches versions and signatures against known weaknesses and produces possible findings; a penetration test attempts controlled exploitation to prove impact within an agreed scope. Then answer questions by asking whether the stem mentions exploitation, scope agreement or automated matching.
Confusing authentication with authorisation, and confusing hashing with encryption - for example saying passwords are encrypted for verification, or that a role check is authentication.
The words are used loosely in everyday speech, and both hashing and encryption transform data, so the purpose difference is not reinforced. Candidates then pick an answer that is directionally right but technically wrong.
What to do instead
Use two test questions: 'who are you?' is authentication, 'what may you do?' is authorisation; 'must I recover the original?' is encryption, 'must I only compare?' is hashing. Apply them to every option before selecting, and remember that password verification compares a stored hash, it does not decrypt anything.
Believing that encryption alone protects data in every state, or that TLS on a website means the site is trustworthy - answering 'the connection is secure, so the site is legitimate'.
Padlock icons and 'HTTPS' messaging have taught users that encryption equals safety. Candidates carry that assumption into questions about phishing sites, data at rest and key management.
What to do instead
Separate the three states: at rest (storage encryption, key management), in transit (TLS), in use (access control, memory protection). Add the rule that TLS authenticates the channel, not the intent of the site owner, so a phishing site can hold a valid certificate. Rehearse this with a phishing-URL example.
Treating a certificate as permanent proof of identity, ignoring expiry, revocation and the role of the certificate authority, and choosing 'the certificate guarantees the server is honest' style answers.
PKI is taught as a chain of trust diagram, and the operational parts - validity period, CRL and OCSP, CA compromise - receive less attention, so the limits of a certificate are not internalised.
What to do instead
Learn the certificate lifecycle as a checklist: issued by a CA after identity validation, valid only within its dates, revocable, and bound to a name or key. Then state the limit explicitly: a certificate binds a public key to an identity, it does not vouch for behaviour. Test yourself on what happens when a CA is compromised or a certificate expires.
Answering legal and compliance questions with 'best practice' rather than the specific obligation - for example saying a breach must be reported 'to someone' without knowing the regulator, the timeframe or the threshold, or assuming one law applies globally.
Legal material is dense and jurisdiction-specific, so candidates memorise generalities and skip the concrete notification duties. They also assume that a familiar framework (for example a payment-card standard) is a law.
What to do instead
Build a one-page reference of the obligations you are actually examined on: which regulator or authority, what triggers notification, the deadline, and whether the source is a statute, a regulation or a voluntary standard. Mark each entry with its jurisdiction. Where you are unsure of a figure, learn the principle and flag the detail for review rather than guessing.