Before you install or upgrade from Splunk SIEM 1.x to 2.x.x, consider the following action items.

  1. If you have a non-production instance of Splunk, upgrade that instance first.
  2. Identify whether you have custom content that uses alert metadata, such as reports, searches, or dashboards.

    If the content is using a non-CIM and non-data model field, review the Migration Guide. Many renamed fields have been aliased to their old values. However, Splunk content based on fields that were removed or were replaced by multiple fields must be updated.

    • If the field is marked as DEPRECATED, you must choose a different field or remove that field from your custom content.
    • If the field has a replacement field identified, then use that field name instead.
    • See field changes for the Alerts v7 API.
    • See field changes for the Data Forwarder Alert Schema v2.
    Note: Because the Alerts v7 schema contains more metadata than the previous schema, you might see an increase up to 2 times in alert size. However, because Observed alerts have been removed, you are likely to see a net decrease in overall storage required for Carbon Black Analytics alerts (up to 10 times decrease), but a net increase in other alert types such as Watchlist (up to 2 times increase).
  3. If there are any Splunk alerts using the Process GUID Details or VMwareCBC Enrich CB Analytic Events alert actions, review why they were configured and the data that is used.
    • In the Carbon Black Cloud Splunk SIEM App v1.x, many customers used these alert actions to get context that was not available in alerts, such as process and parent process information.
    • The alert metadata included in both Alert v7 API and Data Forwarder Schema v2 has been improved, and you may no longer need to run these alert actions.
    • If you determine that it is no longer necessary to automate these alert actions, disable or remove the Splunk Alert.
  4. If you are using the Live Response alert actions List Process or Kill Process, you must change the API Key. Before upgrading, update your existing Splunk access level to include the required permissions.
    1. In the Splunk App, identify the API key (Access Level type is Custom) that you use for other Splunk inputs and actions, such as the Alerts input.
    2. In the Carbon Black Cloud console, identify the access level you use for that API key by going to Settings > API Access, finding the API ID, and reading the Access Level.
    3. Add Live Response permissions to that Access Level.
      1. Go to the Settings > API Access > Access Levels tab.
      2. Click the Pencil icon Pencil icon to edit the access level.
      3. To enable the Kill Process and List Process actions, add the following permissions: 
        * Kill Process requires:
  * device - READ
  * org.liveresponse.session - CREATE, READ, DELETE
  * org.liveresponse.process - READ, DELETE
* List Processes requires:
  * device - READ
  * org.liveresponse.session - CREATE, READ, DELETE
  * org.liveresponse.process - READ
      Note: Full permissions are listed in Alert Actions and Adaptive Responses.
  5. If you are using an Audit Log input, you must change the API key to a custom access level key with audit log permissions before October 31, 2024. Before upgrading, update your existing Splunk access level to include the required permissions. Follow the steps listed above in the Carbon Black Cloud console to add the org.audits permission to the Custom Access Level that the API key in Splunk uses.
    Note: Full permissions are listed in API Data Inputs.
  6. If you are using Carbon Black Cloud Enterprise EDR, decide whether to ingest Authentication Events collected by Carbon Black Cloud into Splunk.
  7. If you are using the Data Forwarder Alerts Input:
    1. Create and enable a Data Forwarder Alert v2 Schema with a different AWS S3 Bucket prefix.
    2. Disable the Data Forwarder Alert v1 Schema.