gistfile1.md

Here's what I was thinking of doing...

{
  // Description of the YARA rules to use. Each key is a group name used in additional_monitoring
  // or in scheduled_queries if you want.
  "yara": {
    "sig_group_1": [ "foo.sig", "bar.sig" ],
    "sig_group_2": [ "baz.sig" ]
  },
  
  // Scheduled queries to be run on a periodic basis. Nothing new here...
  "scheduled_queries": ["select * from yara where path=\"/bin/ls\" and signature_group=\"sig_group_1\""],
  
  // Event based things that will be monitored
  "additional_monitoring": {
    // Paths to watch for filesystem events
    "file_paths": {
      "system_binaries": [ "/usr/bin/%", "/usr/sbin/%" ],
      "tmp": [ "/tmp/%%" ]
    },
    
    // Which of the file_paths above to run through YARA, and which signature groups to use
    "yara": {
      "system_binaries": [ "sig_group_1" ],
      "tmp": [ "sig_group_1", "sig_group_2" ]
    }
  }
}

Here's another way I think it could be done...

{
  // Description of the YARA feature.
  "yara": {
    "signatures": {
      // Each key is an arbitrary group name to give the signatures listed
      "sig_group_1": [ "foo.sig", "bar.sig" ],
      "sig_group_2": [ "baz.sig" ]
    },
    "file_paths": {
      // Each key is a key from file_paths in additional_monitoring
      // The value is a list of signature groups to run when an event fires
      "system_binaries": [ "sig_group_1" ],
      "tmp": [ "sig_group_1", "sig_group_2" ]
    }
  },
  
  // Scheduled queries to be run on a periodic basis. Nothing new here...
  "scheduled_queries": ["select * from yara where path=\"/bin/ls\" and signature_group=\"sig_group_1\""],
  
  // Event based things that will be monitored
  "additional_monitoring": {
    // Paths to watch for filesystem events
    "file_paths": {
      "system_binaries": [ "/usr/bin/%", "/usr/sbin/%" ],
      "tmp": [ "/tmp/%%" ]
    }
  }
}

Now that I've written the second one out I think I like it better because it separates out what to monitor (additional_monitoring) from how to monitor it (yara). If other filesystem event subscribers want to do something there doesn't need to be any changes to "additional_monitoring" to support that.

Ideally the YARA subscriber would get the parsed config data during init() and determine which file paths to monitor (already possible using Config::getFiles() or whatever) and how to monitor by parsing the "yara" key from the config block. This means that additional subscribers don't need to touch core code to get their config block handled.