In This Section: |
After auditing incidents identified by heuristic-driven rules, you begin to understand the needs of your organization. You can add more Data Types to the DLP policy to fit known scenarios. You can set more rules of the DLP policy to Ask User, to gather incident-handling data from users and better analyze their needs.
Create the rules that make up the DLP policy. At this stage, before creating your own Data Types, you can use any of the numerous built-in Data Types.
To create DLP rules:
A new line opens in the rule base table. The order of rules in the DLP policy does not matter. Each DLP gateway checks all installed rules.
If you add multiple Data Types to one rule, they are matched on OR - if at least one of the Data Types is matched, the rule is matched.
Note - If My Organization is the Source, you can right-click and select Edit. This opens the My Organization window, in which you can modify the definition of your internal organization. However, this definition is changed for all of DLP, not just this rule. |
Outside Source - Used as a Destination of a DLP rule, this value means any destination that is external to the Source. For example, if the source of the rule is Network_A, and Outside Source is the destination, then the rule inspects data transmissions going from Network_A to any address outside of Network_A. In comparison, if the destination was Outside My Org, the rule would inspect only data transmissions going from Network_A to any address outside of the organization. Use Outside to create inter-department rules.
You can add a notification to the Data Owners: select Email and customize the notification that the Data Owners will see if this rule is matched.
A rule that uses a time object applies only to connections that begin during the specified date and time period. If the connection continues past that time frame, it is allowed to continue. The relevant time zone is that of the Check Point Security Gateway enforcing the rule.
Here are examples of how to create different types of rules that define when to examine traffic in environments you configure with the Exchange Security Agent.
Scenario 1: I want DLP to examine financial reports sent by users in the Finance department to all internal users (other than Finance department users) and external users. How can I do this?
Data |
Source |
Destination |
Exceptions |
Action |
---|---|---|---|---|
Financial Reports |
Finance_Dept |
Outside Source |
None |
Ask User |
While this rule covers the scenario example, an organization may want fuller coverage and have stricter definitions as to what traffic is allowed and by whom. The next scenario includes a wider source definition.
Scenario 2: How do I make sure that financial reports are not sent by users outside of the Finance department?
This rule applies to all traffic sent by all users in the organization (including Finance department users) to any destination.
Data |
Source |
Destination |
Exceptions |
Action |
---|---|---|---|---|
Financial Reports |
Finance_Dept |
Outside Source |
None |
Ask User |
Financial Reports |
My Organization |
Any |
1 |
Prevent |
Without an exception, if a Finance department user sends a financial report to anyone, it will match the second rule (source=My Organization) and the first rule. When data matches more than one rule, the most restrictive action is applied and multiple logs are created. So without an exception, a financial report sent from a Finance department user will be blocked based on the Prevent action in the second rule and there will be multiple logs that audit the incident.
Exception Rule:
Data |
Source |
Destination |
Protocol |
---|---|---|---|
Financial Reports |
Finance_Dept |
Any |
Any |
To summarize the results of these two rules:
Scenario 3: Financial reports can only be sent within the Finance department. Any user that sends a financial report from outside the Finance department will get a notification and has to make a decision relating to what to do. How can I do this?
Data |
Source |
Destination |
Exceptions |
Action |
---|---|---|---|---|
Financial Reports |
My Organization |
Any |
1 |
Ask User |
Data |
Source |
Destination |
Protocol |
---|---|---|---|
Financial Reports |
Finance_Dept |
Finance_Dept |
Any |
After setting up the basics of a rule, you can do more.
The name of DLP rules is not visible by default, but you may need to see or change the name. For example, if you are following the logs of a rule, you can match the name in the logs to the name in the policy.
To see rule names in the policy, right-click the rule base headers and select Name.
By default, all rules of the DLP policy scan data over the protocols as defined in the gateway properties. You can set a rule to scan only specified protocols.
To see the protocols of rules, right-click the rule base headers and select Protocol.
You can set the severity rating of a rule. This enables you to filter results in SmartEvent and provide more relevant reports with SmartReporter. You can also sort and group the Rule Base by severity.
You can flag a rule for different reminders. Flag a rule as Improve Accuracy if it did not catch data as expected. Flag a rule as Follow up, to set a reminder that you want to work on this rule or the Data Types used by it.
You can jump to flagged rules from Overview. In Policy you can group rules by flags.
For example, you create a new rule using the built-in Data Type Employee Names. You know that this is a placeholder Data Type - you are going to have to supply the list of names of employees in your organization. You flag this rule for Improve Accuracy and continue working on the rule base. Later you can find the rule for Employee Names easily, by grouping the rules by flags or by the Overview link. Then you can edit the Data Type, starting from Policy.
It is recommended that if you import Data Types from Check Point or your vendor, that you flag rules using these Data Types as Follow up, and check the results of these rules in SmartView Tracker and SmartEvent as soon as you can. This ensures that you get any needed assistance in understanding the Data Types and how they can be optimally used.
Logs and events generated from rules that are flagged with Follow up are also marked with Follow up. After you view the logs and events, you can remove the Follow up flag.
To see logs generated by Follow up rules:
To see events generated by Follow up rules:
You can define rules that you think you might need, and disable them until you want them to actually match traffic.
To disable rules:
To enable rules:
It is marked with a red X in the rule base.
Sometimes you may want to create exceptions to a rule in the DLP policy.
For example, a public health clinic that must comply with the Health Insurance Portability and Accountability Act (HIPAA), should not allow patient records to leave the clinic's closed network. However, the clinic works with a specific social worker in a city office, who must have the records on hand for the patients' benefit. As the clinic's Security Administrator, you create an exception to the rule, allowing this data type to be sent to the specific email address. You could make this case even better: in the exception, include a secondary data type is a Dictionary of patient names who have signed a waiver for the social worker to see their records. Thus, with one rule, you ensure that only records that the social worker is allowed to see are sent to the social worker's office. DLP prevents anyone from sending records to an unauthorized email address. It ensures that no employee of the clinic has to deal personal requests to have the records sent to unauthorized destination - it simply cannot be done.
To create an exception to a DLP rule:
The Exceptions for Rule window opens.
The original rule parameters appear in the table.
You can define a combination of Data Types for an exception: "allow this data if it comes with the second type of data". This could be both the original Data Type and another data type - such as patient record + patient name who signed.
To specify complex Data Types for Exceptions:
You can define an Exception to apply to data that comes from a specific user, group, or network: "allow this type of data if it comes from this person".
To specify Exceptions based on sender:
The list of senders includes all defined users, user groups, networks, gateways, and nodes. If you make any selection, the default My Organization is removed.
If My Organization is the Source, you can right-click and select Edit. This opens the My Organization window, in which you can change the definition of your internal organization. This definition is changed for all of DLP, not just this rule.
You can define an Exception to apply to data that is to be sent to specific user, group, or network: "allow this type of data if it is being sent to this person".
To specify Exceptions based on destination:
The list of recipients includes all defined users, user groups, networks, gateways, and nodes. If you make any selection, the default Outside My Org (anything that is not in My Organization) is removed.
You can define an Exception to apply to data that is transmitted over a specific protocol: "allow this data if it is being sent over this protocol".
To specify Exceptions based on protocol
The list of protocols includes DLP supported protocols. If you make any selection, the default Any is removed.