[Security Solution][Endpoint Exceptions] Wildcard warning with IS operator for endpoint exceptions creation/editing #182903

parkiino · 2024-05-08T05:51:17Z

Summary

Adds a warning message under the value, a callout and a confirmation warning modal to endpoint exceptions if an entry contains the "IS" operator with a wildcard value
Unit Tests

Screenshots

…tions-is-wildcard

elasticmachine · 2024-05-14T18:49:28Z

Pinging @elastic/security-defend-workflows (Team:Defend Workflows)

tomsonpl · 2024-05-14T19:00:12Z

packages/kbn-securitysolution-list-utils/src/helpers/index.ts

+ */
+export const getHasWrongOperator = (items: ExceptionsBuilderReturnExceptionItem[]): boolean => {
+  let hasWrongOperator = false;
+  items[0]?.entries.forEach((e) => {


Would you consider using array.some() instead of foreach? :)

this is actually a great idea

tomsonpl

Hey, thanks for the changes! I went through the code and left some suggestions, that could help improve the readability and maintainability of this functionality 👍

Is this functionality something that you could invest more time into refactoring a bit, or you prefer to make as little changes as possible just to meet the required criteria of the task?
If the latter, I totally understand 👍 but this cumbersome component could use a little refresh - that could help you continue building on it in the future.

tomsonpl · 2024-05-16T14:53:05Z

x-pack/plugins/lists/public/exceptions/components/builder/entry_renderer.tsx

@@ -137,9 +137,10 @@ export const BuilderEntryItem: React.FC<EntryItemProps> = ({
    ([newOperator]: OperatorOption[]): void => {
      const { updatedEntry, index } = getEntryOnOperatorChange(entry, newOperator);
      handleError(false);
+      handleWarning(false);


I was wondering if you could think of a different way to manage these errors/warning? Just updating multiple states at once seems odd, and also having wrappers just for calling prop function seems redundant.
Would you have some time to refactor this component a bit?

I think refactoring would probably have to be at a later stage if that's OK

tomsonpl · 2024-05-16T14:53:36Z

x-pack/plugins/lists/public/exceptions/components/builder/exception_item_renderer.tsx

@@ -56,7 +56,7 @@ interface BuilderExceptionListItemProps {
  onDeleteExceptionItem: (item: ExceptionsBuilderExceptionItem, index: number) => void;
  onChangeExceptionItem: (item: ExceptionsBuilderExceptionItem, index: number) => void;
  setErrorsExist: (arg: EntryFieldError) => void;
-  setWarningsExist: (arg: boolean) => void;
+  setWarningsExist: (arg: boolean, arg2: string) => void;


Could you rename the args so they make more sense to other developers? :)

Sorry, this additional arg actually isn't needed anymore

tomsonpl · 2024-05-16T14:57:14Z

...y_solution/public/detection_engine/rule_exceptions/components/add_exception_flyout/index.tsx

@@ -451,6 +462,14 @@ export const AddExceptionFlyout = memo(function AddExceptionFlyout({
    expireTime,
  ]);

+  const handleOnSubmit = useCallback(() => {
+    if (wildcardWarningExists) {


Do you think that adding this if statement to the original handleOnSubmit makes sense? We could avoid having another layer of abstraction then

I don't think it would make sense in this case since I needed to separate the original submit handler for the confirmation modal. We allows the user to add the exception without addressing the warning in the confirmation modal so I wanted to have that logic on its own for the confirmation modal submit handler.

tomsonpl · 2024-05-16T15:00:20Z

...y_solution/public/detection_engine/rule_exceptions/components/add_exception_flyout/index.tsx

@@ -193,6 +200,10 @@ export const AddExceptionFlyout = memo(function AddExceptionFlyout({

  const setExceptionItemsToAdd = useCallback(
    (items: ExceptionsBuilderReturnExceptionItem[]): void => {
+      dispatch({
+        type: 'setWildcardWithWrongOperator',
+        warningExists: getHasWrongOperator(items),


Consider renaming constants/fields/functions to one (or at least similar name) - now there's too many variations for warnings

Talked with @tomsonpl offline about the need for descriptive names since we have several different functions dealing with wildcards that all do different things.

tomsonpl · 2024-05-16T15:01:11Z

..._solution/public/detection_engine/rule_exceptions/components/edit_exception_flyout/index.tsx

@@ -335,6 +348,14 @@ const EditExceptionFlyoutComponent: React.FC<EditExceptionFlyoutProps> = ({
    expireTime,
  ]);

+  const handleOnSubmit = useCallback(() => {


Same as above 👍
But also - this seems to be a duplicated code, can we do something about the reusability here?

I'm not sure that makes sense here since it's using variables from the individual reducers.

tomsonpl · 2024-05-16T15:02:22Z

..._solution/public/detection_engine/rule_exceptions/components/edit_exception_flyout/index.tsx

@@ -367,6 +388,24 @@ const EditExceptionFlyoutComponent: React.FC<EditExceptionFlyoutProps> = ({
    prefix: 'exceptionFlyoutTitle',
  });

+  const confirmModal = useMemo(() => {


Can this be moved out of this component and reused in add_exception_flyout.tsx ?

tomsonpl · 2024-05-16T15:10:42Z

packages/kbn-securitysolution-list-utils/src/helpers/index.ts

-    ) {
-      hasWrongOperator = true;
-    }
+      }) === true


Thanks for the change 👍 I think you do not need to compare this to === true, since validateHasWildcardWithWrongOperator already returns a boolean.

What do you think about the below:

export const hasInvalidOperator = (items: ExceptionsBuilderReturnExceptionItem[]): boolean => { return items[0]?.entries.some((e) => validateHasWildcardWithWrongOperator({ operator: (e as ExceptionsBuilderReturnExceptionItem[number]).type, value: (e as ExceptionsBuilderReturnExceptionItem[number]).value, }) ); };

:

vitaliidm · 2024-05-17T10:55:23Z

packages/kbn-securitysolution-list-utils/src/helpers/index.ts

+  return items[0]?.entries.some((e) => {
+    return (
+      validateHasWildcardWithWrongOperator({
+        operator: (e as ExceptionsBuilderReturnExceptionItem[number]).type,


this line throws type error

proc [tsc] packages/kbn-securitysolution-list-utils/src/helpers/index.ts:1036:62 - error TS2537: Type 'ExceptionsBuilderReturnExceptionItem' has no matching index signature for type 'number'. -- | proc [tsc] | proc [tsc] 1036 operator: (e as ExceptionsBuilderReturnExceptionItem[number]).type, | proc [tsc] ~~~~~~

can casting be avoided here?

vitaliidm · 2024-05-17T11:24:35Z

..._solution/public/detection_engine/rule_exceptions/components/edit_exception_flyout/index.tsx

@@ -367,6 +388,24 @@ const EditExceptionFlyoutComponent: React.FC<EditExceptionFlyoutProps> = ({
    prefix: 'exceptionFlyoutTitle',
  });

+  const confirmModal = useMemo(() => {
+    const { title, body, confirmButton, cancelButton } = CONFIRM_WARNING_MODAL_LABELS(
+      listType === ExceptionListTypeEnum.ENDPOINT ? ENDPOINT_EXCEPTION : RULE_EXCEPTION


So, I can see this PR affects not only endpoint exceptions, but rule exceptions too.

We already had help text, that points wildcard is used with a wrong operator.

Now, we would have additional waring and confirm modal. Three different UI elements highlighting the same possible misusing of wildcard.

cc: @ARWNightingale , @approksiu - are we good with such behaviour for rule exceptions?

The additional warning callout and confirm modal were requests from product to make sure users were addressing the issue in the value. We had several sdhs where users were having trouble diagnosing why their entries were not effective and the smaller warning underneath the value is easy to miss. I feel like rule exceptions could also benefit from this behavior too since it's using the same component, but maybe I'm mistaken?

@caitlinbetz did you have more to add on the design decision?

We should think about how to de-duplicate warnings. I thnk confirmation popup is good, but we should keep only one of the warnings - either under the value or under all conditions. cc @ARWNightingale @caitlinbetz

Thanks @approksiu . We currently have two because 1. we wanted the user to be aware of the potential issue on the form, as it was being created, and 2. wanted the user to confirm the exception if we notice a potential configuration error. So - I think they do both currently serve a purpose.

I think the "third" message, under the value, we can remove (as long as I'm not missing anything @parkiino.) I believe it was added to maintain consistency across some other forms, but again @parkiino let me know your thoughts on removing this one.

@caitlinbetz i think we probably want to keep the one under the value since they show the error per individual condition if there are multiple stringed together with the "AND" or "OR". It seems like @approksiu was suggesting we take out the single callout under all the conditions, but then that would make the design inconsistent with trusted apps and event filters. I'm not sure if it makes sense to only have it for endpoint exceptions and not rule exceptions too, if we tried to split it up that way. If it makes sense to you, maybe we just remove the callout in all the forms, if we do want to reduce one of the warning areas?

@parkiino after discussing with @approksiu - we are okay to leave this functionality as is for the time being. Thank you.

…tions-is-wildcard

…-fix'

…tions-is-wildcard

vitaliidm

@parkiino
Detection engine code looks good.
I left one comment on function name.

I also leave with @approksiu decision on how to proceed with multiple warning and confirmation modal.
What do we decide to do? Should it be merged in a current state?

vitaliidm · 2024-06-07T16:33:28Z

packages/kbn-securitysolution-list-utils/src/helpers/index.ts

+/**
+ * Given an exceptions list, determine if any entries have an "IS" operator with a wildcard value
+ */
+export const getHasWrongOperator = (items: ExceptionsBuilderReturnExceptionItem[]): boolean => {


I would rename this function to reflect it is related to wildcars, like hasWrongOperatorWithWildcard.
Otherwise it difficult to say, what this function is doing.

…tions-is-wildcard

gergoabraham

thanks for the changes! 🙌 🚀
everything looks good, there's one minor request, so i'm requesting changes to avoid auto merge : )

gergoabraham · 2024-06-10T10:02:28Z

x-pack/plugins/security_solution/public/management/common/translations.ts

@@ -202,7 +202,7 @@ export const CONFIRM_WARNING_MODAL_LABELS = (entryType: string) => {
    }),
    body: i18n.translate('xpack.securitySolution.artifacts.confirmWarningModal.body', {
      defaultMessage:
-        'Using a "*" or a "?" in the value with the "IS" operator can make the entry ineffective. Change the operator to ‘matches’ to ensure wildcards run properly. Select “cancel” to revise your entry, or "add" to continue with the entry in its current state.',
+        'Using a "*" or a "?" in the value with the "is" operator can make the entry ineffective. Change the operator to "matches" to ensure wildcards run properly. Select “Cancel” to revise your entry, or "Add" to continue with the entry in its current state.',


awesome, thanks for changing these as well!

packages/kbn-securitysolution-utils/src/path_validations/index.ts

…tions-is-wildcard

gergoabraham

awesome, thanks for all the changes! 🚢 🚀

…tions-is-wildcard

parkiino · 2024-06-11T02:43:20Z

@elasticmachine merge upstream

parkiino · 2024-06-11T10:18:57Z

@elasticmachine merge upstream

approksiu

Discussed with @ARWNightingale and @caitlinbetz. I am OK to proceed as it is implemented now.

parkiino · 2024-06-11T20:31:12Z

@elasticmachine merge upstream

kibana-ci · 2024-06-11T22:03:03Z

💚 Build Succeeded

Buildkite Build
Commit: 5fa9e41

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
`@kbn/securitysolution-list-utils`	160	161	+1

Async chunks

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

id	before	after	diff
`lists`	142.2KB	142.3KB	+85.0B
`securitySolution`	13.6MB	13.6MB	+2.0KB
total			+2.1KB

Unknown metric groups

API count

id	before	after	diff
`@kbn/securitysolution-list-utils`	207	209	+2

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

parkiino added 8 commits April 16, 2024 15:51

working callout warning

0ee80c0

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

8982ba0

…tions-is-wildcard

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

3c7644c

…tions-is-wildcard

working basic fixed callout

7769015

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

2e30f0c

…tions-is-wildcard

revert code and use common function, wip for edit

e017929

working modal

67a18cc

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

a067bc7

…tions-is-wildcard

parkiino changed the title ~~Task/endpoint exceptions is wildcard~~ [Security Solution][Endpoint Exceptions] Wildcard warning with IS operator for endpoint exceptions creation/editing May 14, 2024

parkiino added release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting Team:Defend Workflows “EDR Workflows” sub-team of Security Solution v8.15.0 labels May 14, 2024

parkiino marked this pull request as ready for review May 14, 2024 18:49

parkiino requested review from a team as code owners May 14, 2024 18:49

parkiino requested review from szwarckonrad, gergoabraham and vitaliidm May 14, 2024 18:49

tomsonpl reviewed May 14, 2024

View reviewed changes

parkiino removed the request for review from szwarckonrad May 15, 2024 15:37

parkiino added 2 commits May 15, 2024 14:25

use array.some

4ebc021

get has wrong operator unit test

0a70be9

tomsonpl requested changes May 16, 2024

View reviewed changes

tomsonpl reviewed May 16, 2024

View reviewed changes

gergoabraham reviewed May 17, 2024

View reviewed changes

: Outdated Show resolved Hide resolved

Merge branch 'main' into task/endpoint-exceptions-is-wildcard

9eff267

vitaliidm reviewed May 17, 2024

View reviewed changes

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

2e64791

…tions-is-wildcard

kibanamachine and others added 5 commits June 4, 2024 15:31

[CI] Auto-commit changed files from 'node scripts/eslint --no-cache -…

a448c9e

…-fix'

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

fddd40d

…tions-is-wildcard

adjust tests, and text

a4962c8

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

1772390

…tions-is-wildcard

fix test function name

fd43dbb

parkiino requested review from gergoabraham and vitaliidm June 7, 2024 05:17

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

4704ac4

…tions-is-wildcard

vitaliidm approved these changes Jun 7, 2024

View reviewed changes

vitaliidm requested a review from approksiu June 7, 2024 16:36

parkiino added 3 commits June 9, 2024 22:26

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

deb623c

…tions-is-wildcard

rename getHasWrongOperator"

315b43a

lint

885046d

parkiino enabled auto-merge (squash) June 10, 2024 05:39

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

351ee80

…tions-is-wildcard

gergoabraham requested changes Jun 10, 2024

View reviewed changes

parkiino added 2 commits June 10, 2024 11:14

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

e685ab4

…tions-is-wildcard

fix function and variable names

22d932a

gergoabraham approved these changes Jun 10, 2024

View reviewed changes

Merge remote-tracking branch 'upstream/main' into task/endpoint-excep…

f90749d

…tions-is-wildcard

Merge branch 'main' into task/endpoint-exceptions-is-wildcard

d86d499

Merge branch 'main' into task/endpoint-exceptions-is-wildcard

8c11c8b

approksiu approved these changes Jun 11, 2024

View reviewed changes

Merge branch 'main' into task/endpoint-exceptions-is-wildcard

5fa9e41

parkiino merged commit e767ef4 into elastic:main Jun 11, 2024
36 checks passed

parkiino deleted the task/endpoint-exceptions-is-wildcard branch June 17, 2024 14:49

[Security Solution][Endpoint Exceptions] Wildcard warning with IS operator for endpoint exceptions creation/editing #182903

[Security Solution][Endpoint Exceptions] Wildcard warning with IS operator for endpoint exceptions creation/editing #182903

Conversation

parkiino commented May 8, 2024 • edited Loading

Summary

Screenshots

elasticmachine commented May 14, 2024

tomsonpl May 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomsonpl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomsonpl May 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

parkiino May 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

parkiino May 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vitaliidm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gergoabraham left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gergoabraham left a comment

Choose a reason for hiding this comment

parkiino commented Jun 11, 2024

parkiino commented Jun 11, 2024

approksiu left a comment

Choose a reason for hiding this comment

parkiino commented Jun 11, 2024

kibana-ci commented Jun 11, 2024

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Async chunks

API count

History

parkiino commented May 8, 2024 •

edited

Loading

tomsonpl May 14, 2024 •

edited

Loading

tomsonpl May 16, 2024 •

edited

Loading

parkiino May 23, 2024 •

edited

Loading

parkiino May 28, 2024 •

edited

Loading