Data Collection

Data collection settings impact how data is stored in the database.

Regardless of the user's option, all low-level raw events are collected on the endpoints, sent to the server and processed by the rule engine, which generates detections when appropriate.

When detection is generated for a specific event, this specific event is also stored in the database regardless of the selected data collection option. For the events processed by the rule-engine without triggering detection, data collection settings apply as follows:

Store all available data

All collected low-level raw events are stored in the database. This option creates a vast database but allows detailed investigation of possible incidents because the analyst can see everything that happened on the system, regardless of whether it was previously flagged as suspicious by the product or not.

This option allows using all the product's features, such as retroactive search, execution of Threat Hunting queries or a re-run of existing or custom rules on the data.

Store most important data

Stores all the data related to the processes (for instance, you will see all processes executed on the endpoints along with their properties, such as command line, etc.). It also limits the storage of low-level events generated by the processes only to those generating the detection. It means the analyst will see a complete process tree during the investigation (be aware that the data retention setting applies here). Still, for the actions of the processes (such as writing to the disk, writing to the registry, network connection etc.), the analyst will see only those explicitly caught by the rule.

This may turn into a situation where you will see a network connection (detected by the rule) but will not see that the downloaded file was written to the disk (unless another rule does not detect a specific file write). Similarly, you will not be able to retroactively search for IOCs that are not connected to the process/file and were not detected by the rule previously. For example, you will find a file hash or command line fragment but not the registry write anymore.

Suppose you are missing some important events using this option. In that case, you can still customize this setting by creating custom rules (typically with low severity, which you will ignore during the monitoring) that will solely detect events of your interest to save these low-level events to the database.

Store only data directly related to detections

This option stores only those low-level event data explicitly caught by the rule, creating the smallest database in this mode. It applies to the actions (such as writing to the disk, writing to the registry, network connection etc.) and to the processes themselves (process execution, command line, etc.). However, when detection is triggered for the process, process-related data for the process itself, and with the process-related data about all the processes upwards, the process tree and direct child processes will be stored. (Storing process-related data for these additional processes will not store other data, such as "action-related" events.) The database will not store information about all the other processes.

That means that similarly to the option "Store most important data" you may not see some actions and, in this case, also processes that were not explicitly caught by the rule (and are not in that stored part of the process tree mentioned above) with the corresponding consequences. The process tree will not show processes for stored data.

The ability to retroactively search for IOCs would be minimal since you will see neither IOCs related to actions nor IOCs related to process properties (command line, etc.) unless they were detected by the rule previously.

As mentioned in the previous option, you can customize this setting by creating custom rules (typically with low severity, which you will ignore during the monitoring) that will detect events of your interest (including process execution) to save these low-level events to the database.

Store most important data/Store only data directly related to detections

Some features are limited:

•Events view

•Aggregated events view

•Background tasks

•Scripts view

•Search

The goal is to control the database size. The user is making a trade-off between database size and some advanced options.

Store only data directly related to detections option is recommended for IT Administrators.

To change what data is stored in the database, go to Admin > Server Settings in the Database Collection section.

Data Retention

Select how long the data should be in the database stored. The longer the period, the more extensive database will become before old data is purged.

Choose how long you want the data in the database to be stored. By default, it is three months.

Choose how long you want the low-level data in the database to be stored. By default, it is one month. Low-level data accounts for most of the database size and should be kept as brief as possible. It only limits detailed investigations of data not identified as suspicious by the product when removed.

This setting can be changed in Admin > Server Settings in the Database cleanup section.

ESET Inspect Connector collects information about

•the start and termination of a process running on a workstation (including metadata of such executables)

•dynamically loading libraries and dynamically loading drivers (including metadata of such libraries and drivers)

•events when executable files are being saved to the disk

•file modification (including all files present on the disk)

•events when a file (that is important from a security point of view) is being opened or accessed by a user or process (for example, files containing password information used by popular web browsers)

•a modification to registry entries

•network connections

•any code injections to any running processes

•the creation of named pipes

•the creation of users and groups

•users' logins

•WMI executions and queries

˄˅