-
Notifications
You must be signed in to change notification settings - Fork 392
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
[ProblemChild] Security Detection Rules Don't Allow for Wildcard Whitelisting #7579
[ProblemChild] Security Detection Rules Don't Allow for Wildcard Whitelisting #7579
Conversation
…om/MakoWish/integrations into problem_child_convert_rules_to_eql
…om/MakoWish/integrations into problem_child_convert_rules_to_eql
…om/MakoWish/integrations into problem_child_convert_rules_to_eql
…om/MakoWish/integrations into problem_child_convert_rules_to_eql
…om/MakoWish/integrations into problem_child_convert_rules_to_eql
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.
No specific ML changes here, but LGTM for CODEOWNERS approval.
packages/problemchild/kibana/security_rule/34184d4e-ef61-477b-8d76-5c93448c29bf.json
Show resolved
Hide resolved
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.
Will merge tomorrow if things are good
packages/problemchild/kibana/security_rule/34184d4e-ef61-477b-8d76-5c93448c29bf.json
Show resolved
Hide resolved
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'd suggest tackling known FPs earlier in the pipeline, rather than in rules which are the last step. Provided some options below.
packages/problemchild/kibana/security_rule/34184d4e-ef61-477b-8d76-5c93448c29bf.json
Show resolved
Hide resolved
We wouldn't want a As for using the existing conditional on the I think the only way to do it would be a painless script to check for one of the exceptions and add an ephemeral field/value like In any case, it might be quite an extra load on the ingest nodes for just trying to clean up a few dozen alerts. If the exceptions are done on the Detection Rule, we are only running a wildcard on events that already matched the ProblemChild criteria. If we were to check the arguments in the Ingest Pipeline as suggested, that would be running an expensive iterative regex on every argument in every event we are checking. In our environment, that would be ~250 billion events every 24 hours ( |
@MakoWish All fair points! In that case yeah let's tackle this at the rule level, and if you have identified patterns that would be useful outside of your environment as well, feel free to add those as well! |
I cannot think of any others at this time, but if anybody else has any they would like to include on this PR, I can get them added. |
Nothing at the moment! Thanks once again for your contributions! |
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.
Changes LGTM, but let's merge #7618 first and then this one?
I've merged #7618 |
Package problemchild - 1.1.2 containing this change is available at https://epr.elastic.co/search?package=problemchild |
Co-authored-by: Susan <23287722+susan-shu-c@users.noreply.github.com>
Package problemchild - 2.0.0 containing this change is available at https://epr.elastic.co/search?package=problemchild |
Type of change
What does this PR do?
This PR converts the two security detection rules to EQL and adds a couple exceptions for Tenable Nessus processes.
Checklist
changelog.yml
file.manifest.yml
file.Related issues