Understanding built-in and custom security policies

SES Evolution is equipped with several built-in security policies that can block the behavior and techniques used by most malicious programs, regardless of their purpose, e.g., Trojan horses, remote control tools, ransomware, password stealers, etc. The following are built-in policies:

• Simplified default policy - enables the quick and simple deployment of SES Evolution in a pool by dedicating few human resources to it and without the need to modularly manage administration. Although it can be used without any specific configuration, you must still know how to operate the administration console to create exceptions and update policies.
• Default policy - constitutes a balanced compromise between the need for administration and the security level matching most organizations' needs. Targets companies with moderately large security teams, and which know how to handle SES Evolution administration databases.
  This security policy is applied by default to agent groups.
• Hardened default policy - raises the security level in a pool to the highest level, making administration harder. It is important that you test it with a pilot group before deploying the policy, to benefit from its policies while keeping false positives to a minimum. Used by companies with mature security teams and a well-defined security policy (e.g., an approved software catalog). It requires regular maintenance by administrators.
• Backoffice component protection policy - It guarantees the protection of SES Evolution backoffice components: the backend, agent handlers and the administration console. It contains protections from the default policy, but with the addition of several protection rules that strengthen the security of protected processes and block attempts to read or modify their configuration data.
  You can apply this policy as is to agent groups that contain backoffice components.

Built-in policies consist of built-in rule sets. For more information, refer to the section Understanding built-in rule sets.

If built-in policies do not cover all use cases, you can create custom security policies that adapt closely to your infrastructure. To do so, use the rule sets that make up the built-in policies or create your own rule sets. For more information, refer to the section Creating security policies.

EXAMPLE
Create rules to manage access to the corporate network of your mobile collaborators, or manage the use of trusted devices in your pool.