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:

  1. 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.
  2. Detection rules evaluate those events. Each rule defines one or more queries that filter and aggregate events over a time window.
  3. 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.
  4. 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.
  5. 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.
  6. 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–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 — 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