Advanced AnalyticsExabeam Advanced Analytics Release Notes

If your Advanced Analytics deployment is running on Google Cloud Platform and aggregates all of your logs into Google Pub/Sub, you can now configure Google Cloud Pub/Sub as a log source for Advanced Analytics.

For more information on adding log sources in Advanced Analytics, please refer to the Advanced Analytics Admin Guide.

When adding new or managing existing Exabeam rule on the Exabeam Rules page, you can choose to reload individual or all rules. You can now choose to apply rule changes and reprocess historic data. When applying and reprocessing rule changes to historic data, the reprocess is done in parallel with active, live processing. It does not impede or stop any real-time analysis.

Advanced Analytics now logs specific activities related to administrators and users of the product, including activities within the UI as well as configuration and server changes, too. This is primarily needed to monitor administrator and analyst activities from a compliance perspective. Advanced Analytics activity data is collected and sent to the syslog destination of your choosing.

For more information on accessing Advanced AnalyticsData Lake log activity, please refer to the Audit Actions within Exabeam section within the Advanced AnalyticsData Lake Admin Guide.

We've made several changes to improve the usability of the Exabeam Analytics Engine.

You can now cancel in-progress reprocessing jobs. This is especially helpful if a particularly large reprocessing job slows the entire system, if you accidentally initiated a reprocessing job, or if you simply want to cancel the job for any other reason.

Additionally, we've updated the Reprocessing Jobs table to provide more details and control of your complete, pending, in progress, canceled, or failed reprocessing jobs.

For more information on the Analytics Engine in Advanced Analytics, please refer to the Advanced Analytics Admin Guide.

We've improved the Exabeam Analytics page to provide better detail and control on reprocessing jobs. You can now view the status of jobs (for example, completed, in-progress, pending, and canceled), view specific changes and other details regarding a job, and cancel a pending or in-progress job.

For more information on reprocessing with the Exabeam Analytics Engine, please refer to Restart and Reprocess section of the Advanced Analytics Admin Guide.

Exabeam helps manage the sizes of your models so that they can no longer cause Advanced Analytics to run out of memory. This is done by setting a max number of bins for categorical models. The new limit is 10 million bins, although some models, such as ones where the feature is "Country" have a lower limit. We have put many guardrails in place to make sure models do not consume excessive memory and impact overall system health and performance. These include setting a maximum limit on bins, enabling aging for models, and verifying data which goes into models to make sure it is valid. If a model is still consuming excessive amounts of memory then we will proceed to disable that model.

Disabled models are displayed on the System Optimization tab of the System Health page. There are two disabled models tables — the first contains a list of models that have been disabled for all entities (Global Models), while the second contains a list of models that have been disabled for specific entities (Model Instances) within Advanced Analytics.

You are also shown an indicator on the User or Asset Page when a model has been disabled for that profile.

In addition, model aging is now configurable and enabled by default, with a window of 16 weeks. For some models that contain more sensitive or rare data, e.g. models that track executives or privileged users, the cycle is 32 weeks. Model aging considers data samples taken from a certain number of weeks instead of all points since the beginning of time. This process enhances system performance by cleaning out unused or underutilized models.

For more information on the Model Sizing Improvements, please refer to Model Aging in the Configuring Advanced Analytics section and Disabled Models in the Health Status section of the Advanced Analytics Admin Guide.

As you continue to use Advanced Analytics, you may find that certain high volume users or assets within your organization amass a large number of events of certain event types. When this happens, Exabeam now takes preventive measures to protect the performance of Advanced Analytics by disabling these event types for a specific user or device.

Exabeam helps manage the event type volume by identifying and blacklisting top users and assets. When a specific activity type such as "web" for a certain user or device exceeds 10 million events and a specific event type within that activity type makes up 70% or more of the events in that total sum, then that event type for that user or device will be automatically disabled. If no single event type accounts for over 70% of the total event count in that activity type, then that entity is disabled. These thresholds are configurable.

Disabled event types are displayed on the System Optimization tab of the System Health page. You can see a list of all event types that have been disabled, along with the users and assets for which they have been disabled for.

You are also shown an indicator on the User or Asset Page when an event type has been disabled for that profile. The affected User/Asset Risk Trend and Timeline would account for the disabled event type by displaying statistics only for the remaining events.

For more information on the Top Users and Assets Improvements, please refer to System Optimization in the Health Status section of the Advanced Analytics Admin Guide.

Advanced Analytics automatically identifies poor parser performance and disables such parsers in order to preserve the system health.

We determine the average parse time for each parser in a five minute period. We compare that to a configurable threshold variable in lime.conf. Then we divide each by the total time taken by all parsers in the same five minute period and compare the values to a configurable threshold variable in lime.conf. If the parsers average parse time exceeds the threshold and it exceeds the second threshold of being over a certain percentage of the overall parse time by all parsers then it becomes a candidate for disabling. We perform the same check during a second five minute period and if the same holds true then we proceed to disable the parser.

A slow parser is disabled if its average parsing time is above the parsing time threshold and makes up 50% or more of the total parsing time of all parsers.

Disabled parsers are displayed on the System Optimization tab of the System Health page. You can see a list of all parsers that have been disabled.

You are also shown an indicator when Advanced Analytics determines that a parser is problematic and disables it.

For more information on parser defensiveness, please refer to System Optimization in the Health Status section of the Advanced Analytics Admin Guide.

Exabeam can automatically identify overloaded worker nodes, and then take corrective action by evenly redistributing the event category load across the cluster.

You can enable automatic system load redistribution on the System Optimization tab of the System Health page. This option is enabled by default. Doing so allows the system to check the load distribution once a day.

You are also shown an indicator in the UI when a redistribution of load is needed, is taking place, or has completed.

For more information on System Load Redistribution, please refer to System Optimization in the Health Status section of the Advanced Analytics Admin Guide.

The underlying native docker overlay network technology has been replaced with Calico in Data LakeAdvanced Analytics.

Compared to the native docker overlay technology, Calico brings the following benefits to all Exabeam deployments:

Adopting Calico resolves various overlay and network flapping issues with cluster containers that resulted in intermittent network connection breakdowns and UI restarts in Advanced AnalyticsData Lake deployments.

You must meet the following requirements before installing or upgrading to this release:

If you have questions about the prerequisites, please create a support ticket at Exabeam Community to connect with a technical representative who can assist you.

Previously, Advanced Analytics disaster recovery only supported a two-cluster (active and standby) deployment scenario. Now, you can configure a multi-cluster disaster recovery deployment involving three or more clusters. In this scenario, you can configure a source (primary) cluster and one or more destination clusters.

The primary cluster is responsible for fetching the logs from SIEM or receiving the logs via Syslog. The secondary cluster(s) are responsible for replicating data from the primary cluster.

For more information on configuring and managing disaster recovery, please refer to the Disaster Recovery section of the Advanced Analytics Admin Guide.

Previously, you could not conveniently access certain tabs of the Advanced Analytics Admin Operations page. Now, we've added an Additional Settings link to the Advanced Analytics settings page to quickly and conveniently access the Admin Operations page.

For more information on additional settings in Advanced Analytics, please refer to the Advanced Analytics Admin Guide.

Previously, customers could search for and view non-masked fields, whether or not data masking was enabled for their deployment.

For example, users could successfully search for a non-masked username or account name in Threat Hunter. Additionally, users could copy the URL of a masked username (such as https://<aa_IP>/uba/#user/<obfuscated_name>/...) and simply change the URL to be a valid account name (such as, https://<aa_IP>/uba/#user/<valid_account_name>/...).

Now, users can no longer search for and view non-masked fields by any means if data masking is enabled for their deployment.

For more information on data masking in Advanced Analytics, please refer to the Advanced Analytics Admin Guide.

You can now configure email and syslog notifications for certain reprocessing job status changes, including start, end, and failure.

For more information on configuring job notifications, please refer to the Restart and Reprocess section of the Advanced Analytics Admin Guide.

We have streamlined and optimized memory management in EDS by avoiding duplicates for enhanced performance in context lookup. This improves performance when performing searches, generating reports, and performing other tasks within the Data LakeAdvanced Analytics UI.

We've added a new settings page to provide better control over Exabeam Threat Intelligence Service feeds in your Data LakeAdvanced Analytics deployment. Additionally, you can now easily assign or unassign threat intelligence feeds to/from individual or multiple context tables or create new context tables directly from the page.

For more information on configuring and managing Exabeam Threat Intelligence Service, please refer to the Exabeam Threat Intelligence Service Overview section of the Advanced AnalyticsData Lake Admin Guide.

Telemetry data such as events, metrics, and environment data is collected from Data Lake and Advanced Analytics deployments and sent to Exabeam Cloud Platform to provide visibility into the overall system health, reduce system health false positives, and enable Exabeam to gain insight into common system issues, such as processing downtime (for example, processing delays and storage issues) and UI/application downtime.

The Exabeam Telemetry Service is enabled by default, following the installation of this version.

For more information, please refer to Data LakeAdvanced Analytics Admin Guide > Exabeam Cloud Telemetry Service Overview.

We have optimized the following UI aspects of Entity Analytics so that they load significantly faster:

We’ve improved the speed of numerical model calculation, with the exception of calculations involving the time of the week, which should improve the performance of Advanced Analytics. The new algorithm for numerical histogram anomaly detection not only performs much faster, but it also has better accuracy than the old algorithm.

The old algorithm was highly computing intensive, especially since it used clustering to find the abnormal area of the historical data distribution. The new algorithm uses gamma distribution to first estimate where the majority of the data points lie, and then calculates how far the new event is from the boundary of the normal area. The further the new event is from the boundary, the riskier the event is.

Old Algorithm, O(n2)	New Algorithm, O(n)

As previously mentioned, the old algorithm used hierarchical clustering, O(n2) to cluster every point into bins. It then used sorting, O(nlog(n)), to identify the normal bin boundary, b as seen in the above graph example. On the other hand, the new algorithm simply fits the historical points into gamma distribution, O(n), and then calculates the normal area boundary, b, using O(1). The resulting abnormal area is identified as a in both graph examples.

Previously, the Configure SAML link was located under the Admin Operations tile of the settings page. Now, the Configure SAML link is located under the User Management tile of the settings page.

For more information on configuring SAML, please refer to Advanced AnalyticsData Lake Admin Guide > Configuring SAML.

We've added Last 2 days to the timeframe filter for Notable Users, Notable Assets, Account Lockouts, and other Watchlists on the homepage.

You can also configure the default timeframe filter value in the application_default.conf file.

For more information on the configurations for the watchlists timeframe filters, please review theAdvanced Analytics Admin Guide.

For more information on the configurations for the watchlists timeframe filters, please refer to the Watchlists Timeframe Filter section of the Advanced Analytics Admin Guide.