| Solution |
It has been seen that when the DLP profile of type 'regex' is not blocking upload of sample credit card numbers kept in a file like .txt, .pdf, etc to a cloud drive like file.io.
Points to be noted:
- At first, this might look like a bug, confusing admins/engineers.
- However, this is expected behavior as the samples will not match due to failing Luhn verification.
- The provided credit card number is invalid, so it does not match the built-in data type.
- The built-in data type performs Luhn verification to validate credit card numbers.
- Since the number is invalid, DLP considers it normal and does not block it.
- With a valid credit card number, the built-in data type would match and get blocked.
The regex expression ^3[47][0-9]{13}$ is used for credit card pattern validation. By default, the new Hyperscan matching engine matches anchor patterns (^ and $) only at the start and end of the file buffer. Unlike most regex engines and legacy DLP, it does not consider newlines as boundaries for anchoring.
To enable multiline anchor matching, enclose the pattern to be matched with '/{pattern}/m'.
So the config might look like:
config dlp dictionary
edit "<name_of_dictionary>"
set uuid c1c8d618-fa5b-51ed-92aa-1250e7b079b0
config entries
edit 1
set type "regex"
set pattern "/^3[47][0-9]{13}$/m"
If matching the start/end of the line is not a concern, it is recommended to use word boundaries as they can be more consistently relied upon for matching:
config dlp dictionary
edit "<name_of_dictionary>"
set uuid a8747526-11ff-51ee-69b6-659911a2768b
config entries
edit 1
set type "regex"
set pattern "\\b3[47][0-9]{13}\\b"
|
