-
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
[RAC][Security Solution] Pull Gap Remediation out of search_after_bulk_create #102104
Conversation
81105cf
to
ba3b2f7
Compare
…executions" This reverts commit ba3b2f7.
ba3b2f7
to
4752688
Compare
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
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.
LGTM, this is an exciting improvement - thanks!
…k_create (elastic#102104) * Modify threshold rules to receive a single date range tuple * Modify threat match rules to receive a single date range tuple * Modify custom query rules to receive a single date range tuple * Fix up tests (partially) * Change log message to indicate single tuple instead of array * Bad test? * Prevent max_signals from being exceeded on threat match rule executions * Revert "Prevent max_signals from being exceeded on threat match rule executions" This reverts commit ba3b2f7. * Modify EQL rules to use date range tuple * Modify ML rules to use date range tuple * Fix ML/EQL tests * Use dateMath to parse moments in ML/Threshold tests * Add mocks for threshold test * Use dateMath for eql tests
Friendly reminder: Looks like this PR hasn’t been backported yet. |
…k_create (elastic#102104) * Modify threshold rules to receive a single date range tuple * Modify threat match rules to receive a single date range tuple * Modify custom query rules to receive a single date range tuple * Fix up tests (partially) * Change log message to indicate single tuple instead of array * Bad test? * Prevent max_signals from being exceeded on threat match rule executions * Revert "Prevent max_signals from being exceeded on threat match rule executions" This reverts commit ba3b2f7. * Modify EQL rules to use date range tuple * Modify ML rules to use date range tuple * Fix ML/EQL tests * Use dateMath to parse moments in ML/Threshold tests * Add mocks for threshold test * Use dateMath for eql tests
…k_create (#102104) (#102739) * Modify threshold rules to receive a single date range tuple * Modify threat match rules to receive a single date range tuple * Modify custom query rules to receive a single date range tuple * Fix up tests (partially) * Change log message to indicate single tuple instead of array * Bad test? * Prevent max_signals from being exceeded on threat match rule executions * Revert "Prevent max_signals from being exceeded on threat match rule executions" This reverts commit ba3b2f7. * Modify EQL rules to use date range tuple * Modify ML rules to use date range tuple * Fix ML/EQL tests * Use dateMath to parse moments in ML/Threshold tests * Add mocks for threshold test * Use dateMath for eql tests
}, | ||
references: [], | ||
}; | ||
const tuple = { | ||
from: dateMath.parse(params.from)!, | ||
to: dateMath.parse(params.to)!, |
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 is merged but instead of turning off the checks here can we do a small follow up where we do this similar pattern here that @marshallmain did a while back?
I think that would be good to intentionally throw if for some reason these aren't parseable rather than turning off the typescript check for it.
Later if refactoring or mistakes are made and we get an SDH or issue it would be easier to track down where and what happened from a custom error message than somewhere else where the from and to have become null/undefined.
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.
@FrankHassanabad Is this necessary in test files? Looks like we're only doing this in the test files... the code/test will fail when the check is done here, right? https://github.com/elastic/kibana/blob/master/x-pack/plugins/security_solution/server/lib/detection_engine/signals/search_after_bulk_create.ts#L52-L58
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.
Oh I didn't see it was in a test file. For test files it's optional, I typically still avoid it if I can even in test files, but that's just me probably because I really don't like that TypeScript allows type assertions to be turned off compared to other languages with strict types.
Summary
Fixes #100181 (aside from Threat Match per-timerange bug where maxSignals can be exceeded)
NOTE: This branch includes commits from #101544, which will be removed once that PR is merged.In order to ensure that
maxSignals
is enforced per time-range tuple, avoiding the potential silencing of signals when gap remediation is used, this PR modifiessearchAfterAndBulkCreate
so that it accepts only a single time-range tuple. Accordingly, the logic insignal_rule_alert_type
was modified to loop over the tuples for each rule type and invoke N instances of the executor for N time ranges. This enforcesmaxSignals
for each time range, with the exception of Threat Match rule invocations, which can still generatemaxSignals * M
signals per time range, whereM
is the number of parallel searches performed.To address this, there is an optional commit that adds some synchronization code to(removed in favor of a better solution, to come in a future PR if prioritized) @MikePaquette Is this something we want to fix for 7.14?searchAfterAndBulkCreate
: 81105cfChecklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers