CyberOps Associate common mistakes
CyberOps Associate · Understand the traps and how to avoid them.
When a scenario describes a weakness in software, the candidate selects "threat" or "exploit" instead of "vulnerability," and when the scenario describes an attacker, they select "vulnerability."
Everyday speech uses these words interchangeably ("a security threat" often means a flaw), and the exam deliberately writes stems where the noun roles are the only discriminator. Candidates pattern-match on the topic (e.g., "unpatched server") rather than on the role the noun plays in the sentence.
What to do instead
Before answering, label each entity in the stem with one of four fixed roles: weakness in a system = vulnerability; actor or event with potential to cause harm = threat; the working method or code that leverages a weakness = exploit; the combination of likelihood and impact = risk. If the stem says "could be taken advantage of" it is a vulnerability; if it says "a group is targeting" it is a threat.
The candidate answers a control-classification question with the wrong category, e.g., labeling audit logging a preventive control, labeling a firewall a detective control, or labeling a backup a preventive control.
Candidates classify by the tool's reputation ("firewalls are security") rather than by the control's effect at the moment of the event. The functional difference between stopping an action, noticing an action, and restoring after an action is not something most people articulate in daily work.
What to do instead
Apply a one-question test to each option: does it act before the event (preventive), during/after the event to notice it (detective), or after the event to restore or limit damage (corrective)? Logging, IDS, and audits are detective; firewalls, ACLs, and hardening are preventive; backups, reimaging, and patches applied post-incident are corrective.
The candidate reads a single alert, log line, or signature hit and concludes the host is definitively compromised, or conversely dismisses a corroborated multi-source finding as noise.
Real SOC work trains analysts to triage fast, and exam stems often contain one dramatic-sounding event. Candidates conflate "the sensor reported X" with "X happened," forgetting that a signature match is an observation, not a verdict.
What to do instead
Separate detection from confirmation explicitly. Ask: is there a second independent source (host telemetry, network flow, user report, integrity check)? If the stem gives only one artifact, the defensible answer is "suspicious, needs validation," not "confirmed compromise." Reserve confirmed-compromise answers for stems that supply corroboration or direct evidence of effect.
The candidate reverses source and destination in a flow or log record, misreads a timestamp as local time when it is UTC, or treats the absence of a log entry as proof that an activity did not occur.
Log formats vary by vendor and column order is easy to skim. Candidates also forget that sensors may be positioned asymmetrically and that logging gaps, retention windows, and filtering create silence unrelated to attacker behaviour.
What to do instead
For every record, write out the five-tuple in a fixed order (source IP:port, destination IP:port, protocol) before reasoning about it, and use the well-known-port side plus TCP flags to decide who initiated. Convert all timestamps to one reference zone and note the offset. Treat a null result as "not observed in this data source," and ask whether that source could have seen the activity at all.
The candidate answers a governance question ("what should the organization document to require this behaviour?") with a technical product, or answers a technical question with "write a policy."
Engineers are biased toward tooling and read scenario stems as troubleshooting problems. The wording that signals a policy, standard, procedure, or guideline is subtle and easy to skim past.
What to do instead
Classify the requested artifact first: policy = management intent and mandatory high-level rules; standard = specific mandatory requirements or baselines; procedure = step-by-step instructions for executing a task; guideline = recommended, non-mandatory practice. If the stem says "who must," "is required," or "management direction," choose the governance artifact; if it says "how to configure" or "which setting," choose the technical answer.
The candidate mixes up data-handling concepts, selecting least privilege when the stem describes need-to-know, or choosing "encrypt the database" when the stem's issue is that staff can see records unrelated to their job.
Both principles sound like "give people less access," so the distinction between rights to perform functions/use resources (least privilege) and rights to view specific information (need-to-know) collapses under time pressure.
What to do instead
Map the stem's noun to the principle: functions, systems, and permissions = least privilege; information, records, and data sets = need-to-know. Then check the option against the data classification involved - handling requirements follow the classification label, so an option that ignores the label is usually wrong.
The candidate jumps to eradication or recovery before containment, or assigns an activity such as "imaging the host" or "writing the final report" to the wrong phase of the incident response lifecycle.
In practice these activities overlap and iterate, and candidates remember incidents as stories rather than as a defined lifecycle. Stems also describe an ongoing attack, which feels like it demands an immediate fix rather than a boundary.
What to do instead
Anchor on the ordered lifecycle: preparation, detection and analysis, containment/eradication/recovery, post-incident activity. Ask what the team must accomplish first to stop the spread before removing the cause, and treat documentation, lessons learned, and evidence preservation as occurring within defined phases (post-incident for lessons learned; during detection/analysis and containment for evidence handling).
The candidate selects "hash the drive" or "make a copy" when asked about chain of custody, or selects "turn off the server" when the scenario requires preserving volatile evidence.
Hashing and copying are the memorable, technical-sounding evidence steps, so they attract selection even when the question concerns documentation, transfers, or the order of volatility. Powering off feels like the safest containment action.
What to do instead
Read the question's object: if it asks how to prove the evidence was not altered in transit or storage, the answer involves documented, signed custody records of who held it, when, and where. If it asks what to collect first, follow volatility order (memory and running state before disk, disk before backups and logs), and prefer isolating the host from the network over shutting it down when memory matters.
The candidate misreads a packet capture or flow sequence, e.g., calling a stream "normal" when it shows a SYN to many ports with RST responses, or reading a SYN-ACK as the initiation of a connection.
Reading captures requires reconstructing a conversation in time, and candidates look at individual packets rather than the sequence and flag pattern. Stopping at the first familiar-looking packet produces a plausible but inverted conclusion.
What to do instead
Reconstruct the three-way handshake first (SYN, SYN-ACK, ACK) to establish direction and initiator. Then characterize the pattern: one source to many destinations/ports with resets = scanning; many sources to one destination = probable DoS; small repeated requests with large responses = possible data transfer. Only after naming the pattern should you judge benign versus malicious.
The candidate inverts false positives and false negatives, or confuses an IDS with an IPS when the stem describes placement or the ability to block traffic.
The phrasing is counterintuitive: a false positive is an alarm on benign activity, but candidates reason from the word "positive" as "something good happened." Similarly, both devices inspect traffic, so the distinguishing behavior (blocking) gets lost.
What to do instead
Memorize the definitions as alarm-versus-truth: false positive = alarm raised, activity benign; false negative = no alarm, activity malicious. For device questions, ask whether the described behavior changes the traffic (drop, reset, block) - if yes, it is inline/IPS; if it only reports, it is passive/IDS.