[SentinelOne] Mapping Activity Data field

[jamiehynds]

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:

{
  "groupId": "12950259681860968951",
  "profileUuids": "N/A",
  "vendorId": "5AC",
  "interface": "USB",
  "deviceName": "APPLE INC. IPHONE",
  "uid": "00008130001E654E3CF0001C",
  "minorClass": "N/A",
  "ruleType": "productId",
  "eventTime": "2024-06-13T16:34:36.752+00:00",
  "osType": "windows",
  "lmpVersion": "N/A",
  "ruleId": -1,
  "eventId": "{733fcc36-29a1-11ef-b1e0-ac5afcbabc3c}",
  "creator": "N/A",
  "productId": "12A8",
  "lastLoggedInUserName": "jbloggs",
  "eventType": "disconnected",
  "version": "N/A",
  "sourceType": "API",
  "deviceClass": "06h"
}

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[narph]

• needs update to 8.14, subobjects set at the data stream level, set sub-fields as siblings to the flattened level, similar to https://github.com/elastic/integrations/pull/9868

[andrewkroh]

At 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

• use subobjects: false to mitigate conflicts leaf and non-leaf data types
• add static data type mappings for the fields we know about (e.g. eventTime is a date)
• map everything else under 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).