Cyber Security Quiz: Detection Tuning
10 questions · exam conditions
0:00
Detection TuningQuestion 1 of 10

A network detection rule repeatedly alerts on a vulnerability scanner operated by the security team. Analysts propose excluding all traffic originating from the scanner's static IP address. The scanner uses privileged credentials and can initiate connections to most production systems.

What is the most significant detection-tuning concern with the proposed exclusion?

The exclusion will convert every previous scanner alert into a false negative, even when the activity was authorized.
The exclusion may hide malicious activity if the scanner or its address is compromised or impersonated.
The exclusion will increase false positives because privileged scanning traffic will receive less contextual analysis.
The exclusion may duplicate scanner alerts because both the source address and credentials remain trusted.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Detection Tuning

Practice Detection Tuning in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Detection Tuning, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A network detection rule repeatedly alerts on a vulnerability scanner operated by the security team. Analysts propose excluding all traffic originating from the scanner's static IP address. The scanner uses privileged credentials and can initiate connections to most production systems.

What is the most significant detection-tuning concern with the proposed exclusion?

  1. The exclusion will convert every previous scanner alert into a false negative, even when the activity was authorized.
  2. The exclusion may hide malicious activity if the scanner or its address is compromised or impersonated. (correct answer)
  3. The exclusion will increase false positives because privileged scanning traffic will receive less contextual analysis.
  4. The exclusion may duplicate scanner alerts because both the source address and credentials remain trusted.
Explanation: When tuning detection rules, you must always ask: what new risk does this exclusion create? Excluding a traffic source isn't just an administrative convenience — it's a trust decision. The key framework here is understanding that detection exclusions based on IP addresses create a blind spot, and blind spots can be exploited. The scanner in this scenario holds privileged credentials and can reach most production systems — making it an extraordinarily high-value target. If an attacker compromises the scanner host, or simply spoofs its IP address, your detection rules will silently ignore their activity. Legitimate-looking source addresses can mask malicious behavior, and this exclusion would make that evasion trivially easy. That's why B is correct: the exclusion risks hiding real attacks behind a trusted identity. A is wrong because it misrepresents what happens to past alerts — those have already fired and been logged. The exclusion applies going forward, not retroactively. Describing past alerts as "false negatives" is technically incoherent; a false negative means an alert didn't fire when it should have. C is wrong because excluding traffic reduces alerts — it doesn't increase false positives. Less analysis means fewer alerts overall, not more noise. D is wrong because exclusions suppress alerts, not duplicate them. Trusting both the IP and credentials would not cause double-alerting; it would cause silence. Study tip: Whenever you see a detection-tuning question involving IP-based exclusions, immediately think about IP spoofing and host compromise. The question is almost always testing whether you recognize that static IP trust is fragile — not whether the exclusion is operationally convenient.

Question 2

A credential-theft incident causes the same endpoint detection to fire once per minute for an hour. Analysts confirm that every alert refers to the same genuinely malicious process. The team changes the rule so that identical alerts from the same host are grouped into one case for one hour.

How should the primary effect of this change be characterized?

  1. It reduces false positives because all repeated alerts after the first alert are necessarily false.
  2. It reduces alert duplication without showing that the underlying detections were false positives. (correct answer)
  3. It creates false negatives because each grouped alert represents a separate undetected malicious process.
  4. It increases detection sensitivity because one case now contains multiple copies of the same evidence.
Explanation: When working through SOC operations questions, you need to carefully distinguish between alert quality (false positives/negatives) and alert volume management (deduplication and grouping). These are fundamentally different concepts that exam writers love to conflate. In this scenario, analysts already confirmed every single alert represents the same genuinely malicious process. That confirmation is the critical fact. When the team groups 60 identical alerts into one case, they aren't changing what was detected — they're changing how many tickets represent it. The underlying detection logic remains accurate, the malicious process is still caught, and no real events are missed. This is precisely why B is correct: alert deduplication reduces noise and analyst fatigue without touching detection accuracy whatsoever. A is wrong because it fundamentally misdefines "false positive." A false positive is an alert that fires on benign activity. Alerts 2 through 60 were still accurate detections of real malicious behavior — they were redundant, not false. Calling them false positives because they're duplicates is a dangerous misconception that could lead analysts to dismiss legitimate signals. C gets the logic exactly backwards. A false negative means a malicious event goes undetected. Here, the process is detected and represented in the grouped case — nothing is missed. Grouping identical alerts from the same host into one case doesn't hide separate malicious processes; it consolidates one process's repeated signals. D is simply incoherent. Packing multiple copies of the same evidence into one case doesn't improve detection sensitivity, which measures whether the rule catches threats in the first place. The study tip: always anchor "false positive" and "false negative" to detection accuracy, not alert count. Volume reduction ≠ accuracy change.

Question 3

A detection currently alerts when a user signs in from an unusual country or from a previously unseen device. Many legitimate employees receive new laptops, creating excessive alerts. The team proposes changing the logic so that an alert requires both an unusual country and a previously unseen device.

Which outcome is most likely if the proposed logic is implemented without any additional conditions?

  1. False positives will likely decrease, but attacks satisfying only one condition may become false negatives. (correct answer)
  2. False negatives will likely decrease, because requiring both indicators confirms malicious behavior more reliably.
  3. True positives will necessarily remain unchanged, because the same two indicators are still evaluated by the rule.
  4. False positives will likely increase, because conjunctions create more alert combinations than disjunctions.
Explanation: Whenever you see a question about detection logic, think about the trade-off between false positives (legitimate activity flagged as malicious) and false negatives (malicious activity that goes undetected). Changing a rule's logical operator — from OR to AND — is a classic tuning decision with predictable consequences. An OR rule alerts when at least one condition is true, casting a wide net. An AND rule alerts only when all conditions are simultaneously true, narrowing that net significantly. In the scenario, switching from OR to AND means a user traveling to an unusual country on a known device won't trigger an alert — nor will a new laptop used from a familiar location. Both of those cases would have fired under the old rule. The result: fewer alerts overall, which does reduce false positives (helping with the laptop-replacement noise). However, a genuine attacker who satisfies only one condition — say, logging in from a foreign country on a stolen known device — will now slip through undetected. Those missed attacks become false negatives, making A the correct answer. Choice B is wrong because requiring both conditions actually increases false negatives — it lets more attacks go unnoticed, not fewer. Choice C is wrong because the same indicators being evaluated doesn't mean the same events trigger alerts; the stricter conjunction necessarily changes which true positives fire. Choice D is wrong — AND logic reduces alert volume compared to OR; conjunctions are more restrictive, not more generative. Study tip: Map OR → broader coverage (more FPs, fewer FNs) and AND → narrower coverage (fewer FPs, more FNs). This relationship appears frequently in detection-tuning questions.

Question 4

To tune a noisy rule, an engineer treats every alert closed as "benign" as a confirmed false positive. The closure workflow automatically marks unreviewed alerts benign after seven days. The engineer then suppresses the patterns most common among those closures.

What is the principal risk in this tuning method?

  1. The rule may become more sensitive because expired alerts are counted more than once during tuning.
  2. The timeout will prevent false negatives because every unreviewed event eventually receives a label.
  3. Confirmed benign events may become true positives because the suppression changes their historical labels.
  4. Unverified malicious alerts may be treated as benign, causing future true activity to be suppressed. (correct answer)
Explanation: When you see a tuning question like this, focus on data integrity and labeling accuracy — specifically, whether the inputs used to make tuning decisions actually represent what they claim to represent. The scenario's fatal flaw is in how "benign" labels are assigned. When an alert sits unreviewed for seven days and gets automatically marked benign, no human ever confirmed it was harmless. A real attacker moving slowly — think low-and-slow exfiltration or dormant malware beaconing — could easily fall into that seven-day window. Once that alert is auto-labeled benign, it feeds the tuning process as a confirmed false positive. The engineer then suppresses the patterns it matches, meaning future alerts with identical characteristics will be silenced. Genuine malicious activity gets buried. That's exactly what D describes: unverified alerts treated as benign, causing real threats to be suppressed going forward. A is wrong because the tuning process doesn't recount expired alerts multiple times — there's no duplication mechanism described. The sensitivity concern is fabricated. B gets the logic backwards: the timeout creates false negatives by mislabeling potential true positives as benign, not prevents them. A label is not a verdict. C sounds plausible but confuses causality — suppression changes future detection behavior, not the historical labels of already-closed events. The past closures aren't relabeled; the future alerts are simply never raised. For exam strategy, watch for tuning scenarios where automation substitutes for human judgment. Any time a system auto-labels data that feeds back into its own configuration, ask: "What happens if that label is wrong?" That's almost always where the risk lives.

Question 5

A behavioral rule alerts when an endpoint risk score is at least 7070. Review shows that recurring, authorized maintenance activity usually scores from 7070 through 7676, while every confirmed attack in the reviewed sample scored at least 8484. The team proposes raising the threshold to 8080.

Which statement most accurately describes the likely effect of this tuning change?

  1. It should reduce observed false positives, but attacks scoring below the new threshold could become false negatives. (correct answer)
  2. It should reduce observed false negatives, because only events with stronger evidence will generate alerts.
  3. It should eliminate false positives without affecting false negatives, because all reviewed attacks scored above the threshold.
  4. It should increase both true positives and false positives, because a higher score represents greater detection sensitivity.
Explanation: Whenever you see a question about tuning detection thresholds, anchor yourself to two key concepts: false positives (legitimate activity incorrectly flagged as malicious) and false negatives (actual attacks that fail to generate an alert). Raising a threshold means the system requires stronger evidence before alerting — which has predictable, opposing effects on each error type. In this scenario, the current threshold of 7070 catches authorized maintenance activity scoring 7070–7676, producing false positives. Raising the threshold to 8080 pushes those legitimate events below the alert line, so those false positives disappear. However, the reviewed attacks scored at least 8484 — but that's only the reviewed sample. Real-world attacks don't guarantee scores above 8080. Any future attack scoring between 8080 and 8383 would now go undetected, creating false negatives. Answer A correctly captures both sides of this tradeoff. Answer B is backwards — raising a threshold reduces sensitivity, which increases false negatives rather than reducing them. Answer C makes an overconfident claim: just because reviewed attacks scored above 8484 doesn't mean all future attacks will. You cannot generalize a sample to eliminate an entire error class. Answer D confuses directionality — a higher threshold means the bar for alerting is harder to clear, which reduces detection sensitivity and therefore lowers both true positives and false positives, not increases them. As a study tip: always think of threshold changes as a sliding scale. Raising a threshold trades false positives for false negatives; lowering it does the opposite. Sample-based evidence can inform but never guarantee future behavior.

Question 6

A command-line detection is tuned to require a specific suspicious argument. Testing succeeds on newer endpoints. Several older endpoints, however, do not collect process command-line arguments at all. An attacker executes the relevant command on one of those older endpoints, and no alert is generated.

Which interpretation is most accurate?

  1. The event is a false positive because the rule evaluated incomplete telemetry originating from an otherwise legitimate, enrolled endpoint.
  2. The event is a true negative because the suspicious argument was not present in the data collected from that endpoint, so no match occurred.
  3. The event is a false negative caused by a telemetry dependency that the tuned rule cannot satisfy on endpoints lacking command-line argument collection. (correct answer)
  4. The event is a true positive because the underlying command executed was malicious, regardless of whether the detection system generated an alert.
Explanation: When evaluating detection outcomes, you need to think in two dimensions: did the attack actually happen? and did the system alert? The four combinations — true positive, true negative, false positive, false negative — depend on both the ground truth and the system's response. This question adds a third layer: why the system responded as it did. Here, an attacker genuinely executed a malicious command (the attack happened), but no alert fired. That mismatch — attack occurred, no alert — is the definition of a false negative. The critical detail is why there was no alert: the rule required command-line argument data that the older endpoint simply never collected. The detection had a hidden dependency on a telemetry field that didn't exist in that environment. That makes C the correct answer — a false negative caused by an unsatisfied telemetry dependency. A misuses "false positive," which describes an alert firing on a benign event. Nothing about this scenario involves an alert firing at all, and nothing was benign — so this is doubly wrong. B is the most tempting trap: it sounds logical to say "the argument wasn't in the data, so no match = true negative." But a true negative means no attack occurred and no alert fired. Here an attack did occur, so the absence of an alert is a failure, not a correct non-detection. D confuses outcome terminology entirely — a "true positive" requires an alert to have been generated; no alert means no positive classification at all. For the exam, remember: negatives and positives describe the alert, not the attack. A true negative is correctly not alerting on a benign event — not silently missing a real one.

Question 7

A team modifies a detection rule to suppress a common administrative command when it is launched by a signed management agent. The tuned rule generates far fewer alerts in production. Management asks whether the change improved detection quality.

Which validation method provides the strongest evidence that the tuning reduced false positives without introducing unacceptable false negatives?

  1. Compare total alert counts before and after tuning, and approve the change if the post-tuning count is meaningfully lower than the pre-tuning count.
  2. Run representative benign activity and relevant attack techniques, then compare labeled outcomes before and after tuning to measure changes in both false positives and attack coverage. (correct answer)
  3. Confirm that the management agent is signed and review its vendor documentation, then assume all commands it launches can be safely excluded from detection.
  4. Survey analysts on whether the new alert queue feels more manageable after one normal business day of production operation.
Explanation: When evaluating whether a detection rule change genuinely improved quality — rather than just reduced noise — you need a method that measures both sides of the trade-off simultaneously: false positives (benign activity incorrectly flagged) and false negatives (real attacks missed). This is the core of controlled detection validation, sometimes called "purple team" or regression testing for detection rules. Option B is correct because it uses labeled test cases — known benign activity and known attack techniques — run against both the old and new rule configurations. By comparing outcomes with ground truth, you get concrete, measurable evidence that FPs decreased and that attack detection coverage remained intact. Without that attack-side check, you can't know whether the suppression swallowed real threats along with the noise. Option A is tempting because lower alert counts feel like success, but total alert volume is a poor proxy for quality. A rule that suppresses everything would generate zero alerts — terrible detection, great numbers. Volume metrics can't distinguish reduced FPs from missed attacks. Option C mistakes a signed binary for a trusted execution context. Attackers routinely abuse legitimate, signed management agents (a technique known as "living off the land"). Vendor documentation describes intended behavior, not attacker behavior. Excluding commands solely because the launcher is signed creates a dangerous blind spot. Option D substitutes analyst sentiment for empirical measurement. A lighter-feeling queue after one day reflects workload perception, not detection accuracy — it's anecdote, not evidence. Your study takeaway: whenever a question asks how to validate a detection change, look for the answer that tests both false positives and false negatives with ground-truth labeled data. Anything that measures only one side or relies on proxies (volume, signatures, feelings) is incomplete.

Question 8

After tuning, a security operations center reports that only a small percentage of its alerts are false positives. The team concludes that the rule also has a low false-negative rate. No independent incident review, threat hunting, or adversary simulation has been performed.

Why is the team's conclusion not supported by the reported result?

  1. A low false-positive percentage proves only that most benign events are alerted on, not that attacks are detected.
  2. False negatives usually generate low-severity alerts, so they must be counted separately from other alerts.
  3. False negatives do not appear in the alert queue and require an independent source of known malicious events. (correct answer)
  4. False-positive and false-negative rates are always equal when the same detection threshold is being evaluated.
Explanation: When evaluating detection rules, you need to distinguish between what your alert queue can tell you and what it cannot. False positives appear in the queue — they're alerts that fired on benign events. False negatives, however, are attacks that generated no alert at all. They're invisible to anyone looking only at the alert queue, which is exactly the trap the team in this scenario fell into. This is why C is correct: a low false-positive rate tells you the rule isn't crying wolf on benign traffic, but it says absolutely nothing about the attacks the rule silently missed. To measure false negatives, you need an independent ground truth — known malicious events introduced through threat hunting, red team exercises, or adversary simulation — so you can check whether the rule actually fired on them. A inverts the logic of false positives. A low false-positive rate means most alerts are real, not that benign events are being alerted on. It's describing the wrong direction of the metric entirely. B introduces a fabricated concept. There is no standard classification that separates false negatives by alert severity. False negatives produce no alert, so severity is irrelevant — you can't assign a severity level to something that never appeared. D is simply false. False-positive and false-negative rates move in opposite directions as you adjust a detection threshold — lowering sensitivity reduces false positives but increases false negatives, and vice versa. They are never guaranteed to be equal. The key study takeaway: anytime a question asks about detection effectiveness, ask yourself "what is missing from the data source?" Absence of alerts proves nothing about missed attacks.

Question 9

An anomaly rule was tuned using normal outbound traffic observed during a quiet business month. During a scheduled quarterly data-processing cycle, many legitimate systems exceed the learned baseline and generate alerts. Analysts suggest permanently widening the baseline to include the higher traffic volume.

Which approach best reduces the current false positives while limiting the risk of future false negatives?

  1. Disable the anomaly rule during all high-volume periods because scheduled activity cannot contain malicious traffic.
  2. Raise the global threshold permanently because any traffic volume observed once should be treated as normal.
  3. Use schedule and workload context for the known cycle while retaining detection for unusual hosts or destinations. (correct answer)
  4. Keep the original baseline unchanged because tuning any anomaly threshold necessarily creates false negatives.
Explanation: When tuning anomaly-based detection, your goal is precision: minimize false positives without creating blind spots (false negatives). The core tension here is between accommodating known, legitimate traffic patterns and remaining sensitive enough to catch actual threats hiding within those patterns. The smartest approach — and why C is correct — is contextual tuning. By tagging the quarterly processing cycle as a known scheduled event and scoping the relaxed threshold only to expected hosts and destinations, you preserve your ability to detect something genuinely suspicious (an unusual host exfiltrating data, or traffic to an unexpected destination) even during the high-volume window. The baseline doesn't disappear; it becomes smarter. A is dangerously wrong because disabling detection entirely during high-volume periods is exactly when an attacker might choose to strike — their malicious traffic blends into the noise. "Scheduled activity cannot contain malicious traffic" is a false assumption adversaries exploit. B commits the opposite mistake: permanently raising the global threshold treats a periodic outlier as a new normal for all traffic, effectively teaching the system to ignore elevated volumes forever. This directly manufactures future false negatives at a system-wide scale. D presents a false dilemma. It's true that poorly done tuning can introduce false negatives, but context-aware tuning done carefully does not — it refines detection rather than weakening it. Refusing to tune at all leaves your analysts drowning in noise. Study tip: On security operations questions, watch for answers that trade one problem for a worse one. The correct answer usually balances both error types rather than eliminating one at the other's expense.

Question 10

Before tuning, a rule produces 3030 true-positive alerts and 7070 false-positive alerts during a test period. Independent incident review also identifies 2020 malicious events that the rule did not alert on. A proposed filter would suppress 3535 of the benign alerts and 55 of the true-positive alerts. No other behavior changes.

What would the test results be after applying the filter?

  1. 2525 true positives, 3535 false positives, and 2525 false negatives (correct answer)
  2. 3030 true positives, 3535 false positives, and 2020 false negatives
  3. 2525 true positives, 7070 false positives, and 2020 false negatives
  4. 3030 true positives, 4040 false positives, and 2525 false negatives
Explanation: When a question gives you baseline detection metrics and asks how a filter changes them, your job is to track each category — true positives (TP), false positives (FP), and false negatives (FN) — independently, adjusting only what the filter explicitly touches. Start with the baseline: 3030 TPs (malicious events the rule caught), 7070 FPs (benign events the rule incorrectly flagged), and 2020 FNs (malicious events the rule missed entirely). The proposed filter suppresses 3535 benign alerts and 55 true-positive alerts. Suppressing benign alerts reduces FPs: 70−35=3570 - 35 = 35. Suppressing true-positive alerts means those malicious events now go undetected, so they convert from TPs to FNs: 30−5=2530 - 5 = 25 TPs, and 20+5=2520 + 5 = 25 FNs. The filter changes nothing else. That gives you 2525 TPs, 3535 FPs, and 2525 FNs — confirming A is correct. Choice B keeps TPs at 3030 and FNs at 2020, ignoring that suppressing 55 true-positive alerts removes those detections and increases missed events. Choice C leaves FPs unchanged at 7070, failing to account for the 3535 suppressed benign alerts, and also doesn't adjust the FN count. Choice D reduces FPs by only 3030 instead of 3535 and keeps TPs at 3030, mixing up which category each suppression affects. The key trap here is forgetting that suppressing a true-positive alert doesn't make the attack disappear — it makes the attack undetected, converting it to a false negative. Always ask yourself: when an alert is suppressed, what happens to the underlying event?