0.4 Where Rules Get Deployed

The same rule, four places

A rule is not deployed in the abstract. It runs somewhere specific, against a particular kind of target, under a particular time budget, on an engine somebody else chose. All four of those change what a good rule looks like, and the differences are large enough that a rule tuned for one surface can be unusable on another.

The forensic image

You have a mounted volume and nobody is waiting on a minute-by-minute basis. This is the most permissive surface there is: install whichever engine you like, load every module, accept a rule that takes a second per file if it earns it.

It is also the surface where breadth matters most. You are not looking for one known thing, you are asking what is on this disk that should not be, so you run a large rule set rather than a targeted one, and a rule that is slightly noisy is tolerable because a human is reading every hit anyway.

There is a second permissiveness worth naming: you can scan the same image again tomorrow with a better rule. Nothing is lost by a first pass that misses, because the evidence is static and still there. That is not true of any other surface in this section, and it changes how much you should worry about getting a rule right first time.

The trap is different here: volume. A disk image holds hundreds of thousands of files, and a rule producing a hit on one in a thousand produces hundreds of hits. That is not a false-positive problem in the usual sense, it is a triage problem, and it is why Module 7 covers hit prioritization rather than only scanning.

The endpoint sweep

An agent runs your rules against a live host. Minutes rather than hours, because the machine has a user on it and you are competing with their work for I/O.

Two constraints appear here that the image surface does not have. Scanning a live filesystem means files change underneath you and some are locked. And the engine is whatever the agent ships, which you did not choose and probably cannot change.

That second constraint is the one this course keeps returning to. If the agent embeds YARA 4.x, then a rule using anything YARA-X accepts and 4.x does not will fail to compile on the agent, and the failure surfaces at deployment time in somebody else's console.

Worth being precise about what that failure looks like, because it is rarely a clear error handed back to you. Depending on the platform, a rule that fails to compile may be skipped silently while the rest of the set loads, which leaves you with a deployed rule set that is quietly missing the rule you most wanted in it. That is Section 0.1's silent failure arriving through a completely different door.

The fleet hunt

Thousands of hosts, one question, and an answer that has to arrive while it still matters.

Velociraptor is the common route and Module 7 covers it in detail. What is worth understanding now is that the constraint is not really CPU. It is that a fleet-wide scan taking six hours produces its answer after the containment decision it was meant to inform has already been made, and an answer that arrives after the decision is not an answer.

The arithmetic, done once

Time a single simple rule over one ordinary directory, then scale it.

# One rule, one directory, timed
time yr scan probe.yar /usr/bin/
#
# Then do the multiplication before you deploy it anywhere
#   files per endpoint   ~200,000
#   endpoints            10,000

1066 files scanned in 2.09s, 0 hits
#
extrapolated: 200,000 files x 10,000 endpoints
  = 1,088 CPU-hours for ONE simple rule

A thousand CPU-hours for a single rule with one string in it. Spread across ten thousand machines running in parallel that is roughly six minutes each, which is survivable, and it is also the floor rather than the estimate: a rule with an expensive regular expression can be ten times that on the same files.

Two things follow, and they are the whole reason fleet rules look different from image rules.

Rule count is not the lever, rule cost is. Section 1.1 shows two hundred simple rules costing barely more than one, because the patterns are searched together in a single pass. Adding rules to a fleet hunt is cheap; adding an expensive one is not.

Scope the target, not just the rule. Scanning every file on every endpoint is almost never what you want. Restricting to user-writable directories, or to files modified in the last thirty days, removes most of that number before the rule is involved at all, and Module 7 covers how each platform expresses that.

So fleet rules are narrow, fast, and few. You do not run your whole rule set across ten thousand endpoints; you run the two rules that answer the question you have right now. Module 2's durability work and Module 5's performance work both pay off here more than anywhere else.

The narrowness has a second benefit that is easy to miss. A hunt returning four hits across ten thousand hosts is a result somebody can act on that afternoon. The same hunt returning nine hundred hits is not a result at all, it is a second triage problem, and the rule that produced it has converted one question into a larger one.

This is also the surface most likely to be on 4.x.

The gateway

A mail gateway or upload scanner runs inline, in the delivery path, with a budget measured in fractions of a second per file, on an engine chosen by a vendor.

Realistically you may not be able to deploy your own rules here at all. Where you can, the rules have to be fast enough not to delay mail and precise enough that a false positive does not block a legitimate invoice, which is a considerably higher bar than "an analyst wastes ten minutes."

The reason it is in this course despite the constraints is that it is where a rule has the most value when it works. Catching something before delivery is worth a great deal more than finding it on a disk three weeks later.

It is also the surface where the cost of a false positive is paid by somebody outside security. An analyst losing ten minutes is an internal cost that stays internal; a blocked invoice is a business consequence with a name attached to it, and the tolerance is correspondingly lower.

What this means for how you write

Three habits follow, and they run through the whole course.

Know the target before you write. The surface decides the time budget, the engine, and the acceptable false-positive rate. Writing first and asking later means discovering the constraint after the work.

Write to the most restrictive engine you will deploy to. If any of your surfaces runs 4.x, then your rules are 4.x-compatible rules, and YARA-X is your authoring and validation environment rather than your target. Module 6 is about doing that deliberately instead of by accident.

Assume the rule outlives the incident that produced it. The rule you write today for one fleet hunt ends up in the standing rule set, running on surfaces you were not thinking about. Module 7 covers the lifecycle that follows from that.

Where Sigma fits, and where this stops

A question worth settling early, because the two get confused.

YARA describes files. Bytes on disk, or in memory where the engine supports it. It answers whether this artifact is the same thing as that one.

Sigma describes log events. It answers whether this activity looks like that activity, and it compiles to whatever query language your SIEM speaks.

They are not competitors and they are not interchangeable. A file hash appearing in process telemetry is a Sigma question; the same file sitting in a temp directory is a YARA question. Most real detection coverage uses both, and SEC408 covers the other half.

Section 0.5 takes the boundary further, into what a YARA match does and does not establish even when the rule is perfect.