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.
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] Handle dupes when processing threshold rules #83062
[Security Solution][Detections] Handle dupes when processing threshold rules #83062
Changes from 40 commits
7ac4f7d
fba2636
352a139
0c9d5e3
2f61b30
56e558a
4610643
3fa0e69
0c3c1e7
35e2119
29641b6
5914e99
26c7c0d
7bbd12a
399d886
960ed9b
8591886
a90af11
bf910ab
2396190
83f81cb
3052975
8d6c81d
a087823
2e424f1
c898480
925acc7
ae24022
2c8dcfa
8a7c84a
49044a6
974a5a3
23e4ec3
2bc904f
1e8d122
3a54495
e5f2593
80a582a
fe956ad
2c61c26
a855a19
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Does this merit a comment about preventing the "meta signals pollution"? Or should we make this more implicit by moving this into a simple filtering function, for now?
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 is really about persisting values that belong to the signal before the the
signal
object has been created yet. I like the idea of using a filter, or even maybe architecting this a little differently so that the signal fields can be merged into thesignal
object, rather than having this function create thesignal
object. Will look at this in a follow-up PR.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.
My understanding is that these "temporary" fields (
@timestamp
,threshold_result
) are not intended to be persisted in this format to the final signal, but instead are used to pass context from the query to the signal generation. Had you considered making this process more explicit by nesting these fields in some declarative key likesearchContext
?This seems indicative of some broader architectural issues:
getThresholdSignalQueryFields
seems analogous toadditionalSignalFields
except that it exists at a different level, but I could absolutely see it being moved up asadditionalSourceFields
and similarly taking from_source.searchContext
.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.
I know this isn't new code so definitely a NIT on the above; just curious what your thoughts are here.
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.
So I think I can address this with the signal properties merging code discussed above.
getThresholdSignalQueryFields
is going away, per our discussion last week. Those fields are just copies of the data that can be reconstructed usingsignal.rule.query
andsignal.rule.filter
combined with the "searchContext" contained inthreshold_result
. It may be cumbersome to get them all into onesearchContext
object, but I'll take a look at it. The query and filter already exist in thesignal.rule
section of the signal, whilethreshold_result
belongs to the signal itself (it's computed after the data are aggregated). I think this can be cleaned up a bit though, so I'll see what I can do, and then run it by you. Thanks!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.
Could we move this logic to a function? We've got similar filter-generating functions and this file is already chonky.
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.
Totally!