Incidents

An incident groups related alerts so your team can investigate and resolve them as one case. This page explains how to create incidents, add alerts to them, assign and work them, and close them, what UTMStack sends when an incident is created, and how a managed service provider works on a customer's incidents.

When to open an incident

Open an incident when an alert needs more than a quick decision, for example:

• The alert is a real threat that needs containment, such as a successful logon after a brute force, or malware on a host.

• Several alerts describe the same attack: one attacker hitting several hosts, or several stages of one attack (phishing, then a new inbox rule, then data access).

• The work involves several people or will take more than one shift.

• You need a record for management, an auditor or a customer.

For a single harmless alert, completing it with an observation is enough. See Alert Triage Workflow.

Who can use incidents

Go to Threat Management > Incidents.

Incidents belong to one tenant. Every user of the tenant with incidents.read sees all its incidents.

The incident list

The header shows how many incidents match and how many are open now, for example "12 incidents · 4 open now".

The table shows Incident, Status, Severity, Assignee, Alerts (how many alerts are linked) and Created, newest first, 50 at a time as you scroll. Click the status of an incident to change it.

The Board shows four columns, Open, In review, Completed and Merged, each with its count and up to 200 incidents in all. Each card shows the name, the severity and the number of linked alerts. The status tabs do not apply to the board, and you cannot drag cards between columns: open an incident to change its status.

Create an incident

From the Incidents page

1. 1

   Start the wizard

   Click Create incident. The Create incident dialog opens at "Step 1 of 2".

2. 2

   Describe the incident

   Enter a Name (required), a short title such as Credential attack on dc01 from 203.0.113.45, and a Description with the context, scope and first findings. Click Next.

   
3. 3

   Pick the alerts

   The list shows every top-level alert, newest first, 50 at a time as you scroll. Use Add filter to find the alerts, for example Adversary IP is the attacker's address. Tick one or more alerts; the footer counts them ("3 alerts selected"). Use Back to change the name or description.

4. 4

   Create

   Click Create. You need a name and at least one alert. UTMStack confirms with "Incident created".

From the Alerts page

On Threat Management > Alerts, use Add to incident in the alert panel or in the bulk bar, or click the incident icon on a row (Create incident from this alert). Choose:

• New incident: enter an Incident name and an optional Description, then click Create incident.

• Existing incident: Pick an incident, then click Add to incident.

The dialog says how many alerts will be linked. This is the quickest way when you are already looking at the alerts.

Rules

• Incident names are unique in your tenant and at most 255 characters.

• An alert can belong to only one incident. Linking it again is refused with one or more alerts are already linked to an incident. Alerts already in an incident show the Incident badge.

• One request can link at most 1,000 alerts.

• Linked alerts show Part of an incident with the incident name, ID, who created it and when.

• Linking an alert does not link its echoes (repeats grouped under it). They follow the alert's status, see Statuses below.

• Incidents cannot be deleted. Use a clear name, and the Merged status for duplicates.

Severity

An incident's severity is the worst severity of its alerts (High, Medium or Low). Adding alerts can raise it but never lowers it. Unlinking an alert works it out again from the alerts that remain. An incident without a severity shows Unrated.

Statuses

Change the status with the status buttons at the top of the incident panel, or by clicking the status in the table.

The incident panel

Click an incident to open its panel. The header shows the status, severity, ID (for example #1042), assignee, creation date and number of alerts, and an Ask button when SOC-AI is available to you (see SOC-AI Assistant).

• Status buttons: Open, In review, Completed, Merged.

• Assignee menu: Search users… (up to 500 users), Assign custom to type any login, or Unassign.

Work an incident from start to finish

1. 1

   Create it and assign an owner

   Create the incident from the alerts that started it. Assign it to the person who leads the work, and set it to In review. Every linked alert moves to In review with it.

2. 2

   Write down what you know

   In the Description, say what happened, which hosts and accounts are affected and what you have checked so far. Use Notes for findings as they come in, one note per finding, so the timeline is clear in History.

3. 3

   Find every related alert

   Search for other alerts from the same attacker or against the same host, and add them to the incident:

   • Threat Management > Alerts: Add filter > Adversary IP is the attacker's address, time range All time. Select the alerts and use Add to incident > Existing incident.

   • Adversary View: see which systems the attacker reached.

   • Log Explorer: search the logs for the address or account. See Log Explorer Query Cookbook.

4. 4

   Contain and fix

   Act on the hosts and accounts involved: block addresses, reset passwords, isolate machines. Administrators can run a shipped response flow from an alert's row (see Alerts) or run commands with SOAR > Interactive Console. Record each action in Notes.

5. 5

   Write the solution

   On the Overview tab, type in Solution what caused the incident and what was done, for example "Password of svc-backup reset, 203.0.113.45 blocked on the firewall, dc01 checked, no persistence found."

6. 6

   Close it

   Click Completed. The solution is saved, and every linked alert is set to Completed with the solution as its status note.

For a duplicate incident, add its alerts' context to the incident you keep (as a note), then set the duplicate to Merged. Merged does not move alerts: an alert stays linked to the incident it was first added to.

Email when an incident is created

When an incident is created, UTMStack sends the email New incident: <name>, with the incident's severity, status and description, to the Incident recipients set on Configure > Settings > Email Configuration (To and CC). If To is empty, no email is sent.

Adding alerts, assigning or changing the status does not send email, and there is no notification-bell message for incidents. Tell the assignee yourself, or use a response flow that sends a message. See Alert and Incident Notifications.

Sharing incident indicators with ThreatWinds

UTMStack can share indicators from your incidents with ThreatWinds, the threat intelligence service behind UTMStack's feeds. This is controlled by the switch Contribute incidents on Configure > Settings > ThreatWinds Integration, which is on for new installations.

While it is on, every 5 minutes UTMStack reads all incidents with the status Open or In review, in every tenant on the server. From the events of their alerts it takes values such as IP addresses, host names, domains, URLs, file hashes, email addresses, user names and file names, and sends them to ThreatWinds. UTMStack does not remove private (internal) addresses or user names before sending.

Read Threat Intelligence: How Indicator Alerts Work for the full list of what is sent, and turn the switch off if your policies do not allow this.

Managed service providers: working on a customer's incidents

On a multi-tenant licence, each customer tenant's incidents are private to that tenant. The instance operator (the administrator of the default tenant) can see or work them only when the tenant's administrator allows it on Configure > Settings > Support access:

To work inside a customer tenant, the operator clicks Enter on the tenant's card on the Tenants page, or picks the tenant in the tenant switcher in the top bar. A banner says You are working inside the tenant. Everything done there is recorded in that tenant's audit log, and incident emails go to that tenant's Incident recipients. See Support Access and Tenants.

Troubleshooting