search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.71k stars 8.13k forks source link

[Security Solution] Disable filter cellActions for unmapped fields on Alerts table #154714

Open semd opened 1 year ago

semd commented 1 year ago

Summary

bug: https://github.com/elastic/sdh-security-team/issues/549 epic: https://github.com/elastic/kibana/issues/144943

Filter actions are not working properly on the Alerts page for fields that are not mapped in the alert's index.

This problem was not been introduced by the cell-actions package, it was carried with the migration from SecuritySolution hoverActions. A fix for the cell-actions package would be the following.

Fix description

~This fix will need to be done after we adopt FieldSpec (https://github.com/elastic/kibana/issues/150347#issuecomment-1422447838) for the field type of the actions, we'll be able to check the isMapped flag in the action's isCompatible function to decide if the FilterIn/Out actions should be displayed or hide.~

~To define the value of the isMapped prop we'll have to do a lookup of the indexes array of the field in the browserFields data, and check if the alert's index is present.~

Update The bug happens when a field is not mapped on the alert's index but it is mapped on another index in the security data view. The sorcerer API returns that the field is mapped but fails when we search on the Alerts index.

elasticmachine commented 1 year ago

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

machadoum commented 1 year ago

auto-closed by mistake

machadoum commented 1 year ago

The team discussed this bug, and we think that it isn't a CellActions bug but a data view/sorcerer + Alerts table bug.

The bug happens when a field is not mapped on the alert's index but it is mapped on another index in the security data view. The sorcerer API returns that the field is mapped but fails when we search on the Alerts index.

It happens because the alerts table uses a security data view but only searches on the alert's index. So the root problem is how Dataview is configured for the Alerts table.

This bug isn't something exclusive to CellActions. For example, if the user tries to sort a column that is not mapped on the Alert index, an error happens, and after a refresh, the alerts table doesn't show up anymore.

https://github.com/elastic/kibana/assets/1490444/e0d7c4a0-5bbb-4135-a50b-46a5d79ca83b

stefnestor commented 1 year ago

Related: https://github.com/elastic/kibana/issues/136351 , https://github.com/elastic/kibana/issues/166168 , https://github.com/elastic/kibana/issues/144943

111andre111 commented 9 months ago

Probably another related issue: https://github.com/elastic/kibana/issues/170167 https://github.com/elastic/kibana/issues/171059

111andre111 commented 9 months ago

related: https://github.com/elastic/kibana/issues/171059

elasticmachine commented 6 months ago

Pinging @elastic/security-detection-engine (Team:Detection Engine)

lgestc commented 4 months ago

After looking at this for a few days, I an conviced that the data view selected in the sourcerer does not impact the pattern list used to retrieve the browser fields for the alerts table.

New data view created image

After forcing the data view to be the new one in security solution codebase, I am still getting over 2k fields: image

Regardless of the new dataViewId passed in here: /home/luke/projects/kibana/src/plugins/data_views/common/data_views/data_views.ts ->

the title (aka. the index pattern string) here: image

remains the same, which results in all the security solution fields rendered as compatible with the alerts table view.

After the pattern is explitly set to .alerts-security.alerts-default, the field count looks correctly: image

Draft pr where I set the pattern explicitly when the dataViewId is alerts: https://github.com/elastic/kibana/pull/181540

lgestc commented 4 months ago

on hold until the we refactor data view selection