DLP on the Web Gateway is kind of a black box. We know what rules there are, but we don't get any visibility into how the rules work.
I see two credit card number classifications in the default PCI checks for DLP; (A)Credit Card Number Violations and (B)Bulk Credit Card Number Violations. While we are not able to see exactly how these work, based on past experience I would go with the following:
(A) Looks for credit card numbers that match a Luhn check, but also have a proximity to certain keywords (such as "credit card") to reduce false positives.
(B) Looks for credit card numbers that match a Luhn check, without the proximity check, but requires there be more than a certain large number number of them.
The Network DLP (Prevent) system allows you to see and adjust the policies as you need, so we can get an example of what the values may be. (A) has a proximity requirement for the keywords of 500 bytes. (B) still has the proximity (now within 2500 bytes), and requires that there be at least 100 matching numbers. There is nothing to say that these match up exactly, but I know that they use similar engines to do the work, and would assume therefore similar rules.
Support or sales may have more insight into how exactly the built-in DLP classifications work, but if you want to tune things or have better control your best bet is to use a NDLP product. That would also give you the option of seeing what items have triggered and properly review them.
Thanks for your feedback! So, have you tried NDLP under my sceneario(Block only credit card numbers)??
I haven't set it up *only* for credit card numbers, usually I have several policies that we are interested in. That beind said, yes, I have been able to block a variety of things.
If I wanted a policy to block the numbers without the keyword proximity check, that would be very easy to set up, but generally not advised. There would be a lot of false positives.