[Rule Tuning] Suspicious File Changes Activity Detected

[BenB196]

Link to rule

https://github.com/elastic/detection-rules/blob/e938ed28a046e0f85c63ac1c9592d472b6078e6c/rules/linux/impact_potential_linux_ransomware_file_encryption.toml#L21

Description

In a large deployment, this rule never seems to complete successfully.

I believe the issue is a cardinality one, as:

https://github.com/elastic/detection-rules/blob/e938ed28a046e0f85c63ac1c9592d472b6078e6c/rules/linux/impact_potential_linux_ransomware_file_encryption.toml#L28

Seems extremely expensive.

Example Data

[Aegrah]

Hi @BenB196! Good catch. I changed the query in this tuning PR. The sequence by process.entity_id is one of the most efficient/effective sequencing methods that we have, so changing this would most likely reduce the efficiency of the rule.

Instead, I chose to include a whitelist of processes and suspicious process executable locations, rather than using a blacklist tuning approach. This will not only increase the performance by a lot, but also decrease FPs in the process. In my testing stack, this query only requires about 25% of the time to run in comparison to the original rule. See the [tuning 2] rule.

Would you mind giving this a try in your environment to see whether this tuning will suffice?

Thanks for the suggestions, they are much appreciated!

[BenB196]

Hi @Aegrah, thanks, I went ahead and tested the tuned rule, and am now seeing this rule complete in a much more reasonable time ~9 seconds per run.

[Aegrah]

@BenB196 Perfect, I'm glad to hear about that. When the PR mentioned above is merged, this issue will automatically be closed.

I was wondering, how many docs are you querying in your environment on average? Just for reference.