# "event" signature option. **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [August 18, 2011, 2:43pm UTC](https://community.zeek.org/t/event-signature-option/1994 "2011-08-18T14:43:50Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [August 18, 2011, 2:43pm UTC](https://community.zeek.org/t/event-signature-option/1994/1 "2011-08-18T14:43:50Z")
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 ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [August 18, 2011, 3:12pm UTC](https://community.zeek.org/t/event-signature-option/1994/2 "2011-08-18T15:12:25Z")
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 ---
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [August 18, 2011, 5:34pm UTC](https://community.zeek.org/t/event-signature-option/1994/3 "2011-08-18T17:34:21Z")
> >   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 ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:39pm UTC](https://community.zeek.org/t/event-signature-option/1994/4 "2022-05-06T15:39:47Z")