Data Loss Prevention

Hello!

Does anybody use exclude prefix in custom data identifiers? How it works? I don't see detailed description in the documentation.

For example, I want to catch next strings:

•   passport 1212123456
•   1314134589
•   license 1323456778

but do not catch string:

•   inn 1212123456

I create data identifier with a pattern '\d{10}' and exclude prefix 'inn', but it doesn't work - I catch all strings including last.

I can create template with the Look ahead section for exclude 'inn', but I want to understand how work exclude prefix in custom data identifiers.

Thank you!

May be the next logic in the policy will help you..

Rule:

( Rule 1 = RegEx ("^passport \d{10}")) OR ( Rule 2 = RegEx (^\d{10})) OR ( Rule 3 = RegEx (^license \d{10}))

Exception:

Exception 1 = RegEx ("^inn \d{10}")

Please, give an additional attention to the regular express in example. 

It's really good workflow. But data identifier more useful - I can use it with several policies easier than rull with RegEx. I want to understand how work exclude prefix in custom data identifiers.

You've correctly identified that a Custom Data Identifier is the way to go on this. I believe the prefix validation that you're using (there are a few ways to do that) is looking at the beginning of the matched string (not the characters preceding the matched string as you would think), hence you still detect on that last example.

What you need is a Custom Script Validator on that DI to check your prefix.  I've done these scripts for many reasons, usually for tuning on standard CCN and SSN identifiers. 

If I had to take a quick guess, I'd think your script validator would look something like this:

$prefixLength = datalength($matchPrefix);

if ($prefixLength == 10)
  {
    $chkValue = getStringValueAt($matchPrefix, 0x6, 3);

    assertFalse($chkValue == 'inn');
  }
 

That's completely untested, unverified, etc.  Just basing it on scripts I've written before, so use at your own risk, and test/tweak as necessary.  Do the board a favor and post the final code up here as well when you're done.

Regards,

~Keith

Hi All,

Do we have any documents which talks about how to write a policy or can we have any test cases (mainly from customer driven) from where we can chose and customize the  policy according to our requirements?

If we dont have any then we have to work as a team and should create one, having said everyones participation will be much appriciated for this bigger goal.

Your script is very useful. Thank you very much!

But about the prefix validation:

There is a validator “Exclude beginning characters”, that really looking at the beginning of the matched string. I tried various tests for the validator “Exclude prefix”, but I couldn’t find how it works. The DLP also detects a word ‘innab’ if I create data identifier with a pattern '\w{5}' and exclude prefix 'inn'.

To be honest, I don't feel like all of the custom Data Identifier features are fully baked.  I've found a host of thinngs that don't work as I would expect, nor are they sufficiently documented to tell you how they are at least supposed to function.  Unfortunately for me this has led to a lot of trial and error debugging and testing, even for the simplest things.  It sounds like you might be running into something similar with the match prefix.  I'd have to spend some time looking at it and testing it to tell you for sure.

For instance, with the script processing, I've found that the default behavior is to evaluate to the "False" assertion condition if there is a processing error in the script...meaning rather than just stop/ignore the script validator, it will return the false assertion and never create a match.  Took me half a day of trial and error to confirm that behavior.  The documentation says something like "an error will halt processing of the script", but nowhere does it say it's going to force a false condition.  This is why, like in the example I put up for you, I have the "if" condition...this way I'm not doing any processing on the match prefix unless there actually is one (the absence of a match prefix would force the false assertion).

Good luck and let us know what you find.  Like I said, if I find some time to test/play with the prefix features, I'll also let you know what I figure out.

Regards,

~Keith