-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Detections][EQL] EQL rule execution in detection engine #77419
Conversation
Pinging @elastic/endpoint-response (Team:Endpoint Response) |
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.
Thanks for this enhancement @marshallmain! 🚀
Per the demo over zoom with @spong @peluja1012 and @XavierM, this PR LGTM WRT enabling the Investigate in timeline
workflow, which should display (in Timeline) both the 🐢 "shell" detection, and the building block alerts representing the EQL sequences that triggered the shell detection.
More specifically, we validated that when a user clicks the Investigate in timeline
action on a shell alert in Detections
page, we can display both the shell and it's associated building blocks alerts in Timeline with the following (pseudo) query:
_id: id_of_the_shell_detection OR signal.group.id: id_of_the_shell_detection
@elasticmachine merge upstream |
Pinging @elastic/siem (Team:SIEM) |
Testing the field overrides with both edit: Ahh yeah, I see in code now where you worked around the overrides... 🙂 This seems good to me for |
@@ -65,7 +65,7 @@ export const buildRule = ({ | |||
|
|||
const meta = { ...ruleParams.meta, ...riskScoreMeta, ...severityMeta, ...ruleNameMeta }; | |||
|
|||
const rule = pickBy<RulesSchema>((value: unknown) => value != null, { |
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 believe this is the last guard in place to remove any extraneous null
/undefined
's before writing the rule to the signals. In testing everything looks 👌 without (and I believe we've got tests covering this as well), but just want to verify the intent 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.
Yeah converting the entire rule to Partial
makes it harder to deal with when building the rest of the signal document since we need signal.rule.id
later to compute the doc id. My thought is that we should be able to rely on the elasticsearch js library not to convert undefined
fields to null or anything else so ES should never see undefined
fields. Explicit null
fields I think we should handle (usually reject) at the schema level instead of stripping them out later on. Some null
s are making it into the signal document since they're explicit in the rule SO.
I did more testing on this to figure out where the explicit null fields are coming from and we have some mismatches in the types between signalSchema and RuleTypeParams. For example, timestampOverride is schema.nullable(schema.string())
(so string | null
) in signalSchema, but string | undefined
in RuleTypeParams. So what happens when we don't define timestampOverride when creating a rule is it starts as undefined in the request but then the alert plugin validates using signalSchema which coerces the undefined
into null
and stores it in the SO. Then, when we get the rule SO back later to use in the alert executor, timestampOverride is string | null
but RuleTypeParams says it's string | undefined
and we use it as such. When it's null
(which is when we originally sent undefined
as part of rule creation), we end up with signal.rule.timestamp_override: null
in the signal document.
The UI isn't displaying the null
fields which is probably good. I think the best solution is to resolve the schema mismatches so that our undefined
values stay undefined
instead of being coerced into null
.
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.
Thanks for the extra sleuthing here! 🙂 And yeah, that was my worry with regards to the null
's leaking into the signals. ++ to solving this via the schema mismatches to prevent that coercion in the first place.
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.
Checked out, tested locally and LGTM! Great clean code here @marshallmain, and tests to boot! 🙂
Congrats on all your hard work here to realize EQL within the Detection Engine, this is going to be an absolute game changer for our users! 🚀
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]async chunks size
page load bundle size
distributable file count
History
To update your PR or re-run it, just comment with: |
@spong yeah I was so focused on sequences the single event case was kind of an afterthought 😆 I'll add the overrides for those in the next PR if it's not a blocker here |
* First draft of EQL rules in detection engine * Reorganize functions to separate files * Start adding eventCategoryOverride option for EQL rules * Add building block alerts for each event within sequence * Use eql instead of eql_query for rule type * Remove unused imports * Fix tests * Add basic tests for buildEqlSearchRequest * Add rulesSchema tests for eql * Add buildSignalFromSequence test * Add threat rule fields to buildRuleWithoutOverrides * Fix buildSignalFromSequence typecheck error * Add more tests * Add tests for wrapBuildingBlock and generateSignalId * Use isEqlRule function and fix import error * delete frank * Move sequence interface to types.ts * Fix import * Remove EQL execution placeholder, add back language to eql rule type * allow no indices for eql search * Fix unit tests for language update * Fix buildEqlSearchRequest tests * Replace signal.child with signal.group * remove unused import * Move sequence signal group building to separate testable function * Unbork the merge conflict resolution Co-authored-by: Elastic Machine <[email protected]>
…8550) * First draft of EQL rules in detection engine * Reorganize functions to separate files * Start adding eventCategoryOverride option for EQL rules * Add building block alerts for each event within sequence * Use eql instead of eql_query for rule type * Remove unused imports * Fix tests * Add basic tests for buildEqlSearchRequest * Add rulesSchema tests for eql * Add buildSignalFromSequence test * Add threat rule fields to buildRuleWithoutOverrides * Fix buildSignalFromSequence typecheck error * Add more tests * Add tests for wrapBuildingBlock and generateSignalId * Use isEqlRule function and fix import error * delete frank * Move sequence interface to types.ts * Fix import * Remove EQL execution placeholder, add back language to eql rule type * allow no indices for eql search * Fix unit tests for language update * Fix buildEqlSearchRequest tests * Replace signal.child with signal.group * remove unused import * Move sequence signal group building to separate testable function * Unbork the merge conflict resolution Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
* master: (226 commits) [Enterprise Search] Added Logic for the Credentials View (elastic#77626) [CSM] Js errors (elastic#77919) Add the @kbn/apm-config-loader package (elastic#77855) [Security Solution] Refactor useSelector (elastic#75297) Implement tagcloud renderer (elastic#77910) [APM] Alerting: Add global option to create all alert types (elastic#78151) [Ingest pipelines] Upload indexed document to test a pipeline (elastic#77939) TypeScript cleanup in visualizations plugin (elastic#78428) Lazy load metric & mardown visualizations (elastic#78391) [Detections][EQL] EQL rule execution in detection engine (elastic#77419) Update tutorial-full-experience.asciidoc (elastic#75836) Update tutorial-define-index.asciidoc (elastic#75754) Add support for runtime field types to mappings editor. (elastic#77420) [Monitoring] Usage collection (elastic#75878) [Docs][Actions] Add docs for Jira and IBM Resilient (elastic#78316) [Security Solution][Resolver] Update @timestamp formatting (elastic#78166) [Security Solution] Fix app layout (elastic#76668) [Security Solution][Resolver] 2 new functions to DAL (elastic#78477) Adds new elasticsearch client to telemetry plugin (elastic#78046) skip flaky suite (elastic#78512) (elastic#78511) (elastic#78510) (elastic#78509) (elastic#78508) (elastic#78507) (elastic#78506) (elastic#78505) (elastic#78504) (elastic#78503) (elastic#78502) (elastic#78501) (elastic#78500) ...
Pinging @elastic/security-solution (Team: SecuritySolution) |
Summary
Adds backend functionality for EQL rules in detection engine. Now updated to create a building block alert for each event within a sequence as well as an alert for the sequence as a whole. Non-sequence EQL queries work very similarly to KQL detection rules.
Chart of example sequence signal structure updated with building blocks
Work for follow up PRs:
Checklist
Delete any items that are not applicable to this PR.
For maintainers