Enterprise Vault™ Classification using the Veritas Information Classifier

About policy conditions

A condition specifies the criteria that an item must meet for the Veritas Information Classifier to consider it a match. Your policies can contain any number of conditions.

All conditions have this basic form:

property operator value

For example, in the following condition, "Content" is the property, "contains text" is the operator, and "Stocks" is the value:

At the right of each condition, you can specify the minimum number of times that an item must meet the criteria for the Veritas Information Classifier to consider it a match.

Various applications that you use in your organization may add custom property information to the items that you want to classify. For example, when Enterprise Vault processes an item, it populates a number of the item's metadata properties with information and stores this information with the archived item: the date on which Enterprise Vault archived the item, the number of attachments that it has, and so on.

If you know the name of a property that particularly interests you, you can enter it as a custom field in your policy conditions.

See About the Enterprise Vault properties.

While creating a policy if a required property is not available in the property list, you can create a new property by using custom property fields.

Use the Veritas Information Classifier's YAML file to add a custom property under the property list on the UI.

The metadataDefinitions section of YAML file lists all the existing properties in the property list as follows:

The following table shows the data structure for an existing property:

A regular expression, or regex for short, is a pattern of text that consists of ordinary characters (for example, letters a through z) and special characters, called metacharacters. The pattern describes one or more strings to match when searching text. For example, the following regular expression matches the sequence of digits in all Visa card numbers:

\b4[0-9]{12}(?:[0-9]{3})?\b

Your regular expressions must conform to the Perl regular expression syntax.

See the online Help for the Veritas Information Classifier for extensive information on this syntax.

You may find it helpful to build and test your regular expressions using the free online tool at https://regex101.com. This tool displays an explanation of your regular expression as you type it, and also lists all matches between the regular expression and a test string of your choice. The default regular expression flavor, pcre (php), is compatible with the Veritas Information Classifier.

A pattern match evaluates the selected item property against an existing Veritas Information Classifier pattern. Depending on the selected pattern, you may be able to set the confidence levels that you are willing to accept. A high confidence level is likely to produce fewer but more relevant matches.

Unlike most classification techniques that rely on pattern matching to identify sensitive data, Exact Data Match (EDM) triggers a classification response when the actual data that needs to be protected is detected. By matching on the exact data, this reduces the rate of false positives and allows for much higher levels of accuracy in automatic classification. EDM uses a fingerprint method whereby an extract of a database or table is provided as source file in either CSV or TXT format. The table is ingested, and rules are created that indicate a match when one or more columns of a single row are detected in proximity. EDM is ideal when the identification of discrete customer data, employee data, and any other sensitive data repository maintained within a table is required.

Exact Data Match can be enabled or disabled using YAML.

The Exact Data Match feature allows you to detect the specific data sets from a database. For example, employee records. You can match one or more fields and optional fields as per the configured proximity value. It supports large data sets (like database records) and text in all languages and provides data protection by hashing the stored data. The main benefit of using Exact Data Match is to reduce false positives by matching data exactly (unlike pattern-based matching).

For example, if you have the following content in the document to classify:

Name: Teresa M. Brown

Employee ID: 624828

and you are trying to match against the following EDM source document,

Then this will trigger a match.

When you test a document against a EDM based policy, Veritas Information Classifier shows the result. Also, the first column of the matching row is highlighted.

Example 1:

If source document content is as follows,

with Exact Data Matching Options as follows,

And if test document content is as follows,

The classification result will show a match for two records Stuart, and James.

Example 2:

For same source document and test document as stated in earlier example, if Minimum Columns value is set to 3 as follows:

The classification result will show a match for single record, that is Stuart. Because all 3 fields from first record is present in test document.

Example 3:

For same source document and test document as stated in first example, if proximity value is set to 50 as follows:

In this case, required words are not within proximity of 50 characters. Therefore the result will show no match.

You can set up a condition to restrict policy matching to items in a particular language. For example, set the condition like the one below to find items whose content is primarily in French:

One of the options in the language list is Multiple languages detected. This option matches items that contain at least two languages.

To safeguard against the Veritas Information Classifier ignoring items because it cannot determine their primary language, select Or Primary Language Unknown. The most common reason why the Veritas Information Classifier may be unable to determine an item's primary language is that the item has a very small amount of content.

You can set up a condition to restrict policy matching to content that includes a person name or location.

For example, set the condition like the one below to find content including the person name.

Starting with release 3.2.0, risk score and risk level for each classified item is sent to the consuming applications. Consuming applications can analyze this information and support features such as sort, filter, search, and report on items by risk score and/or risk level. By understanding the level of risk, you can optimize efforts on data management, review, and control. You can prioritize activities and resources on items of highest risk.

The risk score and risk level are based on the number of pattern or policy condition hits. Items with more hits are categorized as high risk. Items with fewer hits are categorized as low risk.

You can configure YAML to lower the weightage of patterns while calculating risk score, for more details, see Configuring hit count weightage through YAML.

Risk score and risk level information in classify API response

The risk information is sent as part of classify response only if following conditions are met:

Risk score calculation

The risk computation of potentially sensitive content is based on the degree of hits against patterns or policy conditions.

Consider the following example, a document is analyzed against a policy containing five patterns and number of hits per pattern is as follows:

The risk score for the document is addition of all pattern hits. Therefore, the Risk score is = 7+2+4+0+3 =16.

Risk levels

Risk is categorized in different risk levels as per the risk score as follows:

In earlier example, the Risk score is =16. Therefore, the Risk is categorized as: Risk Level: Very High

For a less sensitive pattern, you can reduce its weightage in risk score calculation irrespective of actual number of hits against it.

Use application-specific YAML to configure list of patterns for which any number of actual hits will always be considered as a single (1) hit. You can add list of patterns under lowerRiskRuleNameParts field in YAML. Note that the setting is common to all tenants.

For example, see the following table that shows the effect on overall risk score when Pattern 1 is listed under lowerRiskRuleNameParts in YAML:

Therefore, the Risk score in this case is = 1 +2+4+0+3 =10.

Facts and limitations about risk score:

For an All of group only, you can choose to look for instances where the conditions occur within a specified number of characters of each other. For example, the following condition group looks for instances where the word Goodbye appears within 20 characters of the word Hello:

The text string "You say Goodbye and I say Hello" matches these conditions because there are fewer than 20 characters between the first character of Hello and the first character of Goodbye. Similarly, the string "You say Hello and I say Goodbye" also matches because there are fewer than 20 characters between the ends of the two words. In each case, the spaces count as characters.

Rather than choose the from the first condition option, you can choose in a sliding window. This option looks for instances where the conditions occur within any sequence of characters of the specified number. For example, a condition group that looks for instances where the word Goodbye appears within a 20-character sliding window of the word Hello does not match "You say Goodbye and I say Hello". There are 23 characters between the start of the word Goodbye and the end of the word Hello.