When should you use a multi-event rule versus a single-event rule?

The right choice depends on whether the threat pattern you're trying to detect is identifiable from a single log entry on its own, or only becomes apparent when multiple related events are considered together over some time window.

• Use a single-event rule when: the malicious signal is fully contained in one event — a connection to a known-malicious IP, a process execution matching a known-bad hash, a login from a blocklisted account.
• Use a multi-event rule when: the threat is a behavioral pattern spread across multiple actions — repeated failed logins followed by a success (credential stuffing), lateral movement across several hosts within a short window, or data exfiltration inferred from a sequence of unusual access-then-transfer events.

Multi-event rules generally cost more to evaluate, since they require correlating and holding state across a window of related events rather than judging each event in isolation, which is why it's worth confirming a single-event rule genuinely can't express the needed detection logic before reaching for the added complexity of a multi-event correlation.

In practice, many mature detection strategies use both together: single-event rules catch clear-cut, high-confidence indicators quickly and cheaply, while multi-event rules are reserved specifically for the subtler behavioral patterns that genuinely require correlating activity across multiple events to distinguish malicious behavior from coincidental, individually-benign-looking actions.