PatternDB and ActionDB comparison

Comparison

Parsing

• simpler pattern file format (JSON over XML)
• simplified pattern definitions:

<rule provider="patterndb" id="5e792010-3f1f-4a54-9ecd-aef38d05184f" class="system">
 <!-- login success --> 
 <patterns>
   <pattern>pam_unix(su:session): session opened for user root by @ESTRING:usracct.username:(@uid=@NUMBER::@)</pattern>
 </patterns>
 <examples>
   <example>
     <test_message program="su">pam_unix(su:session): session opened for user root by phemmer(uid=8129)</test_message>
     <test_values>
       <test_value name="usracct.username">phemmer</test_value>
    </test_values>
   </example>
 </examples>
</rule>

{
 "uuid": "5e792010-3f1f-4a54-9ecd-aef38d05184f",
 "pattern": "pam_unix(su:session): session opened for user root by %{GREEDY:usracct.username}(uid=%{GREEDY})",
 "test_messages": [
   {   
     "message": "pam_unix(su:session): session opened for user root by phemmer(uid=8129)",
     "values": {
       "name": "phemmer"
     }   
   }   
 ]
}

• less parser types
• INT - for integers
• SET - for character sets
• GREEDY - for "context sensitive parsing", like an ESTRING/QSTRING with a big hint of syntactic sugar)
• "subtree parsing": if a "parser node" didn't match ActionDB tries its next sibling. So if there is a possible match in the actual subtree ActionDB walks in the subtree to find the first full match.

Correlation

• simpler pattern file format (JSON over XML)
• correlation context definition is independent from parsing (but parsing is required, we need the uuids)
• messages can be grouped into contexts by their type and specific context-id (a template string)
• a context can be opened by a specific message type
• a context can be closed by meeting one of the following conditions
• number of messages (max-size)
• specific message type
• global timeout on the context
• timeout, which can be renewed by newer messages
• milisec resolution in timeouts
• generated messages can be fed back to the same ActionDB instance - no more layering