Controlling access to processes
Malicious programs can strike by accessing legitimate processes to retrieve sensitive data or inject malicious code into them.
Rules that regulate access to SES Evolution processes enable protection against such attacks without completely blocking inter-process communication, some of which is legitimate.
Access to a process or thread cannot be fully blocked, but you can restrict privileges during this operation.
These rules apply only to applications, not drivers.
EXAMPLE
Blocking access to the memory of a process can prevent passwords from being stolen from a browser's memory when it is open.
Other examples are given at the end of this section.

An application identifier must be created beforehand for the processes to be protected and for legitimate processes allowed to access other processes. For more information, refer to the section Creating application identifiers.

- Select Policies and click on your policy.
- Select a rule set.
- Click on the Application > Process access tab.
- If you are in read-only mode, click on Edit in the upper banner.
- Click on Add a rule (Process access).
A new row appears. - Click on
in the application ID area and select the process(es) to protect.
- In Default behavior, choose the behavior for each action (in audit rule sets, only the Read action can be configured):
- Read: choose what the rule must do when it reads the memory of the process.
- Changes: choose what the rule must do when the memory of the process is modified.
- Execution flow tampering: a program that takes control of a process can modify its execution pointer. Choose what the rule must do when the execution flow of the process is tampered with.
- Handle duplication: choose what the rule must do when a process attempts to duplicate a resource that belongs to another process.
- Click on + Add a specific behavior and choose the process(es) that you want to exclude from the default behavior. Select the behavior for each case.
- In the upper banner in the rule, you can:
- Make the rule passive. 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, find out their impact, and make the necessary adjustments before disabling Passive rule mode. For further information on testing rules and policies, refer to Testing security policies. - Indicate whether the rule must generate an incident when it is applied.
- Select the log settings that this rule will send.
- Specify whether an action must be performed when a log is sent for this rule. You can choose to display a notification on the agent and/or run a script.
- Enter a description to explain what this rule aims to achieve.
- Make the rule passive. 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.
- The row number of each rule appears on its left. Rearrange the sequence of your rules if you need to, by clicking on the arrows above and below the row number.
- Click on Save at the top right of the window to save changes.
EXAMPLES
You can block any application from accessing the password manager to prevent hackers from accessing passwords or injecting code into its process. In this case, choose the password manager from the list of processes to be protected and select Block for all actions in the default behavior. Do not define any specific behavior.
You can also block execution flow tampering for major applications such as business applications, to prevent hackers from shutting them down or suspending them.