Detection engineering
Everything that decides what becomes an alert lives here: the rule set, how you adjust it, and which of your data is evaluated at all.
None of it does anything until the Detection switch is on. See Security Operations.
The rule set
Around 2,800 rules ship with the platform, drawn from the Sigma community set plus content written for it. They update as the platform updates: new rules are added, retired ones are withdrawn, and a rule you have disabled is never re-enabled by an update. Your decisions survive upgrades.
On top of those you can write your own, in Sigma, under Rules → Add Custom Rule.
Custom rules
A rule that does not compile is rejected rather than stored, so a broken rule cannot sit in your rule set quietly matching nothing.
Once accepted, a new rule goes live within about a minute, and this is the part to be deliberate about:
It begins matching new events from the moment it goes live. It will not tell you what happened last week.
That is intentional - a new rule silently generating a month of backdated alerts is rarely what anyone wants. To test against history, use Replay, which reports match counts and samples without raising alerts.
Replay is also how you find out a rule is too broad before it pages anyone. Write it, replay it over a period you know well, then promote it.
Tuning
Real rule sets need adjusting. The Tuning panel on each rule offers:
SCREENSHOT: the Tuning panel on a detection rule.
| Control | Use |
|---|---|
| Enable / disable | Turn a rule off for your organization |
| Severity override | Raise or lower what this rule means to you |
| Threshold | Fire on a count within a window, not on every event |
| Exclusions | Exempt known-good things by reference |
| Change reason | Required, and recorded |
A tune takes effect end to end in roughly a minute, on both the live and reconciliation paths, so you can tune against a noisy rule and watch it settle rather than waiting for a cycle.
Preview answers "what would this have done?" by re-running your proposed settings over the rule's real recorded decisions. It is not a simulation - it is the same decision logic over the same data, so what it shows is what production would have done.
The required change reason is not bureaucracy. Six months on, "why is this rule off?" is a question somebody will ask, and the answer being in the rule is the difference between a tuned rule set and an eroded one.
A small number are platform-locked. You can tune around them but not switch them off.
Suppressions
Where tuning changes a rule, a suppression is a statement about circumstances. Each carries criteria, a reason, an expiry, and a counter showing how many matches it has absorbed - so a suppression that is quietly swallowing more than you expected is visible.
Two stages:
- Detection-stage drops the match before it becomes an alert.
- Alert-stage mutes at triage, so the alert exists but nobody is paged.
Prefer expiries. A suppression added during an incident and never removed is how rule sets rot.
Environment objects
Named sets of values that rule exclusions reference by name rather than by literal - your scanner networks, your internal ranges. Change the set once and every rule referencing it follows.
Two kinds:
- Manual - you create them. The CIDR form offers your existing subnets as click-to-add chips.
- Derived - maintained automatically from your inventory, such as your organization's subnets. These are read-only here; edit the underlying subnets in Administration and the set follows.
Excluding your own scanners is usually the first thing anyone does, and doing it with an environment object rather than a hardcoded range is what stops it going stale.
Data sources and cost
This is the largest cost control in the SIEM, and it is worth setting deliberately before enabling detection rather than after a surprising bill.
Every data source sits in one of three tiers:
| Tier | Stored | Searchable | Evaluated by rules | Cost |
|---|---|---|---|---|
| Detect | Yes | Yes | Yes | Highest |
| Search | Yes | Yes | No | Lower |
| Archive | Yes | Retention only | No | Lowest |
An unclassified source defaults to detect, which is the safe default and the expensive one.
The question for each source is not "is this data useful?" but "do I want ~2,800 rules evaluated against every event from it?" Verbose sources that matter for investigation but rarely trigger detections - high-volume proxy or DNS logs, for instance - are often better in search: still fully searchable when you need them, not paying detection cost on every event.
Alerting
Also under this section:
- The organization switches - detection, alerting, AI triage.
- Emission floor - the severity below which matches are recorded but never raise an alert. Informational and low rules match and stay out of the queue.
- Maintenance windows - suppress alerts for a bounded period, or drop events entirely, during planned work.
- Alert policies - grouping, rate limits, and where notifications go.
Retention and legal holds
Retention is purchasable per event category beyond the base period. Ageing moves data to cheaper storage; nothing is rewritten or summarized.
Legal holds block every deletion path for their scope - including organization offboarding. A hold is released rather than deleted, so there is always a record of what was preserved and when.
Everything is versioned
Every change on every surface here records who made it, what changed, the before and after, and why. The history is available from the section overview.
That matters twice: for an auditor asking whether detection coverage was reduced, and for you asking why an alert you expected never fired.
Next
- Monitor and respond - working what these rules produce
- Investigations - searching events directly