[Security Solution][CTI] Investigation Time Enrichment View does not render all fields of Threat Indicator documents

[rylnd]

Kibana version: This looks to have been present since the introduction of this UI in 7.14.

Describe the bug: This UI renders two types of enrichments: those that were added to the alert directly via matching during the indicator rule execution (matched.type: 'indicator_match_rule'), and those that are matched after the alert has been created (matched.type: 'investigation_time'.

Steps to reproduce:

1. Create event and indicator documents to match against. Note: I'm using the same index for both, here, and leveraging event.type to partition the two sets.

   Dev Tools

   PUT logs-ti_test/ { "mappings": { "dynamic": "false", "properties": { "@timestamp": { "type": "date", "format": "strict_date_optional_time" }, "event.type": { "type": "keyword" }, "flattened": { "type": "flattened" }, "source.ip": { "type": "ip" }, "threat.indicator.ip": { "type": "ip" } } } } PUT logs-ti_test/_doc/1 { "@timestamp": "2024-03-25T00:41:41.494Z", "source.ip": "127.0.0.1", "event.type": "not_indicator" } PUT logs-ti_test/_doc/2 { "@timestamp": "2024-03-25T00:41:41.494Z", "source.ip": "127.0.0.2", "event.type": "not_indicator" } PUT logs-ti_test/_doc/3 { "@timestamp": "2024-03-25T00:41:41.494Z", "source.ip": "127.0.0.3", "event.type": "not_indicator" } PUT logs-ti_test/_doc/4 { "@timestamp": "2024-03-25T00:41:41.494Z", "event.type": "indicator", "threat.indicator.ip": "127.0.0.1" } PUT logs-ti_test/_doc/5 { "@timestamp": "2024-03-25T00:42:41.494Z", "event.type": "indicator", "threat.indicator.ip": "127.0.0.1", "unmapped_object": { "foo": "bar" } } PUT logs-ti_test/_doc/6 { "@timestamp": "2024-03-25T00:42:41.494Z", "event.type": "indicator", "threat.indicator.ip": "127.0.0.1", "unmapped_array": [{ "foo": "bar" }] } PUT logs-ti_test/_doc/7 { "@timestamp": "2024-03-25T00:42:41.494Z", "event.type": "indicator", "threat.indicator.ip": "127.0.0.2", "flattened": { "foo": "bar" } } PUT logs-ti_test/_doc/8 { "@timestamp": "2024-03-25T00:43:41.494Z", "event.type": "indicator", "threat.indicator.ip": "127.0.0.3", "flattened": [ { "foo": "bar" }, { "foo": "baz" } ] }

2. Create a rule to generate alerts from the non-indicator documents above. The default index pattern should match; a query rule with event.type: not_indicator should be sufficient (with a long enough lookback). At this point, you should have alerts with source.ips of 127.0.0.1 -3, and indicators matching each

3. For each alert with a unique value of source.ip, open the details flyout and navigate to Insights -> Threat Intelligence, and observe:

   • 127.0.0.1 matches multiple indicator documents, which rendere as expected
   • 127.0.0.2 matches an indicator document with a flattened field containing an object, which causes an error
   • 127.0.0.2 matches an indicator document with a flattened field containing an array of objects, which causes an error

Expected behavior: All fields are rendered, or there is appropriate messaging to convey that not all fields are rendered.

Screenshots (if relevant): Screenshot of 127.0.0.1 alert rendered with both object and array-of-object fields:

Errors in browser console (if relevant): https://react.dev/errors/31?invariant=31&args%5B%5D=object%20with%20keys%20%7BSourcesCount%2C%20SightingsCount%2C%20CriticalityLabel%2C%20Rule%2C%20EvidenceString%2C%20Sources%2C%20Timestamp%2C%20Name%2C%20MitigationString%2C%20Criticality%7D

[yctercero]

Hey @rylnd ! Are you actively working on this one?

[rylnd]

There's an open PR that addresses the described bug; I think we just need to decide whether to merge it, and where to backport.