Replies: 1 comment
-
Yeah.. that makes sense and is better than the current methods. Things could even be further improved in that not all uses for intel use all types of data. If one updates an intel file that is 100% file hashes, then it still doesn't make sense to run something like intel/seen/smtp-url-extraction.zeek |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In an appliance setting where users can add or remove intel data, a general expectation is that
frameworks/intel/seen
is loaded by default. That is, once intel data is loaded, theintel/seen
functionality is expected to work, too.The immediate solution is loading
frameworks/intel/seen
by default in such setups. However, not all users/deployments are using intel data and loading these scripts comes at the cost of non-negligible event handler overhead even when no intel data is loaded. Current complex solutions involve conditionally loading offrameworks/intel/seen
and triggering Zeek restarts upon intel data additions or removals.One idea for simplification would be to employ module event groups for event handlers in
frameworks/intel/seen
. Assuming these are all placed intomodule Intel::SeenEvents
, the corresponding module event group can be disabled by default and enabled whenever some intel data becomes available on a node in themin_data_store
. When all intel data is removed at runtime, the module event group can be disabled and no extra overhead from the handlers is incurred.@JustinAzoff - you likely remember the case. Wonder if that makes sense to you, too?
Beta Was this translation helpful? Give feedback.
All reactions