Alerts

Alert Tabs

Each alert tab contains a view of the alerts as seen by the Sensors connected to the Command Center.

Alert Tab Templates:

Upon selecting the Add a New Tab button, the user can choose from a list of predefined templates. The currently available Alert templates are:

• Default

• All Alerts

• Anomalies
• Asset Lifecycle
• IOC Matches
• Malware & Exploits
• Networking Issues
• Open Cases
• Operational Issues
• Other Security Events
• Weak Security Posture

A user can rename, clone, export and delete tabs to create a view in which all information relevant to them is easily accessible. For each selected Alert tab, click the three dots next to the tab name to view the following options:

• Rename: rename the tab
• Clone: clone the tab
• Export: export the tab in JSON format
• Delete: delete the tab

In each alert tab, the following charts are displayed:

• Alerts per category
• Alerts per sensor
• Alerts per severity
• Alerts over time

Alerts Table

With each Alert tab, the alerts table is displayed in the bottom half of the screen. Use the Table / Cases toggle in the top-right corner, above the table to switch between the alert table and alert cases.

The Alerts Table lists the Alerts that match the currently selected filters. Users can leverage Alert Grouping to effectively identify trends and correlation among existing Alerts. Furthermore, by smartly applying filters and displaying the desired table columns, users can focus their analysis and compare Alerts and properties they are interested in. The table sorting functionality allows to rank Alerts based on their properties and details, for example: by Alert Severity or Source and Destination IP Address.

Each Alert will always contain at least the following information:

• A unique numeric identifier.
• A timestamp indicating when the (last) event happened.
• The Sensor from which the Alert was received.
• The Monitored Network monitored by the Sensor.
• The Module or Monitoring Profile that fired the alert.
• The Event Type IDs identifying the suspicious event type reported in the alert.

Depending on the detection engine, an Alert may directly map one-to-one with a suspicious event or be a collection of one or more suspicious events. For example, alerts fired by the Portscan Module map one-to-one with suspicious events, while Alerts fired by the LAN CP and DPBI Monitoring Profiles may group more than one event regarding the same TCP stream in one Alert. In the latter case, the information of each individual suspicious event is described in an Alert Detail. An Alert Detail always describes one single suspicious event. The remainder of this section describes the most important properties and operations that the user can perform on alerts.

The Alerts table shows the first 20 Alerts that match the selected Alert Filters. This is sufficient to, for example, see the last Alerts fired by a particular Sensor. It does however not give an overview of the Alert "situation": Are there any recurring Alerts?, Is one host raising many Alerts? To answer these kinds of questions, click on Aggregate alerts in the sub-menu. The Aggregated alerts overview takes all of the Alert Details from the Alerts that match the current Alert Filters and shows how often a particular Alert Detail was fired, how many endpoints were involved in the same Alert Detail and over what time span the Alert Details were fired. By using the Alert Filters, the operator can generate flexible aggregated overviews. For example, aggregating all Alert Details from the last week, from a particular Monitoring Profile, etc.

Since aggregating many Alert Details can be an expensive operation, the operator is asked for confirmation when more than 1,000,000 Alerts match the currently applied filters. Note that the Frequent Event Aggregation Module and Aggregated alerts overview are two distinct features in eyeInspect. Recall that the Frequent Event Aggregation Module is meant to aggregate events that are occurring too often. Once this happens, a FEA Enter Alert is fired and after the situation has resolved (i.e. the model has been trimmed so that the Alerts are no longer fired), a FEA Exit Alert is fired. The Alert Details fired in this period between FEA Enter and Exit are therefore also not counted in the view aggregated details table. The Frequent Event Aggregation Module and the Aggregated alerts overview complement each other.

The Frequent Event Aggregation Module fires an Alert when a particular event is suddenly occurring frequently, while the Aggregated alerts overview gives information about events that are recurring, but not fast enough for the Frequent Event Aggregation Module to trigger. Additionally, the view aggregated details page shows when multiple hosts are firing similar Alerts.

Filters

Users can apply filters to the Alerts table. The Filters row is present above the table. All filters on the page also apply to the Cases table.

Filtering cross-checks every host in the respective Alert view for a given condition. Only the alerts which match that condition are displayed. All filter fields that are filled in will be combined with a logical AND to create the condition to which a alert must conform to in order for it to be visible in the table. The current filter(s) can be deleted by clicking Reset All Filters at the end of the Filters row.

More information about the most-used filters is outlined below:

Event Type IDs An Event Type ID uniquely identifies the type of suspicious event that a Module or Monitoring Profile detected. Each Event Type ID maps to a name and description, a Detection Engine that can fire it and a default Alert severity that is assigned to an alert with that Event Type ID.

Status

The Alert Status field may assume eight possible values:

Not Analyzed	The Alert was received by the sensor and still not properly inspected by an operator
In Progress	The Alert is currently being inspected by an operator
Analyzed	The Alert has been inspected by an operator
False Alert	The Alert was inspected by an operator and judged to be a false positive. In other words, the operator decided that the reported events are normal network activities wrongly flagged as suspicious
Relevant	The Alert was inspected by an operator and judged to be relevant. In other words, the operator confirmed that the Alert reports about some malicious activities
Not Relevant	The Alert was inspected by an operator and not judged to be relevant. In other words, the operator decided that the reported events are either unusual but not malicious, or malicious but not interesting
Unknown	After inspecting the Alert the operator could not decide whether the reported events are malicious or not
Trimmed	If the Alert was classified as a false alert and the Module or Monitoring Profile was changed to avoid receiving these kind of Alerts in the future, the Alert status can be set to trimmed

The status of the Alerts received from a Sensor is by default Not analyzed. The value of the status field can be changed by the operator at a later time.

Severity

There are six levels of Alert Severity:

Informational	Restored service and generic logs
Low	Unusual operation; should not have direct impact on network or process but may lead to inefficiencies
Medium	May have long-term impact on network or process
High	May have direct/immediate impact on the network or process
Critical	Reserved for custom use cases that require immediate attention. Configurable through customization rules and scripts, not applied for built-in checks.
N/A	There is no information about the severity of this Alert

The severity is meant as a tool for operators to organize and schedule their operations: Alerts with higher Severity should be addressed before the ones with lower values. The severity tries to give a quick answer to the question: how bad is the fact that we see this Alert for the security of our system? For example, upon receiving new Alerts, an operator may first mark the ones that are directed to critical assets (e.g., a mission critical server) with a higher severity and then inspect Alert details in order of severity. The severity of the Alerts received from a Sensor is defined by a mapping and depends on the nature of the event that caused the alert. The severity and status assigned to new Alerts can also be defined using Alert customization rules.

Alert Category

The Alert Category filter enables users to better classify and assign the relevant alerts according to their type. There are five Alert Category groups:

1. Security
2. Networking
3. Anomaly
4. Operational
5. Others
6. Asset Lifecycle

In the Alerts table, the values in the Alert Category column are displayed as "Alert Category (Alert Category Group)”, e.g. "Loss of connectivity (Operational)”.

Additional Info

The Additional Info filter shows details about the source and destination host roles. Extended information is provided as additional info for alerts with specific event types that includes relevant information. Specific alerts can also contain new additional info that is relevant to them, such as:

• All
• Application
• Domain
• File
• Issuer
• Risk
• Share
• Suite
• Username
• Vulnerability
• Yara Rule Name (Malicious file)

It is possible that there is additional information that does not fit any of the above categories, For this reason, the All category exists in the list, which displays all the data without any restrictions.

Because alerts capture events at specific moments in time, each alert is populated with the source and destination host roles present when the alert was raised. As with many other situations, the roles of these assets may change at a later time.

Source and Destination Groups

The Source and Destination Groups filters allow you to view alerts data for assets that have been tagged with custom groups.

Alert Table Actions

To view the available alert actions, select one or more alerts from the alerts table, and click the Actions dropdown above the table to see the following actions:

Edit Alerts

Edit the properties of the selected alerts.

Delete Alerts

Delete the selected alerts.

Trim Alerts

Alert Trimming is only possible for alerts from LAN CP and DPBI.

New Case

While analyzing Alerts, an operator may realize that several Alerts are related, e.g. they are part of the same problem or threat. To allow the operator to group these Alerts into a Case and have new equivalent Alerts automatically associated with this Case, it is possible to create an Alert Case. This provides for a focused view when dealing with issues that involve many Alerts.

In addition, it is possible to assign the selected Alerts to:

Existing Case

Assign the selected alerts to an existing case.

Unassign from Case

Unassign the selected alerts from an assigned case.

Automatically assign Alerts to a Case

To allow eyeInspect to automatically assign incoming Alerts to a relevant Alert Case, the user can set assignment criteria based on Alert attributes. When a case has these criteria set, any new Alert that meets those criteria will be assigned to that case automatically. Assignment criteria can be defined based on any combination of the following Alert attributes:

• Destination and source hosts. Hosts can be identified using IP address, VLAN, IP reuse domain, or MAC address;
• Event names;
• L7 protocols;
• Destination ports
• Profiles and Sensors

An Alert must match all the assignment criteria in order to be assigned to a Case. If an Alert meets the criteria for multiple Cases, the Case whose criteria are most specific takes precedence. Alert attributes and related assignment criteria are evaluated in the same order as listed above. For example, a rule defining a source host takes precedence over a rule that defines a L7 protocol and a sensor. And a rule that has a destination host defined, will take precedence over the one with the source host criterion.

To further avoid clutter and allow the user to focus on new problems and threats, eyeInspect suppresses notifications for Alerts that are automatically assigned to a Case. This behavior can be changed under "Settings" > "System Settings" > "Storing rules and notifications" via the option "Disable alert notifications for alerts assigned to cases".

Alert Cases

The Alert Cases table displays a list of available alert cases. Use the Table / Cases toggle in the top-right corner, above the table to switch between the alert table and alert cases.

Alerts represent individual suspicious or undesired events occurring on the network. Several alerts may be related to each other, as for instance the repeated observation of a device malfunction indicator. Operators can create Alert Cases to group related alerts and instruct eyeInspect to automatically assign new occurrences of those alerts to that Case. Alert cases enable operators to focus on new threats appearing on the network, while keeping track of problems already being analyzed.

To create a new, empty case, click the "Actions" dropdown and then click "Create New Case." The Case creation dialog is shown.

When creating a new case, the Case name is obligatory and ideally should be short and descriptive. It is through the name that the case is most recognizable in the Cases table. A description field is provided for more detailed information about the case. This can be used to state the purpose of this case more clearly. The case's initial status is set to Open by default, but this can be changed here as well. These fields are in the Summary tab and are sufficient to create a Case.

Clicking on a row from the table opens a Details Dialog for the respective Case, which contains detailed information as well as all actions applicable to the Case.

When attempting to delete a Case either from its Details Dialog or from the Cases table, an option will be provided to delete also the Alerts associated to it.

Enriched Case Detail Dialog

From the Case Details window, you can try the new, enriched case detail dialog by using the toggle in the top right corner. The enriched view shows:

• Alert case details in map (visualizing the source and destination assets involved in the alerts of the case) and timeline (a graph that shows how the case progressed over time, grouped by event type) views
• Additional details such as alert count, duration of the case, number of unique event types and L7 protocols involved, in addition to the standard ID, name, creator and status details

Note that the view only supports cases with up to 10,000 alerts and/or 100 assets, and may take up to 90 seconds to load.