Customize Columns for SIEM Signals and External Alerts not persistent?

Hello,

Is there a way to make changes to columns for Signals and External Alerts consistent? Because currently by default (7.6.1) External Alerts colums are always reverted to this:

Which makes no sense.. As:

event.module is irrelevant when event.dataset is shown. observer.name is a field which doesn't even exist (instead of observer.hostname)

Also agent.id is really not useful to show on an already crowded space.

Every time I make changes to the columns and refresh the page, the columns seems to be reset?

Grtz

Willem

Hi @willemdh thanks for the post. You raise several good points here, but the common theme is that you want to be able to customize the column selections shown in the various views and have your changes persist.

Persistent, or "sticky" column customization is a much-requested enhancement, and we are looking to implement that in a future release, possibly storing these settings per-user using local storage. Please let us know if there are other related settings you'd like to see persisted? For example, do you have a default column sort-order you prefer?

Is there a way to make changes to columns for Signals and External Alerts consistent?

This too is common feedback, and we're working towards a more consistent way to present the various kinds of alerts that are relevant to analysts. Today, while consistency is desired, keep in mind that signals and external alerts are different objects, and do have different fields available for display.

event.module is irrelevant when event.dataset is shown.

Fair point when event.dataset is populated with the "module.dataset" convention, but that convention is not strictly required by ECS, so there is sometimes value in having both fields present.

observer.name is a field which doesn't even exist (instead of observer.hostname )

observer.name is a defined ECS field, and would provide context to an analyst about, for example, which instance or a web proxy had produced the external alert, but your point is valid, that observer.hostname may be populated more commonly, and essentially provides similar context.

Also agent.id is really not useful to show on an already crowded space.

Good point - thanks for the feedback.

Hi @Mike_Paquette, As always thanks for the fast and detailed answer.

Correct. The fact that the column selection is (not yet) persistent, imho makes SIEM quite annoying to use. As there are soo many different views on this, if I were Elastic, I would aim high and allow Elastic admins to set a default column selection per space, while also allowing individual users to override the default and further customize to their own needs.

but that convention is not strictly required by ECS

Filebeat event.dataset field's are already using that convention, but Auditbeat, Packetbeat, Heartbeat, Winlogbeat events don't. Why aren't they? Imho, as a major categorization field, which is used in a lot of Elastic's components, this should be the case. If event.dataset always contains the 'module', there would be no / less need to also show eventModule, which would save a lot of column space.

Please let us know if there are other related settings you'd like to see persisted? For example, do you have a default column sort-order you prefer?

Imho at this moment the default sort order should be @timestamp

It should however be very easy to switch to sorting based on event.severity (for External Alerts) or on signal.rule.risk_score for Signals.

Grtz

Willem

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.