Data Loss Prevention

Hi, I would like to check initially my requests against luhn checks and then pass them through a Regex search to eliminate some false positives. Is it possible to put a requests through luhn check and regex at the same time as they come in?

Regards,

Evangelos

The built-in Data Identifier for Credit Card Numbers, even at a Wide Breadth, does this for you. The Data Identifier is using a form of regular expressions for pattern matching and the Active Validator is the Luhn check. False-positives will still be returned. Make tuning judgments based on the incidents returned. Maturing companion detection rules with supporting (qualifying) information will help along with using a Medium or Narrow Breadth. Even then, you will likely need to adjust based on results.

Be aware that with Data Identifiers, you cannot use a regexp to match patterns like you could in a detection rule. Open the online help and search for 'Using the data identifier pattern language'.

Hi Ethan, Thanks for your reply. Re: "a form of regular expressions for pattern matching ", Are these regexes configurable?

Totally configurable, as long as you follow the section for data identifier pattern language in the Admin Guide. My suggestion is create your own data identifier based off one that ships with the product instead of changing a built-in data indentifier. Use the built-in data identifier(s) as a reference. A custom DI gives you a Wide Breadth, but you can configure it as you like. 

Evangelos,

The issue is going to be WHICH luhn check you want to use.

You can create your own Data Identifier that uses ANY regex, but there are only specific Luhn alogoritims loaded in the system. So you will need to use one of them, so I am not sure if there is a luhn check that is applicable to your use case. Hopefully it is available.

Section in the UI.

Manage > Policies > Data Identifiers

Make sure to NOT hit the SAVE button on the existing ones when you view them. This page will marked things as eddited even when you do not change anything.

I would create a NEW Data Identifier for your testing, even if you are duplicatiing an existing one.

Good Luck

Ronak

PLEASE MARKED SOLVED WHEN POSSIBLE

"You can create your own Data Identifier that uses ANY regex..." 

This is true in one sense and false in another. Speaking to what you would be writing for the Patterns area,

The data identifier pattern language is a limited subset of the regular expression lexicon. The data identifier pattern language does not support all of the regular expressions characters and constructs. A regular expression pattern converted to a data identifier pattern will require some syntactical modifications.

Data identifier patterns are limited to 100 characters per line. The pattern itself can be more than 100 characters, but a line cannot have more than 100 character. You should split the pattern up by lines not longer than 100 characters.

Ethan.. I undertstand this more than anyone else.

There are a lot more limitations that are there when it comes to Regex in the DI area. What works in the policy does not work in the DI area.

This is also based on understanding that there are Certain characters in the Regex for that are NOT applicable here in the DI area of the DLP console. In addition there are different Regex lexicon types that work and will not work.. just referecne the OTHER existing patterns and you will learn.

all of this is based on experience and know how.. for instance "|" does not work as well as other common Regex characters.. this is beacuse the DI's do not use the standard based Regex characters. 

This is obvioulsy understood as you get more and more experience with the DLP console.

Good Luck,

Ronak

hi

 sure there is some limitations with DI but also many very interesting things so that is why, on my side, i really like to use them.

So Evangelos, yes you can use DI. Always better to create your own (you can copy a predefined one). For this you have to :

- Define one or more patterns you are looking for (take care that this is limited regex engine, but when you have a doubt look at existing one and do some test)

- Then you have to set a normalizer for matched patterns

- Then select a validator (if needed). in your case or default luhn check is ok for you or you can even define you rown using a scripting language.

 When you defined your own DI you are only allowed to create one level of DI, predefined one usually have three wide / medium / narrow. It will be great to have this capability for our own DI as it is easier to manage after this in DLP policies.

 Regards