[Enhancement] Set event.kind to alert for AWS GuardDuty findings#18895
[Enhancement] Set event.kind to alert for AWS GuardDuty findings#18895
Conversation
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
This comment has been minimized.
This comment has been minimized.
✅ Vale Linting ResultsNo issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
This comment has been minimized.
This comment has been minimized.
TL;DR
Remediation
Investigation detailsRoot CauseInconclusive with current data. The pre-fetched log at Evidence
Verification
Follow-upOnce the full failed step output is available, I can map it directly to the owning file/line and provide a precise fix recommendation. What is this? | From workflow: PR Buildkite Detective Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. |
💔 Build Failed
Failed CI StepsHistory
|
Proposed commit message
Set `event.kind` to `alert` for the AWS GuardDuty findings. Summary
This sets
event.kindtoalertin AWS GuardDuty events, so that the default external alert promotion detection rule inelastic/detection-rulesmatches GuardDuty findings and surfaces them on the Alerts page. Currently the pipeline setsevent.kind: event, which causes the promotion rule to silently skip GuardDuty data despite the integration being installed.Same pattern as #16401 (Wiz Defend) and #5744 (M365D incidents).
Why this is safe
The
aws.guarddutydata stream is finding-only by API contract:httpjsonandaws-s3), both titled "Collect Amazon GuardDuty Findings from AWS."httpjsonpolls AWS's GuardDuty Findings API (ListFindings/GetFindings), which returns findings only.aws-s3ingests GuardDuty findings exports, which contain findings only.This is the key difference from #10528 (F5 BIG-IP ASM), where a single dataset legitimately mixed informational and alert events and unconditional
event.kind: alertmislabeled the informational ones. There is no equivalent informational subset inaws.guarddutyto mislabel.The two existing GuardDuty-related detection rules in
elastic/detection-rules(defense_evasion_guardduty_detector_deletionanddefense_evasion_guardduty_member_manipulation) detect tampering with the GuardDuty service itself via CloudTrail (DeleteDetector,DisassociateMembers, etc.) and querylogs-aws.cloudtrail-*, notlogs-aws.guardduty-*. They are unaffected by this change.Checklist
changelog.ymlfile.