Out of the Box

In This Section: Default Deployment Data Loss Prevention in SmartDashboard Defining My Organization Data Loss Prevention Policies Auditing and Analysis

Default Deployment

The first stage of DLP deployment uses the Data Loss Prevention policy provided Out of the Box.

• Automatic inspection of data is based on built-in Check Point expert heuristics and compliance to various regulations.
• Users in your organization will transmit data as a part of their daily tasks. DLP will catch incidents that match rules of the policy. Rules in this stage will be set to Detect, allowing you to monitor usage and understand the specific needs of your organization without disrupting your users.
• You will audit the data, using experience-driven severity ratings, and the Logs & Monitor tracking to find the key data leaks.

Data Loss Prevention in SmartDashboard

To show these pages in SmartDashboard:

In SmartConsole, select Security Policies > Shared Policies > DLP and click Open DLP Policy in SmartDashboard.

SmartDashboard opens and shows the DLP tab.

Page	Function
Policy	Manage the rule base for Data Loss Prevention policy.
Whitelist Policy	Manage files that will never be matched by the DLP Rule Base.
Data Types	Define representations of data assets to protect.
Repositories	Manage the fingerprint and whitelist repositories. The fingerprint repository contains documents that are not allowed to leave the organization. The whitelist repository contains documents that can leave the organization.
My Organization	Define the internal environment: networks, users, email addresses, and VPN communities.
Gateways	Enable the Data Loss Prevention Software Blade on Check Point Security Gateways. You can define DLP gateways and Exchange Agents. An Exchange Agent lets you scan internal emails between Microsoft Exchange clients once you install the Exchange Security Agent on the Exchange Server. The table shows status, uptime, inspected items, version, CPU usage and comments for the gateways and Exchange Agents. You can see a graphical representation of this information in SmartView Monitor.
UserCheck	Manage UserCheck objects that are used in a Rule Base to: Help users with decisions that can be dangerous to the security of the organization. Share the organization's changing internet policy for web applications and sites with users, in real-time.
Additional Settings:
Protocols	Enable the protocols to be checked on individual DLP Gateways.
Mail Relay	Configure the mail server for DLP to send notification emails.
Email Addresses or Domains	Manage email address lists and domains for use in DLP rules and Data Types.
Watermarks	Configure the tracking option that adds visible watermarks or invisible encrypted text to Microsoft Office documents (Word, Excel, or PowerPoint files from Office 2007 and higher) that are sent as email attachments (outgoing and internal emails).
Advanced	Incident Tracking - Define whether to log all emails (to calculate ratio of incidents) or just DLP incidents. Email Notifications - Define if users are notified after a DLP violation on the selected protocols. Learn User Actions - Define whether DLP learns Ask User answers for all messages of a thread, or asks each time a message violates a DLP rule. Extreme Conditions - Lets you define if to bypass DLP SMTP, FTP and HTTP inspection and prefer connectivity under these extreme conditions: CPU load levels are more than the high CPU load watermark Other extreme conditions including: Internal errors Protocol message sizes are more than the default value File attachments are more than the default value Archive depth level is more than the default value If necessary, you can change the default values. Watermarks - Define whether watermarks are applied on DLP rules and how to handle a document that already has a watermark.
HTTPS Inspection (located in a separate tab)	Configure inspection of HTTPS/SSL traffic from enterprise networks to external destinations.

Defining My Organization

The My Organization page shows what DLP recognizes as data movement in the internal network (where data leakage is not an issue) and what is external (where data transmission must be monitored).

By default, My Organization includes all hosts and networks that are behind the internal interfaces of the DLP gateway. My Organization also includes specific users, user groups, and all users in the LDAP groups defined in the Security Management Server.

Note - The SmartConsole must be in the Active Directory domain to take advantage of the LDAP User List features.

My Organization Definitions: Adding Email Addresses and Domains to My Organization Defining Internal Users Defining Internal User Groups Excluding Users from My Organization Defining Internal Networks Excluding Networks from My Organization Defining Internal VPNs Excluding VPNs from My Organization

Adding Email Addresses and Domains to My Organization

You define the DLP internal domains and specific email addresses that are included in My Organization. You can add domains to include your remote offices and branch offices as part of the definition of what is My Organization.

Important - If your organization uses cloud servers, you should not add them. The technology governing cloud servers makes them inherently insecure, taking the control of your data away from your administration and giving it to a third party. It is recommended to detect all sensitive data sent to and from cloud servers, rather than to trust a service provider to make sure that other clients do not have access to your data.

Add email addresses to include those that are safe for general data sharing. You should not add the private email addresses of any employees or managers. Taking home confidential data is a bad practice that you should discourage and eventually prevent.

Notes about Domains:

• When you add domains, do not use the @ sign. A valid domain example is: example.com
• If you add a domain, it catches all sub domains as well. For example, if the domain is example.com, email addresses such as jsmith@uk.example.com are also considered part of My Organization.
• SMTP traffic is considered internal if the domain of the email is defined in My Organization and if the IP address of the sender is an interface/network defined in My Organization.

Important - Do not remove the default domain definition. You must have a domain in the My Organization definition, or an LDAP server defined. If you do not have the domain defined (either by Email Address Domain or LDAP Account Unit) for My Organization, DLP will not scan emails.

To add domains and email addresses to My Organization:

1. In SmartConsole, open the Data Loss Prevention tab.
2. Click My Organization.
3. In the Email Addresses area, enter a domain or specific email address.
4. Click Add.

Defining Internal Users

Most organizations use an external LDAP server (for example, Active Directory) to manage users and user groups.

You can define an internal user account to use as a source or destination in the Rule Base when:

• Your organization does not use an LDAP server.
• You want to define a user that is not defined in the LDAP server.

You can add accounts for individual users from the Data Loss Prevention tab in SmartConsole.

To define user accounts as internal users:

1. Expand Additional Settings > Users.
2. Click New > User.

   The User Properties window opens.

3. Define the user account.

   The most important field is the email address. This lets DLP recognize the user for email scans.

   The user is added to the other Software Blades managed by SmartConsole.

Defining Internal User Groups

DLP may require different user groups than those in the LDAP server. For example, you may want a group for new employees, whose rules are set to Ask User rather than Prevent, to give them time to become familiar with the organization guidelines. You may also want a group for temporary employees or terminating employees, to give them stricter rules.

To define user groups:

1. Expand Additional Settings> Users.
2. Click New > User Group.

   The Group Properties window opens.

3. Name the group.
4. Select the users, user groups, or external user profiles that you want in this group and click Add.
5. Click OK.

Excluding Users from My Organization

If the default option for the Users area is selected (Users, user groups and LDAP groups defined in the Security Management Server), you can define exclusions to this definition of My Organization.

For example, you can exclude the CEO. This lets the CEO send any data without having it scanned.

To exclude users from My Organization:

1. Open Data Loss Prevention > My Organization.
2. In the Users area, click Exclusions.

   The User groups and Users window opens.

3. Select the listed items that you want to exclude from My Organization.
4. Click Add.
5. Click OK.

Defining Internal Networks

By default, My Organization includes networks, network groups, and hosts that are defined as being behind the internal interface of the DLP gateway.

If you choose to define My Organization by naming specific networks or hosts, any internal networks or hosts that you did not name will not be considered internal by DLP.

Note - The networks and hosts must already be defined in the Objects Tree of SmartConsole.

To define specific networks and hosts:

1. In SmartConsole, open the Data Loss Prevention tab.
2. Click My Organization.
3. In the Networks area, select These networks and hosts only.
4. Click Edit.
5. In the Networks and Hosts window, select items from the list of defined networks and hosts and then click Add.
6. Add as many items as needed to define My Organization.
7. Click OK.

Excluding Networks from My Organization

In large sites it is often more efficient to define exclusions to the internal interfaces than to define the internal environment piece by piece.

If the default option in My Organization is selected (Anything behind the internal interfaces of my gateways), you can define exclusions to internal Networks.

Any network, network group, or host that you define as an exclusion will be recognized by Data Loss Prevention as Outside My Org. To scan data sent from these networks, you must change the default Source of rules from My Org to the network object.

To exclude networks from My Organization:

1. Open Data Loss Prevention > My Organization.
2. In the Networks area, click Exclusions.

   The Networks and Hosts window opens.

3. Select the listed items that you want to exclude from My Organization.
4. Click Add.
5. Click OK.

Defining Internal VPNs

Remote Access communities in VPN of My Organization are supported only in Office Mode.

To configure Office Mode for support of Remote Access communities:

1. In SmartConsole, click Gateways & Servers and double-click the Security Gateway.

   The gateway window opens and shows the General Properties page.

2. From the navigation tree, click VPN Clients > Office Mode.
3. Select Perform Anti spoofing on Office Mode addresses.
4. In Additional IP Addresses for Anti-Spoofing, select the applicable network object.
5. Click OK and publish the changes.

To include VPN traffic in My Organization:

1. In SmartConsole, select Security Policies > Shared Policies > DLP and click Open DLP Policy in SmartDashboard.

   SmartDashboard opens and shows the DLP tab.

2. From the navigation tree, click My Organization.
3. In the VPN section, make sure the All VPN traffic is selected.
4. Click Save and then close SmartDashboard.
5. From SmartConsole, Install Policy.

Excluding VPNs from My Organization

To discover VPNs known to DLP:

1. In SmartConsole, click Gateways & Servers, and find the VPN gateway that protects the DLP gateway.

   For an integrated DLP deployment, this is the DLP gateway itself. The protecting VPN gateway includes the IP address of the DLP gateway in its encryption domain.

2. Double-click the VPN gateway.

   The gateway window opens and shows the General Properties page.

3. From the navigation tree, click IPSec VPN.

   The DLP gateway is aware of the VPN communities that are shown in this page.

To exclude VPNs from My Organization:

1. In SmartConsole, select Security Policies > Shared Policies > DLP and click Open DLP Policy in SmartDashboard.

   SmartDashboard opens and shows the DLP tab.

2. From the navigation tree, click My Organization.
3. In the VPN section, click Exclusions.

   The VPN Communities window opens.

4. Select the VPNs that you want to exclude from My Organization and click Add.

   Ignore the VPNs that are not relevant to the protecting VPN gateway; they are excluded by default.

5. Click Save and then close SmartDashboard.
6. From SmartConsole, Install Policy.

Data Loss Prevention Policies

The DLP policy defines which data is to be protected from transmission, including: email body, email recipients, email attachments (even if zipped), FTP upload, web post, web mail, and so on. The policy determines the action that DLP takes if a transmission is captured.

Manage the rules of the policy in the Data Loss Prevention > Policy page.

Overview of DLP Rules

A Data Loss Prevention rule is made up of:

• Flag - your indicator for rules to handle. No Flag, Follow Up, Improve Accuracy - mark rules for scanning in Policy and for access from the Overview page.
• A Data Type to protect - some Data Types are complex, others are as simple as one word. You can make your rule base as long as needed.
• A transmission source - by default, your entire internal organization (the policy will check all data transmissions coming from any user in your organization containing the defined Data Type), or a selected user, group, segment, or network.

  Best Practice - Create user groups for data access. For example: users with access to highly sensitive data, newly hired employees, employees on notice of termination, managers with responsibilities over specific types of data.

• A destination - by default, anything that is outside of the internal organization. You may choose to make the destination any network object defined in the SmartConsole to protect data transfer between groups of users inside your organization. You can make the destination a specific domain, such as Gmail or Hotmail for private emails.
• A protocol - by default Any, but you can choose to have the rule apply only to HTTP posts, or only to FTP uploads. To view the protocol column, right-click the heading line of the policy and select Protocol.
• Exceptions - If exceptions to this rule have been added to allow specific traffic. A value valid for the main rule is valid in an exception. Be careful! Exceptions are matched first; if a data transmission matches an exception in any place of the policy, it will not be checked further.
• An action to take - DLP response if a data transmission matches the other parameters of the rule: detect and log, inform sender or data owner, delay until user decides, or prevent the transmission.
• A tracking option - when data transmissions match Data Loss Prevention rules, they are logged as incidents in the Logs & Monitor view by default. You can add email notifications here and other tracking methods.
• A severity level - set the severity of the rules in your policy, to help in filtering and reporting while auditing Data Loss Prevention incidents through the Logs & Monitor view. High and Critical rules should be the first that you audit and, if you decide to keep this severity level, they should be moved from Detect to Ask as soon as your users understand what is expected of them.
• Install On - Security Gateways with Data Loss Prevention enabled. Default value is all DLP Security Gateways.
• A time range - a period of time during which the DLP rule is enforced.
• Category - Label for types of rules. Built-in rules have default categories. To change the category of a new rule, right-click and select from the list.
• Comment - Optional notes for rules.

The rule base of the DLP gateway should look familiar if you have experience with the Check Point Firewall rule base, but there are differences.

• DLP rules are based on Data Types, created through an easy-to-use wizard. Protocols (services) used to transmit data and the people who transmit data are secondary, defining issues.
• DLP rules usually scan communications from the internal organization going out. Firewall rules usually scan communications from outside coming into the internal network.
• The method that DLP rules match data is different.

DLP and Identity Awareness

When Identity Awareness is enabled, you can create access role objects and use them in the DLP policy. When Identity Awareness is enabled, in DLP:

• Emails notifications can be sent when DLP violations occur using the FTP or HTTP protocols. (Before R76, DLP email notifications were only sent when the violation occurred on the SMTP protocol.)
• Access role objects can be used in the Source or Destination column of a DLP rule.
• The Action column of a DLP rule can redirect unknown users to the Identity Captive Portal for authentication.
• The Logs & Monitor logs identify users that violate the DLP policy.

Email Notifications for FTP and HTTP DLP violations

In addition to email notifications on SMTP DLP violations, you can configure notifications to be sent when the violation occurs using the FTP or HTTP protocols. To send these notifications, you must:

1. Enable Identity Awareness.
2. In Data Loss Prevention Additional Settings Advanced > Email Notifications, select:
   • Web
   • FTP

When you select Web or FTP in the Email Notifications area, the Web and FTP options are also selected in the Learn User Actions area. This lets DLP learn how the user decides to handle a DLP incident and apply the same decision for subsequent messages.

Access Roles in the Source or Destination of a Rule

Access role objects can be used in the Source or Destination column of a DLP rule. The presence of access roles makes DLP user aware. The access role object identifies users, computers, and network locations as one object. You can select specified users, user groups, or user branches as the object.

Redirection to an Authentication Captive Portal

Captive Portal redirection only applies to the HTTP and HTTPS protocols. Redirection occurs when the sender is unknown (the IP address does not map to any user in the AD) and the Action of the DLP rule is Identity Captive Portal and one of these conditions is also met:

1. No access role objects are in the Source or Destination column of the policy rule but the Source and Destination do match those of the HTTP connection being examined by the DLP gateway.
2. The Source column of the DLP rule contains an access role.

Redirecting to the Captive Portal lets DLP:

• Identify unknown users and log their FTP and HTTP activity

  Once known, these users can be matched against access roles in the policy.

• Send notification emails for FTP and HTTP violations

  Note - Captive Portal redirection occurs: Regardless of the data transferred in the message Before the data payload of the connection is scanned for violation of a policy rule

To Redirect HTTP traffic to the Captive Portal:

1. Right-click the Action and select Identity Captive Portal.
2. Select Redirect HTTP connections to an authentication Captive Portal.
3. Click OK.

   The Action column shows Identity Captive Portal.

Identifying Users Behind a Proxy

If your organization uses an HTTP proxy server behind the gateway, the identities of users behind the proxy will remain hidden unless you configure:

• The company proxy server to use an X-Forwarded-For HTTP Header
• The DLP gateway to use the X-Forward-For HTTP header.

You can also configure the DLP gateway to strip the X-Forward-For header in outgoing traffic. Without the header, internal IP addresses are not be shown in requests to the internet.

To use X-Forwarded-For HTTP header:

1. Configure your proxy server to use X-Forwarded-For HTTP Header.
2. In SmartConsole, on the Identity Awareness page of the DLP gateway object, select Detect users located behind HTTP proxy using X-Forward-For header.
3. To configure the DLP gateway to stop the X Forwarded-For header showing internal IP addresses in requests to the internet, select Hide X Forward-For header in outgoing traffic.
4. Install the policy.

Example DLP rule with Identity Awareness

These three rules show how Identity Awareness works with DLP:

Rule 1

Data	Source	Destination	Protocol	Action
PCI – Credit Card Numbers	Finance_Dept (Access Role)	Outside My Org	Any	Prevent

In this rule:

• Access role objects are used in the Source column. This rule will prevent a known user in the Finance department from sending credit numbers outside of the organization. Known users that are not listed in the access role will not be prevented from sending credit card numbers outside of the organization.
• An unknown user (a computer with an IP address that is not mapped to any user in the Active Directory) attempting to send credit card numbers outside of the organization will not be stopped by this rule.
• A user that is known but not part of the access role will not be prevented from sending credit card numbers.
• There is also no redirect to the Captive Portal so that the unknown sender cannot be identified.

Rule 2

Data	Source	Destination	Protocol	Action
PCI – Credit Card Numbers	My Organization	Outside My Org	Any	Prevent Identity Captive Portal

In this rule:

• Known users inside the organization will be prevented from sending out credit card data, and receive email notification of the policy violation.
• Unknown users inside the organization sending out all types of data will be directed to the Captive Portal for identification. Once identified, DLP scans the data for a possible violation.

  Note - Enabling Identity Captive Portal on this rule means that HTTP or HTTPS connections passing from inside to outside of the organization must be identified with a user.

Rule 3

Data	Source	Destination	Protocol	Action
PCI – Credit Card Numbers	Finance_Dept (Access Role)	Outside My Org	Any	Prevent Identity Captive Portal

In this rule:

• A known user in the Finance department will be prevented from sending credit numbers outside of the organization.
• An access role in the Source (plus Captive Portal in the Action column) means that for HTTP connections there is a redirect if the source user is unknown and the destination matches the destination specified by the policy
• A user that is known but not part of the access role will not be:
  • Prevented from sending out credit card numbers
  • Redirected to the Captive Portal.

DLP Rule Matching Order

The DLP rule order does not matter. In this rule base, each transmission is checked against each rule.

Because the rule order does not matter, you can change the display of the DLP policy for your convenience.

• To show rules in a different order, click a column header. The rules are sorted by the selected column.
• To show rules in groups, select an option from the Grouping menu in Data Loss Prevention > Policy.
• To show or hide columns, right-click the policy column header and select an item.
• To change the arrangement of columns, drag a column to a new position.

DLP Rule Matching with Exceptions

If data matches a rule, and the rule has exceptions, the exceptions to a rule are checked. If the data matches any exception, DLP allows the transmission.

For example, consider a rule that captures emails containing more than fifteen employee names in the body of a message. If a user in the HR department sends a list of twenty employees to an outside address (such as their contractor), the email will be allowed without incident logging or any Data Loss Prevention action taken - because the same rule has an exception that allows users in the HR group to send lists of employee names outside your organization.

If the data matches multiple rules, one with an exception and one without exceptions, the rule without exceptions is used.

DLP Rule Matching with Multiple Matches

If the data matches multiple rules, the most restrictive rule is applied.

For example, if a user sends an email with an attached unencrypted PDF, the email can match two rules. One rule is Detect: detect emails to an external destination that contain PDF files. A second rule is Ask User: delay emails with PDF files that are unencrypted, until the user specifies that it is good to send. This rule will also inform the Marketing and Technical Communications manager that the PDF was released from the company to an external destination.

In this case:

1. The email is quarantined.
2. The user gets a notification and has to make a decision relating to what to do.
3. The data owner gets a notification.
4. The rule violations (one for Detect and one for Ask User) are logged.

Rule Actions

For each DLP rule that you create for a Data Type, you also define what action is to be taken if the rule matches a transmission.

Action	Description
Detect	The transmission is passed. The event is logged and is available for your review and analysis in the Logs & Monitor view. The data and the email itself, or the properties of the transmission if not email, are saved in storage for future reference. You can choose to notify Data Owners of the event. This is true for all the following actions as well.
Inform User	The transmission is passed, but the incident is logged and the user is notified.
Ask User	The transmission is held until the user verifies that it should be sent. A notification, usually with a remediation link to the Self Incident Handling portal, is sent to the user. The user decides whether the transmission should be completed or not. The decision itself is logged in the Logs & Monitor Logs view under the User Response category. Administrators with full permissions or with the View/Release/Discard DLP messages permission can also decide whether the transmission should be completed or not from the Logs & Monitor view. This can be useful in the event that a user is not available to make sure if it should be sent.
Prevent	The data transmission is blocked. Best Practice - Check Point does not recommend using the Prevent action as a first choice. The action may prove disruptive. To improve the accuracy of rule matches, set rules to Prevent only when you have tested them with the less strict actions over a reasonable amount of time.
Watermark	Tracks outgoing Microsoft Office documents (Word, Excel, or PowerPoint files from Office 2007 and higher) by adding visible watermarks or invisible encrypted text. By default, all rules are created without a watermark action. Watermarks can be created and edited without having to apply them. Once a watermark object is created, it can be reused in multiple rules.

Note - If data matches multiple rules, the rule of the most restrictive action is applied. The order from most restrictive to least is: Prevent, Ask User, Inform User, Detect.

Managing Rules in Detect

The Detect action is set to rules by default because it is the least disruptive of the action options. When Data Loss Prevention discovers a transmission containing protected data, an incident is logged in the Logs & Monitor Logs view and other logging actions (if any) are taken.

You might want to leave all your rules in Detect at first. Then you can review the logs and decide which rules are needed according to your organization's actions. This could save you and your users a lot of time and make your explanations of what they need to know and what to do much more specific to their needs.

Setting Rule Tracking

A primary consideration for creating Data Loss Prevention rules is how to audit incidents.

In the rule base of the Data Loss Prevention policy, the Track column offers these options:

Option	Meaning
Email	Sends an email to a configured recipient
Log	Records the incident in the Logs & Monitor view (All the other tracking options also log an incident).
Alert	Opens a pop-up window in the SmartView Monitor.
SNMP Trap	Sends an SNMP alert to the SNMP GUI. This uses the fwd process, to run the internal_snmp_trap script that sends an ID, the trap type, source port, community, and host name.
User Defined (alert)	Sends one of three possible customized alerts. The alerts are defined by the scripts specified in the main Menu > Global Properties > Log and Alert > Alert Commands. The alert process on the Log server runs the scripts.
Store Incident	Determines how the data should be stored and deleted (if at all). The options are: Yes Only as text Don't store (depending on other conditions) Delete

Store Incident

Store Incident tracking options determine how data that matches a DLP rule is stored (or not stored). These options are available:

Store Option	Meaning
Yes	Email data is stored as an .eml file FTP data is stored in the .zip format HTTP Text entered onto a web page is saved as HTML and viewed in the default browser when the data is opened through a link in the Log Details window. An uploaded file is stored in the .zip format Note: For FTP and HTTP, only those elements of the message that violate DLP rules are stored.
Only as Text	Textual data extracted from the email (header and body) and the attachment is stored as HTML, but only those sections that triggered the violation. FTP data is stored as HTML. HTTP text entered onto a web page is saved as HTML and viewed in the default browser when the data is opened through a link in the Log Details window. Note: For FTP and HTTP, only those elements of the message that violate DLP rules are shown in the HTML page which stores the information.
Don't Store	When the rule is matched, the incident is logged and the data deleted so that it cannot be viewed in the Logs & Monitor view. Note: The deletion of the data can be prevented by other store options. If a scanned message matches a number of store incident options, the option with highest priority has precedence: Delete - Priority 1 Yes - Priority 2 Only as Text - Priority 3 Don't Store - Priority 4
Delete	Logs the incident and immediately deletes the data. Select this example for sensitive data such as credit card numbers. Note: If the email that contains the sensitive data also has an attachment that must be watermarked, the email is not deleted. The email is saved but you cannot view it with the Logs & Monitor view.

Resolving Store Incident Conflicts

If a scanned message matches a number of different DLP rules, and each rule has a different store option, the option with highest priority has precedence. For example, if an email matches these rules:

Rule	Store Incident Option	Priority
Rule_1	Only as text	3
Rule_2	Yes	2
Rule_3	Don't store	4

The store incident option related to Rule_2 has the highest priority. The data will be stored even though the email matched a rule (Rule_3) configured to delete the data.

Changing the Priority

The Only as Text store option can be configured to have a higher priority than Yes. To change the priority:

1. On the gateway, open: $DLPDIR/config/dlp.conf

   Each message protocol has its own section. For example:

   )

   :ftp (

   :enabled (1)

   :maximum_words_to_log (14)

   :maximum_chars_to_words_in_log (490)

   :cleanup_session_files (1)

   :save_incident_quota_percentage (85)

   :allow_append_cmd (0)

   :view_incident_dispute_option (yes)

   )

2. Search for: view_incident_dispute_option

   The default value is Yes.

3. For all protocols (SMTP, FTP, HTTP), change Yes to Text.
4. Save and close dlp.conf.

Setting a Time Restriction

The Time column in the DLP Rule table holds a time object or group of time objects. The time object is the same time object as used in the Firewall Rule Base.

• A time object defines:
  • A time period during which the DLP rule is enforced (in hours) or
  • A time period defined by activation and expiration dates.
• Time objects apply for each rule.

  Notes - A DLP rule that incorporates a time object will not be enforced once the time object expires. Time objects are not supported for UTM-1 Edge appliances and QoS. Installing a DLP policy that contains a time object in a rule will result in failure. An object that does not have an activation or expiration date is always active.

To create a time object:

1. Open the Data Loss Prevention tab > Policy page.
2. Right click in the Time column of a rule.
3. From the pop-up menu, select Time.

   A window opens showing a list of existing time objects. You can select an existing time or create a new one.

   Note - Existing time object can be reused.

4. Click New > Time.
5. The Time Properties window opens.
6. On the General page, enter a name for the object
7. On the Time page:
   1. In the Time Period section, configure when the time object activates and expires.
   2. In the Restrict to specific hour ranges section, specify up to 3 ranges when the time object enforces the DLP rule. During these periods, the related DLP rule is enforced. The time specified here refers to the local time on the Security Gateway.
   3. Specify days.

      The days when the time object enforces the DLP rule. The time object can be enforcing the DLP rule each day, specified days of the week, a specified month or all months.

8. Click OK.

If you have more than one time object, you can merge them into a group. When a condition in one of the time objects in the group is met, the DLP rule is enforced.

To create a time group object:

1. Open the Data Loss Prevention tab > Policy page.
2. Right click in the Time column of a rule.
3. From the pop-up menu, select Group.

   The Time Group window opens.

4. Enter a name for the group.
5. Add or Remove time objects from the group.
6. Click OK.

Supported Archive Types

The DLP blade supports the extraction and scanning of these compressed archive types:

• zip
• zip-exe
• gzip
• rar
• tar
• jar
• 7z

Selective Deployment - Gateways

For any rule in the policy, you can choose that it be deployed on specific Enforcing Gateways.

To deploy a rule on specific Enforcing DLP Gateways:

1. In SmartConsole, open Data Loss Prevention > Policy.
2. In the rule you want, click in the plus in the Install On column.

   Defined DLP Gateways appear in a menu.

3. Select the Gateways on which you want this rule to be deployed.
4. Install Policy on the DLP gateway.

Selective Deployment - Protocols

Check Point Data Loss Prevention supports various data transmission protocols.

It is recommended that you enable protocols as needed in your deployment. Start with only SMTP. Observe the logs on detected emails and user responses for handling them. Later, add FTP to the policy. For emails and large uploads, users do not expect instant responses. They can handle incidents in the Portal or UserCheck client for emails and uploads without disturbing their work, especially if your users know what to expect and how to handle the incidents.

HTTP, which includes posts to web sites, comments on media sites, blogging, and web mail, is another matter. Users do expect that when they press Enter, their words are sent and received instantly. If an employee uses HTTP for mission-critical work, having to decide whether a sentence is OK to send or not every instance is going to be extremely disruptive. Therefore, it is recommended that you enable HTTP only after you have run analysis on usage and incidents.

You can also enable inspection for Exchange Agent emails and the HTTPS protocol.

To select protocol deployment for all gateways:

1. In SmartConsole, open Data Loss Prevention.
2. Expand Additional Settings and click Protocols.
3. Clear the checkbox of any of the protocols that you do not want to inspect.

Important - If you clear all of the protocol checkboxes, Data Loss Prevention will have no effect.

To select protocol deployment per gateway:

1. In SmartConsole, open the Firewall tab.
2. In the Network Objects list, double-click the gateway.

   The properties window of the gateway opens.

3. In General Properties > Software Blades > Network Security, make sure Data Loss Prevention is selected.
4. Open the Data Loss Prevention page.
5. In the Protocols area, select one of the following:
   • Apply the DLP policy on the default protocols - as selected in the Data Loss Prevention tab, according to the previous procedure.
   • Apply the DLP policy to these protocols only - select the protocols that you want this gateway to check for the Data Loss Prevention policy.

Auditing and Analysis

In the process of Data Loss Prevention, analysis of incidents is essential.

Before you begin, make sure that the severity of rules in the policy is accurate.

While auditing rules in the Logs & Monitor view, use the Follow Up flag. If you find an incident or a set of incidents that you want to fine-tune, or for which you doubt whether the action is best, you can set the Data Type or the rule to Follow Up.

Using the Logs & Monitor Logs View

The DLP gateway issues logs for various events.

To open the Logs & Monitor Logs view:

Go to the Logs & Monitor > Logs > Queries > DLP.

The Data Loss Prevention logs are categorized for filtering.

To see more information:

1. Click DLP Log.

   The DLP Log Details window opens, displaying more information about the incident in an easy-to-read format, with links back to the Data Loss Prevention tab in SmartConsole or to specific information on the Data Type.

   From the log of a specific incident you can open the actual data that caused the incident. You should not have to review most of the incidents manually, but the original transmission (for example, the email or its attachment) is kept for you if there is a question from the sender or the data owners.

   Because personal emails and web posts may be captured and stored for viewing, you must let the users know that this may happen. Failure to do so may cause your organization issues with local privacy laws.

Note - To view DLP incidents in the Logs & Monitor view or SmartEvent SmartConsole application on a Windows 7 computer, Microsoft Office 2010 is required. DLP incidents may not show if the incidents (which are in EML file format) are associated with any other application.

DLP Actions

Actions for DLP incidents include:

DLP Action	Description
Ask User	DLP incident captured and put in Quarantine, user asked to decide what to do.
Do not Send	User decided to drop transmission that was captured by DLP. An administrator with full permissions or with the View, Release or Discard DLP messages permission can also drop these transmissions. Email notification is sent to the user.
Send	User decided to continue transmission after DLP capture. An administrator with full permissions or with the View/Release/Discard DLP messages permission can also decide to continue transmission. Email notification is sent to the user.
Quarantine Expired	DLP captured data transmission cannot be sent because the user did not make a decision in time. Expired incidents may still be viewed, until they are deleted (routine cleanup process).
Prevent	DLP transmission was blocked.
Allow	DLP transmission was allowed; usually by exception to rule.
Inform User	DLP transmission was detected and allowed, and user notified.
Deleted Due To Quota	DLP incidents are deleted from gateway for disk space.

DLP General Columns

DLP incidents can show some or all of these columns and are available to all administrators.

DLP Columns	Description
Incident UID	Unique ID of the incident.
DLP Action Reason	Reason for the action. Possible values: Rule Base, Internal Error, Prior User Decision
Related Incident	Internal incident ID related to the current log.
DLP Transport	Protocol of the traffic of the incident: HTTP, FTP, Email.

Using the Incident UID as a key between multiple logs:

Each DLP incident has a unique ID included in the log and sent to the user as part of an email notification. User responses (Send, Do not Send) are assigned the same Incident UID that was assigned to the initial DLP incident log.

If a user/administrator sends an email with a DLP violation and then decides to discard it, two logs are generated. The first log is a DLP incident log with Ask User action and is assigned an Incident UID. On the user action, the second log is generated with the same UID, with the Do not Send action.

Each matched Data Type generates its own log. The gateway makes sure that all the Data Type logs of one incident show the same unique Incident UID and rule action (Prevent, Ask, Inform, or Detect). This happens also if Data Types were matched on different rules. The same action shown for an incident is the most restrictive.

For example, in a case that a transmission matches two Data Types. Each Data Type is used in a different rule. The action of one rule is Prevent. The action in the second rule is Detect. The two logs that are generated will show Prevent as the action. The action implemented will be Prevent. The log of the Detect rule will show Rule Base (Action set by different rule) in the DLP Action Reason column.

DLP Restricted Columns

These columns are restricted to administrators with permissions.

Restricted Filters	Description
UserCheck
User Response	Comment entered by the user in the text box shown in the UserCheck notification.
UserCheck Message to User	The message shown to the user.
Interaction Name	The interaction name as shown in SmartConsole.
Fingerprint
Matched File	The file name and path in the scanned fingerprint repository that matches the inspected message.
Matched File Percentage	How much is this file similar to Matched File. In "exact match" this will always be 100%.
Matched File Text Segments	In a partial match, the number of file parts/segments that are matched between the Matched File and the inspected file (parts/segment may overlap).
DLP Type
DLP Rule Name	Name of the DLP rule on which the incident was matched.
Message to User	Message sent, as configured by administrator, for the rule on which the incident was matched.
DLP Words List	If the Data Type on which the incident was matched included a word list (keywords, dictionary, and so on), the list of matched words.
DLP Relevant Data Types	If matched Data Type is a group Data Type. This field specifies which Data Types from that group were matched.
User Information
DLP Recipients	For SMTP traffic, list of recipients of captured email.
Mail Subject	For SMTP traffic, the subject of captured email.
Scanned Data Fragment	Captured data itself: email and attachment of SMTP, file of FTP, or HTTP traffic.
More
UserCheck	A Boolean field that shows if the log is produced by UserCheck or by another DLP.
Data Type Name	Name of the matched Data Type.
Data Type UID	Internal ID of the Data Type on which the incident was matched.
DLP Categories	Category of Data Type on which the incident was matched.
DLP Template Score	A measurement, expressed as a percentage, that shows how closely a document matches the template file. 0% - The document and template are very different. 100% - The document and template are a close match.

Event Analysis Views Available in SmartConsole

As of R80, the Event Analysis views of the SmartEvent GUI have been incorporated into the SmartConsole Logs & Monitor view. They provide advanced analysis tools with filtering, charts, and statistics of all events that pass through enabled Security Gateways.