Using Scheduled Detection & Response Rules

Most security tooling is built around a reflex. Something happens, a rule fires, an analyst looks. The instrument is exquisitely tuned to react, and it sits idle the rest of the time. In this Loud and Clear session, Matt from LimaCharlie makes a quieter argument that cuts against that reflex: the most valuable thing a detection engine can do is not wait for an event but manufacture one on a schedule, on purpose, against systems where nothing is wrong yet. The feature he walks through, scheduled detection and response rules, is small. The shift in posture behind it is not.

The platform already knows more than its sensors report

The conceptual move that makes scheduled rules work comes before any scheduling. Matt widens what the word "event" means inside LimaCharlie. Most operators think of events as system telemetry: process starts, memory mapping, network connections off an EDR sensor, ingested Windows event logs, adapter data from AWS or Google Cloud. All of it is observable by the detection and response engine, and all of it can carry a rule.

What gets overlooked is that the platform emits events for its own operations too. Pull an artifact, deploy a sensor, issue a console command, and each produces an observable event. That last case is the hinge. When you run a command like OS Services, which lists installed services across Windows, Linux, and Mac, the response comes back as an OS_SERVICES_REP event in the sensor timeline, not just text scrolling in a console. Once the output of an action is itself a first-class event, you can write rules against it, route it, and model it. The command stops being something an analyst reads and becomes data the platform can carry downstream.

This reframing is the whole game, because it converts a one-off lookup into something repeatable. Matt contrasts it with the old way of profiling service creation as a persistence mechanism: query a pile of Windows event logs, normalize them, slice for the right event IDs (the open rule sets from Sigma, SnapAttack, and SOC Prime tend to pivot on 7045 events), and arrive at a single point-in-time picture. He is blunt that this is reactive and does not scale. You can do it once. You cannot do it nightly across every host without burning analyst hours you do not have.

Scheduling turns reactive lookups into a standing profile

The scheduler is where that observation pays off. A scheduled rule sets its target to schedule rather than to incoming telemetry, which tells the platform to act as what Matt repeatedly calls an internal cron job. The event defines frequency from a fixed menu: 30 minutes, or 1, 3, 6, 12, 24, or 168 hours. The right interval follows the volatility of the data. Services rarely churn, so a daily pull is sensible, but Matt notes he would tighten that to every 30 minutes during an active incident response, when he is specifically watching for changes an adversary is making in near real time.

Scope is the other dial. Rules run per organization (once per period for the whole org), per sensor (once per period on each endpoint), or per cloud adapter across AWS, Azure, GCP, 1Password, Slack, and the rest. The per-sensor and per-cloud-adapter responses also carry runtime metadata, which Matt suggests pivoting on to profile host names or adapter types without scrolling sensor lists or hitting the API. One operational constraint is worth holding onto: per-sensor rules only reach sensors that have checked in at least once in the last 30 days, which is sensible since a silent host has nothing to give.

For a provider running many tenants, the qualifier layer is where this stops being a feature and starts being a workflow. Matt builds his example rule to run OS Services every 24 hours against Linux systems, scoping with a platform operator. But he leans harder on tags. Tag a host high priority active IR and the next scheduled run sweeps it in automatically. Onboarding a system into a collection program becomes an act of labeling, not rule editing, which is exactly the kind of operation that has to be cheap when you are doing it across a customer base rather than a single network.

The ephemerality is a design constraint, not a footnote

The most consequential detail in the session is also the easiest to miss, and Matt flags it deliberately. Scheduled events are short-lived. They are not part of LimaCharlie's yearly retention, and you cannot go back through the query language and ask the platform to show every schedule hit from the past month. The scheduled trigger is a fuse, not a record.

This is why the entire argument routes through the response event rather than the schedule itself. The OS_SERVICES_REP data is what persists in the timeline and, more importantly, what you can forward through outputs to somewhere durable, like an S3 bucket for visualization, consolidation, or hunting. Matt's preferred pattern follows from this directly: run the scheduled pull broadly against all Linux or all Windows hosts, let the response events accumulate in the timeline, then filter at the output level rather than the detection level. The collection stays wide while the forwarding stays narrow. A system outside the scope of today's incident still has its history sitting there, so when it comes into scope later, the data you wish you had collected is already collected. He demonstrates this with OS_PROCESSES_REP events captured over several days, where the process count drifts harmlessly between 83 and 86, the point being not the numbers but that the timeline holds them at all.

What this adds up to is a use case most detection tooling never reaches for. Matt's built-in sample rule pulls installed packages from every Windows host weekly and simply keeps the events. Ten weeks in, that is a running software inventory: what changed, what users installed, which browser needs updating. When a vulnerability lands, you search the historical package events to find who is exposed before anyone has to ask. That is LimaCharlie behaving less like a threat detector and more like a standing census of the environment.

The deeper claim under the demos is about stance. A detection engine that only fires on what arrives is permanently downstream of the adversary. One that can interrogate every host on a schedule, treat the answers as observable events, and bank them where they survive turns the same machinery into proactive environment profiling. For an MSSP or MDR, that is the difference between collecting evidence after a customer asks a question and already holding the answer when they do.