shashank-elastic
commented
1 year ago FYI - @DefSecSentinel @Aegrah @imays11
Closed shashank-elastic closed 1 year ago
shashank-elastic
commented
1 year ago FYI - @DefSecSentinel @Aegrah @imays11
Aegrah
commented
1 year ago The following rules have been created in either 8.8 or 8.9, and require a first round of tuning. Rules that are checked and have no executions yet will be moved to next release.
| Rule | Checked | Status | Comment |
|---|---|---|---|
| credential_access_credential_dumping | Yes | Skipped | No Alerts |
| credential_access_potential_linux_ssh_bruteforce_external | Yes | Good | Noisy by design |
| credential_access_potential_linux_ssh_bruteforce_internal | Yes | Good | Since redesign only TPs |
| credential_access_proc_credential_dumping | Yes | Skipped | No Alerts |
| defense_evasion_esxi_suspicious_timestomp_touch | Yes | Skipped | No Alerts |
| defense_evasion_mount_execution | Yes | Skipped | No Alerts |
| defense_evasion_potential_proot_exploits | Yes | Skipped | No Alerts |
| defense_evasion_rename_esxi_files | Yes | Skipped | No Alerts |
| defense_evasion_rename_esxi_index_file | Yes | Skipped | No Alerts |
| discovery_esxi_software_via_find | Yes | Skipped | No Alerts |
| discovery_esxi_software_via_grep | Yes | Good | 1 TP and 7779 alerts originating from one cluster and back up tool parent process --> best to exclude on per environment basis |
| execution_suspicious_mining_process_creation_events | Yes | Skipped | No Alerts |
| execution_esxi_process_kill | Yes | Skipped | No Alerts |
| impact_potential_linux_ransomware_file_encryption | Yes | Tuned | Added whitelisting for commonly abused file paths, black listing for commonly used file extensions and increased with runs https://github.com/elastic/detection-rules/pull/2859 |
| impact_potential_linux_ransomware_note_detected | Yes | Tuned | Added whitelisting for commonly abused file paths, black listing for commonly used file extensions and increased with runs https://github.com/elastic/detection-rules/pull/2859 |
| persistence_cron_job_creation | Yes | Skipped | No Alerts |
| persistence_init_d_file_creation | Yes | Good | 40 hits --> 18/40 from 1 service in 1 unique cluster. Several TPs (mostly testing for a demo) --> best to exclude on per environment basis (writing an exclusion here would not only decrease FP but also TP) |
| persistence_linux_shell_activity_via_web_server | Checked | Good | 50 hits, out of which 29 TPs. The other 21 FPs originate from 1 process within 1 unique cluster --> best to exclude on per environment basis |
| persistence_message_of_the_day_creation | Checked | Good | 5 hits, 4 FPs from 1 unique cluster using Kaniko Executor, 1 TP from a ransomware demo --> best to exclude on per environment basis |
| persistence_message_of_the_day_execution | Yes | Skipped | No Alerts |
| persistence_rc_script_creation | Yes | Tuned | 12 out of 12 TPs originating from 3 unique clusters, but updated logic using new_terms rule type to increase quality in #2857 |
| persistence_systemd_scheduled_timer_created | Yes | Skipped | No Alerts |
| persistence_systemd_service_creation | Yes | Skipped | No Alerts |
Aegrah
commented
1 year ago The following rules have either been checked and tuned last release and need to be rechecked, or have another reason why a second tuning is required. If the tuning process of last release is successful, many of these rules will not require any additional tuning.
| Rule | Checked | Status | Comment |
|---|---|---|---|
| credential_access_potential_linux_ssh_bruteforce_root | Yes | Deprecated | 2,285,626 hits in two months, noisy by design. Proposal: deprecation (as the same behavior is captured in our default brute force rule) or change to brute force attack followed by successful login (which is also already captured in another rule) https://github.com/elastic/detection-rules/pull/2859 |
| defense_evasion_hidden_shared_object | Yes | Good | 36 hits since last tuning, 33 FPs coming from the unzip of one package in one unique cluster. Other 3 hits are TPs --> best to exclude on per environment basis |
| execution_abnormal_process_id_file_created | Yes | Tuned | Converted rule to new_terms rule until we can use file.size for additional filtering. New rule looks at a combination of unique process.executable and file.path in order to minimize FPs. Made rule Endgame compatible as well https://github.com/elastic/detection-rules/pull/2859 |
| execution_shell_evasion_linux_binary | Yes | Tuned | Went from 1,562,525 hits back to around 1k hits by further specifying shell execution conditions for several GTFObins that generated way too much noise https://github.com/elastic/detection-rules/pull/2859 |
| execution_tc_bpf_filter | Yes | Good | 1 hit which is a TP |
| impact_process_kill_threshold | Yes | Tuned | 31 hits, doesn't require performance tuning. Added process.name and user.name to cardinality fields to allow for more useful telemetry and extra information for the user when analyzing the alert https://github.com/elastic/detection-rules/pull/2859 |
| persistence_etc_file_creation | Yes | Tuned | Removed .swp extension, whitelisted 2 process.executables, fixed description and made rule Endgame compatible https://github.com/elastic/detection-rules/pull/2859 |
| privilege_escalation_shadow_file_read | Yes | Tuned | 21,197 hits, all true /etc/shadow reads --> converted to new_terms rule to look for previously unseen process.command_line values in order to filter noise and made rule Endgame compatible https://github.com/elastic/detection-rules/pull/2859 |
shashank-elastic
commented
1 year ago Community issues have been scoped along with this tuning.The PR will be raised accordingly. FYI @Aegrah
Aegrah
commented
1 year ago I just finished the last tunings for round 1 & 2 of 8.9 tuning, once the community issues have been resolved the sheet can be updated to make sure we are ready for the next release cycle! Could you add a similar overview as I did above? Allows for a good overview we will be able to use next cycle as well. @shashank-elastic
shashank-elastic
commented
1 year ago @Aegrah --> Awesome stuff on tuning.
We have also tackled all the community reported issues and the PR includes the changes. For #2002 we have given a custom query for the user as the evaluation did not warrant a tuning for the original rule. cc @DefSecSentinel
shashank-elastic
commented
1 year ago In the process of updating the Linux Rule Tuining Sheet. identified more tunings and added them to PR. Rules need to be checked From lateral Movement onwards.
shashank-elastic
commented
1 year ago The Linux Tuning Sheet is completely Updated. We have added Tunings for Rules, and also marked Rules for next release follow up. The below Rules have high Bloats and needs one more round of investigation
cc @DefSecSentinel @Aegrah
shashank-elastic
commented
1 year ago Investigation Regarding the below rules have been updated on the Review Sheet.
shashank-elastic
commented
1 year ago Tuning in place for the below rules.
Forking a new issue #2911 to Analyze defense_evasion_file_mod_writable_dir and decoupling that from this PR as this is dev complete
cc @Aegrah @DefSecSentinel
Description
A detailed Analysis of Linux Rule Tunings over the releases has been documented here
The sheet above has been updated using the following structure: Green --> Good. Blue --> Added in previous release and must be checked for the first time. Yellow --> Was tuned last release and has to be checked for the second time. Orange --> Was checked this release, but had either no results because the rule was too new or has to be checked again for a second round. Thus, will have to be checked next release. Gray --> Rule was removed.
Review Rules Guide Lines.
Round 1 Iteration Rule Tunings
Following Rules have to be reviewed for Tuning in 8.9
Previous Release Tuning Checks (Round 2)
The below Rules have been fixed in previous release, they need to re-checked for tuning and updated accordingly.
Similar Issues reported Community
2828
2851
2002
Note : Update the excel sheet according with the tuning details that can help us track for future releases