Splunk® User Behavior Analytics

Send and Receive Data from the Splunk Platform

How Splunk UBA sends and receives data from the Splunk platform

Splunk User Behavior Analytics (UBA) can send data to and receive data from the Splunk platform in a variety of ways, as shown in the following figure.

This image shows how data can be exchanged between Splunk UBA and the Splunk platform. Each method and corresponding details are provided in the table immediately following the image.

The following table provides additional details about each type of integration between Splunk UBA and Splunk Enterprise Security (ES) and Splunk Enterprise.

Integration Configuration How to Secure Splunk Add-on for Splunk UBA Required? Documentation
Splunk UBA pushes anomalies and threats to Splunk ES as notable events. Splunk UBA anomalies and threats are stored in Splunk ES as notable events. Configure the SplunkES output connector in Splunk UBA and connect to the default HTTP Event Collector (HEC) port 8088 on the Splunk ES search head. TLS (store the Splunk root CA certificate in Splunk UBA) Yes Send Splunk UBA anomalies and threats to Splunk ES as notable events.
Splunk UBA pulls notable events from Splunk ES and stores them in Splunk UBA as External Alarms. Configure a data source connecter in Splunk UBA and connect to the search head or forwarder port 8089 on Splunk ES. TLS (store the Splunk root CA certificate in Splunk UBA) Yes Pull notable events from Splunk ES to Splunk UBA.
Splunk UBA pushes health logs to Splunk Enterprise. Use the Splunk UBA Monitoring App to monitor the health of your Splunk UBA deployment from Splunk Enterprise. Enable the forwarder embedded in Splunk UBA to forward health logs to the _internal index on port 9997. You can customize the index and port number as needed. TLS (the usual ways to secure forwarder-to-indexer communications) No About the Splunk UBA Monitoring app in the Splunk UBA Monitoring App manual.
Splunk UBA pushes audit data to Splunk Enterprise for analysis. Configure the property in the uba-site.properties file in Splunk UBA to send audit events to Splunk search head or forwarder port 10008. Events are sent to the _audit index on Splunk Enterprise. TLS (store the Splunk root CA certificate in Splunk UBA) Yes Send Splunk UBA audit events to Splunk ES.
Splunk Enterprise pushes events directly to Kafka on Splunk UBA. Splunk UBA issues micro batch queries to the REST API on the Splunk search head on port 8089. The indexers then push the search results back to Kafka on Splunk UBA (port 9093). TLS (store the Splunk root CA certificate in Splunk UBA) No Send data from the Splunk Platform directly to Kafka in the Splunk UBA Kafka Ingestion App manual.
Splunk UBA pulls raw events from Splunk Enterprise. Configure a Splunk connector in Splunk UBA and connect to a Splunk search head on port 8089. TLS (secure access to Splunk's REST API) No Use connectors to add data from the Splunk platform to Splunk UBA in the Get Data into Splunk User Behavior Analytics manual.
Use Event Drilldown in Splunk UBA to view raw events in the Splunk platform. No data is passed. Clicking on the link takes you to Splunk Enterprise, where the raw events query is run. Splunk web (8000/443) and management ports (8089). TLS (secure access to Splunk's REST API) No Use event drilldown to review an anomaly's raw events in Use Splunk User Behavior Analytics.

Configure the OutputConnector to add a unique user identifier to UBA events sent to Enterprise Security

Perform the following optional steps to configure the OutputConnector to add the employeeid field as a unique user identifier to Splunk Enterprise Security (ES):

  1. In the UBA management node as the caspida user, set the uba.splunkes.threat.export.json parameter to "true" in /etc/caspida/local/conf/uba-site.properties as shown in the following example:
    uba.splunkes.threat.export.json=true
  2. Make a copy of uba_threat_export.json file as shown in the following example: 
    cp -p /etc/caspida/local/conf/export/splunkes/uba_threat_export.json /etc/caspida/local/conf/export/splunkes/uba_threat_export.json.ORIG

    If you have previously backed up modifications to uba_threat_export.json prior to upgrading to version 5.1.0, run the following command to restore it to its new directory: cat /opt/caspida/conf/export/splunkes/uba_threat_export.json.NEW > /etc/caspida/local/conf/export/splunkes/uba_threat_export.json

  3. Edit /etc/caspida/local/conf/export/splunkes/uba_threat_export.json, and add the following employeeid field under entityInfo > user > fields: 
    {
  "name": "employeeid",
  "exportName": "employee_id"
}

    Example: 

    "entityInfo": {
    "user": {
      "exportName": "users",
      "fields": [{
        "name": "id",
        "exportName": "id"
      }, {
		"name": "employeeid",
		"exportName": "employee_id"
      }, {
        "name": "name",
        "exportName": "name"
      }, {
        "name": "type",
        "exportName": "type"
      }, {
        "name": "status",
        "exportName": "status"
      }, {
        "name": "score",
        "exportName": "score"
      }, {
        "name": "eventtime",
        "exportName": "found_time"
      }]
    },
  4. (Optional) Use a JSON validator to make sure there are no errors in your JSON syntax. You can use any online JSON validator, or use the following command: 
    python -m json.tool /etc/caspida/local/conf/export/splunkes/uba_threat_export.json
    This command can be run from the directory where the JSON file is located. If there are no errors, the full contents of the JSON file are displayed. If there are errors, a message appears with the line number in the file where the error is located.
  5. To sync the cluster and restart caspida services, run the following commands:
    /opt/caspida/bin/Caspida sync-cluster /etc/caspida/local/conf
/opt/caspida/bin/Caspida stop
/opt/caspida/bin/Caspida start

Perform the following steps in Enterprise Security (ES) to have the new employeeid field appear in Incidents Review:

  1. Edit the SPL corresponding to the UBA/UEBA Threat Notable and add the following fields:
    | spath output=employee_id path="entities.users{}.employee_id"
    Under stats:
    values(entities.users{}.employee_id) as employee_id
    Example: 
    | from datamodel:"UEBA"."UEBA_Threats" | search uba_threat_status != closed | spath output=employee_id path="entities.users{}.employee_id" | stats values(employee_id) as employee_id, values(app) as app,values(dvc) as dvc,values(user) as user,dc(user) as user_count,values(url) as url,latest(action) as action,latest(uba_event_type) as uba_event_type,latest(description) as description,latest(link) as link,latest(modify_time) as modify_time,latest(severity) as severity,latest(signature) as signature,latest(start_time) as start_time,latest(threat_category) as threat_category by uba_host,uba_event_id
  2. Modify the Incident Review Settings to add employee_id, Employee ID in Table Attributes as shown:
    This image shows the settings page for Incident Review. Table Attributes include Time, Security Domain, Title, Urgency, Status, Owner, and Employee ID.
    • In UBA, export threat from UBA to ES
    • In ES, verify that the threat in ES shows the new employeeid field
    • In UBA, the /var/log/caspida/outoutconnector.log will show events sent that include more information.
  3. Changes should now be in effect as follows:
    Before: user="Rod Simmers"
    After: entities":"users":"id":"998811947371393516","name":"Rod Simmers","employee_id":"ACME-485",

Configure the OutputConnector to add a unique user identifier to UBA risk events sent to Enterprise Security

Perform the following optional steps to configure the OutputConnector to add the employeeid field as a unique user identifier to UBA risk events sent to Splunk Enterprise Security (ES):

  1. In the UBA management node as the caspida user, set the uba.splunkes.threat.risk.export.json parameter to "true" in /etc/caspida/local/conf/uba-site.properties as shown in the following example: 
    uba.splunkes.threat.risk.export.json=true
  2. Make a copy of uba_threat_risk_export.json file as shown in the following example: 
    cp -p /etc/caspida/local/conf/export/splunkes/uba_threat_risk_export.json /etc/caspida/local/conf/export/splunkes/uba_threat_risk_export.json.ORIG
  3. Edit /etc/caspida/local/conf/export/splunkes/uba_threat_risk_export.json, and add the following employeeid field under the path of entityInfo > user > fields: 
    {
  "name": "employeeid",
  "exportName": "employee_id"
}

    Example:

    "entityInfo": {
    "user": {
      "exportName": "users",
      "fields": [{
        "name": "id",
        "exportName": "id"
      }, {
		"name": "employeeid",
		"exportName": "employee_id"
      }, {
        "name": "name",
        "exportName": "name"
      }, {
        "name": "type",
        "exportName": "type"
      }, {
        "name": "status",
        "exportName": "status"
      }, {
        "name": "score",
        "exportName": "score"
      }, {
        "name": "eventtime",
        "exportName": "found_time"
      }]
    },
  4. (Optional) Use a JSON validator to make sure there are no errors in your JSON syntax. You can use any online JSON validator, or use the following command: 
    python -m json.tool /etc/caspida/local/conf/export/splunkes/uba_threat_risk_export.json

    This command can be run from the directory where the JSON file is located. If there are no errors, the full contents of the JSON file are displayed. If there are errors, a message appears with the line number in the file where the error is located.

  5. To sync the cluster and restart caspida services, run the following commands: 
    /opt/caspida/bin/Caspida sync-cluster /opt/caspida/conf/export/
/opt/caspida/bin/Caspida sync-cluster /etc/caspida/local/conf
/opt/caspida/bin/Caspida stop
/opt/caspida/bin/Caspida start
  6. You will now be able to see employee_id in risk event JSONs.

Red Hat Enterprise Linux 8.x cryptographic policies

When installed on RHEL 8.x operating systems, Splunk UBA uses a 2048 bit RSA encryption key. The Splunk platform that communicates with Splunk UBA must also use a 2048 bit encryption key. If the Splunk platform uses a 1024 bit encryption key, you will see the following error in the job executor logs: 

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits. RSA 1024bit key used with certificate

To resolve this issue, use a stronger certificate of at least 2048 bits in length on the Splunk platform.

Alternatively, you can action either of the following options:

Alternate option 1

Set the java.security.disableSystemPropertiesFile property to true in the $JAVA_HOME/jre/lib/security/java.security file in Splunk UBA. 

java.security.disableSystemPropertiesFile property = true

Alternate option 2

Reduce the strength of the RHEL 8 cryptographic policies in Splunk UBA.

  • First, run the following command on the Splunk UBA management node: 
    update-crypto-policies --set LEGACY
  • Then run the following commands on the Splunk UBA management node to stop and restart Splunk UBA: 
    /opt/caspida/bin/Caspida stop-all
/opt/caspida/bin/Caspida start-all
Last modified on 09 September, 2024
  About the Splunk Add-on for Splunk UBA

This documentation applies to the following versions of Splunk® User Behavior Analytics: 5.4.0, 5.4.1

Acrobat logo Download manual
Acrobat logo Download this page

Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters