The present invention relates to methods of preventing sensitive data from leaving an organization, and, more particularly to using a scripting language processing engine to prevent such leakage of sensitive data.
Data leak prevention products try to find data which an organization has defined as secret or sensitive in order to prevent it from leaving the perimeters of the organization. This data can be a list of employees, a list of customers, credit cards, different personal identification numbers, source code, and so on. Each of these specific types of data may be referred to a data type. The data types are recognized in different manners: by matching words or phrases out of a custom tailored dictionary of words and phrases, by file type, by regular expressions. A “regular expression” is understood to refer to a defined notation of a DLP product such as the notation “\d(11)”, which is a defined PCRE (“Peri Compatible Regular Expressions”) notation.
Data leak prevention products cannot, however, handle certain kinds of requests concerning detection of documents or identification of documents having certain data considered to be sensitive in nature or considered to be suspicious in the way it is handled. For example, governmental entities, credit card companies, banks and other large entities which have hundreds of thousands or millions of customers often issue identification numbers unique to each customer. The validation of these identification numbers can be verified by applying a set of mathematical operations to the number. This validation procedure may distinguish the number from most accidentally erroneous numbers and may also protect against use of certain fraudulently created identification numbers by those who may not know about the validation procedure. “Identification numbers” can be anything from taxpayer ID numbers, license plate numbers, bank account numbers, national ID numbers, credit card numbers or other numbers used to uniquely identify individuals amongst a large number of individuals (typically 100,000 or more) who subscribe to, use or are part of a large governmental or private entity.
Each governmental entity or large entity, for example each country in the world, may have its own unique validation procedures applicable to its own identification numbers. As an example, Australian business numbers have been selected so that the following validation function in the form of a mathematical procedure verifies their authenticity. The Australian number must be 11 digits. When one multiplies each of the 11 digits by the following 11 factors: 10, 1, 3, 5, 7, 9, 11, 13, 15, 27 and 19, sums the result and then divides by 89, only if the remainder is zero is the number a valid Australian business number. Other countries and entities select their numbers so that a different mathematical procedure may be used to validate their identification numbers.
If a user using a data leak prevention product would want to detect documents, for example entails, containing five or more Australian business numbers, one available solution would be for the user to create a dictionary of all valid Australian business numbers. That solution would use up a lot of RAM and hard disk resources because of its size (i.e. the order of magnitude of the entries may be 10**9). Alternatively, the user could try to detect Australian business numbers in the documents by detecting the existence of any eleven-digit number in a document. This may be accomplished by using a regular expression, meaning a PCRE notation of a DLP product, for example “\d(11)”. This solution is not very accurate since it will generate way too many false positives.
In the above example, another problem is that it is difficult to establish an appropriate threshold for the number of appearances of a data type in a document, such as an email. Suppose action by a data leak prevention software is triggered by the number of such appearances or supposed the document type is defined by the number of such appearances. In the above example, for example, if all entails having five or more Australian business numbers were flagged, the threshold may be too low and there may be too many false positives. On the other hand, increasing the threshold to ten in order to reduce false positives would not completely eliminate the false positives and may encourage significantly more instances of failing to detect problematic documents that should have been detected, i.e. false negatives.
Another example of a request that a data leak prevention product would typically not be able to handle is detecting mails sent to a particular recipient in which the identity of that recipient also appears in the body of the email. The appearance of the recipient in the body of the email can be an important indicator justifying reduced concern about the appropriateness of the email being sent to the recipient from a security point of view. A further example of a request that a data leak prevention product would normally be unable to handle is a request to define as sensitive entails sent by a particular customer to a certain number of recipients.
There is a compelling need to have an improved method or system that will save sensitive data from leakage outside the organization. There is a further need to have such a system or method that allows the administrator to conveniently categorize documents according to their security sensitivity in response to sophisticated requests.