-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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][Detections][Threshold Rules] Threshold multiple aggregations with cardinality #90826
Conversation
This reverts commit b73b34a.
...lugins/security_solution/server/lib/detection_engine/signals/threshold_get_bucket_filters.ts
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/detections/components/rules/threshold_input/index.tsx
Show resolved
Hide resolved
...lugins/security_solution/server/lib/detection_engine/signals/threshold_get_bucket_filters.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/detections/components/alerts_table/actions.tsx
Outdated
Show resolved
Hide resolved
...ugins/security_solution/server/lib/detection_engine/signals/bulk_create_threshold_signals.ts
Outdated
Show resolved
Hide resolved
...plugins/security_solution/server/search_strategy/timeline/factory/events/all/helpers.test.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 🦖 📦 🐔
@@ -36,7 +36,14 @@ export interface MatrixHistogramRequestOptions extends RequestBasicOptions { | |||
timerange: TimerangeInput; | |||
histogramType: MatrixHistogramType; | |||
stackByField: string; | |||
threshold?: { field: string | undefined; value: number } | undefined; | |||
threshold?: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like a few changes similar to this one were made in this PR, would it be worth pulling this out into its own type shared between the updated code? not a blocker, but might be a nice follow up.
threshold: { | ||
field: ['host.name'], | ||
value: 100, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this rule has type query
so adding threshold
fields to it makes an invalid rule. The test works for now, but may be a pain later if build_bulk_body
starts using the stricter types that keep different rule types separated.
@@ -95,16 +96,24 @@ export const buildSignal = (docs: BaseSignalHit[], rule: RulesSchema): Signal => | |||
}; | |||
}; | |||
|
|||
const isThresholdResult = (thresholdResult: SearchTypes): thresholdResult is ThresholdResult => { | |||
return typeof thresholdResult === 'object'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any array will satisfy this check
field, | ||
value: result[0].value, | ||
}; | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One edge case to consider here is what happens when a threshold rule is edited and the list of fields to aggregate on changes.
Suppose threshold.fields
was ["source.ip", "destination.ip", host.name"]
and we edit the rule removing host.name
. On the next rule run, when we find a signal that was made pre-edit and build a filter based on that signal the filter will only include source.ip
and destination.ip
since host.name
will no longer be in bucketByFields
. This filter will be broader than the bucket from the original signal so we risk excluding documents that were not part of the original set that met the threshold.
Instead we could create the filters based only on signalTerms
and not use bucketByFields
at all when generating these filters. This way, in the above case where a field is removed from threshold rule, future rule runs will still include that field and value in the filter.
I think the current behavior is good enough that these edge cases can be addressed in a follow up PR.
Also for a follow up PR: if you specify a cardinality field but leave the "group by" field blank then the cardinality field is silently ignored. We should either disallow this combination or use the cardinality field when "group by" is blank. |
…ggregations with cardinality (#90826) (#91792) * Remove unnecessary spreads * Layout, round 1 * Revert "Layout, round 1" This reverts commit b73b34a. * Make threshold field an array * Add cardinality fields * Fix validation schema * Query for multi-aggs * Finish multi-agg aggregation * Translate to multi-agg buckets * Fix existing tests and add new test skeletons * clean up * Fix types * Fix threshold_result data structure * previous signals filter * Fix previous signal detection * Finish previous signal parsing * tying up loose ends * Fix timeline view for multi-agg threshold signals * Fix build_bulk_body tests * test fixes * Add test for threshold bucket filters * Address comments * Fixing schema errors * Remove unnecessary comment * Fix tests * Fix types * linting * linting * Fixes * Handle pre-7.12 threshold format in timeline view * missing null check * adding in follow-up pr * Handle pre-7.12 filters * unnecessary change * Revert "unnecessary change" This reverts commit 3edc7f2. * linting * Fix rule schemas * Fix tests Co-authored-by: Marshall Main <[email protected]> Co-authored-by: Marshall Main <[email protected]>
💚 Build SucceededMetrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
… Rules (#522) This is a rough pass at updating the [Create Rule API docs](https://www.elastic.co/guide/en/security/current/rules-api-create.html#_request_body) for the recent changes surrounding `Threshold` and `Indicator Match` rules. @madirey and @rylnd if you could verify these changes and if any additional fields should be documented that would be greatly appreciated. 🙂 Resolves: elastic/kibana#91965 Note: The grouping of optional fields per rule type makes these docs difficult to maintain (for me at least 😅), as you need to cross reference each optional field from each type, plus I'd bargain our users might find it useful to be able to look at all fields per each rule type independently. Something to verify with users/discuss, but would be a nice add for maintaining these docs (outside of writing scripts to generate the groupings). ##### Threshold Rules: For more details on `cardinality_field` and `cardinality_value` see: elastic/kibana#90826 ##### Indicator Match Rules: For more details on `threat_filters` see: elastic/kibana#91260
… Rules (elastic#522) This is a rough pass at updating the [Create Rule API docs](https://www.elastic.co/guide/en/security/current/rules-api-create.html#_request_body) for the recent changes surrounding `Threshold` and `Indicator Match` rules. @madirey and @rylnd if you could verify these changes and if any additional fields should be documented that would be greatly appreciated. 🙂 Resolves: elastic/kibana#91965 Note: The grouping of optional fields per rule type makes these docs difficult to maintain (for me at least 😅), as you need to cross reference each optional field from each type, plus I'd bargain our users might find it useful to be able to look at all fields per each rule type independently. Something to verify with users/discuss, but would be a nice add for maintaining these docs (outside of writing scripts to generate the groupings). ##### Threshold Rules: For more details on `cardinality_field` and `cardinality_value` see: elastic/kibana#90826 ##### Indicator Match Rules: For more details on `threat_filters` see: elastic/kibana#91260
… Rules (elastic#522) This is a rough pass at updating the [Create Rule API docs](https://www.elastic.co/guide/en/security/current/rules-api-create.html#_request_body) for the recent changes surrounding `Threshold` and `Indicator Match` rules. @madirey and @rylnd if you could verify these changes and if any additional fields should be documented that would be greatly appreciated. 🙂 Resolves: elastic/kibana#91965 Note: The grouping of optional fields per rule type makes these docs difficult to maintain (for me at least 😅), as you need to cross reference each optional field from each type, plus I'd bargain our users might find it useful to be able to look at all fields per each rule type independently. Something to verify with users/discuss, but would be a nice add for maintaining these docs (outside of writing scripts to generate the groupings). ##### Threshold Rules: For more details on `cardinality_field` and `cardinality_value` see: elastic/kibana#90826 ##### Indicator Match Rules: For more details on `threat_filters` see: elastic/kibana#91260
… Rules (#522) (#540) This is a rough pass at updating the [Create Rule API docs](https://www.elastic.co/guide/en/security/current/rules-api-create.html#_request_body) for the recent changes surrounding `Threshold` and `Indicator Match` rules. @madirey and @rylnd if you could verify these changes and if any additional fields should be documented that would be greatly appreciated. 🙂 Resolves: elastic/kibana#91965 Note: The grouping of optional fields per rule type makes these docs difficult to maintain (for me at least 😅), as you need to cross reference each optional field from each type, plus I'd bargain our users might find it useful to be able to look at all fields per each rule type independently. Something to verify with users/discuss, but would be a nice add for maintaining these docs (outside of writing scripts to generate the groupings). ##### Threshold Rules: For more details on `cardinality_field` and `cardinality_value` see: elastic/kibana#90826 ##### Indicator Match Rules: For more details on `threat_filters` see: elastic/kibana#91260
… Rules (#522) (#539) This is a rough pass at updating the [Create Rule API docs](https://www.elastic.co/guide/en/security/current/rules-api-create.html#_request_body) for the recent changes surrounding `Threshold` and `Indicator Match` rules. @madirey and @rylnd if you could verify these changes and if any additional fields should be documented that would be greatly appreciated. 🙂 Resolves: elastic/kibana#91965 Note: The grouping of optional fields per rule type makes these docs difficult to maintain (for me at least 😅), as you need to cross reference each optional field from each type, plus I'd bargain our users might find it useful to be able to look at all fields per each rule type independently. Something to verify with users/discuss, but would be a nice add for maintaining these docs (outside of writing scripts to generate the groupings). ##### Threshold Rules: For more details on `cardinality_field` and `cardinality_value` see: elastic/kibana#90826 ##### Indicator Match Rules: For more details on `threat_filters` see: elastic/kibana#91260
Summary
This PR adds support for multiple
terms
aggregations within a Threshold Rule, as well as an additionalcardinality
aggregation for matching a specific number of unique values across a field.Pre-existing signals from 7.11.x are handled without a migration by converting the existing document to a 7.12-conforming document DE-side and client-side before evaluating.
TODO:
Add migration forthreshold
andthreshold_result
or handle pre-7.12 schema separatelyChecklist
Delete any items that are not applicable to this PR.
For maintainers