Open jamiehynds opened 2 months ago
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)
flattened
level, similar to https://github.com/elastic/integrations/pull/9868At the moment I believe subobject: false
usage is blocked by https://github.com/elastic/kibana/issues/183496, so unless the workaround I mentioned in the Okta PR is valid, then this will need to wait on the Kibana fix.
The general approach to safely map this data will be
subobjects: false
to mitigate conflicts leaf and non-leaf data typeseventTime
is a date
)sentinel_one.activity.data.*
as a keyword (or we could see about disabling dynamic mappings which would require us to add mappings for anything users want to use)For backwards comparability, we keep the option of populating the sentinel_one.activity.data.flattened
field (see the okta PR).
We are currently mapping an important SentinelOne field,
sentinel_one.activity.data.flattened
to flattened. Although that flattened field contains valuable security information, users can't build detections from that field as it's flattened.Could we fully parse the field into ECS (where possible) to ensure users can get value from it
Sample data: