Jon Watkins

Building Windows to Evaluate 'Key' Stats in Real-time Rules

Discussion created by Jon Watkins Employee on Jun 10, 2016

Overview of the rule concept we discussed in the CAB call 6/9/16.  Any question on the concept, please post.  Two-part rule builds a 10 minute window in which to evaluate a spike in the aggregate WTD value ip.uniq('user').  Possible use cases and other related notes posted at end.


Rule 1: Start the timer and select window (in this case 10 minutes).  Capture number of unique users for IP as the register value.




Rule 2: Compare difference of register value with current value of ip.uniq(‘user’).  Set your alert threshold (>3, in example).  Add a dedupe register.



Usage notes:


  • Great method to quickly pick up IPs engaged in pw guessing, credential checking, account peeking.


  • Solid high risk factor around high-risk URLs.  ie, let me know when a 3rd user hits a transfer page from same IP within 30 minutes.  Or, same thing, but over 48 hours and maybe more users.


  • Same principle applies to any other stat generated by keys.  These keys can simply be used in the trigger condition, but remember the difference—using them in trigger condition only you don’t have the ability to see abrupt changes in ‘windows’ of time.  Examples:


    • bankaccount.uniq(‘user’)
      • This assumes a bankaccount key has been added to schema, with user as a ‘value’. 
    • user.uniq(‘bankaccount’)
      • Assume bankaccount has been added as a value under the user key
    • page.hits(‘total’)
      • Works out of the box
    • ip.hits(‘total’)
      • Works out of the box


  • It may be that registers are set on the second rule to track something additional downstream.  For instance, by setting a register in rule #2, I now have an IP with an important additional risk factor that is necessary for detecting activity xyz in a rule #3.