CS0-003 Security Operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Aggregate alerts by source IP and time window

  Why this is correct

  Aggregating alerts by source IP and time window groups multiple failed login attempts into a single, consolidated alert, effectively suppressing repetitive notifications while still preserving detection of brute-force or credential-stuffing activity. This correlation technique condenses dozens or hundreds of individual events into one actionable incident, reducing analyst alert fatigue and allowing the security team to focus on the actual attack pattern rather than being overwhelmed by event-level noise.

• ✗

  Disable the rule entirely

  Why it's wrong here

  Disabling the rule entirely removes all visibility into failed login attempts, which are often the first indicator of brute-force attacks, credential stuffing, or account compromise. This leaves the SIEM blind to a critical early-warning signal, and even if the rule is noisy, providing zero detection coverage is a much greater security risk. The correct approach is to tune the rule's aggregation and filtering logic, not to delete it outright.

• ✓

  Whitelist IP addresses of internal services that generate repeated failed logins

  Why this is correct

  Whitelisting IP addresses belonging to internal services that legitimately generate repeated failed logins suppresses known-benign events, such as an application with misconfigured credentials or a service account whose password expired. This targeted exclusion reduces false positives while preserving detection for truly suspicious IPs, but it must be applied narrowly and reviewed periodically because if a whitelisted service account is compromised, its malicious activity would also be silently ignored.

• ✗

  Increase the alert severity threshold

  Why it's wrong here

  Raising the alert severity threshold does not reduce the number of alerts generated by the rule; it only changes how severe the resulting alert is labeled (e.g., from high to critical) and may affect notification pathways, not the frequency of alert creation. Noisy rules need to be filtered via aggregation, whitelisting, or by adjusting the rule's match conditions, not by altering severity, which can actually worsen the problem by causing critical-level alerts to be ignored due to the same noise volume.

• ✗

  Increase the log retention period

  Why it's wrong here

  Increasing the log retention period affects only how long raw logs are stored for compliance or forensic analysis, and has no bearing on real-time alert generation or rule matching. The SIEM evaluates inbound event streams against rule logic essentially at the moment they arrive, so keeping logs longer will not lower the number of triggered alerts. Log retention is an operational and compliance concern, not a detection and tuning control.

Go deeper

Related to this question