Open XDR Data Format
Open XDR Data Format is based on Elastic Common Schema (ECS), which is the normalized format used for ESET Open XDR. ECS simplifies writing queries and enables correlating data across different data sources. Telemetry events, indicators and incidents are normalized into this schema across products and integrations that are part of the Open XDR Platform.
Open XDR Data is available from computers running ESET Management Agent version 13.0+ and ESET Inspect Connector 3.0+. Find more about unifying ESET Inspect and ESET PROTECT (Open XDR). |
Field Sets
ECS defines multiple groups of related fields, known as Field Sets.
•Expand all Field Sets and Extensions
Agent fields describe the software component that collects, detects, or observes telemetry events or indicators.
|
The base field set contains all fields which are at the root of the events. These fields are common across all types of events.
|
Designed to capture metadata about resources running in a cloud environment.
|
Fields describing the digital signature of a file on disk, an executable that launched a process, or a dynamically loaded library. They indicate whether the file is signed, who signed it, and whether the signature is valid and trusted. Code signature fields are expected to be nested at: •process.* •file.* •dll.*
|
Fields that describe the target of a network connection or data transfer. This typically includes details about the endpoint receiving the data, such as IP address, port, domain.
|
Fields that describe the hardware device involved in the event. This typically includes attributes such as device identifiers, model, manufacturer, serial number, and other characteristics that help identify the physical device generating or receiving data.
|
Fields describing a dynamically loaded library involved in an event. While the name is Windows-centric, this field set covers multiple platforms: •Dynamic-link library (.dll) commonly used on Windows •Shared Object (.so) commonly used on Unix-like operating systems •Dynamic library (.dylib) commonly used on macOS Following field sets can be nested under DLL field set: •dll.code_signature.* •dll.hash.* •dll.pe.*
|
ECS-specific meta information.
|
Fields that describe the details of an event or activity captured by a system or application. These fields provide context such as the event’s category, type, action, outcome, and timestamps.
|
Represents details about a file involved in the event. Following field sets can be nested under file field set: •file.code_signature.* •file.hash.* •file.pe.*
|
Contains cryptographic hash values that uniquely identify files. Hash fields are expected to be nested at: •process.hash.* •file.hash.* •dll.hash.* •email.attachments.file.hash.* •eset.executable.hash.* •eset.process.loaded_libraries.hash.*
|
Represents details about the host (computer, server, or device) where the event originated or was observed. Following field sets can be nested under host field set: •host.os.*
|
Represents details about network activity related to the event. These fields describe the protocol, direction, and identifiers for network traffic.
|
Represents details about the operating system running on a host or device. Operating system fields are expected to be nested at: •host.os.*
|
Represents metadata extracted from a Windows Portable Executable (PE) file, such as executables, DLLs, and drivers. PE fields are expected to be nested at: •dll.pe.* •file.pe.* •process.pe.*
|
Represents details about a process running on a host that is related to the event. Process fields are expected to be nested at: •process.parent.* Following field sets can be nested under process field set: •process.code_signature.* •process.hash.* •process.pe.* •process.user.*
|
Contains lists of identifiers that are related to the event. These values help with pivoting across different events that may have the same value in different fields e.g. process.hash and process.parent.hash.
|
Represents details about an indicator. These fields help identify, categorize, and correlate indicators based on the detection logic that triggered them.
|
Fields that describe the source of a network connection or data transfer. This typically includes details about the endpoint sending the data, such as IP address, port, domain.
|
Represents details about a URL involved in the event. These fields describe the structure and components of the URL.
|
Represents details about a user associated with the event. User fields are expected to be nested at: •process.user.*
|
Extensions
Custom ECS extensions are additional field sets introduced by integrations to capture data that is not covered by the standard Elastic Common Schema. These fields allow for richer context and vendor-specific attributes while maintaining compatibility with ECS. Extensions must follow ECS naming conventions and are grouped under a clear namespace to avoid conflicts with standard ECS fields.
ESET Extension
The ESET Extension standardizes data from ESET products by mapping antivirus detections and behavioral indicators to custom ECS fields under ESET namespace.
ESET Extension fields are expected to be nested at eset.*:
The ESET base field set contains all fields which are at the root of the eset.* namespace.
|
Represents details about ancestor processes. Ancestor fields are expected to be nested at: •eset.process.ancestors.* Following ECS fields are expected to be nested under eset.executable: •hash.*
|
Represents details about children processes. Children fields are expected to be nested at: •eset.process.children.* Following ECS fileds are expected to be nested under eset.executable: •hash.*
|
Provides information about an executable linked to the event. When this field appears under eset.process.*, it specifically refers to the executable of the process running on the host in connection with the event. ESET executable fields are expected to be nested at: •eset.dll.* •eset.file.* •eset.process.executable.* •eset.process.loaded_libraries.* The following ECS fields are expected to be nested under eset.executable: •code_signature.* •hash.* Following ESET Extension fields are expected to be nested under eset.executable: •livegrid_findings.*
|
Provides information about LiveGrid® data linked to the executable. ESET LiveGrid Findings fields are expected to be nested at: •eset.executable.*
|
Provides information about loaded libraries that were loaded in the process at the time of the indicator creation. ESET LiveGrid Findings fields are expected to be nested at: •eset.process.loaded_libraries.* Following field sets are expected to be nested under eset.loaded_libraries field set: •eset.executable.*
|
Represents details about a process running on a host that is related to the event. Following field sets can be nested under eset.process field set: •process.ancestors.* •process.children.* •eset.executable.* •eset.loaded_libraries.*
|
Represents a task executed in response to a EDR rule being triggered, aimed at mitigating or neutralizing a potential security threat. ESET remediation action fields are expected to be nested at: •eset.*
|
Represents information about the event that triggered a rule. ESET triggering event fields are expected to be nested at: •eset.triggering_event.*
|
The ESET Metadata Extension standardizes ESET-specific metadata for security events. It captures customer, service, and deployment details to aid in incident prioritization and routing within ESET Security Operations Centers (SOC). ESET metadata fields are expected to be nested at: •eset_metadata.*
|