Device Stopped Sending Events

The purpose of this article is to describe a more workable and usable alternative of the DSSE test that will:

  • Resolve the issue of the original DSSE test firing unnecessarily when one device in a paired device group (active/backup) becomes unresponsive
  • Enable the typical "CRE-isms" of actions and responses, which become unavailable through the original DSSE test
Note: This technical blog article is as-is and didn’t go through any extra vetting.

Introduction

In QRadar®, the Custom Rules Engine (CRE) works on the presence of events by processing them, then comparing them against defined rules. There is another test that runs in the background of the CRE known as the Device Stopped Sending Events (DSSE) test. Unlike the CRE, the DSSE runs on the absence of events, and this creates a conflict as many of the typical "CRE-isms" (read: actions, responses, other tests, and, filters in the same rule) become unavailable, and don't get called properly. Additionally, when any particular type of device in a device group or device list stops sending, the DSSE rule (shown in the following diagram), detects an issue.

Image showing the DSSE rule that detects issues when a device stops sending events to QRadar.

Figure 1. DSSE rule (Device Stopped Sending Events)

The Solution

This solution replaces the three original tests (pictured in the preceding screen capture) with two generic rules that are known as the tracker rule and the watcher rule. These rules test against and populate two separate reference data containers. The tracker rule operates by following the event data that is input into reference sets. Then, when the Reference Set entry expires, events are no longer allotted to it and the watcher rule is triggered.

Keep in mind that a Reference Set is a collection of data that maps one unique key to several values. Sets compare a property value against a list, with the purpose of pinpointing its key. A Reference Map is a collection of data that maps one unique key to one value; they are used to verify a unique combination of two property values. For example, to correlate user activity on your network with a LoginID.

Rule #1 - Tracker Rule

A tracker rule tracks events as they come through the system. If a log source ID exists in the SystemsToWatch reference map, then the value gets placed in the ActiveSystemsSending reference set.

Image showing a tracker rule in the QRadar Console.

Figure 2. Tracker rule in QRadar Console

Then, a response limiter is attached to the value. This response limiter is much smaller than the TTL of the reference set, and is indexed on the log source.

Image showing the Rule Response selection for a tracker rule.

Figure 3. Rule Response selection for tracker rule.

Rule #2 - The Watcher Rule

A watcher rule watches the system. As long as the system sees at least one event from the log source since startup, then values are populated in the Reference Set.

Image showing a watcher rule in the QRadar Console.

Figure 4. Watcher rule in QRadar Console

As soon as that Reference Set entry expires, it means that all log sources tied to the Unique Name in the Reference Map stop sending events. In this case, an offense is generated and indexed based on that unique name.

Image showing the Rule Response selection for a watcher rule.

Figure 5. Rule Response selection for watcher rule.

The Log Source Name that is mentioned in this procedure is ExpiredReferenceElement and it is configured as follows:

Image showing the Property Definition in the QRadar Console.

Figure 6. Property Definition in QRadar Console.