Working with triggered alerts
- Former user (Deleted)
- Anupriya Asthana
- Laszlo Frazer
[ Overview ] [ Data table registry of triggered alerts ] [ What tasks can be performed in the Alerts overview? ] [ What permissions do I need? ]
Overview
When an alert is triggered, a notification is sent through the specified channel. By managing Delivery Methods, you can set up and manage how and to whom alerts can be delivered.
Delivery methods are managed in the Administration → Alert configuration → Delivery Methods tab. Further, inside the relevant delivery method type tab, you can manage the delivery method.
This notification contains the details of the triggered alert and a link to access them in Devo. This allows the recipient to analyze the details and decide on a course of action. Here is an example of an alert notification sent via email.
Furthermore, all triggered alerts are displayed under the Alerts → Overview tab.
This is your control panel to track the alerts that have been triggered over time. There are two parts:
Top area: it displays a dynamic chart to visually analyze the overall quantity of alerts displayed in the bottom area, and the triaging options to filter them.
Bottom area: it lists all the alerts triggered in the domain, starting with the most recent one, and gives you the ability to carry out workflows related to managing the conditions that trigger the alerts.
Data table registry of triggered alerts
All triggered alerts are registered in the siem.logtrust.alert.info table at the time of generation. Additionally, they are registered in the devo.audit.alert.triggered table, which maintains a comprehensive record of all subsequent changes they undergo during their lifecycle.
When an alert should have been triggered but was not, for whatever reason, it is registered as an error in the siem.logtrust.alert.error table.
What tasks can be performed in the Alerts overview?
These are the different tasks you can perform in this area, such as:
What permissions do I need?
As there are many different tasks with different contexts to perform in this area, the set of permissions required is consequently very granular:
To access this area to see triggered alerts, see their details, open their queries, and create comments, you need the View version of the Triggered alerts permission.
To change the priority and status of the alerts or create post-filters, you also need the child permission to Update status/priority.
The Manage version of the Triggered alerts permission allows you to do all the above, and delete alerts (more info about permissions here).
The actions that imply interacting with the alerts definition will not show unless you have the Manage level of the Alert configuration permission (know more about alert definitions here).
Additionally, you need to have alerts assigned (see Assign resources to a role). You will only see triggered alerts for those alerts assigned and permitting only the interaction level specified for them. In other words, the permissions grant theoretical access to alerts, while assigning a specific alert grants the actual access.
