Recently I met a friend of mine, who is responsible for a fairly large production network with well-founded high security requirements. One of the interesting aspects of his work was the plan to actually remove some of the security devices and appliances deployed. Removing, you ask? Yes!
The driving force for looking at the effectiveness of their network security was of course money, namely the money needed to operate and maintain it. When this network was built, a great deal was spent on the security of it, much like many people in the industry and all security appliance vendors recommend. But when looking at the cost years later, they decided to grab available data and see what type and how many actual attacks happened since the deployment of all the firewalls, IDS sensors and whatnot. The result: very little. So they get rid of some.
On the other hand, think about the security devices as targets and not protections for a minute.
Take a fairly simple protocol, such as HTTP. A web server only needs to implement the functionality of this one clear text protocol correctly and will be fine. Now, how many major web servers do you know that didn't have a HTTP parsing vulnerability in the past? But the parsing of a HTTP request is implemented in a fairly small share of the web server's code base, because it also has to deal with things like MIME types, virtualization of path information, finding and opening files and other stuff.
Compare this to an network intrusion detection system (NIDS) sensor. It needs to do the same thing, namely implement protocol parsing correctly, but for 100 some times complex protocols (the number is from ISS's Proventia). Also, the protocol inspection is it's job, so the lion share of binary code executed is actually attackable surface. In the past, people used TAPs (RX-only network connection) and stated that this prevents attackers from breaking into the NIDS sensors, because they would be unable to communicate with it. Did anybody ever evaluate a fully deployed NIDS under the assumption of one sensor running non-interactive attacker code? I think a not too complex multi-stage shellcode (the term is a bit misleading here) should be able to exploit the central NIDS management server from the implicitly trusted NIDS sensor and phone home from there. Stuff like this has been done before.
Today, everyone deploys inline network IPS. eEye showed nicely [1, 2] what it means to deploy something with such a large attack surface in the middle of your communication stream: namely, your IPS gets owned first and used as a very convenient jump point into the management network. I also vividly remember when K2 presented at DefCon 9 on polymorphic shellcode  and the ISS sensor, which was supposed to just not notice the exploit, crashed in front of the audience while parsing the modified exploit. And please don't think this is about ISS's products, this is a general issue.
On the organizational side of larger IT operations, the same or related teams usually manage the firewall and NIDS rules. In practice, this means the firewall will have a rule saying "block port 99" and the NIDS will have a rule saying, "alert on internal port 99 traffic". So you have two types of NIDS sensors deployed, the ones on the outside producing several thousand alarms per minute and the ones on the inside reporting traffic violations and P2P leech. Is this worth thousands of bucks per month operational cost?
But the only actual reason many organizations have these devices is for forensics, since nobody is watching them in real time anyway. If I were to be called into a case where systems are owned using 0day, I would much prefer a full packet dump covering the last 30 days instead of a selection of may-be-accurate information the IDS has for the same time period. Running a full packet log with a rotation of 30 days is going to cost you very little. A common 100 GB hard drive will be easily able to handle a day worth of traffic and one can reproduce the entire day completely without a semi-intelligent piece of hot needle software pre-filtering the data.
Again, the very old recommendation to keep things simple and stupid holds ground. If your deployed software does not act on input such as network traffic, the same can be as malformed as it wishes to be. I wonder how many IDS sensors choke on HTTP chunked encoding reassembly when the "protected" web server behind it does not even support this transfer method.
Consider throwing away at least parts of your IDS and reinvesting the saved money and staff time into their education. Even a little talented network security person will be able to use additional knowledge more intelligently than any of your alert filtering software solutions. And, you don't have to script them: they are voice controllable.