TR-2335: Use of Incident Response/Review compatible fields in Correlation Searches

[beano500]

A few of the use cases (e.g. "Detect Mimikatz With PowerShell Script Block Logging") generate fields in the notable events that are not compatible with the default configuration of Incident Response / Asset Enrichment (UserID) in this case.

If I have asset enrichment enabled, and the field that identifies a user is, for example, "user" - then within Incident Response fields like user_email, user_bunit, etc. are also pulled through - as they have been defined in "Incident Review - Event Attributes"

If a field of a different name is used, for example, "UserID", then these fields are not pulled through (and would have to be manually defined as an "Incident Review - Event Attributes"

Also the identity enrichment macro "get_identity4events()" currently reports that it only supports the field names - user, src_user, host_owner, orig_host_owner, src_owner, dest_owner, or dvc_owner. So I am not sure if UserID would work.

Consistency in naming fields across the whole of ESCU would be good, and I would suggest adopting some of the CIM based names would be good.

Many thanks
Simon

[ljstella]

Update: We're aware of this issue, and have been for some time but are still determining the best route forward for revisiting every single search that's included as part of ESCU.

[nasbench]

No longer applicable as per the JIRA ticket