Yamato-Security / hayabusa

Hayabusa (隼) is a sigma-based threat hunting and fast forensics timeline generator for Windows event logs.
GNU General Public License v3.0
2.17k stars 189 forks source link

Support `undefined` in `--exclude-status` #1087

Open YamatoSecurity opened 1 year ago

YamatoSecurity commented 1 year ago

Recently, some sigma rules are being uploaded without the level defined so they are undefined rules. However, --exclude-status does not support disabling undefined rules so I would like to support this.

hitenkoku commented 1 year ago

@YamatoSecurity exclude_status is an option to filter by the name of the status (containing the values stable and test) in the rule.

I think it would be better to create a new option to disable reading of undefined levels. (ex. exclude_level)

YamatoSecurity commented 1 year ago

Thanks for letting me know. So use a new option --exclude-undefined instead of --exclude-status undefined ? This would add another option making the options a little longer. Either way is no problem for me but why do you think adding a new option is better than adding a undefined level to the type of levels? Is it easier to implement that way?

hitenkoku commented 1 year ago

@YamatoSecurity Yes, implementation will be easy by using --exclude-undefined.

The implementation can be done either way, but there will be issues due to the need to check multiple fields.

The undefind is the value of the level of the rule, and the exclude_status is the value of the status of the rule that is being targeted by the exclude_status, which is something else.

It is unclear whether the value set in exclude-status is for the status of the rule or for the value of the level of the rule.

For example, if status does not exist and you have taken the value of undefined, you will fall under this filtering even if you do not want to filter by status.

This would add another option making the options a little longer. Either way is no problem for me but why do you think adding a new option is better than adding a undefined level to the type of levels? Is it easier to implement that way?

YamatoSecurity commented 1 year ago

@hitenkoku Ah, I see now. I'm sorry I wrote in the issue that level is sometimes not defined, but I meant to write status. However, sometimes level may also not be defined so I think there are two issues that we have to consider.

  1. When level is not defined and 2. When status is not defined. I agree we shouldn't mix levels and status. Please let me do some testing to see what happens when level and status is not defined and I will try to figure out what we should do. We can talk on Tuesday night at the meeting about this.
hitenkoku commented 1 year ago

I confirmed treatment as "informational" when level is not defined. ref: https://github.com/Yamato-Security/hayabusa/blob/5769a75ea08a588e3bf850d82b0ea3f30e33f0fa/src/yaml.rs#L322-L325

I confirmed that no filtering by exclude_status when status is undefined. refs: https://github.com/Yamato-Security/hayabusa/blob/5769a75ea08a588e3bf850d82b0ea3f30e33f0fa/src/yaml.rs#L279-L286