[Security Solution] "Filter In", "Filter Out" and "Show top values" are not working for alerts table Data under cases.

[ghost]

Describe the bug:
"Filter In", "Filter Out" and "Show top values" are not working for alerts table Data under cases.

Build Details:

Version:8.3.0 BC4
Commit:875ea184462f73a04410981ac9eaf799db28b4f0
Build:53413

Preconditions

1. Elasticsearch should be up and running
2. Kibana should be up and running
3. Alerts should be present on environment.

Steps to Reproduce

1. Navigate to Security--> Alerts
2. Select multiple alerts.
3. Attach selected alerts to a case.
4. Navigate to Security--> Cases.
5. Open the Case and click on Alerts tab.
6. Use "Filter In", "Filter Out" and "Show top values" on alerts table data.

Expected Result
"Filter In", "Filter Out" and "Show top values" should work on alerts table data.

Actual Result
"Filter In", "Filter Out" and "Show top values" is not working on alerts table data.

Screen Records

Cases.-.Kibana.-.Google.Chrome.2022-06-15.15-44-03.mp4

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/response-ops-cases (Feature:Cases)

[cnasikas]

@kqualters-elastic Does it make sense to filter in the alerts table inside cases?

[kqualters-elastic]

if we add the query bar maybe, without it, no imo.

[cnasikas]

Thanks! There is no plan to add a query bar in Cases at the moment. I think this is related to how the security solution registers the alerts' table configuration. Who should I assign for?

cc @XavierM

[cnasikas]

@michaelolo24 Any update on this?

[michaelolo24]

@cnasikas sorry was out on vacation when this came in, but I pinged @XavierM about it

[XavierM]

I will remove this filtering from the cell actions

[abo1787]

Removal of this functionality has negatively impacted the ability to filter inside the security > explore > hosts panel (the CMD integration that was brought into Elastic). Also it notes this ticket is still open, how did this function (removal of the filtering) get merged into a mainline branch that's impacting my 8.7.1 deployment if this ticket is still open?

We rely on this ability to filter our session data. We have a query bar on that application. It seems this was removed from the wrong section, or it has some negative regression on another section it shouldn't have ... Either way as an enterprise customer seeing an open ticket noted as the breaking change that removed functionality in an elastic cloud deployment running the latest version of code looks like a major security hole. Are you deploying non production versions to your cloud deploy base, or do you have customers running on improperly vetted code? At a minimum I'd expect the ticket to be closed on our side (and merged on your side though I don't think I could see that) before it gets deployed to a customer.

Please add this capability back in, and remove it only from the alerts panel where it wasn't working. It was working properly where we needed it and can no longer quickly filter without building a filter in the query bar.

[machadoum]

Hi @abo1787,

Thank you for reporting this issue!

I can reproduce that "Filter In" and "Filter Out" actions are absent from Hosts/Session and Alerts/Cases on 8.7.1.

The bug you found isn't related to this ticket. The ticket is still open because we haven't merged the branch yet. Another change caused this regression bug.

I apologize for any inconvenience you may have faced and assure you that we are working to resolve it.

---

Update: The bug shall get fixed on version 8.8

[cnasikas]

Hi @abo1787,

As @machadoum said, this issue is unrelated to your problem. It is still open because we did not fix it. What you encountered is a bug introduced in 8.7. I can ensure you that there is no way to have code from the main branch (non-production) to cloud deployments. Sorry for the inconvenience.

[elasticmachine]

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

[semd]

I don't have the capacity to take it, but an easy fix would be to conditionally add FILTER as disabledActionTypes at:

kibana/x-pack/plugins/security_solution/public/detections/hooks/trigger_actions_alert_table/use_cell_actions.tsx

Lines 79 to 88 in 87f0c8e

	return {
	triggerId: SecurityCellActionsTrigger.DEFAULT,
	fields,
	metadata: {
	// cell actions scope
	scopeId: tableId,
	},
	dataGridRef,
	};

like this:

      const disabledActionTypes =
        tableId === TableId.alertsOnCasePage ? [SecurityCellActionType.FILTER] : undefined;

      return {
        triggerId: SecurityCellActionsTrigger.DEFAULT,
        fields,
        metadata: {
          // cell actions scope
          scopeId: tableId,
        },
        dataGridRef,
        disabledActionTypes,
      };

This should hide filter actions in the Cases alerts table

[abo1787]

Thank you for confirming that the two issues are not related. I'll follow up with my support ticket that landed me here and see if he can link me to the bug in question that caused my actual problem.

[ghost]

Hi Team,

we have validated this issue on main and found the issue to be fixed. Filter in and Filter out action are now not showing and show top is now started working.

Observations:

However, in the show top n modal incorrect count Showing:115 alerts is showing ❌

video1573097995.mp4

thanks!!

c.c @MadameSheema

[machadoum]

Hey Karanbir, thank you for reviewing it. Can you tell me why it's wrong and what the expected behavior is?

At the moment, this component displays all alerts in the global time range. If we want it to only display alerts within a case, we'll need to submit a feature request.

[ghost]

ok @machadoum thanks for clearing the time range for which seeing the alert count on show top modal.

We can close this ticket as this is fixed ✔️

thanks !!