[sentinel_one] Add Support for Application Risk Data Stream #14910
Conversation
mohitjha-elastic
added
enhancement
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
andrewkroh
added
dashboard
🚀 Benchmarks reportTo see the full report comment with |
💚 Build Succeeded
History
|
|
| {{fields "threat"}} | ||
|
|
||
| ### application risk |
There was a problem hiding this comment.
Move to the top after application (sort)
| @@ -0,0 +1,20 @@ | |||
| { | |||
There was a problem hiding this comment.
For this ILM policy to work, you would need delete_index privilege on source indices for kibana_system role.
| "tags": [ | ||
| "preserve_duplicate_custom_fields" | ||
| ], | ||
| "vulnerability": { |
There was a problem hiding this comment.
Can you check if any fields from https://docs.elastic.dev/security-solution/cloud-security/cdr/3p-dev-guide#vulnerability-findings-1 can also be added to this data stream?
| - set: | ||
| field: event.kind | ||
| tag: set_event_kind | ||
| value: event |
| # Use of "*" to use all namespaces defined. | ||
| source: | ||
| index: | ||
| - "logs-sentinel_one.application_risk-*" | ||
| dest: | ||
| index: "logs-sentinel_one_latest.dest_application_risk-1" | ||
| aliases: | ||
| - alias: "logs-sentinel_one_latest.application_risk" | ||
| move_on_creation: true | ||
| latest: | ||
| unique_key: | ||
| - event.dataset | ||
| - event.id | ||
| sort: "@timestamp" | ||
| description: >- | ||
| Latest application risk from SentinelOne. As application risk get updated, this transform stores only the latest state of each application risk inside the destination index. Thus the transform's destination index contains only the latest state of the application risk. | ||
| frequency: 30s |
There was a problem hiding this comment.
@nick-alayil, @maxcold
We are adding new vulnerability data to our SentinelOne integration and this is the transform use case for storing latest state of vulnerabilities (SentinelOne calls them application risks). I think it makes sense to defer transform addition so that we can add it as part of Extended protections (3rd party CDR integrations) list. This way we can avoid redundancy of having 2 transforms on same data. WDYT?
There was a problem hiding this comment.
If we can cover one transform for both use cases with no downsides, then definetly it makes sense to me!
Proposed commit message
Checklist
changelog.ymlfile.How to test this PR locally
Related Issue