SCS-C02 Threat Detection and Incident Response Practice Question

A company is using Amazon GuardDuty to detect threats. They notice that GuardDuty is generating a high volume of 'UnauthorizedAccess:EC2/SSHBruteForce' findings from an internal EC2 instance that is used for vulnerability scanning. The security team wants to reduce false positives without disabling GuardDuty entirely. What should they do?

⚠ Common exam trap

Candidates often confuse suppression rules with disabling finding types or disabling GuardDuty entirely, not realizing that suppression rules provide a granular, IP-based mechanism to reduce noise without compromising overall security coverage.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a suppression rule for findings originating from the vulnerability scanner's IP address.

Amazon GuardDuty's suppression rules allow you to filter out findings based on criteria such as IP address, without disabling the detector or any finding types. By creating a suppression rule that matches the vulnerability scanner's IP address, you automatically archive and suppress future 'UnauthorizedAccess:EC2/SSHBruteForce' findings from that specific source, reducing false positives while maintaining full threat detection coverage for all other instances.

Answer analysis

Option-by-option breakdown

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

✗
Change the security group of the vulnerability scanner to block SSH traffic.
Why it's wrong here
Changing the security group on the vulnerability scanner to block SSH traffic would stop new SSH connections from that instance, but GuardDuty detects threats by analyzing VPC Flow Logs, DNS logs, and CloudTrail events independently of the current security-group state. This action also does nothing to archive or filter the existing false-positive finding, and it would break the scanner's legitimate vulnerability-assessment function.
✗
Disable GuardDuty for the subnet where the vulnerability scanner is located.
Why it's wrong here
GuardDuty is enabled and managed at the AWS account and Region level, not at the subnet or VPC level. There is no supported configuration to disable GuardDuty for a specific subnet; doing so would require stopping GuardDuty entirely, which is neither practical nor available. The correct way to reduce noise from a trusted source is to use a scoped suppression rule, not to disable monitoring for a resource.
✗
Disable the 'UnauthorizedAccess:EC2/SSHBruteForce' finding type in GuardDuty.
Why it's wrong here
Disabling the 'UnauthorizedAccess:EC2/SSHBruteForce' finding type in GuardDuty, even if such a global toggle existed, would suppress all SSH brute-force findings across every workload in the account, including genuine attacks against production systems. That approach is dangerously broad because it removes all visibility into a common attack vector rather than distinguishing between expected scanner traffic and real threats. The safe, targeted solution is to suppress only findings originating from the known scanner IP.
✓
Create a suppression rule for findings originating from the vulnerability scanner's IP address.
Why this is correct
Creating a suppression rule that matches the vulnerability scanner's IP address is the correct action because GuardDuty suppression rules automatically archive findings from trusted sources without changing your security posture. The rule can be scoped to the specific IP and finding type (or even the specific scanner instance), preventing future false positives while preserving detection of real SSH brute-force attempts from any other source.

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question