Reading Time: 5 minutes

There is a dilemma over event collection of Endpoint Detection and Response (EDR) products. Collecting all events generated by endpoints means bottlenecks on the endpoint and on the network.  Collecting less may result in missing important events; collecting more could result in low-performance endpoints.

Current EDR vendors including Crowdstrike use a predefined event schema where all are hardcoded in their agents. Crowdstrike announces that they are using 400 different events (where a percent of it are their own agent-specific events) that are static, with predefined rules such as checks for specific registry file locations, etc.

The following are their top event categories:

  • Registry Events
  • File Events
  • Behavior Events
  • Browser Events
  • Clipboard Operations
  • Process events
  • Scheduled Task Events
  • Service Events
  • Thread events
  • Environment Variables
  • FW Events
  • IOA Rules Events
  • NetShare Events
  • USB Events
  • Injection Events
  • Network Events
  • Windows Event Log
  • FS Events
  • Install Events
  • Java Events
  • Kernel Events
  • Module Events
  • LSASS Events
  • Quarantine Actions
  • Ransomware Actions
  • SMB Client Events

For each category, specific events are generated like PdfFileWritten, DmpFileWritten, DexFileWritten etc. but those are all file write operations where only type of the file has been changed. The same applies for Registry events, Service events etc.

But what about file write operation to unknown or generic file type? What about not just one event but a series of events? Or frequency of events? Or patterns of the same events that are important? In such cases, a static event model like Crowdstrike’s has very limited scope detecting those new APT type of attacks. We can regard Crowdstrike event model as “signature-based event collection” that closely resembles the old signature-based AV scanners.

Comodo’s Dragon Enterprise introduces “Adaptive Event Modelling” where events are defined from base descriptors like






Some other descriptors are:

  • User
  • Registry
  • Memory
  • Network
  • service,
  • volume,
  • IP, etc.

and the low-level events (LLE) are generated as a result of one elementary activity. These are based on raw events from different components but provide some abstraction layer from event source and API-specific and controller-specific data. For example, different raw events from different controllers and with a different set of fields can be converted to an LLE of one type.

The middle-level events (MLE) are events which are generated as a result of a sequence of LLE. Some examples are given below:

They are usually generated by local patterns matching components. Each event descriptor has own set of fields. However, the events have standard common fields.

The event descriptor is used in the policy matching. The policy can access the fields in the condition rules and compare them with predefined values. However, not all event fields can be used for policy checking.

Some fields are not scalar types but complex types (dictionaries and sequences). Access to the dictionary fields is provided by using “.”. The access to the sequence fields is provided by using “[]” notation. The examples are below:


Figure 1 Example of Adaptive Event Modeling Policies

The logical objects (like Process, File, User) in events are represented as dictionaries with a predefined format. The format of each object is described, and its fields can be used for policy matching if it is specified. The object descriptor can contain fields that refer to other objects.

Figure 2 Patterns Chaining

Using this definition, Comodo Dragon Platform defines policy-based event collection that can be applied to not only the endpoint itself, but can be different for each process, service or user actions. By this we are not only be able to collect everything Crowdstrike collects, but also it is adaptive during the incidents. Why should we collect and send all fire write events for a trusted process if it is not being injected yet?  If an injection occurs or a different fork happens, Dragon Platform starts collection all details for that process, remaining the other process collection untouched. On those low-level events here are some examples of events where Crowdstrike does not collect:


Dragon Enterprise does all pattern matching dynamically on the endpoint, controls what to collect, what to correlate, and wants to send based on the adaptive policy definitions.

On the other hand, Dragon Enterprise also analyzes the time series of respective events. Our Adaptive Event modeling also investigates different degrees of periodicity in the data, including systematic user-process, process-process, process-system integration, as well as day-of-week and time-of-day effects, and makes inferences about the detected events (e.g., popularity or level of attendance).

Like advanced persistent threats (APT), insider threats should be also considered in the scope of EDR. Aggregated behavior of individual human beings typically exhibits a periodicity in time on several scales (daily, weekly, etc.) that reflects the rhythms of the underlying human activity and makes the data appear non-homogeneous. At the same time, the data is often corrupted by several “burst” periods of unusual behaviors. The problem of finding and extracting these anomalous events is made difficult by both elements. Dragon Enterprises uses unsupervised learning in this context, based on time-varying process models that can also account for anomalous events. We generated adaptively and autonomously learning to separate unusual “burst” events from traces of normal human activity.

For more information about Comodo Dragon Enterprise versus Crowdstrike visit

IT Computer Management

EDR Security

Endpoint Detection and Response