Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DOCS][Security Solution][Exceptions] - New exceptions UI/UX #2304

Closed
yctercero opened this issue Aug 12, 2022 · 8 comments · Fixed by #2546
Closed

[DOCS][Security Solution][Exceptions] - New exceptions UI/UX #2304

yctercero opened this issue Aug 12, 2022 · 8 comments · Fixed by #2546
Assignees
Labels

Comments

@yctercero
Copy link
Contributor

yctercero commented Aug 12, 2022

Description

We are updating the exceptions UI/UX. Much of it is not necessarily new functionality, but updated flows. To be a bit more specific, a lot of this already exists on the API for exceptions, but was not exposed in the UI. However, it is going to touch a lot of surface area.

Ticket will be updated as we merge changes in.

Exceptions Epic

[Update 9.14.22] - much of epic has been pushed to 8.6. This ticket will reflect only what is going in 8.5.

Changes made

Rule details exceptions tab

  • Exceptions tab is now split into Rule exceptions tab and Endpoint exceptions tab [PR]
    • If the rule is not linked to the endpoint exception list, the Endpoint exception tab will not be shown
  • The exception item UI has been updated [PR]
    • It now includes an Affects x rules button that shows the user which rules are affected by the exception item
      • Clicking on it shows the rules and user can click to navigate to that rule
  • The view for when no exception items exists is updated [PR]

The exceptions list management page, edit/add modal all remain unchanged.

@yctercero
Copy link
Contributor Author

Release notes for PR:

@nastasha-solomon
Copy link
Contributor

@yctercero thanks for providing summaries for both! If the bugs fixed in elastic/kibana#141682 were discovered internally (i.e., they weren’t reported by one of our customers), it’s likely fine to omit them from the 8.5.0 release notes.

@yctercero
Copy link
Contributor Author

@yctercero thanks for providing summaries for both! If the bugs fixed in elastic/kibana#141682 were discovered internally (i.e., they weren’t reported by one of our customers), it’s likely fine to omit them from the 8.5.0 release notes.

Yes! So far all those were internally reported.

@nastasha-solomon
Copy link
Contributor

@yctercero @joepeeples and I had a few questions about the new Rule exceptions and Endpoint exception tabs:

  • What conditions need to be met in order for the Endpoint exception tab to display on a rule's details page? Do users need to enable the Elastic endpoint exceptions advanced rule setting when creating the rule? Does the rule also need at least one exception associated with it? Do any other requirements need to be met in order for this tab to display?
    • I noticed you had mentioned that a rule needs to be linked to an Endpoint exception list for the Endpoint exception tab to display, but I'm not sure how users would create that link. I'm also not too clear on what an exceptions list is-- our docs are fairly limited on the subject.
  • Have a similar question about the workflow for creating new Endpoint exceptions from an alert. What determines whether a user do this?
  • Is the change I highlighted below a new addition in 8.5? If it is, would you mind sharing the PR associated with it?

exceptions-list-change

@jmikell821 jmikell821 added the Team: Detections/Response Detections and Response label Sep 28, 2022
@yctercero
Copy link
Contributor Author

@yctercero @joepeeples and I had a few questions about the new Rule exceptions and Endpoint exception tabs:

  • What conditions need to be met in order for the Endpoint exception tab to display on a rule's details page? Do users need to enable the Elastic endpoint exceptions advanced rule setting when creating the rule? Does the rule also need at least one exception associated with it? Do any other requirements need to be met in order for this tab to display?

    • I noticed you had mentioned that a rule needs to be linked to an Endpoint exception list for the Endpoint exception tab to display, but I'm not sure how users would create that link. I'm also not too clear on what an exceptions list is-- our docs are fairly limited on the subject.

So for the endpoint exceptions tab to display, we check to see if the rule is referencing the endpoint exception list - that's just an internally created exception list container dedicated to endpoint exceptions that are processed in both the detection engine and the endpoints. The api docs go into more detail than the Ui docs about this breakdown of a list vs item. Maybe it'd be helpful to reference that in the UI docs? The goal is with the now 8.6 exceptions makeover, all this will be more intuitive.

The user can add an endpoint list to their rule in 2 ways:

  • Rule about advanced settings --> check the box that says add endpoint exception list
  • Add an endpoint exception from the alerts table. This is an option when the alert contains endpoint data, otherwise, it is disabled as an alert action

None of this functionality described is new, but I do see from working on this and also your (great) questions that perhaps this is a UX we want to revisit or now that it is a tab on its own it requires a bit more explanation from our end. It is by no means intuitive for a user to add endpoint exceptions to make the tab appear. I've suggested that we always show that tab. cc @peluja1012

  • Have a similar question about the workflow for creating new Endpoint exceptions from an alert. What determines whether a user do this?

There's a check we do to see if the alert data contains endpoint fields, if it does, then that option is made available from the alert actions dropdown.

  • Is the change I highlighted below a new addition in 8.5? If it is, would you mind sharing the PR associated with it?
exceptions-list-change

That change is not new for 8.5. Just the changes made to the exception item card displayed in the exceptions tab in rule details.

@nastasha-solomon
Copy link
Contributor

Thanks for the helpful explanations and links, @yctercero! Couple questions and some thoughts:

  • Am I understanding correctly that an exception list is a container that holds one more exception items? Usually, I'd expect a list to be more than one item but maybe in this case, a list can be one item or more?
  • Is there a difference between an endpoint exception list and a general exception list? Can endpoint exception lists only be created for alerts that have endpoint data? In our docs, we generally explain what exception lists are and how they're made but if endpoint exception lists are different, we should explain why and how.
  • Which alert fields are considered endpoint fields?

@yctercero
Copy link
Contributor Author

Thanks for the helpful explanations and links, @yctercero! Couple questions and some thoughts:

  • Am I understanding correctly that an exception list is a container that holds one more exception items? Usually, I'd expect a list to be more than one item but maybe in this case, a list can be one item or more?

Correct. The container is just a saved object with general information on a list. The list can actually have 0, 1 or more exception items. A list with 0 items doesn't exactly do much, but it is possible. So like in the new flow for 8.6 (NOT 8.5 yet) a user will be able to "Crate exception list" from the UI. At that point the container will have 0 items and then the user adds items to it.

  • Is there a difference between an endpoint exception list and a general exception list? Can endpoint exception lists only be created for alerts that have endpoint data? In our docs, we generally explain what exception lists are and how they're made but if endpoint exception lists are different, we should explain why and how.

Endpoint exception lists are conceptually the same, but when we refer to the endpoint exception list it refers to a list that is internally managed and created by us, not the user. We just allow them to link rules to the list and add items to the list if they want. The biggest difference is that endpoint exception lists get evaluated on both the detection engine and the agent. Exception lists on the other hand, are always just evaluated in the detection engine. That's what the text added in elastic/kibana#141682 tries to explain (where each list type gets evaluated).

  • Which alert fields are considered endpoint fields?

To allow a user to add an endpoint exception from an alert, we check for kibana.alert.original_event.module determined:endpoint and kibana.alert.original_event.kind:alert. In terms of what fields a user is able to add an exception for for endpoint list - they're the following - https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/detection_engine/rule_exceptions/utils/exceptionable_endpoint_fields.json

@nastasha-solomon
Copy link
Contributor

The additional information is helpful - thanks, @yctercero !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants