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][Case][Bug] Only update alert status in its specific index #92530

Merged
merged 14 commits into from
Mar 3, 2021

Conversation

jonathan-buttner
Copy link
Contributor

@jonathan-buttner jonathan-buttner commented Feb 23, 2021

This PR fixes a bug where updating the status of an alert could change multiple alerts if they have the same _id in separate indices. To fix this we'll update and retrieve alerts using the Elasticsearch bulk and mget APIs. The alert information is currently stored in two arrays (alertIds and index) within the saved object. Before we interact with the Elasticsearch APIs we'll transform them into an array of objects so we tie each alert ID to a specific index. This avoids accidentally updating an alert with a specific _id across multiple indices at the same time.

Issue: #91936

@jonathan-buttner jonathan-buttner added v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.12.0 Team:Threat Hunting Security Solution Threat Hunting Team Feature:Cases Cases feature v7.13.0 labels Feb 23, 2021
@jonathan-buttner jonathan-buttner requested a review from a team as a code owner February 23, 2021 22:14
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

@jonathan-buttner
Copy link
Contributor Author

@elasticmachine merge upstream

ids: ['alert-id-1'],
status: CaseStatuses.closed,
indices: new Set<string>(['.siem-signals']),
alerts: [{ id: 'alert-id-1', index: '.siem-signals', status: CaseStatuses.closed }],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So each alert will only have one index? Just curious if index should still be a Set()

// create an array of requests that indicate the id, index, and status to update an alert
const alertsToUpdate = totalAlerts.saved_objects.reduce(
(acc: UpdateAlertRequest[], alertComment) => {
if (isCommentRequestTypeAlertOrGenAlert(alertComment.attributes)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessary for this PR, but just thinking it may be better to have functions that only care about one status, i.e. isCommentRequestType(attributes) || isGenAlert(attributes). I just imagine other forms of alerts in the near or far future appearing and this becoming more unwieldy.

@@ -219,8 +219,8 @@ export class CaseClientHandler implements CaseClient {
} catch (error) {
throw createCaseError({
message: `Failed to get alerts using client ids: ${JSON.stringify(
args.ids
)} \nindices: ${JSON.stringify([...args.indices])}: ${error}`,
args.alertsInfo
Copy link
Contributor

@michaelolo24 michaelolo24 Mar 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it alerts or alertsInfo...Looking at your other change in this file on line 172 (should they be the same or different?) (saw your client/types file). Also, forgot to change the "ids" to "alerts" right before the stringify in this change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh thank you. Yeah alertsInfo vs alerts is kind of confusing. They're slightly different structures but I didn't know how to name them haha. Any ideas?

* id existing in an index at each position in the array. This is not ideal. Ideally an alert comment request would
* accept an array of objects like this: Array<{id: string; index: string; ruleName: string ruleID: string}> instead.
*
* To reformat the alert comment request requires a migration and a breaking API change.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you create an issue for this when you have time, so we can discuss it there? It sounds like it's worth making the change for more stability. And the changed API seems much easier to potentially work with

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah good idea. I'll create the issue 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Copy link
Contributor

@michaelolo24 michaelolo24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed here and also virtually with @jonathan-buttner

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
triggersActionsUi 1.6MB 1.5MB -23.9KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
triggersActionsUi 104.1KB 104.2KB +82.0B
Unknown metric groups

async chunk count

id before after diff
triggersActionsUi 41 42 +1

History

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

@jonathan-buttner jonathan-buttner merged commit 9dd395b into elastic:master Mar 3, 2021
@jonathan-buttner jonathan-buttner deleted the sync-alerts-dup-id branch March 3, 2021 18:29
jonathan-buttner added a commit to jonathan-buttner/kibana that referenced this pull request Mar 3, 2021
…ic index (elastic#92530)

* Writing failing test for duplicate ids

* Test is correctly failing prior to bug fix

* Working jest tests

* Adding more jest tests

* Fixing jest tests

* Adding await and gzip

* Fixing type errors

* Updating log message

Co-authored-by: Kibana Machine <[email protected]>
jonathan-buttner added a commit to jonathan-buttner/kibana that referenced this pull request Mar 3, 2021
…ic index (elastic#92530)

* Writing failing test for duplicate ids

* Test is correctly failing prior to bug fix

* Working jest tests

* Adding more jest tests

* Fixing jest tests

* Adding await and gzip

* Fixing type errors

* Updating log message

Co-authored-by: Kibana Machine <[email protected]>
jonathan-buttner added a commit that referenced this pull request Mar 3, 2021
…ic index (#92530) (#93484)

* Writing failing test for duplicate ids

* Test is correctly failing prior to bug fix

* Working jest tests

* Adding more jest tests

* Fixing jest tests

* Adding await and gzip

* Fixing type errors

* Updating log message

Co-authored-by: Kibana Machine <[email protected]>

Co-authored-by: Kibana Machine <[email protected]>
jonathan-buttner added a commit that referenced this pull request Mar 3, 2021
…ic index (#92530) (#93509)

* Writing failing test for duplicate ids

* Test is correctly failing prior to bug fix

* Working jest tests

* Adding more jest tests

* Fixing jest tests

* Adding await and gzip

* Fixing type errors

* Updating log message

Co-authored-by: Kibana Machine <[email protected]>

Co-authored-by: Kibana Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Cases Cases feature release_note:skip Skip the PR/issue when compiling release notes Team:Threat Hunting Security Solution Threat Hunting Team v7.13.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants