- Advanced Analytics
- Understand the Basics of Advanced Analytics
- Deploy Exabeam Products
- Considerations for Installing and Deploying Exabeam Products
- Things You Need to Know About Deploying Advanced Analytics
- Pre-Check Scripts for an On-Premises or Cloud Deployment
- Install Exabeam Software
- Upgrade an Exabeam Product
- Add Ingestion (LIME) Nodes to an Existing Advanced Analytics Cluster
- Apply Pre-approved CentOS Updates
- Configure Advanced Analytics
- Set Up Admin Operations
- Set Up Authentication and Access Control
- What Are Accounts & Groups?
- What Are Assets & Networks?
- Common Access Card (CAC) Authentication and Limitations
- Role-based Access Control
- Out-of-the-Box Access Roles
- Set Up User Management
- Manage Users
- Set Up LDAP Server
- Set Up LDAP Authentication
- Single Sign-on and Multi-factor Authentication Using SAML
- Set Up Context Management
- Custom Context Tables
- How Audit Logging Works
- Starting the Analytics Engine
- Additional Configurations
- Configure Static Mappings of Hosts to/from IP Addresses
- Associate Machine Oriented Log Events to User Sessions
- Display a Custom Login Message
- Configure Threat Hunter Maximum Search Result Limit
- Change Date and Time Formats
- Set Up Machine Learning Algorithms (Beta)
- Detect Phishing
- Restart the Analytics Engine
- Custom Configuration Validation
- Advanced Analytics Transaction Log and Configuration Backup and Restore
- Reprocess Jobs
- Re-Assign to a New IP (Appliance Only)
- Hadoop Distributed File System (HDFS) Namenode Storage Redundancy
- User Engagement Analytics Policy
- Set Up Rules Administration
- Exabeam Threat Intelligence Service
- Threat Intelligence Service Prerequisites
- Connect to Threat Intelligence Service through a Proxy
- View and Manage Threat Intelligence Feeds
- Assign Threat Intelligence Feed to a New Context Table
- Create a New Context Table from a Threat Intelligence Feed
- View Threat Intelligence Service Context Tables
- Check ExaCloud Connector Service Health Status
- Exabeam Cloud Telemetry Service
- Disaster Recovery (Advanced Analytics, Case Manager, and Incident Responder)
- Enable Settings to Detect Email Sent to Personal Accounts
- Manage Security Content in Advanced Analytics
- Exabeam Hardening
- Health Status Page
- Generate Technical Support Information
- View Version Information
- Syslog Notifications Key-Value Pair Definitions
Configure Advanced Analytics
Everything administrators need to know about setting up and operating Advanced Analytics.
Set Up Admin Operations
Everything administrators need to know about setting up and operating Advanced Analytics.
Access Exabeam Advanced Analytics
Navigate, log in, and authenticate into your Advanced Analytics environment.
If you have an hardware or virtual deployment of Advanced Analytics, enter the IP address of the server and port number 8484:
https://[IP address]:8484 or https://[IP address]:8484/uba
If you have the SaaS deployment of Advanced Analytics, navigate to https://[company].aa.exabeam.com.
Use your organization credentials to log into your Advanced Analytics product.
These login credentials were established when Advanced Analytics was installed. You can authenticate into Advanced Analytics using LDAP, SAML, CAC, or SSO through Okta. To configure and enable these authentication types, contact your Technical Account Manager.
If you work for a federal agency, you can authenticate into Advanced Analytics using Common Access Card (CAC). United States government personnel use the CAC to access physical spaces, computer networks, and systems. You have readers on your workstations that read your Personal Identity Verification (PIV) and authenticate you into various network resources.
You can authenticate into Advanced Analytics using CAC combined with another authentication mechanism, like Kerberos or local authentication. To configure and and enable other authentication mechanisms, contact your Technical Account Manager.
Set Up Log Management
Large enterprise environments generally include many server, network, and security technologies that can provide useful activity logs to trace who is doing what and where. Log ingestion can be coupled with your Data Lake data repository, that can forward syslogs to Advanced Analytics. (See Data Lake Administration Guide > Syslog Forwarding to Advanced Analytics.)
Use the Log Ingestion Settings page to configure the following log sources:
Note
The Syslog destination is your site collector IP/FQDN, and only TLS connections are accepted in port TCP/515.
|
|
View Insights About Syslog Ingested Logs
Advanced Analytics has the ability to test the data pipeline of logs coming in via Syslog.
Note
This option is only available if the Enable Syslog Ingestion button is toggled on.
Click the Syslog Stats button to view the number of logs fetched, the number of events parsed, and the number of events created. A warning will also appear that lists any event types that were not created within the Syslog feed that was analyzed.
In this step you can also select Options to limit the time range and number of log events tested.
Ingest Logs from Google Cloud Pub/Sub into Advanced Analytics
To create events from Google Cloud Pub/Sub topics, configure Google Pub/Sub as an Advanced Analytics log source.
Create a Google Cloud service account with Pub/Sub Publisher and Pub/Sub Subscriber permissions.
Create and download a JSON-type service account key. You use this JSON file later.
Create a Google Cloud Pub/Sub topic with Google-managed key encryption.
For the Google Cloud Pub/Sub topic you created, create a subscription with specific settings:
Delivery type – Select Pull.
Subscription expiration – Select Never expire.
Retry policy – Select Retry immediately.
Save the subscription ID to use later.
In the navigation bar, click the menu
, select Settings, then navigate to Log Management > Log Ingestion Settings.
Click ADD, then from the Source Type list, select Google Cloud Pub/Sub.
Enter information about your Google Cloud Pub/Sub topic:
Description – Describe the topic, what kinds of logs you're ingesting, or any other information helpful for you to identify this as a log source.
Service key – Upload the Google Cloud service account key JSON file you downloaded.
Subscriptions
Subscription name – Enter the Google Cloud Pub/Sub subscription ID you created.
Description – Describe the subscription, to which Google Cloud Pub/Sub topic it was created, or what messages it receives.
To verify the connection to your Google Cloud Pub/Sub topic, click TEST CONNECTION. If you see an error, verify the information you entered then retest the connection.
Click SAVE.
Restart Log Ingestion and Messaging Engine (LIME):
In the navigation bar, click the menu
, select Settings, then navigate to Admin Operations > Exabeam Engine.
Under Exabeam Log Ingestion, click Ingest Log Feeds, then click Next.
Select Restart the engine, click Next.
Click Ingest feeds, then click Confirm.
To ingest specific logs from your Google Cloud Pub/Sub topic, configure a log feed.
Set Up Training & Scoring
To build a baseline, Advanced Analytics extensively profiles the people, asset usage, and sessions. For example, in a typical deployment, Advanced Analytics begins by examining typically 60-90 days of an organization's logs. After the initial baseline analysis is done, Advanced Analytics begins assigning scores to each session based on the amount and type of anomalies in the session.
Set Up Log Feeds
Advanced Analytics can be configured to fetch log data from a SIEM. Administrators can configure log feeds that can be queried during ingestion. Exabeam provides out-of-the-box queries for various log sources; or you can edit them and apply your own.
Once the log feed is setup, you can perform a test query that fetches a small sample of logs from the log management system. You can also parse the sample logs to make sure that Advanced Analytics is able to normalize the logs. If the system is unable to parse the logs, reach out to Customer Success and the Exabeam team will create a parser for those logs.
Draft/Published Modes for Log Feeds
There are two different modes when it comes to adding log feeds under Settings > Log Feeds. When you create a new log feed and complete the workflow you will be asked if you would like to publish the feed. Publishing the feed lets the Analytics Processing Engine know that the respected feed is ready for consumption.
If you choose to not publish the feed then it will be left in draft mode and will not be picked up by the processing engine. You can always publish a feed that is in draft mode at a later time.
This allows you to add multiple feeds and test queries without worrying about the feed being picked up by the processing engine or having the processing engine encounter errors when a draft feed is deleted.
Once a feed is in published mode it will be picked up by the processing engine at the top of the hour.
Get Notified about System Activity
Configure Advanced Analytics to send notifications to your log repository or email about system health, notable sessions, anomalies, and other important system information.
Depending on the format in which you want information about your system, send notifications to your log repository or email.
Advanced Analytics sends notifications to your log repository in a structured data format using Syslog. These notifications are formatted so machines, like your log repository, can easily understand them.
Advanced Analytics sends notifications to your email in a format that's easier to read for humans.
Send Notifications to your Log Repository, Log Ticketing System, or SIEM
Send notifications to your log repository, log ticketing system, or SIEM using the Syslog protocol.
Click the menu
, select Settings, then navigate to Log Management > Incident Notification .
Click add
, then select Syslog Notification.
Configure your notification settings:
IP / Hostname – Enter the IP or host name of your Syslog server.
Port – Enter the port your Syslog server uses.
Protocol – Select the network protocol your Syslog server uses to send messages: TCP, SSL_TCP, or UDP.
Syslog Security Level – Assign a severity level to the notification:
Informational – Normal operational events, no action needed.
Debug – Useful information for debugging, sent after an error occurs.
Error – An error has occurred and must be resolved.
Warning – Events that will lead to an error if you don't take action.
Emergency – Your system is unavailable and unusable.
Alert – Events that should be corrected immediately.
Notice – An unusual event has occured.
Critical – Some event, like a hard device error, has occurred and your system is in critical condition.
Notifications by Product – Select the events for which you want to be notified:
System Health – All system health alerts for Advanced Analytics.
Notable Sessions – A user or asset has reached a risk threshold and become notable. This notification describes which rule was triggered and contains any relevant event details, which are unique to each event type. If an event detail isn't available, it isn't included in the notification.
Anomalies – A rule has been triggered.
AA/CM/OAR Audit – An Exabeam user does something in Advanced Analytics, Case Manager, or Incident Responder that's important to know when auditing their activity history; for example, when someone modifies rule behaviour, changes log sources, or changes user roles and permissions.
Job Start – Data processing engines, like Log Ingestion and Messaging Engine (LIME) or the Analytics Engine, have started processing a log.
Job End – Data processing engines, like LIME or the Analytics Engine, have stopped processing a log.
Job Failure – Data processing engines, like LIME or the Analytics Engine, have failed to process a log.
Click ADD NOTIFICATION.
Restart the Analytics Engine.
Send Notifications to Your Email
To get human-friendly notifications, configure email notifications.
Some Incident Responder actions also send email notifications, including:
Notify User By Email Phishing
Phishing Summary Report
Send Email
Send Template Email
Send Indicators via Email
If you configure these settings correctly, Incident Responder uses IRNotificationSMTPService as the service for these actions. If you configure these settings incorrectly, these actions won't work correctly.
Click the menu
, select Settings, then navigate to Log Management > Incident Notification .
Click add
, then select Email Notification.
Configure your notification settings:
IP / Hostname – Enter the IP or hostname of your outgoing mail server. If you have a SaaS environment, enter cloudrelay1.connect.exabeam.com.
Port – Enter the port number for your outgoing mail server. If you have a SaaS environment, enter 587.
SSL – Select if your mail server uses Secure Sockets Layer (SSL) protocol. If you have a SaaS environment, select this box.
Username Required – If your mail server requires a username, select the box, then enter the username.
Password Required – If your mail server requires a password, select the box, then enter the password.
Sender Email Address – Enter the email address the email is sent from. If you have a SaaS environment, enter <yourinstance>@ notify.exabeam.com.
Recipients – List the email addresses to receive these email notifications, separated by a comma.
E-mail Signature – Enter text that's automatically added to the end of all email notifications.
Notifications by Product – Select the events for which you want to be notified.
Incident Responder:
System Health – All system health alerts for Case Manager and Incident Responder.
Advanced Analytics:
System Health – All system health alerts for Advanced Analytics.
Notable Sessions – A user or asset has reached a risk threshold and become notable. This notification describes which rule was triggered and contains any relevant event details, which are unique to each event type. If an event detail isn't available, it isn't included in the notification.
Anomalies – A rule has been triggered.
AA/CM/OAR Audit – An Exabeam user does something in Advanced Analytics, Case Manager, or Incident Responder that's important to know when auditing their activity history; for example, when someone modifies rule behaviour, changes log sources, or changes user roles and permissions.
Job Start – Data processing engines, like Log Ingestion and Messaging Engine (LIME) or the Analytics Engine, have started processing a log.
Job End – Data processing engines, like LIME or the Analytics Engine, have stopped processing a log.
Job Failure – Data processing engines, like LIME or the Analytics Engine, have failed to process a log.
Click ADD NOTIFICATION.
Advanced Analytics Transaction Log and Configuration Backup and Restore
Hardware and Virtual Deployments Only
Rebuilding a failed worker node host (from a failed disk for on on-premise appliance) or shifting a worker node host to new resources (such as in AWS) takes significant planning. One of the more complex steps and most prone to error is migrating the configurations. Exabeam has provide a backup mechanism for layered data format (LDF) transaction log and configuration files to minimize the risk of error. To use the configuration backup and restore feature, you must have:
Amazon Web Services S3 storage or an active Advanced Analytics worker node
Cluster with two or more worker nodes
Have read and write permission for the credentials you will configure to access the base path at the storage destination
A scheduled task in Advanced Analytics to run backup to the storage destination
Note
To rebuild after a cluster failure, it is recommended that a cloud-based backups be used. To rebuild nodes from disk failures, backup files to a worker node or cloud-based destination.
Warning
Master nodes cannot be backed up and restored. Only worker nodes.
If you want to save the generate backup files to your first worker node, then no further configuration is needed to configure an external storage destination. A worker node destination addresses possible disk failure at the master node appliance. This is not recommended as the sole method for disaster recovery.
If you are storing your configurations at an AWS S3 location, you will need to define the target location before scheduling a backup.
Go to Settings > Additional Settings > Admin Operations > External Storage.
Click Add to register an AWS backup destination.
Fill all field and then click TEST CONNECTION to verify connection credentials.
Once a working connection is confirmed Successful, click SAVE.
Once you have a verified destination to store your files, configure and schedule a recurring backup.
Go to Settings > Additional Settings > Backup & Restore > Backups.
Click CREATE BACKUP to generate a new schedule record. If you are changing the destination, click the edit icon
on the displayed record.
Fill all fields and then click SAVE to apply the configuration.
Warning
Time is given in UTC.
A successful backup will place a backup.exa
file at either the base path of the AWS destination or /opt/exabeam/data/backup
at the worker node. In the case that the scheduled backup fails to write files to the destination, confirm there is enough space at the destination to hold the files and that the exabeam-web-common
service is running. (If exabeam-web-common
is not running, review its application.log
for hints as to the possible cause.)
In order to restore a node host using files store off-node, you must have:
administrator privileges to run tasks a the host
SSH access to the host
free space at the restoration partition at the master node host that is greater than 10 times the size of
backup.exa
backup file
Copy the backup file,
backup.exa
, from the backup location to the restoration partition. This should be a temporary work directory (<restore_path>
) at the master node.Run the following to unpack the EXA file and repopulate files.
sudo /opt/exabeam/bin/tools/exa-restore <restore_path>/backup.exa
exa-restore
will stop all services, restore files, and then start all services. Monitor the console output for error messages. See Troubleshooting a Restoration ifexa-restore
is unable to run to completion.Remove
backup.exa
and the temporary work directory when restoration is completed.
If restoration does not succeed, the try following below solutions. If the scenarios listed do not match your situation,
Not Enough Disk Space
Select a different partition to restore the configuration files to and try to restore again. Otherwise, review files stored in to target destination and offload files to create more space.
Restore Script Cannot Stop All Services
Use the following to manually stop all services:
source /opt/exabeam/bin/shell-environment.bash && everything-stop
Restore Script Cannot Start All Services
Use the following to manually start all services:
source /opt/exabeam/bin/shell-environment.bash && everything-start
Restore Script Could Not Restore a Particular File
Use tar
to manually restore the file:
# Determine the task ID and base directory (<base_dir>) for the file restoration that failed. # Go to the <base_id>/<task_id> directory and apply following command: sudo tar -xzpvf backup.tar backup.tgz -C <baseDir> # Manually start all services. source /opt/exabeam/bin/shell-environment.bash && everything-start
Exabeam Licenses
All Exabeam products require a license in order to function. These licenses determine which Exabeam products and features you can use. You are not limited by the amount of external data you can ingest and process.
There are multiple types of Exabeam product licenses available, which you can add to your Exabeam instance. Exabeam bundles these licenses together and issues you one key to activate all purchased products. For more information on the different product licenses, please see Types of Exabeam Product Licenses.
License Lifecycle
When you first install Exabeam, the installed instance uses a 30 day grace period license. This license allows you to try out all of the features in Exabeam for 30 days.
Grace Period
Exabeam provides a 30-day grace period for expired licenses before products stop processing data. During the grace period, you will not experience any change in product functionality. There is no limit to the amount of data you can ingest and process.
When the license or grace period is 14 days away from expiring, you will receive a warning alert on the home page and an email.
You can request a new license by contacting your Exabeam account representative or by opening a support ticket.
Expiration Period
When your grace period has ended, you will start to experience limited product functionality. Please contact your Exabeam representative for a valid license and restore all product features.
For Advanced Analytics license expirations, the Log Ingestion Engine will continue to ingest data, but the Analytics Engine will stop processing. Threat Hunter and telemetry will also stop working.
You will receive a critical alert on the home page and an email.
License Alerts
License alerts are sent via an alert on the home page and in email when the license or grace period is 14 days away from expiring and when the grace period expires.
Note
The email alert is sent to the address linked in the notifications setting page at Settings > Additional Settings > Notifications > Setup Notifications.
The home page alert is permanent until resolved. You must purchase a product license or renew your existing license to continue using Exabeam.
![]() |
You can also check the status and details of your license any time by visiting Settings > ADMIN OPERATIONS > Licenses or System Health > Health Alerts.
License Versions
Currently, Exabeam has three versions of our product licenses (V1, V2, and V3). License versions are not backward compatible. If you are upgrading from Advanced Analytics I41 / or earlier you must apply the V3 license version. The table below summarizes how the different license versions are designed to work:
V1 | V2 | V3 | |
---|---|---|---|
Products Supported |
|
|
|
Product Version | Advanced Analytics I38 and below | Advanced Analytics I41 | Advanced Analytics I46 and above Data Lake I24 and above |
Uses unique customer ID | No | No | Yes |
Federal License Mode | No | No | Yes |
Available to customers through the Exabeam Community | No | No | Yes |
Licensed enforced in Advanced Analytics | Yes | Yes | Yes |
Licensed enforced in Data Lake | NA | NA | No |
Applied through the UI | No, the license must be placed in a path in Tequila | No, the license must be placed in a path in Tequila | Yes |
Note
Licenses for Advanced Analytics I46 / and later must be installed via the GUI on the license management page.
Types of Exabeam Product Licenses
Exabeam licenses specify which products you have access to and for how long. We bundle your product licenses together into one license file. Therefore, all products that fall under your Exabeam platform share the same expiration dates.
Advanced Analytics product licenses:
User Analytics – This is the core product of Advanced Analytics . Exabeam’s user behavioral analytics security solution provides modern threat detection using behavioral modeling and machine learning.
Threat Hunter – Threat Hunter is a point and click advanced search function which allows for searches across a variety of dimensions, such as Activity Types, User Names, and Reasons. It comes fully integrated with User Analytics.
Exabeam Threat Intelligence Services (TIS) – TIS provides real-time actionable intelligence into potential threats to your environment by uncovering indicators of compromise (IOC). It comes fully integrated with the purchase of an Advanced Analytics V3 license. TIS also allows access to telemetry.
Entity Analytics (EA) – Entity Analytics offers analytics capabilities for internet-connected devices and entities beyond users such as hosts and IP addresses within an environment.
Entity Analytics is available as an add-on option. If you are adding Entity Analytics to your existing Advanced Analytics platform, you will be sent a new license key. Note that you may require additional nodes to process asset oriented log sources.
Incident Responder – Also known as Orchestration Automation Response. Incident Responder adds automation to your SOC to make your cyber security incident response team more productive.
Incident Responder is available as an add-on option. If you are adding Incident Responder to your existing Advanced Analytics platform, you will be sent a new license key. Note that you may require additional nodes to support automated incident responses.
Case Manager – Case Manager can fully integrate into Advanced Analytics enabling you to optimize analyst workflow by managing the life cycle of your incidents.
Case Manager is available as an add-on option. If you are adding Case Manager to your existing Advanced Analytics platform, you will be sent a new license key. Note that you may require additional nodes to support this module extension.
After you have purchased or renewed your product licenses, proceed to Download a License.
Download an On-premises or Cloud Exabeam License
You can download your unique customer license file from the Exabeam Community.
To download your Exabeam license file:
Log into the Exabeam Community with your credentials.
Click on your username.
Click on My Account.
Click on the text file under the License File section to start the download
After you have downloaded your Exabeam license, proceed to Apply a License.
Exabeam Cluster Authentication Token
Hardware and Virtual Deployments Only
The cluster authentication token is used to verify identities between clusters that have been deployed in phases as well as HTTP-based log collectors. Each peer cluster in a query pool must have its own token. You can set expiration dates during token creation or manually revoke tokens at any time.
To generate a token:
Navigate to Settings > Admin Operations > Cluster Authentication Token.
At the Cluster Authentication Token menu:
To configure a new token, click
.
Or to edit an existing configuration, click
.
In the Setup Token menu, fill in the Token Name, Expiry Date, and select the Permission Level(s).
Note
Token names may contain letters, numbers, and spaces only.
Click ADD TOKEN or SAVE to apply the configuration.
Use this generated file to allow your API(s) to authenticated by token. Ensure that your API uses ExaAuthToken
in its requests. For curl clients, the request structure resembles:
curl -H "ExaAuthToken:<generated_token>" https://<external_host>:<api_port>/<api_request_path>
Set Up Authentication and Access Control
What Are Accounts & Groups?
Peer Groups
Peer groups can be a team, department, division, geographic location, etc. and are defined by the organization. Exabeam uses this information to compare a user's behavior to that of their peers. For example, when a user logs into an application for the first time Exabeam can evaluate if it is normal for a member of their peer group to access that application. When Dynamic Peer Grouping is enabled, Exabeam will use machine learning to choose the best possible peer groups for a user for different activities based on the behaviors they exhibit.
Executives
Exabeam watches executive movements very closely because they are privileged and have access to sensitive and confidential information, making their credentials highly desirable for account takeover. Identifying executives allows the system to model executive assets, thereby prioritizing anomalous behaviors associated with them. For example, we will place a higher score for an anomaly triggered by a non-executive user accessing an executive workstation.
Service Accounts
A service account is a user account that belongs to an application rather than an end user and runs a particular piece of software. During the setup process, we work with an organization to identify patterns in service account labels and uses this information to classify accounts as service accounts based on their behavior. Exabeam also adds or removes points from sessions based on service account activity. For example, if a service account logs into an application interactively, we will add points to the session because service accounts should not typically log in to applications.
What Are Assets & Networks?
Workstations & Servers
Assets are computer devices such as servers, workstations, and printers. During the setup process, we will ask you to review and confirm asset labels. It is important for Exabeam to understand the asset types within the organization - are they Domain Controllers, Exchange Servers, Database Servers or workstations? This adds further context to what Exabeam sees within the logs. For example, if a user performs interactive logons to an Exchange Server on a daily basis, the user is likely an Exchange Administrator. Exabeam automatically pulls in assets from the LDAP server and categorizes them as servers or workstations based on the OS property or the Organizational Units they belong to. In this step, we ask you to review whether the assets tagged by Exabeam are accurate. In addition to configuration of assets during setup, Exabeam also runs an ongoing classifier that classifies assets as workstations or servers based on their behavior.
Network Zones
Network zones are internal network locations defined by the organization rather than a physical place. Zones can be cities, business units, buildings, or even specific rooms. For example, "Atlanta" can refer to a network zone within an organization rather than the city itself (all according to an organization's preference). Administrators can upload information regarding network zones for their internal assets via CSV or add manually one at a time.
Asset Groups
Asset Groups are a collection of assets that perform the same function in the organization and need to be treated as a single entity from an anomaly detection perspective. An example of an asset group would be a collection of Exchange Servers. Grouping them this way is useful to our modeling processing because it allows us to treat an asset group as a single entity, reducing the amount of false positives that are generated when users connect to multiple servers within that group. As a concrete example, if a user regularly connects to email exchange server #1 then Exabeam builds a baseline that says this is their normal behavior. But exchange servers are often load-balanced, and if the user then connects to email exchange server #2 we can say that this is still normal behavior for them because the exchange servers are one Asset Group. Other examples of asset groups are SharePoint farms, or Virtual Desktop Infrastructure (VDI).
Common Access Card (CAC) Authentication and Limitations
Exabeam supports Common Access Card (CAC) authentication. CAC is the principal card used to enable physical spaces, and provides access to computer networks and systems. Analysts have CAC readers on their workstations that read their Personal Identity Verification (PIV) and authenticates them to use various network resources.
Exabeam allows CAC authentication in combination with other authentication mechanisms (Kerberos, Local authentication, etc.).
Please note the following restrictions:
Configure CAC users that are authorized to access Exabeam from the Exabeam User Management page.
During the user provisioning, the CAC analysts must be assigned roles. The roles associated with a CAC user will be used for authorization when they login.
Figure 1. Add User menu
Configure a CAC User
Generate Certificate and add to the cluster by running the shell script below. Fill in the fields pertinent to your organization.
#!/bin/bash # Main variables Country="[country]" CommonName="[cac_username_hostname]" State="[state]" Locality="[locality]" Organization="[organization]" OrganizationalUnit="[organizational_unit]" EmailAddress="[email_address]" # C = Country Name (2 letter code) # ST = State or Province Name (full name) # L = Locality Name (eg, city) # O = Organization Name (eg, company) # OU = Organizational Unit Name (eg, section) # CN = Common Name (eg, your name or your server's hostname) # emailAddress = Email Address SubjString="/C=$Country/CN=$CommonName/emailAddress=$EmailAddress/ST=$State/L=$Locality/O=$Organization/OU=$OrganizationalUnit" # Run the following commands on Exabeam server to create Client Certificate openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -aes-128-cbc -out ca.key -pass pass:test openssl req -new -x509 -days 365 -sha256 -key ca.key -out ca.pem -subj "$SubjString" -passin pass:test # Create client cert that will be signed by CA cCountry="[country]" cCommonName="[cac_username]" cState="[state]" cLocality="[locality]" cOrganization="[organization]" cOrganizationalUnit="[organization_unit]" cEmailAddress="[email]" cSubjString="/C=$cCountry/CN=$cCommonName/emailAddress=$cEmailAddress/ST=$cState/L=$cLocality/O=$cOrganization/OU=$cOrganizationalUnit"openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out client.keyopenssl req -new -key client.key -sha256 -out client.csr -subj "$cSubjString"openssl x509 -req -days 365 -in client.csr -CA ca.pem -CAkey ca.key -set_serial 0x`openssl rand 16 -hex` -sha256 -out client.pem -passin pass:testopenssl pkcs12 -export -in client.pem -inkey client.key -name "Sub-domain certificate for some name" -out client.p12 -passout pass:test
Upload the generated
ca.pem
file to the CAC user home directory at the master node.Execute the following commands at the master node:
source /opt/exabeam/bin/shell-environment.bash docker cp ca.pem exabeam-web-common:/ docker exec exabeam-web-common keytool -import -trustcacerts -alias cacbundle -file ca.pem -keystore /opt/exabeam/web-common/config/custom/truststore.jks -storepass changeit -noprompt
To associate the credentials to a login, create a CAC user by navigating to Settings > User Management > Users > Add User and select CAC in User type.
Configuration of Client Certificates
Located in /opt/exabeam/config/common/web/custom/application.conf
the sslClientAuth
flag must be set to true. Example below.
tequila { service { interface = "0.0.0.0" #hostname = "<hostname>" port = 8484 https = true sslKeystore = "$EXABEAM_HOME/config/custom/keystore.jks" sslKeypass = "password" # The following property enables Two-Way Client SSL Authentication sslClientAuth = true
To install client certificates for CAC, add the client certificate bundle to the trust store on the master host. Example below (replace the name of the file with the bundle you are installing):
# For Exabeam Data Lake sudo docker exec exabeam-web-common-host1 /bin/bash -c "cd /opt/exabeam/config/custom; keytool -import -trustcacerts -alias cacbundle -file ca.pem -keystore truststore.jks -storepass changeit -noprompt" # For Exabeam Advanced Analytics sudo docker exec exabeam-web-common /bin/bash -c "cd /opt/exabeam/config/custom; keytool -import -trustcacerts -alias cacbundle -file ca.pem -keystore truststore.jks -storepass changeit -noprompt
To verify the contents of the trust store on the master host, run the following:
# For Exabeam Data Lake sudo docker exec exabeam-web-common-host1 /bin/bash -c "keytool -list -v -keystore /opt/exabeam/config/custom/truststore.jks -storepass changeit" # For Exabeam Advanced Analytics sudo docker exec exabeam-web-common /bin/bash -c "keytool -list -v -keystore /opt/exabeam/config/custom/truststore.jks -storepass changeit"
After configuration changes, restart web-common
.
source /opt/exabeam/bin/shell-environment.bash; web-common-restart
Role-based Access Control
Customers are able to control the responsibilities and activities of their SOC team members with Role-based Access Control (RBAC). Local users, LDAP users or SAML authenticated users will be assigned roles within Exabeam.
Each user can be assigned one or more roles and the responsibilities of those roles are determined by the permissions their role allows. If users are assigned more than one role, that user receives the permissions of both roles.
Note
If a user is assigned multiple roles with conflicting permissions, Exabeam enforces the role having more permission. For example, if a role with lighter permission and a role with full permission are both assigned to a user, then the user will have full permission.
To access the Roles page, navigate to Settings > User Management > Roles.
Out-of-the-Box Access Roles
Exabeam provides pre-configured access roles that restrict a user's tasks, actions, and views. A user may have more than one role. When a task, action, or view has more than one role associated to a user, the role with the greater access is applied.
Administrator: This role is intended for administrative access to Exabeam. Users assigned to this role can perform administrative operations on Exabeam, such as configuring the appliance to fetch logs from the SIEM and connecting to Active Directory to pull in contextual information. The default admin credential belongs to this role. This is a predefined role provided by Exabeam and cannot be deleted.
Auditor: Users assigned to this role have only view privileges within the Exabeam UI. They can view all activities within the Exabeam UI, but cannot make any changes. This is a predefined role provided by Exabeam.
Default permissions include:
Permission | Description |
---|---|
View Comments | View comments |
View Activities | View all notable users, assets, sessions, and related risk reasons in the organization. |
View Global Insights | View the organizational models built by Exabeam. The histograms that show the normal behavior for all entities in the organization can be viewed. |
View Executive Info | View the risk reasons and the timeline of the executive users in the organization. You will be able to see the activities performed by executive users along with the associated anomalies. |
View Incidents | View incidents. |
View Infographics | View all the infographics built by Exabeam. You will be able to see the overall trends for the organization. |
View Insights | View the normal behaviors for specific entities within the organization. The histograms for specific users and assets can be viewed. |
Search Incidents | Can search keywords in Incident Responder via the search bar. |
Basic Search | Perform basic search on the Exabeam homepage. Basic search allows you to search for a specific user, asset, session, or a security alert. |
View Search Library | View the Search Library provided by Exabeam and the corresponding search results associated with the filters. |
Threat Hunting | Perform threat hunting on Exabeam. Threat hunting allows you to query the platform across a variety of dimension such as find all users whose sessions contain data exfiltration activities or a malware on their asset. |
Tier 1 Analyst: Users assigned to this role are junior security analysts or incident desk responders who supports the day-to-day enterprise security operation and monitoring. This type of role will not be authorized to make any changes to Exabeam system except for making user, session and lockout comments. Users in this role cannot approve sessions or lockout activities. This is a predefined role provided by Exabeam.
Default permissions include:
Permission | Description |
---|---|
View Executive Info | View the risk reasons and the timeline of the executive users in the organization. You will be able to see the activities performed by executive users along with the associated anomalies. |
View Activities | View all notable users, assets, sessions and related risk reasons in the organization. |
View Infographics | View all the infographics built by Exabeam. You will be able to see the overall trends for the organization. |
View Global Insights | View the organizational models built by Exabeam. The histograms that show the normal behavior for all entities in the organization can be viewed. |
View Insights | View the normal behaviors for specific entities within the organization. The histograms for specific users and assets can be viewed. |
Add AA Comments | Add comments for the various entities (users, assets and sessions) within Exabeam. |
Sending Incidents to Incident Responder | Send incidents to Incident Responder. |
Basic Search | Perform basic search on the Exabeam homepage. Basic search allows you to search for a specific user, asset, session, or a security alert. |
Tier 3 Analyst: Users assigned to this role will be performing more complex investigations and remediation plans. They can review user sessions, account lockouts, add comments, approve activities and perform threat hunting. This is a predefined role provided by Exabeam and cannot be deleted.
Default permissions include:
Permission | Description |
---|---|
View Activities | View all notable users, assets, sessions and related risk reasons in the organization. |
View Executive Info | View the risk reasons and the timeline of the executive users in the organization. You will be able to see the activities performed by executive users along with the associated anomalies. |
View Global Insights | View the organizational models built by Exabeam. The histograms that show the normal behavior for all entities in the organization can be viewed. |
View Infographics | View all the infographics built by Exabeam. You will be able to see the overall trends for the organization. |
View Rules | View configured rules that determine how security events are handled. |
View Insights | View the normal behaviors for specific entities within the organization. The histograms for specific users and assets can be viewed. |
Approve Lockouts | Accept account lockout activities for users. Accepting lockouts indicates to Exabeam that the specific set of behaviors for that lockout activity sequence are whitelisted and are deemed normal for that user. |
Accept Sessions | Accept sessions for users. Accepting sessions indicates to Exabeam that the specific set of behaviors for that session are whitelisted and are deemed normal for that user. |
Add AA Comments | Add comments for the various entities (users, assets and sessions) within Exabeam. |
Manage Rules | Create/Edit/Reload rules that determine how security events are handled. |
Manage Watchlist | Add or remove users from the Watchlist. Users that have been added to the Watchlist are always listed on the Exabeam homepage, allowing them to be scrutinized closely. |
Sending incidents to Incident Responder | Send incidents to Incident Responder. |
Manage Search Library | Create saved searches as well as edit them. |
Basic Search | Perform basic search on the Exabeam homepage. Basic search allows you to search for a specific user, asset, session, or a security alert. |
View Search Library | View the Search Library provided by Exabeam and the corresponding search results associated with the filters. |
Threat Hunting | Perform threat hunting on Exabeam. Threat hunting allows you to query the platform across a variety of dimensions such as find all users whose sessions contain data exfiltration activities or a malware on their asset. |
Data Privacy Officer: This role is needed only when the data masking feature is turned on within Exabeam. Users assigned to this role are the only users that can view personally identifiable information (PII) in an unmasked form. They can review user sessions, account lockouts, add comments, approve activities and perform threat hunting. This is a predefined role provided by Exabeam.
See the section in this document titled Mask Data Within the Advanced Analytics UI on the next page for more information on this feature.
Default permissions include:
Permission | Description |
---|---|
View Activities | View all notable users, assets, sessions and related risk reasons in the organization. |
View Executive Info | View the risk reasons and the timeline of the executive users in the organization. You will be able to see the activities performed by executive users along with the associated anomalies. |
View Global Insights | View the organizational models built by Exabeam. The histograms that show the normal behavior for all entities in the organization can be viewed. |
View Infographics | View all the infographics built by Exabeam. You will be able to see the overall trends for the organization. |
View Insights | View the normal behaviors for specific entities within the organization. The histograms for specific users and assets can be viewed. |
Basic Search | Perform basic search on the Exabeam homepage. Basic search allows you to search for a specific user, asset, session, or a security alert. |
View Search Library | View the Search Library provided by Exabeam and the corresponding search results associated with the filters. |
Threat Hunting | Perform threat hunting on Exabeam. Threat hunting allows you to query the platform across a variety of dimensions such as find all users whose sessions contain data exfiltration activities or a malware on their asset. |
Mask Data Within the Advanced Analytics UI
Note
To enable/disable and configure data masking, please contact your Exabeam technical representative.
Note
Data masking is not supported in Case Management or Incident Responder modules.
Data masking within the UI ensures that personal data cannot be read, copied, modified, or removed without authorization during processing or use. With data masking enabled, the only user able to see a user's personal information will be users assigned to the permission "View Clear Text Data". The default role "Data Privacy Officer" is assigned this permission out of the box. Data masking is a configurable setting and is turned off by default.
To enable data masking in the UI, the dataMaskingEnabled
field needs to be set to true
. This is located in /opt/exabeam/config/tequila/custom/application.config
.
PII { # Globally enable/disable data masking on all the PII configured fields. Default value is false. dataMaskingEnabled = true }
You're able to fully customize which PII data is masked or shown in your deployment. The following fields are available when configuring PII data masking:
Default – This is the standard list of PII values controlled by Exabeam. If data masking is enabled, all of these fields are encrypted.
Custom – Encrypt additional fields beyond the default list by adding them to this custom list. The default is empty.
Excluded – Do not encrypt these fields. Adds that are in the default list to expose their values in your deployment. The default is empty.
For example, if you want to mask all default fields other than "task name
" and also want to mask the "address
" field, then you would configure the lists as shown below:
PII { # Globally enable/disable data masking on all the PII configured fields. Default value is false. dataMaskingEnabled = true dataMaskingSuffix = ":M" encryptedFields = { #encrypt fields event { default = [ #EventFieldName "user", "account", ... "task_name" ] custom=["address"] excluded=["task_name"] } ... } }
Mask Data for Notifications
You can configure Advanced Analytics to mask specific fields when sending notable sessions and/or anomalous rules via email, Splunk, and QRadar. This prevents exposure of sensitive data when viewing alerts sent to external destinations.
Note
Advanced Analytics activity log data is not masked or obfuscated when sent via Syslog. It is your responsibility to upload the data to a dedicated index which is available only to users with appropriate privileges.
Before proceeding through the steps below, ensure your deployment has:
Enabled data masking (instructions below)
Configured a destination for Notable Sessions notifications sent from Advanced Analytics via Incident Notifications
By default, all fields in a notification are unmasked. To enable data masking for notifications, the Enabled
field needs to be set to true
. This is located in the application.conf
file in the path /opt/exabeam/config/tequila/custom
.
NotificationRouter { ... Masking { Enabled = true Types = [...] NotableSessionFields = [...] AnomaliesRulesFields = [...] } }
Use the Types
field to add the notification destinations (Syslog, Email, QRadar, and/or Splunk). Then, use the NotableSessionFields
and AnomaliesRulesFields
to mask specific fields included in a notification.
For example, if you want to mask the user, source host and IP, and destination host and IP for notifications sent via syslog and Splunk, then you would configure the lists as shown below:
NotificationRouter { ... Masking { Enabled = true Types = [Syslog, Splunk] NotableSessionFields = ["user", "src_host", "src_ip", "dest_host", "dest_ip"] } }
Set Up User Management
Users are the analysts that have access to the Exabeam UI to review and investigate activity. These analysts also have the ability to accept sessions. Exabeam supports local authentication or authentication against an LDAP server.
Roles
Exabeam supports role-based access control. Under Default Roles are the roles that Exabeam has created; these cannot be deleted or modified. Selecting a role displays the permissions associated with that role.
Users can also create custom roles by selecting Create a New Role. In this dialogue box you will be asked to name the role and select the permissions associated with it.
Add an Exabeam Role
Exabeam's default roles include Administrator, Auditor, and Tier (1 and 3) Analyst. If you do not want to use these default roles or edit their permissions, create ones that best suit your organization.
To add a new role:
Navigate to Settings > Exabeam User Management > Roles.
Click Create Role.
Fill the Create a new role fields and click SAVE. The search box allows you to search for specific permissions.
Your newly created role should appear in the Roles UI under Custom Roles and can be assigned to any analyst.
To start assigning users to the role, select the role and click Next, which will direct you to the Users UI to edit user settings. Edit the configuration for the users you wish to add the role to and click Next to apply the changes.
Supported Permissions
Administration
All Admin Ops: Perform all Exabeam administrative operations such as configuring the appliance, connecting to the log repository and Active Directory, setting up log feeds, managing users and roles that access the Exabeam UI, and performing system health checks.
Manage Users and Context Sources: Manage users and roles in the Exabeam Security Intelligence Platform, as well as the context sources used to enhanced the logs ingested (e.g. assets, peer groups, service accounts, executives)
Manage context tables: Manage users, assets or other objects within Context Tables.
Comments
Add Advanced Analytics Comments: Add comments for the various entities (users, assets and sessions) within Exabeam.
Add Incident Responder Comments
Create
Create incidents
Upload Custom Services: Upload custom actions or services.
Delete
Delete incidents
Manage
Manage Bi-directional Communication: Configure inbound and outbound settings for Bi-Directional Communications.
Manage Data Ingest: Configure log sources and feeds and email-based ingest.
Manage Playbooks: Create, update, or delete playbooks.
Manage Services: Configure, edit, or delete services (3rd party integrations).
Manage Triggers: Create, update, or delete playbook triggers.
Run Playbooks: Run a playbook manually from the workbench.
Manage Checklist Definitions: Configure checklist definitions.
Manage ingest rules: Add, edit, or delete rules for how incidents are assigned, restricted, and prioritized on ingest.
Manage Queues: Create, edit, delete, and assign membership to queues
Manage Templates: Create, edit, or delete playbook templates.
Run Actions: Launch individual actions from the user interface.
View
Manage Incident Configs: Manage Incident Incident Responder Configs
View API
View Executive Info: View the risk reasons and the timeline of the executive users in the organization. You will be able to see the activities performed by executive users along with the associated anomalies.
View health
View Raw Logs: View the raw logs that are used to built the events on AA timeline.
View Infographics: View all the infographics built by Exabeam. You will be able to see the overall trends for the organization.
View Metrics: View the Incident Responder Metrics page.
View Activities: View all notable users, assets, sessions and related risk reasons in the organization.
View comments
View Global Insights: View the organizational models built by Exabeam. The histograms that show the normal behavior for all entities in the organization can be viewed.
View incidents
View Insights: View the normal behaviors for specific entities within the organization. The histograms for specific users and assets can be viewed.
View Rules: View configured rules that determine how security events are handled
Edit & Approve
Approve Lockouts: Accept account lockout activities for users. Accepting lockouts indicates to Exabeam that the specific set of behaviors for that lockout activity sequence are whitelisted and are deemed normal for that user.
Bulk Edit: Users can edit multiple incidents at the same time.
Edit incidents: Edit an incident's fields, edit entities & artifacts.
Manage Watchlist: Add or remove users from the Watchlist. Users that have been added to the Watchlist are always listed on the Exabeam homepage, allowing them to be scrutinized closely.
Accept Sessions: Accept sessions for users. Accepting sessions indicates to Exabeam that the specific set of behaviors for that session are whitelisted and are deemed normal for that user.
Delete entities and artifacts: Users can delete entities and artifacts.
Manage Rules: Create/Edit/Reload rules that determine how security events are handled
Sending incidents to Incident Responder
Search
Manage Search Library: Create saved searches as well as edit them.
Basic Search: Perform basic search on the Exabeam homepage. Basic search allows you to search for a specific user, asset, session, or a security alert.
Threat Hunting: Perform thread hunting on Exabeam. Query the platform across a variety of dimensions such as find all users whose sessions contain data exfiltration activities or a malware on their asset.
Manage Threat Hunting Public searches: Create, update, delete saved public searches
Search Incidents: Can search keywords in Incident Responder via the search bar.
View Search Library: View the Search Library provided by Exabeam and the corresponding search results associated with the filters.
Data Privacy
View Unmasked Data (PII): Show all personally identifiable information (PII) in a clear text form. When data masking is enabled within Exabeam, this permission should be enabled only for select users that need to see PII in a clear text form.
Manage Users
Understand the difference between Roles and Users. Configure the analysts that have access to the Exabeam User Interface, add the analyst's information, assign them roles, and set up user permissions and access based on your organization's needs.
Users
Users are the analysts that have access to the Exabeam UI to review and investigate activity. These analysts have specific roles, permissions, and can be assigned Exabeam objects within the platform. They also have the ability to accept sessions. Exabeam supports local authentication or authentication against an LDAP server.
Add an Exabeam User
Navigate to Settings > Exabeam User Management > Users.
Click Add User.
Fill the new user fields and select role(s), and then click SAVE.
Your newly created user should appear in the Users UI.
Exabeam User Password Policy
Exabeam users must adhere to security requirements for forming passwords. The Exabeam Security Management Platform (SMP) adheres to the following for user passwords:
Passwords must:
Be between 8 to 32 characters
Contain at least one uppercase, lowercase, numeric, and special character
Contain no blank space
User must change password every 90 days
New passwords cannot match last 5 passwords
SHA256 hashing is applied to store passwords
Only administrator user can rest passwords and unblock users who have been locked out due to too many consecutive failed logins
The management policies that are adjustable:
Strong password policy can be changed by editing the
webcommon
block in/opt/exabeam/config/common/web/custom/application.conf
.webcommon { ... auth { defaultAdmin { username = "admin" password = "changeme" } ... passwordConstraints { minLength = 8 maxLength = 32 lowerCaseCount = 1 upperCaseCount = 1 numericCount = 1 specialCharCount = 1 spacesAllowed = false passwordHistoryCount = 5 # 0 to disable password history checking } failedLoginLockout = 0 # 0 to disable loginLockout passwordExpirationDays = 90 # 0 to disable password expiration passwordHashing = "sha256" # accept either sha256 or bcrypt as options } ... }
Default idle session timeout is 4 hours. Edit the
silhouette.authenticator.cookieIdleTimeout
value (in seconds) in/opt/exabeam/config/common/web/custom/application.conf
.silhouette.authenticator.cookieIdleTimeout = 14400
Set Up LDAP Server
If you are adding an LDAP server for the first time, then the Add LDAP Server page displays when you reach the Import LDAP page. Otherwise, if you have already added an existing LDAP server, click Add LDAP Server to add more.
The add/edit LDAP Server page displays the fields necessary to query and pull context information from your LDAP server(s), including:
Server Type – Select either Microsoft Active Directory (default) or NetIQ eDirectory.
Primary IP Address or Hostname – Enter the LDAP IP address or hostname for the primary server of the given server type.
Note
For context retrieval in Microsoft Active Directory environments, we recommend pointing to a Global Catalog server. To list Global Catalog servers, enter the following command in a Windows command prompt window: nslookup -querytype=srv gc.tcp.acme.local
.
Replace acme.local
with your company's domain name.
I have a secondary server – If the primary LDAP server is unavailable, Exabeam falls back to the secondary LDAP server if configured. Click this checkbox to add a secondary LDAP server and display a Secondary IP Address or Hostname field.
TCP Port – Enter the TCP port of the LDAP server. Optionally, select Enable SSL (LDAPS) and/or Global Catalog to auto-populate the TCP port information accordingly.
Bind DN – Enter the bind domain name, or leave blank for anonymous bind.
Bind Password – Enter the bind password, if applicable.
Base DN – Enter the base domain name. For example, DC=acme, DC=local, etc.
For Microsoft Active Directory:
LDAP attributes for Account Name – This field auto-populated with the value
sAMAccountName
. Please modify the value if your AD deployment uses a different value.
For NetIQ eDirectory:
LDAP Attributes – The list of all attributes to be queried by the Exabeam Domain Service (EDS) component is required. When testing the connection to the eDirectory server, EDS will collect from the server a list of the available attributes and display that list as a drop down menu. Select the name of the attribute from that list or provide a name of your own. Only names for the LDAP attributes you want EDS to poll are required (i.e., not necessarily the full list). Additionally, EDS does not support other types of attributes, therefore you cannot add “new attributes” on the list below.
Click Validate Connection to test the LDAP settings.
If you selected Global Catalog, this button displays as Connect & Get Domains.
Set Up LDAP Authentication
In addition to local authentication Exabeam can authenticate users via an external LDAP server.
When you arrive at this page, by default the ‘Enable LDAP Authentication’ is selected and the LDAP attribute name is also populated. To change the LDAP attribute, enter the new account name and click Save. To add an LDAP group, select Add LDAP Group and enter the DN of the group you would like to add. Test Settings will tell you how many analysts Exabeam found in the group. From here you can select which role(s) to assign. It is important to note that these roles are assigned to the group and not to the individual analysts; if an analyst changes groups their role will automatically change to the role(s) associated with their new group.
Single Sign-on and Multi-factor Authentication Using SAML
Exabeam users may have a single sign on vendor in their environment, such as Okta, Ping, Duo, Google, or Microsoft Active Directory Federation Services. Exabeam integrates with them, allowing administrators and users to sign on to Exabeam using their existing credentials.
With SAML Authentication enabled, there is no need for users to enter credentials and/or remember/renew a password with Exabeam.
Configuring Single Sign-on and Multi-factor Authentication
Exabeam users may have a single sign on vendor in their environment, such as Okta, Ping, Microsoft Active Directory Federated Services (ADFS), or Google. You may also implement a custom or generic identity provider (IdP). Exabeam integrates with them, allowing administrators and users to sign on to Exabeam using their existing credentials. With SAML authentication enabled, there is no need for users to enter credentials and/or remember/renew a password with Exabeam.
Warning
If your instance of Exabeam is running in a private network, you must ensure webcommon.service.externalAddress
is pointing to the correct external IP address and is the same as <exabeam_master_host>
, which was specified in configuration for IdP. The property is pointing to EXABEAM_IP
environment variable, which is assigned during Exabeam deployment.
When Exabeam is deployed on AWS, there should not be any issues. When Exabeam is deployed on Google Cloud Platform, you may need to set the property in /optz/exabeam/config/common/web/default/application_default.conf
.
Important
For Exabeam SaaS deployments, additional restrictions have been applied to enforce security cross origin resource sharing (CORS) practices. Please add the origin of your SSO provider by following the Exabeam Operational Hardening guidelines to ensure SSO works when CORS protection is enabled.
Single sign-on: If your organization uses Okta, Ping Identity, Microsoft Active Directory Federated Services (ADFS), or Google as an IdP, you can configure single sign-on directly within the UI. Once configured, your users are automatically authenticated into the UI and will not be asked to create and/or enter specific login credentials.
Multi-factor authentication: Similarly, Exabeam products automatically support your multi-factor authentication (MFA, including two-factor authentication and/or two-step verification) through Okta, Ping Identity, and Google.
Configure your identity service provider to produce credentials. The following instructions are for identity providers supported by Exabeam.
Log onto Google Admin, then go to Home > SAML apps.
Click the + icon to enable SSO for a SAML application.
Click SETUP MY OWN CUSTOM APP.
Click Next.
Set the Application name, and then click Next.
Set the following properties ACS URL and Entity ID.
ACS URL:
https://<exabeam_master_host>:8484/api/auth/saml2/google/handle-assertion
Entity ID:
https://<exabeam_master_host>:8484/api/auth/saml2/google/login
where the
<exabeam_master_host>
is either an external IP address or hostname of the UI accessible by Google.Click Attribute Mapping to create a mapping. Fill in the fields. The values in the first column are keys and should correspond to those which will be provided in web-common SAML SP config later. In this example First Name of the user from IdP is used for grouping.
Click Next and then click OK.
Click the vertical ellipse icon and then click ON for everyone.
Open Service Provider Details > Manage Certificates. Then, select the DOWNLOAD IDP METADATA file. Put the file in an easily accessible location. Hold this file for later configuration. Go to Configure Identity Providers in Exabeam to set up SSO.
The instructions that follow are based on Windows 2019 Server.
Ensure that the identity provider (IdP) initiated SSO is enabled in ADFS. Verify using the PowerShell cmdlets
Get-AdfsProperties
andSet-AdfsProperties
.Get-AdfsProperties | Select EnableIdpInitiatedSignonpage # EnableIdpInitiatedSignonPage # ---------------------------- # False Set-AdfsProperties –EnableIdpInitiatedSignonPage $True
Note
For more information on enabling IdP SSO, see
https://blogs.technet.microsoft.com/rmilne/2017/06/20/how-to-enable-idpinitiatedsignon-page-inad-fs-2016/
https://docs.microsoft.com/en-us/powershell/module/adfs/set-adfsproperties
Configure Microsoft ADFS Relying Party Trust by going to the Server Manager > Tools > AD FS > AD FS Management.
Go to the Relying Party Trusts branch and click Add Relying Party Trust.
Select Claims aware and then click Start.
Select Enter data about the relying party manually and then click Next.
Enter a Display name.
Exabeam SAML SSO
, for example, and then click Next.Click Next at the Configure Certificate menu.
Select Enable support for the SAML 2.0 WebSSO protocol.
At Relying party SAML 2.0 SSO service URL, enter the ACS link
https://<exabeam master host>:8484/api/auth/saml2/adfs/handle-assertion
, and then click Next.At Relying party trust identifier, enter the Exabeam Entity ID,
https://<exabeam master host>:8484/api/auth/saml2/adfs/login
. Click Add to enter it into the list of trusted identifiers.At the Choose Access Control Policy menu, choose an access control policy from the list that adheres to your organization's policies. Then click Next.
Leave Configure claims issuance policy for this application selected. Click Close.
Verify that a new record was created in the Rely Party Trusts list.
Select the new record. Right-click and then select Edit Claim Issuance Policy.
Select Add Rule and choose the template Send LDAP Attributes as Claims.
In the Edit Rule menu, enter a Claim rule name. Select Choose Active Directory as the Attribute store, and add the following attribute mappings:
E-Mail-Addresses > EmailAddress
Set to user email
Display-Name > FirstName
First name of
exabeam
userDisplay-Name > Username
Username with prefix added (For example, if username is
Jackyl
it becomes[saml]Jackyl
, username ofexabeam
user.)Surname > LastName
Last name of
exabeam
userDisplay-Name > ExaGroup
Associated user group for retrieving role and permissions. The display name will be set as the value ExaGroup attribute inside IdP response and must exist among all group mappings on the Exabeam side.
Click Finish to save the configuration. Click Okay to close the menu.
Select the record again. Right-click and then select Edit Claim Issuance Policy.
Click Add Rule and then select the template Transform an Incoming Claim. Click Next.
Set a rule to transform
Username
toName ID
in anunspecified
format. Click View Rule Language to see the resultant rule. Here is an example:c:[Type == "Username"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified");
Download
metadata.xml
file from IdP (ADFS) athttps://<adfs host>/FederationMetadata/2007-06/FederationMetadata.xml
.Go to Configure Identity Providers in Exabeam to set up SSO. In the setup, use the following Exabeam-to-IdP attribute mappings:
Email Address > EmailAddress
Username > Username
First Name > FirstName
Last Name > LastName
Group > ExaGroup
Exagroup
is used here as an example of a group name.
Log into the Okta console for your organization. The instructions that follow are based on the Okta Classic UI.
Click Admin.
Click Add Applications.
Click Create New App.
Select SAML 2.0.
Enter the App name and then click Next.
Enter the following properties:
Single sign on URL:
https://<exabeam_master_host>:8484/api/auth/saml2/okta/handle-assertion
Click Next to go to the confirmation menu.
Select I'm an Okta customer adding an internal app and the checkbox This is an internal app that we have created.
Press Finish to apply the configuration.
Click on the Assignments section of the Exabeam test application and select Assign to People.
Press Assign.
Leave the username as-is and press Save and Go Back.
Press Done.
Click on the Sign On section of the Exabeam test application and press View Setup Instructions.
In the new page that opens, you can find the SSO URL, certificate file, metadata file content. Hold this information for later configuration. Go to Configure Identity Providers in Exabeam to set up SSO.
Ping
Log into the Ping console for your organization.
Go to Applications and press Add Application.
Choose New SAML Application.
Enter Application Name, Application Description and choose Other category. Press Continue to Next Step.
Set mandatory properties:
Assertion Consumer Service (ACS): https://<exabeam_master_host>:8484/api/auth/saml2/ping/handle-assertion
Entity ID: https://<exabeam_master_host>:8484/api/auth/saml2/ping/login
where the <exabeam_master_host> is either an external IP address or hostname of the UI accessible by Ping.
Press Continue to Next Step.
Specify attribute mapping. Mark each property as
Required
. TheSAML_SUBJECT
attribute is required for Ping to function correctly.For the attribute
SAML_SUBJECT
attribute press Advanced.Set Name ID Format to send to SP to the value shown in the example below, then press Save.
Pay attention to this.
On the Preview settings page, download the Certificate file and Metadata file. Hold these files for later configuration.
The SSO URL is found in the Metadata file, with the tag
md:SingleSignOnService
, whereBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
.Press Finish. Make sure the created application is enabled.
Go to Configure Identity Providers in Exabeam to set up SSO.
Once you have collected authentication metadata or certificate files from your IdP, you will associate the IdP to your Exabeam product. These instructions assumes you have created an identity service provider record. (See Configure SAML Identity Provider)
Log into your Exabeam product
Navigate to Settings > Admin Operations > Configure SAML.
Select the IdP in the list and click the Edit icon to configure the record to open the Edit Identity Provider menu.
Click the IdP Enable toggle to activate the service.
Ensure the correct SAML Provider is shown.
If you have a metadata file from your IdP, select Upload the XML file metadata file provided by your IdP and then click CHOOSE FILE to upload the file.
If you have a certificate file and SSO URL, select Configure SSO manually and then click CHOOSE FILE to upload the certificate and enter the SSO URL.
You can optionally specify the Authentication Method, if you are uploading SSO assets.
Configure the Query Attributes mappings.
Click SAVE to apply the configurations.
Go to Map SAML Groups to Exabeam User Roles to associate user roles to your IdP service.
To configure an identity provider in your Exabeam deployment:
Log in to your instance of the UI.
Navigate to Settings.
On the Settings page, go to User Management > Configure SAML.
Click Add Identity Provider.
This step assumes you have already configured the IdP service provider. If not, configure your IdP service before proceeding.
Custom or generic SSO IdP are to include: (Please refer to the IdP vendor for additional instructions.)
IdP vendor name (15 characters or less)
Idp logo (PNG file size of 1Mb or less and in 3:4 or 9:16 aspect ratio)
The IdP is enabled by default upon saving. It can be disabled by toggling the IdP Disabled button.
Note
You can configure multiple identity providers for your organization, but you can enable only one at a time. For information on configuring your SAML Identity Provider, see Configure SAML Identity Provider.
Select your SAML Identity Provider. All supported IdPs are listed in the drop-down.
Complete the SSO Configuration by choosing one of the two options below. If you have an XML metadata file from you IdP, choose the first option. If you do not, you will need to manually configure SSO.
Upload the XML file metadata provided by your IdP – Click the button to locate and upload the XML file from your computer. SAML metadata is used to share configuration information between the Identity Provider (IdP) and the Service Provider (SP).
Configure SSO manually – Click the Choose File button to locate and upload the IdP certificate from your computer, and then enter the Single Sign-on URL and select either HTTP Post or HTTP Redirect. Optionally, configure the Single Log-Out URL and Redirect to URL after Log-Out.
Select the Authentication Method or leave the field blank to accept the default configuration.
For Custom/Generic IdPCustom/Generic IdP, configure the Name of IdP and Upload IdP logo.
For ADFS, configure the encryption. Select the option(s) that applies to your environment.
Encryption Enabled -- Users are able to fill data for signature request and decryption response.
Signature Enabled -- Adds a signature to the SAML authorization requests. Encryption keys (private key and certificate) are required.
Internal Keys -- User internal Exabeam encryption key-pair (located in the trust store). To download the internal certificate, click the Download certificate link.
Custom Keys -- User the key-pair from your organization.
Configure the Query Attributes to map your identity provider attributes to Exabeam's attributes.
Click Identity Providers table.
. Your identity provider now appears in the
You can also continue customizing the configuration by mapping your SAML groups to Exabeam user roles.
Once you have configured a SAML identity provider, the Group Mappings options appears below the Identity Providers table.
To map your existing SAML groups to Exabeam user roles:
Click Add Group.
Select your configured Identity Provider.
Enter a SAML Group Name. The name must match the
Group
value that comes from the IdP response in the group attribute; meaning,<Attribute name="Group" value="[saml_group_name]">
.Use the checkboxes to select default and custom roles.
Click Save.
Your SAML user groups are now mapped to Exabeam user roles.
You can dictate how SAML authentication is handled within Exabeam products. There are two ways to implement SAML as well as disabling it entirely.
Navigate to Settings > User Management > Configure SAML.
In the SAML Status box has setting your organization is to support. To change the status, click EDIT.
The SAML Status box shows the current condition of how your users are permitted to log in to the UI. Click Edit to configure how your users are permitted to log in, including:
Disabled – SAML was configured, but it is not currently enabled. Consequently, users from your organization can only log in with their Exabeam credentials, but they will not be automatically authorized based on the their SAML credentials.
Allowed – Users can log in with their SAML or Exabeam credentials. If they have Exabeam credentials, they will also be able to use them to log in.
Mandatory – Users can log in with their SAML credentials, but they cannot log in with their Exabeam credentials.
Select Allowed or Mandatory to implement SAML credentialing, and then click SAVE to apply changes.
Configure an Identity Provider
Please contact your Technical Account Manager.
Click the Menu
, then navigate to Settings > Admin Operations > Additional Settings.
Under User Management, select Configure SAML.
Click Add Identity Provider.
You can configure multiple identity providers for your organization, but yenable only one at a time. By default, the IdP is enabled when you save. To disable it, toggle the IdP Disabled button.
Under SAML Identity Provider, select a provider from the list of all supported providers.
Decide how you want to configure the SSO:
If you have an XML metadata file from your IdP, select Upload the XML metadata file provided by your IdP. Click CHOOSE FILE, then upload the XML file.
If you don't have an XML metadata file, select Configure SSO manually. Click CHOOSE FILE, upload the IdP certificate, then enter the single sign-on URL. If applicable, enter a single log-out URL or a URL to redirect to after logging out.
To map the identity provider attributes to Exabeam attributes, configure the query attributes:
Click Identity Providers table.
. Your identity provider appears in the
You can also continue customizing the configuration by mapping your SAML groups to Exabeam user roles.
Map SAML Groups to Exabeam User Roles
Once you have configured a SAML identity provider, the Group Mappings options appears below the Identity Providers table.
To map your existing SAML groups to Exabeam user roles:
Click Add Group.
Select your configured Identity Provider.
Enter a SAML Group Name.
Use the checkboxes to select default and custom roles.
Click Save.
Set Up Context Management
Logs tell Exabeam what the users and entities are doing while context tells us who the users and entities are. These are data sources that typically come from identity services such as Active Directory. They enrich the logs to help with the anomaly detection process or are used directly by the risk engine layer for fact-based rules. Regardless of where these external feeds are used, they all go through the anomaly detection layer as part of an event. Examples of context information potentially used by the anomaly detection layer are the location for a given IP address, ISP name for an IP address, and department for a user.
Analysts are able to view and edit Exabeam's out-of-the-box context tables as well as create their own custom tables. They can select a specific table, such as Executive Users, Service Accounts, etc. and see the details of the table and all of the objects within the table. Edits can be performed on objects individually or through CSV uploads.
Out-of-the-Box Context Tables
Context Table | Source | Available Actions |
---|---|---|
email_user | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam. Administrators cannot add, edit, or delete the entries in this context table. |
fullname_user | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam. Administrators cannot add, edit, or delete the entries in this context table. |
user_account | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or AD filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_department | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_division | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_manager | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Advanced Directoryfilters. Where Administrators have manually added users, they can also edit or delete entries. |
user_department_number | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_country | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_location | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_title | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_fullname | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam. Administrators cannot add, edit, or delete the entries in this context table. |
user_phone_cell | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_phone_office | LDAP | This table is automatically populated when administrators integrate their LDAP system with Exabeam and add regular expression through the Advanced Analytics tab. Administrators can add entries manually via CSV or Active Directory filters. Where Administrators have manually added users, they can also edit or delete entries. |
user_is_privileged | Administrators | Administrators can add entries manually, via CSV, or Active Directory. Entries can also be edited or deleted. |
Threat Intelligence Service Context Tables
The table below shows the description of each available threat intelligence feed to a context table in Advanced Analytics:
Context Table | Description |
---|---|
is_ip_threat | IP addresses identified as a threat. |
is_ip_ransomeware_ip | IP addresses associated with ransomware traffic. |
is_tor_ip | Known Tor IP addresses. |
reputation_domains | Domains associated with malware traffic |
web_phishing | Domains associated with phishing attacks. |
For more information on Exabeam threat intelligence service, please see the section Threat Intelligence Service Overview.
Custom Context Tables
Exabeam provides several filters and lookups to get your security deployment running immediately. However, there may be assets and users within your organization that need particular attention and cannot be fully addressed out of the box. Custom context tables allow you the flexibility to create watchlists or reference lists for assets, threat intelligence indicators, and users/groups that do not fit in the typical deployment categories. Custom context tables let you put parts of your organization under extra monitoring or special scrutiny, such as financial servers, privileged insiders, and high-level departed employees.
Within Advanced Analytics, you can create watchlists using context tables. When creating the table, the Label attribute allows you to attach tags to records that match entries in your context table. This provides quick access to query your results and/or focus your tracking using a global characteristic.
You can also build rules based on entries in your context tables. Set up alerts, actions, or playbooks to trigger when conditions match records, such as access to devices in a special asset group.
Context Data
Prepare Context Data
You can upload data as CSV files with either key and value columns or key-only column. All context tables include a Label to tag matching records into groups during parsing and filtering.
Key-value CSV –Two-field data file with a header row. This lookup lists correlations between the two fields, such as:
Key Fieldname | Value Fieldname |
---|---|
AC1Group | Accounts Receivable |
AC2Group | Accounts Payable |
Key-only CSV – Single-field data file with no header row. Items on this list are compared to as being present or not during data filtering. For example, a watchlist context table, SpecialGroup, consists of user groups of special interest:
“Accounts Receivable”
“Accounts Payable”
“Accounting Database Admin”
You can create a correlation rule that sends an alert when the monitoring data contains a user having the group name that matches any in the SpecialGroup table.
Label – The named tag associated with a record. This allows you to filter groups of records during parsing or filtering. You can also use labels to assemble watchlists based on groupings rather than by individual asset or user record.
Note
You can opt not to use labels by selecting No Label during table creation. Otherwise, labels are associated with tables and its records. For key-value context tables, the Label is drawn from the value field of the matching context table entry. For key-only context tables, the Label is the table attribute you enter in the Manual Assignment field during table creation and is used to tag all matching records.
![]() |
Create Custom Lookups
You must first create a table object to add contextual data to. Create the table with key-only or key-value field and whether labels will used based on the needs of your organization. Use the various methods to add content into your table depending on your data source.
Create a Context Table
To introduce context data into your environment, create a table object to contain your data and reference it in queries and lookups.
Navigate to Settings > Accounts & Groups > Context Tables.
At the top right of the UI, click the blue + to open the New Context Table dialogue box.
Fill in the details of the type of context table that this will be.
Fill in table attribute fields:
Name – A unique name identifying the table in queries and in the context of your organization.
Object Type – The type gives the table additional tagging (with information on the potential data source, such as LDAP for users or user groups).
Users – This object type is associated with users and user group context tables. LDAP data sources can be used to fill its content.
Assets – These are itemizable objects of value to your organization. These can be devices, files, or workstations/servers.
Miscellaneous – These are reference objects of interest, such as tags for groups of objects within a department or network zones.
Type – Select the field structure in the table as
Key Value
orKey Only
. See Prepare Context Data for more information. If you are creating a correlation context table, useKey Only
.Label Assignment – Click the text source for creating the label or use no label. See Prepare Context Data for more information.
Click Save to advance to the table details UI for the newly created context table.
Your table is ready to store data. The following sections describe ways to add data to your table. Each method is dependent on the data source and intended use of the table.
Import Data into a Context Table Using CSV
This is the most flexible method to create unconventional context tables as the CSV file can contain any category or type of data that you wish to monitor.
Select your desired context table.
Select the Upload Table icon.
Click Upload CSV. From your file system, select the CSV file you wish to import, then select Next.
Note
Key and value (2 fields) tables require a header first row. Do not include a header for keys-only CSV files (1 field). Table names may be alpha-numeric with no blank spaces. (Underscore is acceptable.)
Inspect the contents that will be added to your table. Select Apply Changes, when you are done.
Once context has been integrated, it is displayed in the table. You can use the lookup tables in rules as required.

For assistance in creating custom context tables, contact Exabeam Customer Success by opening a case at Exabeam Community.
Import Data into a Context Table Using an LDAP Connection
This section details the steps required to create context tables to customize your lookups. In this example, we are creating a lookup table with two fields: the userAccountControl
field and the User ID
field. This allows the event enricher to map one to the other. For example, let's say you have a log that does not include the username, but instead included the userAccountControl
field. This would map the two together. A similar use case would be badge logs: you could create a lookup table that maps the badge ID to the actual username, assuming the badge ID is contained in LDAP.
Navigate to the Settings > Accounts & Groups > Context Tables.
Click the ‘+’ icon to add a new table.
In this example, we use these settings:
Name –
useraccountcontrol_user
Object Type –
Users
Type –
Key Value
Label Assignment –
Automatic Assignment from value
Click Save.
Click No Label if you do not want to add a label to matching records during parsing or filtering.
The context table now appears in the Context Management tables list.
Select the name of the context table you created in Step 4 to configure it with values.
After clicking on
useraccountcontrol_user
you will be presented with the setup page for theuseraccountcontrol_user
context table.Click + Add Connection to connect the context table to an LDAP domain server.
Select the LDAP Server(s), Key, and Value to populate the context table. Optionally, filter the attribute source with conditions by clicking ADD CONDITION.
Click TEST CONNECTION to view and validate the test results, and then click SAVE.
Once context has been integrated, it is displayed in the table. You can use the lookup table in rules as required.
For assistance in creating custom context tables, contact Exabeam Customer Success by opening a case at Exabeam Community
How Audit Logging Works
Specific activities related to Exabeam product administrators and users are logged, including activities within the UI as well as configuration and server changes. This is especially useful for reviewing activities of departed employees as well as for audits (for example, GDPR).
The following events are logged:
|
|
These audit logs are stored in MongoDB. You can find them at exabeam_audit_db
inside the audit_events
collection. The collection stores the entire auditing history. You cannot purge audit logs or set retention limits.
Audit Log Retention
Hardware and Virtual Deployments Only
The Exabeam audit logs are activity logs for user and asset activity in your organization. The logs are held for 90 days by default and retention can be extended up to 365 days.
Retention time is found in /opt/exabeam/config/common/web/custom/application.conf
, where webcommon.audit.retentionPeriod
determines the number of days logs are held. The range may be 1 to 365 days.
Send Advanced Analytics Activity Log Data via Syslog
Access activity data via Syslog. Audit logs of administrative and analyst actions can be forwarded to an existing SIEM or Data Lake via Syslog. Exabeam sends the Advanced Analytics activity data every five minutes.
Note
Advanced Analytics activity log data is not masked or obfuscated when sent via Syslog. It is your responsibility to upload the data to a dedicated index which is available only to users with appropriate privileges.
To access activity data via Syslog:
Navigate to Settings > Log Management > Incident Notification.
Edit an existing Syslog destination, or create a new Syslog destination.
Configure any applicable Syslog settings.
After completing the applicable fields, click TEST CONNECTION.
If the test fails, validate the configured fields and re-test connectivity until successful.
If the test succeeds, continue to the next step.
Click the AA/CM/OAR Audit checkbox.
Click Add Notification.
Starting the Analytics Engine
Once the setup is complete, the administrator can start the Exabeam Analytics Engine. The engine will start fetching the logs from the SIEM, parsing, and then analyzing them. On the Settings page, go to Admin Operations then Exabeam Engine to access controls.
Actions can be restarted from a specific point in time - Exabeam will re-fetch and reprocess all the logs going forward from that time. Note that date and time is given in UTC and starts at epoch (i.e. 00:00:00 hour).
When Ingest Log Feeds (and logs are selected) or Restart Processing is selected, a settings menu is presented.
Restart the engine – Select this option if this is the first time the engine is run.
Restart from the initial training period – Restart engine using data initially collected.
Restart from a date – Reprocess based on specific date (UTC).
Additional Configurations
Configure Static Mappings of Hosts to/from IP Addresses
Hardware and Virtual Deployments Only
Note
To configure this feature, please contact your Technical Account Manager.
You can configure static mappings from hosts to IP addresses, and vice versa. This is especially useful for mapping domain controllers (DCs). Since DCs do not often change IPs, you can tie the DC hostname to a specific IP address. Additionally, if there is user activity that isn't tied to a hostname but is tied to an IP address, then you can map the user to their specific, static IP address. This helps maintain and enrich information in events that may be lost or unknown since the system cannot tie events to dynamic IP addresses.
Map IP addresses to hosts
Add them to the file: /opt/exabeam/data/context/dynamic_objects/static_ip_host_mapping.csv
CSV Format: [ip], [host]
Map hosts to IP addresses
Add them to the file: /opt/exabeam/data/context/dynamic_objects/static_host_ip_mapping.csv
CSV Format: [host], [ip]
Associate Machine Oriented Log Events to User Sessions
Hardware and Virtual Deployments Only
Proxy and other generic sequence events (such as, web, database, file activity, endpoint) as well as some security and DLP alerts may generate logs that contain only machine names or IP addresses without the user names. In Advanced Analytics , you can automatically associate these events with users by IP/host-to-user mapping.
Note
This feature is currently only available for sequence events in multi-node deployments.
User-Host/IP Association
Exabeam will create an IP/host-to-user association based on specific configurable events. (See example below.) The logic to associate users and hosts is flexible and is configurable by using the UserPresentOnHostIf
parameter. For example, you can choose to associate a user and host in Kerberos logon events only if the IP is in a specific network zone.
The configuration also allows you to associate the user with any field based on event type. For example, you can associate the user in a Kerberos logon event with dest_host (destination host) and dest_ip (destination IP), and the user in a remote-access event with src_host (source host) and src_ip (source IP). The user of a remote logon event can be associated with both src_host and dest_host because the events indicates they are present on both.
User-Host Example
The example configuration below shows an association between user and IP event. Edits are made to /opt/exabeam/config/custom/custom_exabeam_config.conf
:
UserPresentOnHostIf { kerberos-logon = { Condition = "not (EndsWith(user, '$') OR InList(user, 'system', 'local service', 'network service','anonymous logon'))" UserPresentOn = ["dest_host", "dest_ip"] } remote-logon = { Condition = "not (EndsWith(user, '$') OR InList(user, 'system', 'local service', 'network service','anonymous logon'))" UserPresentOn = ["dest_host", "src_host", "dest_ip", "src_ip"] } remote-access = { Condition = "InList(ticket_options, '0x40800000', '0x60810010') && not (EndsWith(user, '$') OR InList(user, 'system', 'local service', 'network service', 'anonymous logon'))" UserPresentOn = ["src_host", "src_ip"] } }
After editing the configuration file, restart services to apply changes:
exabeam-analytics-stop exabeam-analytics-start
User-Event Association
Based on the host/IP-to-user association described above, Exabeam can associate an event with a host/IP to a user. This is done via the HostToUserMerger parameter. This configuration enables you to determine which events will utilize the created associations as well as which fields should be used to make it.
A user will be resolved from the host/IP only if one user is associated with this host/IP. If more than one user is associated, no user will be resolved.
User-event example
The example configuration below defines which events should be considered for resolving the user. The events web-activity-allowed and web-activity-denied are event types that will be associated with the user.
HostToUserMerger { Enabled = true EventTypes = [ { EventType = "web-activity-allowed" MergeFields = ["src_host", “src_ip”] }, { EventType = "web-activity-denied" MergeFields = ["src_host"] } ] }
After editing the configuration file, restart services to apply changes:
exabeam-analytics-stop exabeam-analytics-start
Alert-User Association
The host/IP-to-user association will also be used to resolve the user in security and DLP alerts that do not have one. If one user is on the host during the alert trigger, then the user is associated with a host/IP when resolving a user in security. If there is more than one user on the host, no DLP alerts are associated.
Display a Custom Login Message
You can create and display a custom login message for your users. The message is displayed to all users before they can proceed to login.
To display a custom login message:
On a web browser, log in to your Exabeam web console using an account with administrator privileges.
Navigate to Settings > Admin Operations > Additional Settings.
Under Admin Operations, click Login Message.
Click EDIT.
Enter a login message in Message Content.
Note
The message content has no character limit and must follow UTF-8 format. It supports empty lines between text. However, it does not support special print types, links, or images.
A common type of message is a warning message. The following example is a sample message:
Usage Warning
This computer system is for authorized use only. Users have no explicit or implicit expectation of privacy.
Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to an authorized site. By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of the authorized site.
Unauthorized or improper use of this system may result in administrative disciplinary action and civil and criminal penalties. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning.
Note
This sample warning message is intended to be used only as an example. Do not use this message in your deployment.
Click SAVE.
Click the Display Login Message toggle to enable the message.
Note
You can hide your message at any time without deleting it by disabling the message content.
Your custom login message is now shared with all users before they proceed to the login screen.
![]() |
Configure Threat Hunter Maximum Search Result Limit
You can configure the maximum search result limit when using Threat Hunter’s search capabilities. By default, the result limit is set to 10,000 sessions.
Note
To configure this feature, please contact your Technical Account Manager.
The default result limit is located in the application_default.conf
file at /opt/exabeam/config/tequila/default/application_default.conf
.
All changes should be made to
/opt/exabeam/config/tequila/custom/application.conf
.
To configure the default result limit, enter an acceptable value in place of 10000
at tequila.data.criteria
:
finalQueryResultLimit = 10000
There is no restriction on the limit value, however, for very large intermediate results you should input at least 30,000 sessions.
Change Date and Time Formats
Hardware and Virtual Deployments Only
Change the way dates and times are displayed in Advanced Analytics, Case Manager, and Incident Responder.
Note
To configure this feature, please contact your Technical Account Manager.
Dates and times may appear slightly different between Advanced Analytics, Case Manager, and Incident Responder.
Navigate to
/opt/exabeam/config/tequila/custom/
, then open theapplication.conf
file.Enter a supported format value:
To configure how dates are formatted, enter a supported value after
tequila.data.criteria.dateFormat =
, in quotation marks:tequila.data.criteria.dateFormat = "[value]"
To configure how times are formatted, enter a supported value after
tequila.data.criteria.timeFormat =
, in quotation marks:tequila.data.criteria.timeFormat = "[value]"
Save the
application.conf
file.Restart Advanced Analytics Restful Web Services:
web-stop; web-start
Supported Date and Time Formats
View all the ways you can format dates and times displayed in Advanced Analytics, Case Manager, and Incident Responder.
Date Formats
By default, dates are displayed in the "default" format, DD Month Year; for example, 27 September 2012.
Depending on the format, some areas of the product, like watchlists and user or asset profiles, may display a shortened or year-less version.
Value | Format | Example | Shortened Example | Year-less Example |
---|---|---|---|---|
"default" | DD Month YYYY | 27 September 2012 | 27 Sep 2012 | 27 Sep |
"default-short" | DD Mo YYYY | 27 Sep 2012 | n/a | 27 Sep |
"default-num" | DD-MM-YYYY | 27-09-2012 | n/a | 27-09 |
"default-num-short" | DD-MM-YY | 27-09-12 | n/a | 27-09 |
"us" | Month DD YYYY | September 27 2012 | Sep 27 2012 | Sep 27 |
"us-short" | Mo DD YYYY | Sep 27 2012 | n/a | Sep 27 |
"us-num" | MM-DD-YYYY | 09-27-2012 | n/a | 09-27 |
"us-num-short" | MM-DD-YY | 09-27-12 | n/a | 09-27 |
"ISO" | YYYY-MM-DD (ISO 8601) | 2012-09-27 | n/a | 09-27 |
"ISO-slash" | YYYY/MM/DD | 2012/09/27 | n/a | 09/27 |
Time Formats
By default, times are displayed in 24hr format.
Value | Format | Notes |
---|---|---|
"24hr" | 13:45 | This is the default value in the configuration file. For chart labels, the time appears as 13 instead of 1pm. Minutes aren't displayed. |
"12hr" | 1:45pm | Leading zeros aren't displayed. For example, the time appears as 1:45pm instead of 01:45pm. Some areas of the product use a and p to indicate am and pm. |
Set Up Machine Learning Algorithms (Beta)
Machine Learning (ML) algorithms require a different infrastructure than regular deployments. This infrastructure is necessary to run data science algorithms. ML infrastructure will install two new docker-powered services: Hadoop YARN and Advanced Analytics API.
Note
These machine learning algorithms are currently available as beta features.
Installation is only supported on EX4000 powered single- or multi-node deployments running Advanced Analytics i35 or later due to the high system resources needed for these jobs. ML infrastructure is a requirement for algorithms that drive the Personal Email Detection, Daily Activity Change Detection, and Windows Privileged Command Monitoring features.
Install and Deploy Machine Learning
Installation is done through the unified installer by specifying the ml
product after Advanced Analytics has already been deployed. The build version needs to be identical to the version used for Advanced Analytics.
When asked for the docker tag of the image to be used for ML, make sure to use the same tag which was used for Advanced Analytics.
Optionally, run this process in screen:
screen -LS [yourname]_[todaysdate]
Run the following script:
/opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select your inputs based on the following prompts:
Add Product(s) Which product(s) do you wish to add? ['ml', 'lms', 'ir']: ml What is the docker tag for new ml images? <AA version_build> Would you like to override the default docker_gwbridge IP/CIDR? n Do you want to setup disaster recovery? n
Stop the Log Ingestion Engine and the Analytics Engine at the shell, make configuration changes, and then restart services.
exa-lime-stop; exa-martini-stop
Edit
EventStore
parameters in/opt/exabeam/config/custom/custom_exabeam_config.conf
:EventStore.Enabled = true EventStore.UseHDFS = true
Navigate to
/opt/exabeam/config/custom/custom_exabeam_config.conf
and make sure that Event Store is disabled:EventStore.Enabled = false
Restart the DS server, and then start the Log Ingestion Engine and the Analytics Engine:
ds-server-stop; ds-server-start exa-lime-start; exa-martini-start
Check the state of the DS server by inspecting the log
/opt/exabeam/data/logs/ds-server.log
.Check the DS server logs to ensure the algorithms have been enabled.
grep enabled /opt/exabeam/data/logs/ds-server.log
You should be able to see a list of all algorithms, along with their statuses and configurations.
Note
Navigate to
/opt/exabeam/ds-server/config/custom/algorithms.conf
and setEnabled = true
on the DS algorithms you want to implement. If the customalgorithms.conf
does not contain the DS algorithm you want to implement, copy over the corresponding algorithm block from/opt/exabeam/ds-server/config/default/algorithms_default.conf
.Navigate to
/opt/exabeam/data/logs
and enableEventStore:
} EventStore { UserHDFS = true Enabled = true }
Restart the Log Ingestion Engine and the Analytics Engine to apply any updates:
exa-lime-stop exa-lime-start exa-martini-stop exa-martini-start
Continue to each module to complete your configurations
Configure Machine Learning
All Machine Learning algorithms use EventStore
and expect the data to be stored on HDFS, which must be manually activated by adding this line to /opt/exabeam/config/custom/custom_exabeam_config.conf
:
EventStore.Enabled = true EventStore.UseHDFS = true
All other algorithm-specific configurations should be done in /opt/exabeam/ds-server/config/custom/algorithms.conf
.
The defaults for each algorithm can be found in /opt/exabeam/ds-server/config/default/algorithms_default.conf
. As with other configuration changes, only the options which are changed should be overwritten in the custom algorithms.conf
file.
LogFetcher.LogDir
in /opt/exabeam/config/custom/custom_exabeam_config.conf
is the path for Martini to find events. DS algorithms use this path as well. Therefore, make sure that you have SDK.EventStoreHDFSPathTemplates
in /opt/exabeam/ds-server/config/default/script.conf
, which corresponds to LogFetcher.LogDir
.
For example:
/opt/exabeam/ds-server/config/default/script.confEventStoreHDFSPathTemplates = [ "hdfs://hadoop-master:9000/opt/exabeam/data/input/(YYYY-MM-dd)/(HH).*.evt.gz" ] /opt/exabeam/config/custom/custom_exabeam_config.conf LogFetcher { UseHDFS = true LogDir = "/opt/exabeam/data/input" # this values by default, you don’t have to override it in this config HDFSHost = "hadoop-master" HDFSPort = 9000 }
Note
You can free up space by removing data in hdfs://hadoop-master:9000/opt/exabeam/data/output
, which is not required for DS deployments.
Upgrade Machine Learning Deployment
ML deployments have to be updated together with the underlying Advanced Analytics version. If Machine Learning is installed, the upgrade tool will ask both for a tag for Advanced Analytics and a tag for ML. Make sure to use the same tag for Advanced Analytics and ML. The format for the tag is <version>_<build #>
.
Upgrading ML Custom Configurations
In i50.6 we have changed the source of processing events. Now, EventStore
is no longer needed and should not be enabled to run DS algorithms. Instead, all ML algorithms read events from LogDir. Therefore, if you are upgrading from a version pre-i50.6, make sure EventStore.Type
has been removed from these files:
ds-server/config/default/algorithms_default.conf
ds-server/config/custom/algorithms.conf
ds-server/config/default/script.conf
If you have custom settings, you must also make sure that you edit them correctly in order to preserve them. Custom configurations are not automatically updated.
See details on the required edits below:
In script.conf
Make sure that you remove EventStore.Type
, and change EventStoreHDFSPathTemplates
accordingly. Instead of an output generated by Martini, you should connect it to the Lime output.
Previous version of script.conf
:
{ EventStoreHDFSPathTemplates = [ "hdfs://hadoop-master:9000/opt/exabeam/data/output/(YYYY-MM-dd)/(HH).[type]-events-{m,s?}.evt.gz", "hdfs://hadoop-master:9000/opt/exabeam/data/output/(YYYY-MM-dd)/(HH).[type]-events-{m,s?}.[category].evt.gz" ] EventStore { #Event type. Can be Raw, Container or Any Type = "Container" #Event category. All available categories are in event_categories.conf Categories = ["all"] }
New version of script.conf
:
{ EventStoreHDFSPathTemplates = [ "hdfs://hadoop-master:9000/opt/exabeam/data/input/(YYYY-MM-dd)/(HH).*.[category].evt.gz" ] EventStore { #Event category. All available categories are in event_categories.conf Categories = ["all"] }
To check that everything runs correctly, check custom_exabeam_config.conf
LogFetcher.LogDir
for a path to events folder: /opt/exabeam/config/custom/custom_exabeam_config.conf
LogFetcher { UseHDFS = true # this path to events folder in HDFS should be the same as in # script.conf EventStoreHDFSPathTemplates, main difference LogDir = "/opt/exabeam/data/input" # this values by default, you don’t have to override it in this config HDFSHost = "hadoop-master" HDFSPort = 9000 }
This path should be the same as in script.conf EventStoreHDFSPathTemplates
:
EventStoreHDFSPathTemplates = [ "hdfs://hadoop-master:9000/opt/exabeam/data/input/(YYYY-MM-dd)/(HH).*.[category].evt.gz" ] LogDir = "/opt/exabeam/data/input"
In algorithms.conf
If you customized EventStore.EventType
for the personal-email-identification algorithm, daily-activity-change algorithm, or wincli-command-centric algorithm, then you must ensure that you remove parameter EventStore.EventType
from the configuration:
Previous version of algorithms.conf
:
personal-email-identification { ... EventStore { Type = “Container” Categories = ["alerts"] } ... }
New version of algorithms.conf
:
personal-email-identification { ... EventStore { Categories = ["alerts"] } ... }
To check that everything runs correctly, check the log files after launching exabeam-analytics. AA-API: /opt/exabeam/data/logs/aa-api.log
DS server: /opt/exabeam/data/logs/ds-server.log # spark log files for all algorithms are located in the folder: /opt/exabeam/data/logs/ds-server
Exabeam: /opt/exabeam/data/logs/exabeam.log
Also, you can check Processed
events: tail -f -n 300 /opt/exabeam/data/logs/exabeam.log | grep Processed
You should not see “0 events”
for Processed
events. If “0 events”
persists, then that means that the paths to event files are configured improperly. If you run into this issue, check: /opt/exabeam/config/custom/custom_exabeam_config.conf LogFetcher.LogDir.
You should have the same specifications in the HDFS folder as in LogFetcher.LogDir
. Also, the folder should contain folders with date and files, such as 00.*.evt.gz - 23.*.evt.gz
.
Checking ML Status
You can check the status of DS algorithms in the mongo data_science_db
. There is a separate collection with the states for each algorithm. You can also check the progress in the Martini logs: tail -f /opt/exabeam/data/logs/exabeam.log
Deactivate ML
To deactivate all ML components, shut down the respective services:
ds-server-stop aa-api-stop hadoop-yarn-stop
Detect Daily Activity Change
Daily activity change detection identifies significant changes in a user's overall behavior across both sessions (eg: Windows, VPN) and sequence events (eg: web activity, endpoint activity).
In addition to examining individual activities, Advanced Analytics also looks at anomalies in the overall patterns of the daily activities of a user. For example, taken individually it might not be anomalous for a user to access a server remotely that has been accessed before or download files from Salesforce, but a combination of activities could be anomalous based on the user's daily activity behavior.
The daily activity change will generate an event. If today's behavior is significantly different from past behavior, then that event will also generate a triggered rule (DAILY-ACTIVITY-CHANGE) for the event. The risk score from daily activity change is transferred to the user's session just like any other web or endpoint sequence.
Daily activity change detection is available as a beta capability and by default the feature is turned off.
Configuration Prerequisites
Ensure that you have the Machine Learning infrastructure (beta) installed. If you do not, follow the instructions in the section Machine Learning Algorithms (Beta). Then return to these configuration instructions.
Configuration
Machine Learning Algorithms (Beta) must be deployed in order for the feature to work. Installation is done through the unified installer by specifying the ml product. The build version needs to be identical to the version used for Advanced Analytics.
To enable Daily Activity Change add the following line to
/opt/exabeam/ds-server/config/custom/algorithms.conf
:Algorithms.daily-activity-change.Enabled = true
To enable Daily Activity Change, in
/opt/exabeam/ds-server/config/custom/algorithms.conf
set:daily-activity-change { ... Enabled = true
EventStore must be disabled:
Make sure that in
/opt/exabeam/config/custom/custom_exabeam_config.conf
:EventStore.Enabled = false
EventStore must also be active for the feature to work:
Add the following lines to
/opt/exabeam/config/custom/custom_exabeam_config.conf
:EventStore.Enabled = true EventStore.UseHDFS = true
Daily Activity Change Parameters
You can customize configuration parameters for the algorithm under daily-activity-change
within algorithms.conf
(/opt/exabeam/ds-server/config/custom/algorithms.conf
). Refer to algorithms_default.conf
(/opt/exabeam/ds-server/config/default/algorihtms_default.conf
) for default settings.
VarianceThreshold = 0.95
– variance threshold used by PCAResidueThreshold = 1
– above this threshold is considered anomalousMinTrainingPeriod = 30
– a minimum period of historic data required to detect daily activity changeTrainingPeriod = 90
– data from eventTime - trainingPeriod to eventTime will be taken to train the algorithmRetentionPeriod = 180
– keep historic data for this periodRuleId = "DAILY-ACTIVITY-CHANGE"
– in mongo triggered_rule_db triggered_rule_collection all triggered rules by this algorithm will be saved with rule_id = “DAILY-ACTIVITY-CHANGE”RuleEventType = "daily-activity"
– in mongo triggered_rule_db.triggered_rule_collection all triggered rules by this algorithm will be saved with rule_event_type = “daily-activity”DistinctCountIntervalMs = 600000
– time in events from EventStore will be rounded down to 600000 Ms = 10 minutes.For example:1406877142000 = Friday, August 1, 2014 7:12:22 AM
Becomes:1406877000000 = Friday, August 1, 2014 7:10:00 AM
Verify Intermediate Results
This algorithm saves results in the Mongo database. You can check database ds_dac_db
. It should have two collections: event_weight and user_activity
. They should not be empty while processing.
You can also check triggered_rule_db
in collection triggered_rule_collection
. There should be some events with rule_id = DAILY-ACTIVITY-CHANGE
if there are suspicious users.
Enable Daily Activity Change
Ensure that you have the installed. If you do not, follow the instructions in the section Machine Learning Infrastructure. Then return to these configuration instructions.
Machine Learning Infrastructure must be deployed in order for the feature to work. Installation is done through the unified installer by specifying the
ml
product. The build version needs to be identical to the version used for Advanced Analytics.Add the following line to
/opt/exabeam/ds-server/config/custom/algorithms.conf
:Algorithms.daily-activity-change.Enabled = true
EventStore must also be active for the feature to work.
Add the following lines to
/opt/exabeam/config/custom/custom_exabeam_config.conf
:EventStore.Enabled = true EventStore.UseHDFS = true
Monitor Windows Privileged Commands
Note
To configure this feature, please contact your Technical Account Manager.
Advanced Analytics now identifies anomalous behaviors around Windows privileged commands performed via command line by privilege users. Attackers move through a network using native Windows commands in order to collect information, perform reconnaissance, spread malware, etc. The pattern of the Windows command usage by attackers is statistically and behaviorally different from that of legitimate users and therefore it is possible to detect anomalous behaviors involving command execution. Exabeam performs an offline machine learning algorithm to detect anomalous Windows command execution and assigns risk scores to users performing them.
Associated Rules:
ID | Name | Description |
---|---|---|
EPA-F-CLI | Suspicious Windows process executed | A native Windows command has been executed which is suspicious for this type of user. For example, a non-technical user is executing complicated powershell commands. Check with the user if they are aware of this and who/what is behind it. |
Configuration Prerequisites
Ensure that you have the Machine Learning infrastructure (beta) installed. If you do not, follow the instructions in the section Machine Learning Algorithms. Then return to these configuration instructions.
Configuration
Configuration changes should be made in /opt/exabeam/config/custom/exabeam_custom.config. To enable CLI detection set Enabled = true
.
Field Descriptions:
Enabled
– Set to true to enable detection; set to false to disable.CmdFlagsRegex
– Regular expressions used for flag extraction.CasheSize
– Number of process IDs to be stored.CacheExpirationTime
– The number of days after whichCacheSize
is reset.Commands
– List of the CLI commands that the algorithm will monitor.
Machine Learning Algorithms (Beta) must be deployed in order for the feature to work. Installation is done through the unified installer by specifying the
ml
product. The build version needs to be identical to the version used for Advanced Analytics.To enable Windows Command Line Algorithm, in
/opt/exabeam/ds-server/config/custom/algorithms.conf
set:wincli-command-centric { ... Enabled = true
Commands
andCmdFlagsRegex
should be the same as in thecustom_exabeam_config.conf
.EventStore must be disabled:
Make sure that in
/opt/exabeam/config/custom/custom_exabeam_config.conf
:EventStore.Enabled = false
Windows Privileged Command Monitoring Parameters
You can customize configuration parameters for the algorithm under wincli-command-centric
within algorithms.conf
(/opt/exabeam/ds-server/config/custom/algorithms.conf
). Refer to algorithms_default.conf
(/opt/exabeam/ds-server/config/default/algorihtms_default.conf
) for default settings.
TrainingPeriod = 40
– data fromtrainingPeriod
toeventTime
will be taken to train the algorithmBinThresholds
– bins with size above the threshold are ignored. By default:BinThresholds { flag = 100 directory = 100 parent = 100 }
Commands = ["at.exe", "bcdedit.exe", "cscript.exe", "csvde.exe"...]
– list of the CLI commands that the algorithm will monitorCmdFlagsRegex = "\\s(--|-|/)[a-zA-Z0-9-]+"
– regular expressions used to extract flags from the commandHistoricStatsCollection = "command_centric_historic_stats"
– collection inds_wincli_db
which will retain statistics for Martini rule behaviour
Verify Intermediate Results
To verify the intermediate results, you can look for data in ds_wincli_db
collections: command_centric_historic_stats
command_centric_daily_stats
Support Information
This feature is supported in single and multi-node environments on the EX4000 but not on the EX2000 single-node environment.
Detect Phishing
Note
To configure this feature, please contact your Technical Account Manager.
Advanced Analytics now detects users who visit suspected phishing websites. Phishing often starts with a domain name string that has the look-and-feel of a legitimate domain, but is not. Phishers target the Internet's most recognizable domain names (google.com, yahoo.com, etc.) and make slight changes on these domain names in order to fool unassuming eyes. Phishing detection uses lexical analysis to identify whether a domain is a variant of popular domain names. In addition, it also checks URLs against a white-list of popular legitimate domains and a blacklist of identified suspicious domains. It also uses substring searches to identify domains that contain the domain name of a popular site as a substring within the suspect domain. For example, www.gmail.com-hack.net
contains the recognizable "gmail.com" within the top level domain.
Associated Rules:
ID | Name | Description |
---|---|---|
WA-Phishing | Web activity to a phishing domain | Web activity to a suspected phishing domain has been detected. The domain is suspected as Phishing based on Exabeam data science algorithms. |
Configuration
Configuration should be made in /opt/exabeam/config/custom/custom_exabeam_config.conf
.
To enable Phishing Detection, set PhishingDetector.Enabled = true
.
Support Information
Supported in single and multi-node environments with EX2000 and EX4000.
Restart the Analytics Engine
Administrators typically need to restart the Analytics Engine when configuration changes are made to the system such as adding new log feeds to be analyzed by Exabeam or changing risk scores to an existing rule.
Exabeam will store time-based records in the database for recovery and granular reprocessing. The histograms and the processing state of the Exabeam Analytics Engine are time-stamped by week and stored in the database. This allows the Exabeam Analytics Engine to be able to go back to any week in the past and continue processing.
To illustrate, let's say that the Exabeam Analytics Engine started processing logs from January 1, 2016, and is currently processing today, April 15, 2016. The administrator would like to ingest new Cloud application log feeds into Exabeam and start reprocessing from a time in the past, say March 30, 2016. The administrator would stop the Exabeam Analytics Engine and then restart processing from March 30, 2016. The system will go back to find the weekly boundary where the state of the nodes and the models are consistent - which might mean a few days before March 30, 2016 - and start processing all the configured log feeds from that point in time.
Navigate to Settings > Admin Operations > Exabeam Engine.
Upon clicking Restart Processing, the Processing Feeds page appears. You can choose to:
Restart the engine from where it left off.
Restart and reprocess all the configured log feeds from the initial training period
Restart from a specific date. The Analytics Engine will choose the nearest snapshot available for the date chosen and reprocess from this date.
Note
Reprocessing can take a considerable amount of time depending on the volume of data that needs to be reprocessed.
Caution
Upon clicking Process, a success page loads. If you are reconfiguring a secondary appliance, DO NOT click Start Exabeam Engine on the success page. Rather, please contact your administrator.
Note
If a Log Ingestion Engine restart is required when you attempt to restart the Analytics Engine, you will be prompted with a dialog box to also restart the Log Ingestion Engine. Advanced Analytics will intelligently handle the coordination between the two Engines. The Log Ingestion Engine will restart from the same time period as the Analytics Engine. You can choose to cancel the restart if you would like the Log Ingestion Engine to finish its current process, but this will also cancel the Analytics Engine restart procedure.
If you have made configuration changes then the system will check for any inadvertent errors in the configuration files before performing the restart. If the custom configuration validation does identify errors in the config files then it will list the errors and not perform the restart. Otherwise, it will restart the analytics engine as usual.
Custom Configuration Validation
Hardware and Virtual Deployments Only
Any edits you make to your Exabeam custom configuration files are validated before you are able to restart the analytics engine to apply them to your system. This helps prevent Advanced Analytics system failures due to inadvertent errors introduced to the config files.
The system validates Human-Optimized Configuration Object Notation (HOCON) syntax, for example, missing a quotes or wrong caps ("SCOREMANAGER" instead of "ScoreManager"). The validation also checks for dependencies such as extended rules in custom config files that are missing dependencies within default config files. Some additional supported validation examples are:
Value validity and ranges
Operators
Brackets
Date formats
Rule expressions
Model dependencies
If found, errors are listed by file name during the analytics engine restart attempt.
From here you can fix the configuration errors, Cancel the modal, and retry the restart.
Only the config files related to Advanced Analytics are validated:
custom_exabeam_config.conf
(includes default config)cluster.conf
custom_lime_config.conf
event_builder.conf
models.conf
parsers.conf
(includes both default and custom)rule_labels.json
rules.conf
custom_event_categories.conf
In addition to helping you troubleshoot your custom config edits, Advanced Analytics also saves the last known working config files. Every time the system successfully restarts, a backup is made and stored for you.
The backups are collected and zipped in /opt/exabeam/config/backup
under custom_configuration_backups_martini
. All zipped files are named as follows custom_config_backup_<date>_<time>
with time in UTC server time. The last ten backups are stored, and the oldest copy is deleted to make room for a new backup.
You may choose to Roll Back to the latest backup if you run into configuration errors that you are unable to fix. If you do so the latest backup is restored and the analytics engine is not restarted.
Advanced Analytics Transaction Log and Configuration Backup and Restore
Hardware and Virtual Deployments Only
Rebuilding a failed worker node host (from a failed disk for on on-premise appliance) or shifting a worker node host to new resources (such as in AWS) takes significant planning. One of the more complex steps and most prone to error is migrating the configurations. Exabeam has provide a backup mechanism for layered data format (LDF) transaction log and configuration files to minimize the risk of error. To use the configuration backup and restore feature, you must have:
Amazon Web Services S3 storage or an active Advanced Analytics worker node
Cluster with two or more worker nodes
Have read and write permission for the credentials you will configure to access the base path at the storage destination
A scheduled task in Advanced Analytics to run backup to the storage destination
Note
To rebuild after a cluster failure, it is recommended that a cloud-based backups be used. To rebuild nodes from disk failures, backup files to a worker node or cloud-based destination.
Warning
Master nodes cannot be backed up and restored. Only worker nodes.
If you want to save the generate backup files to your first worker node, then no further configuration is needed to configure an external storage destination. A worker node destination addresses possible disk failure at the master node appliance. This is not recommended as the sole method for disaster recovery.
If you are storing your configurations at an AWS S3 location, you will need to define the target location before scheduling a backup.
Go to Settings > Additional Settings > Admin Operations > External Storage.
Click Add to register an AWS backup destination.
Fill all field and then click TEST CONNECTION to verify connection credentials.
Once a working connection is confirmed Successful, click SAVE.
Once you have a verified destination to store your files, configure and schedule a recurring backup.
Go to Settings > Additional Settings > Backup & Restore > Backups.
Click CREATE BACKUP to generate a new schedule record. If you are changing the destination, click the edit icon
on the displayed record.
Fill all fields and then click SAVE to apply the configuration.
Warning
Time is given in UTC.
A successful backup will place a backup.exa
file at either the base path of the AWS destination or /opt/exabeam/data/backup
at the worker node. In the case that the scheduled backup fails to write files to the destination, confirm there is enough space at the destination to hold the files and that the exabeam-web-common
service is running. (If exabeam-web-common
is not running, review its application.log
for hints as to the possible cause.)
In order to restore a node host using files store off-node, you must have:
administrator privileges to run tasks a the host
SSH access to the host
free space at the restoration partition at the master node host that is greater than 10 times the size of
backup.exa
backup file
Copy the backup file,
backup.exa
, from the backup location to the restoration partition. This should be a temporary work directory (<restore_path>
) at the master node.Run the following to unpack the EXA file and repopulate files.
sudo /opt/exabeam/bin/tools/exa-restore <restore_path>/backup.exa
exa-restore
will stop all services, restore files, and then start all services. Monitor the console output for error messages. See Troubleshooting a Restoration ifexa-restore
is unable to run to completion.Remove
backup.exa
and the temporary work directory when restoration is completed.
If restoration does not succeed, the try following below solutions. If the scenarios listed do not match your situation,
Not Enough Disk Space
Select a different partition to restore the configuration files to and try to restore again. Otherwise, review files stored in to target destination and offload files to create more space.
Restore Script Cannot Stop All Services
Use the following to manually stop all services:
source /opt/exabeam/bin/shell-environment.bash && everything-stop
Restore Script Cannot Start All Services
Use the following to manually start all services:
source /opt/exabeam/bin/shell-environment.bash && everything-start
Restore Script Could Not Restore a Particular File
Use tar
to manually restore the file:
# Determine the task ID and base directory (<base_dir>) for the file restoration that failed. # Go to the <base_id>/<task_id> directory and apply following command: sudo tar -xzpvf backup.tar backup.tgz -C <baseDir> # Manually start all services. source /opt/exabeam/bin/shell-environment.bash && everything-start
Reprocess Jobs
Access the Reprocessing Jobs tab to 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.

If you wish to cancel a reprocessing job for any reason, select the job in the Reprocessing Jobs table and then click Cancel Job.
Configure Notifications About Reprocessing Job Status Changes
You can configure email and Syslog notifications for certain reprocessing job status changes, including start, end, and failure.
To configure notifications for reprocessing job status changes:
Navigate to Settings > Log Management > Incident Notification.
Select an existing notification or create a new notification. You can choose either Syslog or email.
Select the reprocessing jobs notifications according to your business needs (Job status changes and/or Job failures).
Save your changes.
Re-Assign to a New IP (Appliance Only)
Hardware Deployments Only
Note
These instructions apply to Exabeam appliances only. For instructions on re-assigning IPs in virtual deployments, please contact Exabeam Customer Success by opening a case at Exabeam Community.
Set up a named session to connect to the host. This will allow the process to continue in the event you lose connection to the host.
screen -LS [session_name]
Enter the cluster configuration menu.
source /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
From the list of options, choose
Change network settings.
Choose
Change IP of cluster hosts
.Choose
Change IP(s) of the cluster - Part I (Before changing IP)
.You will go through a clean up of any previous Exabeam installations.
Do you want to continue with uninstalling the product? [y/n] y
Acknowledge the Exabeam requisites.
********************************************************************** Part I completed. Nuke successful. Product has been uninstalled. ***Important*** Before running Part II, please perform these next steps below (Not optional!): - Step 1 (Manual): Update the IPs (using nmtui or tool of choice) - Step 2 (Manual): Restart network (e.g., systemctl restart network) ********************************************************************** Please enter 'y' if you have read and understood the next steps: [y/n] y
Open the
nmtui
to change IP addresses of each host in the cluster where the IP address will be changed.sudo nmtui
Go to Edit Connection and then select the network interface.
The example below shows the menu for the network hardware device
eno1
. Go to ETHERNET > IPv4 CONFIGURATION.Warning
Please apply the correct subnet CIDR block when entering
[ip]/[subnet]
. Otherwise, network routing will fail or produce unforeseen circumstances.Set the configuration to MANUAL, and then modify the IP address in Addresses.
Click OK to save changes and exit the menu.
Restart the network services.
sudo systemctl restart network
Enter the cluster configuration menu again.
/opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Choose
Change network settings.
Choose
Change IP of cluster hosts.
Choose
Change IP(s) of the cluster - Part II (Before changing IP)
Acknowledge the Exabeam requisites.
********************************************************************** Please make sure you have completed all the items listed below: - Complete Part I successfully (nuke/uninstall product) - (Manual) Update the IPs (using nmtui or tool of choice) - (Manual) Restart network (e.g., systemctl restart network) ********************************************************************** Do you want to continue with Part II? [y/n] y
Provide the new IP of the host.
What is the new IP address of [hostname]? (Previous address was 10.70.0.14)[new_host_ip]
Update your DNS and NTP server information, if they have changed. Otherwise, answer
n
.Do you want to update your DNS server(s)? [y/n] n Do you want to update your NTP server? [y/n] n
Hadoop Distributed File System (HDFS) Namenode Storage Redundancy
There is a safeguard in place for the HDFS NameNode (master node), storage to prevent data loss in the case of data corruption. Redundancy is automatically set up for you when you install or upgrade Advanced Analytics and include at least three nodes.
Note
Deployments may take longer if redundancy is enabled.
These nodes can include the common LIME and master node in the EX2003 appliance (excluding single-node deployments), or the standalone/dedicated LIME and Master Node in the EX4003. The Incident Responder node does not factor into the node count.
Redundancy requires two NameNodes that are both operating at all times. The second NameNode is always on the next available Advanced Analytics host, which in most cases is the first worker node. It constantly replicates the primary NameNode.
With this feature enabled in the case of the Master NameNode failing the system can still move forward without data loss. In such cases, you can use this redundancy to fix the state of Hadoop (such as installing a new SSD if there was an SSD failure) and successfully restart it.
Note
Disaster recovery deployments mirror the NameNode duplicated environment.
User Engagement Analytics Policy
Exabeam uses user engagement analytics to provide in-app walkthroughs and anonymously analyze user behavior, such as page views and clicks in the UI. This data informs user research and improves the overall user experience of the Exabeam Security Management Platform (SMP). Our user engagement analytics sends usage data from the web browser of the user to a cloud-based service called Pendo.
There are three types of data that our user engagement analytics receives from the web browser of the user. This data is sent to a cloud-based service called Pendo:
Metadata – User and account information that is explicitly provided when a user logs in to the Exabeam SMP, such as:
User ID or user email
Account name
IP address
Browser name and version
Page Load Data – Information on pages as users navigate to various parts of the Exabeam SMP, such as root paths of URLs and page titles.
UI Interactions Data – Information on how users interact with the Exabeam SMP, such as:
Clicking the Search button
Clicking inside a text box
Tabbing into a text box
Opt Out of User Engagement Analytics
Note
For customers with a Federal license, we disable user engagement analytics by default.
To prevent Exabeam SMP from sending your data to our user analytics:
Access the config file at
/opt/exabeam/config/common/web/custom/application.conf
Add the following code snippet to the file:
webcommon { app.tracker { appTrackerEnabled = false apiKey = "" } }
Run the following command to restart Web Common and apply the changes:
. /opt/exabeam/bin/shell-environment.bash web-common-restart
Set Up Rules Administration
Administrators are able to create and modify rules from within the Advanced Analytics UI in order to meet their needs. From the Rules Administration page, Administrators can:
View all the rules configured in the system, arranged categorically.
Change the risk scores for a rule.
Edit an existing Exabeam Rule. This will overwrite Exabeam's original rule of the same name with the option to 'Revert to Default', which negates any changes made.
Create a new fact-based rule.
Clone any existing Exabeam Rule. After cloning, an administrator can edit the cloned rule and save. Cloning preserves the original rule.
Disable any rule.
Reload the rules. New rules or changes made to existing rules will not take effect until the rules are reloaded.
Note
Modified or newly added rules that need to be reloaded are highlighted with an orange triangle.
All Rules: A comprehensive list of all rules existing in Advanced Analytics's system.
Exabeam Rules: These are all of the out-of-the-box Exabeam rules.
Custom Rules: All rules that have been created, cloned, or edited and saved by an administrator.
Disabled Rules: All the rules that have been disabled and are not being triggered.
Expanding a category will list all the rules in that category and offer more details about each rule.
The icon to the left of the rule indicates that the rule has been edited by an administrator.
The Rule Name and Description are displayed.
The Trigger Frequency is a measure of how often the rule has been flagged in User Sessions.
The Risk Level indicates the number of points that are allocated to a User Session when the rule is triggered.
Selecting the vertical ellipsis to the right offers four options:
Disable - Disables the rule. The rule will not trigger. This option will read 'Enable' for a rule that has already been disabled.
Advanced Editor - Launches the JSON style Advanced Editor.
Clone - This option makes a copy of the rule. You can save the copy under a new name and edit the new rule in the Advanced Editor.
Revert to Default - This option only appears for rules that have been edited by an administrator. Selecting this option clears all changes that have been made to the rule and restore it to the default settings.
What Is an Exabeam Rule?
So what exactly is a rule anyway? There are two types of Exabeam rules:
Model-based
Fact-based
Model-based rules rely on a model to determine if the rule should be applied to an event in a session, while fact based rules do not.
For example, a Fireye malware alert is fact based and does not require a model in order to be triggered. On the other hand, a rule such as an abnormal volume of data moved to USB is a Model-based rule.
Model-based rules rely on the information modeled in a histogram to determine anomalous activities. A rule is triggered if an event is concluded to be anomalous, and points are allocated towards the user session in which the event occurred. Each individual rule determines the criticality of the event and allocates the relevant number of points to the session associated with that event.
Taken together, the sum of scores from the applied rules is the score for the session. An example of a high-scoring event is the first login to a critical system by a specific user – which allocates a score of 40 to a user’s session. Confidence in the model must be above a certain percentage for the information to be used by a rule. This percentage is set in each rule, though most use 80%. When there is enough reliable information for the confidence to be 80% or higher, this is called convergence. If convergence is not reached, the rule cannot be triggered for the event.
How Exabeam Models Work
Since anomaly-based rules depend on models, it is helpful to have a basic understanding of how Exabeam's models work.
Our anomaly detection relies on statistical profiling of network entity behavior. Our statistical profiling is not only about user-level data. In fact, Exabeam profiles all network entities, including hosts and machines, and this extends to applications or processes, as data permits. The statistical profiling is histogram frequency based. To perform the histogram-based profiling, which requires discrete input, we incorporate a variety of methods to transform and to condition the data. Probability distributions are modeled using histograms, which are graphical representations of data. There are three different model types – categorical, numerical clustered, and numerical time-of-week.
Categorical is the most common. It models a string with significance: number, host name, username, etc. Where numbers fall into specific categories which cannot be quantified. When you model which host a user logs into, it is a categorical model.
Numerical Clustered involves numbers that have meaning – it builds clusters around a user’s common activities so you can easily see when the user deviates from this norm. For example, you can model how many hosts a user normally accesses in a session.
Numerical Time-of-Week models when users log into their machines in a 24-hour period. It models time as a cycle so that the beginning and end of the period are close together, rather than far apart. For example, if a user logs into a machine Sunday at 11:00 pm, it is closely modeled to Monday at 12:00am.
Model Aging
Over time, models built in your deployment naturally become outdated. For example, if an employee moves to a different department or accepts a promotion and they do not adhere to the same routines, access points, or other historical regularities.
We automatically clean up and rebuild all models on a regular basis (default is every 16 weeks) to ensure your models are as accurate and up-to-date as possible. This process also enhances system performance by cleaning out unused or underutilized models.
Rule Naming Convention
Exabeam has an internal Rule ID naming convention that is outlined below. This system is used for Exabeam created rules and models only. When a rule is created or cloned by a customer, the system will automatically create a Rule ID for the new rule that consists of customer-created
, followed by a random hash. For example, a new rule could be called, customer-created-4Ef3DDYQsQ {
.
The Exabeam convention for model and rule names is: ET-SF-A/F-Z
ET: The event types that the model or rule addresses. For example,
RA = remote-access
NKL = NTLM/Kerberos-logon
RL = remote-logon
SF: Scope and Feature of the model. For example,
HU = Scope=Host, Feature=User
OZ = Scope=Organization, Feature=Zone
A/F: For rules only
A = Abnormal
F = First
Z : Additional Information (Optional). For example,
DC: Domain Controller models/rules
CS: Critical Systems
Reprocess Rules
When adding new or managing existing Exabeam rule on the Exabeam Rules page, you can choose to reload individual or all rules. You can choose to reload and apply rule changes from the current point in time, or 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.
You can view the status of pending, in-progress, completed, canceled, and failed jobs at any time by navigating to Settings > Admin Operations > Exabeam Engine > Reprocessing Jobs. For more information on reprocessing, please see the section Reprocess Jobs.
Create Fact Based Rules Using the Simple Editor
The Simple Editor allows an administrator to create fact based rules. A fact based rule is one that does not rely on a model in order to trigger. See Exabeam Rules and the How Exabeam Models Work sections in this document for more information on the difference between fact based and model based rules.
Access the Simple Editor by navigating to Settings > Admin Operations > Exabeam Rules and clicking the + button.
After an administrator creates a rule, the rule is validated during the save operation.
Rule Category – Defines which category the rule falls under. For example, VPN Activity, Critical System Activity, etc.
Name – When the rule is triggered, this is the name displayed in the Advanced Analytics UI during the user session. We recommend using descriptive rule names to indicate the nature of the risky behavior; for example, Data Exfiltration by a Flight Risk User.
Description – The rule description provides additional details to help analysts investigate. Defining the why of the rule as well as the what helps analysts interpret the results of User Sessions more easily.
Events – Select the event types that the rule will depend on. For example, if your rule is evaluating user logins then the log types should reflect all the different login events that you want analyzed.
Risk Level – The risk level reflects the risk score that will be added to a User Session if the rule is triggered.
Rule Expression – This is the boolean expression that the rule engine uses to determine if a particular rule will trigger. This means that your rule will only trigger if all of the conditions described in the Rule Expression are met.
Rule Dependency – This is the only field in the Simple Editor that is optional. The Rule Dependency defines another rule (identified by the Rule ID) that your rule is dependent upon. When Rule A depends on Rule E, then Rule A will only trigger if Rule E is evaluated to true.
Example of Using the Simple Editor
We want to create a new fact-based rule: add 15 extra risk points to the sessions of users HR considers to be a flight risk. We have already added a context file titled ‘Flight Risk’ that contains the IDs of those users. We want our rule to trigger every time a User with the user label ‘Flight Risk’ starts a session.
We want the name and description of our rule to reflect its purpose.
Name – Flight Risks
Description – Users that HR considers to be flight risks.
We then want to select all of the events that this rule will analyze and how many points are added to a user session if this rule triggers.
Event Types – remote-access, remote-logon, local-logon, kerberos-logon, ntlm-logon, account-switch, app-logon, app-activity, privileged-object-access
Risk Level – Critical (15)
We then want to build a Rule Expression - this is the boolean expression that the rule engine uses to determine if a particular rule will trigger. This means that your rule will only trigger if all of the conditions described in the Rule Expression are met.
Our Field is User and the property of the user field that we want is User Label. In this case, a rule has to be triggered when the value of the user label is Flight Risk. Note that the label in the context lookup table for the Flight Risk users should match this value.
Click Done with Expression and we've created a rule expression for a rule that will trigger whenever the term Flight Risk is found in the user_label field.
Returning back to the Create a Rule page, we want our rule to trigger once per session and it does not depend on another rule triggering.
Click Save & Reload All. This saves the rule and reloads the rule file; rules need to be reloaded into the Exabeam Engine to have the changes be effective.
Edit Rules Using the Advanced Editor
The Advanced Editor is a JSON style editor and is what an administrator would use if they wanted to edit one of Exabeam's existing rules, or edit a cloned rule. All of Exabeam's out-of-the-box rules can be edited only via the Advanced Editor.
Note
Be careful here, these settings are for very advanced users only. Changes you make here can have a significant impact on the Exabeam Analytics Engine. The Advanced Editor allows administrators and advanced analysts to make changes to Exabeam rules in a JSON style configuration format. This should be used by administrators that have the expertise to create or tweak a machine learning rule and understand the syntax language for expressing a rule. In case of questions, reach out to Exabeam Customer Success for guidance.
This editor shows the entire rule as it exists in the configuration file. The Rule ID is the only field that cannot be changed. See the Rule Naming Convention section in this document for more information about Exabeam's naming convention. When an administrator makes any changes to a rule, the rule is validated during the save operation. If the rule has incorrect syntax, the administrator is prompted with the error and the details of the error. Once a rule is edited and saved using the Advanced Editor, the rule cannot be viewed via the Simple Editor.
Fields in the Advanced Editor
Glossary
ClassifyIf
This expression is similar to the
TrainIf
field in the model template. It evaluates to true if classification needs to be performed for a given event. In other words, how many times this rule should trigger.DependencyExpression
This field defines a Boolean expression of other rule IDs. When rule A depends on expression E, A will only trigger if its parameters satisfy the RuleExpression, and E is evaluated to true after the rule IDs are substituted with their rule evaluation result.When an administrator makes any changes to a rule, the rule is validated during the save operation. If the rule is not syntactically well formed, the administrator is prompted with the error and the details of the error.
Disabled
This field will read either True or False. Set to True to deactivate the rule and all associated modelling.
FactFeatureName
he name of a feature used for fact based rules. For model-based rules the FactFeatureName is defined in the associated model.
Model
The name of the model that this rule references. If this rule is fact-based, then the model name is FACT.
PercentileThreshold
This value indicates which observations are considered anomalous based on the histogram. For example, a value of 0.1 indicates a percentile threshold of 10%. This goes back to the histogram and means that for the purposes of this rule we only consider events that appear below the 10th percentile to be abnormal. Note that many rules distinguish between the first time an event occurs and when that event has happened before, but is still abnormal. These two occurrences often appear as two separate rules because we want to assign two different scores to them.
ReasonTemplate
This appears in the UI and is to facilitate cross-examination by users. The items between braces represent type and value for an element to be displayed. The type helps define what happens when the user clicks on the hyperlink in the UI.
Rule ID
Unique identifier for this rule. The name in our example is NKL-UH-F. Exabeam has a naming convention for both models and rules that is outlined in the section titled Naming Convention. When editing or cloning an existing rule you cannot change the Rule ID.
RuleDescription
This is used in the UI to describe the reason why a particular rule triggered.
RuleEventTypes
This collection defines what events we are considering in this rule. It can be the same events that the model considers, but does not have to be. Sometimes you may want to model on one parameter but trigger on another.
RuleExpression
This is the boolean expression that the rule engine uses to determine if a particular rule will trigger. Your rule will only trigger if all of the conditions described in the Rule Expression are met. You can use probability or number of observations (
num_observations)
to determine how many times this event has been seen before. When either is set to zero it is a way to see when something happens that has not happened before. Theconfidence_factor
refers to a concept called convergence. In order for the rule to use the information gathered by the model, we must be confident in that information. A percentage is set in each Confidence in the model must be above a certain percentage for the information to be used by a rule. This percentage is set in each rule, though most use 80%. When there is enough reliable information for the confidence to be 80% or higher, this is called convergence. If convergence is not reached, the rule cannot be triggered for the event.RuleName
Descriptive name for the rule. Used for documentation purposes.
RuleType
This appears in the UI and is to facilitate cross-examination by users. The items between braces represent type and value for an element to be displayed. The type helps define what happens when the user clicks on the hyperlink in the UI.
Score
This is the score that will be assigned to a session when this rule triggers. Higher scores mean a higher level of risk from the security perspective.
Exabeam Threat Intelligence Service
The Exabeam Threat Intelligence Service delivers a constant stream of up-to-date threat indicators to Advanced Analytics deployments.
The categories of indicators affected are the following:
• IP addresses associated with Ransomware or Malware attacks
• IP addresses associated with the TOR network
• Domain names associated with Ransomware, Phishing, or Malware attacks
Indicators are downloaded by the on premise products from Threat Intelligence Service on a daily basis.
![]() |
Advanced Analytics and Data Lake connect to Threat Intelligence Service through a cloud connector service that provides authentication and establishes a secure connection to Threat Intelligence Service. The cloud connector service then collects updated threat indicators from Threat Intelligence Service daily.
These indicators are then made available within Advanced Analytics to provide enhanced risk scoring based on curated threat intelligence.
This product does not require a separate license. It is bundled with Advanced Analytics deployments. Additional installation or configuration is not required.
If you would like to learn more, contact your technical account manager or watch product videos via the Exabeam Community.
Threat Intelligence Service Prerequisites
Before configuring Threat Intelligence Service, ensure your deployment meets the following prerequisites:
At least 5 Mbps Internet connection
Access to https://api.cloud.exabeam.com over HTTPS port 443
Note
Ensure dynamic access is enabled as the IP address may change. Also, for this reason, firewall rules for static IP and port addresses are not supported.
DNS resolution for Internet hostnames (this will only be used to resolve to https://api.cloud.exabeam.com)
Connect to Threat Intelligence Service through a Proxy
The communication between Threat Intelligence Service and Advanced Analytics occurs over a secure HTTPS connection.
If connections from your organization do not make use of a web proxy server, you may skip this section. Threat Intelligence Service is available automatically and does not require additional configuration.
If connections from your organization are required to go through a web proxy server to access the Internet, you will need to provide the configuration as shown below.
Note
Configuration is required for each of your Advanced AnalyticsData Lake deployments.
Warning
If your proxy performs SSL Interception, it will replace the SSL certificate from the Exabeam Threat Intel Service (ETIS) with an unknown certificate during the SSL negotiation, which will cause the connection to ETIS to fail. If possible, please disable SSL Interception for the IP address of your Exabeam products. If this cannot be disabled, please contact Exabeam Customer Success for further assistance.
Before configuring Threat Intelligence Service, ensure your deployment meets the following prerequisites:
At least 5 Mbps Internet connection
Access to https://api.cloud.exabeam.com over HTTPS port 443
Note
Ensure dynamic access is enabled as the IP address may change. Also, for this reason, firewall rules for static IP and port addresses are not supported.
DNS resolution for Internet hostnames (this will only be used to resolve to https://api.cloud.exabeam.com)
Establish a CLI session with the master node of your Exabeam deployment.
Open the custom file
/opt/exabeam/config/common/cloud-connection-service/custom/application.conf
Add the following section to the custom file and configure the parameters
proxyHost
,proxyPort
,proxyUsername
, andproxyPassword
.Note
Be sure to choose the appropriate settings based on whether the proxy utilizes http or https. Additionally, always use quoted strings for
proxyHost
,proxyProtocol
,proxyUsername
, andproxyPassword
.HTTP:
HTTPS:
Stop and then restart the cloud connector service in your product:
source /opt/exabeam/bin/shell-environment.bash
cloud-connection-service-stop
cloud-connection-service-start
Note
Important Note: The username and password values are hashed in Data Lake i24 and later. After Cloud Connection Service (CCS) is restarted (step 4), the username and password are hashed using a 128 bit AES key, and these hashed values are stored in the local secrets store. In the config file, the username and password values are replaced by the hashed values.
If you want to subsequently change the values again, you can do so by replacing the hashed values by new plain text values and restart the CCS service.
As soon as the deployment can successfully connect to Threat Intelligence Service, threat intelligence feed data is pulled and saved as context tables and is also viewable on the Threat Intelligence Feeds settings page.
View and Manage Threat Intelligence Feeds
To view threat intelligence feeds, navigate to Settings > Cloud Config > Threat Intelligence Feeds.
![]() |
The page displays details related to all threat intelligence feeds provided by the cloud-based Exabeam Threat Intelligence service, such as:
The type of the feed (for example, domain list, IP list, etc.)
The name of the feed (as given by the cloud-based service)
A short description of the feed
The status indicating the availability of the feeds in the cloud-based service
The time of last update from the cloud service
Note
Data provided by the threat intelligence feeds can be accessed in Context tables (see section on Viewing Threat Intelligence Service Context Tables). The initial service feeds are associated with existing context tables by default. This means that as soon as your deployment is connected to the cloud-based Threat Intelligence Service service, your deployment will start collecting threat intelligence data.
If you want to collect data from some of the threads in other context tables, see the next section on Assigning a Threat Intelligence Feed to a New Context Table.
Associated context tables
![]() |
Assign Threat Intelligence Feed to a New Context Table
Some of the feeds are pre-assigned to context tables. Click the arrow of a threat intelligence feed to expand and view additional details, including:
ID
Source URL
Indicator in Context Tables
Retrieved from Source
Feed Indicator Sample
Context Table(s)
![]() |
Click the edit icon of a single threat intelligence feed to assign or unassign it to one or more context tables.
Note
You cannot unassign default context table mappings.
Click the view icon to view existing indicators in the context table.
![]() |
Select multiple threat intelligence feeds to bulk assign or unassign them from context tables.
![]() |
Create a New Context Table from a Threat Intelligence Feed
To create a new context table from one or more threat intelligence feeds:
Navigate to Settings > Cloud Config > Threat Intelligence Feeds.
Edit a threat intelligence feed.
To create a new context table from a single feed, click the edit
icon of the single feed.
To create a new context table from multiple feeds, select the feeds and then click Assign.
Click + Add Context Table.
Configure the context table fields, including title, object type (users assets, miscellaneous), and type (key value or key only).
Click ADD.
View Threat Intelligence Service Context Tables
To view the current context tables provided by Threat Intelligence Service:
Log in to your instance of the UI.
Navigate to Settings > Accounts & Groups > Context TablesSettings > Context Management > Context Tables.
Select one of the context tables listed above. For example, web_phishing (shown below).
On the context table details page, view the keys and values currently associated with the context table.
Check ExaCloud Connector Service Health Status
To view the current status of the ExaCloud connector service:
Log in to your instance of the UI.
Click the top-right menu icon and select System Health.
Select the Health Checks tab.
Click Run Checks.
Expand the Service Availability section, and then review the ExaCloud connection service availability icon.
The service availability icon shows the current health of the Cloud connector service that is deployed on your Exabeam product.
Green – The cloud connector service is healthy and running on your on-prem deployment.
Note
The green icon does not specifically indicate the cloud connector is connecting to the cloud and pulling Threat Intelligence Service data. It only indicates the cloud connector service is up and running.
Red – The cloud connector service has failed. Please contact Exabeam Customer Success by opening a case via Community.Exabeam.com.
Exabeam Cloud Telemetry Service
Exabeam telemetry service provides valuable quality and health metrics to Exabeam. System events, metrics, and environment health data are collected and sent to Exabeam Cloud, enabling insight into system issues, such as processing downtime (such as processing delays and storage issues) and UI/application availability.
Learn about the different types of telemetry data, possible telemetry data, and disabling this feature.
Note
If you do not wish to send any data to the Exabeam Cloud, please follow the opt-out instructions listed in the How to Disable Exabeam Cloud Telemetry Service.
Prerequisites
For Exabeam to successfully collect telemetry data, please ensure the following prerequisites are met:
Advanced Analytics I48.4 or later with a valid license
Data Lake I32 or later with a valid license
Access to *.cloud.exabeam.com over HTTPS port 443.
Types of Telemetry Data in Exabeam Cloud Telemetry Service
At a high level, telemetry data falls into one of three categories:
Metrics (for example, CPU, events-per-second, and processing delay)
Events (for example, machine restart, user login, and configuration changes)
Environment (for example, versions, products, nodes, and configuration)
IP addresses and hostnames are masked before being sent to Exabeam Cloud. For example, {"host": "*.*.0.24"}
.
Metrics
The example below shows the metrics data sent from the master node to the telemetry service in Exabeam Cloud:
Note
The example below is only a partial example and does not show the full payload.
{ "metrics": [ {"points":[[1558614965, 0.29]], "name": "tm.plt.service_cpu.exabeam-web-common-host1"}, {"points": [[1558614965, 0.3457]], "name": "tm.plt.service_memory.exabeam-web-common-host1"}, {"points": [[1558614965, 0.77]], "name": "tm.plt.service_cpu.mongodb-shard-host1"}, {"points": [[1558614965, 0.04947]], "name": "tm.plt.service_memory.mongodb-shard-host1"} ] }
Events
The example below shows the events data sent from the master node to the telemetry service in Exabeam Cloud:
Note
The example below is only a partial example and does not show the full payload.
{ "events": [ "dateHappened": 1558614965, "title": "Device /dev/shm S.M.A.R.T health check: FAIL", "text": "S.M.A.R.T non-compatible device" ] }
Environment
The example below shows the environment data sent from the master node to the telemetry service in Exabeam Cloud:
Note
The example below is only a partial example and does not show the full payload.
{"environment": { "versions": { "uba": { "build": "4", "branch": "I46.2"}, "common": { "build": "7", "branch": "PLT-i12.5"}, "exa_security": { "build": "33", "branch": "c180815.1"} }, "hosts": { "host3": { "host": "*.*.0.24","roles": ["oar","cm"]}, "host2": {"host": "*.*.0.72","roles": ["uba_slave"]}, "host1": {"host": "*.*.0.70","roles": ["uba_master"]} }, "licenseInfo": { "customer": "EXA-1234567", "gracePeriod": 60, "expiryDate": "10-11-2021", "version": "3", "products": ["User Analytics","Entity Analytics"], "uploadedAt": 1557740839325 } }
Data Collected by Exabeam Cloud Telemetry Service
Exabeam telemetry service provides valuable quality and health metrics to Exabeam. System events, metrics, and environment health data are collected and sent to Exabeam Cloud, enabling insight into system issues, such as processing downtime (such as processing delays and storage issues) and UI/application availability. The table below lists the possible metrics, events, and environment telemetry data.
Note
You can also view a full list of product metrics and events sent to the Exabeam cloud (including when the requests were made and the full payload) by accessing the audit log file located at /opt/exabeam/data/logs/common/cloud-connection-service/telemetry.log
.
Environment | ||
---|---|---|
Name | Description | Frequency |
Inventory | Nodes, masked IPs, and roles of each node. | Once a day |
Product Version | Versions of each product in your deployment. | Once a day |
License information | License information for each product in your deployment. | Once a day |
Metrics for Advanced Analytics | ||
---|---|---|
Name | Description | Frequency |
tm.aa.processing_delay_sec | An Advanced Analytics processing delay (if applicable) in seconds. | 5 mins |
tm.plt.service_status.<service-name> | Per-service status. | 5 min |
tm.plt.ssh_logins | Number of SSH logins. | 5 min |
tm.plt.service_memory.<service-name> | Per-service memory. | 5 min |
tm.plt.service_cpu.<service-name> | Per-service CPU. | 5 min |
tm.plt.load_avg_1m tm.plt.load_avg_5m tm.plt.load_avg_10m | Load average (CPU) per 1-minute, 5-minute, and 10-minute period. | 5 min |
tm.aa.compressed_logs_bytes | Log volume of the last hour. | 1 hour |
tm.aa.compressed_events_bytes | Events volume of the last hour. | 1 hour |
tm.aa.notable_users | Notable users. | 5 min |
tm.plt.disk_usage.mongo tm.plt.disk_usage.data tm.plt.disk_usage.root | Disk usage per partition. | 5 min |
tm.plt.total_users | Total users. | 1 hour |
tm.plt.total_assets | Total assets. | 1 hour |
Metrics for Data Lake | ||
---|---|---|
Name | Description | Frequency |
tm.plt.service_status.<service-name> | Per-service status. | 5 min |
tm.plt.ssh_logins | Number of SSH logins. | 5 min |
tm.plt.service_memory.<service-name> | Per-service memory. | 5 min |
tm.plt.service_cpu.<service-name> | Per-service CPU. | 5 min |
tm.plt.load_avg_1m tm.plt.load_avg_5m tm.plt.load_avg_10m | Load average (CPU) broken per 1-minute, 5-minute, and 10-minute period. | 5 min |
tm.plt.disk_usage.mongo tm.plt.disk_usage.data tm.plt.disk_usage.root tm.plt.disk_usage.es_hot tm.plt.disk_usage.kafka | Disk usage per partition. | 5 min |
tm.plt.total_users | Total users. | 1 hour |
tm.plt.total_assets | Total assets. | 1 hour |
tm.dl.es.cluster_status tm.dl.es.number_of_nodes tm.dl.es.number_of_data_nodes tm.dl.es.active_shards tm.dl.es.active_primary_shards | Elasticsearch cluster status. | 5 min |
tm.dl.kafka.total_lag | A Kafka delay if detected. | 5 min |
tm.dl.kafka.connectors_lag | A Kafka connector lag if detected. | 5 min |
tm.dl.avg_doc_size_bytes | Average document size. | 15 min |
tm.dl.avg_msg_size_bytes | Average message size. | 5 min |
tm.dl.index_delay | Index delay if detected. | 5 min |
tm.dl.connectors_send_rate_bytes | Total connector ingestion rate in bytes. | 5 min |
tm.dl.ingestion_queue | Kafka topic delay if detected. | 5 min |
tm.dl.indexing_rate | Average indexing rate. | 5 min |
tm.dl.shards_today | Elasticsearch shards today. | 5 min |
tm.dl.shards_total | Elasticsearch shards total. | 5 min |
How to Disable Exabeam Cloud Telemetry Service
Hardware and Virtual Deployments Only
Cloud Telemetry Service will be enabled by default, following the installation of the relevant product versions. Exabeam highly recommends to connect to the Telemetry Service, in order to enjoy the benefits of future enhancements that will be built using this data.
If you do not wish to send any data to the Exabeam Cloud, the steps required vary depending on your deployment scenario:
Product Upgrade or Patch Installation
Product Installation
Any time after Product Upgrade
Disabling Telemetry Before Product Upgrade or Patch Installation
To disable the hosting of telemetry data in the Exabeam Cloud before upgrading your Exabeam product(s):
Access the Cloud Connection Service (CCS) configuration files at:
/opt/exabeam/config/common/cloud-connection-service/custom/application.conf
Add a new line:
cloud.plugin.Telemetry.enabled = false
Perform the upgrade steps described in the Upgrade an On-Premises or Cloud Exabeam Product section.
Disabling Telemetry During a Product Installation
To disable the hosting of telemetry data in the Exabeam Cloud while installing your Exabeam product(s):
Perform the installation steps described in the product installation section, but do not upload the product license. You will upload the product license later in this process.
Access the Cloud Connection Service (CCS) configuration files at:
/opt/exabeam/config/common/cloud-connection-service/custom/application.conf
Add a new line:
cloud.plugin.Telemetry.enabled = false
Restart CCS by running the following command:
. /opt/exabeam/bin/shell-environment.bash cloud-connection-service-stop && cloud-connection-service-start
Upload the product license by following the steps provided in the Download an On-premises or Cloud Exabeam License and ??? sections.
Disabling Telemetry After Product Upgrade
To disable the hosting of telemetry data in the Exabeam Cloud after upgrading your Exabeam product(s):
Access the Cloud Connection Service (CCS) configuration files at:
/opt/exabeam/config/common/cloud-connection-service/custom/application.conf
Add a new line:
cloud.plugin.Telemetry.enabled = false
Restart CCS by running the following command:
. /opt/exabeam/bin/shell-environment.bash cloud-connection-service-stop && cloud-connection-service-start
Disaster Recovery (Advanced Analytics, Case Manager, and Incident Responder)
Hardware and Virtual Deployments Only
In a disaster recovery scenario, Advanced Analytics content is replicated continuously from the active site to the passive site, including:
Logs/Events – The active cluster fetches logs from SIEM and/or receiving the logs via Syslog. Once the logs are parsed, the events are replicated to the passive cluster.
Configuration – Changes to configuration such as configuring new log feeds, parsers, LDAP server, roles and Exabeam users, models and rules are replicated from the active to the standby cluster. This includes files as well as the relevant database collections (for example, EDS configuration, users and roles are in database).
Context – Contextual data such as users, assets, service accounts, peer groups, etc.
User Generated Data – Comments, approved sessions, Watchlists, starred sessions, saved searches, and whitelists stored in the Mongo database.
Note
You can also configure your Advanced Analytics deployment to replicate only specific file types across clusters.
If you have Case Manager or a combined Case Manager and Incident Responder license, the disaster recovery system replicates:
Incidents and incident details (entities, artifacts, comments, etc.)
Custom incident filters and searches.
Roles and permissions.
Playbooks and actions (including history and saved results of previous actions)
Configurations (for example, alert sources, alert feeds, notification settings, incident message and email settings), phases and tasks, integrated services (for example, parsers and alert rules).
Deploy Disaster Recovery
Hardware and Virtual Deployments Only
Warning
You can only perform this configuration with the assistance of Exabeam Customer Success Engineer.
The two-cluster scenario employs an Active-Passive Disaster Recovery architecture with asynchronous replication.
With this approach, you maintain an active and secondary set of Advanced Analytics (and additional Case Manager and Incident Responder) clusters in separate locations. In cases of a failure at the active site, you can fail over to the passive site.
At a high level, when Disaster Recovery is set up between two Advanced Analytics clusters, the active cluster is responsible for fetching the logs from SIEM or receiving the logs via Syslog. Once the logs have been parsed into events, the events are replicated from the active cluster to the passive cluster every five minutes.
Optionally, the raw logs can be replicated from the active to the passive cluster. (This allows reprocessing of logs, if needed. However, replication will generate great bandwidth demands between nodes.) If the active cluster goes down, then the passive cluster becomes the active until such time as the downed site is recovered.
![]() |
Prerequisites
Open port TCP 10022 (bi-directional)
IP addresses of both the primary and secondary clusters
SSH key to access the primary cluster
At least 200 megabits per second connection between primary and secondary clusters
The active and passive clusters must have the exact same number of nodes in the same formation. For example, if the second and third nodes on the primary cluster are worker nodes, the second and third nodes on the passive cluster must also be worker nodes. If the fifth node on the primary cluster is a Case Manager node, the fifth cluster on the passive cluster must also be a Case Manager node.
Deployment
This process requires you to setup disaster recovery first on the active cluster (primary node) and then on the passive cluster (secondary site).
Note
If you have already set up disaster recovery for Advanced Analytics and are adding disaster recovery for Incident Responder, please see Adding Case Manager & Incident Responder Disaster Recovery to Existing Advanced Analytics Disaster Recovery.
Active Cluster Setup
On the active site, run the following:
screen -LS dr_setup /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select option: "Configure disaster recovery".
Select the option: "This cluster is source cluster (usually the primary)"
Please select the type of cluster: 1) This cluster is source cluster (usually the primary) 2) This cluster is destination cluster (usually the dr node) 3) This cluster is for file replication (configuration change needed)
Please wait for the cluster setup to successfully complete before proceeding to the next section.
Passive Cluster Setup
Copy onto the passive cluster master the SSH key that allows access to the active cluster. (Skip this step if you have a pre-existing key that allows you to SSH from passive to the active cluster.)
On the passive site (standby master), run the following:
screen -LS dr_setup /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select option: "Configure disaster recovery".
Select the option: "This cluster is destination cluster (usually the dr node)"
Please select the type of cluster: 1) This cluster is source cluster (usually the primary) 2) This cluster is destination cluster (usually the dr node) 3) This cluster is for file replication (configuration change needed)
Input the IP address of the active cluster.
What is the IP of the source cluster?
Select the option "SSH key".
The source cluster's SSH key will replace the one for this cluster. How do you want to pull the source cluster SSH key? 1) password 2) SSH key
Input the private key file path.
What is the path to the private key file?
The passive cluster will connect to the active cluster with the private key provided. If there is no SSH key at the passive cluster, select Option 1 and follow the prompts. You will be asked for user credentials (with sufficient privileges) to either access the active cluster master to retrieve the SSH key or generate a new key.
Failover to Passive Cluster
Hardware and Virtual Deployments Only
This section includes instructions on how to failover to the passive site when the previously active site goes down. It also covers how to failback when you are ready to bring the restored site back online.
Exabeam's recommended policy for failback is to demote the failed cluster as the new passive cluster going forward. For example, Cluster A is the active cluster and Cluster B is the passive. Cluster A fails and Cluster B becomes active. When Cluster A is ready to come back online, it rejoins as a passive cluster until complete data synchronization and is then promoted to an active cluster again.
Make Passive Cluster (Secondary Site) Become Active
Log on to the passive cluster and ensure docker is running:
sos; docker ps
Stop the replicator:
replicator-socks-stop; replicator-stop
After stopping the replicator, run the deployment script:
screen -LS dr_failover /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select "Promote Disaster Recovery Cluster to be Primary." This step promotes the passive cluster to be the active.
After the passive cluster is promoted to active, stop docker:
sos; everything-stop
Start docker again:
docker-start
Run the following command to start all services:
everything-start
If using a Syslog server, please switch the Syslog server to push logs to the new active cluster environment (secondary site).
If you have deployed Helpdesk Communications, restart two-way email service in the UI.
Start Log Ingestion and Analytics Engine from the Exabeam Engine page.
Make Failed Active Cluster (Primary Site) Become Passive After Recovery
Warning
Do not immediately promote the restored cluster back to active status after recovery. It must be demoted in order to synchronize data lost during its outage.
Log on to the existing active and ensure docker is running.
sos; docker ps
Run the deployment script:
screen -LS dr_failover /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select option "Configure Disaster Recovery."
Select the option: "This cluster is destination cluster (usually the dr node)"
Please select the type of cluster: 1) This cluster is source cluster (usually the primary) 2) This cluster is destination cluster (usually the dr node) 3) This cluster is for file replication (configuration change needed)
Input the IP address of the source cluster.
What is the IP of the source cluster?
Select the option "SSH key".
The source cluster's SSH key will replace the one for this cluster. How do you want to pull the source cluster SSH key? 1) password 2) SSH key
Input the private key file path.
What is the path to the private key file?
Run the following command to stop all services:
sos; everything-stop
After the recovered cluster is demoted, start docker again:
docker-start
Run the following command to start all services:
everything-start
Failback to Passive Site (Original Primary) Cluster
Demote Active Cluster (Secondary Site) Back to Passive After Synchronization
Log on to the current active cluster and ensure docker is running:
sos; docker ps
Stop the replicator:
replicator-socks-stop; replicator-stop
After stopping the replicator, run the deployment script:
screen -LS dr_failback /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select option "Configure Disaster Recovery."
Set the cluster as Disaster Recovery (Non Primary) to demote the active (former standby) cluster back to standby.
After the active (former passive) cluster is demoted to passive, stop docker:
sos; everything-stop
After everything is done, start docker again:
docker-start
Run the following command to start all services:
everything-start
Promote Restored Cluster (Original Primary) to Active
Log on to the restored cluster master and ensure docker is running:
sos; docker ps
Run the deployment script:
screen -LS dr_failback /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select "Promote Disaster Recovery Cluster to be Primary." This step promotes the recovered cluster to back to active status.
Run the following command to stop all services:
sos; everything-stop
After the restored cluster is promoted, start docker again:
docker-start
Run the following command to start all services:
sos; everything-start
If you have deployed Incident Responder, restart incident feed log ingestion in the UI.
Navigate to Settings > Case Manager > Incident Ingestion > Incident Feeds.
Click Restart Log Ingestion Engine.
If you have deployed Helpdesk Communications, restart two-way email service in the UI.
Navigate to Settings > Case Manager > Incident Ingestion > 2-Way Email.
Click the pencil/edit icon associated with the applicable email configuration.
Click Restart.
If using a Syslog server, please switch the Syslog server to push logs to the active cluster (primary site). Start Log Ingestion and Analytics Engine from the Exabeam Engine page.
Replicate Specific Files Across Clusters
Hardware and Virtual Deployments Only
Warning
You can only perform this configuration with the assistance of Exabeam Customer Success Engineer.
File replication across clusters leverages Advanced Analytics and Incident Responder disaster recovery functionality, which replicates entire cluster configurations, context, user generated data, logs/events, and HDFS files (for Incident Responder).
Note
Advanced Analytics HDFS files are copied from oldest to newest. Incident Responder HDFS files are copied from newest to oldest.
In certain customer scenarios, clusters are situated in remote areas with considerable bandwidth restraints. In these rare scenarios, you can configure Advanced Analytics and/or Incident Responder to only replicate and fetch specific files. For example, you can configure your deployment to replicate only compressed event files across clusters.

Primary Site – Source Cluster Setup
On the primary site, run the following:
screen -LS dr_setup /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select option: "Configure disaster recovery".
Select the option: "This cluster is source cluster (usually the primary)"
Please select the type of cluster: 1) This cluster is source cluster (usually the primary) 2) This cluster is destination cluster (usually the dr node) 3) This cluster is for file replication (configuration change needed)
Wait for the deployment to successfully finish.
Secondary Site – Destination Cluster Setup
On the secondary site, run the following:
screen -LS dr_setup /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select option: "Configure disaster recovery".
Select the option: "This cluster is for file replication (configuration change needed)"
Please select the type of cluster: 1) This cluster is source cluster (usually the primary) 2) This cluster is destination cluster (usually the dr node) 3) This cluster is for file replication (configuration change needed)
Input the IP address of the source cluster.
What is the IP of the source cluster?
Select the option "SSH key".
The source cluster's SSH key will replace the one for this cluster. How do you want to pull the source cluster SSH key? 1) password 2) SSH key
Input the private key path.
What is the path to the private key file?
Wait for the deployment to successfully finish.
Replication of the primary cluster automatically begins, but all replication items are disabled. You must manually enable the replication items.
On the secondary site, access the custom configuration file
/opt/exabeam/config/custom/custom_replicator_disable.conf
, and then enable replication items.For example, if you wish to only fetch compressed event files, then set the
Enabled
field for the [“.evt.gz”] file type totrue
(shown below).{ EndPointType = HDFS Include { Dir = "/opt/exabeam/data/input" FilePattern = [".evt.gz"] } Enabled = true }
Start the replicator.
sos; replicator-socks-start; replicator-start
Once the replicator is started, log on to the standby cluster GUI. Navigate to Context Setup and click the Generate Context button. This gathers context from the active cluster to synchronize the standby cluster.
Add Case Manager and Incident Responder to Advanced Analytics Disaster Recovery
Hardware and Virtual Deployments Only
If you are upgrading from Advanced Analytics SMP 2019.1 (i48) or lower and have configured disaster recovery for Advanced Analytics, add Case Manager and Incident Responder to the existing Advanced Analytics disaster recovery.
Warning
Configure this only with an Exabeam Customer Success Engineer.
1. Stop the Replicator
Ensure that the Advanced Analytics replication is current.
To ensure that the passive site matches the active site, compare the files in HDFS, the local file system, and MongoDB.
Source the shell environment:
. /opt/exabeam/bin/shell-environment.bash
On the active cluster, stop the replicator:
sos; replicator-socks-stop; replicator-stop
2. Upgrade the Passive and Active Advanced Analytics Clusters
Note
Both the primary and secondary clusters must be on the same release version at all times.
Warning
If you have an existing custom UI port, please set the web_common_external_port
variable in /opt/exabeam_installer/group_vars/all.yml
. Otherwise, you may lose access at the custom UI port after the clusters upgrade.
web_common_external_port: <UI_port_number>
(Optional) Disable Exabeam Cloud Telemetry Service.
If you use the SkyFormation cloud connector service, stop the service.
For SkyFormation v.2.1.18 and higher, run:
sudo systemctl stop sk4compose
For SkyFormation v.2.1.17 and lower, run:
sudo systemctl stop sk4tomcat sudo systemctl stop sk4postgres
Note
After you've finished upgrading the clusters, the SkyFormation service automatically starts. To upgrade to the latest version of SkyFormation, please refer to the Update SkyFormation app on an Exabeam Appliance guide at support.skyformation.com.
From Exabeam Community, download the
Exabeam_[product]_[build_version].sxb
file of the version you're upgrading to. Place it anywhere on the master node, except/opt/exabeam_installer
, using Secure File Transfer Protocol (SFTP).Change the permission of the file:
chmod +x Exabeam_[product]_[build_version].sxb
Start a new terminal session using your
exabeam
credentials (do not run as ROOT).To avoid accidentally terminating your session, initiate a screen session.
screen -LS [yourname]_[todaysdate]
Execute the command (where
yy
is the iteration number andzz
is the build number):./Exabeam_[product]_[build_version].sxb upgrade
The system auto-detects your existing version. If it can't, you are prompted to enter the existing version you are upgrading from.
When the upgrade finishes, decide whether to start the Analytics Engine and Log Ingestion Message Extraction engine:
Upgrade completed. Do you want to start exabeam-analytics now? [y/n] y Upgrade completed. Do you want to start lime now? [y/n] y
3. Add Case Manager to Advanced Analytics
SSH to the primary Advanced Analytics machine.
Start a new screen session:
screen –LS new_screen /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
When asked to make a selection, choose
Add product to the cluster
.From these actions, choose option
4
.1) Upgrade from existing version 2) Deploy cluster 3) Run precheck 4) Add product to the cluster 5) Add new nodes to the cluster 6) Nuke existing services 7) Nuke existing services and deploy 8) Balance hadoop (run if adding nodes failed the first time) 9) Roll back to previously backed up version 10) Generate inventory file on disk 11) Configure disaster recovery 12) Promote Disaster Recovery Cluster to be Primary 13) Install pre-approved CentOS package updates 14) Change network settings 15) Generate certificate signing requests 16) Exit Choices: ['1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16']: default (1): 4
Indicate how the node should be configured:
Which product(s) do you wish to add? ['ml', 'dl', 'cm']: cm How many nodes do you wish to add? (minimum: 0): 1 What is the IP address of node 1 (localhost/127.0.0.1 not allowed)? 10.10.2.40 What are the roles of node 1? ['cm', 'uba_slave']: cm
To configure Elasticsearch, Kafka, DNS servers, and disaster recovery, it's best that you use these values:
How many elasticsearch instances per host? [2] 1 What's the replication factor for elasticsearch? 0 means no replication. [0] How much memory in GB for each elasticsearch instance? [16] 16 How much memory in GB for each kafka instance? [5] Would you like to add any DNS servers? [y/n] n Do you want to setup disaster recovery? [y/n] n
Once the installation script successfully completes, restart the Analytics Engine.
4. Configure Disaster Recovery on the Advanced Analytics and Case Manager Passive Clusters
On the secondary site, run:
screen -LS dr_setup /opt/exabeam_installer/init/exabeam-multinode-deployment.sh
Select option:
Configure disaster recovery
.Select the third option:
This cluster is for file replication (configuration change needed)
Please select the type of cluster: 1) This cluster is source cluster (usually the primary) 2) This cluster is destination cluster (usually the dr node) 3) This cluster is for file replication (configuration change needed)
Enter the IP address of the source cluster.
What is the IP of the source cluster?
Select option:
SSH key
.The source cluster's SSH key will replace the one for this cluster. How do you want to pull the source cluster SSH key? 1) password 2) SSH key
Enter the private key path.
What is the path to the private key file?
The deployment may take some time to finish.
The primary cluster begins to replicate automatically, but all replication items are disabled. You must manually enable the replication items.
On the secondary site, access the custom configuration file /
opt/exabeam/config/custom/custom_replicator_disable.conf
, then enable replication items.For example, if you wish to only fetch compressed event files, then set the
Enabled
field for the [“.evt.gz
”] file type totrue
:{ EndPointType = HDFS Include { Dir = "/opt/exabeam/data/input" FilePattern = [".evt.gz"] } Enabled = true }
Start the replicator:
sos; replicator-start
Log on to the standby cluster GUI.
To gather context from the active cluster to synchronize the standby cluster, navigate to LDAP Import > Generate Context, then click Generate Context.
5. Start the Replicator
On the active cluster, start the replicator:
replicator-socks-start; replicator-start
Enable Settings to Detect Email Sent to Personal Accounts
Hardware and Virtual Deployments Only
To start monitoring when someone sends company email to a personal email account, enable it in the algorithms.conf
custom configuration file.
Don't change the other parameters in the custom configuration file; they affect the machine learning algorithm behind this capability. If you have questions about these parameters, contact Exabeam Customer Success.
Source the shell environment:
. /opt/exabeam/bin/shell-environment.bash
Navigate to
/opt/exabeam/ds-server/config/custom/algorithms.conf
.In the
algorithms.conf
file underpersonal-email-identification
, change the value ofEnabled
totrue
:personal-email-identification { Enabled = true
Add your company domain as a string to
CompanyDomain
:personal-email-identification { Enabled = true Parameters = { CompanyDomain = "company.com"
To add multiple company domains, insert them in a list:
personal-email-identification { Enabled = true Parameters = { CompanyDomain = ["company.com", "company1.com", "comapny2.com"] }
Save the
algorithms.conf
file.Restart the DS server:
ds-server-stop ds-server-start
Manage Security Content in Advanced Analytics
Install, get updates on, uninstall, and upload content packages in Advanced Analytics settings.
Manage all your content packages directly in Advanced Analytics settings, under Admin Operations > Additional Settings > Content Updates. Instead of using Content Installer, which requires you to use the command line and manually restart internal engines, you retrieve the latest available content packages from the cloud in real time, including both general Exabeam releases and custom fixes you request.
In these settings, a content package that includes custom fixes you requested is called a custom package. A content package from a general Exabeam release is called a default package. It's important that you update your content with each release because the release may contain new rules and models, support new log sources and vendors, and remove noisy rules or faulty models, and other additions and fixes that keep your system running smoothly.
If you have an environment that can access the internet, you can pull the latest content packages manually or automatically, select a specific content packages to install, or even schedule content packages to automatically install on a daily or weekly basis, all from the cloud.
If you have an environment that can't access the internet, you can't connect to the cloud. You must view and download the latest content packages from the Exabeam Community, then upload them.
You can only install and upload content packages that contain event builders or parsers.
Manually Install a Content Package
Install a new content package directly from Advanced Analytics settings onto your system.
Select a content package to install from a list of the latest, available content packages. If your environment can't access the internet, you can't install content packages from the cloud. Instead, download the content package from the Exabeam Community or your case ticket, then manually upload it.
A content package from a general Exabeam release is called a default package. It's important that you update your content with each release because the release may contain new rules and models, support new log sources and vendors, and remove noisy rules or faulty models, and other additions and fixes that keep your system running smoothly. You can upload multiple default content packages, but only install one default package at a time.
A content package that includes custom fixes you requested is called a custom package. You can upload and install any number of custom packages.
You can only install custom content packages that contain event builders or parsers.
In the navigation bar, click the menu
, select Settings, then navigate to Admin Operations > Additional Settings.
Under ADMIN OPERATIONS, select Content Updates.
To install a default content package, click the DEFAULT PACKAGES tab. To install a custom content package, click the CUSTOM PACKAGES tab.
Click INSTALL.
If the package is a default content package and a newer version of one you previously installed, this newer version replaces the older version. You can no longer view or install the older version.
If the package is a custom content package and a newer version of one you already installed, ensure that you uninstall the older version.
Automatically Install Content Packages
Schedule Advanced Analytics to automatically check for and install new content packages on a daily or weekly basis.
If you have an environment that can't access the internet, you can't install content packages from the cloud. Instead, download a content package from the Exabeam Community or your case note, then manually upload it.
Only content packages that contain event builders or parsers are available.
In the navigation bar, click the menu
, select Settings, then navigate to Admin Operations > Additional Settings.
Under ADMIN OPERATIONS, select Content Updates.
Click Install Schedule, then toggle Auto Install on.
After Install package, select the day of the week when Advanced Analytics downloads new content.
After at, select the time when Advanced Analytics downloads new content.
Click SAVE. If newer versions of custom content packages were installed, ensure that you uninstall the older version.
Manually Check for New Content Packages
Manually fetch the latest available content packages. You can also set Advanced Analytics to automatically check for new packages every 30 minutes.
If you have an environment that can't access the internet, you can't connect to the cloud to view the latest, available content packages. Instead, check the Exabeam Community for the latest content packages. If you manually refresh the list, Advanced Analytics says you have no new packages.
Only content packages that contain event builders or parsers are available.
In the navigation bar, click the menu
, select Settings, then navigate to Admin Operations > Additional Settings.
Under ADMIN OPERATIONS, select Content Updates.
Click refresh
. Advanced Analytics checks for new default and custom content packages and updates both lists.
Automatically Check for New Content Packages
Set Advanced Analytics to automatically check for new content packages and fetch them every 30 minutes.
This setting automatically checks for new content packages but doesn't install them. To automatically install them, you must schedule it separately.
If you have an environment that can't access the internet, you can't connect to the cloud to view the latest, available content packages. Instead, check the Exabeam Community for the latest content packages.
Only content packages that contain event builders or parsers are available.
In the navigation bar, click the menu
, select Settings, then navigate to Admin Operations > Additional Settings.
Under ADMIN OPERATIONS, select Content Updates.
Click Last Update Checked, toggle Auto Updates on, then click SAVE. Advanced Analytics checks for new content packages every 30 minutes and updates the list.
Upload a Content Package
If you have an environment that can't access the internet, download new content from the Exabeam Community or your case ticket, then upload it directly in Advanced Analytics settings.
If you can access the internet in your environment, you see a list of the latest available content packages in the cloud. Directly install a content package from this list instead of uploading packages to Advanced Analytics .
A content package from a general Exabeam release is called a default package. It's important that you update your content with each release because the release may contain new rules and models, support new log sources and vendors, and remove noisy rules or faulty models, and other additions and fixes that keep your system running smoothly. You can upload multiple default content packages, but only install one default package at a time.
A content package that includes custom fixes you requested is called a custom package. You can upload and install any number of custom packages.
You can only upload content packages that contain event builders or parsers.
Ensure that you download the content package from the Exabeam Community or your case ticket.
In the navigation bar, click the menu
, select Settings, then navigate to Admin Operations > Additional Settings.
Under ADMIN OPERATIONS, select Content Updates.
To upload a content package from a general Exabeam content release, click DEFAULT PACKAGES. To upload a content package you requested, click CUSTOM PACKAGES.
Click the upload
button.
Click UPLOAD THE PACKAGE, then select a ZIP file to upload, up to 100 MB.
Click SAVE. Your content package is uploaded.
Locate your content package, then click INSTALL. Your content package is installed. If the package is a custom content package and a newer version of one you already installed, ensure that you uninstall the older version.
Uninstall a Custom Content Package
Uninstall a custom content package if there's an issue with the package or to remove an older version of a package once you upload a newer version.
A content package from a general Exabeam release is called a default package. A content package that includes custom fixes you requested is called a custom package. You can only uninstall a custom content package, not a default content package. To remove a default content package, you must install another default content package.
In the navigation bar, click the menu
, select Settings, then navigate to Admin Operations > Additional Settings.
Under ADMIN OPERATIONS, select Content Updates.
Click the CUSTOM PACKAGES tab, then next to the content package, click UNINSTALL.
Exabeam Hardening
The Exabeam Security Management Platform (SMP) has enabled security features by default that provide stricter controls and data protection. Two examples of what Exabeam has built protection against include Cross-Site Request Forgery (CSRF) and Cross-Origin Resource Sharing (CORS). A default set of filters are defined and enabled in Exabeam configurations. This improves the default security of the environment for all Exabeam services.
For Exabeam SaaS deployments that use Exabeam Advanced Analytics as your Exabeam Cloud Connector identity provider (IdP), Exabeam will update Cloud Connector to v.2.5.86 or later.
No manual configuration is needed for deployments with the following versions or later, as these protections are enabled by default:
Exabeam Advanced Analytics i53.6
Exabeam Data Lake i34.6
Important
This security enhancement has been enabled by default:
Data Lake i34.6 and i35
Advanced Analytics i53.6 and i54.5
It is not enabled by default in:
Data Lake i33 or earlier
Advanced Analytics i52 or earlier
Please follow the hardening guidelines. At the earliest opportunity, please upgrade to a currently supported version of Advanced Analytics and Data Lake .
How to Enable Cross-Site Request Forgery Protection
Cross-Site Request Forgery (CSRF) attacks are web-based vulnerabilities where attackers trick users with trusted credentials to commit unintended malicious actions. CSRF attacks change the states of their targets rather than steal data. Examples include changing account emails and changing passwords.
CSRF protection is available for Exabeam Advanced Analytics and Data Lake and previously inactive. Older versions of Advanced Analytics and Data Lake may manually harden or upgrade to a hardened supported version (Advanced Analytics i53.6 or later and Data Lake i34.6 or later) to enable the security configuration by default.
For information about enabled versions, see Exabeam Hardening.
These protections may affect API calls to the Exabeam SMP; please review customs scripts and APIs used by your organization. Please follow instructions given in Step 1c to conform your scripts.
To enable CSRF protection, apply the following:
For all deployments, the
/opt/exabeam/config/common/web/custom/application.conf
file at each master host needs to be configured to enable CSRF protection at service startup.Edit the following parameters in the CONF file:
csrf.enabled=true csrf.cookie.secure=true csrf.cookie.name="CSRF_TOKEN"
Restart
web-common
to enable CSRF protection.. /opt/exabeam/bin/shell-environment.bash web-common-restart
Note
Log ingestion will not be interrupted during the restart.
web-common
can take up to 1 minute to resume services.API calls to Exabeam that utilize
POST
requests using typesapplication/x-www-form-urlencoded
,multipart/form-data
andtext/plain
are affected by CSRF configurations. Ensure API clients have headers that hasCsrf-Token
set to valuenocheck
.Continue with the next step.
For Advanced Analytics using Case Manager or Incident Responder , edit
/opt/exabeam/code/soar-python-action-engine/soar/integrations/exabeamaa/connector.py
.Find the entry
self._session = SoarSession(base_url=apiurl, timeout=timeout, verify=False)
and replace with:self._session = SoarSession(base_url=apiurl, timeout=timeout, verify=False, headers={'Csrf-Token': 'nocheck'})
Restart services.
sudo systemctl restart exabeam-soar-python-action-engine-web-server sudo systemctl restart exabeam-soar-python-action-engine
If SAML is configured, the IdP’s domain needs to be explicitly added to the CORS origins and then apply the new configuration. Please follow steps given in How to Enable Cross-Origin Resource Sharing Protection.
How to Enable Cross-Origin Resource Sharing Protection
Cross-Origin Resource Sharing (CORS) is a browser standard which allows for the resources or functionality of a web application to be accessed by other web pages originating from a different domain -- specifically, the origin. An origin is defined by the scheme (protocol), host (domain), and port of the URL used to access a resource. CORS is a policy that allows a server to indicate any origins other than its own from which a browser should permit loading of resources
CORS protection is available for Exabeam Advanced Analytics and Data Lake and enabled by default in Data Lake i34.6 or Advanced Analytics i53.6 and later versions. Older versions of Advanced Analytics and Data Lake may manually harden or upgrade to a hardened supported version (Advanced Analytics i53.6 or later and Data Lake i34.6 or later) to enable the security configuration by default.
For information about enabled versions, see Exabeam Hardening.
To manually enable CORS protection when it is not enabled by default, apply the following:
For all deployments, the
/opt/exabeam/config/common/web/custom/application.conf
file at each master host needs to be configured to enable CORS protection at service startup. Editwebcommon.service.origins
parameter the CONF file to match your Exabeam service domain:webcommon.service.origins = ["https://*.exabeam.<your_organization>.com:<listener_port>", <...additional_origins...>]
Here's an example with 2 service origins:
webcommon.service.origins = ["https://*.exabeam.org-name.com", "https://*.exabeam.org-name.com:8484"]
Restart
web-common
to enable CORS protection.. /opt/exabeam/bin/shell-environment.bash web-common-restart
Note
Log ingestion will not be interrupted during the restart.
web-common
can take up to 1 minute to resume services.
How to Verify Origin and CORS Enforcement with cURL
The verification method presented here uses cURL to test CORS protection once it has been implemented.
You can verify that your environment is enforcing CORS policy with the following (using www.example.com
as an origin):
curl -H "Origin: http://www.example.com" --verbose <exabeam_ip_or_hostname>
The response should be 403 Forbidden
with the error message Invalid Origin - http:www.example.com
.
To verify that CORS is working as intended, modify the origin:
curl -H "Origin: <exabeam_ip_or_hostname>" --verbose <exabeam_ip_or_hostname>
The response should be 200 OK
with the Exabeam home page's HTML.