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

[Security Solution] Discuss UI/UX designs for customizing prebuilt rules #178211

Closed
Tracked by #174168
jpdjere opened this issue Mar 7, 2024 · 4 comments
Closed
Tracked by #174168
Labels
8.14 candidate design Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.

Comments

@jpdjere
Copy link
Contributor

jpdjere commented Mar 7, 2024

Epics: https://github.com/elastic/security-team/issues/1974 (internal), #174168

This ticket contains decisions made in sync meetings about the UI/UX of the different pages/components needed for Milestone 3 of the Prebuilt Rules Customization epic. You can always refer to the designs:

Figma designs

Design alignment of 2024-03-28

Three-Way-Diff component

  • Two scenarios of conflict for a specific field, solvable and non-solvable:
    • If solvable: use read-only view as default, and pre-populated with automerged proposal
    • If not-solvable: use editable component view as default, pre-populated with current version
  • Both dropdowns should be in the left column. They allow the user to choose two versions for comparison using an inline diff in the left column
  • Review update after accepting all field changes:
    • Button called "Preview final update", onclick opens modal with final review in JSON diff style (current vs final versions)
    • Reuse JSON diff component for final review

Rule Updates table and Add Elastic Rules page

  • Update filtering to allow by: Elastic rules and Customized Elastic rules
  • Rule category wording in filters:
    • How do we differentiate Elastic customized vs Elastic non-customized? Maybe just call customized vs non-customized. Or customized: YES vs NO.
  • (Milestone 4) Rework filtering as Alex proposed in the design in the Rule Updates page and Add Elastic Rules page, with the facet sidebar.

Rule Management table

  • Explore adding a facet view for filtering, as well. Take into account space constraints.
  • If not possible, just add a new "Elastic customized" button to the existing filters

Rule Details page

  • How are we indicating what the "rule category" is (non-customized prebuilt VS customized prebuilt VS custom) on the page?
    • Display it somewhere in the header. Design TBD
  • For future (not Milestone 3): Which fields were customized? Add icon beside the field to mark it as customized.

Rule Editing page

  • For future (not Milestone 3): Which fields were customized? Add icon beside the edit field component to mark it as customized.

Design alignment of 2024-03-06

Alignment between @ARWNightingale @banderror and @jpdjere on changes needed for:

Three Way Diff component for each field:

Update Flyout

  • Rule Preview
    • To see diffs between the current version and the Final Version chosen by the user, we’d like to introduce a subsequent step to field diff solving, which works as a preview, where the current rule field values are displayed against the final rule field values (that is, the end result that the rule will have once the upgrade is performed) with diffs+highlighting.
    • Preview button should only be enabled when all fields are accepted
    • Clicking on the preview button changes the view to a JSON diff view showing the diff between the current view and the Final Version of the rule.
    • We should reuse the JSON diff view component that currently lives in its own tab.

Update Rules Table

Rules Table

  • Discussed if Elastic prebuilt rules should show some kind of indication that they are customized:
    • Not for now due to space constraints.
    • Instead create a good filtering experience.
  • Filters:
    • Allow users to filter rules by custom, Elastic or Elastic customized (Elastic customized will be a subset of Elastic)

Rule Detail page

  • How do we indicate that a Prebuilt Rules is customized:
    • Will add to the designs a "Rule category" piece of information that describes this.
    • For now, we won't show which fields were modified or how (this requires introducing a new endpoint that calculates a rules' diff with its base version).
@jpdjere jpdjere added triage_needed design Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Detection Rule Management Security Detection Rule Management Team Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area labels Mar 7, 2024
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

@jpdjere
Copy link
Contributor Author

jpdjere commented Apr 10, 2024

UI tickets created, see draft plan for links: #174168 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.14 candidate design Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
Projects
None yet
Development

No branches or pull requests

3 participants