Do you know of any reasoning behind this. Seems odd that you can not remove something you create.

Not really. I was told at one time that it would be in a future release. I assume it has something to do with the difficulties maintaining db integrity when you delete records. Frankly, I think you should be able to.

There is an excellent explanation of the reasoning behind this on page 265 of the recently published book on MARS by Dale Tesch and Greg Abelard. I'll print it here:

"CS-MARS is a SIM (Security Information Manager) that maintains the integrity of the log data for the life of the data. Because theoretically you can archive data for decades, it is important to have the rules that processed the archived data available. If you decide to import archived data into MARS, to maintain the integrity of that data, you should process it under the rule conditions that were available when the data was originally received by MARS. Therefore, you cannot delete the rules; you can only change their states. Many a forensics investigation has been compromised because the original rules were not available to match the data."

Hope that helps.

That sounds lovely from an idealogical standpoint, but it appears to be utter b.s. from a "how csmars works" standpoint. They seem to be implying that dynamic data is re-processed during a pnrestore? I don't think that is the case.

1) log data or "dynamic data" in CSMARS is relatively short lived (3 weeks for us).

2) cases and their related data are part of the CONFIG data, not the dynamic data, and are permanent.

3) the pnrestore command always restores the most recent CONFIG data and can restore dynamic data from some point in the past until the current time.

How exactly would one restore dynamic data into CSMARS that was 1 year old, let alone 10 years? You probably can't, unless you are barely using the CSMARS. The most you can effectively restore is whatever the normal capacity of dynamic data is for you(3 weeks in our case). What you're left with is that CSMARS can't be used at all for old dynamic data. If you want that data, go to the archive and get it yourself (which is what we do).

I would also note that the triggering rule appears to be saved with the case "separately" from any current rules(this separation could happen later when rule is changed, hard to tell). This is necessary because user rules can change over time. Referring to an existing rule that has changed would be Very Bad indeed and certainly result in a "forensics investigation that has been compromised", as if CSMARS has that level of integrity to begin with...512 byte message truncation?;-)

This is a very interesting thread all from a simple question.

I can accept the fact that forensic issues may come into play but the reasoning I have for a desire to be able to remove a drop rule. I need to stress the point this say a drop rule. I have had the current MARS for three weeks as a lab device and have adjusted the IDS devices I have to send all events rather then filter the events at the IDS device it?s self.

There are thousands of ?TCP SYN Host sweep? events along with some other numerous events that are generated by normal internal network behavior. Since the false positive option only allows for the very limited tuning such as the host to any, host to the host or any to host. I found that selecting this and tuning it is a fast way to create a drop rule that I can go and edit changing the host of either source and destination to networks or adding individual host.

I ended up creating the same type of drop rule twice or three times for the same signature event but then I consolidated the rules by taking the host and converting into a network in a different rule with the same signature properties. I found that also same host or host in a network will generate the false positive events for a different signature that I can eliminate and consolidate multiple rules by adding that signature to an existing rule.

So rather then having to change the status of a rule that has been created by either the use of duplicate or the false positive tuning. I think one should be able to delete that rule as you are dropping the traffic anyhow.

Warnings maybe needed to alert during deletion of the potential legal aspects but if I decided to delete or change something this is my decision. There is no warning when creating the rule, so why is this restricted when the decision to get rid of the rule is made.