A signal is generated whenever a detection rule matches activity in your security events. Signals are where investigation happens: they show what was detected, how serious it is, which assets are involved, and the events that triggered it.

For how signals are produced, see Detection Rules and Signals Overview.

The signals list

Go to Security → Signals to see every signal your rules have generated.

A stat strip at the top summarizes signals by status, and you can filter the list by facets:

  • Severity — Critical, High, Medium, Low, Info.
  • Status — the triage state (see Signal statuses).
  • Source — the data source that produced the events.
  • Rule — the detection rule that fired.
  • MITRE Tactic — the ATT&CK tactic associated with the signal.

You can also sort by time, severity, source IP, action, or host.

Searching signals

The list accepts the same filter syntax used in rules. For example:

copy
icon/buttons/copy 
severity:critical AND -status:closed AND rule:*login*

Signal statuses

Signals move through a triage lifecycle. Opening a signal automatically moves it from New to Open.

Status Meaning
New Freshly fired and not yet reviewed.
Open Has been viewed but not yet resolved.
Investigating An analyst is actively working the signal.
Resolved Investigation is complete and the threat is handled.
False positive Determined not to be a real threat.

Status changes apply immediately and update the stat-strip counts as you work.

Inspecting a signal

Select a signal to open its detail view. It contains everything you need for first-pass triage:

  • Severity and status badges — the current impact level and triage state.
  • Description — the rule's message, rendered from its notification template.
  • Details — source, rule name and ID, MITRE tactic and technique, match count (how many events matched), and the triggered and updated timestamps.
  • Affected assets — the group-by values that triggered the signal, such as the source IP, host, or user.
  • Sample events — a sample of the events that matched the rule, with their time, severity, action, host, source IP, and user.
Note: Only a sample of matching events is stored on the signal for quick triage. To inspect every contributing event, pivot to the Events view.

Triage actions

From a signal you can:

  • Change status — move it to Investigating, Resolved, or False positive.
  • Assign an analyst — set an owner so the team knows who is handling it.
  • Suppress — temporarily mute recurring signals for 1 hour, 24 hours, or 7 days. Suppression is useful for known-benign activity while you tune the underlying rule.
  • Copy permalink — share a direct link to the signal with your team.

Signal groups

When a single rule fires repeatedly within its evaluation window — for example, the same brute-force pattern continuing — Atatus groups those fires into a signal group.

  • The group is summarized by the rule and its group-by values, so you triage the activity once instead of event by event.
  • A status change on the group cascades to every signal it contains. Resolving the group resolves all of its signals.

Reducing noise

If a rule produces signals you expect or do not care about, you have two options:

  1. Suppress at triage — use the Suppress actions on a signal or group for a quick, time-boxed mute.
  2. Suppress at the rule — add a suppression to the rule itself so the noisy pattern never generates a signal. This is the durable fix.

For built-in rules that are too noisy or not relevant, you can also disable them or override their severity from the Detection Rules list.

Next steps