One case per attack, not one alert per event.

Where incidents come from

An incident opened from a finding starts with the finding’s title and its level as the severity (informational becomes info). Each finding that joins later raises the severity to the worst seen, widens the first and last seen times, and adds one to the event count.

What makes two findings one case

A new advisory or live finding joins an open incident when all of these hold:

• The incident is not resolved, and was last seen within the past 24 hours.
• Both are in the same project, or both are workspace-wide.
• Both are drills, or neither is. Drill findings open drill incidents, kept apart from real ones.
• They share a subject, or the incident holds a finding from a rule linked to this one.

Findings of one rule that the rule itself correlates, such as one brute-force wave, also share a subject. When more than one incident qualifies, the one with the most shared subjects wins, then the most recently seen. A rule link alone ranks below any shared subject.

Working an incident

open → investigating → contained → resolved

Any member who can see an incident can change its status and severity, assign it to a member of the workspace, add notes, and move findings in or out. An incident assigned to you appears under Assigned to me in Shield → Incidents and in tilldev shield incidents --assignee me.

The timeline

One timeline, oldest first, interleaves the notes and changes people made, each finding as it fired, each playbook run, and each step that finished with what it did. The timeline is append-only; nothing is edited away. Every change a person makes to an incident, and every step a playbook takes, is also written to the workspace audit log.

Moving findings

Attaching a finding that is in another incident moves it, and both timelines say so. A finding can only join an incident in its own project and of its own kind, drill or real. A resolved incident takes no new findings until it is reopened.

Closing with a verdict

Name the ATT&CK techniques the incident showed, such as T1110 or T1078.004. Ids are checked against the ATT&CK catalogue TillTell ships, and revoked ids are refused with the one that replaced them. Reopening an incident clears its resolution. A resolution can also be changed after the fact.

Merging

Merge folds up to 20 incidents into one open incident. Each merged incident is resolved as a duplicate pointing at the one it went into, and its findings and runs move there. Incidents in different projects, or a drill and a real one, cannot be merged. A merged incident cannot be reopened: reopen the one it went into.

What real incidents teach

Shield → Incidents → Rule backlog lists the incidents resolved as real in the last 180 days that had no TillTell finding in them, grouped by the techniques they were resolved with. Each technique there is detection you are missing. The ATT&CK coverage map shows the same count on each technique, and tilldev shield tell coverage lists it.

Owners and admins can leave an incident out of the backlog, for example one a rule could never see, and put it back later. Drill incidents never count.

Linked rules

Some attacks show up as findings from different rules that share no subject: a credential-stuffing wave from many addresses, then a sign-in from a new country on an account it reached, say. The backlog page suggests rule pairs that fired together in at least two real incidents. Owners and admins link them there or from the CLI, and from then on a finding from either rule joins an open incident that holds the other.

Who sees what

A developer or viewer limited to some projects under Settings → Team (“Limit access”) sees incidents, findings and playbook runs in those projects plus workspace-wide ones, in the dashboard, the bell, the CLI and the API. Anything else answers as not found. Linking rules and changing the backlog are for owners and admins; everything else on this page is open to any member who can see the incident.

Alerts

A new incident lights the notification bell. Findings that joined an incident do not ring on their own, and drill incidents never ring. Security alerts by email, Slack and webhook still go out per finding as set in Shield → Settings, and the webhook body carries the finding’s incident_id.

From the terminal

# the queue, and one incident in full
tilldev shield incidents --status open,investigating
tilldev shield incidents --assignee me
tilldev shield incidents show <incident-id>

# triage
tilldev shield incidents set <incident-id> --status investigating --assignee <user-id>
tilldev shield incidents note <incident-id> "blocked the range at the edge"
tilldev shield incidents attach <incident-id> <finding-id>
tilldev shield tell escalate <finding-id>

# close it out
tilldev shield incidents resolve <incident-id> --as real --techniques T1110,T1078
tilldev shield incidents merge <incident-id> <duplicate-id> <duplicate-id>

# what to build next
tilldev shield incidents backlog
tilldev shield tell links add tell-cred-stuffing tell-login-new-country --note "same campaign"
tilldev shield playbooks runs --incident <incident-id>

The same operations are on the HTTP API under /api/shield/incidents/… and /api/shield/tell/links, documented in the API reference.