[Security Solution] Expandably flyout - Enable expandable flyout for generic events

[christineweng]

Summary

This PR enables the overview tab and left section insights for a generic event. When user to go host or user page and expand details for an event, in addition to table and json tab, they now have access to:

• Overview tab on the right section, which provide description of the event kind or event category (detail logic linked in comment), key insights such as highlighted fields, entities, prevalence and visualization previews (if available)
• Expanded details that includes entities details and prevalence details

Many sections are shared by the alert details flyout, which we are hoping to provide a unified experience when user opens the details flyout.

When overview and expanded sections are enabled

• Ideally event.kind and event.category should be ecs compliant, meaning the field values are of allowed_values within ecs definition.
• If the field is not ecs compliant, and it does not fit the criteria to generate an event renderer, the overview tab and expanded sections are hidden

Variations depending on event kind

There is a variation of the about section depending on event.kind:

• event.kind == 'event'
  • This is the most general and common event document, hence we provide details at the event.category level.
  • The title is also dynamic based on the category type (i.e if event.category is process, the process.name is displayed)
• event.kind != 'event'
  • These are events that not as common/general as event so we are providing description at the event.kind level
  • The title matches the event.kind field
  • event.category is included as a list of categories present for the document

How to test

• Enable feature flag expandableEventFlyoutEnabled
• Generate some event data (the resolver generate data script is sufficient to the test main logic, to get the event renderer to show up, see comment on feeding additional data), alternatively, auditbeat and filebeat also feed event data.
• Go to Explore -> Host -> Events table -> expand event details

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[elasticmachine]

Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations)

[christineweng]

more details on the criteria https://github.com/elastic/security-team/issues/7759

[christineweng]

To test all the event renderer scenarios:

1. Go to Dev Tool
2. Set up an index called event-test and mapping: you can copy and paste the command in add_index.json and click run
3. Add event data - event_test_data_bulk.json contains a bulk upload command that injects 16 events, each has its own event renderer.
4. Go to Discover, create a dataview with the new index
5. Go to Explore page -> Host, select the data view from step 4

• The events are timestamped at 2/6/2024, if you don't see any events, try adjusting the time range or update the date before injecting data in step 3
• event_test_data.json contains the events in json formatting if you want to modify/add one add a time. The _bulk API requires each event to be 1 line.
• To read more about event renderers, go to timeline -> query tab, click on the setting icon
  
  

[PhilippeOberti]

This looks really good! I left a few comments. I feel like the biggest thing we need to iron out is related to UI.
It feels weird that we show the rule name for a signal event, but then show something different for other types...

[PhilippeOberti]

this is getting close, thanks for making all the changes!
I left a few more comments on the code and a UI question

[PhilippeOberti]

thanks for making all the changes @christineweng the code looks awesome!!

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: fa91f70

Failed CI Steps

• Defend Workflows Cypress Tests #3

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	5004	5010	+6

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	11.6MB	13.0MB	⚠️ +1.4MB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	71.9KB	72.0KB	+32.0B

History

• 💔 Build #195011 failed de002ec4069a7a47febbdbec815a4e5a1d0c2484
• 💛 Build #194833 was flaky b991eb324ce9b79cccbaae88450975043d058135
• 💛 Build #194559 was flaky 455e2d91d5ddcec67360148d04ea2187d18398f1
• 💛 Build #193920 was flaky 595df9c
• 💔 Build #193897 failed 663c8b77fbcfba02f086500f198e2f46f09f4251

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @christineweng