Catching silent log sources in QRadar

An attacker who stops your logs does not trigger your detections. Here is how I find log sources that have gone quiet, and how I keep those alerts useful instead of noisy.

Why silence is a detection problem

Most SOC content is written to catch something that happens: a failed login burst, a new admin account, a beacon to a rare domain. Every one of those rules depends on an assumption nobody writes down. It assumes the events are arriving.

When a log source stops sending, nothing fires. The dashboard looks calm. In a managed service environment, a calm dashboard for a client is easy to read as good news, and that is exactly the problem.

Log sources go quiet for ordinary reasons: an expired certificate on a syslog forwarder, a firewall rule change, a full disk on a collector, an agent that crashed after a patch. They also go quiet for hostile reasons. MITRE ATT&CK tracks this as Impair Defenses (T1562), including disabling Windows event logging (T1562.002) and tampering with security tools (T1562.001). From the SOC, both look identical at first: the events stop.

So I treat log source health as a detection in its own right, with the same care I would give any other rule.

Step 1: find when each source last spoke

The core idea is simple. For every log source, find the most recent event time, and flag any source whose last event is older than a threshold. In AQL, starttime and NOW() are both epoch milliseconds, so 30 minutes is 1,800,000.

SELECT
  LOGSOURCENAME(logsourceid)                 AS "Log source",
  LOGSOURCETYPENAME(devicetype)              AS "Type",
  DATEFORMAT(MAX(starttime), 'yyyy-MM-dd HH:mm') AS "Last event",
  (NOW() - MAX(starttime)) / 60000           AS "Minutes silent"
FROM events
GROUP BY logsourceid
HAVING MAX(starttime) < NOW() - 1800000
ORDER BY "Minutes silent" DESC
LAST 24 HOURS

This is the query behind the flagship panel in the log source health dashboards I built. It answers the question the SOC lead actually asks each morning: which sources have stopped talking, and for how long?

AQL syntax and function support vary slightly between QRadar versions, so test any query here in your own console before you build on it.

Step 2: close the blind spot in that query

There are three ways I deal with this, and I use them together:

1. Compare against an inventory. Keep a list of the log sources you expect to hear from, for example in a reference set of critical sources. Anything on the list that is missing from the results is silent, however long it has been gone.
2. Run a wider window on a schedule. A daily report over 7 days catches sources that dropped out between the short checks. It is heavier, so it belongs in an overnight report, not a live dashboard.
3. Use the platform's own status. QRadar tracks log source status and can raise system notifications when sources stop reporting. Treat that as a second opinion, not a replacement, because it will not know which sources matter most to you.

Step 3: one threshold does not fit every source

A single 30-minute rule for everything produces a stream of useless alerts. Some sources are chatty and some are naturally quiet. I group sources into tiers and give each tier its own expected silence:

The exact numbers matter less than the habit of measuring them. Look at how often each source normally reports over a couple of weeks, then set the threshold just beyond its normal gap. Review the tiers whenever the environment changes.

Step 4: watch for sources that go quiet, not only silent

A source can keep sending a trickle of events while losing most of its data. A firewall might keep sending system messages while its traffic logs stop. A simple volume check catches this:

SELECT
  LOGSOURCENAME(logsourceid) AS "Log source",
  COUNT(*)                   AS "Events last hour"
FROM events
GROUP BY logsourceid
ORDER BY "Events last hour" ASC
LAST 1 HOURS

On its own, a count means little. Compared with the same hour on previous days, a sharp drop is worth a look. I start by flagging any critical source running below about a quarter of its usual volume, then tune from there.

Step 5: check that the events still make sense

The quietest failure of all is a source that sends plenty of events that QRadar can no longer parse. A vendor update changes the log format, events stop mapping to known event types, and every rule that relies on usernames or IP fields goes blind while the volume graph looks healthy.

I track, per source, the share of events that land in unknown or unparsed categories. A sudden rise after a patch window is one of the most reliable signs that a parser needs attention. This became its own dashboard, parsing and coverage quality, because it kept catching problems the other checks missed.

Making it part of the routine

Health checks only help if someone acts on them. What worked for me:

• Put the silent sources panel first on the analyst dashboard, so it is the first thing seen on every shift.
• Give every health alert an owner and a short runbook: check the collector, check the network path, contact the client's system owner.
• Treat unexplained silence on a critical source during an active incident as a possible attacker action until proven otherwise.
• Report coverage to clients alongside threat activity. "We saw nothing" and "we could see everything, and nothing happened" are very different statements.

Summary

Every detection rule assumes the data is there. Log source health is how you check that assumption. Find when each source last spoke, cover the sources that fell out of your search window, set thresholds per tier, watch volume as well as silence, and check that events still parse. None of this is glamorous, but it is the difference between a SOC that is quiet because nothing happened and one that is quiet because it has gone blind.

All examples here are generic and built for illustration. They contain no client data.