Creating Custom Detection Rules

Custom detection rules let you define exactly what Atatus Cloud SIEM should look for in your security events and how it should respond. This guide walks through creating a rule from start to finish, and how to manage existing rules.

If you are new to detection rules, read Detection Rules and Signals Overview first.

Prerequisites

• A user with permission to manage SIEM detection rules.
• At least one data source sending security events (an integration, Linux audit logs, Kubernetes audit logs, or file integrity monitoring).

Start a new rule

1. Go to Security → Detection Rules.
2. Click New Rule.

The rule builder is organized as a five-step form. Each step expands and collapses, and the footer shows which steps still need attention before you can save.

Two toggles in the header control whether the rule runs and whether it alerts:

Step 1: Select a detection method

Choose how the rule identifies threats in your data. See Detection methods for guidance on each option.

Step 2: Define detection queries

This step describes what to look for. Start with the rule's general settings:

Add one or more queries

Each rule has at least one query. A query filters and aggregates events:

Click Add query to add more queries. You can then combine them in your case conditions.

Step 3: Set rule cases

Cases turn query results into a signal. Each case is a boolean condition over your query names, evaluated top to bottom — the first matching case wins and sets the signal's severity.

Conditions support comparison and logical operators (>, >=, <, <=, ==, !=, &&, ||) over your query names. For example:

failed_logins >= 10 || (failed_logins > 5 && hostname == "prod")

Click Add case to add more cases — for example, a Critical case for very high volumes and a High case for lower ones.

Step 4: Say what's happening

This step composes the notification body and the tags applied to the signals this rule generates.

A useful notification template states the goal and the response steps, for example:

### Goal
Detect repeated failed logins that may indicate a brute-force attempt.

### Triage and response
1. Investigate the source IP and affected host.
2. Check whether the account is locked or compromised.
3. Block the IP or rotate credentials if confirmed.

Step 5: Create a suppression

Suppression reduces noise by muting recurring or expected signals. This step is optional.

Test the rule

Before saving, click Test rule in the footer to validate the rule's configuration against recent data. The footer also lists any incomplete steps; once everything is valid it shows Ready to save.

When you are satisfied, click Save Rule.

A complete example

The following describes an SSH brute-force rule end to end:

This rule fires a High severity signal whenever a single source IP produces 10 or more failed SSH authentications on a host within any 5-minute window.

Manage existing rules

From the Detection Rules list you can manage both built-in and custom rules:

• Enable or disable — Toggle a rule on or off without deleting it. This works for both built-in and custom rules.
• Override a built-in rule — Built-in rules are read-only, but you can override settings such as severity and notification routing for your account.
• Clone — Copy any rule (built-in or custom) into a new, fully editable custom rule. The copy's name is suffixed with (copy).
• Edit — Open a custom rule back in the five-step builder to change it.
• Import and export — When editing a custom rule, export it to JSON or import a rule definition. Bulk import is also available for onboarding many rules at once.
• Delete — Remove a custom rule. Any overrides you made on it are removed as well.

Next steps

• Filter Query Syntax — the full filter DSL for your rule queries.
• Investigating Signals — triage the signals your rules generate.