Skip to main content

Hello all, 

We have both AWS CloudTrail and GuardDuty feeds configured in our SecOps instance. The detection rules for CloudTrail seem to be working & giving the right detections. The ones we have in place for GuardDuty findings are not working as expected - no detections at all. I did some debugging of the GuardDuty logs in the SIEM Search, it looks like the CloudTrail event digest logs are getting misclassified as from LogSource : GuardDuty (please find below).

I checked with my AWS admin and he confirmed both are running on the same SQS queue. Could this be the root cause for the issue? Is my perception correct here? If so, please confirm if I have create dedicated queues. Standard or FIFO queue? What are the best practices? It would be helpful if someone can share link for the official Google SecOps documentation that justifies this new proposal to my management.

Thanks for helping out! Appreciate your feedback.

Creating two dedicated SQS queues ensures that each log source has its own ingestion path, allowing Google SecOps to correctly identify and parse the logs, leading to accurate detection.
Unfortunately I don’t see any documentation that explicitly states that is best practice but Chronicle Feed Management API  implicitly supports the need for distinct configurations for different data sources.

Some other resources that might help:
Collect AWS GuardDuty logs
Create and manage feeds using the feed management UI