VERISCO Alertio Correlate
Incidents
An incident is a group of related alerts that together describe one attack. This page explains how they are built, how to read one, and how to work it to a close.
Open Incidents in the Detect group. Where Alerts shows individual events, Incidents shows what those events amount to.
The kill chain#
Every alert is placed on one of six stages, from its MITRE ATT&CK technique where it has one, and from its rule groups otherwise.
| Stage | Covers |
|---|---|
| Reconnaissance | Scanning, enumeration and discovery. |
| Credential Access | Brute force, password spraying, credential theft, and suspicious successful sign-ins. |
| Exploitation | Exploiting a service, code execution, initial access. |
| Privilege Escalation | Gaining higher permissions, such as joining an administrators group. |
| Lateral Movement | Moving from one host to another. |
| Impact | The damaging action: data destroyed, modified or encrypted. |
Informational events, such as a routine successful sign-in, are not a stage on their own. They become evidence only when they sit inside an attack.
How far along the six stages an attack got is the incident's kill-chain depth. It is the most useful way to order the list: the deepest attacks are the most developed.
How alerts are grouped#
The correlation engine threads alerts by the entity they concern: an address, a host, or a user account. Threading by user is what keeps an attack together when it crosses network zones: the same account phished on the mail server, used to sign in to the domain, then added to an administrators group, is one incident, even though the source address changed halfway through.
When a sequence of alerts matches one of the correlation patterns, an incident is opened and a notification is raised.
Reading an incident#
Select an incident to open it.
| Part | Tells you |
|---|---|
| Title and summary | What happened and to whom, in one line, then the story in a sentence: for example, privilege-group modification on the domain controller followed by a security group deleted. |
| Risk score | How serious the incident is overall, from 0 to 100. |
| Facts row | Source address, agent, blast radius, first seen, last activity, duration and assignee. |
| Kill-chain progression | Each stage, whether it was reached, when, and with how many alerts. Every reached stage is backed by real alerts. |
| Affected assets | The blast radius: every machine involved, with its criticality. |
| Evidence | Every correlated alert, as a Timeline, a Table or a Graph, with the entity it was grouped on. |
| AI attack story | On request, a written account of how the attack started, how it moved, why these alerts belong together, and a recommended response. |
Working an incident#
| Action | Use it to |
|---|---|
| Acknowledge | Record that the incident has been seen and is being handled. |
| Run playbook | Start a playbook against this incident. |
| Generate attack story | Produce the written narrative, useful for handover and reporting. |
| Close | Mark the incident resolved. Confirmation is requested. |
Acknowledge and close can be applied to several incidents at once from the selection bar. Both require the Analyst or Administrator role.
Finding incidents#
| Control | Restricts to |
|---|---|
| Tabs | Open, Reached impact, Unacknowledged, Closed. |
| Summary tiles | The matching filter, for example open critical incidents. |
| Stage bar | Incidents that reached at least the stage you select. |
| Severity chips | One or more severities. |
| Agent and Any depth | Incidents involving one endpoint, or that reached a minimum stage. |
| Search | Pattern, entity, address and agent. |
Something missing or wrong on this page? Tell us and we will fix it.