Closed YamatoSecurity closed 1 year ago
@YamatoSecurity Unique xxx detections is calculated based on the file path of the rule file and not based on the ID of the rule.
I will try to support aggregation based on the ID of the rule.
@hitenkoku Ah, I see. That makes sense.
In a sense, process_creation
, etc... rules are 2 rules in one so I thought it was better to count the unique detections based on rule path but it might be confusing why they don't match up to the number of unique detections and is treated as a single detection in sigma so it is probably better to count the number of unique detections by rule ID instead of rule path.
I understand. Then the number of elements of All xxx alerts in the html file and the number of elements of Unique detection in the Result Summary will not match, is this a problem?
I think it would be better to leave the html file as it is, since the html file is linked to the link so that it can be viewed.
@hitenkoku Yes, I think the HTML report is to leave as it is now with links to the rule paths. However, it looks like the Results Summary unique detection number is counting by rule path instead of id? If this is true, can you change the Results Summary unique detection number in the HTML to the same as is being displayed to screen now?
@hitenkoku We should also count the following by rule ID instead of path as well:
Excluded rules: 27
Noisy rules: 12 (Disabled)
Deprecated rules: 169 (4.54%) (Disabled)
Experimental rules: 2001 (53.70%)
Stable rules: 230 (6.17%)
Test rules: 1495 (40.12%)
Unsupported rules: 46 (1.23%) (Disabled)
Hayabusa rules: 157
Sigma rules: 3569
Total enabled detection rules: 3726
This is a difficult decision as there will be more rules actually loaded than shown here but most people treat process_creation
rules, etc.. as one rule even though they are looking at two different data sources (Sec 4688 and Sysmon 1) so we should probably display the total based on unique rule IDs.
@YamatoSecurity I have created a separate issue for counting the number of rules because we are using a different logic.
Could I address this issue in a separate pull request? #1113
We should also count the following by rule ID instead of path as well:
Excluded rules: 27 Noisy rules: 12 (Disabled) Deprecated rules: 169 (4.54%) (Disabled) Experimental rules: 2001 (53.70%) Stable rules: 230 (6.17%) Test rules: 1495 (40.12%) Unsupported rules: 46 (1.23%) (Disabled) Hayabusa rules: 157 Sigma rules: 3569 Total enabled detection rules: 3726
This is a difficult decision as there will be more rules actually loaded than shown here but most people treat
process_creation
rules, etc.. as one rule even though they are looking at two different data sources (Sec 4688 and Sysmon 1) so we should probably display the total based on unique rule IDs.
@hitenkoku Making a separate issue is a better idea. Thank you!
@hitenkoku Can you take a look at this?
It seems that the number of unique detections is not correct. How to reproduce:
RuleID: "%RuleID%"
toconfig/default_profile.yaml
./target/release/hayabusa json-timeline -d ../hayabusa-sample-evtx -L -u -D -o hayabusa-sample.jsonl -C -H hayabusa-sample.html
These are my results:
However, when I check the total number of unique rule IDs with:
the result is
605
, not685
.I also checked the HTML report. For example, for critical alerts in the HTML report, there are only
21
unique rules but the Results Summary says there should be23
.I checked the number of total detections, and those seem to be correct.
Total critical alerts is correct:
I also checked in the same way the total detections for high, med, low, info and all are correct.