[8.x] [Security Solution] [Attack discovery] Alerts filtering (#205070) #205137
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## [Security Solution] [Attack discovery] Alerts filtering  This PR enhances _Attack discovery_ by providing users additional control over which alerts are included as context to the large language model (LLM). Using the new resizeable _Attack discovery settings flyout_, users may: - Filter alerts via a search bar and filters - Control the time window (previously fixed to `Last 24 hrs`) ### Before (feature flag disabled) Previously, users could only set the number of alerts sent as context to the LLM via a modal:  ### After (feature flag enabled) The new Attack discovery settings flyout replaces the modal:  It has two tabs, _Alert summary_ and _Alerts preview_. ### Alert summary The _Alert summary_ Lens embeddable counts the selected field name via an ES|QL query:  The Alert summary query is an aggregation. It does NOT display the details of individual alerts. ### Alerts preview The _Alerts preview_ Lens embeddable shows a preview of the actual alerts that will be sent as context via an ES|QL query:  Users may resize the settings flyout to view all the fields in the Alerts preview. ### Feature flag Enable the `attackDiscoveryAlertFiltering` feature flag via the following setting in `kibana.dev.yml`: ```yaml xpack.securitySolution.enableExperimental: - 'attackDiscoveryAlertFiltering' ``` Enabling the feature flag: - Replaces the `Settings` modal with the `Attack discovery settings` flyout - Includes additional `start`, `end`, and `filters` parameters in requests to generate Attack discoveries - Enables new loading messages ### Details #### Loading messages The loading messages displayed when generating Attack discoveries were updated to render three types of date ranges: 1) The default date range (`Last 24 hours`), which displays the same message seen in previous versions:  2) Relative date ranges:  3) Absolute date ranges:  #### Filtering preferences Alert filtering preferences are stored in local storage. This PR adds the following new local storage keys: ``` elasticAssistantDefault.attackDiscovery.default.end elasticAssistantDefault.attackDiscovery.default.filters elasticAssistantDefault.attackDiscovery.default.query elasticAssistantDefault.attackDiscovery.default.start ``` Users may use the `Reset` button in the Attack discovery settings flyout to restore the above to their defaults. #### Known limitations The following known limitations in this PR may be mitigated in follow-up PRs: #### Table cell hover actions are disabled Table cell actions, i.e. `Filter for` and `Filter out` are disabled in the `Alert summary` and `Alerts preview` tables. The actions are disabled because custom cell hover actions registered in `x-pack/solutions/security/plugins/security_solution/public/app/actions/register.ts` do NOT appear to receive field metadata (i.e. the name of the field being hovered over) when the action is triggered. This limitation also appears to apply to ad hoc ES|QL visualizations created via Lens in Kibana's _Dashboard_ app. ##### Default table sort indicators are hidden The `Alert summary` and `Alerts preview` tables are sorted descending by Count, and Risk score, respectively, via their ES|QL queries. The tables _should_ display default sort indicators, as illustrated by the screenshots below:   The default indicators are hidden in this PR as a workaround for an error that occurs in `EuiDataGrid` when switching tabs when the column sort indicators are enabled: ``` TypeError: Cannot read properties of undefined (reading 'split') ``` To re-enable the sort indicators, `DEFAULT_ALERT_SUMMARY_SORT` and `DEFAULT_ALERTS_PREVIEW_SORT` must respectively be passed as the `sorting` prop to the `PreviewTab` in `x-pack/solutions/security/plugins/security_solution/public/attack_discovery/pages/settings_flyout/alert_selection/helpers/get_tabs/index.tsx`, as illustrated by the following code: ```typescript <PreviewTab dataTestSubj={ALERT_SUMMARY_TEST_SUBJ} embeddableId={SUMMARY_TAB_EMBEDDABLE_ID} end={end} filters={filters} getLensAttributes={getAlertSummaryLensAttributes} getPreviewEsqlQuery={getAlertSummaryEsqlQuery} maxAlerts={maxAlerts} query={query} setTableStackBy0={setAlertSummaryStackBy0} start={start} sorting={DEFAULT_ALERT_SUMMARY_SORT} // <-- enables the sort indicator tableStackBy0={alertSummaryStackBy0} /> ``` ##### Selected date range not persisted The `start` and `end` date range selected when a user starts generation are not (yet) persisted in Elasticsearch. As a result, the loading message always displays the currently configured range, rather than the range selected at the start of generation. (cherry picked from commit 681d40e)
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…olution/public/attack_discovery/pages/index.tsx`
In `main`, the `convertToBuildEsQuery` function called in the page above accepts a parameter named `dataViewSpec`, which is typed as:
```typescript
dataViewSpec: DataViewSpec | undefined;
```
In `8.x`, the `convertToBuildEsQuery` function takes a different parameter named `indexPattern` instead of `dataViewSpec`, and it's typed differently:
```typescript
indexPattern: DataViewBase | undefined;
```
The page was updated to call the `convertToBuildEsQuery` function using the `8.x` version of the parameter.
- fixed a type error by updating `x-pack/solutions/security/plugins/security_solution/public/attack_discovery/pages/settings_flyout/alert_selection/use_data_view/index.ts`
In `8.x`, when the `AlertSelectionQuery` component in `x-pack/solutions/security/plugins/security_solution/public/attack_discovery/pages/settings_flyout/alert_selection/alert_selection_query/index.tsx` obtains a `sourcererDataView` via `useSourcererDataView` in the following code:
```typescript
const { sourcererDataView, loading: isLoadingIndexPattern } = useSourcererDataView(
SourcererScopeName.detections
);
```
the `sourcererDataView` is typed as:
```typescript
const sourcererDataView: DataViewSpec | undefined
```
The `dataViewSpec` parameter of the `useDataView` hook was updated (in this 8.x branch) to reflect the fact that `sourcererDataView` may be undefined:
```typescript
dataViewSpec: DataViewSpec | undefined;
```
and an additional check for `undefined` was added in `useDataView`.
Comment on lines
+187
to
+198
| const { indexPattern } = useSourcererDataView(); | ||
|
|
||
| // filterQuery is the combined search bar query and filters in ES format: | ||
| const [filterQuery, kqlError] = useMemo( | ||
| () => | ||
| convertToBuildEsQuery({ | ||
| config: getEsQueryConfig(uiSettings), | ||
| indexPattern, | ||
| queries: [query ?? getDefaultQuery()], // <-- search bar query | ||
| filters: filters ?? [], // <-- search bar filters | ||
| }), | ||
| [filters, indexPattern, query, uiSettings] |
There was a problem hiding this comment.
In main, the convertToBuildEsQuery function called here accepts a parameter named dataViewSpec, which is typed as:
dataViewSpec: DataViewSpec | undefined;In 8.x, the convertToBuildEsQuery function takes a different parameter named indexPattern instead of dataViewSpec, and it's typed differently:
indexPattern: DataViewBase | undefined;The page was updated to call the convertToBuildEsQuery function using the 8.x version of the parameter.
| dataViewSpec, | ||
| loading, | ||
| }: { | ||
| dataViewSpec: DataViewSpec | undefined; |
There was a problem hiding this comment.
In 8.x, when the AlertSelectionQuery component in x-pack/solutions/security/plugins/security_solution/public/attack_discovery/pages/settings_flyout/alert_selection/alert_selection_query/index.tsx obtains a sourcererDataView via useSourcererDataView in the following code:
const { sourcererDataView, loading: isLoadingIndexPattern } = useSourcererDataView(
SourcererScopeName.detections
);the sourcererDataView is typed as:
const sourcererDataView: DataViewSpec | undefinedThe dataViewSpec parameter of the useDataView hook was updated (in this 8.x branch) to reflect the fact that sourcererDataView may be undefined:
dataViewSpec: DataViewSpec | undefined;| let active = true; | ||
|
|
||
| async function createDataView() { | ||
| if (dataViewSpec != null && !loading) { |
There was a problem hiding this comment.
This additional check was added because in the 8.x branch, the dataViewSpec argument may be undefined:
dataViewSpec: DataViewSpec | undefined;as noted in this comment above.
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
History
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This will backport the following commits from
mainto8.x:Questions ?
Please refer to the Backport tool documentation