[SIEM] Adds Signals Histogram

[spong]

Summary

Detection Engine Meta Issue: #50405

This PR adds the Signals Histogram component for use on the main Detection Engine page, Rule Details page, and the newly designed Overview page.

Out of the box configuration includes an EuiSelect for stacking by the following:

• Risk Scores
• Severities
• Event Actions
• Event Categories
• Host Names
• Rule Types
• Rules
• Users
• Destination IPs
• Source IPs

Additional configuration properties are available to configure the component as needed depending on where it will be displayed (e.g. no Stack By option on Overview, filter to specific rule_id on Rule Details, etc):

interface SignalsHistogramPanelProps {
  defaultStackByOption?: SignalsHistogramOption;
  filters?: esFilters.Filter[];
  from: number;
  query?: Query;
  legendPosition?: 'left' | 'right' | 'bottom' | 'top';
  loadingInitial?: boolean;
  showLinkToSignals?: boolean;
  showTotalSignalsCount?: boolean;
  stackByOptions?: SignalsHistogramOption[];
  title?: string;
  to: number;
  updateDateRange: (min: number, max: number) => void;
}

Light Theme:

Dark Theme:

Overview:

Example props for overview impl:

<SignalsHistogramPanel
  filters={filters}
  from={from}
  loadingInitial={loading}
  query={query}
  showTotalSignalsCount={true}
  showLinkToSignals={true}
  defaultStackByOption={{
    text: 'Signals count by MITRE ATT&CK category',
    value: 'signal.rule.threats',
  }}
  legendPosition={'right'}
  to={to}
  title="Signals count by MITRE ATT&CK category"
  updateDateRange={updateDateRangeCallback}
/>

Note @andrew-goldstein @angorayc @MichaelMarcialis -- looks like the MITRE ATT&CK Tactics are stored as a nested object in signal.rule.threat, so we may have to do some finangling to get it to show on the histogram.

e.g. format:

{
  "framework": "MITRE ATT&CK",
  "tactic": {
    "id": "TA0010",
    "reference": "https://attack.mitre.org/tactics/TA0010",
    "name": "Exfiltration"
  },
  "techniques": [
    {
      "id": "T1002",
      "name": "Data Compressed",
      "reference": "https://attack.mitre.org/techniques/T1002"
    }
  ]
}

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
  • Will work with @benskelker on any specific documentation
• 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)

[angorayc]

I like that we still have i18n in histograms' label!

[angorayc]

Ran the branch and all worked well. Thanks a lot for adding the dropdown list and histogram!

[FrankHassanabad]

This is confusing for a few reasons and the intention is not really there.

The io-ts TypeScript for updated_by and created_by both say they cannot be null but looking at the operators it does look like they can be which I think is the actual use case. So I would change the types.

The second part is that when updated_by is null it will never hit these lines below and show an updated_by by UNKNOWN but rather just show an empty string.

So which is it we want? To show nothing for updated_by when it is null or to show it but mark it as UNKNOWN?

[spong]

Oooh good catch. This is existing code that got reformatted from my changes, so will have to hear from @XavierM on this, but my best guess is that we'd want the latter and show UNKNOWN. Although there may be some special logic I'm missing out on for how updated_by is used?

[FrankHassanabad]

From the backend we always provide a updated_at and a created_at without mistake as far as I know now. So the checks for these should never happen.

However, same issues with TypeScript saying that these two can never be null/undefined. If you want to be safe and just guard against a regression bug on our side or something else, I would change the type system to reflect that and also I would not put "fake dates" such as new Date().toISOString() but rather defer to using a -- nonexistent placeholder to show that they just aren't present.

Up to you.

[spong]

cc @XavierM -- this may be an artifact from initial development when they weren't always present?

[FrankHassanabad]

Few conversations but feel free to merge anytime.

[kibanamachine]

💚 Build Succeeded

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

History

• 💚 Build #18896 succeeded 8da528d
• 💚 Build #18273 succeeded 18d9718
• 💚 Build #17056 succeeded 8d47169

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