Custom rules, saved filters, and ignore rules
The built-in detection catalogue covers the common attacks. Real fleets need three more things: rules for what is specific to you, a way to apply one configuration to many hosts, and a way to silence events you have investigated and decided are fine. This page covers all three and the Security, then Detections page where most of it lives.
The Detections page
Section titled “The Detections page”Security, then Detections is the single configuration surface for what the agents detect and how it alerts. It replaced the older Policies and Rules pages, which now redirect here. Five tabs:
| Tab | Holds |
|---|---|
| Rules | The policies (access control, file integrity, network security, process monitoring, container security, privilege escalation, cryptojacking) and their rules, with on/off and severity overrides |
| Advanced | Individual rules, frameworks (general, SOX, PCI DSS), and per-host overrides including custom rules |
| Lists | Account-wide lists the rules read: the SSH allowed-source list, authorised container registries |
| Alerting | The bridge from security events to alerts: on/off, minimum severity (default high), and the escalation policy |
| Response | Automatic SSH brute-force blocking: dispatch, thresholds, and the kill switch that forces dry-run; see SSH login monitoring |
Every change is reconciled server-side and pushed to the affected hosts as agent configuration. A policy shows Degraded when a host cannot run all the probes it needs. Details of the Rules and Advanced tabs are in Customizing detection rules.
Custom detection rules
Section titled “Custom detection rules”A custom rule is evaluated on the host by the agent, like a built-in rule. Add one from the per-host override on the Advanced tab.
| Field | Notes |
|---|---|
| Name, description | Shown on events the rule raises |
| Condition | The match expression, in the same form as the built-in rules |
| Severity | Default medium |
| Priority | The syslog-style priority the event carries; default WARNING |
| Tags, MITRE tactics and techniques, framework | Optional classification, carried on every event |
Saving links the rule to the host’s override and pushes the probes the
rule needs; the agent evaluates the condition locally, so a rule costs
nothing on the server side. Rule IDs are prefixed custom- in the event
stream. A background sync retries any host that missed the push, every
minute, until it confirms.
Context rules for AI triage
Section titled “Context rules for AI triage”A second, older kind of custom rule lives at Security, then Custom
Rules (the list now redirects to Detections; the add and edit forms
remain). These are not evaluated by the agent. They describe a policy in
plain terms - allowed users, blocked processes, time windows, hosts or
profiles they apply to, and a free-text condition - and that description
is given to the AI triage model as context when it judges an event.
Use them to tell the triage “backups run as svc-backup between 01:00
and 03:00” so a legitimate pattern stops being flagged as suspicious;
use a detection rule when you want a deterministic event.
Saved rule filters
Section titled “Saved rule filters”A saved rule filter is a named configuration - which policies are on, which frameworks, and per-rule severity overrides - that can be applied to hosts. Find them under Security, then Filters (the older Security Profiles link lands here).
Create one, set the policies and overrides, and choose Apply to host. Applying switches the host from “use workspace defaults” to that exact configuration, written into the host’s agent configuration and pushed. Editing the filter later does not re-apply it; apply again to the hosts that should follow it. Typical filters: “web tier” with network rules tightened, “build agents” with process rules relaxed, “PCI hosts” with the PCI DSS framework on.
Ignore rules
Section titled “Ignore rules”An ignore rule suppresses events, not configuration. When an event matches, it is dropped before triage and alerting, and the rule’s match counter increments so you can see it working. Find them under Security, then Ignore Rules, or create one from an event’s page with the event’s fields pre-filled.
| Field | Notes |
|---|---|
| Scope | host, process, user, rule, rule_host (default), rule_process, or global |
| Match | Any of rule name, hostname, agent, process name, process path, command line, user, container, priority |
| Reason | Required; future you will want it |
| Expires | Optional. Set one for a temporary suppression during a migration; leave empty for a permanent decision |
| Enabled | Toggle without deleting |
Prefer the narrowest scope that stops the noise: rule_host (this rule
on this host) or rule_process (this rule from this binary) rather than
rule or global. The source event is linked from the rule so the
decision can be revisited.
Which one to reach for
Section titled “Which one to reach for”| You want to | Use |
|---|---|
| Detect something the catalogue does not | A custom detection rule |
| Explain a legitimate pattern to AI triage | A context rule |
| Give a group of hosts the same detection configuration | A saved rule filter |
| Stop a specific event that keeps firing | An ignore rule |
| Lower a built-in rule’s severity everywhere | A severity override on the Rules tab |
| Silence everything on a host during planned work | A maintenance window, not an ignore rule |
Next steps
Section titled “Next steps”- Customizing detection rules for the Rules and Advanced tabs in detail
- Security events for reading what the rules produce
- File integrity monitoring and YARA