Skip to content
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

Support undefined in --exclude-status #1087

Open
YamatoSecurity opened this issue Jun 6, 2023 · 5 comments
Open

Support undefined in --exclude-status #1087

YamatoSecurity opened this issue Jun 6, 2023 · 5 comments
Assignees
Labels
enhancement New feature or request Priority:Low

Comments

@YamatoSecurity
Copy link
Collaborator

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.

@YamatoSecurity YamatoSecurity added enhancement New feature or request Priority:Low labels Jun 6, 2023
@hitenkoku hitenkoku added this to the v2.8.0 milestone Jun 15, 2023
@hitenkoku hitenkoku self-assigned this Jun 20, 2023
@hitenkoku
Copy link
Collaborator

@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
Copy link
Collaborator Author

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
Copy link
Collaborator

@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
Copy link
Collaborator Author

@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
Copy link
Collaborator

hitenkoku commented Jun 24, 2023

I confirmed treatment as "informational" when level is not defined. ref:

hayabusa/src/yaml.rs

Lines 322 to 325 in 5769a75

let doc_level = &yaml_doc["level"]
.as_str()
.unwrap_or("informational")
.to_uppercase();

I confirmed that no filtering by exclude_status when status is undefined.
refs:

hayabusa/src/yaml.rs

Lines 279 to 286 in 5769a75

let status = yaml_doc["status"].as_str();
if let Some(s) = yaml_doc["status"].as_str() {
// excluded status optionで指定されたstatusを除外する
if self.exclude_status.contains(&s.to_string()) {
let entry = self.rule_load_cnt.entry("excluded".into()).or_insert(0);
*entry += 1;
return Option::None;
}

@YamatoSecurity YamatoSecurity modified the milestones: v2.8.0, v2.9.0 Aug 15, 2023
@YamatoSecurity YamatoSecurity modified the milestones: v2.9.0, v2.10.0 Sep 14, 2023
@YamatoSecurity YamatoSecurity modified the milestones: v2.10.0, v2.11.0 Oct 18, 2023
@YamatoSecurity YamatoSecurity modified the milestones: v2.11.0, v2.13.0 Dec 14, 2023
@YamatoSecurity YamatoSecurity modified the milestones: v2.13.0, v2.14.0 Jan 23, 2024
@YamatoSecurity YamatoSecurity removed this from the v2.14.0 milestone Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Priority:Low
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants