We noticed a while ago that SIEM will sometimes randomly disable vital Correlation rules and Alarms. I have given up trying to figure out why (McAfee magic...), but audit caught this so now we are required to provide monthly evidence that all rules are enabled.
I am trying to do this programatically but there doesn't seem to be an API enpoint for pulling Correlation rule/Alarm configs, specifically I need to check if these are enabled.
Does anyone have any experience or suggestions here. Thanks!!!!
Past in the URL This Path - https://Your SIEM IP/rs/esm/help
There you will see all the available commands for API,
Regarding Correlation, I found just 3 Commands
Get a list of all event correlations.
Get the source events and flows for a given correlated event ID
Return Esm Correlation Trigger Info
Thanks for the response, put I am sepecifically looking for Correlation configurations. I am familiar with and have been using the API, so I have already looked through that documentation.
I am starting to get the sense that this functionality, like most other things I would like to do in ESM, does not exist.
I have seen this happen on SIEMs as well. I'm no so sure it's "McAfee Magic" or some policy change that ended up having unintended consequences. Much of the configuration items in the SIEM are very dependent on each other, often with larger groups working on SIEMs these dependencies become oversights.
My thinking is you are looking for a quick "sanity" check, which I have done in the past. The solution is to build a "zone" for sending spoofed data to, in this zone you would configure one of each of your data source types in your environment, create a list of packets that will trigger all of your correlation rules once. Then send these on a daily/weekly/hourly basis. A deviation rule on the number of triggered alarms in this zone would indicate there is a problem, which can then send an email.
That is very Interesting solution - It would theoretically work. However, the issue is that I have well over 100 custom correlation rules that need to be verified and creating a trigger for every rule seems incredibly tedious and time cosuming. Not sure that this would actually save any time.
The solution is very similar to unit testing and the continuous integration testing that comes with software development. As with software development, it does take time to go back and write all of the test, however if the work is done upfront with each correlation rule, it is far easier. When building a correlation rule you often have the X packets you need to fire the rule in front of you while you are making it.