Exam Security-Operations-Engineer Topic 3 Question 35 Discussion
Actual exam question for Google's Security-Operations-Engineer exam
Question #: 35
Topic #: 3
Question #: 35
Topic #: 3
A Google Security Operations (SecOps) detection rule is generating frequent false positive alerts. The rule was designed to detect suspicious Cloud Storage enumeration by triggering an alert whenever the storage.
objects.list API operation is called using the api.operation UDM field. However, a legitimate backup automation tool that uses the same API, causing the rule to fire unnecessarily. You need to reduce these false positives from this trusted backup tool while still detecting potentially malicious usage. How should you modify the rule to improve its accuracy?
objects.list API operation is called using the api.operation UDM field. However, a legitimate backup automation tool that uses the same API, causing the rule to fire unnecessarily. You need to reduce these false positives from this trusted backup tool while still detecting potentially malicious usage. How should you modify the rule to improve its accuracy?
Suggested Answer: D Vote an answer
Comprehensive and Detailed Explanation
The correct solution is Option D. The problem is that a known, trusted principal (the backup tool's service account) is performing a legitimate action (storage.objects.list) that happens to look like the suspicious behavior the rule is designed to catch.
The most precise and effective way to reduce these false positives without weakening the rule's ability to catch malicious actors is to create an exception for the trusted principal.
By adding principal.user.email != "[email protected]" (or the equivalent principal.user.userid) to the events or condition section of the YARA-L rule, the rule will now only evaluate events where the actor is not the known-good backup bot.
* Option A is incorrect because it just lowers the priority of the false positive; it doesn't stop it from being generated.
* Option B is incorrect because the legitimate tool might also perform repeated calls, leading to the same false positive.
* Option C is incorrect because api.service_name = "storage.googleapis.com" is less specific than api.
operation = "storage.objects.list" and would likely increase the number of false positives by triggering on any storage API call.
Exact Extract from Google Security Operations Documents:
Reduce false positives: When a detection rule generates false positives due to known-benign activity (e.g., from an administrative script or automation tool), the best practice is to add a not condition to the rule to exclude the trusted entity.8 You can filter on UDM fields to create exceptions. For example, to prevent a rule from firing on activity from a specific service account, you can add a condition to the events section such as:
and $e.principal.user.userid != "[email protected]" This technique, often called "allow-listing" or "suppression," improves the rule's accuracy by focusing only on unknown or untrusted principals.
References:
Google Cloud Documentation: Google Security Operations > Documentation > Detections > Overview of the YARA-L 2.0 language > Add not conditions to prevent false positives
The correct solution is Option D. The problem is that a known, trusted principal (the backup tool's service account) is performing a legitimate action (storage.objects.list) that happens to look like the suspicious behavior the rule is designed to catch.
The most precise and effective way to reduce these false positives without weakening the rule's ability to catch malicious actors is to create an exception for the trusted principal.
By adding principal.user.email != "[email protected]" (or the equivalent principal.user.userid) to the events or condition section of the YARA-L rule, the rule will now only evaluate events where the actor is not the known-good backup bot.
* Option A is incorrect because it just lowers the priority of the false positive; it doesn't stop it from being generated.
* Option B is incorrect because the legitimate tool might also perform repeated calls, leading to the same false positive.
* Option C is incorrect because api.service_name = "storage.googleapis.com" is less specific than api.
operation = "storage.objects.list" and would likely increase the number of false positives by triggering on any storage API call.
Exact Extract from Google Security Operations Documents:
Reduce false positives: When a detection rule generates false positives due to known-benign activity (e.g., from an administrative script or automation tool), the best practice is to add a not condition to the rule to exclude the trusted entity.8 You can filter on UDM fields to create exceptions. For example, to prevent a rule from firing on activity from a specific service account, you can add a condition to the events section such as:
and $e.principal.user.userid != "[email protected]" This technique, often called "allow-listing" or "suppression," improves the rule's accuracy by focusing only on unknown or untrusted principals.
References:
Google Cloud Documentation: Google Security Operations > Documentation > Detections > Overview of the YARA-L 2.0 language > Add not conditions to prevent false positives
by Levi at Dec 20, 2025, 03:02 AM
0
0
0
10
Comments
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Report Comment
Commenting
You can sign-up / login (it's free).