Use Exceptions in a Regex Policy

Regex policies can include exceptions, which are also regular expressions, but used to exempt objects that would otherwise trigger incidents. You can use exceptions in cases where you are monitoring, for example, customer accounts, but also have one or more test accounts used in testing and training materials.

Example 1

Assume that customer account numbers are of the form: ####-####-#### (where “#” is any digit). To monitor for the presence of such account numbers, you could use this regular expression:

\d{4}-\d{4}-\d{4}

Here \d means any digit, {4} means 4 instances, and - simply means -.

If you use as sample text: “1234-5678-9012, 9999-333-22, 1111-2222-3333, 0000-5454-4343,” (the second sequence is not a valid customer account), your Policy configuration panel would look like this, with the properly-formed account numbers correctly matched:

Now assume that your organization uses customer account numbers beginning with “0000” for testing and training purposes. They are correctly formed (see the third match, above), but they should not trigger incidents because they frequently appear in objects and/or documents stored in your platform, and they are known to be safe – that is, not real customer accounts.

An exception is also a regular expression. However, rather than monitoring the whole scope of the policy, as the “main” regex does, the exception expression tests for matches only within the results returned by the main regex.

In this example, the results consist of three matches: 1234-5678-9012, 1111-2222-3333 and 0000-5454-4343. You might use this regex to match your test accounts: 0000-\d{4}-\d{4} (where “0000” simply matches four repeated zeroes). Enter that expression as an Exception, and the Policy panel looks like this:

Example 2

This example is simply an exercise to experiment with how the regex exceptions system works.
First enter the following main regex, which will find the word “purple” followed by any other word:

(?i)purple\s\S*\b

Here (?i) means ignore case, \s means any single whitespace character, \S* means any number of non-whitespace characters, and \b means a boundary between words.
Next enter the sample text “purple prose, Purple Heart; purple rose - PURPLE people, purple cows”. This results in five matches:

Finally, enter one or more exceptions, each of which is one of the words following “purple”. Here we’ve entered “(?i)prose” and “(?i)people”:

Remember that exceptions monitor only the results from the main regex. There is no need to include “purple” in the exceptions, because every result already includes that word. All we need to match is a pattern within a result. You can experiment by entering additional exceptions to see results reflected in the regex tester.

You can enter up to 15 exceptions for each regex policy. If you need more exceptions for a given policy, you can combine them by using the regex “or” operator (vertical bar: |) as long as the combined expression does not exceed the limit of 2048 characters.

Sometimes you need a further refinement to allow for words contained within other words. In this example, “rose” is contained within “prose”, so when “rose” is an exception, it also removes “prose”:

This was not the goal; regular expressions should result in precise, not accidental matches. Adding a word boundary before the exception expression — \b(?i)rose — can ensure your exception expression (or any regular expression) is more precise: