Print count of rules in the scan wizard

[YamatoSecurity]

Before:

? Which set of detection rules would you like to load? ›
❯ 1. Core ( status: test, stable | level: high, critical )
  2. Core+ ( status: test, stable | level: medium, high, critical )
  3. Core++ ( status: experimental, test, stable | level: medium, high, critical )
  4. All alert rules ( status: * | level: low+ )
  5. All event and alert rules ( status: * | level: informational+ )

? Include Emerging Threats rules? (y/n) › yes
? Include Threat Hunting rules? (y/n) › no

After:

? Which set of detection rules would you like to load? ›
❯ 1. Core  ( 500 rules ) ( status: test, stable | level: high, critical )
  2. Core+ ( 800 rules) ( status: test, stable | level: medium, high, critical ) 
  3. Core++ ( 1000 rules ) ( status: experimental, test, stable | level: medium, high, critical ) 
  4. All alert rules ( 2500 rules) ( status: * | level: low+ ) 
  5. All event and alert rules ( 3000 rules ) ( status: * | level: informational+ ) 

? Include Emerging Threats rules? ( 300 rules ) (y/n) › yes
? Include Threat Hunting rules? ( 200 rules ) (y/n) › no

[hitenkoku]

@YamatoSecurity Thanks for your issue.
I have two ideas.

1. rule load and stock by prompt select before prompt output
   • This case rule load is one time, but it use memory to stock rule data before prompt.
2. two times rule load way, first load is executed to count rule by choice before prompt output, second load is executed to load rule with selected prompt rule

• This case File load is two times, but used memory can little differ.

I think better 2 than 1. What do you think?

[YamatoSecurity]

@hitenkoku Thanks for the question! Yes, I think we should prioritize using little memory and it does not take long to load rules especially if the first time just loads things like status, level, etc.. So let's do option 2.

[YamatoSecurity]

One thing that might be tricky with counting the number of rules to include is that they will change depending on what the user selects. For example, if there are rules that are bothnoisy and unsupported and rules that are both not noisy and unsupported then the number of rules the user can include will change depending on whether the user chooses yes or no for Include noisy rules?. This may make the logic for counting a little complex. What do you think?

[hitenkoku]

@YamatoSecurity Thanks for comment. I will implement option 2.
I think that it's better counting noisy and unsupported rules on first rule check.

For example, if there are rules that are bothnoisy and unsupported and rules that are both not noisy and unsupported then the number of rules the user can include will change depending on whether the user chooses yes or no for Include noisy rules?. This may make the logic for counting a little complex. What do you think?

[YamatoSecurity]

Yes, it will be too complicated to try to dynamically count them and probably confuse users.
Let's use the total count for rules based on their characteristics.