[Security Solution][Detections][Threshold Rules] Threshold multiple aggregations with cardinality#90826
Conversation
...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
This reverts commit 3edc7f2.
| histogramType: MatrixHistogramType; | ||
| stackByField: string; | ||
| threshold?: { field: string | undefined; value: number } | undefined; | ||
| threshold?: |
There was a problem hiding this comment.
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.
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.
| }; | ||
|
|
||
| const isThresholdResult = (thresholdResult: SearchTypes): thresholdResult is ThresholdResult => { | ||
| return typeof thresholdResult === 'object'; |
There was a problem hiding this comment.
any array will satisfy this check
| field, | ||
| value: result[0].value, | ||
| }; | ||
| }); |
There was a problem hiding this comment.
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 <marshall.main@elastic.co> Co-authored-by: Marshall Main <marshall.main@elastic.co>
💚 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
termsaggregations within a Threshold Rule, as well as an additionalcardinalityaggregation 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 forthresholdandthreshold_resultor handle pre-7.12 schema separatelyChecklist
Delete any items that are not applicable to this PR.
For maintainers