Open jwinterknight opened 2 months ago
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)
Actually it would make more sense to parse out type
, display_name
, and alternate_id
and then let end users filter on their end in queries, alerts, and ES|QL.
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.
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 thedisplay_name
be parsed out when thetype
is "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" }