[Security Solution] Bulk update on index pattern for ML rules

[cybersecdiva]

Describe the bug:
ML rules doesn't have index patterns. Users should not be able to modify and update and add index patterns

Kibana/Elasticsearch Stack version:
8.1 BC1

Steps to reproduce:

1. Create a new ML rule

Go to Rules overview and search Ml and select Mltest rules

• In this scenario I have a total of 3 Ml test rules and used ml* to list all ML rules

2. Select the Ml test rules ----> Bulk actions ----> Index patterns ----> Add index patterns

( apm-*-transaction, traces-apm*, auditbeat-*, endgame-*, filebeat-*, logs-*, packetbeat-*, winlogbeat-*)

Note: Behavior was also tested with the selection of a single index pattern, and the same result produced and allowed bulk update on index pattern for ML rule

Current behavior:

Expected behavior:
The selection for modification add/delete index patterns for ML rules should prompt an error message

[elasticmachine]

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

[cybersecdiva]

@MadameSheema FYI

[cybersecdiva]

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

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[vitaliidm]

@yiyangliu9286 , @jethr0null , can you please look at this issue.
We need to come up with solution how to tell user that ML rules can't be edited for index patterns

1. Should we prevent user from proceeding with editing ML rules(like with Elastic ones)? We need to make sure in this case we don't display too many modal windows, like first one for Elastic rules, second for ML rules.
   For this solution there 2 cases:

• User selects ML rules on page. This way we know which are ML and can notify user if needed
• User selects all existing rules. This way we don't know if there are any ML rules, we would need to make HTTP request to determine it(similarly to elastic rule)

2. Or should we partially fail bulk edit for ML rule?
3. Or maybe display message in toast that some of rules were skipped because they are ML?

Or maybe we can combine approaches

[banderror]

Synced with @vitaliidm on the current behavior of the bulk actions endpoint.

So if the user tries to edit (add, remove, overwrite) index patterns of a set of rules, and there is one or a few ML rules among them, the endpoint will silently skip applying this modification to the ML rules. However, in the endpoint response, these ML rules will be represented as successfully updated, which is not true.

The server-side logic is going to be fixed in #124525 in such a way that the endpoint will return an error for every attempt to edit index patterns of an ML rule.

[yiyangliu9286]

Thanks for the update and the proposed solution @vitaliidm @banderror!

I think from the frond-end UI perceptive we'd like to notify users about ML rules cannot be edited (as well as the existing prebuilt rules which also cannot be edited atm), here are 4 scenarios:

• If users select rules which contain prebuilt rules + ML rules + custom rules:

• If users select rules which contain ML rules + custom rules:

• If users select rules which contain prebuilt rules + ML rules (block action):

• If users select rules which contain ML rules (block action):

[vitaliidm]

@yiyangliu9286 , I'm thinking this approach can be too complex to scale

Right now we would have 7 scenarios:

1. Elastic rules
2. ML rules for index patterns
3. Custom
4. Elastic rules + ML
5. Elastic + Custom
6. Custom + ML
7. Elastic + Custom + ML

If there would be yet another one uneditable rule type: we will end up with ~ 12 scenarios and so on and so on.

Plus:

• Modal title will be too large, it would consist more and more data.
• Localization also become difficult to handle, due to a lot of scenarios.
• Maybe we would need to give user some details, for example why ML rule is no getting updated with Index Pattern

Instead, what if would have just common 3 scenarios:

1. No custom rules, action is blocked
   We than display in modal window list with number of failed rules and reason

2. Custom rules + uneditable rules
   We say in title how many rule we can edit.
   And then list of rules that can't be

3. All custom - no modal at all, as before

This way, if there would be another type of not applicable action, we would just add another item in a list.
Without a need to handle multiple crossing scenarios
Here is a rough draft of my proposal

[banderror]

I agree with @vitaliidm - let's keep the title as simple as possible without permutations and combinations, and represent types of rules that can't be edited in the form of a list.

I'd maybe suggest

The action will only be applied to 3 out of 176 rules you've selected
===========

This action can't be applied to the following rules:

- 170 prebuilt Elastic rules (editing prebuilt rules is not supported)
- 3 custom Machine Learning rules (these rules don't have index patterns)

                     Cancel     Edit 3 rules

[banderror]

Okie, so the server-side logic has been fixed in #124525 and will be released in 8.1.0. I think we can work on the UI improvements as part of the 8.2 dev cycle (release in 8.2.0 and maybe 8.1.1+).

[yiyangliu9286]

@yiyangliu9286 , I'm thinking this approach can be too complex to scale

Right now we would have 7 scenarios:

1. Elastic rules
2. ML rules for index patterns
3. Custom
4. Elastic rules + ML
5. Elastic + Custom
6. Custom + ML
7. Elastic + Custom + ML

If there would be yet another one uneditable rule type: we will end up with ~ 12 scenarios and so on and so on.

Plus:

• Modal title will be too large, it would consist more and more data.
• Localization also become difficult to handle, due to a lot of scenarios.
• Maybe we would need to give user some details, for example why ML rule is no getting updated with Index Pattern

Instead, what if would have just common 3 scenarios:

1. No custom rules, action is blocked
   We than display in modal window list with number of failed rules and reason
2. Custom rules + uneditable rules
   We say in title how many rule we can edit.
   And then list of rules that can't be
3. All custom - no modal at all, as before

This way, if there would be another type of not applicable action, we would just add another item in a list. Without a need to handle multiple crossing scenarios Here is a rough draft of my proposal

Hi @vitaliidm and @banderror! Thanks for the suggested path and providing your thoughts on how to improve and better resolve this issue by considering the current and future use cases! I think your proposal would be the most simplified and intuitive way to address this - we wouldn't want to create a lot of complicated use cases to potentially create users confusion, so let's proceed to fix this issue to align your thoughts here.

Let's limit users options for those 3 scenarios you've mentioned above (I think it makes sense to to able to explain to users why those rules aren't editable) Here are the updated designs:

1. No custom rules, action is blocked (explain why those rules cannot be edited for different reasons + rules count, and block users to proceed to the next step):

2. Custom rules + uneditable rules (address the number of Custom rules to be able to edit in the title, and in the paragraph, explain why those rules cannot be edited + rules count):

3. All custom - no modal at all, as before

[cybersecdiva]

@banderror For clarification, will we be providing a fix for this bug in 8.2 to prevent the user from adding ML rules using bulk actions for index patterns and tags?

[banderror]

@cybersecdiva Yup, it's in our checklist for 8.2.
Small correction though: no need for preventing editing tags of ML rules, only index patterns.

[banderror]

Just an update that the team thinks that we should address #125512 before fixing the remainder of this bug. I'll push it to the 8.4 scope.

[vitaliidm]

Hey @yiyangliu9286
I also added a default option if any error happens during the check, it will be displayed as such

[Rules number[ rules can't be edited due to error: [Error message goes here]

Please, let me know if you are fine with this implementation

[yiyangliu9286]

Hey @yiyangliu9286 I also added a default option if any error happens during the check, it will be displayed as such

[Rules number[ rules can't be edited due to error: [Error message goes here]

Please, let me know if you are fine with this implementation

Thanks for showing this @vitaliidm! This looks good to me. The only thing I'd say is to make the format of the two bullet points consistent:

This action can't be applied to followings rules:
- 640 Prebuilt Elastic rules (editing prebuilt rules is not supported)
- 101 [%rule_type%, if they are one type e.g. Machine Learning] rules can't be edited (the current user is not a machine learning administrator)

[vitaliidm]

@cybersecdiva, issue has been addressed in #134664

[banderror]

cc @MadameSheema

[ghost]

Hi Team,

We have validated above issue on 8.4.0 BC1 and it's working fine. 🟢

Build Details

VERSION: 8.4.0 BC1
BUILD: 54999
COMMIT: 58f7eaf0f8dc3c43cbfcd393e587f155e97b3d0d

Screenshots:
NO custom Rules

Custom Rules and Non actionable rules

Custom Rules

Please let us know if we need to cover any other scenarios or we are good to close this issue.

Thanks !

CC: @MadameSheema

[banderror]

I think we've addressed all the issues described in this ticket and can close it @karanverma-qasource. Thank you.