Unique event

The Unique event setting decides when a new detection opens a new row in your events list and when it only adds to the count of an existing one. This page explains each field you can choose, how to set it for one machine, and what it cannot change after the fact.

What counts as a new event

When a detection matches an event you already have, EyalSec adds one to that event's count instead of adding a row. The Unique event setting is the list of fields that decide whether two detections match. It is on each product's Filters page, under Unique event.

Fewer fields means fewer, busier rows: the same problem reported a thousand times is one row with a count of 1000. More fields means more rows, each more specific. See grouping and count for how rows and counts appear in the list.

Grouping does not change what you pay: billing counts every detection, however it is grouped. It does change how fast you use your event quota, which counts rows, so more fields means more rows and the quota fills sooner.

The fields

Three fields are always used and cannot be switched off: Your account, Product and Sink (the operation the data reached). They are shown ticked and greyed out, marked always. On top of them you can tick any of the five optional fields below, then press Save.

The default is Taint chain plus Detail line. It is what every account uses until someone changes it.

Taint chain

Taint chain separates detections where the same sink was reached by a different chain of assignments: the same operation fed by different data paths becomes separate events. It is on by default.

Switch it off to group every detection at a sink into one row regardless of how the data got there.

Detail line

Detail line separates detections by the extra detail line each one carries, such as the page URL for an es-chromium event or the origin token for an es-python event. It is on by default.

Switch it off if one operation reached from many pages or inputs should be a single row.

Stack trace

Stack trace separates detections by the call path that reached the sink. One sink reached from twenty different call paths becomes twenty events instead of one. It is off by default.

Turn it on when you need to fix every caller separately. Without it, a row shows the stack trace of its most recent detection only.

Machine

Machine keeps your machines apart. Without it, the same detection on two of your machines is one row, and its count covers both. It is off by default.

Turn it on when you want a separate row per machine, for example to see which hosts still show a problem after a fix has been rolled out to some of them.

Origin

Origin separates detections by the detail of where the untrusted data came from (the event's origin block, such as the file or network peer). It is off by default.

Without it, a row keeps the origin of its most recent detection only.

Applies to: one machine or the whole account

Applies to chooses which setting you are looking at. All machines (account default) is the setting for every machine of this product; picking a machine shows that machine's own setting. A machine with its own setting uses it instead of the account default.

• The list shows the machines of the product whose Filters page you are on.
• A machine with no setting of its own shows following the account default next to the picker.
• The setting is per product: the es-python page and the es-chromium page each have their own.
• Press Save after changing the ticks. The page confirms with "Saved. Applies to detections from now on."

Reset to default

Reset to default removes the setting of the scope you are looking at, so it goes back to inheriting. For a machine, that means following the account default again; for the account default, it means the built-in default (Taint chain plus Detail line).

The button appears only when the scope has a setting of its own.

What it cannot change

The setting applies to detections recorded from the moment you save. It does not regroup events that are already stored, in either direction.

Turning a field on later does not recover the past. When detections merge into one row, only the most recent one's stack trace and origin are kept, so the others were never stored and nothing can split them apart afterwards. If you think you will want a field, turn it on early.

After you change the setting, a detection that used to merge into an existing row may open a new row instead, because rows written under the old setting and the new one are kept apart. Your older rows stay as they were.