Planning your integration for ES

System and software requirements

To build integrations for Splunk Enterprise Security, you need access to a licensed version of Splunk Enterprise with Splunk Enterprise Security installed. The Splunk Enterprise Security Sandbox is not sufficient for development. Only members of Splunk Partner programs can request Splunk Enterprise Security trial licenses.

Do not use your production Splunk Enterprise Security environment for development.

If you do not already have access to a licensed version of these products:

  1. Developers can obtain a developer license for the Splunk platform by following the Splunk Developer License Sign Up instructions.
  2. Customers who want access to a developer license can contact their sales representative at Splunk.
  3. Partners who want to try Splunk Enterprise Security can reach out to their account representative at Splunk to request a trial.

Recommended tools

Splunk Add-on Builder simplifies the process of building add-ons that ingest data from new security data sources and normalize them to the Common Information Model. You can also use it to build custom adaptive response actions to integrate with the Adaptive Response framework.

You can download the Splunk Add-on Builder from Splunkbase.

Packaging your integrations

Package your integration as a Splunk add-on. Packaging your integration as an add-on provides two major benefits: it allows you to share it on Splunkbase with other users, and it helps to prevent misconfigurations that would cause your custom integration to be invalidated by Splunk Enterprise Security upgrades. See Packaging Toolkit for information about packaging your add-on.

As a best practice, follow the naming conventions expected by Splunk Enterprise Security. The Update ES modular input automatically imports apps and add-ons prefixed with any of the following: DA-ESS-, SA-, TA-, Splunk_SA_, Splunk_TA_, and Splunk_DA-ESS_. For more information about how ES admins import custom apps and add-ons, see Import custom apps and add-ons to Splunk Enterprise Security. For more information about the DA/SA/TA naming conventions, see About the Enterprise Security solution architecture.

If your integration consists only of custom search objects and glass tables, you have the option to export your content from Splunk Enterprise Security as an add-on. See Export content from Splunk Enterprise Security as an app.


Highlight changes to custom views and collections in the navigation editor

In Splunk Enterprise Security 4.7.0 and later, the ES navigation editor highlights views and collections that are new, updated, or deprecated using small icons. As an app developer, you can apply these icons to custom views that you package in your app to alert ES admins to relevant changes. You can also highlight changes to collections, which bundle several views together. For more about creating views and collections in apps, see Add navigation to a Splunk app.

Highlighting the changes to your views and collections helps a Splunk ES administrator discover your content when they customize the navigation for their instance. The icons call attention to the latest views or modifications you have made to your app without impacting any custom navigation the ES admin has implemented on their instance. For more information about how Splunk Enterprise Security administrators use the navigation editor, see Customize the menu bar in Splunk Enterprise Security.

Follow the procedure to highlight changes to each custom view and collection in your app. Refer to SA-Utils/README/managed_configurations.conf.example for an example.

  1. Open or create default/managed_configurations.conf in your app package.
  2. Include a stanza that defines each custom view in your app using this template:
    label = <Friendly name for the view>
    description = <Description of the view>
    editable = 0
    endpoint = services/data/ui/nav/<view_name>
    nav_view_status = <Status of the view>
  3. In each stanza, replace the bracketed items in the template with the values that apply to the custom view.
  4. For the nav_view_status attribute, specify one of these statuses:
    Status Description
    new This view is newly added to the app in this version.
    In the navigation editor, this view is marked with an orange N.
    updated This view is updated in this version of the app.
    In the navigation editor, this view is marked with a yellow U.
    old This view is unchanged from the previous version of the app.
    In the navigation editor, no icon is applied to this view.
    deprecated This view is deprecated in this version of the app. As a best practice, deprecate a view for at least one release before removing it.
    In the navigation editor, this view is marked with a gray D.
  5. To highlight changes to collections in your app, use this template:
    label = <Friendly name of the collection>
    description = <Collection description>
    editable = 0
    nav_collection_status = <Status of the collection>
    nav_collection_data = \
    <collection label="<Friendly name of the collection">\
        <view name="view_id_of_first_view" />\
        <view name="view_id_of_second_view" />\
        <view name="view_id_of_third_view" />\
  6. In each stanza, replace the bracketed items in the template with the values that apply to your collection. For statuses, refer to the table in step 4, as the same status values apply to collections.

As you revise your app and produce new versions, adjust the nav_view_status and nav_collection_status attributes in this file to reflect your changes. For example, if you mark a view as new in Version 1.0.0, change it to old in version 1.1.0 if version 1.1.0 does not introduce any changes to that view.