Policy Guide › How Policy Works › Policy Processing

Policy Processing

Every day, CA Data Protection 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 Data Protection separate those events that require policy from those that do not without causing massive disruption to an organization's daily work?

When CA Data Protection 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 Data Protection user account.

   Typically, each employee has their own user account. If CA Data Protection 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 Data Protection 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 Data Protection user account is very fast. Each CA Data Protection 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 Data Protection applies that account's user policy to the event.

   

   Policy processing procedure: CA Data Protection associates the event owner (1) with an account in the CA Data Protection 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 Data Protection 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 Data Protection then identifies the relevant triggers within this policy. For example, if CA Data Protection 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 Data Protection 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 Data Protection knows that the event is benign and can be exempted from further policy processing. CA Data Protection then applies the next trigger listed in the user policy.
5. After applying all the relevant triggers, CA Data Protection 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 Data Protection then performs any required capture actions.