Understanding the difference between protection, exception and audit rule sets

There are several types of rule sets: protection, exceptions, and audit.

They serve different purposes depending on the rule set to which the security rules belong.

  • In a protection rule set, rules can be used to block attacks on workstations, detect elevation of privileges and manage access to different applications, networks, peripherals, etc. 

  • In an audit rule set, the rules can be used to generate logs for the sole purpose of monitoring the activity of your pool, and possibly for reconstructing the context of an attack.

  • An exception rule set contains only exception rules. These are usually created from logs that you consider to be false positives. For further information, see Adding exceptions for logs.

The Threats tab of rule sets does not list exactly the same protections depending on whether it is a protection/exception set or an audit set. For more information, see the section Managing vulnerability exploitation.

Similarly, management of temporary web access and control of Wi-Fi board activation are only possible within the protection and exception rule sets.

In a protection or exception rule set, the agent evaluates the rules one by one and in the following order:

  • If an action is prohibited for a resource, the agent will generate a log, block the action and stop scanning any other rules that apply to this resource.
  • If an action is explicitly allowed for a resource, the agent will allow it and stop scanning any other rules that apply to this resource.
  • If a rule does not apply to a resource, the agent will continue scanning the rules that follow.

Protection rule sets, are used to protect your workstations against malicious behavior and restrict access to protect your assets against dangerous behavior.

Exception rule sets allow you to adjust restrictions to limit false positives.

In protection and exception rule sets, all resource and device access control rules have a Passive rule mode. Passive rules behave like standard rules but do not actually block any actions. The agent only generates logs that indicate which actions security rules would have blocked.
Use this mode to test new restriction rules, determine their impact, and make the necessary adjustments before disabling Passive rule mode.

You can also test entire rule sets or entire policies before implementing them on your pool of machines. For more information, refer to the section Testing security policies.

In audit rule sets, if Audit is selected as the action in a rule, the agent sends logs to indicate the actions performed by applications. The agent scans all the rules that follow in all cases.
Use this mode to monitor access to certain resources and send relevant information to the administrator without blocking access, so that abnormal behavior can be detected.

Audit rules can also be configured to monitor collaborators’ activity: the applications that they use most often, or the versions of the applications that they use for example.

To prevent too many logs from being generated, create precise rules that do not cover too wide a range of resources or applications.

Audit rules can be used transparently in SES Evolution if you choose not to show logs on the agent or console, or if you choose not to send them to a syslog server. However, during an attack, the logs generated and saved on the agent can help to reconstruct the context of the attack, which is illustrated in a chart. For further information, refer to the section Analyzing contexts to understand attacks.

In audit rules, each action can be set to: Allow or Audit. Allow means that the rule will not do anything. It may be useful when you want to configure a default action and one or several specific actions in a rule. You can select Audit for specific actions and Allow for the default action. It is also useful when there are several actions available for a resource and you want to monitor only one type of action.