[Okta] Mapping flattened fields to parse application launched

[jwinterknight]

Currently, important Okta information is being mapped to a flattened field okta.target. Although that flattened field contains valuable security information, users can't build detections or use ES|QL from that field as it's flattened. Can the display_namebe parsed out when the typeis "AppInstance". This information details what SSO application is launched from the Okta console. See Sample data below of the flattened field.

{ "id": "f0923j02jf2fj23209fj", "type": "AppInstance", "display_name": "Okta Admin Console", "alternate_id": "Okta Admin Console" }, { "id": "ru2o20f2390j2f02fa", "type": "Rule", "display_name": "Admin Pol", "alternate_id": "unknown" }

also

{ "id": "jwoe228f23j2f3jfa", "type": "AppInstance", "display_name": "Office 365 Test", "alternate_id": "Office 365 Test" }, { "id": "f032fj234fjlakfjewf0j", "type": "AppUser", "display_name": "test employee", "alternate_id": "emp@testcompany.com" }

[elasticmachine]

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

[jwinterknight]

Actually it would make more sense to parse out type, display_name, and alternate_idand then let end users filter on their end in queries, alerts, and ES|QL.

[efd6]

The design intention here was that the field can be copied out to a user's field in a custom pipeline.

The issue here is that the relationships between fields each object of the target array are important, which means that the objects would need to be mapped as a nested field. Copying out the three fields listed (or even the conditional approach initially proposed) would still require this to happen, so if it is important enough for enough people then the approach would be to change the mapping, although this would have impacts on mapping in existing indexes.