Using Management Center for Cisco Security Agents 6.0
Data Loss Prevention

Table Of Contents

Data Loss Prevention

Overview

Data Loss Prevention Basics

Enabling Data Loss Prevention Protection

1. Install the DLP license

2. Configure the DLP policies for the groups you want to protect

Scanning Data Tags and Static Data Tags

Scanning Data Tags

Static Data Tags

Scanning Data Tag Search Patterns

Text-matching Search Patterns

Built-In Scanning Patterns

The @datascan Token

Managing Scanning Data Tags

Data Classification - Scanning Data Tags List Page

Built-In Data Scanning Tags

Creating a Scanning Data Tag

Editing a Scanning Data Tag

Cloning a Scanning Data Tag

Deleting a Scanning Data Tag

Managing Static Data Tags

Data Classification - Static Data Tags List Page

Adding Descriptions to Static Data Tags

View References to Static Data Tags

Data Loss Prevention Scanning Tasks

Scheduling a Background DLP Scan

Performing an On-Demand DLP Scan

Identifying a Host's DLP Scan Schedule

Identifying a Group's DLP Scan Schedule

Data Loss Prevention Reporting

Creating Data Loss Prevention Rules and Components

Creating File Access Control Rules to Apply Scanning Data Tags

Creating File Access Control Rules to Apply Static Data Tags


Data Loss Prevention


Overview

Data on network endpoints is increasingly subject to internal policies and external regulations concerning proprietary and confidential information. The process of data classification assists network data security by helping track the existence of sensitive data, its location in the enterprise, how that data is being accessed, and how it must be protected to meet legal and regulatory requirements.

Cisco Security Agent's new Data Loss Prevention (DLP) feature includes these capabilities:

Classification and tagging of a file based on the result of a content scan or its location on the host system.

Classification and tagging of a file based on what applications attempt to read or write it.

User notification when users are working with content that is considered sensitive. Raising awareness of the presence of sensitive data will help prevent accidental data loss.

The DLP feature enables CSA to tag files based on several types of file content, including specific characters or phrases. CSA also provides optimized pattern matching for credit card numbers and Social Security numbers, which are especially sensitive and subject to government regulatory control.

Identification of sensitive data and control over sensitive data can be customized on the CSA MC to assist in the implementation of Data Loss Prevention controls for use of data in compliance with your organization's policies.

This chapter contains these sections:

Data Loss Prevention Basics

Enabling Data Loss Prevention Protection

Scanning Data Tags and Static Data Tags

Scanning Data Tag Search Patterns

The @datascan Token

Managing Scanning Data Tags

Data Classification - Scanning Data Tags List Page

Built-In Data Scanning Tags

Creating a Scanning Data Tag

Editing a Scanning Data Tag

Cloning a Scanning Data Tag

Deleting a Scanning Data Tag

Managing Static Data Tags

Data Classification - Static Data Tags List Page

Adding Descriptions to Static Data Tags

View References to Static Data Tags

Data Loss Prevention Scanning Tasks

Scheduling a Background DLP Scan

Performing an On-Demand DLP Scan

Identifying a Host's DLP Scan Schedule

Identifying a Group's DLP Scan Schedule

Data Loss Prevention Reporting

Creating Data Loss Prevention Rules and Components

Creating File Access Control Rules to Apply Scanning Data Tags

Creating File Access Control Rules to Apply Static Data Tags

Data Loss Prevention Basics

This section describes the basic concepts of CSA's Data Loss Prevention (DLP) feature.

Enabling Data Loss Prevention Protection

The Data Loss Prevention feature is available for Windows desktop platforms only. To enable Data Loss Prevention protection, you need to perform these tasks:

1. Install the DLP license

Before CSA MC distributes data scanning rules to a host, CSA requires a DLP license key in addition to the standard CSA desktop host key. Data Loss Prevention license files are named DLP Desktop Agent Upgrade and are available in bundles from 25 to 10,000 seats.

With the license in place, CSA can tag files with scanning data tags and static data tags, CSA can gather information on files with those tags, and CSA can enforce rules that consider a file's tag.

If you have not done so already, you can upload a data loss prevention license to the CSA MC by following this short procedure:

Step 1 Log on to the CSA MC as a user with configure or deploy privileges.

Step 2 Click Home to go to the Home page.

Step 3 Click Update License Information.

Step 4 Browse to the location of the DLP license file, and click Upload.

2. Configure the DLP policies for the groups you want to protect


Step 1 Open the Host Security page.

Step 2 Expand the Group that you want to protect with DLP. You should find that the Data Loss Prevention policy is listed with your group but its checkbox is probably not checked and may even be grayed-out.

Step 3 Click the red warning link next to the Data Loss Prevention policy name.

Step 4 Configure and save any rules that require customization.

Step 5 Click the checkbox for the Data Loss Prevention policy and click Save on the Host Security page.

Step 6 Generate rules. After you have configured the DLP license, generate rules. The DLP policy will be distributed to the hosts in the group when they next poll in.


Tip If you want to distribute the Data Leakage Prevention policy quickly, send a polling hint to the group.


Scanning Data Tags and Static Data Tags

There are two types of data tags: scanning data tags and static data tags. Scanning data tags can be assigned to a file based on its contents. Static data tags can be assigned to a file based on what applications use that file.

Scanning Data Tags

A scanning data tag is assigned to a file if CSA has scanned the contents of the file and matched a pattern in the file to a pattern defined on the Data Classification - Scanning Tags page.

You can create scanning data tags representing any string of characters you decide to search for. (See Text-matching Search Patterns for more information.) There are also pre-configured, "built-in" scanning tags that are provided by default.

The "built-in" scanning data tags are defined by pre-configured patterns that are used to find Social Security numbers and credit card numbers. CSA uses a special number-scanning algorithm to identify these numbers in files while, at the same time, differentiating them from other large numbers. For example, CSA can distinguish between a file containing nine digit part numbers and a file containing Social Security numbers with a high degree of accuracy.

If more than one type of pattern is found in a file, the file is tagged with more than one scanning tag.

After a file has received a scanning data tag, other rules can govern how users are allowed to interact with that file. Users may also be notified if they are using a file with sensitive information. Making users aware of the kind of files they access helps to prevent accidental data loss.

See Creating a Scanning Data Tag for an explanation of how to create scanning data tags.


Note There is support in the default Data Loss Prevention policies for the <Regulatory Controlled> and <Proprietary Information> tags. If you assign one of these two tags, then the default Data Loss Prevention policies will restrict the behavior of the tagged files. If you assign a tag other than one of these two, then you must create your own rules that govern the behavior of these tagged files.


Static Data Tags

A static data tag can be assigned to a file if a particular application accesses the file. Static data tags are built-in data tags distributed with this release and are listed on the Data Classification - Static Data Tags page on the CSA MC. You cannot change the names of these tags and you cannot create new static data tags.

You define the rules, based on your enterprise's needs, that assign static data tags to files. There are no Data Loss Prevention policies that come pre-configured to assign static data tags to files.

Static data tagging can be useful if, for example, you have a specialized application. Perhaps your enterprise is a hospital and you know in advance that any file that your specialized application reads falls under HIPAA guidelines. There is a <HIPAA Controlled> static data tag that you can apply to the file. This type of tagging method may also be useful when a file type is not scananble for a text-matching pattern, such as an audio file or a graphics file.

See Creating File Access Control Rules to Apply Static Data Tags for more information.

Scanning Data Tag Search Patterns

The Patterns field of the Data Classification - Scanning Tag pop-up is where you specify the pattern that your content tag represents. See Figure 16-1.

The two types of patterns can be specified in this field:

Text-matching Search Patterns

Built-In Scanning Patterns

Figure 16-1 Data Classification - Scanning Tag dialog

Text-matching Search Patterns

Text-matching patterns can contain any strings of characters or numbers specified by the administrator.


Note In general, long text-matching patterns usually will be more effective than short patterns. Searching for long text-matching patterns prevents CSA from assigning content tags to files that you did not expect or intend to match. For example, by searching for the pattern Company confidential. For internal use only CSA is more likely to find and tag files that are truly confidential than if your pattern was only the word confidential.


These are the syntax requirements for character-matching search patterns:

CSA's string-searches support English, and languages other than English, whose character sets can be represented by 2-byte UNICODE text-encodings. (Currently, this excludes Asian and Semitic languages.) We also support accented Latin, Greek, and Cyrillic characters, as long as each letter and its accents are included within a single two-byte character.


Note In order to match strings with accented characters, the string must be entered twice using both the "combined encoding" and the "pre-composed encoding" UNICODE formats.


Text-matching patterns are not case sensitive. For example, the pattern cisco will match Cisco and cisco.

A text-matching pattern can be no more than 256 characters long including wildcards. For example, the pattern: confidential* is 13 characters long.

The smallest text-matching pattern you can search for, not including wildcards, is two characters long.

A text-matching pattern, by default, can only match a whole word or phrase, and not part of a word. Therefore, a pattern such as confidential will not match the word nonconfidential in a file.

Wildcards, represented by a * , can be used to match prefixes and suffixes of a word as well as character strings in between other strings. Here are some other examples:

The pattern *confidential matches nonconfidential.

The pattern confidential* matches confidentiality.

The pattern *confidential* matches nonconfidentiality.

The pattern confidential does not match nonconfidential, confidentiality, or nonconfidentiality.

If multiple words are specified, and they are included on the same line in the Patterns field, they must appear in the same order in the target file to be considered a match. If words are entered on separate lines, the presence in the file of any of the lines in the Patterns field, in any order, is considered a match.

A wildcard can be used in the middle of a string with more than one word. In this case the wildcard breaks the pattern into three parts: the string before the wildcard, the wildcard, and the string after the wildcard.

CSA will match the pattern, Cisco*confidential, to a string that begins with Cisco, ends with confidential and has no more than 50 characters in between Cisco and confidential. For example Cisco*confidential will match Cisco Security Agent - Company Confidential because " Security Agent - Company " is only 26 characters long.

Numeric strings are matched like alphabetic strings. The whole string in the Patterns field must be matched exactly in the file to record a match; if there is more than one number on a line in the Patterns field, that entire string must be present in the target file to make a match; and wildcards may be used to match longer strings of numbers.


Tip Though wildcards can be used to match strings of numbers, if you use wildcards, you may end up matching other alpha-numeric strings that you did not expect or intend to match with your string. Entering exact strings of numbers in the Patterns field will produce the most accurate results.


These are examples of using wildcards with numbers:

The pattern 9785551234 will only match 9785551234.

The pattern 5551234 will not match 9785551234.

The pattern *5551234 will match 9785551234.

The pattern *8555123* will match 1234978555123456789.

The pattern 978* will match 9785551234 as well as many other alpha-numeric string that you may not have intended on matching.

Built-In Scanning Patterns

CSA contains two "built-In" scanning patterns, @ssn and @credit_card. These patterns use special number-scanning algorithms contained in CSA. The @ssn search pattern is optimized to identify patterns of valid Social Security numbers issued by the United States federal government. The @credit_card pattern is optimized to identify valid credit card numbers used by major credit card issuers. These search patterns also distinguish Social Security numbers and credit card numbers from other long numbers to limit the number of false matches.

The @datascan Token

The @datascan token is used in the Content matching field of file sets and the Data Classification area of system state sets to identify files that have received a scanning data tag or static data tag. Using the @datascan token allows rules to refer to a group of files rather than individual files. The syntax for defining a scanning classification tag for these variables is in Data Classification (DLP) Tag Token Syntax, page 2-58.

Managing Scanning Data Tags

Scanning Data Tags are managed through the CSA MC. The Data Classification - Scanning Data Tags list page is accessible from the menu bar by navigating Configuration > Global Settings > Data Classification - Scanning Data Tags.

This page lets you manage scanning data tags that are applied to files after a rule matches a text-matching search pattern or a built-in search pattern. Some built-in scanning data tags are provided by default with this release.

You can perform several administrative tasks from this page. See these procedures for more information:

Creating a Scanning Data Tag

Editing a Scanning Data Tag

Cloning a Scanning Data Tag

Deleting a Scanning Data Tag

Data Classification - Scanning Data Tags List Page

The Data Classification - Scanning Data Tags list page describes tags by displaying these columns of information:

Tag: This is the name of the tag that identifies a pattern of text. The tag is applied to a file that contains the pattern of text specified for the tag. This tag name will be visible to you when creating variables such as file sets or system state sets.

Pattern: This field displays the string of text that CSA searches for when performing a data scan. Once the pattern is located, the tag that identifies this pattern is applied to the file that contains the pattern.

Occurrences: Describes the number of times a pattern has to be found in a file for the file to be tagged as having that pattern.

For built-in numeric patterns such as @ssn or @credit_card, CSA uses a proprietary algorithm to determine if a file has a legitimate concentration of social security numbers or credit card numbers and not other kinds of long numbers. This strives to prevent, for example, a database of part numbers as being mistaken for a database of social security numbers or credit card numbers.

Description: Displays the description for your tag for informational purposes.

Version: Displays the version of CSA with which the tag was supplied. By clicking the column heading, the entries can be filtered to show tags from all versions, only those tags that have been user-defined, or those from a particular release.

Priority: If the CSA database has entries for many tagged files and the database is getting too big, the entries for the files tagged with the high-priority tags remain in the database and the entries for the files with the lowest priority tags are discarded.

Status: A data tag is either "enabled" and CSA actively scans for it, or it is "disabled" and CSA does not scan for it.

In Use: A data tag is in use if it is specifically referenced by at least one variable such as a file set or a system state set. If the tag is only referenced by variables that reference all data tags, for example, @datascan=<*>, the tag is not to considered to be in use.

To find out which variable uses the tag, click in the row that describes the data tag, click the Tasks button in the Data Classification - Scanning Tag dialog, and click View references. A list of file sets is displayed.

A data tag that is "In Use" cannot be deleted without first deleting the variable that references the tag.

Built-In Data Scanning Tags

Files are given scanning data tags if CSA has scanned the file and matched pattern in the file. CSA provides these built-in data scanning tags by default:

<credit_card>: The <credit_card> tag uses @credit_card, which is a number scanning search pattern built into CSA. The @credit_card search pattern is optimized to identify patterns of valid credit card numbers used by major credit card issuers.

<Proprietary Information>: The <Proprietary Information> tag is assigned to a file if CSA matches the exact phrase "Company Confidential" or "Internal Use Only" a certain number of times, in a scanned file. However, before files can be tagged with the <Proprietary Information> tag, your CSA administrator needs to edit the pattern to make sure it is appropriate for your enterprise, before enabling the tag.

<SSN>: The <SSN> tag uses @ssn, which is a number scanning search pattern built into CSA. The @ssn search pattern is optimized to identify patterns of valid Social Security numbers issued by the United States federal government. A <SSN> tag is assigned to scanned data if CSA finds valid Social Security numbers in the data.

<Regulatory Controlled>: The <Regulatory Controlled> tag is assigned to files in which the @credit_card or @ssn patterns are found. A <Regulatory Controlled> tag is assigned to scanned data if CSA finds valid credit card numbers or Social Security numbers in the data.

Creating a Scanning Data Tag

This kind of tag would be applied to a file after a "Data scan on OPEN" or "Data scan on CLOSE" FACL triggers a scan on a file and CSA finds the pattern specified by the data classification tag.


Step 1 Log on to the CSA MC as a user with configure privileges. This procedure may done by either a Simple Mode or Advanced Mode user.

Step 2 From the Configuration menu, navigate Global Settings > Scanning Data Tags.

Step 3 Click New. The Data Classification - Scanning Tag dialog opens.

Step 4 In the Tag field, enter a tag name. Only alphanumeric characters, underscores, hyphens, parentheses and periods may be used in a tag name.

Step 5 Optionally, in the Description field, enter a description of the pattern.

Step 6 In the Patterns field, enter a combination of a text string, a numerical string, or a built-in pattern chosen by clicking Insert Pattern (@credit_card and @ssn are the preselected patterns available). The pattern list cannot be empty. See "Scanning Data Tag Search Patterns" section for how to enter a string in the Patterns field.


Note In order to match strings with accented characters, the string must be entered twice using the "combined encoding" and the "pre-composed encoding" UNICODE formats.


Step 7 In the Pattern Count field, specify the number of times the pattern must be found in a file for the file to receive the tag.

Step 8 In the Priority field, select a priority for the scanning data tag. If the CSA database has entries for many tagged files and the database is getting too big, the entries for the files tagged with the high-priority tags remain in the database and the entries for the files with the low priority tags are discarded.

Step 9 Select the Enabled check box to enable the tag.

Step 10 Click Save to save the tag. The tag will be available after rules are generated and distributed to hosts when they poll in to the CSA MC.

Editing a Scanning Data Tag


Step 1 Log on to the CSA MC as a user with configure privileges. This procedure may done by either a Simple Mode or Advanced Mode user.

Step 2 Click the link for an existing scanning data tag. The Data Classification - Scanning Tag dialog opens.

Step 3 If a tag is not in use, you can change its name. If a Tag is "in use" then it is referenced by some other component or rule. In that case, you must click Allow tag change to rename the tag. Only alphanumeric characters, underscores, hyphens, parentheses and periods may be used in a tag name.


Note Changing the name of the tag on this page does not change the name of the tag globally. If you want the components and rules that use the old tag name to use the new tag name, you need to edit those items individually.


Step 4 Optionally, in the Description field, enter a description of the pattern.

Step 5 In the Patterns: field, enter a combination of a text string, a numerical string, or a pre-selected pattern chosen by clicking on Insert Pattern (@credit_card and @ssn are the pre-selected patterns available). The pattern list cannot be empty. See "Scanning Data Tag Search Patterns" section for how to enter a string in the Patterns field.


Note In order to match strings with accented characters, the string must be entered twice using the "combined encoding" and the "pre-composed encoding" UNICODE formats.


Step 6 In the Pattern Count field, specify the number of times the pattern must be found in a file for the file to receive the tag.

Step 7 In the Priority field, select a priority for the scanning data tag. If the CSA database has entries for many tagged files and the database is getting too big, the entries for the files tagged with the high-priority tags remain in the database and the entries for the files with the low priority tags are discarded.

Step 8 Select the Enabled check box to enable the tag, clear the Enabled check box to disable the tag.

Step 9 Click Save to save your changes. The tag will be available after rules are generated and distributed to hosts when they poll in to the CSA MC.

Cloning a Scanning Data Tag


Step 1 Log on to the CSA MC as a user with configure privileges. This procedure may done by either a Simple Mode or Advanced Mode user.

Step 2 Click the link for an existing scanning data tag. The Data Classification - Scanning Tag dialog opens.Select the checkbox to the left of the tag to be cloned. Only one tag may be cloned at a time.

Step 3 Click "Clone", then select "OK". A new tag will appear in the Data Classifications - Scanning Tags screen, with a <new> marker next to the tag name. The cloned tag may then be edited by following the steps in Creating a Scanning Data Tag.

Deleting a Scanning Data Tag


Step 1 Log on to the CSA MC as a user with configure privileges. This procedure may done by either a Simple Mode or Advanced Mode user.

Step 2 Select the checkbox to the left of the tag(s) to be deleted.

Step 3 Click Delete, then select OK if you are sure you want the tag(s) to be deleted.


Note Scanning data tags that are "In Use" can not be deleted without first deleting the variable that references the tag.


Managing Static Data Tags

Static Data Tags are assigned to files based on what group of applications attempt to access them.

The Static Data Tags list page is accessible from the menu bar by navigating Configuration > Global Settings > Static Data Tags. This page helps you identify in what rules and variables these static data tags have been referenced.

You can perform two administrative tasks from this page. See these procedures for more information:

Adding Descriptions to Static Data Tags

View References to Static Data Tags

Data Classification - Static Data Tags List Page

The Data Classification - Static Data Tags list page describes tags by displaying these columns of information:

Tag: This is the name of the tag given to the file after a particular applications has accessed it. This tag name will be visible to you when creating variables such as file sets or system state sets.

Description: Displays the description for your tag for informational purposes.

In Use: A data tag is in use if it is specifically referenced by at least one variable such as a file set or a system state set. If the tag is only referenced by variables that reference all data tags, for example, @datascan=<*>, the tag is not to considered to be in use.

To find out which variable uses the tag, click in the row that describes the data tag, click the Tasks button in the Data Classification - Scanning Tag dialog, and click View references. A list of file sets is displayed.

The attributes of a static tag are defined by a file access control rule that you create. See Creating File Access Control Rules to Apply Static Data Tags for a procedure to define the attributes of a static tag.

Adding Descriptions to Static Data Tags


Step 1 Log on to CSA MC and switch to Advanced Mode.

Step 2 From the Configuration menu, navigate Global Settings > Static Data Tags.

Step 3 In the Data Classification - Static Tags list page, click the link for the static data tag you want to describe.

Step 4 Enter your description in the Description field and click Save.

View References to Static Data Tags


Step 1 Log on to CSA MC and switch to Advanced Mode.

Step 2 From the Configuration menu, navigate Global Settings > Static Data Tags.

Step 3 In the Data Classification - Static Tags list page, click the link to the static data tag for which you want to view references.

Step 4 Expand the Tasks menu and click View References.

Step 5 Click a link to follow the reference.

Data Loss Prevention Scanning Tasks

Data Loss Prevention scans can be scheduled or performed "on-demand."


Note Background and on-demand scans do not change a file's modification date.


Scheduling a Background DLP Scan

Administrators can schedule weekly or monthly background scans of all hosts that use the default Data Loss Prevention - desktops policy provided with this release. This policy contains a rule that specifies which files will be scanned during a background scan. By default, files on fixed local drives are scanned during a DLP background scan.

Background scans happen slowly, at a controlled pace, so as not to affect the user experience.

Follow this procedure to create your own DLP background scanning task or enable the DLP background scanning task provided with this release.


Step 1 Log on to the CSA MC as a user with configure or deploy privileges and switch to Advanced Mode.

Step 2 From the Systems menu, in the CSA MC interface, navigate Host Tasks > Host Scanning Tasks.

Step 3 Click New.

Step 4 Give the task a Name and a Description.

Step 5 Select Enabled if you want to enable this task immediately after rules are regenerated and software updates are distributed to hosts.

Step 6 In the Configuration area, define the task:

In the Run this task fields, choose to run this task every week and on a particular day of the week, or choose to run this task every month and on a particular day of every month.


Note If a scan is scheduled on the 31st of the month, the scan will not be performed on months with fewer days.


In the At field, specify the time of day the scan is to run. Time is expressed in twenty-four hour format.

Check Perform background DL search on all hosts in group and select a group from the drop-down list. You can only specify one group per background scan task.


Note Combining an AntiVirus scan with a Data Loss Prevention scan causes two separate system scans.


Step 7 Click Save.

You will then need to generate rules for the task to be distributed to all hosts in that group.

Performing an On-Demand DLP Scan

An on-demand DLP scan searches fixed drives on the host for files with data scanning tags. In order for an On-demand DLP Scan to work you need to have Data Loss Prevention enabled. See Enabling Data Loss Prevention Protection for more information.


Step 1 Log on to CSA MC as a user with configure or deploy privileges and switch to Advanced Mode.

Step 2 From the Systems menu, click Hosts.

Step 3 Click the link for the host on which you want to start an immediate scan.

Step 4 At the end of the DL full-scan schedule row, click View DL Scan Results.

Step 5 In the Scanning dialog box, click DL Scan Results if the tab is not open already.

Step 6 Click Scan Now. A polling hint is sent to the host, after the host receives the polling hint, the on-demand scan begins automatically. If the host does not receive the polling hint, the scan will begin the next time the host polls.

While the scan is in progress, you can click Get Results to receive the information gathered so far. After clicking Get Results, the agent on the host forwards the information it has collected the next time the agent polls.

When the on-demand scan is complete, the agent sends the results to the MC automatically.

The DL Scan Results page refreshes the information it has periodically. Upon refresh, the latest information forwarded from the agent is displayed on the page.

Identifying a Host's DLP Scan Schedule

To identify a host's Data Loss Prevention scan schedule, follow this procedure:


Step 1 Log into the CSA MC and switch to Advanced Mode.

Step 2 From the Systems menu, select Hosts.

Step 3 Click the link for the host you want to investigate.

Step 4 Expand the Host Status area.

Step 5 The DL Full Scan Schedule field identifies the data loss prevention scanning schedule for the host.

Identifying a Group's DLP Scan Schedule

To identify a group's Data Loss Prevention scan schedule, follow this procedure:


Step 1 Log into the CSA MC and switch to Advanced Mode.

Step 2 From the Systems menu, select Groups.

Step 3 Click the link for the group you want to investigate.

Step 4 In the Features area, look for Data Loss Prevention.

Step 5 Click the link for Background Scan: On (Off). The pop-up box displays the time of the regularly scheduled background scan or indicates that DL background scanning is disabled.

Data Loss Prevention Reporting

You can generate reports that describe the number of files tagged with scanning data tags and the location of those files. See "Data Loss Prevention Reports" section on page 11-14 for the various Data Loss Prevention reports you can generate.

Creating Data Loss Prevention Rules and Components

This release provides policies which seek to prevent data loss. These policies include rules that trigger scans for text patterns and built-in data patterns and warns users of possible data loss activities.

If you want to create customized rules and file sets for your enterprise, this section provides procedures to do that.

Creating File Access Control Rules to Apply Scanning Data Tags

Use file access control rules to trigger data scans on files. Generally, think of a file access control rule triggering a data scan after testing this kind of statement: "Perform a data scan on a file, if an application attempts to read or write that file, and the attempt was allowed (or denied)."


Note Unless this rule applies a static tag when the application's actions are allowed by default, you will also need to create a separate rule that allows (or denies) the applications attempt to access the file.


Follow this procedure when creating a FACL to trigger a data scan:


Note See Configuring Rule Modules, page 5-4 to create your own rule module into which you will put this rule.



Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.

Step 2 Open the rule module to which you want to add this rule.

Step 3 Expand the Rules area of the rule module configuration screen and click the Add button. A pop-up list of the available rule types appears.

Step 4 Select File access control rule. This takes you to the configuration view for this rule type.

Step 5 Enter the following information for the rule:

Description—Enter a description of this rule.

This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.

Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.)

By not selecting this checkbox, you can save this rule, but it will not be active in the module and it will not be distributed to groups.

Step 6 In the Take the following action list box, select Set from the pulldown list.

Step 7 In the Attributes list box, select the kind of scan you want to perform: Data scan on CLOSE or Data scan on OPEN. See Attribute: Data scan on CLOSE, page 5-29 or Attribute: Data scan on OPEN, page 5-30 for descriptions of these set attributes.

Step 8 In the Value field select NOT being required for this file to prevent a file from being scanned for information or Being required for this file to require that the file be scanned for information.

Step 9 Enable the Log checkbox to turn logging on for this rule. Generally, you will not want to turn logging on for these set rules, except for testing or debugging a new rule.

Step 10 When —

Applications in any (or all) of the following selected classes

Select one or more preconfigured application classes here to indicate the application(s) whose access to the listed files you want to control. You may also create a new application class by clicking the blue New link next to the application class list box. For application class configuration details, see Chapter 8, "Using Application Classes"

If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application classes.

If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.

But not in the following class

Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.


Note When your rule is configured, currently selected application classes appear at the top of the list.


Step 11 Attempt the following operations—In this step, you specify the file operation that the application, you are controlling, is attempting.

If you are creating a Scan on OPEN rule, you must select both the Read File and Write File operations you are allowing or denying on the files named in the On any of these files box. If you are creating a Scan on CLOSE rule, you can only select the Write File operation.

The Write directory operation is not a valid choice for Data scan on OPEN or Data scan on CLOSE actions.


Caution Directory protection ignores the file portion of the specified path and only matches the directory portion of the path. If the directory portion is not well specified, the protection will be overly broad. For example, if you select to protect a directory in a deny rule and enter the directory path as follows: **\Program Files\**Outlook.exe, then no directories can be modified under Program Files. That is an overly broad protection to specify and would likely result in system instability. If you choose to protect directories, be sure to be very specific in your path string and understand the resulting behavior.

Step 12 On any (or all) of these files—In this step you configure the file sets on which you want to perform data scans.

If you choose, On any of these files, the rule will trigger a file-scan on a file that is a member of any one of the file sets you specify.

If you choose, On all of these files, the rule will trigger a file-scan on a file that is a member of all of the file sets you specify.

Click the Insert File Set link to enter a pre-configured file set from a list of available file sets. In the Insert File Set list box, you may also click the blue New link, at the top of the list, to create a new file set for the rule. Finally, you can also list the literal files you want to protect, using the file paths (including wildcards).

For information on entering file path literals here rather than using pre-configured File Sets, see Using the Correct Syntax, page 2-41.

Step 13 And — In this area specify, the enforcement action taken by CSA.

Specifying Allow by default or Allow if triggered by a rule triggers a scan on files that applications have been allowed to access. Specifying Terminated or Denied by rule scans files that other applications have been prevented from accessing.

Step 14 When you are finished configuring your File access control rule, click the Save button.

This rule is now part of your rule module. It takes effect when the rule module is attached to a policy, the policy is attached to a group and then is downloaded by an agent on the network.

Creating File Access Control Rules to Apply Static Data Tags

You can use file access control rules to assign a static data tag to a file without having scanned its contents. Generally, think of this rule as classifying a file after testing this kind of statement: "Assign to a file this static data tag if an application attempts to modify the file, and the attempt was allowed (or denied)."


Note Unless this rule applies a static tag when the application's actions are allowed by default, you will also need to create a separate rule that allows (or denies) the applications attempt to access the file.


Static data tags are applied to files after they have been modified and closed.

Follow this procedure when creating a FACL to trigger a data scan:


Note See Configuring Rule Modules, page 5-4 to create your own rule module into which you will put this rule.



Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.

Step 2 Open the rule module to which you want to add this rule.

Step 3 Expand the Rules area of the rule module configuration screen and click the Add button. A pop-up list of the available rule types appears.

Step 4 Select File access control rule. This takes you to the configuration view for this rule type.

Step 5 Enter the following information for the rule:

Description—Enter a description of this rule.

This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.

Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.)

By not selecting this checkbox, you can save this rule, but it will not be active in the module and it will not be distributed to groups.

Step 6 In the Take the following action list box, select Set from the pulldown list.

Step 7 In the Attributes list box, select file Data Classification. See Attribute: file Data Classification, page 5-34 for a description of this setting.

Step 8 In the Value field, select "include the tag <Tag Name>." In the value filed's pulldown menu, there are several static tags for you choose from. You should choose a Tag Name that is related to the kind of application that is accessing the file. As delivered in the default policies, these static tags arrive unused and unconfigured.

The static tags' names were chosen to guide and support the tags' intended use. For example, if your end-users run medical application software, then some of your FACL rules might set the static tag <HIPAA Controlled> for any files that your medical software touches. Note, though, that a file cannot take on more than one static tag. If two "Set file Data Classification" rules fire on the same file, then the tag that appears first in the Value field of the file Data Classification set action will be applied.

For example, if rule 100 is written to apply the <Confidential Information> static tag and rule 200 is written to apply the <HIPAA controlled> tag, if both rules are triggered for the same file, the file will be tagged with the <HIPAA Controlled> static tag because it appears higher in the list of file Data Classification set values.

Step 9 Enable the Log checkbox to turn logging on for this rule. Generally, you will not want to turn logging on for these set rules, except for testing or debugging a new rule.

Step 10 When —

Applications in any (or all) of the following selected classes

Select one or more preconfigured application classes here to indicate the application(s) whose access to the listed files you want to control. You may also create a new application class by clicking the blue New link next to the application class list box. For application class configuration details, see Chapter 8, "Using Application Classes"

If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application classes.

If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.

But not in the following class

Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.


Note When your rule is configured, currently selected application classes appear at the top of the list.


Step 11 Attempt the following operations—In this step, you specify the file operation that the application you are controlling is attempting. You can only specify Write File.

Refer to File and Directory protection in Using the Correct Syntax, page 2-41.


Caution Directory protection ignores the file portion of the specified path and only matches the directory portion of the path. If the directory portion is not well specified, the protection will be overly broad. For example, if you select to protect a directory in a deny rule and enter the directory path as follows: **\Program Files\**Outlook.exe, then no directories can be modified under Program Files. That is an overly broad protection to specify and would likely result in system instability. If you choose to protect directories, be sure to be very specific in your path string and understand the resulting behavior.

Step 12 On any (or all) of these files—In this step you configure the file sets which contains the files you want to tag.

If you choose, On any of these files, the rule will tag a file that is a member of any one of the file sets you specify.

If you choose, On all of these files, the rule will tag a file that is a member of all of the file sets you specify.

Click the Insert File Set link to enter a pre-configured file set from a list of available file sets. Click Show All to expand the list of file sets to choose from. In the Insert File Set list box, you may also click the blue New link, at the top of the list, to create a new file set for the rule. Finally, you can also list the literal files you want to protect, using the file paths (including wildcards).

For information on entering file path literals here rather than using pre-configured File Sets, see Using the Correct Syntax, page 2-41.

Step 13 And — In this area specify, the enforcement action taken by CSA.

Specifying Allow by default or Allow if triggered by a rule triggers a scan on files that applications have been allowed to access. Specifying Terminated or Denied by rule scans files that other applications have been prevented from accessing.

Step 14 When you are finished configuring your File access control rule, click the Save button.

This rule is now part of your rule module. It takes effect when the rule module is attached to a policy, the policy is attached to a group and then downloaded by an agent on the network.

In order to distribute rules to the correct hosts, you must associate policies with groups and then Generate rules. See page 5-16 for instructions.