-
Notifications
You must be signed in to change notification settings - Fork 528
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
[D4C Conversion] Converting Compatible D4C Rules to DR #4532
base: main
Are you sure you want to change the base?
Conversation
Rule: Tuning - GuidelinesThese guidelines serve as a reminder set of considerations when tuning an existing rule. Documentation and Context
Rule Metadata Checks
Testing and Validation
|
⛔️ Tests failed:
|
⛔️ Tests failed:
|
…tection-rules into convert-d4c-to-defend
⛔️ Tests failed:
|
⛔️ Tests failed:
|
@Aegrah would push this as BBRs first make sense? Adoption of the endpoint is higher than what we had with D4C, so we can make sure we are not pushing additional noise, while we validate how reliable the fields we didn't use in other rules yet are |
@w0rk3r I have nothing against moving them to BBR first for a cycle. However, based on the telem available currently, I think none of these rules will be prone to large bulks of FPs. I don't think it's necessary, but at the same time, if we want to minimize the potential risk of pushing a potentially noisy rule, I can make the change! Any thoughts @imays11? |
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.
Looks great, thank you Ruben! I understand but don't think it's necessary to move them to BBR first.
rules/linux/execution_container_management_binary_launched_inside_container.toml
Outdated
Show resolved
Hide resolved
rules/linux/privilege_escalation_debugfs_launched_inside_container.toml
Outdated
Show resolved
Hide resolved
rules/linux/privilege_escalation_debugfs_launched_inside_container.toml
Outdated
Show resolved
Hide resolved
rules/linux/privilege_escalation_mount_launched_inside_container.toml
Outdated
Show resolved
Hide resolved
rules/linux/privilege_escalation_mount_launched_inside_container.toml
Outdated
Show resolved
Hide resolved
…ide_container.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
…iner.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
…iner.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
…er.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
⛔️ Tests failed:
|
…er.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
⛔️ Tests failed:
|
⛔️ Tests failed:
|
⛔️ Tests failed:
|
⛔️ Tests failed:
|
Thanks for the thorough review @imays11. If this one does not get the approvals necessary to merge prior to my PTO, feel free to merge it before the next release @shashank-elastic! |
Summary
This PR converts all compatible D4C rules to DR. Please review the rules carefully, and also the investigation guides. Any references to specific fields that are unavailable in Defend are removed from the investigation guides. However, this was manual work, thus, please review it carefully.
Conversion constraints
process.entry_leader.entry_meta.type == "container"
field, onlyprocess
rules were converted, asfile
andnetwork
events do not contain this field.container.security_context.privileged
field is unavailable, thus, rules relying on privileged container scenarios were converted without this field set totrue
. Given the low-volume occurrences of these events, this should not be an issue.