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][Detections][Threshold Rules] Threshold multiple aggregations with cardinality #90826

Merged
merged 50 commits into from
Feb 18, 2021

Conversation

madirey
Copy link
Contributor

@madirey madirey commented Feb 9, 2021

Summary

This PR adds support for multiple terms aggregations within a Threshold Rule, as well as an additional cardinality 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:

image

image

Checklist

Delete any items that are not applicable to this PR.

For maintainers

Copy link
Contributor

@lykkin lykkin left a 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?:
Copy link
Contributor

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,
},
Copy link
Contributor

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';
Copy link
Contributor

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,
};
});
Copy link
Contributor

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.

@marshallmain
Copy link
Contributor

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.

@madirey madirey enabled auto-merge (squash) February 18, 2021 01:18
@madirey madirey merged commit 5b0e283 into elastic:master Feb 18, 2021
@madirey madirey deleted the threshold-multiple-aggs branch February 18, 2021 04:08
madirey added a commit that referenced this pull request Feb 18, 2021
…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]>
@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
securitySolution 7.7MB 7.7MB +5.7KB

Page load bundle

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

id before after diff
securitySolution 238.5KB 239.3KB +790.0B

History

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

spong added a commit to elastic/security-docs that referenced this pull request Mar 9, 2021
… 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
spong added a commit to spong/security-docs that referenced this pull request Mar 9, 2021
… 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
spong added a commit to spong/security-docs that referenced this pull request Mar 9, 2021
… 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
spong added a commit to elastic/security-docs that referenced this pull request Mar 9, 2021
… 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
spong added a commit to elastic/security-docs that referenced this pull request Mar 9, 2021
… 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Feature:Detection Alerts Security Solution Detection Alerts Feature release_note:enhancement Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v7.12.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants