Wow, was I wrong. Cisco appears to have some bugs to fix in this area. Are you familiar with the contextual data that is included in some alarms? With just the 'produce alert' action enabled, certain inspection engines include something called "contextual data" in the alarm. If you also enabled the 'produce verbose alert' action, the trigger packet is included in the alarm too. the context data appears to always be a subset of the trigger packet, but I don't know how it's size/content is determined. In any event, here's the behavior I observed:

Both 'context data' and 'trigger packet data' are treated as normal event types. So, there is no 'tie' to a specific alarm...if you drop 'trigger packet data' you drop them for all alarms. Worse still it appears that if you drop 'context data', it drops both the 'context data' and the 'trigger packet data' for any alarms that contain 'context data'. I assume (but did not test) that the reverse is also true...if you drop 'trigger packet' events you also drop the 'context type' events if an alarm has both.

The short answer is, don't drop either if you want to see them for any alarms.

I have verified this and it's sadly correct.

I had two drop rules, one with a common IDS alert WITH trigger packet and one rule for another common IDS alert WITHOUT trigger packet.

I inactivated the second drop rule and got an incident with no trigger packet in the session. I then removed "trigger packet" from the first drop rule and the next time I had an incident the trigger packet was included in the session.

What makes this even more insane is if you DON'T drop the trigger packet along with the alert and then run a query, for example on the destination IP, the trigger packets show up in the report.

Another example of how bad this really is: If I created a general rule firing on any RED events the rule sometimes fires with only "orphaned" trigger packets included.

I'd say this must be fixed unless it render the whole idea of rule tuning unusable

/Fredrik