Reporting: Alert Overview

Document created by RSA Information Design and Development on Sep 14, 2017Last modified by RSA Information Design and Development on Oct 15, 2017
Version 9Show Document
  • View in full screen mode

Alerts can be used to generate timely insights about current security issues, vulnerabilities, and exploits. For example, when a malicious email is sent from a compromised account, you would need an alert that automatically notifies you when such an event occurs.

The following concepts of alerting will help you understand more about alert rules, conditions, notifications, and templates.

Alert Rules

Alert rules specify the logic for alert generation. Alert rules allow you to set up threshold limits and define how to be notified if these limits are exceeded. For example, you may set up a rule to be alerted if the CPU usage remains abnormally high for 5 minutes or more.

Alert Definitions

The alert definition is similar to defining rules for reports. These rules must be defined based on your use case. Alert definitions are made by selecting the alert rules you define in the Build Rule view. You select this rule while defining an alert.

Note: You can only alert using rules defined for NetWitness data source.

Once an alert is created, this data is collected from the Reporting Engine and displayed on the user interface.

Once an alert is defined, you can schedule the alert to run every minute (by default), or run at the present time, or run at the near future.

Note: In the NetWitness user interface, wherever Date and Time is displayed, it is always according to the user selected time zone profile.

Alert Definition

Alert Notifications

The following are the components required to configure alert notifications:

  • Notification server – Notification Server is used to send alert notifications. For example, SMTP mail server. Once you configure a notification server, you can add it to a rule. When the rule triggers an alert, the rule will use that server to send alert notifications.
  • Notifications – Alert outputs, which can be email, SMTP, SNMP, and Syslog.
  • Templates – The pre-defined format of an alert message.

When ever the rule condition is encountered, alerts get generated based on the severity level and notifies the user depending on the notification method set for that specific alert. The following are the various notification methods:

  • Email/ SMTP: Simple Mail Transfer Protocol (SMTP) sends alert emails for system activity. Email alerts can be sent to their intended recipients by selecting SMTP as notification type.

  • SNMP: Simple Network Management Protocol (SNMP) sends alerts to multiple computers for SNMP traps. SNMP alerts can be sent to other computers by selecting SNMP as notification type.
  • Syslog: Syslog alerts generate notifications from Syslog messages. Syslog alerts can be sent by selecting Syslog as notification type.

Alerts can be configured to notify events that require attention, or as mechanisms to take automated actions based on conditions configured in an alert. An alert is sent when conditions within the entity have met the criteria selected for the alert. The notification criteria determines when and at what frequency the alert is generated.

Alert Templates

Alert templates are pre-defined format for an alert message. You can use these templates to create alerts.

Access Control for Alerting

Depending on the user role, the user is provided with specific set of access permissions in order to manage an alert. The Administrator manages the access rights provided to each user role from the Administration > Security > Roles tab. You can set access permissions for the user roles to manage an alert. The Reporting module provides access control at the alert level.

Note: Reporting Engine Alert permissions are prefixed with 'RE' to distinguish them from Event Streaming Analysis (ESA). 

When you create users and user roles, ensure that the roles that you create for specific tasks have access to all the necessary permissions. This could require permissions at several levels of the role hierarchy.

Alerts can be combined with a specific set of user roles so that when a user logs into NetWitness, the only alerts they can access are alerts accessible by the role to which the user belongs. Users that belong to a user role with the ‘Read & Write’ access permission can define alerts. The access can further be tightened so that the alerts are accessed only by those who have the ‘Read Only’ access.

At the alert level, you can set the following access permissions for the user roles in NetWitness:

  • Read & Write
  • Read Only
  • No Access

Note: Before applying the Alert permissions, the default permission set for all the user roles is 'No Access' permission and the checkbox is unchecked.

If you want to change the access permission for a specific user role, you must set it at the alert level. Except for administrators, the default permission set for all the other user roles is 'No Access' permission.

The two scenarios are explained in brief:

  • Scenario 1: Permissions applied to alert/ rules based on the user role.
  • Scenario 2: Read-only permission applied to rules in the Alert.
                         
 

Role

(Analysts)

Permissions applied to Alert/ Rules based on the user role Permission (Read-only) applied to Rules in the Alert
Alert Read & Write Read & Write Read & Write

Rules

Read

Read

Read

The Alert is assigned the role of a Security Analyst and permissions are set to Read & Write alerts.

For scenario 1, each of the levels has a permission set based on the user role. For scenario 2, the Read permission is set for the Rules except that the permission for the rules must not be higher than the permission for the Alerts.

If the permission for the rules is higher than the permission for the Alerts, the permission is not applied. For example, if you set the permissions for the Alert as No Access and then specify the option Apply Read-only permission to Rules in the Alerts, the read-only permission is not set for the rules.

Access Control for an Alert When Multiple Alerts are Selected

When you want to change permissions of multiple alerts, you must select several alerts and set their access permissions using the Alert Permissions panel. The access permission that you choose is applied to all the selected alerts.

Login as a specific user and view the access details

When you login to the NetWitness UI as a user having Read access permission, all the alerts will be denoted with the symbol () and when you click on the symbol the 'Read Only' callout is displayed on the Alert List panel.

When you login to the NetWitness UI as a user not having Read & Write access permission on an Alert, all the alerts will be denoted with the symbol () and the alerts appear grayed out on the Alert List panel.

The following figure shows the Alert List panel when logged in with minimal Read & Write access permission.

alert diff user

Note: If a user (other than ADMIN) creates an alert, ADMIN cannot access that alert.

The following table lists the various columns in the Alert Permissions panel:

                               
ColumnDescription
RolesThe role of the user logged into the NetWitness user interface.
Read & WriteThe user can access, view, edit, import, export, and delete the alert on the Alerts page. The user can also change the permission on the alert.
Read OnlyThe user can only access and view the alert on the Alerts page.
No AccessThe user cannot access or view the alert for which this permission is set. 
IconCheckbox.png Apply Read-only permission to Rules in the Alerts The user can automatically apply permissions to the rules in the alerts.

The following is an overview of the entire process of alerting:

alert workflow

To configure and generate an alert on Reporting Engine, perform the following:

  1. Configure Reporting Engine
  2. Configure an Alert
  3. Schedule an Alert
  4. View an Alert
  5. Investigate an Alert
  6. Manage an Alert and Alert Template
You are here
Table of Contents > Alerting Overview

Attachments

    Outcomes