From dcb5be651235f9f22101195daee35f4c9ef1d77b Mon Sep 17 00:00:00 2001 From: Henri DF Date: Thu, 28 Apr 2016 14:09:35 -0700 Subject: [PATCH] Destroyed Rule outputs (markdown) --- Rule-outputs.md | 45 --------------------------------------------- 1 file changed, 45 deletions(-) delete mode 100644 Rule-outputs.md diff --git a/Rule-outputs.md b/Rule-outputs.md deleted file mode 100644 index 0610641..0000000 --- a/Rule-outputs.md +++ /dev/null @@ -1,45 +0,0 @@ -In the current digwatch output, each rule has an optional associated output specifying what output should be printed. -For example: -``` -read and fd.name contains .so and not so_dirs | Shared object loaded from unexpected place (%evt.time, %evt.type, %proc.name, %fd.name) -``` -​ -It is easy to foresee a need for more flexibilty in specifying outputs - not just _what_ is output, but where and how it goes. -​ -Here are some simple examples: -​ -- associating severities with events, like in syslog (@loris). -- being able to specify which file a given rule's output goes to -- specifying that a rule (or all rules) should be piped into some other tool or transport. For example send out an alert to some REST API. -​ - -Taking things a bit further, we could envision generalized "post-processing" of rule outputs. -This is somewhat similar to what chisels do for a single filter today. -​ -For example, for the rule that "detects .so files loaded outside of a known directory", rather than send an alert at each event, we could pipe these into a script that maintains a list of all the loaded .so's and periodically sends that list out. -​ -Or, for a simple form of suppression/baselining, we could have a script that maintains some state summarizing previously-seen events, and only outputs new ones. -​ -​ -Here's a strawman syntax proposal: -​ -``` -​ -// Handled as currently: output interpreted like sysdig -p argument -rule ... | Shared object loaded from unexpected place (%evt.time, %evt.type, %proc.name, %fd.name) -​ -// New: use function call syntax to indicate sending into a Lua function: -rule ... | syslog(evt, WARN, "%evt.time, %evt.type, %proc.name, %fd.name") -rule ... | write_to_file(evt, "filename.txt") -rule ... | send_http(evt, "http://pagerduty.com/rest/alert?id=xyz") -rule ... | suppress_dupes(evt, "fieldname") -​ -``` -​ -​ -The API available to these Lua functions is a subset of the existing Lua Chisel API (maybe with some minor additions/changes). For sure, it will need `chisel.request_field()` and `evt.field()`. - -Taking things _much_ further out, these Lua functions could be given an API allowing them to modify the ruleset on the fly, adding or inserting rules. This enables a broad range of approaches to baselining, learning, and adaptation. - - -