Filter endpoint list exceptions in DE logic by nkhristinin · Pull Request #233289 · elastic/kibana

nkhristinin · 2025-08-28T09:59:49Z

Summary

Related: https://github.com/elastic/security-team/issues/13777
https://github.com/elastic/security-team/issues/14573

We are filtering endpoint exceptions from DE execution logic.

Update tests so that endpoint exceptions don't affect alerts generated right now (they should be excluded on the endpoint)

How to test:

Enable FF - endpointExceptionsMovedUnderManagement

Install elastic defender (you can click add elastic defend later at the end) - http://localhost:5601/app/security/administration/endpoints

Now you should have Endpoint Security (Elastic Defend) installed.
Let's create 2 events. You can manipulate user.name to check how exceptions works later.

POST logs-endpoint.alerts-1/_doc
{
  "event.kind": "alert",
  "event.module": "endpoint",
  "event.ingested": "2025-09-09T08:39:55.101Z",
  "@timestamp": "2025-09-09T08:39:55.101Z",
  "user.name": "hello1",
  "host": {
    "os": {
      "name": "windows",           
      "type": "windows"            
    }
  }
}

POST logs-endpoint.alerts-1/_doc
{
  "event.kind": "alert",
  "event.module": "endpoint",
  "event.ingested": "2025-09-09T08:39:55.101Z",
  "@timestamp": "2025-09-09T08:39:55.101Z",
  "user.name": "hello2",
  "host": {
    "os": {
      "name": "windows",           
      "type": "windows"            
    }
  }
}

For the rule, change the interval/schedule if you need to create alerts more easily.
Add endpoint exceptions (windows, and user.name - some value, for example hello1).

--

With FF enabled, we should see 2 alerts generated for user.name hello1 and hello2.

With FF disabled, the exception should work on the DE side, so you only see 1 alert for hello2.

nkhristinin · 2025-08-28T09:59:56Z

/ci

nkhristinin · 2025-09-08T08:25:20Z

/ci

nkhristinin · 2025-09-08T09:58:51Z

/ci

nkhristinin · 2025-09-08T13:57:49Z

@elasticmachine merge upstream

nkhristinin · 2025-09-10T07:51:34Z

@elasticmachine merge upstream

nkhristinin · 2025-09-15T13:23:12Z

@elasticmachine merge upstream

denar50

I tested it locally and it works as expected. LGTM!

denar50 · 2025-09-16T08:37:41Z

+        )
+      : lists;
+
+    if (filteredLists.length > 0) {


nit: you can do an early return here so the try/catch block is not nested inside the if. It makes the code easier to read.

if (filteredLists.length === 0) { return []; } try { ...

nkhristinin · 2025-09-18T13:56:49Z

@elasticmachine merge upstream

nkhristinin · 2025-10-08T14:51:07Z

@elasticmachine merge upstream

kibanamachine · 2025-10-08T17:02:33Z

Starting backport for target branches: 9.2

https://github.com/elastic/kibana/actions/runs/18352264525

elasticmachine · 2025-10-08T17:03:34Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: d8ec368

Failed CI Steps

FTR Configs #41

Test Failures

[job] [logs] FTR Configs #41 / discover/group5 discover no data adds a new data view when no data views

Metrics [docs]

✅ unchanged

History

💔 Build #347707 failed 31dda83
💔 Build #345658 failed 229749c
💔 Build #343808 failed a171a87
💔 Build #339368 failed 0c05b50
💚 Build #337663 succeeded 3784311
💔 Build #337362 failed 398abef

@timestamp

## Summary Related: elastic/security-team#13777 We are filtering endpoint exceptions from DE execution logic. Update tests so that endpoint exceptions don't affect alerts generated right now (they should be excluded on the endpoint) ### How to test: Enable FF - `endpointExceptionsMovedUnderManagement` 1. Install elastic defender (you can click add elastic defend later at the end) - http://localhost:5601/app/security/administration/endpoints <img width="1325" height="650" alt="Screenshot 2025-09-09 at 10 38 13" src="https://github.com/user-attachments/assets/1b642cc8-ec4c-471a-bcd7-5b0086fc2f90" /> 2. Now you should have `Endpoint Security (Elastic Defend)` installed. 3. Let's create 2 events. You can manipulate user.name to check how exceptions works later. ``` POST logs-endpoint.alerts-1/_doc { "event.kind": "alert", "event.module": "endpoint", "event.ingested": "2025-09-09T08:39:55.101Z", "@timestamp": "2025-09-09T08:39:55.101Z", "user.name": "hello1", "host": { "os": { "name": "windows", "type": "windows" } } } POST logs-endpoint.alerts-1/_doc { "event.kind": "alert", "event.module": "endpoint", "event.ingested": "2025-09-09T08:39:55.101Z", "@timestamp": "2025-09-09T08:39:55.101Z", "user.name": "hello2", "host": { "os": { "name": "windows", "type": "windows" } } } ``` 4. For the rule, change the interval/schedule if you need to create alerts more easily. 5. Add endpoint exceptions (windows, and user.name - some value, for example hello1). <img width="1455" height="577" alt="Screenshot 2025-09-09 at 11 13 18" src="https://github.com/user-attachments/assets/ed7e83a2-25bf-4254-8362-5e863ee77e3f" /> -- With FF enabled, we should see 2 alerts generated for `user.name` `hello1` and `hello2`. With FF disabled, the exception should work on the DE side, so you only see 1 alert for `hello2`. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit b1713c3)

kibanamachine · 2025-10-08T17:09:36Z

💚 All backports created successfully

Status	Branch	Result
✅	9.2

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

@timestamp

# Backport This will backport the following commits from `main` to `9.2`: - [Filter endpoint list exceptions in DE logic (#233289)](#233289)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Khristinin Nikita <nikita.khristinin@elastic.co> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

florent-leborgne · 2025-10-14T08:58:03Z

Hi! This PR has a release_note:deprecation label. To make sure that this PR is listed in the right place and with useful information for end users, the PR would also ideally have:

A team or feature label
A ## Release note section in the description that explains the nature of the change

If the change should not be listed in the release notes, please use the release_note:skip label instead.

If this helps, we have a page describing release notes best practices for PRs (Elastic access only)

@timestamp

## Summary Related: elastic/security-team#13777 We are filtering endpoint exceptions from DE execution logic. Update tests so that endpoint exceptions don't affect alerts generated right now (they should be excluded on the endpoint) ### How to test: Enable FF - `endpointExceptionsMovedUnderManagement` 1. Install elastic defender (you can click add elastic defend later at the end) - http://localhost:5601/app/security/administration/endpoints <img width="1325" height="650" alt="Screenshot 2025-09-09 at 10 38 13" src="https://github.com/user-attachments/assets/1b642cc8-ec4c-471a-bcd7-5b0086fc2f90" /> 2. Now you should have `Endpoint Security (Elastic Defend)` installed. 3. Let's create 2 events. You can manipulate user.name to check how exceptions works later. ``` POST logs-endpoint.alerts-1/_doc { "event.kind": "alert", "event.module": "endpoint", "event.ingested": "2025-09-09T08:39:55.101Z", "@timestamp": "2025-09-09T08:39:55.101Z", "user.name": "hello1", "host": { "os": { "name": "windows", "type": "windows" } } } POST logs-endpoint.alerts-1/_doc { "event.kind": "alert", "event.module": "endpoint", "event.ingested": "2025-09-09T08:39:55.101Z", "@timestamp": "2025-09-09T08:39:55.101Z", "user.name": "hello2", "host": { "os": { "name": "windows", "type": "windows" } } } ``` 4. For the rule, change the interval/schedule if you need to create alerts more easily. 5. Add endpoint exceptions (windows, and user.name - some value, for example hello1). <img width="1455" height="577" alt="Screenshot 2025-09-09 at 11 13 18" src="https://github.com/user-attachments/assets/ed7e83a2-25bf-4254-8362-5e863ee77e3f" /> -- With FF enabled, we should see 2 alerts generated for `user.name` `hello1` and `hello2`. With FF disabled, the exception should work on the DE side, so you only see 1 alert for `hello2`. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

@timestamp

## Summary Related: elastic/security-team#13777 We are filtering endpoint exceptions from DE execution logic. Update tests so that endpoint exceptions don't affect alerts generated right now (they should be excluded on the endpoint) ### How to test: Enable FF - `endpointExceptionsMovedUnderManagement` 1. Install elastic defender (you can click add elastic defend later at the end) - http://localhost:5601/app/security/administration/endpoints <img width="1325" height="650" alt="Screenshot 2025-09-09 at 10 38 13" src="https://github.com/user-attachments/assets/1b642cc8-ec4c-471a-bcd7-5b0086fc2f90" /> 2. Now you should have `Endpoint Security (Elastic Defend)` installed. 3. Let's create 2 events. You can manipulate user.name to check how exceptions works later. ``` POST logs-endpoint.alerts-1/_doc { "event.kind": "alert", "event.module": "endpoint", "event.ingested": "2025-09-09T08:39:55.101Z", "@timestamp": "2025-09-09T08:39:55.101Z", "user.name": "hello1", "host": { "os": { "name": "windows", "type": "windows" } } } POST logs-endpoint.alerts-1/_doc { "event.kind": "alert", "event.module": "endpoint", "event.ingested": "2025-09-09T08:39:55.101Z", "@timestamp": "2025-09-09T08:39:55.101Z", "user.name": "hello2", "host": { "os": { "name": "windows", "type": "windows" } } } ``` 4. For the rule, change the interval/schedule if you need to create alerts more easily. 5. Add endpoint exceptions (windows, and user.name - some value, for example hello1). <img width="1455" height="577" alt="Screenshot 2025-09-09 at 11 13 18" src="https://github.com/user-attachments/assets/ed7e83a2-25bf-4254-8362-5e863ee77e3f" /> -- With FF enabled, we should see 2 alerts generated for `user.name` `hello1` and `hello2`. With FF disabled, the exception should work on the DE side, so you only see 1 alert for `hello2`. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

…o add endpoint exceptions to rule execution (#242480) ## Summary Conditionally render endpoint exceptions UI checkbox under "About Rule" advanced settings. UI change related to: #233289

…o add endpoint exceptions to rule execution (elastic#242480) ## Summary Conditionally render endpoint exceptions UI checkbox under "About Rule" advanced settings. UI change related to: elastic#233289 (cherry picked from commit 98685d9)

…o add endpoint exceptions to rule execution (elastic#242480) ## Summary Conditionally render endpoint exceptions UI checkbox under "About Rule" advanced settings. UI change related to: elastic#233289

elasticmachine · 2026-01-09T17:24:59Z

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

Previously, rule exception logic allowed for Endpoint Exceptions to be applied to rules, and thus the associated list needed to be present in order for our exception retrieval to succeed. However, with the effort of elastic/security-team#14573, and particularly elastic#233289, we no longer apply endpoint exceptions, and so these calls are no longer necessary. (In fact, these calls are now preventing Rules-only users from e.g. previewing rules, as that call requires privileges they do not have, causing errors and a short-circuiting). The one exception to the above may be if a rule references an endpoint list, and the FF is not yet removed (meaning we still search for endpoint exceptions). However, I will add a regression test for that case.

…icy Endpoint Exceptions (#259598) ## Summary This PR adds an opt-in mechanism that allows using the so far global-only Endpoint Exceptions on a per-policy basis. > [!note] > Hidden behind feature flag (as part of the Endpoint exception move effort): > ``` > xpack.securitySolution.enableExperimental: > - endpointExceptionsMovedUnderManagement > ``` ### Behavior in short - new deployments are automatically opted in. they also won't see the 'Endpoint exceptions moved' and 'Endpoint exceptions not evaluated on rules anymore' callouts (from #258556). - upgraded environments will see a new callout on the Endpoint exceptions page that suggests to enable per-policy behavior - superuser role (ESS) or admin role (serverless) users are able to perform the opt-in - other users will see a message to contact their administrators - after manually opting in - Endpoint exceptions can be assigned to package policies, like other endpoint artifacts - but, they won't be evaluated during rule execution anymore (see #233289) - and they cannot be added to detection rules anymore (see #242480) ### Data Opt-in status is stored in the `ReferenceDataClient`, and it's defaulted during plugin start phase either to: - `{ status: false }`, in case endpoint exception list exists (i.e. upgrade, it's created every time), - `{ status: true, reason: 'newDeployment' }`, in case the list does not exist. ### API 2 new API endpoints are added: - `GET /internal/api/endpoint/endpoint_exceptions_per_policy_opt_in` to receive the opt-in status on the UI, - `POST /internal/api/endpoint/endpoint_exceptions_per_policy_opt_in` to perform the opt-in, that sets the status to `{ status: true, reason: 'userOptedIn' }` ### UI #### empty page is... empty <img width="400" height="793" alt="image" src="https://github.com/user-attachments/assets/e7b72ab9-2a42-49ca-b2e9-2447e3ff9dd3" /> #### callout for non-superusers <img width="1280" height="516" alt="image" src="https://github.com/user-attachments/assets/f88a04a6-b8bb-46be-8f5f-ece5f1d89cf2" /> #### callout for superusers / admins <img width="1215" height="554" alt="image" src="https://github.com/user-attachments/assets/e2552d27-ac9d-4dfe-84da-48012fdf57fc" /> #### menu action for superusers / admins in case the callout is dismissed. although, it will come up again as it's only dismissed for the session. <img width="335" height="204" alt="image" src="https://github.com/user-attachments/assets/5d7a23e6-2428-4f8f-b941-0f97e8bd7750" /> #### modal <img width="925" height="564" alt="image" src="https://github.com/user-attachments/assets/0cbc4573-b052-4e1f-82c5-13298532f7fe" /> ### recording #### opt-in process and endpoint exceptions pages https://github.com/user-attachments/assets/de8204bd-72d2-4a99-b51c-b86771c577c3 ### hiding stuff behind opt-in status - endpoint exception related per-policy activities are available only after opt-in, like - per-policy assignment in the form, - assigning exceptions to policies in the Policy details page Endpoint exceptions tab, - `ManifestManager` also uses per-policy EE after opt-in only. - 'endpoint exceptions moved' informative callouts are shown without opting in (due to the FF enabled), or after _manual_ opt-in (i.e. are hidden on new deployments) - see the details in the previous PR: #258556 - 'endpoint exceptions are not evaluated on rules' informative callouts are shown only after _manually_ opting in (i.e. it needs opt-in, but isn't shown on new deployments) - see the details in the previous PR: #258556 ## Testing To test this, - either add some data (endpoint exceptions), and then turn on the feature flag `xpack.securitySolution.enableExperimental.endpointExceptionsMovedUnderManagement`, to simulate an 'upgrade' scenario, - or start with the feature flag turned on, to simulate a 'new deployment' scenario. ### Reading opt-in status dev console: ``` GET .kibana_security_solution/_doc/security:reference-data:ENDPOINT-EXCEPTIONS-PER-POLICY-OPT-IN-STATUS ``` ### Deleting opt-in status you can also delete the opt-in status, so you're back to the 'upgrade' scenario. for this, you need a `system_indices_superuser`, here's a quick console command to create one: ``` POST kbn://internal/security/users/testuser { "password": "changeme", "username": "testuser", "full_name": "", "email": "", "roles": [ "system_indices_superuser", "superuser" ] } ``` and then delete like this: ``` DELETE .kibana_security_solution/_doc/security:reference-data:ENDPOINT-EXCEPTIONS-PER-POLICY-OPT-IN-STATUS ``` ## todo docs ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

…icy Endpoint Exceptions (elastic#259598) ## Summary This PR adds an opt-in mechanism that allows using the so far global-only Endpoint Exceptions on a per-policy basis. > [!note] > Hidden behind feature flag (as part of the Endpoint exception move effort): > ``` > xpack.securitySolution.enableExperimental: > - endpointExceptionsMovedUnderManagement > ``` ### Behavior in short - new deployments are automatically opted in. they also won't see the 'Endpoint exceptions moved' and 'Endpoint exceptions not evaluated on rules anymore' callouts (from elastic#258556). - upgraded environments will see a new callout on the Endpoint exceptions page that suggests to enable per-policy behavior - superuser role (ESS) or admin role (serverless) users are able to perform the opt-in - other users will see a message to contact their administrators - after manually opting in - Endpoint exceptions can be assigned to package policies, like other endpoint artifacts - but, they won't be evaluated during rule execution anymore (see elastic#233289) - and they cannot be added to detection rules anymore (see elastic#242480) ### Data Opt-in status is stored in the `ReferenceDataClient`, and it's defaulted during plugin start phase either to: - `{ status: false }`, in case endpoint exception list exists (i.e. upgrade, it's created every time), - `{ status: true, reason: 'newDeployment' }`, in case the list does not exist. ### API 2 new API endpoints are added: - `GET /internal/api/endpoint/endpoint_exceptions_per_policy_opt_in` to receive the opt-in status on the UI, - `POST /internal/api/endpoint/endpoint_exceptions_per_policy_opt_in` to perform the opt-in, that sets the status to `{ status: true, reason: 'userOptedIn' }` ### UI #### empty page is... empty <img width="400" height="793" alt="image" src="https://github.com/user-attachments/assets/e7b72ab9-2a42-49ca-b2e9-2447e3ff9dd3" /> #### callout for non-superusers <img width="1280" height="516" alt="image" src="https://github.com/user-attachments/assets/f88a04a6-b8bb-46be-8f5f-ece5f1d89cf2" /> #### callout for superusers / admins <img width="1215" height="554" alt="image" src="https://github.com/user-attachments/assets/e2552d27-ac9d-4dfe-84da-48012fdf57fc" /> #### menu action for superusers / admins in case the callout is dismissed. although, it will come up again as it's only dismissed for the session. <img width="335" height="204" alt="image" src="https://github.com/user-attachments/assets/5d7a23e6-2428-4f8f-b941-0f97e8bd7750" /> #### modal <img width="925" height="564" alt="image" src="https://github.com/user-attachments/assets/0cbc4573-b052-4e1f-82c5-13298532f7fe" /> ### recording #### opt-in process and endpoint exceptions pages https://github.com/user-attachments/assets/de8204bd-72d2-4a99-b51c-b86771c577c3 ### hiding stuff behind opt-in status - endpoint exception related per-policy activities are available only after opt-in, like - per-policy assignment in the form, - assigning exceptions to policies in the Policy details page Endpoint exceptions tab, - `ManifestManager` also uses per-policy EE after opt-in only. - 'endpoint exceptions moved' informative callouts are shown without opting in (due to the FF enabled), or after _manual_ opt-in (i.e. are hidden on new deployments) - see the details in the previous PR: elastic#258556 - 'endpoint exceptions are not evaluated on rules' informative callouts are shown only after _manually_ opting in (i.e. it needs opt-in, but isn't shown on new deployments) - see the details in the previous PR: elastic#258556 ## Testing To test this, - either add some data (endpoint exceptions), and then turn on the feature flag `xpack.securitySolution.enableExperimental.endpointExceptionsMovedUnderManagement`, to simulate an 'upgrade' scenario, - or start with the feature flag turned on, to simulate a 'new deployment' scenario. ### Reading opt-in status dev console: ``` GET .kibana_security_solution/_doc/security:reference-data:ENDPOINT-EXCEPTIONS-PER-POLICY-OPT-IN-STATUS ``` ### Deleting opt-in status you can also delete the opt-in status, so you're back to the 'upgrade' scenario. for this, you need a `system_indices_superuser`, here's a quick console command to create one: ``` POST kbn://internal/security/users/testuser { "password": "changeme", "username": "testuser", "full_name": "", "email": "", "roles": [ "system_indices_superuser", "superuser" ] } ``` and then delete like this: ``` DELETE .kibana_security_solution/_doc/security:reference-data:ENDPOINT-EXCEPTIONS-PER-POLICY-OPT-IN-STATUS ``` ## todo docs ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

…ated routes (#258266) ## Summary This PR removes two calls to `createEndpointList()` from rule-related code paths. [PR #233289](#233289) removed the use of endpoint exceptions in rules, so ensuring the endpoint list exists in these rule routes is no longer required. Dropping these calls fixes a 9.3 issue where users with **only** the Rules Kibana feature could not preview rules, because the routes were invoking `createEndpointList()`, which depended on list/exception permissions those users do not have. The problem was first seen on the Alerts RBAC branch but affects current 9.3 behavior. ### Expected behavior for rules that reference an endpoint exception list - **Until the feature flag is enabled/removed:** Rules keep using any associated endpoint exception list when the `endpointExceptionsMovedUnderManagement` feature flag is off. No change to that behavior. - **When the user cannot read the endpoint exception list:** Endpoint exceptions are ignored (no error). Rule creation and preview succeed; only endpoint exception list items are skipped for that execution. A new integration test under `create_rules` covers this: a user with only the Rules feature can create and preview a rule that references the endpoint exception list, and the preview completes successfully with no errors while endpoint exceptions are ignored. --- ## How to Review 1. **Feature flag and execution:** Ensure rule execution and `getExceptions` still respect `endpointExceptionsMovedUnderManagement` (endpoint lists filtered out when the flag is on) and that missing read permission for the endpoint list results in endpoint exceptions being ignored, not in failures. 1. **New integration test:** Run the new test that uses a role with only the Rules feature (e.g. `rulesAllPreviewIndexRole`), creates a rule that references the endpoint exception list, and runs a rule preview. It should pass and assert that the preview returns no errors (validating that endpoint exceptions are ignored when the user cannot read the endpoint list). 1. **Regression:** Run the existing detections/rule creation and prebuilt-rule installation tests to confirm no regressions from removing `createEndpointList()`. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…ated routes (elastic#258266) ## Summary This PR removes two calls to `createEndpointList()` from rule-related code paths. [PR elastic#233289](elastic#233289) removed the use of endpoint exceptions in rules, so ensuring the endpoint list exists in these rule routes is no longer required. Dropping these calls fixes a 9.3 issue where users with **only** the Rules Kibana feature could not preview rules, because the routes were invoking `createEndpointList()`, which depended on list/exception permissions those users do not have. The problem was first seen on the Alerts RBAC branch but affects current 9.3 behavior. ### Expected behavior for rules that reference an endpoint exception list - **Until the feature flag is enabled/removed:** Rules keep using any associated endpoint exception list when the `endpointExceptionsMovedUnderManagement` feature flag is off. No change to that behavior. - **When the user cannot read the endpoint exception list:** Endpoint exceptions are ignored (no error). Rule creation and preview succeed; only endpoint exception list items are skipped for that execution. A new integration test under `create_rules` covers this: a user with only the Rules feature can create and preview a rule that references the endpoint exception list, and the preview completes successfully with no errors while endpoint exceptions are ignored. --- ## How to Review 1. **Feature flag and execution:** Ensure rule execution and `getExceptions` still respect `endpointExceptionsMovedUnderManagement` (endpoint lists filtered out when the flag is on) and that missing read permission for the endpoint list results in endpoint exceptions being ignored, not in failures. 1. **New integration test:** Run the new test that uses a role with only the Rules feature (e.g. `rulesAllPreviewIndexRole`), creates a rule that references the endpoint exception list, and runs a rule preview. It should pass and assert that the preview returns no errors (validating that endpoint exceptions are ignored when the user cannot read the endpoint list). 1. **Regression:** Run the existing detections/rule creation and prebuilt-rule installation tests to confirm no regressions from removing `createEndpointList()`. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit f912fdc) # Conflicts: # x-pack/solutions/security/plugins/security_solution/server/lib/detection_engine/rule_management/api/rules/create_rule/route.ts # x-pack/solutions/security/test/security_solution_api_integration/test_suites/detections_response/utils/auth/roles.ts

…le-related routes (#258266) (#261176) # Backport This will backport the following commits from `main` to `9.3`: - [[Detection Engine] Remove Endpoint List bootstrap calls from Rule-related routes (#258266)](#258266)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Filter endpoint list excpetions

077eca6

nkhristinin added 2 commits September 8, 2025 10:19

Updatet tests

55f8902

fix unit tests

95d0251

fix types

d74b493

fix type

ac0196c

nkhristinin changed the title ~~Filter endpoint list excpetions~~ Filter endpoint list exceptions in DE logic Sep 8, 2025

nkhristinin marked this pull request as ready for review September 8, 2025 13:57

nkhristinin requested a review from a team as a code owner September 8, 2025 13:57

nkhristinin requested a review from denar50 September 8, 2025 13:57

Merge branch 'main' into exceptions-remove-de

2b4f64e

nkhristinin added release_note:deprecation release_note:skip Skip the PR/issue when compiling release notes backport:version Backport to applied version labels v9.2.0 and removed release_note:skip Skip the PR/issue when compiling release notes labels Sep 8, 2025

nkhristinin marked this pull request as draft September 8, 2025 15:09

Add feature flag

7e11932

nkhristinin marked this pull request as ready for review September 9, 2025 09:18

nkhristinin requested a review from a team as a code owner September 9, 2025 09:18

change params

398abef

Merge branch 'main' into exceptions-remove-de

3784311

Merge branch 'main' into exceptions-remove-de

0c05b50

denar50 approved these changes Sep 16, 2025

View reviewed changes

Merge branch 'main' into exceptions-remove-de

d8ec368

nkhristinin merged commit b1713c3 into elastic:main Oct 8, 2025
12 checks passed

kibanamachine added the v9.3.0 label Oct 8, 2025

kibanamachine mentioned this pull request Oct 8, 2025

[9.2] Filter endpoint list exceptions in DE logic (#233289) #238111

Merged

dhurley14 mentioned this pull request Nov 12, 2025

[Security Solution] [Detection Engine] Conditionally hides checkbox to add endpoint exceptions to rule execution #242480

Merged

1 task

florent-leborgne added the Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. label Jan 9, 2026

yctercero added release_note:skip Skip the PR/issue when compiling release notes and removed release_note:deprecation labels Mar 3, 2026

rylnd mentioned this pull request Mar 18, 2026

[Detection Engine] Remove Endpoint List bootstrap calls from Rule-related routes #258266

Merged

4 tasks

gergoabraham mentioned this pull request Mar 27, 2026

[EDR Workflows][Endpoint Exception move] Opt-in mechanism for per-policy Endpoint Exceptions #259598

Merged

3 tasks

Conversation

nkhristinin commented Aug 28, 2025 • edited by approksiu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

How to test:

Uh oh!

nkhristinin commented Aug 28, 2025

Uh oh!

nkhristinin commented Sep 8, 2025

Uh oh!

nkhristinin commented Sep 8, 2025

Uh oh!

nkhristinin commented Sep 8, 2025

Uh oh!

nkhristinin commented Sep 10, 2025

Uh oh!

nkhristinin commented Sep 15, 2025

Uh oh!

denar50 left a comment

Choose a reason for hiding this comment

Uh oh!

denar50 Sep 16, 2025

Choose a reason for hiding this comment

Uh oh!

nkhristinin commented Sep 18, 2025

Uh oh!

nkhristinin commented Oct 8, 2025

Uh oh!

Uh oh!

kibanamachine commented Oct 8, 2025

Uh oh!

elasticmachine commented Oct 8, 2025

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

History

Uh oh!

kibanamachine commented Oct 8, 2025

💚 All backports created successfully

Questions ?

Uh oh!

florent-leborgne commented Oct 14, 2025

Uh oh!

elasticmachine commented Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

nkhristinin commented Aug 28, 2025 •

edited by approksiu

Loading