[Security Solution] [Timeline] The Alert (kibana.alert.reason) renderer is always enabled in Timeline, even when the Alerts category is disabled

[andrew-goldstein]

[Security Solution] [Timeline] The Alert (kibana.alert.reason) renderer is always enabled in Timeline, even when the Alerts category is disabled

The Alert Renderer is an interactive version of the kibana.alert.reason field. It ensures every alert has a "fallback" row renderer, because some alerts won't be rendered by the more specialized renderers, e.g. netflow, audit, etc.

It's possible to disable all other row renderers in Timeline, but it's not possible to disable the Alert (kibana.alert.reason) renderer.

There is already a (legacy) category named Alerts in Customize Event Renderers modal, shown in the screenshot below:

however the Alert (kibana.alert.reason) renderer is still displayed for alerts, even when the Alerts category is unchecked. The setting does not take effect because the Alerts category does not include the (fallback) (kibana.alert.reason) renderer.

Kibana/Elasticsearch Stack version:

main / v8.15.0

Functional Area (e.g. Endpoint management, timelines, resolver, etc.):

Timeline

Steps to reproduce:

1. Navigate to Security > Alerts
2. Click the Investigate in timeline row-level action for an alert

Expected results

• The alert opened in timeline is displayed with a renderer, per the screenshot below:

3. Click the settings gear to display the Customize Event Renderers modal

4. Click the Disable all button

Expected result

• The alerts category is disabled, per the screenshot below:
  

5. Close the Customize Event Renderers modal

Expected result

• The alert is no longer displayed in Timeline with an alert renderer

Actual result

• The alert is still displayed in Timeline with an alert renderer, per the screenshot below:

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[kqualters-elastic]

@andrew-goldstein actually seems like this was never present in the catalog, only the 'alerts', (not 'alert'), for events of event.kind != signal were toggleable, and this renderer for rule alerts was always on since it was added. We could tie the status to that of the alerts renderer, or have it live separately in the catalog, with own description and all that. Should the catalog mention the 'combineRenderer' behavior and all that if so?

[andrew-goldstein]

@andrew-goldstein actually seems like this was never present in the catalog, only the 'alerts', (not 'alert'), for events of event.kind != signal were toggleable, and this renderer for rule alerts was always on since it was added.

That is correct. Unchecking the existing alerts category in the catalog has no effect, because the existing category never included the newer (kibana.alert.reason) renderer.

We could tie the status to that of the alerts renderer, or have it live separately in the catalog, with own description and all that. Should the catalog mention the 'combineRenderer' behavior and all that if so?

I was thinking users might prefer to only reason about alerts as a single category in the catalog (as it is today). The aim would be to abstract away the implementation details, like 'combineRenderer', as opposed to mentioning them in the catalog.

However, if there are unintended consequences, especially in the form of additional user or code complexity, it's also reasonable to have two entries in the catalog:

1. The existing alerts category
2. A new entry for the alerts renderer

It may not be possible to add a second entry in the catalog without exposing a few more implementation details to the user. I'm wondering if @benironside might be able to help craft the user-facing text in the catalog if that's required.

In summary, if it's possible to abstract away some implementation details and keep things simple for the user by having a single toggle, consider that approach. On the other hand, if there are unintended consequences that add a different type of complexity burden on the user or code, consider having two separate entries in the catalog, with help from the docs folks.