6.1 Viewing and Triaging Alerts in Alert Views

To view and analyze alerts, you must first create the alert view. To configure the alert view, you must either be an administrator or have the Manage Alerts permission. For more information, see Visualizing Network Traffic in NetIQ Sentinel Administration Guide.“

6.1.1 Creating an Alert View

To view and analyze alerts, you must first configure the alert view.

To create an alert view:

Log in to the Sentinel Web console.
Click Real-time Views > Alert Views > the Create icon.
Specify the following information:
- Name: Specify a name for the alert view.
- Sharing: Select either of the following options:
  - Public: Allow everyone to view the alert view. In the public mode, you are the owner of the alert view and other users cannot edit it.
  - Private: Only you will be able to view the alert view.
- Data sources: Add other data sources from which you want to view alerts. For information about data sources, see Configuring Data Federation in the NetIQ Sentinel Administration Guide.
- Criteria: Specify the criteria to filter the alerts.
- Tenant: If you are in a multi-tenant environment, select the department or the tenant name for which you want to view alerts.
  
  NOTE:This option is displayed only if you are an administrator in a multi-tenant environment. For information about multitenancy, see Configuring Sentinel for Multitenancy in the NetIQ Sentinel Administration Guide.
- Time range: Specify the time range for which you want to view alerts.
- Use alert period: Select Created or Modified to view the alerts that were created or modified in the specified time range.
Click Save to save the alert view.

6.1.2 Viewing Alerts

Sentinel provides a graphical and tabular representation of alerts that match the specified alert criteria. The charts represent the alerts overview information classified by Priority, State, and Severity. The alert view table displays only distinct alerts. Duplicate alerts are rolled up to a single distinct alert. For more information about rolling up of duplicate alerts, see Configuring Alert Notifications in the NetIQ Sentinel Administration Guide. The alert view table provides information about an alert such as, severity, priority, owner, state, occurrences, and so on. Alerts from Sentinel servers in distributed location are distinguished by the Remote icon () next to the name of the alert. You can view the IP address of the remote Sentinel server by moving the mouse over the name of the alert.

NOTE:The alerts displayed in the alert view are filtered depending on the manage alert permissions and the tenancy of the user role. For more information about permission to manage alerts, see Configuring Roles and Users in the NetIQ Sentinel Administration Guide.

To create customized charts and tables for further analysis of the alert data, see Section 6.2, Analyzing Alert Dashboards.

To view alert views:

In the Sentinel Web interface, click Real-time Views > Alert Views.
Select the desired alert view and click the Open alerts view icon.

As you visualize and monitor alerts, you can perform the following activities in the alert view:

Mouse over the charts to determine the number of alerts based on alert states, priority, and severity.
Sort alerts based on one or more columns in the table. Press Shift+click to select multiple columns to sort. By default, the alert view table displays alerts based on the time when the alerts were triggered. Therefore, the latest alerts are listed on the top in the table.
Assign alerts to a user or a role, including yourself or your role.
Modify the alert state to indicate the progress on the alert investigation.
Add comments to the alert to indicate the changes you made to the alert, which helps you to keep an up-to-date record of the alert investigation. For example, you can add comments when you change the state of a specific alert or when you have gathered more information about the alert. Providing specific comments allows you to accumulate knowledge about a particular instance of the alert and track how a particular condition was addressed. Comments are important in tracking the alert, particularly if the process of resolving the alert spans several users or roles.
View events that triggered the alert and drill-down further to the extent of viewing the user identities that triggered the event by clicking the View details icon in the alert view table.

The Alert Details page displays a detailed information about an alert including the following:
- Source: Displays the correlation rule that generated the alert. You can also annotate the correlation rule by adding information to the knowledge base so that future alerts generated by this correlation rule include the associated historical information.
- Knowledge Base: Knowledge base is a repository that contains information about the conditions that resulted in the alert. It can also include information about resolution of a particular alert, which can help others resolve similar alerts in the future. Over time, you can collect a valuable knowledge base about the alert specific to a tenant or an enterprise.
  
  For example, an employee has recently joined the organization and does have the access permissions to a secured server. But this employee might not have been added yet to the authorized users list. Therefore, an alert is generated every time the employee tries to access the server. In such a case, you can add a note in the alert knowledge base to indicate that the “employee is approved to access the server, but is not yet listed in the authorized users list. This alert can be ignored and set to low priority.”
  
  NOTE:To view or edit the knowledge base, you must be an administrator or have the View Knowledge Base or Edit Knowledge Base permissions.
- Alert Fields: Displays the alert fields that provide the following information:
  - who and what caused the alert
  - the assets affected
  - the taxonomic categories of the action that caused the alert, the outcome, and so on. For more information on taxonomy, see Sentinel Taxonomy.
  For more information about alert fields, click Tips on the top-right corner of the Sentinel Web interface.
- Trigger Events: Displays the events that triggered the alert. You can investigate the conditions that triggered the alert by examining the trigger events. By default, the Alert Details page displays 10000 trigger events per alert. You can also define this number as necessary. For more information, see Configuring the Number of Trigger Events to be Displayed in the Alert View in the NetIQ Sentinel Administration Guide.
  
  You can also perform necessary actions on these events similar to how you would do with the events in a Search page. To view the alert trigger events in the Search page, click the Search icon. Sentinel displays the events that triggered the alert in a new Search page.
  
  NOTE:Although the alert may include trigger events older than the configured data retention period, the search will only return events that are within the data retention period.
  
  For information about manually performing actions on events, see Section 11.0, Manually Performing Actions on Events. You can also perform other event operations such as adding these events to an incident, exporting these events to a CSV file, and viewing the vulnerabilities associated with these events. For information about performing event operations, see Section 3.5, Performing Event Operations in Section 3.0, Searching Events.
- Show history: Displays the changes made to the alert, which helps you track any actions taken on the alert.
- Identities: Displays the list of users involved in the alert. This information helps you to investigate about the users involved in the alert and monitor their activities.

6.1.3 Escalating Alerts to an Incident

After performing adequate investigation on an alert, you may determine there is some serious problem and the alert needs further investigation by the security analyst. You can escalate such alerts by creating an incident without losing all the work you already did as part of the alert investigation.

You must have any of the following permissions to escalate alerts to an incident:

Create incidents, add events and escalate alerts to incidents
Create, modify and execute actions on assigned incidents
Manage all aspects of incidents: create, modify and delete

In multi-tenancy environments, only users in the default tenant can escalate alerts to incidents.

You can escalate alerts either to an existing incident or create a new incident. When you select the option to escalate alerts to an existing incident, Sentinel lists the existing incidents.

By default, Sentinel displays 500 incidents in the list. To configure the number of incidents you want to view by default, see Configuring the Number of Incidents to be Listed in the Incidents List in the NetIQ Sentinel Administration Guide.

Sentinel sorts the list of incidents based on the relevance of the incident to the selected alerts. The relevance score of the incident helps you to easily identify the appropriate incident rather than having to scroll through the entire list of incidents. The relevance score ranges from 0 to 100. The higher the score the higher the relevancy of the incident to the selected alerts. Incidents with the following properties have a higher relevance score:

Incident name matches with any of the selected alerts’ names.
Incident already contains alerts whose names match with the names of any of the selected alerts.
Incident name matches with any of the selected alerts’ names and the incident also contains alerts whose names match with the names of any of the selected alerts.

Sentinel considers only the first 50 selected alerts to calculate the relevance score.

When you escalate alerts to an incident, Sentinel attaches the events that triggered the alert, asset details, and alert comments to the incident. By default, Sentinel attaches 25 trigger events per alert to the incident. To configure the number of trigger events to be attached to the incident, see Configuring the Number of Alert Trigger Events to be Attached with the Incident in the NetIQ Sentinel Administration Guide.

After you escalate an alert, Sentinel changes the alert state to Closed. If you want to escalate the same alerts to a different incident, you can re-open the alerts and escalate them to a different incident. However, you cannot re-escalate the same alerts to the same incident again. If there are additional trigger events to the same alerts that were already escalated and you want to add those events to the same incident, you can open the alert trigger events in the search pane and then add the additional trigger events to the already created incident. For more information, see Section 3.5.3, Adding Events to an Incident.

To escalate alerts to an incident:

In the Sentinel Web interface, click Real-time Views > Alert Views.
Select the desired alert view and click the Open the alert view icon.
In the Alerts View panel, select the desired alerts and click Escalate.

or

Select the alert you want to escalate, click the View Details icon and then click Escalate.

You can escalate only alerts that are not in the Closed state.
Specify the reason for escalation.
(Conditional) To verify whether there’s an existing incident for the selected alerts, click Select an existing incident, select the relevant incident, and click Escalate.
(Conditional) If there is no matching incident for the selected alerts or you want to create a new incident, click create a new incident.

Sentinel populates the default values for the incident based on the selected alert. If you selected more than one alert, Sentinel populates the incident values based on the first alert you selected.

Specify the required information, and click Escalate. For more information about the incident parameters, see Section 16.2, Creating Incidents.

NOTE:If you try to escalate the same alerts to the same incident again, an error is displayed and the Escalate button is disabled. Click Cancel to cancel the escalation and escalate the alerts to a different incident.

For more information about viewing and managing incidents in the Sentinel Control Center, see Section 16.3, Managing Incidents.