[Security Solution] Add the ability to filter by index pattern to the rules management table#128245
Conversation
0581c6a to
8ef2d28
Compare
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
8ef2d28 to
c282980
Compare
|
@yiyangliu9286 As a follow-up to our discussion, could you please review the changes to the rules table header and filters?
I kept the refresh button as it was before as there's no ready-to-use UI component at the moment (or I am missing something 🤔). So I would propose implementing it separately and updating all our tables at once. Also, I kept the Custom/Elastic rules toggle in its place as there are not too many other filters, so enough space. But please let me know if you think we should move that toggle. |
Hi @xcrzx! Thanks so much for this quick implementation updates, this looks awesome!
I agree that we can keep the current table actions as is because the new table utility bar component haven't been made to an EUI component yet (as far as I know of). One small question, do you think if it makes sense to implement the "Auto refresh" and the "Refresh" button as part of this release's changes, since the EuiAutoRefreshButton component is ready to use (i know that in our case, we need some customization to the existing component). Or we should make this as an UX/UI enhancement as part of the 8.3 cycle? I am happy for either decision based on your time and capacity. |
Let's work on it separately and ship in a different PR to keep our PRs single-purpose. @yiyangliu9286 It would be super helpful if we had a ticket describing the design changes that we'd like to apply to the Rule Management and Monitoring tables. While it's clear how we could move filters from one place on the table to another, I'd be willing to sync on the new table refresh button in more detail: its behavior and UI states. |
@xcrzx If |
Thanks, @banderror! I couldn't find it in the docs for some reason. It looks like we can use it but need some exploration on how we wire it up with other components. Let's do that separately, as there's not much time left before FF. |
5d600d1 to
a9c358d
Compare
a9c358d to
9f7d8f4
Compare
💛 Build succeeded, but was flakyTest Failures
Metrics [docs]Async chunks
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @xcrzx |
| // Check that the rules table shows at least one row | ||
| cy.get(RULES_TABLE).find(RULES_ROW).should('have.length.gte', 1); | ||
| // Check that the rules table doesn't show the rule from the first page | ||
| cy.get(RULES_TABLE).should('not.contain', ruleNameFirstPage); |
There was a problem hiding this comment.
cc @MadameSheema -- not sure if you're still tracking cypress changes, but here's a few more. Let me know if you'd like to stop receiving these pings! 🙂
| 'xpack.securitySolution.detectionEngine.rules.allRules.searchPlaceholder', | ||
| { | ||
| defaultMessage: 'e.g. rule name', | ||
| defaultMessage: 'Search by rule name, index pattern, or MITRE ATT&CK tactic or technique', |
| const SEARCHABLE_RULE_PARAMS = [ | ||
| 'alert.attributes.name', | ||
| 'alert.attributes.params.index', | ||
| 'alert.attributes.params.threat.tactic.id', | ||
| 'alert.attributes.params.threat.tactic.name', | ||
| 'alert.attributes.params.threat.technique.id', | ||
| 'alert.attributes.params.threat.technique.name', | ||
| ]; |
There was a problem hiding this comment.
Was subtechnique not added as a searchable param? You know if there was any particular reason?
There was a problem hiding this comment.
Good catch, thanks, @spong! I'll add subtechnique to the searchable params as well.
| const filters: string[] = []; | ||
|
|
||
| if (showCustomRules) { | ||
| filters.push(`alert.attributes.tags: "${INTERNAL_IMMUTABLE_KEY}:false"`); | ||
| } |
There was a problem hiding this comment.
This function is far more readable -- thank you @xcrzx!
|
|
||
| if (tags.length > 0) { | ||
| filters.push( | ||
| `alert.attributes.tags:(${tags.map((tag) => `"${escapeKuery(tag)}"`).join(' AND ')})` |
There was a problem hiding this comment.
++ for bringing in the common escapeKuery 👍
| { | ||
| refetchInterval, | ||
| enabled: isInMemorySorting, | ||
| keepPreviousData: true, // Use this option so that the state doesn't jump between "success" and "loading" on page change |
| 'xpack.securitySolution.detectionEngine.rules.allRules.searchPlaceholder', | ||
| { | ||
| defaultMessage: 'e.g. rule name', | ||
| defaultMessage: 'Search by rule name, index pattern, or MITRE ATT&CK tactic or technique', |
There was a problem hiding this comment.
Also noticed a small UX item here: if a user copies the whole tactic/technique from Rule Details, ie. Defense Evasion (TA0005) and pastes that in they won't get any results since id/name are independent fields -- they would need to search Defense Evasion or TA0005. Not too much we could do here outside updating the placeholder text on the search bar to include an example maybe?
There was a problem hiding this comment.
Yeah, I agree 👍 Providing an example would make this UI a bit friendlier to our users.
spong
left a comment
There was a problem hiding this comment.
Checked out, tested locally, and performed code review. LGTM @xcrzx! 👍
Couple small nits, and a potential copy change that may need to be updated, but everything else looks and tested great! Thanks for the additional cleanup you've provided along the way as well! 🙂
|
Thanks for your review, @spong! I'm going to add a tour showing the new capabilities in the next PR, so I will also include changes to copy and filter by |




Partially addresses: #125596, https://github.com/elastic/security-team/issues/1972
Resolves: #126166
Summary
Added the ability to sort detection rules by index pattern and MITRE ATT&CK tactics or techniques.
1. Filter by index pattern
2. Filter by MITRE ATT&CK tactic or technique name
3. Filter by MITRE ATT&CK tactic or technique id
Other changes
In the in-memory implementation, rules are not filtered on the client-side anymore. Instead, we fetch filtered rules from the server and only sort and paginate them in memory. This change was necessary to get rid of discrepancies between the two implementations. See #126166 for more detail.