Ability to hide detections from plain sight

[fr0stysh4ke]

Searching through the detection module when rules are imported and enabled which will cause the famous rule mismatch error because the rule is broken and needs to be disabled to get the elasticalert, suricata, or strelka to show okay. Also having ability to hide rules that you don't want to see helps to manage the detection module to be clean. I was thinking of this as a analyst perspective that works in a small or large corporation maybe a home user, or that you have mainly juniors or who ever is new on site shouldn't have to search through disabled alerts to find specific rules to disable them, especially if they are custom rules, I know some companies will duplicate the current rules and enabled them instead or if the analyst has no idea what they are looking for especially if they have a different title then the alert name in the alert module. If the modules were synced with new rules, the new analyst or who ever is on shift may do a mass enable on them and which will re-enable all of the alerts and the alerts was supposed to be disabled will have be re-disabled and removing them from the detection page.

[dougburks]

I'm not sure I understand what you're asking. Have you tried clicking the query bar and selecting All Detections - Enabled? This should hide any disabled detections.

For more information, please see:
https://docs.securityonion.net/en/2.4/detections.html#query-bar

[fr0stysh4ke]

I apologize if I wasn't clear earlier. What I meant to ask about is the ability to hide certain rules. For example, let's say there are rule mismatches for detections we’ve determined to be bad and should remain disabled because their detection status will never show "Okay."

If tools like Suricata, Strelka, or ElastAlert receive updates, those detections will show as "false" because they aren’t enabled yet. Now, imagine an analyst notices the update, clicks the checkbox, and selects "Enable All Detections." This action will enable all detections, even the ones that are supposed to stay disabled.

This creates a problem: rules that should remain disabled get re-enabled. Then, we have to dig through everything and manually re-disable the rules that should have stayed off.

For context, we currently have rules being vetted. The dropdown only shows "All Detections," whether they are enabled or disabled. What we’re looking for is a way to prevent analysts from re-enabling specific rules—something like a "Hidden Detections" category, this should also apply to custom rules, and have a custom filter just like "All Detections" have it say "All Custom Detections -Enabled/Disabled"

This would save time by ensuring analysts don’t have to manually cross-check detections with a spreadsheet or apply multiple filters to identify what needs to stay disabled. We did check the documentation first before posting this idea/feature

I hope this explanation is clearer now. Again, I apologize for any confusion earlier. By the way, SO team is amazing

[defensivedepth]

For example, let's say there are rule mismatches for detections we’ve determined to be bad and should remain disabled because their detection status will never show "Okay."

Can you elaborate? Rule mismatches are an error state that lets you know that the status of the rule doesnt match the production status ie it is enabled, but the rule is not actually running in production for some reason.

[fr0stysh4ke]

Hello,

Of Course
problemchild.log




.

.

We are currently investigating an issue with Strelka related to a rule mismatch. Additionally, we’ve observed mismatches in some Suricata rules, although these are no longer documented in the detection module. For instance, the Emerging Threat Suricata rule no longer shows in the detection module

However, locating or identifying mismatched rules has been challenging as they seem to disappear from the detection page, Even tho it has been documented in the logs.(Yes, tg files do get unzipped and looked at)

One notable example is the Cobalt Strike YARA rule, which is not appearing on the detection page, alongside a few others this is the rule mismatch for Strelka as of currently. Additionally, the malware load driver, which was vetted and disabled earlier, seems to have vanished from the repository altogether with error code of 500. This suggests there may be an issue with the pipeline between the GitHub repository and how rules are imported into SO.

We’ve also noticed that once mismatched rules are resolved, the detections page populates as expected. This indicates that default/custom rules are being implemented properly, with the exception of rules like the Cobalt Strike YARA rule, which is sourced externally from Yarafy by Abuse.ch.