[Security Solution][Alerts] Provide more information about rule exception behavior before creation

[marshallmain]

Rule preview now provides users with a reliable way to assess how a rule will perform before creating a rule or before saving changes when editing a rule. Rule preview when editing a rule takes into account any exceptions that have already been added to the rule. However, when creating a new exception users don't have a good way to quickly verify if the exception will suppress new alerts the way they intend.

We've received a number of SDHs in the past where users create an exception and then find that the exception does not suppress alerts as intended. e.g.

• https://github.com/elastic/sdh-security-team/issues/488
• https://github.com/elastic/sdh-security-team/issues/437
• https://github.com/elastic/sdh-security-team/issues/405

Most commonly these issues occur when a field is mapped in some indices but not others - in this scenario, a field appears in the field selection drop-down because it is mapped in some indices but the field does not work in all indices. The result is the exception can be created without issue, but the exception may not work as expected on indices where the field is unmapped.

In other cases, exceptions may not work as expected if the field's value is not clearly displayed in the UI. SDH We've encountered some cases where, for example, the whitespace in the exception entry is not displayed but is included in the actual exception, causing the entry not to match documents that it appears that it should.

Discussion

We would like to provide users with more tools to verify how their exceptions will operate before creating them. These new tools should make it faster and easier for users to detect cases like those above where exceptions will not perform as they intend, and allow for fast feedback loops where a user can define an exception in the flyout, test it, make changes, and test again - all without having to wait for the rule to run again and/or wait for new data to come in that triggers the rule.

We have 2 initial proposals for UX changes:

1. In the field selection drop down, add a counter like 47/57 for each field that shows how many indices the field is mapped in out of the total indices fields are selected from. E.g. 47/57 would mean that of the 57 indices, that field is not mapped in 10 indices. We could add a tooltip or warning icon in cases where a field is not mapped in all of the indices to notify users that the field is not mapped in some of their indices, and this may cause the exception not to work as intended.
2. Extend the rule preview API to accept ephemeral exception items, separately from the standard rule schema that includes exception list IDs, so we can preview what the rule would do with an exception item without actually creating the exception. We could then add a preview capability in the "Add Rule Exception" flyout with either a full table of preview results, a summary of statistics about the preview results (alerts created, or a histogram, etc), or maybe 2 tables side-by-side comparing how the rule executes with/without the exception.

This issue is for tracking work on exploring these 2 options and other options for providing improved visibility into exception behavior before the exceptions are created.

[elasticmachine]

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

[e40pud]

I've got design feedback from @ARWNightingale to improve the warning message that we show underneath the field dropdown menu when users select a field with the mapping issues. We will use the accordion component to hide the details of the warning (showing all the mapping issues across all the indices).

Screen.Recording.2023-01-30.at.12.23.12.mov

Also, we will show the tooltip on problematic field hovering while selecting one from the dropdown menu:

[e40pud]

We covered mapping issues in this PR. The proposal about the previewing what the rule would do with an exception item without actually creating the exception will be addressed in this ticket.