Tuning your IDS ruleset to limit false positive alerts and silence non-applicable rules is a critical part of running any competent IDS security strategy. Despite that fact, we’ve always been surprised at how difficult distributing, maintaining, synchronizing, and tuning an efficient set of rules can be.
More mature security shops have had to solve this problem, so they’ve turned to many of the great community and paid tools that are out there. We have seen sophisticated teams leverage everything from popular configuration management tools such as Puppet or Chef, to relying on bash scripts that utilize rsync or SCP to synchronize rules files and configurations across sensors. At the end of the day, none of these solutions are ideal as they still require manual effort and create a system operations expertise barrier to rules tuning.
Since Threat Stack’s Snorby Cloud architecture allows us to control much of this experience automatically, we set out to create a rules management solution that solved many of the pain points we’ve experienced in our careers.
#1 Messing with configuration files is not fun
Our top requirement was that the entire rules management experience should be contained within the Snorby Interface. Here is what it looks like:
Rules can be enabled or disabled globally directly from this screen by clicking the green label. These changes are sent immediately to the agents and within 60 seconds all agents will be aware that the rule is disabled. Our agent handles all the necessary modifications to the IDS’ configuration files. There is no need to manually edit anything.
If you want fine-tune control, you can click “edit”, and assign that rule to only work with specific agents:
Once confirmed, the rule will show as “mixed” like this in the index view:
#2 Significant manual barriers slow rule disablement
A lot of shops require their analysts to submit email request or physically talk to the IDS operations person when they want to tune out a noisy or worthless rule. Our goal was to allow a user (with the appropriate permissions) to do this daily task directly from the UI.
As you can see in the example above, we have the option of disabling this rule directly from the user interface. What’s important to note here is that we are tuning rules directly from the event that caused us to question the rule’s value.
What if we want more control? Well that brings us to our final point, #3.
#3 Manual rule suppression and thresholding is a nightmare
Again, thresholding or advanced suppression of a rule in is a must-have when you don’t want to just squash a perfectly good rule when it only alerts noisily under certain circumstances.
You can now suppress or threshold rules by pivoting directly from an event:
Once there, you can configure threshold criteria and apply the appropriate scope:
Or configure suppression criteria (also with scoping):
As you can see, previously defined threshold or suppression rules show up as a count in the lower right-hand corner. You can view all other suppression rules and destroy them in the following interface:
This rules management interface is only possible thanks to the end-end control we have in the Threat Stack architecture. Existing customers can leverage this new functionality by running `sudo snorby-cloud-agent upgrade`. New users will have this rules management enabled automatically. This is our first attempt at solving this problem and improvements and additions to the functionality will follow. For example, we plan on allowing our users to leverage this UI to write and maintain their own rulesets, and enable this workflow for our HIDS rules.
We also have some exciting rules partnership announcements on the horizon, so stay tuned!