[AI4DSOC] Fix issue with filtering by integrations

[PhilippeOberti]

Summary

This PR fixes an issue with the logic implemented in this previous PR:
In the AI for SOC effort, each integration is bundled with a single rule. This means that deselecting a source from the Source filter button is equivalent to adding a filter to the search bar to exclude all alerts with the kibana.alert.rule.name property having the value of that integration.

The problem with the previous logic above is the value in the kibana.alert.rule.name field can be overridden (see `Rule name override here). Therefore filtering alerts by this value does not guarantee that all the alerts generated by the rule will be correctly filtered out.

The new logic uses the rule.id instead of the rule.name, which we then use to filter using the signal.rule.id field instead of kibana.alert.rule.name

Example:

There are following 2 integrations installed:

[
  {
    id: 'splunk',
    name: 'splunk',
    status: installationStatuses.Installed,
    title: 'Splunk',
    version: '',
  },
  {
    id: 'google_secops',
    name: 'google_secops',
    status: installationStatuses.Installed,
    title: 'Google SecOps',
    version: '',
  },
]

This means that - in theory - there are the following 2 rules installed and running:

[
  {
    related_integrations: [{ package: 'splunk' }],
    id: 'splunk_rule_id',
  },
  {
    related_integrations: [{ package: 'google_secops' }],
    id: 'google_secops_rule_id',
  },
]

In this case, the Sources button would show 2 entries, as follow:

[
  {
    checked: 'on',
    key: 'splunk_rule_id',
    label: 'Splunk',
  },
  {
    checked: 'on',
    key: 'google_secops_rule_id',
    label: 'Splunk',
  },
]

This PR also fixes a small miss in the prior PR that implemented the KPI section, where I had forgotten to pass the KQL filters to the charts.

Before

Screen.Recording.2025-04-01.at.1.30.03.PM.mov

After

Screen.Recording.2025-04-01.at.1.31.07.PM.mov

How to test

This needs to be ran in Serverless:

• yarn es serverless --projectType security
• yarn serverless-security --no-base-path

You also need to enable the AI for SOC tier, by adding the following to your serverless.security.dev.yaml file:

xpack.securitySolutionServerless.productTypes:
  [
    { product_line: 'ai_soc', product_tier: 'search_ai_lake' },
  ]

Use one of these Serverless users:

• platform_engineer
• endpoint_operations_analyst
• endpoint_policy_manager
• admin
• system_indices_superuser

Notes

• generate data: yarn test:generate:serverless-dev
• create 4 catch all rules, each with a name of a AI for SOC integration (google_secops, microsoft_sentinel,, sentinel_one and crowdstrike)
• change this line to installedPackages: availablePackages to force having some packages installed
• change this line to r.name === p.name to make sure there will be matches between integrations and rules

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

https://github.com/elastic/security-team/issues/11956

[elasticmachine]

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

[christineweng]

Code changes LGTM.

Do you know the difference between rule.id and rule_id? I'm seeing different values in my local

[PhilippeOberti]

Code changes LGTM.

Do you know the difference between rule.id and rule_id? I'm seeing different values in my local

I think this is because a rule object has both an id field and a rule_id field. After doing some checks the one I need is id. Not sure what the rule_id actually is 😆

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 0a30ea9

Metrics [docs]

Async chunks

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

id	before	after	diff
securitySolution	8.9MB	8.9MB	+92.0B

History

• 💔 Build #290299 failed 3e3e497
• 💔 Build #290066 failed 1cee06c
• 💛 Build #289215 was flaky 6ce0b4f
• 💚 Build #288846 succeeded d403ab1