crowdstrike: add support for OverwatchGenericDetectionSummaryEvent in falcon data stream#19969
crowdstrike: add support for OverwatchGenericDetectionSummaryEvent in falcon data stream#19969navnit-elastic wants to merge 3 commits into
Conversation
navnit-elastic
added
documentation
… falcon data stream
navnit-elastic
force-pushed
the
crowdstrike-19509
branch
from
60cc39d to
cc9d2fd
Compare
✅ Elastic Docs Style Checker (Vale)No 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;DRBuildkite failed before uploading the pipeline because the post-checkout hook could not merge PR #19969 with Remediation
Investigation detailsRoot CauseThis is a merge-conflict/configuration failure during Buildkite checkout. The build log shows the agent checked out PR commit
Evidence
Verification
What is this? | From workflow: PR Buildkite Detective Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. |
🚀 Benchmarks reportTo see the full report comment with |
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
![vera-review-bot[bot]](https://avatars.githubusercontent.com/in/3297022?s=60&v=4){kind=small}
| field: event.kind | ||
| value: alert | ||
| tag: set_event_kind | ||
| - append: |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: medium path: packages/crowdstrike/data_stream/falcon/elasticsearch/ingest_pipeline/overwatch_generic_detection_summary.yml:8
The overwatch pipeline sets event.kind/type but no event.category; add an appropriate ECS event.category (e.g. threat/malware) as the sibling detection pipelines do.
Details
This pipeline sets event.kind: alert and event.type: info but leaves event.category unset. The sibling detection sub-pipelines in this same data stream (detection_summary.yml, mobile_detection_summary.yml) append an event.category (malware). Alerts without an event.category are harder to filter and correlate in category-based security views and detection rules.
Recommendation:
Append a semantically appropriate ECS event.category for the detection, for example:
- append:
field: event.category
value: threat
tag: append_threat_category🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
There was a problem hiding this comment.
@jamiehynds, do you have preference on event.category for OverwatchGenericDetectionSummaryEvent?
There was a problem hiding this comment.
@navnit-elastic I'd recommend event.category: malware to ensure consistency with our other CrowdStrike mappings. Although not every OverWatchDetection will be confirmed malware, they're typically EDR-sourced threat-hunting alerts, so they fall squarely under this category even when the specific finding is behavioral.
There was a problem hiding this comment.
@jamiehynds, Thank you for the confirmation.
|
✅ All changelog entries have the correct PR link. |
| --- | ||
| description: Pipeline for OverwatchGenericDetectionSummaryEvent events. | ||
| processors: | ||
| - set: |
There was a problem hiding this comment.
Severity: 🟡 Medium confidence: high path: packages/crowdstrike/data_stream/falcon/elasticsearch/ingest_pipeline/overwatch_generic_detection_summary.yml:4
Overwatch pipeline never maps the event's ISO Timestamp, so @timestamp falls back to ingest time; add a date processor mapping crowdstrike.event.Timestamp to @timestamp.
Details
OverwatchGenericDetectionSummaryEvent carries its detection time only in crowdstrike.event.Timestamp (an ISO8601 string, e.g. 2026-05-15T10:15:00Z) and has no UTCTimestamp, eventCreationTime, or ContextTimeStamp. The default pipeline's date processors and the '@timestamp copy_from event.created' step (default.yml lines 133-167) all run BEFORE this sub-pipeline is invoked (default.yml line 284) and find no usable field, and this sub-pipeline sets no date field. The result is that neither @timestamp nor event.created is ever populated from the event, so @timestamp defaults to ingestion time and the true detection time is lost. The committed expected output confirms this: it contains no @timestamp and no event.created. Sibling summary pipelines (recon_notification_summary, mobile_detection_summary, cspm_events) all map their event timestamp; this one is the outlier.
Recommendation:
Add a date processor in the sub-pipeline that parses the ISO Timestamp into @timestamp (and drop it from the removal list / leave it as-is per package convention):
- date:
field: crowdstrike.event.Timestamp
target_field: '@timestamp'
timezone: UTC
formats:
- ISO8601
tag: date_overwatch_timestamp
if: ctx.crowdstrike?.event?.Timestamp != null
on_failure:
- append:
tag: append_error_message_overwatch_timestamp
field: error.message
value: 'Processor {{{_ingest.on_failure_processor_type}}} with tag {{{_ingest.on_failure_processor_tag}}} in pipeline {{{_ingest.on_failure_pipeline}}} failed with message: {{{_ingest.on_failure_message}}}'Then extend the expected test output to assert the resulting @timestamp so the mapping stays covered.
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
Review summaryIssues found across the latest commits 5ec1b7c — 1 medium
Issues found across earlier commits 92c387a — 1 high, 1 low
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
|
💚 Build Succeeded
History
|
2 participants
Proposed commit message
Checklist
changelog.ymlfile.Author's Checklist
How to test this PR locally
Related issues
Screenshots