Monitoring SES Evolution agent activity

SES Evolution offers an accurate view of SES Evolution agent and console activity through various types of logs classified by severity.

Among other data, logs contain the time of an event, the agent on which it occurred, the identity of the process that performed the operation, and if operations are blocked, information about the block.

No short file names in MS-DOS 8.3 format must be visible in SES Evolution logs. Windows short file name creation must be disabled on all SES Evolution agents.

  • To do so, set the value of the NtfsDisable8dot3NameCreation registry key to 1 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.

SES Evolution agents generate several types of logs:

  • Event logs are simple logs without an attached context. They provide information, for example, on blocked user actions that are prohibited by security policies, which then makes it possible to audit certain operations, etc. Events fall under several types:

    • Protection events

    		 Generated when operations are blocked or audited by a security rule. For example, the process illegimate_process.exe attempted to run the process abused_process.exe.
    Self-protection events Generated when suspicious events are detected on the Windows system that are not associated with a security rule. For example, the user attempted to delete a protected file.
    Operational events Generated when events relating to the global operation of SES Evolution are detected. For example, the agent applied a new policy.
    External events Generated when events relating to External event forwarding and OSSEC audit rules are detected.
    Windows Defender events Generated when Windows events relating to the Virus and threat protection feature are reported.
    These logs are displayed only when the security policy contains Stormshield - Windows Defender event forwarding rule sets.
  • Alert logs indicate that an attack occurred. Such logs come with a context that makes it possible to analyze the events that led up to the malicious action.
  • Context logs are captured continuously on agents and represent an overall audit of actions performed on a workstation. They are not kept and are sent only when an alert is detected. These logs provide information on activity on the workstation just before and after the attack.

Agent logs can be read on the administration console and the agent’s interface. They can also be read on the Syslog server if you have configured one.

Depending on whether you want to make changes or only view the Agent logs panel, you must have the Agent logs-Modify or Agent logs-Display privilege.

You can configure the log levels to send to the console, the agent and the Syslog server. For further information, refer to the sections Sending logs generated by agents and Configuring log management.

The agent has a protection mechanism against log flooding.

When it detects a certain number of strictly identical or similar logs over a short period of time, it stops generating the following similar logs and counts them. In addition, it does not generate a context even if the security rule associated with the log is configured accordingly. However, the protections remain active and the other logs are still generated.

It then issues a specific log indicating the detection of the log flooding. When log generation falls below a certain threshold, it issues another log to signal the end of the generation of similar logs. Depending on the log display setting, these two logs can be displayed on the agent interface and in the administration console.

In the administration console, from the logs indicating the start and end of the log flooding, you can access the log that triggered the protection. If necessary, create an exception on this log or adapt your security policies to prevent the phenomenon from recurring. To create an exception, see Adding exceptions to logs.