Detection Rules and Signals Overview

Atatus Cloud SIEM continuously evaluates the security events collected from your hosts, clusters, cloud accounts, and integrations. When activity matches a detection rule, Atatus generates a signal, an actionable alert that your team can triage, investigate, and resolve. This page explains how signals are generated, the building blocks of a detection rule, and the difference between Atatus-provided and custom rules.

How signals are generated

Signal generation follows a simple pipeline:

Data sources send security events. Integrations and agents (Linux audit logs, Kubernetes audit logs, file integrity monitoring, CloudTrail, Okta, GitHub, and many more) forward normalized security events into the SIEM pipeline.
Detection rules evaluate those events. Each rule defines one or more queries that filter and aggregate events over a time window.
Cases decide the outcome. When a rule’s condition is met, its first matching case sets the severity and the message of the resulting signal.
A signal is created. The signal records what matched, how many events were involved, sample events for quick triage, and the MITRE ATT&CK context.
Notifications are dispatched (optional). If the rule is set to notify, the signal is routed to your configured Slack, Microsoft Teams, Email, or PagerDuty channels.
Analysts triage the signal. Signals move through statuses (open, investigating, resolved, false positive) and can be assigned, suppressed, or grouped.

See Investigating Signals for the triage workflow and Creating Custom Detection Rules to build your own rules.

Anatomy of a detection rule

Every rule, whether built-in or custom, is made up of the same parts.

Component	Description
Detection method	How the rule identifies threats (threshold, anomaly detection, new value, impossible travel, or static match).
Queries	One or more filters against your security data, with an aggregation (count, sum, average, or cardinality) and optional group-by fields.
Cases	Boolean conditions over the query results. The first matching case decides the signal’s severity and name.
Evaluation window	The time window, in seconds, over which events are aggregated.
Severity and risk score	The impact level of a generated signal.
MITRE ATT&CK mapping	Tactics and techniques associated with the detection.
Notifications	The channels and teams alerted when the rule fires.
Suppression	Optional rules to reduce noise from recurring or expected signals.

Detection methods

When you create a custom rule, you choose one of five detection methods. The method determines how Atatus evaluates your queries.

Method	When to use it
Threshold	Trigger when an event count exceeds a defined threshold within a time window. The most common method, for example, 10 failed logins from one IP in 5 minutes.
Anomaly Detection	Use a learned baseline to detect statistical deviations from normal behavior.
New Value	Trigger when a new, never-before-seen value appears for a field, for example, a login from a country you have never seen.
Impossible Travel	Detect logins from geographically impossible locations within a short timeframe.
Static Match	Match events against a fixed set of conditions, without dynamic aggregation. Useful for workload and runtime security checks.

Severity and risk score

Each signal carries a severity that reflects how urgently it should be reviewed. Atatus maps each severity to a default risk score (0 to 100), which is used for sorting and prioritization.

Severity	Default risk score
Critical	90
High	70
Medium	50
Low	30
Info	10

A rule’s severity comes from its cases, and the first matching case sets the signal severity. If you do not set a risk score explicitly, Atatus derives it from the severity.

MITRE ATT&CK mapping

Rules can be tagged with MITRE ATT&CK tactics (for example, TA0006 Credential Access) and techniques (for example, T1110 Brute Force). These tags appear on the resulting signals and power the MITRE framework view, helping you understand attacker behavior and coverage across the kill chain. Built-in rules ship with MITRE mappings already applied. Custom rules inherit tactics and techniques when you clone a built-in rule, and they can also be set through the API.

Built-in rules vs. custom rules

Atatus Cloud SIEM provides two kinds of rules.

Built-in (Atatus-provided) rules: A curated, continuously updated library of detections maintained by Atatus and mapped to MITRE ATT&CK. These are read-only, but you can:
- Enable or disable them for your account.
- Override specific settings such as severity, notification behavior, and routing.
- Clone them into a fully editable custom rule.
Custom rules: Rules you author for your own environment. You have full control over the queries, cases, notifications, and suppression. See Creating Custom Detection Rules.

Both kinds of rules appear together in the Detection Rules list, where you can filter by severity, source, rule type, category, tags, and origin (built-in or custom).

Next steps

Creating Custom Detection Rules: build a rule step by step.
Filter Query Syntax: write the filters that power your rule queries.
Investigating Signals: triage and resolve the signals your rules generate.

​How signals are generated

​Anatomy of a detection rule

​Detection methods

​Severity and risk score

​MITRE ATT&CK mapping

​Built-in rules vs. custom rules

​Next steps