EDR

ZADIG XDR provides EDR software. It consists of a set of projects implementing a unified cross-platform service core, which combines multiple modules (potentially native) and is consistently deployed across various target platforms. The actual agent is designed to operate in the background and respond to different types of events. The XDR solution involves a persistent agent whose data is displayed and managed through a unified platform with endpoint management and protection features, enabling correlation with data from all other integrated sources. It was initially designed to support access filesystem events but can easily accommodate other event sources.

The solution supports non-persistent installations to the extent that the client already has an automated application distribution management solution. Alerts generated by the platform can be processed by SOAR (Security Orchestration, Automation, and Response) to trigger agent distribution profiles on the devices involved in the alert.

Below is the diagram of the service architecture. It encompasses all the key aspects of its design discussed later:

Modules injection

Dependency injection is done via autofac by using a configuration file for the run-time composition. All modules so far can be seen as either event producers (generators) or consumers (handlers). All of them either expose or connects to some common interfaces. Depending on the target platform and desired features, a different set of modules can be configured for dependency injection on a per-deployment basis by different packaging setup.

Native extensions

Modules may depend on platform-specific features or APIs. In this case, the module provides by its own all the required native extensions, i.e. bindings, libraries, drivers or supplementary applications.
In no case other interfacing modules should care about how such platform specificity is implemented, everything remains hidden within the module.

App hosts

The composition root is part of a library which can be referenced from different kind of application hosts. This makes easier to develop, test and deploy the agent inside multiple minimal wrappers which best adapt to the endpoint device. For instance, it is possible to run the same agent service core codebase as a console application or a background service.

User applications

A number of features requires foreground user interactions. Their implementation is part of platform-specific applications that best match the various use cases across different endpoint device classes.

Configuration

The agent service core may include a module which needs out-of-package parameters to be set in order for the module to be functional. On purpose, user applications need to have write access - at certain conditions - to a shared config locations the agent core could read on startup.

Given that the agent service core will likely run with high system-wide privileges, the user application must eventually ask for elevated rights in order to write into the shared config location.

Core service interaction

The agent service core might include event handling modules which need asynchronous user interactions for service status signaling, alerting or decision taking.
User applications couples with such kind of modules and provide necessary UI and integrations with platform shell APIs.

Deployment model

Each platform allow a number of different deployment models. Here we needed to choose some which efficiently ship both the core agent service worker (with all its modules) and the user application.
Modern packaged deployment looks to be fairly convenient for out requirements, as each major OS currently provides a way to bundle our two components into a single deployable item.

Typical packaging-enabled features

Moreover, packaged apps can benefit from platform features like automatic updates, easy uninstall and optimized package delivery and licensing (which could be useful in future in case different modules get installed as additional plug-ins).