NCJOSI common mistakes
NCJOSI · Understand the traps and how to avoid them.
Treating the OSI model as a memorization exercise and answering questions by recalling a layer number instead of mapping the scenario's device, protocol, or attack to the layer where it actually operates.
Candidates cram layer names and numbers but never practice translating a description like 'a switch forwarding based on MAC addresses' or 'a SYN flood' into a layer, so under time pressure they default to the wrong number or confuse adjacent layers.
What to do instead
Build a one-page mapping table of common protocols, devices, and attacks against each layer, then drill by reading scenario stems and stating the layer plus the reason before checking the answer. Practice explaining why a given control (e.g., a firewall ACL vs. an application proxy) sits where it does.
Confusing symmetric and asymmetric cryptography when answering questions about key distribution, digital signatures, and TLS handshakes.
Candidates learn that 'symmetric is fast, asymmetric is slow' but do not internalize which key does what, so they misattribute signing to the private key of the recipient or claim TLS encrypts all traffic with RSA.
What to do instead
Write out the TLS handshake step by step from memory and label each operation: which key encrypts, which key signs, which key verifies. For every crypto question, ask 'who holds which key and what property is being proven (confidentiality vs. authenticity vs. integrity)?' before choosing.
Selecting 'block the IP' or 'blacklist the source' as the response to an attack without considering whether the indicator is spoofable or whether the attack is volumetric versus application-layer.
Candidates pattern-match on 'attack detected' and pick the most familiar defensive action, ignoring that source IPs in SYN floods and reflected DDoS are spoofed, so IP blocking is ineffective.
What to do instead
Before answering, classify the attack by layer and by whether the source is trustworthy. If spoofing is possible, favor rate limiting, SYN cookies, upstream scrubbing, or filtering at the provider. Practice writing a one-sentence justification for why each distractor control fails.
Reading a log or packet capture and answering from the first matching line rather than correlating timestamps, source/destination pairs, and sequence across events.
Candidates treat monitoring questions as single-fact lookups and skip the multi-event reasoning the scenario demands, so they miss that an earlier benign-looking event is the actual root cause or that an alert is a false positive.
What to do instead
Adopt a fixed triage routine: identify the asset, the time window, the user, and the outcome, then check whether each event is consistent with the others. Practice on sample log excerpts by writing a short timeline before looking at the options.
Confusing the order and purpose of incident response phases, especially containment versus eradication and identification versus containment.
The phases are learned as a list without the decision logic that separates them, so candidates pick 'eradicate' when the scenario describes isolating a host, or pick 'containment' when malware is still being removed.
What to do instead
For each phase, write the question it answers: identification = what happened and scope; containment = how do we stop spread now; eradication = how do we remove the cause; recovery = how do we restore; lessons learned = what changes. Classify each action verb in practice scenarios against these questions.
Treating risk as equivalent to a single severity score, ignoring likelihood, impact, and the difference between inherent and residual risk.
Candidates latch onto CVSS base scores or qualitative labels and forget that risk combines probability and consequence, and that existing controls reduce residual risk, leading to wrong prioritization answers.
What to do instead
Practice computing risk as likelihood times impact and explicitly stating the control that changes residual risk. When a question gives a CVSS score plus context (exposure, compensating controls, asset criticality), justify prioritization using the context rather than the score alone.
Choosing an authentication factor by its label rather than by what it actually verifies, such as classifying a security question or a one-time code as 'something you have'.
Candidates memorize the three factor categories but do not test each example against the definition, so knowledge-based questions, SMS codes, and hardware tokens get misclassified.
What to do instead
Define each factor by the evidence it proves: knowledge (something you know), possession (something you have), inherence (something you are). For each example, ask what the user must physically present or recall. Note that a password plus a security question is still single-factor because both are knowledge.
Answering compliance questions by naming a framework (PCI DSS, HIPAA, ISO 27001, NIST) without matching the framework's actual scope, control intent, or the organization's obligation.
Candidates learn framework names as buzzwords and assume any question mentioning regulated data maps to the most familiar standard, missing that the scenario's data type or business model points to a different obligation.
What to do instead
Build a comparison table of major frameworks with columns for data type covered, who must comply, and a representative control. Read each scenario for the data category first, then select the framework that governs that data, and verify the control described actually belongs to it.
Confusing vulnerability scanning with penetration testing and treating a scan finding as proof of exploitability.
Candidates see 'vulnerability identified' and assume confirmed compromise or validated risk, or conversely dismiss a scanner result as noise, because they have not internalized the difference between detection and exploitation.
What to do instead
State the purpose of each: scanning enumerates potential weaknesses with possible false positives; penetration testing validates exploitability with human judgment. For each question, ask whether the scenario describes discovery, validation, or remediation, and choose the activity that matches that stage.
Applying a forensic process that alters evidence, such as analyzing a live system before capturing volatile data or working on the original disk instead of a verified image.
Candidates focus on finding the answer (the attacker, the malware) and skip order-of-volatility and chain-of-custody reasoning, so they choose actions that destroy memory-resident evidence or break admissibility.
What to do instead
Memorize the order of volatility (registers/cache, memory, network state, disk, backups) and the rule to image before analysis with hash verification. For each forensic scenario, ask what evidence would be lost by the proposed action and whether the action preserves integrity and chain of custody.