Response Talking Points
Picking the appropriate response action(s) can be difficult in certain cases--think about database transactions. If there is a detection-response system in a critical database server, rarely will the right response terminate the database application process(es), since abrupt termination could cause data corruption and other badness. However, it may be relatively safe to terminate an inbound network connection from a client host assuming that any partially completed transactions will be rolled back. Likewise, it may be naive to dump the entire process memory space whenever there is an anomaly, especially if your freaky application uses a gig of ram per process. Such action would probably result in a self-induced DoS pretty quickly. The appropriate solution is to have a number of response actions available, from granular to corse, so the system can be configured to take a measured response specific to the target application or host.
Let's talk more about measured responses. Let us presume that your company has a critical database, and previously it was calculated that every hour of downtime costs the business one million dollars. That works out to $278 per second of downtime. Ouch. What attacks against that database system, if successful, would cost your company more than the cost of making it unaccessible ($278 per second)? Probably not many. But if that system is compromised by a worm or even a human attacker, you would want to know about it right away and know how it was compromised. You would want an alert, and you would want that alert to contain all the necessary data for a someone to figure out what is broken and needs to be fixed. This is a subtle but important difference between signature-based and anomaly-based detection systems.