[SIEM] Detections add alert & signal tab

[XavierM]

Summary

@angorayc and I worked together to get the alert tab on detection engine,

@patrykkopycinski be aware of this PR for your breadcrumb fix on the detection engine.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[MichaelMarcialis]

@MichaelMarcialis I should do the same for rule details since we have tabs there too

@XavierM: Actually, that shouldn't be necessary on the rule details page, since the tabs are supposed to be below the definition, about and schedule panels. It looks as though the tabs on that page are in the wrong spot right now. I'll make sure to record that in my full detection engine design review.

[MichaelMarcialis]

Thanks for making these changes, @XavierM and @angorayc! It's looking great. Here's a few notes from my review.

• With the addition of third-party alerts, the “Last signal” timestamp subtitle in the page header no longer makes sense. There are a few possibilities to fix this, but for the sake of simplicity, would it be possible to replace the "Last signal" subtitle with a new "Last detection" subtitle that uses either the most recent signal or alert relative timestamp (whichever is the most recent)?
  We agree to keep it the way it is

• The alerts histogram header text appears to change in accordance with the selection the user has made in the stack selector. However, the signals histogram does not do this. For consistency’s sake, can we have the alerts histogram header not change at all, thus matching the signals histogram? I think simply having the text be a static “Alert detection frequency” will do (assuming this doesn’t have any ill effects elsewhere).

• Currently, the alerts histogram legend is aligned on the right side of the panel, while the signals histogram's legend is bottom aligned. For consistency, can align the signals histogram legend to the right (and possibly all other histograms found in the hosts and network sections, if time permits)?

• The signals table header text is currently "All signals". Can we change this to “Signals” to match with alerts table wording?

• The current rules page header text is "Rules". Can we now change the rules page header text to be “Signal detection rules” to match the wording of our new button text?

[andrew-goldstein]

• The alerts table header text is currently "Alerts". Can we change this to “All alerts” to match with signals table wording?

@MichaelMarcialis technically, the All Signals table on the Detection engine page is always showing a subset of all the signals that have been created. This is true because the date picker (+ KQL) ensure only some of the signals that have been created (24 hours by default) are being shown.

Also per the screenshot below, it's only possible to view only Open signals or Closed signals, but never both of them at the same time:

Thus ignoring the date picker, the table still is only showing a subset of signals (open or closed).

If you agree that the table is technically not showing all of the signals that have been created, or even all of the signals (simultaneously) for the selected date range, please consider recommending an alternative to All in All signals

[MichaelMarcialis]

@MichaelMarcialis technically, the All Signals table on the Detection engine page is always showing a subset of all the signals that have been created. This is true because the date picker (+ KQL) ensure only some of the signals that have been created (24 hours by default) are being shown.

Good point. I'll update my comment to reflect this. Thanks!

[andrew-goldstein]

I wouldn't hold up this PR for it, but FYI i'm not seeing the Signals histogram refreshing when the date picker Update is clicked (on both the Detection engine and Overview page

[andrew-goldstein]

Lot's of much needed fixes and great catches in this PR. Thanks @XavierM 🙏

I did some light desk testing and ran a subset of the cypress tests. I found one (unrelated to this PR) issue with refreshing the Signals histogram, but there's no reason to hold up this PR for it.

LGTM 🚀

[XavierM]

I wouldn't hold up this PR for it, but FYI i'm not seeing the Signals histogram refreshing when the date picker Update is clicked (on both the Detection engine and Overview page

This is known issue, we will fix it in coming PR

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: d04abc0

History

• 💚 Build #21161 succeeded 17c33d0
• 💚 Build #20998 succeeded b3e3929
• 💔 Build #20962 failed 12395be

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