Crowdstrike FDR Mapping Enhancement

[jamiehynds]

related.ip
Our FDR pipeline currently adds observer.ip, source.ip and destination.ip to related.hosts but customer feedback suggests, it should be added be added to related.ip field instead of related.hosts.
https://github.com/elastic/integrations/blob/main/packages/crowdstrike/data_stream/fdr/elasticsearch/ingest_pipeline/default.yml#L1342
https://github.com/elastic/integrations/blob/main/packages/crowdstrike/data_stream/fdr/elasticsearch/ingest_pipeline/default.yml#L1834
https://github.com/elastic/integrations/blob/main/packages/crowdstrike/data_stream/fdr/elasticsearch/ingest_pipeline/default.yml#L1839

crowdstrike.FirstSeen
Customer has suggested this field is mapped to @timestamp. What field do we currently rely on to generate the timestamp? We do have a threat.indicator.first_seen but not a good fit here, as it relates more to IOC's.

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[jamiehynds]

Currently blocked by elastic/kibana#134321

[botelastic]

Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[efd6]

Regarding the timestamp, the logic is to take the first available value from the FDR data in the following list:

1. UTCTimestamp
2. timestamp
3. CreationTimeStamp
4. AgentLocalTime
5. _time

This seems fairly sensible to me, and there will always be an argument that it should be different, no matter what we have, so I'm not sure it should be changed.