Upgrading/Updating SIEM rules

[alaine (alex)]

Good Morning,

I am in the process of migrating a SOC from Splunk to Elastic and am going through some of the growing pains at the moment. This question is in regards to upgrading/updating SIEM rules as we upgrade our elastic cluster.

We have spent a good bit of time selecting rules from the pre-built rules that cover areas "of interest" to us. Once, we selected those rules we have had to go through the tuning process to get them working within our environment alerting at an acceptable level. Basically as soon as we got through that process we had to upgrade the cluster and now we have the option to update our SIEM rules.

We have duplicated all the rules that we are using in our environment so that we can actually alter them. My question is when and if we decide to upgrade the pre-built rules is there any easy way to determine which of the rules that we are using has been altered? If so, should we duplicate the updated rule and then bring over all of the tuning that we have done in our environment on the old version of the rule to the new one? Or, does it make more sense to just update the logic of the rule that we are currently using with the logic that makes up the updated rule?

Right now it isn't so bad as we are only running slightly over 100 detections due to other performance issues we are encountering, but at some point once we figure those problems out we expect to be able to scale our detections up to be running way more detections. I am curious if there is an expeditious way to do this? Otherwise this is kind of a nightmare process especially considering how fast elastic roles out new versions. Obviously, we don't have to update with each upgrade, but this is a crucial part of having a fully functional SIEM (as advertised.....)

Thanks for any thoughts,
Alex

[willemdh]

Hey Alex,

I hope you find the root cause of your performance issues soon. There must be something going on..

About rule management, I have the same issues. As you know I'm running about 700 rules and I'm maintaining those all by myself.

I try to duplicate each builtin rule which need adjustments. I give these duplicated rules a custom tag. The duplicated rules wont get overwritten with updates. I make sure I have daily backups.

Im thinking about a way to get my customised rules and exceptions into some git repo, so I can trace what has changed by who where and so I can revert if necessary.

Managing and tuning the rules is a lot of work, of course depending on the amount of data you are searching.

Looking forward to some quality improvements from Elastic to make managing those rules more easy. What I miss are notification templates, bulk edit functionalities, customizable quick action buttons which can trigger a webhook, better sorting, list management, exception management, ..

Looking forward to other peoples views on your interesting questions.

Willem

[alaine (alex)]

Willem,

Thanks for getting back to me. I have done the same thing as you as far as duplication and tagging. It is weird to me that having a rule activated doesn't tag it automatically as that auto-refresh setting drives me crazy (but that is another rant). We are working on a script now to try and tackle this. I am not sure if we are going to have to select and export manually, but once we get the ndjson file we will run it against the script that will pull out the names of all the rules and bounce those against the list that elastic provides of the updated rules to at least speed up the process of identifying which rules have been affected.

The second issue is going to be the environmentally specific stuff that you mentioned like tuning, which at this point seems very tough. I am afraid that the answer to this question is just going to be more man hours on very menial tasks. It seems like this functionality could be incorporated into the update process though. The other issue being that we have to use duplicated rules rather than the originals.

I kind of understand why they don't want us making changes to the original rules, but it makes it difficult for them to automate these issues away, and I am not sure what kind of access our scripts are going to have to the SIEM. As I am thinking this script through it is growing bigger and bigger, but honestly might be worth it especially considering you have 700 rules to manually go through.

We are utilizing git, but are still working on getting the processes down. I haven't really come up with a good way to link into the security app yet in order to take care of some of the issues that we are discussing here.

Then again I am just rehashing all of the things you mentioned such as notification templates, bulk edit functions, customizable quick action buttons, etc...

I am getting ready to go through the update process relatively soon. I will let you know if there are any valuable lessons learned.

Alex