In a SIEM, how does a rule matching a known-bad domain differ from one matching a behaviour?

## Two things a rule can compare A detection rule is a predicate over collected records. What separates the two families is what the predicate is written against. An **indicator rule** compares a field to a fixed artefact that was *observed once*: a domain name, a URL, an IP address, a file hash, a certificate serial, a TLS client fingerprint such as a JA3 value. The rule says, in effect, "if any egress proxy record's destination host equals one of these strings, alert". Authoring cost is close to zero — you paste a value in. Reading the alert is easy too, because the verdict is almost pre-made: the record contained a string somebody previously attached to malicious activity. A **behavioural rule** compares fields to an *invariant of the activity* — something that has to be true for the technique to work at all, independent of the infrastructure carrying it. "A process that is not a browser or a known updater is making outbound TLS connections to the internet" is a behavioural clause. So is "a host reached an external address with no preceding DNS resolution from that host". Nothing in either clause names a hostname, so nothing in either clause breaks when the hostname changes. ## What each costs **To author.** The indicator rule costs a copy-paste. The behavioural rule costs you understanding: you have to know the technique well enough to name a property of it that cannot be dropped, and you have to know which collected record carries that property. **To maintain.** This is where they diverge hardest, and it is the part juniors miss. The indicator rule needs no maintenance and gives no warning when it becomes useless — it simply stops matching. Nothing on your dashboard changes; a rule that never fires looks exactly like a rule protecting a quiet estate. The behavioural rule does need maintenance, but its maintenance is *visible*: it fires on legitimate work — a backup agent, a monitoring collector, an installer — and you tune those out by excluding them on a stable attribute, one at a time, in daylight. **To run.** The indicator rule usually has no selective predicate: every record in the source has to be tested against the whole list on every scheduled run, so its cost tracks total traffic volume and grows with the list. A well-chosen behavioural clause is normally *selective* — it eliminates the overwhelming majority of records before anything expensive happens. ## What each actually proves An indicator match proves exactly one thing: **a record contained that string**. It does not prove the host is compromised. Infrastructure gets reused, domains get resold, a CDN address is shared with thousands of innocent tenants, and an analyst may have visited a sample in a browser. A behavioural match proves the *behaviour occurred*, which is a stronger statement about the activity and a weaker one about intent — plenty of legitimate software does adversary-shaped things. That gives you the distinction the whole triage discipline turns on: a **false positive** (the clause did not really match what it claims to match) is a rule defect; a **benign true positive** (the clause matched correctly, and the cause is legitimate) is a tuning job, not a broken rule. Getting the vocabulary the right way round matters here too. A domain, a hash, a certificate serial are **indicators** — artefacts observed. "Fronting command-and-control through a mainstream CDN so that egress looks like ordinary web traffic" is a **behaviour**. Candidates who call a hash a technique, or describe a behavioural clause as "a better indicator", have not separated the two categories yet. ## Why both stay in the portfolio The conclusion is not "behavioural rules are correct and match lists are amateur". A short, high-confidence, expiry-dated match list is one of the cheapest things a small team owns: near-zero authoring cost, near-zero analyst time when it does not fire, and a fast, defensible close when it does. What goes wrong is scale and permanence — a very large list wired straight into alerting, with no owner and no expiry date, converts somebody else's collection into your analyst's Tuesday. The practical rule of thumb: spend behavioural rules on **coverage** of techniques you expect to face, and spend match lists on **certainty** about a small set of things you currently care about, with a date on them and a name against them.