Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fbc7ec0d6b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Configure CloudTrail to capture management Read events and ingest them with | ||
| the aws:cloudtrail sourcetype. The tested CloudWatch Logs operations are | ||
| recorded as management events, so a CloudWatch Logs data-event selector is | ||
| not required. The analytic uses a rolling five-minute window and counts |
There was a problem hiding this comment.
When a deployment follows this guidance and collects only management Read events, CloudTrail will not ingest GetLogEvents or FilterLogEvents: AWS classifies these CloudWatch Logs log-group operations as data events. Consequently, the documented configuration misses the primary log-retrieval activity—and specifically the GetLogEvents activity used by this analytic's true-positive test. Require an advanced data-event selector for AWS::Logs::LogGroup instead of stating that no selector is needed.
Useful? React with 👍 / 👎.
| | streamstats time_window=5m count AS event_count | ||
| by user vendor_account |
There was a problem hiding this comment.
In environments where CloudTrail events are delivered or ingested more than once, this counts every copy as a separate API operation because no eventID deduplication occurs. A principal with at most 500 actual calls can therefore cross the threshold and generate a false alert, contradicting the implementation guidance that promises unique identifiers are counted to reduce duplicate-ingestion effects. Deduplicate by eventID before streamstats (while retaining events without an ID), or remove that guarantee and explicitly accept duplicate-sensitive counts.
Useful? React with 👍 / 👎.
Summary
Adds an AWS CloudTrail analytic that detects more than 500 Amazon CloudWatch Logs read operations performed by the same principal and AWS account within a rolling five-minute window.
Monitored operations
Detection details
Testing
Attack data
splunk/attack_data#1225