NISP Level 1 - Security Operations common mistakes
NISP Level 1 - Security Operations · Understand the traps and how to avoid them.
Treating the CIA triad as three interchangeable words and answering 'confidentiality' for any control that involves encryption or passwords, even when the scenario is about data being altered in transit or a system being unavailable.
Candidates memorise the acronym but never attach a decision test to each leg, so under time pressure they match on the surface keyword (encryption, password) rather than on the security property the scenario actually describes.
What to do instead
Before answering, write one line: what is the harm in the scenario - someone reading it (confidentiality), someone changing it (integrity), or nobody being able to use it (availability)? Then pick the control that addresses that harm. Practise with mixed scenarios where a hash protects integrity, a backup protects availability, and encryption protects confidentiality.
Classifying every privacy or data-handling question as a compliance question and citing a law, when the question is actually asking which security objective or control class applies.
Law and regulation content is memorable and heavily emphasised in study material, so candidates over-apply it and stop reading the actual stem, which may be about least privilege or data minimisation as a design principle.
What to do instead
Read the stem's final clause first to identify what is being asked (a principle, a control, a legal obligation, or a role). Only invoke a specific law when the stem names a jurisdiction, a data subject right, or a breach notification timeline.
Confusing authentication with authorisation and assigning the wrong control to a scenario, for example answering 'multi-factor authentication' when the question is about limiting what a logged-in user can reach.
Both live in the same identity domain and both are described with similar vocabulary (access, permissions, credentials), so candidates pattern-match on 'access' and pick the wrong half of the pair.
What to do instead
Apply a fixed test: authentication answers 'who are you' and happens before a session exists; authorisation answers 'what may you do' and happens after. If the scenario mentions roles, groups, permissions, or least privilege, it is authorisation. If it mentions passwords, tokens, or factors, it is authentication.
Assuming a firewall or IDS alone stops an attack, and choosing 'install a firewall' as the fix for problems that are actually about inspection of encrypted traffic, lateral movement inside a trusted zone, or application-layer payloads.
Perimeter devices are the most familiar control in the network domain, and candidates default to them because they can picture the device, not because it addresses the specific failure described.
What to do instead
For each network scenario, name the layer first (packet, session, application) and the zone (outside, DMZ, internal). Then ask whether the described traffic crosses a boundary at all; if it is internal east-west traffic or encrypted payload, a perimeter filter is the wrong answer and segmentation, inspection, or endpoint controls are correct.
Recommending 'apply all patches immediately' or 'disable the service' as the universal hardening answer without weighing operational impact, change control, or the actual exposure of the asset.
Hardening checklists are learned as absolutes, and candidates do not practise the trade-off reasoning that distinguishes a critical internet-facing server from an isolated lab host.
What to do instead
State the asset's exposure and criticality before choosing a remediation. Rank by risk (likelihood times impact), and prefer answers that include testing, a maintenance window, or compensating controls when the stem mentions uptime requirements or legacy dependencies.
Mixing up encoding, hashing, encryption, and digital signatures, for example saying a hash 'encrypts' a password or that a signature 'encrypts' a message for confidentiality.
All four transform data into unreadable-looking output, and study material often presents them in one chapter, so the distinctions blur into a single 'scrambling' concept.
What to do instead
Memorise one purpose per technique: encoding is reversible formatting with no key; hashing is one-way and used for integrity and password storage; encryption is reversible with a key and provides confidentiality; a signature provides authenticity and integrity using the sender's private key. Test yourself by asking 'can it be reversed, and by whom?'
Treating symmetric and asymmetric keys as interchangeable and choosing the wrong key for a task, such as using a public key to decrypt a password vault or a private key to encrypt bulk data.
The key pair vocabulary is learned as a pair of words rather than as a workflow, so candidates cannot reconstruct who holds which key and what each operation achieves.
What to do instead
Draw the two-party diagram once from memory: sender encrypts with the recipient's public key, recipient decrypts with their own private key; sender signs with their own private key, verifier checks with the sender's public key. Rehearse it until you can derive any key question from the diagram rather than recall.
Answering incident response questions with the containment step when the stem describes detection, triage, or evidence preservation, and skipping the ordering of the response phases.
Containment feels like the most decisive action, and candidates have not internalised that the phases are sequential and that premature containment can destroy forensic evidence.
What to do instead
Memorise the phase order (preparation, detection and analysis, containment, eradication, recovery, lessons learned) and, for each scenario, ask which phase the described action belongs to. If the stem mentions logs, scope, or evidence, the answer is analysis or preservation, not containment.
Confusing vulnerability scanning with penetration testing and treating a scanner output as proof of exploitability, or recommending a penetration test when the question is about continuous coverage of a large estate.
Both are assessment activities that produce findings, and the tools overlap, so candidates collapse them into one concept and then cannot answer questions about frequency, authorisation, or false positives.
What to do instead
Separate them by intent and evidence: scanning is automated, broad, frequent, and reports potential weaknesses with false positives; penetration testing is manual, narrow, authorised, and demonstrates actual exploitation. Choose scanning for coverage and prioritisation, testing for validating a specific attack path or control.
Confusing recovery point objective with recovery time objective, and choosing a backup frequency when the stem is about acceptable downtime, or vice versa.
Both are two-letter objectives expressed in time units, and candidates memorise the acronyms without anchoring them to the business question each one answers.
What to do instead
Anchor each to a question: RPO asks 'how much data can we afford to lose?' and drives backup frequency; RTO asks 'how long may we be down?' and drives recovery capability and staffing. In any scenario, underline the phrase about lost data or about elapsed downtime before selecting an answer.