"event" signature option.

This question is mostly for Robin, but I thought that others could benefit from seeing the answer.

Why does the "event" signature option work like it does? All it seems to do is give the supplied string to the signature_match event, but you essentially get that same functionality from the signature id that is given to the same event. It seems to me like you'd provide the name of an event handler to the event option which would then be triggered when the signature matches. That event handler would also have to take the same arguments as the signature_match event. It would provide a nice way to skip over the signature->notice support that the signature framework provides since we keep using signatures for things other than direct detection of malicious activity.

Thanks,
  .Seth

Yeah, that would be the right way to do it. The current scheme was
driven by the Snort-to-Bro conversion we were doing back then when
other signatures uses weren't really on the radar.

I'm fine changing that, but perhaps we should then add another keyword
like "notice" that always triggers the signature_match event (or then
perhaps signature_notice). That would make it clear which signatures
are triggering a notice, vs. those which are for other stuff.

The reason for passing the string is mainly convinience: without it,
the script layer would need a mapping id->msg for givubg the user more
context in the notice. I'd keep that with the signature_notice event
if we go that way, but skip for other events.

Robin

  It seems to me like you'd provide the name of an event handler to the
  event option which would then be triggered when the signature
  matches.

I like that idea a lot!

I'm fine changing that, but perhaps we should then add another keyword
like "notice" that always triggers the signature_match event (or then
perhaps signature_notice). That would make it clear which signatures
are triggering a notice, vs. those which are for other stuff.

I think we should then aim for the next release, since it would break current signature files. So it seems appropriate to do something disruptive like this together with all the other disruptive changes.

The reason for passing the string is mainly convinience: without it,
the script layer would need a mapping id->msg for givubg the user more
context in the notice. I'd keep that with the signature_notice event
if we go that way, but skip for other events.

ACK. It's a nice way to "group" signatures together by supplying the same string message to all of them.

just my 2ct
Gregor