Cloud-delivered Advanced AnalyticsExabeam Advanced Analytics User Guide

Exabeam assigns a risk score to users and their IT environment sessions by combining user behavior intelligence and fact-based information. In a single session, Exabeam may report risk related to abnormal access to an asset, a security alert received from a 3rd party system, a new user being created from a new network location, and changes to the access privilege of the user. Asset criticality and threat intelligence information can also be factored into the risk analysis.

The following major components work together to produce a risk score:

To build a baseline, Exabeam extensively profiles the people, asset usage, and sessions (Exabeam’s word for profiling or base-lining is training). In a typical deployment, Exabeam starts by examining 90 days of an organization’s logs. After the initial baseline analysis is done, Exabeam starts scoring the sessions. Note the following:

When Exabeam categorizes behavior as anomalous, it does so based on rules and models that it applies to users, assets, peer groups, and the organization as a whole. In the case of an employee who exhibits suspicious behavior or a security device that posts an alert, Exabeam will display events that are not normal for that user or asset. However we don't display only abnormal events. We also display normal events so that the Analyst can have the full picture and can understand what led to the anomalous event. For example, behind the suspicious behavior could be VPN requests from countries never before seen or remote logons to assets or network zones that never have been accessed.

Before evaluating a specific event, Exabeam must have confidence in the basis of its evaluation of that event. In Exabeam’s case, this basis means enough quantity and consistency of data for each user and their attributes. If Exabeam lacks enough data for a specific type of event, it does not evaluate the rule for that event even as it evaluates other rules during the session. However, note that the confidence factor is not taken into account for the first time a rule is triggered.

The confidence in each user’s profile is built during the initial baseline development as well as on an ongoing basis as new events arrive. In contrast, some behaviors might require Exabeam to take more time to establish confidence. For example, if a user’s job involves irregular foreign travel, establishing confidence in a profile of VPN sessions from foreign countries takes longer.

An example of profiling that might never lead to confidence in one area of behavior is a behavior that changes every day. The only predictable thing about this behavior is that it changes daily. For example, if an ISP starts a policy of assigning a different IP address every day, Exabeam cannot establish a histogram that applies to that behavior. An organization can accept this because if the new IP address were part of an attack, many other rules would be triggered. Put another way, a new IP address every day does not automatically indicate a threat. The total score for all anomalies during a session indicates attacks.

Analysts also have an option for choosing certain behaviors to accept, as the Sessions chapter describes. After sufficient examination of a session, an analyst can manually add the session’s events to a user’s profile so that those events stop triggering the applicable rules.

Access to configuration, data views, actions, and analysis in Advanced Analytics is restricted based on user-assigned roles. Roles are functional groups you configure and adjust based on your organization’s task structure.

For example, you may have two tiers of security analysts along with a group of auditors who all need access to Advanced Analytics. The three groups do not have equal level of privileges to view, run tasks, or adjust system configurations. You may have roles named SA1, SA2, and Auditor. While users in the SA1 and SA2 roles are allowed to view notable users, those in the Auditor role may not. A SA1 user may make a copy of URLs from a suspicious session and sends it them to a user in SA2 who can see the information in clear text. Another SA1 user will not be able to see that same information if the role excludes viewing data that is masked due to privacy policies.

Users are assigned a role in their profile. More than one role can be assigned, but be aware of tasks with conflicting privileges. In the case of conflicting privileges, we combine the privileges and give all explicitly allowed permissions between them.

When a user tries to access a view, menu, or execute a task outside the designated role, an error message is presented advising the user does not have sufficient privileges.

For information on how to configure access restrictions, see Universal Role-Based Access in the Advanced Analytics Administration Guide.

Exabeam supports Data Masking to meet the data privacy directives of enterprise organizations.

It ensures that personal data cannot be read, copied, modified, or removed without authorization during processing or use. With data masking enabled the only SOC analysts that will be able to see clear text PII will be those administrators that are assigned to the Data Privacy Officer role. All other administrators will see disguised information:

Data Masking can be enabled via a configurable setting. It is turned off by default. Please see the Administration Guide for more information on how to enable the feature.