Policy Guide › How Policy Works › Policy Processing

Policy Processing

Every day, CA DataMinder server and endpoint agents analyze thousands of events. Most of these are benign and do not need to be under policy control. So how does CA DataMinder separate those events that require policy from those that do not without causing massive disruption to an organization's daily work?

When CA DataMinder detects an event, whether it is an email, IM conversation, a print job, or a file, it goes through the following steps:

1. First, it identifies the event owner. For example, this may be the sender of an outbound email.
2. After identifying the owner, it associates the owner with a CA DataMinder user account.

   Typically, each employee has their own user account. If CA DataMinder identifies an employee as the event owner, it can quickly locate that employee's user account.

   For events that cannot be associated with an employee, such as emails sent from outside your organization or files stored on your network, CA DataMinder typically assigns a default owner. This default owner corresponds to a 'system' user account (such as the External Sender or DefaultFileUser) rather than the policy for an actual user.

   This process of associating the owner (1) with a CA DataMinder user account is very fast. Each CA DataMinder policy engine contains a record of the entire user hierarchy (2), and this record is continually kept up to date. Each endpoint agent identifies the relevant user account when the user first logs on. CA DataMinder applies that account's user policy to the event.

   

   Policy processing procedure: CA DataMinder associates the event owner (1) with an account in the CA DataMinder user hierarchy (2). It then applies this account's policy (3). If a policy trigger fires, it immediately applies the appropriate action, such as a blocking (4).

3. After locating the correct account in the user hierarchy, CA DataMinder applies that account's user policy to the event as follows:
   1. If the policy engine or (this is unlikely) the endpoint agent does not already hold a cached copy of the required user policy, it requests the policy from the CMS.
   2. CA DataMinder then identifies the relevant triggers within this policy. For example, if CA DataMinder is scanning a file system, it knows that it only needs to apply Data At Rest triggers. All other trigger types are immediately disregarded. It also immediately disregards all disabled triggers.
   3. Finally, it tests all the relevant triggers. That is, it applies each trigger to see whether the event causes the trigger to fire. Triggers are applied in the order in which they are listed in the user policy.
4. When CA DataMinder applies an individual trigger, it tries to determine as fast as possible whether the trigger will fire. It therefore applies the simplest, fastest trigger criteria first. If an event fails to match these criteria, CA DataMinder knows that the event is benign and can be exempted from further policy processing. CA DataMinder then applies the next trigger listed in the user policy.
5. After applying all the relevant triggers, CA DataMinder applies the corresponding control actions if one or more triggers fired (if no triggers fired, no actions are applied).

   It applies the control actions in order of priority. The order in which multiple control actions are applied is determined by the control action number. The control action with the lowest number takes precedence. For example, Action 1 always gets applied before Action 2 or Action 3.

6. When all control actions have been performed, CA DataMinder then performs any required capture actions.