LC101: Writing detection and response rules

Most detection platforms treat the rule as a signature. You write a pattern, the pattern matches malware, the alert lands somewhere, and a human picks it up from a queue. Matt Bromiley, LimaCharlie's Lead Solutions Engineer, spent this second LC101 session quietly dismantling that model. His argument is that a detection and response rule is not a signature for malware at all. It is a question you ask of your telemetry, and the most consequential decision you make is what happens in the gap between asking it and getting an answer.

A detection is a question, and most of them are not about malware

Bromiley's reframe is deliberate. He concedes that ninety eight or ninety nine percent of the time, people reach for detection rules to find malware. Then he sets that aside. With every data source landing in one place, EDR telemetry from Windows, Mac, Linux, Chrome OS, Docker, and Edge alongside third party logs and cloud sets, the real capability is interrogation. How many PsExec services have been installed? How many times has the "matt" user logged in, and onto which systems? Those are needle in a haystack questions against millions of rows, and nobody wants an analyst grinding through logs every night to answer them. So you write a rule that does it automatically and tells the computer to speak up.

The clever part is what this does to the word "malicious." Bromiley writes a rule that fires whenever the "matt" user logs in. He has said nothing about a threat. Put an asterisk on it, assume that account is compromised, and the same rule is now threat actor detection. Take the asterisk off and it is asset inventory, classification, an answer to a business question. The mechanism never changed. For a provider running many tenants, this is the difference between a tool that only catches intrusions and one that also tells you what is in each environment and what your clients are actually doing. His advice for writing the detection follows from this: say the question out loud first. "Every time someone connects to example.com or example.net." The operators you need, is, or, contains, a regex, a CIDR check for public versus private addresses, are usually already sitting inside the English sentence. You just translate.

The whole point is to not throw the answer over a wall

This is where Bromiley's bias, which he admits, becomes an actual argument. Most shops he describes do detection engineering, fire an alert, and hand it off to a separate playbook, a separate automation platform, a separate set of workflows that take it from there. He does not call that wrong. He calls it slow. The moment a good rule fires and the alert sits in a queue for five minutes, ten minutes, an hour, or is never seen, you have given time to the adversary. Time is the defender's one structural advantage, and handing detection to one system and response to another is a way of giving it away.

So a LimaCharlie rule carries its response in the same YAML object: one descriptor to detect, one to respond. The response side answers a single question, what do you want to happen when the thing is found, and the answer scales with how much you actually care. Sometimes it is just report, surfacing in the Detections view under a name you chose. Sometimes it is a chain: email the top five people on the investigation, add tags, set a priority, kill the process, isolate the host from the network while keeping only the LimaCharlie channel open. A wait action staggers those steps so you can sequence them deliberately. Because the rule fires right next to the source event, the containment happens while the advantage of time is still yours, not after it has leaked into a ticketing backlog.

Tagging is the move he clearly enjoys most, and it is the cleanest proof that detections are not just about threats. A rule that spots Adobe Acrobat on a machine can drop a VIP tag on that sensor for a day. A rule that sees a DNS request to a known bad domain can tag the host "systems of interest" and let later searches pivot off that tag instead of deduplicating CSVs by hand. The detection becomes classification, and the classification feeds the next detection.

You do not have to write a single line to start

Bromiley keeps interrupting his own lecture to make this point, because the YAML can intimidate. His demo organization shows 887 rules, and he wrote almost none of them. The Marketplace ships curated sets you subscribe to: Sigma, open source, free, and in his instance updated two hours before the recording; SnapAttack Community Edition, free; a Soteria managed set covering Windows, Linux, and Mac at a nominal per sensor cost; a LimaCharlie sponsored generic macOS set; and a SOC Prime integration that takes an API key. Create an organization, install a sensor, subscribe to Sigma, and roughly thirty seconds to a minute later you have hundreds of working detections with no detection engineering background required.

The catch is the reason custom rules survive, and it ties directly back to his thesis about response. Those managed sets detect well, but their contents are proprietary. You can run a Soteria rule looking for a binary in a non standard directory, but you cannot open it and change what it does when it fires. The response side, the part Bromiley argues is the real value, stays locked. So the natural path is to lean on curated sets for instant coverage, then write your own rules for the niches each environment carries and, more importantly, for response actions you control. His "productivity dropper" rule is the template: it matches Windows process events where Word, Outlook, Excel, PowerPoint, a browser, or Acrobat spawns a shell, script, or executable, using a case insensitive path match and a with descendant clause to walk down the process tree to what got dropped. It is dense, but it is the same shape as the one line example. Pick the event that carries the signal, because a domain name only exists in a DNS_REQUEST and never in the raw TCP connection, name the field in the path, choose your operators, then decide what should happen. Detect, and respond, in one place, before your adversary gets to spend the time you would otherwise have handed them.