Making the Move From IDS to IPS

Computerworld - The product life-cycle management project I mentioned in my last article has been quiet as the project management team evaluates everyone's input to the evaluation documentation. I'm taking this opportunity to spin up a project to move from our current intrusion-detection system (IDS) to an intrusion-prevention system (IPS).
I've been contemplating this for a while but have hesitated because once my department places a device inline with other network gear, we become another bump in the wire and have certain responsibilities in regards to network availability.
IDS vs. IPS
As many of you know, an IDS typically sits on a monitoring port, sometimes called a SPAN port (in the Cisco world), and is passive by nature. The IDS device sits in promiscuous mode and listens to the network traffic passing by, and when something abnormal occurs, it sends alerts on the suspicious activity as defined by configured rules.
Take that same IDS sensor and place it inline so that all network traffic must pass through it, and you have an IPS. So basically, an IPS is nothing more than an IDS that has some additional functionality and is positioned in a different place on the network. The rules, signatures, alerts and reporting are typically all the same. Even Snort, the freely available IDS, has its own term, "Snort inline," for what is essentially intrusion prevention.
My reasoning for moving to IPS is pretty straightforward. Only a couple of people report to me, and they are bogged down with projects and daily security activities. I'd like to have a full-time person to monitor the IDS and respond to events, but I can't afford that. Meanwhile, we continue to respond to worms and other suspicious activity after the fact, either placing rules in the firewall or visiting all the affected desktops. And we can't count on our antivirus infrastructure either. One recent worm, W32/PrsKey-A, ran rampant in our network for several days before our antivirus vendor finally produced a signature, and that happened only after we sent the vendor an infected file for evaluation.

As an aside, we were able to do our own evaluation of the worm's code and its impact. Through that evaluation, we were able to determine the files and registry settings that the worm modified, the vector that it used to propagate and the ports it was using to open a back channel. Creating a signature in our IDS would give us the ability to detect the worm's presence, but unless we were willing to generate TCP resets,