Set up the universal forwarder using Splunk SOAR version 6.2.x
Starting in Splunk SOAR version 6.2.0, remote search is replaced with the Splunk SOAR universal forwarder.
Data is only available to forward to your Splunk Cloud Platform or Splunk Enterprise instance after you have configured the universal forwarder, following the steps in the next section, Configure the universal forwarder in Splunk SOAR.
If you have already configured universal forwarders in Splunk SOAR version 6.2.0, no further action is required. Your Splunk App for SOAR dashboards will be populated with the same data types as they were with previous versions of Splunk SOAR.
Configure the universal forwarder in Splunk SOAR
Before completing these steps, you must complete the steps described in Configure the service with Splunk App for SOAR.
For details on configuring the universal forwarder in Splunk SOAR, see the documentation for your deployment:
- Splunk SOAR (Cloud): Configure forwarders to send SOAR data to your Splunk deployment
- Splunk SOAR (On-premises): Configure forwarders to send SOAR data to your Splunk deployment
If you choose, while configuring the universal forwarder in Splunk SOAR, use the option to create a TCP token.
Changes in auditing
With the change from remote search to data forwarders, there are some changes to auditing, including new field names described in the table at the end of this article. For complete information on auditing in Splunk App for SOAR, see Configure auditing using Splunk App for SOAR.
Missing audit data after conversion
If any audit data is missing from the conversion, see Backfill Splunk SOAR audit data in the Configure auditing using Splunk App for SOAR article.
Search field equivalents
This table shows the equivalents between using /rest/audit and the new universal forwarder. This is especially helpful if you have been using dashboards or searches and want to map from your existing dashboards to the data from the new universal forwarder.
Field | /rest/audit | Splunk SOAR universal forwarder | Notes |
---|---|---|---|
index | <user's choice> | _audit | |
source | <user's SOAR server name> | /opt/phantom/var/log/phantom/audit.log | |
sourcetype | soar | _audit | |
host | https://<user's SOAR IP> | <user's SOAR IP> | |
user | the user's username (for example: automation , admin )
|
the user's ID (for example: 2 , 1 )
|
If user is null, no user was associated with the action; the action was performed by the Splunk SOAR system. |
- | action | If action is null, the action does not fit neatly into one of the categories: created, modified, accessed, deleted | |
- | component | ||
- | ctx_* many available |
For any ctx_* field, when the user logs in, the last_login field updates, which modifies the record. | |
- | dest | ||
- | file | ||
- | level | ||
- | line | ||
- | log_type | ||
- | logger | ||
"AUDIT ID" | - | ||
"AUDIT SOURCE" | message | ||
"CHANGED FIELD" | - | ||
"IP ADDRESS" | src ctx_request_remote_addr |
For any ctx_* field, when the user logs in, the last_login field updates, which modifies the record. | |
"NOTE" | object_attrs.note | A summary of what happened, usually including the resource that was changed and the action taken on it. | |
"OBJECT ID" | object_id | ||
"OBJECT TYPE" | object_category | ||
"TIME" | time | ||
"USER" | - | ||
"USER ID" | user ctx_user_id |
For any ctx_* field, when the user logs in, the last_login field updates, which modifies the record. | |
- | object_attrs.changed_time | When the resource was changed. | |
- | object_attrs.created_time | When the audit record was created. | |
- | object_attrs.related_category | The related object type, such as container or case_management. | |
- | pid | ||
- | product_version | ||
- | status | ||
- | tag | ||
- | user_category |
Configure the service with Splunk App for SOAR | Reindex data |
This documentation applies to the following versions of Splunk® App for SOAR: 1.0.57, 1.0.67, 1.0.71
Feedback submitted, thanks!