EDR: How to Write Ingress Filters to Minimize Performance Costs

Products

• Carbon Black EDR (formerly Cb Response)

Issue/Introduction

Describe how to create and check ingress filters for efficiency.

Environment

• EDR Servers: All Supported Versions

Resolution

1. Create a regex filter.   A regex reference is https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html

For example: rxi | .*AmazingApp.v5.30.*

2. Check the regex filter for accuracy. 

For example, the regex above states case insensitive search for an unlimited amount characters followed by AmazinApp then one character then v5 then another character followed by 30 and then an unlimited number of trailing characters.

3a. Based on collected events, fine-tune 'greedy' regex ".*" by limiting the amount of characters.  This directly affects CPU performance.

For example .{0,10} states find 0 characters OR no more than 10 characters.  Fine-tuned filter: rxi | .{2,8}AmazingApp.v5.30.{0,10}

3b. Check the performance of the initial regex and the fine-tuned regex on https://regex101.com.   Launch the debugger on the right to determine the steps required to complete a match against a 1000+ character string.

4. Test the regex filter to verify only the intended events are filtered.

Additional Information

• If /var/log/cb/nginx/access.log has more HTTP 503s than HTTP 200s and there are multiple ingress filters enabled, determine if there are greedy filters that should be fine-tuned. 
• Events containing command lines with over 1000 characters are becoming more common.  The ingress filter ".*" becomes 0 to strlen(cmdline) which is resource expensive.
• Check the efficiency of the regex filter on https://regex101.com/.  Launch the debugger on the right to determine the number of steps needed to match against a random 1000+ string.  The filter ".*AmazingApp1.7.33.ps1.*" took ~120,000 steps where ".{2,14}AmazingApp1.7.33.ps1.{0,10}" took ~14,000 steps.