SplunkPy v2

Run queries on Splunk and fetch Splunk ES Findings and Investigations (Splunk ES 8.2+).

Analytics & SIEM · Splunk

Details

ID	`SplunkPy v2`
Provider	Cisco Systems
Category	Analytics & SIEM
From Version	6.0.0
Docker Image	`demisto/splunksdk-py3:1.0.0.10133006`
Supported Modules	Agentix XSIAM Cloud Posture Security EDR Cortex Cloud Cloud Runtime Security

README

Use the SplunkPy v2 integration to:

Fetch events (logs) from Splunk into Cortex
Push events from Cortex to Splunk
Fetch Splunk Enterprise Security events (Findings) into Cortex.

Important: This integration is designed specifically for Splunk Enterprise Security version 8.2 and above.
For Splunk ES versions prior to 8.2, please use the legacy SplunkPy integration.

This integration was integrated and tested with Splunk Enterprise v10.0.0 and Enterprise Security v8.2.3.

Use Cases

User Configuration Requirements

Option one

Assign the following roles to the user: admin, ess_admin (for working with Splunk Enterprise Security).

Option two

When assigning admin is not an option.
Define a custom role and include all necessary capabilities: (permissions)

Define the indexes configuration for the custom role:

At the end of the process, the Splunk user (not admin user) should receive the previously created role. Following is the list of capabilities that covers both the Splunk UI access and using the SplunkPy v2 integration including Enterprise security:

accelerate_search
admin_all_objects
can_own_notable_events
change_own_password
edit_analyticstories
edit_cam_queue
edit_correlationsearches
edit_lookups
edit_notable_events
edit_own_objects
edit_tcp
edit_tcp_stream
edit_upload_and_index
get_metadata
get_typeahead
input_file
list_accelerate_search
list_all_objects
list_inputs
list_introspection
list_metrics_catalog
list_search_head_clustering
manage_all_investigations
manage_behavioral_analytics
output_file
rest_access_server_endpoints
rest_apps_view
rest_properties_get
rest_properties_set
rtsearch
run_collect
run_mcollect
run_msearch
run_sendalert
schedule_rtsearch
schedule_search
search
search_process_config_refresh
upload_lookup_files

SplunkPy v2 command permissions by example

splunk-finding-event-edit

custom roles required: (at least one)
ess_analyst, ess_admin
Can replace the Splunk power role for ES users.

User-Level Permissions:
Read: Access to view resources (e.g., dashboards, reports).
Write: Ability to modify existing resources or create new ones.

Query Load Analysis

Mirroring

When mirroring in enabled, 2-3 simultaneous queries are expected.
Each query can have more that one API call. On mirror out - API call for updating each finding event that changed. This also includes User mapping queries and mirroring queries.

Enrichment

Fetching finding event - for each fetch iteration 2 queries.
For each finding event that fetched - we have 3 enrichments(max).
<Amount of fetched findings> * <amount of defined enrichments>
In case of more that one drilldown - number of drilldown queries.
Each query can have more that one API call.

Fetch

Configured by the instance configuration max_fetch (behind the scenes an query can made few API calls).

Configure SplunkPy v2 in Cortex

Parameter	Description	Required
Server URL	The Splunk server URL. Port 8089 (Splunk’s default REST API port) is used automatically. Only include the port in the URL if using a non-default port. Examples: ‘https://splunk.example.com’ (uses default port 8089) or ‘https://splunk.example.com:8090’ (uses custom port 8090).	True
Splunk Token		True
Fetch events query	The Splunk search query by which to fetch events. The default query fetches ES finding events. You can edit this query to fetch other types of events. Note, that to fetch ES finding events, make sure to include the \`notable\` macro in your query.	False
Fetch Limit (Max.- 200, Recommended less than 50)		False
Fetch incidents		False
Incident type		False
Parse Raw Part of Finding Events	Whether to parse the raw part of the Findings, or not.	False
Replace with Underscore in Incident Fields	Whether to replace special characters to underscore when parsing the raw data of the Findings, or not.	False
First fetch timestamp (<number> <time unit>, e.g., 12 hours, 7 days, 3 months, 1 year)	The amount of time to go back when performing the first fetch, or when creating a mapping using the Select Schema option.	False
Event types to fetch	Select the Splunk event types to ingest. Default is `Finding`.	False
First fetch timestamp (Investigations)	The relative time interval to look back during the initial investigation fetch (for example, 12 hours, 7 days, 3 months).	False
Investigations fetch query	The SPL query used when “Investigation” is selected for “Event types to fetch”. The query must include the `FETCH_FILTER_PLACEHOLDER` token. Do not modify or remove this token. For more information on customizing the query (for example, adding the filter &status=New), see the integration documentation under “Fetching investigation events”.	False
Maximum investigations per fetch	The maximum number of investigations to fetch per cycle. Limited to 100 by the Splunk investigations endpoint.	False
Extract Fields - CSV fields that will be parsed out of raw finding events		False
Incident Mirroring Direction	Choose the direction to mirror the incident: Incoming (from Splunk to Cortex XSOAR), Outgoing (from Cortex XSOAR to Splunk), or Incoming and Outgoing (from/to Cortex XSOAR and Splunk).	False
Close Mirrored Cortex XSOAR Incidents (Incoming Mirroring)	When selected, closing the Splunk finding event with a “Closed” status will close the Cortex XSOAR incident.	False
Additional Splunk status labels to close on mirror (Incoming Mirroring)	A comma-separated list of Splunk status labels to mirror as closed Cortex XSOAR incident (Example: Resolved,False-Positive).	False
Enable Splunk statuses marked as “End Status” to close on mirror (Incoming Mirroring)	When selected, automatically close the Cortex XSOAR incident when the Splunk ES event (Finding or Investigation) is marked as ‘End Status’.	False
Close Mirrored Splunk ES Events (Outgoing Mirroring)	When selected, automatically close the corresponding Splunk ES event (Finding or Investigation) when the Cortex XSOAR incident is closed.	False
Trust any certificate (not secure)		False
Use system proxy settings		False
The app context of the namespace		False
HEC Token (HTTP Event Collector)		False
HEC BASE URL (e.g: https://localhost:8088 or https://example.splunkcloud.com/).		False
Enrichment Types	Enrichment types to enrich each fetched finding. If none are selected, the integration will fetch findings as usual (without enrichment).
For more info about enrichment types see Enriching Finding Events.	False
Asset enrichment lookup tables	CSV of the Splunk lookup tables from which to take the Asset enrichment data.	False
Identity enrichment lookup tables	CSV of the Splunk lookup tables from which to take the Identity enrichment data.	False
Enrichment Timeout (Minutes)	When the selected timeout was reached, Finding events that were not enriched will be saved without the enrichment.	False
Number of Events Per Enrichment Type	The limit of how many events to retrieve per each one of the enrichment types (Drilldown, Asset, and Identity). In a case of multiple drilldown enrichments the limit will apply for each drilldown search query. To retrieve all events, enter “0” (not recommended).	False
Advanced: Extensive logging (for debugging purposes). Do not use this option unless advised otherwise.		False
Advanced: Time type to use when fetching events	Defines which timestamp will be used to filter the events: - creation time: Filters based on when the event actually occurred. - index time (Beta): Beta feature – Filters based on when the event was ingested into Splunk. This option is still in testing and may not behave as expected in all scenarios. When using this mode, the parameter “Fetch backwards window for the events occurrence time (minutes)” should be set to `0``, as indexing time ensures there are no delay-based gaps. The default is “creation time”.
Advanced: Fetch backwards window for the events occurrence time (minutes)	The fetch time range will be at least the size specified here. This will support events that have a gap between their occurrence time and their index time in Splunk. To decide how long the backwards window should be, you need to determine the average time between them both in your Splunk environment.	False
Advanced: Unique ID Fields	A comma-separated list of additional fields to use when generating unique incident IDs for events that are not findings (i.e., queries without the `notable` macro). By default, the integration uses: _cd, index,_time, _indextime,_raw. If these fields do not provide unique values in your environment, specify additional fields here to ensure incident uniqueness. Example: source,host,unique_field	False
Enable user mapping	Whether to enable the user mapping between Cortex XSOAR and Splunk, or not. For more information see https://xsoar.pan.dev/docs/reference/integrations/splunk-py#configure-user-mapping-between-splunk-and-cortex-xsoar	False
Users Lookup table name	The name of the lookup table in Splunk, containing the username’s mapping data.	False
XSOAR user key	The name of the lookup column containing the Cortex XSOAR username.	False
SPLUNK user key	The name of the lookup table containing the Splunk username.	False
Note tag from Splunk	Add this tag to an entry to mirror it as a note from Splunk.	False
Note tag to Splunk	Add this tag to an entry to mirror it as a note to Splunk.	False
Incidents Fetch Interval		False

Note: To use a Splunk Cloud instance, contact Splunk support to request API access. Use a non-SAML account to access the API.

Splunk Enterprise Security Users

Note: The following information is for Splunk Enterprise Security version 8.2+ users.
This integration requires Splunk ES 8.2 or higher due to the new Finding Events API and terminology changes (Notable Events → Finding Events, Comments → Notes).
For Splunk ES versions prior to 8.2, use the legacy SplunkPy integration.
For Splunk non-Enterprise Security Users, see Splunk non-Enterprise Security Users.

Fetching finding events

The integration allows for fetching Splunk Finding events using a default query. The query can be changed and modified to support different Splunk use cases.

Enriching finding events

This integration allows 3 types of enrichments for fetched findings: Drilldown, Asset, and Identity.

Enrichment types

Drilldown search enrichment: Fetches the drilldown searches configured by the user in the rule name that triggered the finding event and performs this search. The results are stored in the context of the incident under the Drilldown field as follows: [{‘query_name’:, 'query_search': , 'query_results': [{result1}, {result2}, {result3}], 'enrichment_status': }].
Asset search enrichment: Runs the following query:
| inputlookup append=T asset_lookup_by_str where asset=$ASSETS_VALUE | inputlookup append=t asset_lookup_by_cidr where asset=$ASSETS_VALUE | rename _key as asset_id | stats values(*) as * by asset_id
where the $ASSETS_VALUE is replaced with the src, dest, src_ip and dst_ip from the fetched finding. The results are stored in the context of the incident under the Asset field.
Identity search enrichment: Runs the following query
| inputlookup identity_lookup_expanded where identity=$IDENTITY_VALUE
where the $IDENTITY_VALUE is replaced with the user and src_user from the fetched finding event. The results are stored in the context of the incident under the Identity field.

How to configure

Configure the integration to fetch incidents.
Enrichment Types: Select the enrichment types you want to enrich each fetched finding with. If none are selected, the integration will fetch findings as usual (without enrichment).
Fetch events query: The query for fetching events. The default query is for fetching finding events. You can edit this query to fetch other types of events. Note that to fetch finding events, make sure the query uses the `notable` macro.
Enrichment Timeout (Minutes): The timeout for each enrichment (default is 5min). When the selected timeout was reached, finding events that were not enriched will be saved without the enrichment.
Number of Events Per Enrichment Type: The maximal amount of events to fetch per enrichment type (Drilldown, Asset, and Identity). In a case of multiple drilldown enrichments the limit will apply for each drilldown search query. (default to 20).

Troubleshooting enrichment status

Each enriched incident contains the following fields in the incident context:

successful_drilldown_enrichment: whether the drilldown enrichment was successful. In a case of multiple drilldown enrichments, the status is successful if at least one drilldown search enrichment was successful.
successful_asset_enrichment: whether the asset enrichment was successful.
successful_identity_enrichment: whether the identity enrichment was successful.

Resetting the enriching fetch mechanism

Run the Last Run button
Run the splunk-reset-enriching-fetch-mechanism command and the mechanism will be reset to the initial configuration.

Enrichment Limitations

As the enrichment process is asynchronous, fetching enriched incidents takes longer. The integration was tested with 20+ findings simultaneously that were fetched and enriched after approximately ~4min.
If you wish to configure a mapper, wait for the integration to perform the first fetch successfully. This is to make the fetch mechanism logic stable.
The drilldown search, does not support Splunk’s advanced syntax. For example: Splunk filters (** s**, ** h**, etc.)

Configure User Mapping between Splunk and Cortex XSOAR/XSIAM

When fetching incidents from Splunk to Cortex XSOAR and when mirroring incidents between Splunk and Cortex XSOAR, the Splunk Owner Name (user) associated with an incident needs to be mapped to the relevant Cortex XSOAR Owner Name (user).
You can use Splunk to define a user lookup table and then configure the SplunkPy v2 integration instance to enable the user mapping. Alternatively, you can map the users with a script or a transformer.

Note:

When mapping users, the specified Cortex XSOAR/XSIAM user must be a valid user in the system.
The Cortex XSOAR Owner incident field can only be used for mirroring changes out to Splunk, you cannot use it to update Cortex XSOAR incidents based on values from Splunk. To mirror changes in from Splunk, use the Assigned User incident field.

Configure User Mapping Using Splunk

Define the lookup table in Splunk.
1. Under App: Lookup Editor, select Lookup Editor.
2. Select Create a New Lookup > KV Store lookup.
3. Enter the Name for the table. For example, splunk_xsoar_users is the default lookup table name defined in the SplunkPy v2 integration settings.
4. Under App, select Enterprise Security.
5. Assign two Key-value collection schema fields, one for the Cortex XSOAR/XSIAM usernames and one for the corresponding Splunk usernames. For example, xsoar_user and splunk_user are the default field values defined in the SplunkPy v2 integration settings.
6. Click Create Lookup.
7. Add values to the table to map Cortex XSOAR/XSIAM users to the Splunk users.
Note:
If the user keys are defined already in another table, you can use that table name and relevant key names in the SplunkPy integration settings.
Configure the SplunkPy v2 integration instance.
1. Under Settings > Integrations, search for the SplunkPy v2 integration and create an instance.
2. In the Integration Settings:
  1. Select Enable user mapping.
  2. Set Users Lookup table name to the name of the lookup table defined in Splunk. By default it is splunk_xsoar_users.
  3. Set the XSOAR user key to the field defined in the Splunk lookup table. By default it is xsoar_user.
  4. Set the SPLUNK user key to the field defined in the Splunk lookup table. By default it is splunk_user.

Incident Mirroring

Important Notes

Mirroring-in is not supported when multiple Splunk integration instances are connected to the same Splunk server, meaning only one instance per Splunk server can be configured to perform mirroring-in.
This feature is available from Cortex XSOAR version 6.0.0.
This feature is supported by Splunk Enterprise Security only.
In order for the mirroring to work, the Incident Mirroring Direction parameter needs to be set before the incident is fetched.
In order to ensure the mirroring works as expected, mappers are required, both for incoming and outgoing, to map the expected fields in Cortex XSOAR and Splunk.
For mirroring the owner field, the usernames need to be transformed to the corresponding in Cortex XSOAR and Splunk.

Splunk Notes Mirroring

Splunk Notes Updates/Deletions - Editing or deleting existing Finding notes will NOT trigger mirroring to XSOAR on their own. Notes changes will only appear in the Splunk Notes field when a “real” change occurs in another finding field (such as status, owner, urgency, etc.), which triggers the mirror-in process. However, these changes will NOT update War Room notes. War Room notes from Splunk will NOT be deleted or updated.
Notes Display Behavior - The Splunk Notes field will display notes from the past week only. However, all notes that were mirrored via mirror-in will appear in the War Room notes.
Notes Time - Note timestamps will display the same time as shown in Splunk for the user who created the authentication token. The timezone offset is based on the timezone configured for that user in Splunk.

You can enable incident mirroring between Cortex XSOAR incidents and Splunk findings.

To set up mirroring:

Navigate to Settings > Integrations > Servers & Services.
Search for SplunkPy v2 and select your integration instance.
Enable Fetches incidents.
You can go to the Fetch events query parameter and select the query to fetch the findings from Splunk. Make sure to provide a query which uses the `notable` macro, See the default query as an example.
In the Incident Mirroring Direction integration parameter, select in which direction the incidents should be mirrored:
- Incoming - Any changes in Splunk findings (finding’s status, status_label, urgency, notes, and owner) will be reflected in Cortex XSOAR incidents.
- Outgoing - Any changes in Cortex XSOAR incidents (finding’s status, urgency, notes, and owner) will be reflected in Splunk findings.
- Incoming And Outgoing - Changes in Cortex XSOAR incidents and Splunk findings will be reflected in both directions.
- None - Turns off incident mirroring.
Optional: Check the Close Mirrored Cortex XSOAR Incidents (Incoming Mirroring) integration parameter to close the Cortex XSOAR incident when the corresponding finding is closed on the Splunk side.
By default, only Findings closed with a “Closed” label will be mirrored. You can specify specific statuses (comma-separated) in the Additional Splunk status labels to close on mirror (Incoming Mirroring), and enable the Enable Splunk statuses marked as “End Status” to close on mirror (Incoming Mirroring) option to add statuses marked as “End Status” in Splunk, and to add additional statuses to the mirroring process.
Optional: Check the Close Mirrored Splunk Finding Event integration parameter to close the Splunk finding when the corresponding Cortex XSOAR incident is closed.

Mapping fetched incidents using Select Schema

This integration supports the Select Schema feature of XSOAR 6.0 by providing the get-mapping-fields command.
When creating a new field mapping for fetched incidents, the Pull Instances option retrieves current incidents which can be clicked to visually map fields.
The Select Schema option retrieves possible objects, even if they are not the next objects to be fetched, or have not been triggered in the past 24 hours.
This enables you to map fields for an incident without having to generate a new alert or incident just for the sake of mapping.
The get-mapping-fields command can be executed in the Playground to test and review the list of sample objects that are returned under the current configuration.

To use this feature, you must set several integration instance parameters:

Fetch events query - The query used for fetching new incidents. Select Schema will run a modified version of this query to get the object samples, so it is important to have the correct query here.
First fetch timestamp - The time scope of objects to be pulled. You may choose to go back further in time to include samples for alert types that haven’t triggered recently - so long as your Splunk server can handle the more intensive Search Job involved.

Splunk non-Enterprise Security Users

Configure Splunk to Produce Alerts for SplunkPy v2 for non-ES Splunk Users

It is recommended that Splunk is configured to produce basic alerts that the SplunkPy v2 integration can ingest, by creating a summary index in which alerts are stored. The SplunkPy v2 integration can then query that index for incident ingestion. It is not recommended to use the Cortex XSOAR/XSIAM application with Splunk for routine event consumption because this method is not able to be monitored and is not scalable.

Create a summary index in Splunk. For more information, click here.
Build a query to return relevant alerts.
Identify the fields list from the Splunk query and save it to a local file.
Define a search macro to capture the fields list that you saved locally. For more information, click here.
Use the following naming convention: (demisto_fields_{type}).
Define a scheduled search, the results of which are stored in the summary index. For more information about scheduling searches, click here.
In the Summary indexing section, select the summary index, and enter the {key:value} pair for Cortex XSOAR/XSIAM classification.
Configure the incident type in Cortex XSOAR by navigating to Settings > Advanced > Incident Types. Note: In the example, Splunk Generic is a custom incident type.
Configure the classification. Make sure that your non ES incident fields are associated with your custom incident type.
1. Navigate to Settings > Integrations > Classification & Mapping.
2. Click your classifier.
3. Select your instance.
4. Click the fetched data.
5. Drag the value to the appropriate incident type.
Configure the mapping. Make sure to map your non ES fields accordingly and make sure that these incident fields are associated with their custom incident type.
1. Navigate to Settings > Integrations > Classification & Mapping.
2. Click your mapper.
3. Select your instance.
4. Click the Choose data path link for the field you want to map.
5. Click the data from the Splunk fields to map it to Cortex XSOAR.
(Optional) Create custom fields.
Build a playbook and assign it as the default for this incident type.

Constraints

The following features are not supported in non-ES (Enterprise Security) Splunk.

Incident Mirroring
Enrichment.
Content in the Splunk content pack (such as mappers, layout, playbooks, incident fields, and the incident type). Therefore, you will need to create your own content. See the Cortex XSOAR Administrator’s Guide for information.

Create KV Store

KV Store stores your data as key-value pairs in collections. It provides a way to save and retrieve data within your Splunk apps. The following is an example for how to create a KV Store.

In Cortex XSOAR/XSIAM, create a new KV Store.

!splunk-kv-store-collection-create kv_store_name=”<kv_store_name>“

For example:

!splunk-kv-store-collection-create kv_store_name=”test_kvstore”
Define the fields and their type in the KV Store.

!splunk-kv-store-collection-config kv_store_collection_name=”<kv_store_name>” kv_store_fields=”field.<field-name>=<type>,index.<index-name>=<type>,field.<field-name-or-index>=<type>,…“

For example:

!splunk-kv-store-collection-config kv_store_collection_name=”test_kvstore” kv_stre_fields=”field.src=cidr,field.t=number,field.description=string”

Note: To see the fields in Splunk, you must install the Splunk App for Lookup File Editing app in Splunk. For more information, see Define a KV Store lookup in Splunk.
Make the KV Store usable in Splunk queries.

!splunk-kv-store-collection-create-transform kv_store_collection_name=<kv-store-name> supported_fields=<field-name-or-index>,<field-name-or-index>,<field-name-or-index>,…

For example:

!splunk-kv-store-collection-create-transform kv_store_collection_name=<test_kvstore> supported_fields=src,t,description

Note: If no value is specified, the KV Store collection configuration will be used.

Add data to the KV Store

To add data to the fields in the KV Store, run the following command:

!splunk-kv-store-collection-add-entries kv_store_data=”{"<field-name-or-index>": "<value>", "<field-name-or-index>": "<value>", "<field-name-or-index>": "<value>"…}”

For example:

!splunk-kv-store-collection-add-entries kv_store_data=”{"src": "88.88.88.88", "t": 9, "description": This is the description"}”

Commands

You can execute these commands from the CLI, as part of an automation, or in a playbook.
After you successfully execute a command, a DBot message appears in the War Room with the command details.

splunk-results

Returns the results of a previous Splunk search. This command can be used in conjunction with the splunk-job-create command.

Base Command

splunk-results

Input

Argument Name	Description	Required
sid	The ID of the search for which to return results.	Required
limit	The maximum number of returned results per search. To retrieve all results, enter “0” (not recommended).	Optional

Context Output

There is no context output for this command.

Command Example

!splunk-results sid="1566221331.1186" limit="200"

splunk-search

Searches Splunk for events. For human readable output, the table command is supported in the query argument. For example, query=" * | table field1 field2 field3" will generate a table with field1, field2, and field3 as headers.

Base Command

splunk-search

Input

Argument Name	Description	Required
query	The Splunk search language string to execute. For example, “index=* \| head 3”.	Required
earliest_time	Specifies the earliest time in the time range to search. The time string can be a UTC time (with fractional seconds), a relative time specifier (to now), or a formatted time string. The default is 1 week ago, in the format “-7d”. You can also specify time in the format: 2014-06-19T12:00:00.000-07:00.	Optional
latest_time	Specifies the latest time in the time range to search. The time string can be a UTC time (with fractional seconds), a relative time specifier (to now), or a formatted time string. For example: “2014-06-19T12:00:00.000-07:00” or “-3d” (for 3 days ago).	Optional
event_limit	The maximum number of events to return. The default is 100. If “0” is selected, all results are returned.	Optional
app	The string that contains the application namespace in which to restrict searches.	Optional
batch_limit	The maximum number of returned results to process at a time. For example, if 100 results are returned, and you specify a `batch_limit` of 10, the results will be processed 10 at a time over 10 iterations. This does not affect the search or the context and outputs returned. In some cases, specifying a `batch_size` enhances search performance. If you think that the search execution is suboptimal, it is recommended to try several `batch_size` values to determine which works best for your search. The default is 25,000.	Optional
update_context	Determines whether the results will be entered into the context.	Optional
polling	Use XSOAR built-in polling to retrieve the result when it’s ready.	Optional
interval_in_seconds	Interval in seconds between each poll.	Optional
sid	The job sid.	Optional
fast_mode	Determines whether to retrieve the results in fast mode	Optional

Context Output

Path	Type	Description
Splunk.Result	Unknown	The results of the Splunk search. The results are a JSON array, in which each item is a Splunk event.
Splunk.JobStatus.SID	String	ID of the job.
Splunk.JobStatus.Status	String	Status of the job.
Splunk.JobStatus.TotalResults	String	The number of events that were returned by the job.

Command Example

!splunk-search query="* | head 3" earliest_time="-1000d"

Note: To display empty columns as well, the following should be added to the query: | fillnull value=

Human Readable Output

Splunk Search results for query: * | head 3

_bkt	_cd	_indextime	_kv	_raw	_serial	_si	_sourcetype	_time	host	index	linecount	source	sourcetype	splunk_server
main~445~66D21DF4-F4FD-4886-A986-82E72ADCBFE9	445:897774	1585462906	1	InsertedAt=”2020-03-29 06:21:43”; EventID=”837005”; EventType=”Application control”; Action=”None”; ComputerName=”ACME-code-007”; ComputerDomain=”DOMAIN”; ComputerIPAddress=”127.0.0.1”; EventTime=”2020-03-29 06:21:43”; EventTypeID=”5”; Name=”LogMeIn”; EventName=”LogMeIn”; UserName=””; ActionID=”6”; ScanTypeID=”200”; ScanType=”Unknown”; SubTypeID=”23”; SubType=”Remote management tool”; GroupName=””;\u003cbr\u003e	2	ip-172-31-44-193, main	sophos:appcontrol	2020-03-28T23:21:43.000-07:00	127.0.0.1	main	2	eventgen	sophos:appcontrol	ip-172-31-44-193

splunk-submit-event

Creates a new event in Splunk.

Base Command

splunk-submit-event

Input

Argument Name	Description	Required
index	The Splunk index to which to push the data. Run the `splunk-get-indexes` command to get all of the indexes.	Required
data	The new event data to push. Can be any string.	Required
sourcetype	The event source type.	Required
host	The event host. Can be “Local” or “120.0.0.1”.	Required

Context Output

There is no context output for this command.

Command Example

!splunk-submit-event index="main" data="test" sourcetype="demisto-ci" host="localhost"

Human Readable Output

splunk-get-indexes

Prints all Splunk index names.

Base Command

splunk-get-indexes

Input

There are no input arguments for this command.

Context Output

There is no context output for this command.

Command Example

!splunk-get-indexes extend-context="indexes="

Human Readable Output

splunk-finding-event-edit

Update an existing finding event in Splunk ES.

Base Command

splunk-finding-event-edit

Input

Argument Name	Description	Required
event_ids	A comma-separated list of event IDs of finding events.	Required
owner	The Splunk user to assign to the finding events.	Optional
note	The Note to add to the finding events.	Optional
urgency	The urgency of the finding events.	Optional
status	The status of the finding events. Can be one of the default options: Unassigned, Assigned, In Progress, Pending, Resolved, Closed Or you can specif another custom status.	Optional
disposition	The disposition of the finding events. Can be one of the default options: Unassigned, True Positive - Suspicious Activity, Benign Positive - Suspicious But Expected, False Positive - Incorrect Analytic Logic, False Positive - Inaccurate Data, Other, Undetermined. Or you can specify custom dispositions as `disposition:#` where `#` is the number of the custom configured disposition on Splunk.	Optional
finding_time	The time associated with the finding event (e.g., the `_time` field of the finding). Use this argument only when the command fails with error code MC_01202 or MC_0210, which indicate that the finding event time is required to complete the update.	Optional

Context Output

There is no context output for this command.

Command Example

!splunk-finding-event-edit event_ids=${incident.eventid} note="note from `splunk-finding-event-edit` command"

Human Readable Output

splunk-update-investigation

Updates existing investigations in Splunk ES. Supports updating fields such as owner, status, urgency, disposition, name, and description, adding a note, and appending finding IDs to the investigation.

Base Command

splunk-update-investigation

Input

Argument Name	Description	Required
event_ids	A comma-separated list of investigation IDs.	Required
owner	A Splunk user to assign to the investigations.	Optional
note	Note to add to the investigation.	Optional
disposition	Disposition of the investigation. If more options exist on the server, specifying the disposition as `disposition:#` will work in place of choosing one of the default values from the list. Possible values are: Unassigned, True Positive - Suspicious Activity, Benign Positive - Suspicious But Expected, False Positive - Incorrect Analytic Logic, False Positive - Inaccurate Data, Other, Undetermined.	Optional
status	Investigation status. Possible values are: New, Unassigned, In progress, Pending, Resolved, Closed.	Optional
urgency	Investigation urgency. Possible values are: critical, high, medium, low, informational.	Optional
name	Updated name for the investigation.	Optional
description	Updated description for the investigation.	Optional
findings	Comma-separated list of finding IDs to add (append) to the investigation. Only allowed when exactly one investigation ID is provided in `event_ids`.	Optional
finding_times	The list of times for findings added to the investigation. Value can be in relative, ISO, or epoch time. Ignored when `findings` is not provided. Only allowed when exactly one investigation ID is provided in `event_ids`.	Optional

Context Output

There is no context output for this command.

Command example

!splunk-update-investigation event_ids="ES00019"

Human Readable Output

Splunk ES events updated successfully:
Successfully updated Splunk ES event ES-00019

Command example (update name, description and append findings)

!splunk-update-investigation event_ids="ES00019" name="New investigation name" description="Updated description" findings="FND-1,FND-2" finding_times="1700000001,1700000002"

Human Readable Output

Splunk ES events updated successfully:
Successfully updated Splunk ES event ES-00019

splunk-job-create

Creates a new search job in Splunk.

Base Command

splunk-job-create

Input

Argument Name	Description	Required
query	The Splunk search language string to execute. For example, “index=* \| head 3”.	Required
app	The string that contains the application namespace in which to restrict searches.	Optional

Context Output

Path	Type	Description
Splunk.Job	Unknown	The SID of the created job.

Command Example

!splunk-job-create query="index=* | head 3"

Context Example

{
    "Splunk.Job": "1566221733.1628"
}

Human Readable Output

splunk-parse-raw

Parses the raw part of the event.

Base Command

splunk-parse-raw

Input

Argument Name	Description	Required
raw	The raw data of the Splunk event (string).	Optional

Context Output

Path	Type	Description
Splunk.Raw.Parsed	unknown	The raw event data (parsed).

Command Example

!splunk-parse-raw

splunk-submit-event-hec

Sends events Splunk. if batch_event_data or entry_id arguments are provided then all arguments related to a single event are ignored.

Base Command

splunk-submit-event-hec

Input

Argument Name	Description	Required
event	The event payload key-value pair. An example string: “event”: “Access log test message.”.	Optional
fields	Fields for indexing that do not occur in the event payload itself. Accepts multiple, comma-separated, fields.	Optional
index	The index name.	Optional
host	The hostname.	Optional
source_type	The user-defined event source type.	Optional
source	The user-defined event source.	Optional
time	The epoch-formatted time.	Optional
batch_event_data	A batch of events to send to Splunk. For example, `{"event": "something happened at 14/10/2024 12:29", "fields": {"severity": "INFO", "category": "test2, test2"}, "index": "index0","sourcetype": "sourcetype0","source": "/example/something" } {"event": "something happened at 14/10/2024 13:29", "index": "index1", "sourcetype": "sourcetype1","source": "/example/something", "fields":{ "fields" : "severity: INFO, category: test2, test2"}}`. If provided, the arguments related to a single event and the `entry_id` argument are ignored.	Optional
batch_event_data	A batch of events to send to splunk. For example, `{"event": "something happened at 14/10/2024 12:29", "fields": {"severity": "INFO", "category": "test2, test2"}, "index": "index0","sourcetype": "sourcetype0","source": "/example/something" } {"event": "something happened at 14/10/2024 13:29", "index": "index1", "sourcetype": "sourcetype1","source": "/exeample/something", "fields":{ "fields" : "severity: INFO, category: test2, test2"}}`. If provided, the arguments related to a single event and the `entry_id` argument are ignored.	Optional
entry_id	The entry id in Cortex XSOAR of the file containing a batch of events. Content of the file should be valid batch event’s data, as it would be provided to the `batch_event_data`. If provided, the arguments related to a single event are ignored.	Optional

Batched events description

This command allows sending events to Splunk, either as a single event or a batch of multiple events.
To send a single event: Use the event, fields, host, index, source, source_type, and time arguments.
To send a batch of events, there are two options, either use the batch_event_data argument or use the entry_id argument (for a file uploaded to Cortex XSOAR).
Batch format requirements: The batch must be a single string containing valid dictionaries, each representing an event. Events should not be separated by commas. Each dictionary should include all necessary fields for an event. For example: {"event": "event occurred at 14/10/2024 12:29", "fields": {"severity": "INFO", "category": "test1"}, "index": "index0", "sourcetype": "sourcetype0", "source": "/path/event1"} {"event": "event occurred at 14/10/2024 13:29", "index": "index1", "sourcetype": "sourcetype1", "source": "/path/event2", "fields": {"severity": "INFO", "category": "test2"}}.
This formatted string can be passed directly via batch_event_data, or, if saved in a file, the file can be uploaded to Cortex XSOAR, and the entry_id (e.g., ${File.[4].EntryID}) should be provided.

Context Output

There is no context output for this command.

Command Example

!splunk-submit-event-hec event="something happened" fields="severity: INFO, category: test, test1" source_type=access source="/var/log/access.log"

Human Readable Output

The event was sent successfully to Splunk.

splunk-job-status

Returns the status of a job.

Base Command

splunk-job-status

Input

Argument Name	Description	Required
sid	Comma-separated list of job IDs for which to retrieve the statuses.	Required

Context Output

Path	Type	Description
Splunk.JobStatus.SID	Unknown	The ID of the job.
Splunk.JobStatus.Status	Unknown	The status of the job.

Command Example

!splunk-job-status sid=1234.5667

Context Example

Splank.JobStatus = {
    'SID': 1234.5667,
    'Status': DONE
}

Human Readable Output

get-mapping-fields

Gets one sample alert per alert type. Used only for creating a mapping with Select Schema.

Base Command

get-mapping-fields

Input

There are no input arguments for this command.

Context Output

There is no context output for this command.

Command Example

!get-mapping-fields using="SplunkPy_v2_instance" raw-response="true"

Human Readable Output

{
    "Access - Brute Force Access Behavior Detected - Rule": {
        "_bkt": "notable~712~66D21DF4-F4FD-4886-A986-82E72ADCBFE9",
        "_cd": "712:21939",
        "_indextime": "1598464820",
        "_serial": "0",
        "_si": [
            "ip-1-1-1-1",
            "notable"
        ],
        "_sourcetype": "stash",
        "_time": "2020-08-26T11:00:20.000-07:00",
        "host": "ip-1-1-1-1",
        "host_risk_object_type": "system",
        "host_risk_score": "0",
        "index": "notable",
        "linecount": "1",
        "priority": "unknown",
        "risk_score": "460",
        "rule_description": "Access - Brute Force Access Behavior Detected - Rule",
        "rule_name": "Access - Brute Force Access Behavior Detected - Rule",
        "rule_title": "Access - Brute Force Access Behavior Detected - Rule",
        "security_domain": "Access - Brute Force Access Behavior Detected - Rule",
        "severity": "unknown",
        "source": "Access - Brute Force Access Behavior Detected - Rule",
        "sourcetype": "stash",
        "splunk_server": "ip-1-1-1-1",
        "src": "1.1.1.1",
        "src_risk_object_type": "system",
        "src_risk_score": "460",
        "urgency": "low"
    },
    "Access - Excessive Failed Logins - Rule": {
        "_bkt": "notable~712~66D21DF4-F4FD-4886-A986-82E72ADCBFE9",
        "_cd": "712:21515",
        "_indextime": "1598460945",
        "_serial": "22",
        "_si": [
            "ip-1-1-1-1",
            "notable"
        ],
        "_sourcetype": "stash",
        "_time": "2020-08-26T09:55:45.000-07:00",
        "host": "ip-1-1-1-1",
        "host_risk_object_type": "system",
        "host_risk_score": "0",
        "index": "notable",
        "linecount": "1",
        "priority": "unknown",
        "risk_score": "380",
        "rule_description": "Access - Excessive Failed Logins - Rule",
        "rule_name": "Access - Excessive Failed Logins - Rule",
        "rule_title": "Access - Excessive Failed Logins - Rule",
        "security_domain": "Access - Excessive Failed Logins - Rule",
        "severity": "unknown",
        "source": "Access - Excessive Failed Logins - Rule",
        "sourcetype": "stash",
        "splunk_server": "ip-1-1-1-1",
        "src": "1.1.1.1",
        "src_risk_object_type": "system",
        "src_risk_score": "380",
        "urgency": "low"
}

splunk-kv-store-collection-create

Creates a new KV store table.

Base Command

splunk-kv-store-collection-create

Input

Argument Name	Description	Required
kv_store_name	The name of the KV store collection.	Required
app_name	The name of the Splunk application in which to create the KV store. The default is “search”.	Required

Context Output

There is no context output for this command.

Command Example

!splunk-kv-store-collection-create app_name=search kv_store_name=demisto_store

Human Readable Output

KV store collection search created successfully

splunk-kv-store-collection-config

Configures the KV store fields.

Base Command

splunk-kv-store-collection-config

Input

Argument Name	Description	Required
kv_store_collection_name	The name of the KV store collection.	Required
kv_store_fields	The list of names and value types to define the KV store collection scheme, e.g., id=number, name=string, address=string.	Required
app_name	The name of the Splunk application that contains the KV store collection. The default is “search”.	Required

Context Output

There is no context output for this command.

Command Example

!splunk-kv-store-collection-config app_name=search kv_store_collection_name=demisto_store kv_store_fields=addr=string

Human Readable Output

KV store collection search configured successfully

splunk-kv-store-collection-add-entries

Adds objects to a KV store utilizing the batch-save API.

Base Command

splunk-kv-store-collection-add-entries

Input

Argument Name	Description	Required
kv_store_data	The data to add to the KV store collection, according to the collection JSON format, e.g., {“name”: “Splunk HQ”, “id”: 123, “address”: { “street”: “250 Brannan Street”, “city”: “San Francisco”, “state”: “CA”, “zip”: “94107”}}	Required
kv_store_collection_name	The name of the KV store collection.	Required
indicator_path	The path to the indicator value in kv_store_data.	Optional
app_name	The name of the Splunk application that contains the KV store collection. The default is “search”.	Required

Context Output

There is no context output for this command.

Command Example

!splunk-kv-store-collection-add-entries app_name=search kv_store_collection_name=demisto_store kv_store_data="{\"addr\": \"0.0.0.0\"}" indicator_path=addr

Human Readable Output

Data added to demisto_store

splunk-kv-store-collections-list

Lists all collections for the specified application.

Base Command

splunk-kv-store-collections-list

Input

Argument Name	Description	Required
app_name	The name of the Splunk application in which to create the KV store. The default is “search”.	Required

Context Output

Path	Type	Description
Splunk.CollectionList	String	List of collections.

Command Example

!splunk-kv-store-collections-list app_name=search

Context Example

{
    "Splunk": {
        "CollectionList": [
            "autofocus_tags",
            "files"
        ]
    }
}

Human Readable Output

list of collection names search

name

autofocus_tags

files

name
autofocus_tags
files

splunk-kv-store-collection-data-list

Lists all data within a specific KV store collection or collections.

Base Command

splunk-kv-store-collection-data-list

Input

Argument Name	Description	Required
app_name	The name of the Splunk application that contains the KV store collection. Default is search.	Required
kv_store_collection_name	A comma-separated list of KV store collections.	Required
limit	Maximum number of records to return. The default is 50.	Optional

Context Output

Path	Type	Description
Splunk.KVstoreData	Unknown	An array of collection names. Each collection name will have an array of values, e.g., Splunk.KVstoreData.<collection_name> is a list of the data in the collection.

Command Example

!splunk-kv-store-collection-data-list app_name=search limit=3 kv_store_collection_name=demisto_store

Context Example

{
    "Splunk": {
        "KVstoreData": {
            "demisto_store": [
                {
                    "_key": "5f4e2e9c097d9e6749453536",
                    "_user": "nobody",
                    "addr": "0.0.0.0"
                }
            ]
        }
    }
}

Human Readable Output

list of collection values demisto_store

_key _user addr

5f4e2e9c097d9e6749453536 nobody 0.0.0.0

_key	_user	addr
5f4e2e9c097d9e6749453536	nobody	0.0.0.0

splunk-kv-store-collection-data-delete

Deletes all data within the specified KV store collection or collections.

Base Command

splunk-kv-store-collection-data-delete

Input

Argument Name	Description	Required
app_name	The name of the Splunk application that contains the KV store collection. For example, “search”.”	Required
kv_store_collection_name	A comma-separated list of KV store collections.	Required

Context Output

There is no context output for this command.

Command Example

!splunk-kv-store-collection-data-delete app_name=search kv_store_collection_name=demisto_store

Human Readable Output

The values of the demisto_store were deleted successfully

splunk-kv-store-collection-delete

Deletes the specified KV stores.

Base Command

splunk-kv-store-collection-delete

Input

Argument Name	Description	Required
app_name	The name of the Splunk application that contains the KV store. The default is “search”.	Required
kv_store_name	A comma-separated list of KV stores.	Required

Context Output

There is no context output for this command.

Command Example

!splunk-kv-store-collection-delete app_name=search kv_store_name=demisto_store

Human Readable Output

The following KV store demisto_store were deleted successfully

splunk-kv-store-collection-search-entry

Searches for specific objects in a store. Search can be a basic key-value pair or a full query.

Base Command

splunk-kv-store-collection-search-entry

Input

Argument Name	Description	Required
app_name	The name of the Splunk application that contains the KV store collection. The default is “search”.	Required
kv_store_collection_name	The name of the KV store collection	Required
key	The key name to search in the store. If the query argument is used, this argument will be ignored.	Optional
value	The value to search in the store. If the query argument is used, this argument will be ignored.	Optional
query	Complex query to search in the store with operators such as “and”, “or”, “not”, etc. For more information see the Splunk documentation: https://docs.splunk.com/Documentation/Splunk/8.0.3/RESTREF/RESTkvstore	Optional

Context Output

Path	Type	Description
Splunk.KVstoreData	Unknown	An array of collection names. Each collection name will have an array of values, e.g., Splunk.KVstoreData.<collection_name> is a list of the data in the collection.

Command Example

!splunk-kv-store-collection-search-entry app_name=search kv_store_collection_name=demisto_store key=addr value=0.0.0.0

Context Example

{
    "Splunk": {
        "KVstoreData": {
            "demisto_store": [
                {
                    "_key": "5f4e2e9c097d9e6749453536",
                    "_user": "nobody",
                    "addr": "0.0.0.0"
                }
            ]
        }
    }
}

Human Readable Output

list of collection values demisto_store

_key _user addr

5f4e2e9c097d9e6749453536 nobody 0.0.0.0

_key	_user	addr
5f4e2e9c097d9e6749453536	nobody	0.0.0.0

splunk-kv-store-collection-delete-entry

Deletes the specified object in store. Search can be a basic key-value pair or a full query.

Base Command

splunk-kv-store-collection-delete-entry

Input

Argument Name	Description	Required
app_name	The name of the Splunk application that contains the KV store collection. The default is “search”.	Required
kv_store_collection_name	The name of the KV store collection.	Required
indicator_path	The path to the indicator value in kv_store_data.	Optional
key	The key name to search in the store. If the query argument is used, this argument will be ignored.	Optional
value	The value to search in the store. If the query argument is used, this argument will be ignored.	Optional
query	Complex query to search in the store with operators such as “and”, “or”, “not”, etc. For more information see the Splunk documentation: https://docs.splunk.com/Documentation/Splunk/8.0.3/RESTREF/RESTkvstore	Optional

Context Output

There is no context output for this command.

Command Example

!splunk-kv-store-collection-delete-entry app_name=search kv_store_collection_name=demisto_store key=addr value=0.0.0.0 indicator_path=addr

Human Readable Output

The values of the demisto_store were deleted successfully

get-modified-remote-data

Gets the list of finding events that were modified since the last update. This command should be used for debugging purposes, and is available from Cortex XSOAR version 6.1.

Base Command

get-modified-remote-data

Input

Argument Name	Description	Required
lastUpdate	ISO format date with timezone, e.g., 2021-02-09T16:41:30.589575+02:00. The incident is only returned if it was modified after the last update time.	Required

Context Output

There is no context output for this command.

splunk-reset-enriching-fetch-mechanism

Resets the enriching fetch mechanism.

Base Command

splunk-reset-enriching-fetch-mechanism

Input

There are no input arguments for this command.

Context Output

There is no context output for this command.

Command Example


#### Human Readable Output

>Enriching fetch mechanism was reset successfully.

### splunk-get-username-by-xsoar-user

***
Returns the Splunk's username matching the given Cortex XSOAR's username.

#### Base Command

`splunk-get-username-by-xsoar-user`

#### Input

| **Argument Name** | **Description** | **Required** |
| --- | --- | --- |
| xsoar_username | Cortex XSOAR username to match in Splunk's usernames records. | Required |

#### Context Output

| **Path** | **Type** | **Description** |
| --- | --- | --- |
| Splunk.UserMapping.XsoarUser | String | Cortex XSOAR user mapping. |
| Splunk.UserMapping.SplunkUser | String | Splunk user mapping. |

#### Command Example

```!splunk-get-username-by-xsoar-user xsoar_username=admin```

#### Context Example

{
“Splunk”: {
“UserMapping”: [
{
“SplunkUser”: “unassigned”,
“XsoarUser”: “admin”
}
]
}
}
```

Human Readable Output

Xsoar-Splunk Username Mapping

Xsoar User Splunk User

admin unassigned

Xsoar User	Splunk User
admin	unassigned

splunk-kv-store-collection-create-transform

Creates the KV store collection transform.

Base Command

splunk-kv-store-collection-create-transform

Input

Argument Name	Description	Required
kv_store_collection_name	The name of the KV store collection.	Required
supported_fields	A comma-delimited list of the fields supported by the collection, e.g., _key,id,name,address. If no value is specified, the KV Store collection configuration will be used.	Optional
app_name	The name of the Splunk application that contains the KV store collection. Default is search.	Required

Context Output

There is no context output for this command.

splunk-job-share

Change job settings to share its results to all Splunk users, and change its TTL.

Base Command

splunk-job-share

Input

Argument Name	Description	Required
sid	Comma-separated list of job IDs to share.	Required
ttl	Time in seconds for the job’s expiry time. Default is 1800.	Optional

Context Output

There is no context output for this command.

splunk-investigation-create

Creates a new investigation in Splunk Enterprise Security.

Base Command

splunk-investigation-create

Input

Argument Name	Description	Required
name	The name of the investigation to be created.	Required
description	The description of the investigation to be created.	Optional
investigation_type	The type of the investigation to be created (for example, `default`).	Optional
status	The status of the investigation to be created. Defaults to the out-of-the-box Splunk ES status labels; custom statuses are also supported by typing the status ID or label. Possible values are: New, In Progress, Pending, Resolved, Closed.	Optional
disposition	The disposition of the investigation to be created. Defaults to the out-of-the-box Splunk ES disposition labels; custom dispositions are also supported by typing the disposition ID or label. Possible values are: Undetermined, True Positive - Suspicious Activity, Benign Positive - Suspicious But Expected, False Positive - Incorrect Analytic Logic, False Positive - Inaccurate Data, Other.	Optional
owner	The Splunk user to assign as the owner of the investigation.	Optional
urgency	The urgency of the investigation to be created. Possible values are: informational, low, medium, high, critical, unknown.	Optional
sensitivity	The sensitivity of the investigation to be created. Possible values are: White, Green, Amber, Red, Unassigned.	Optional

Context Output

Path	Type	Description
Splunk.Investigation.investigation_guid	String	The ID (GUID) of the investigation that was created.

splunk-investigation-list

Lists investigations from Splunk Enterprise Security.

Base Command

splunk-investigation-list

Input

Argument Name	Description	Required
investigation_ids	A comma-separated list of investigation IDs (GUID or display ID such as `ES-00001`) to retrieve.	Optional
limit	The maximum number of investigations to return on the page. Maximum is 100. Default is 20.	Optional
offset	The pagination offset used together with `limit` to specify the starting point of the returned results.	Optional
sort	The sort expression for the returned investigations (for example, `create_time:asc,status:desc`).	Optional
disposition	A comma-separated list of disposition IDs or disposition labels to filter investigations by (for example, `disposition:1,Undetermined`).	Optional
status	A comma-separated list of status IDs or status labels to filter investigations by (for example, `New,In progress`).	Optional
owner	A comma-separated list of owners to filter investigations by.	Optional
urgency	A comma-separated list of urgency values to filter investigations by (for example, `medium,high,critical`). Valid values are `informational`, `low`, `medium`, `high`, `critical`, or `unknown`.	Optional
sensitivity	A comma-separated list of sensitivity values to filter investigations by (for example, `Amber,Red`). Valid values are `White`, `Green`, `Amber`, `Red`, or `Unassigned`.	Optional
create_time_min	The minimum (epoch) time during which investigations were created.	Optional
create_time_max	The maximum (epoch) time during which investigations were created.	Optional
update_time_min	The minimum (epoch) time during which investigations were updated.	Optional
update_time_max	The maximum (epoch) time during which investigations were updated.	Optional

Context Output

Path	Type	Description
Splunk.Investigation.investigation_guid	String	The ID (GUID) of the investigation.
Splunk.Investigation.investigation_id	String	The short display ID of the investigation (for example, `ES-00001`).
Splunk.Investigation.name	String	The name of the investigation.
Splunk.Investigation.description	String	The description of the investigation.
Splunk.Investigation.investigation_type	String	The type of the investigation.
Splunk.Investigation.source	String	The detection that generated the investigation.
Splunk.Investigation.incident_origin	String	Where the investigation came from (for example, Splunk Enterprise Security or a risk-based alerting finding).
Splunk.Investigation.finding_id	String	The ID of the originating Splunk Enterprise Security finding.
Splunk.Investigation.disposition	String	The disposition ID of the investigation.
Splunk.Investigation.disposition_name	String	The disposition name of the investigation.
Splunk.Investigation.status	String	The status ID of the investigation.
Splunk.Investigation.status_name	String	The status name of the investigation.
Splunk.Investigation.owner	String	The person assigned to the investigation.
Splunk.Investigation.urgency	String	The urgency of the investigation.
Splunk.Investigation.sensitivity	String	The sensitivity of the investigation.
Splunk.Investigation.create_time	Number	The time when the investigation was created (epoch seconds).
Splunk.Investigation.update_time	Number	The time when the investigation was last updated (epoch seconds).
Splunk.Investigation.mc_create_time	Number	The time when the finding or investigation was created or imported into Splunk Enterprise Security (epoch seconds).
Splunk.Investigation.count_findings	Number	The number of findings (or intermediate findings) associated with this investigation or finding-based-detection (FBD) group.
Splunk.Investigation.risk_event_count	Number	The number of risk events associated with this investigation.
Splunk.Investigation.risk_score	Number	The maximum risk score for all the findings added to the investigation.
Splunk.Investigation.excluded_finding_ids	Unknown	A list of finding IDs (or intermediate findings in the finding groups) that are removed from the investigation.
Splunk.Investigation.attachments	Unknown	An array of file IDs attached directly to the investigation.
Splunk.Investigation.notes	Unknown	An array of note IDs added directly to the finding or investigation.
Splunk.Investigation.findings.incident_ids	Unknown	The added finding IDs.
Splunk.Investigation.findings.field_inheritors	Unknown	The added finding IDs that will inherit this investigation’s owner, status, urgency, sensitivity, and disposition values.
Splunk.Investigation.current_response_plan_phase.phase_id	String	The ID of the current response plan phase.
Splunk.Investigation.current_response_plan_phase.response_plan_id	String	The ID of the current response plan.
Splunk.Investigation.response_plans	Unknown	The array of response plans added to the investigation.
Splunk.Investigation.consolidated_findings	Unknown	The consolidated list of fields for the findings and all the findings that are added to this investigation.
Splunk.Investigation.finding	Unknown	The raw data of the originating finding.
Splunk.Investigation.custom_fields	Unknown	The custom fields in the investigation.
Splunk.Investigation.src	Unknown	A list of values for the `source` field.
Splunk.Investigation.dest	Unknown	A list of values for the `destination` field.
Splunk.Investigation.dvc	Unknown	A list of values for the `device` field.
Splunk.Investigation.orig_host	Unknown	A list of values for the `host` field.
Splunk.Investigation.src_user	Unknown	A list of values for the `source user` field.
Splunk.Investigation.user	Unknown	A list of values for the `user` field.
Splunk.Investigation.risk_object	Unknown	The list of entities for a finding, finding group, or investigation.
Splunk.Investigation.risk_object_type	Unknown	The list of risk object types for a finding, finding group, or investigation.

Additional Information

To get the HEC token

Go to the Splunk UI.
Under Settings > Data > Data inputs, click HTTP Event Collector.
Click New Token.
Add all the relevant details until done.

For the HTTP Port number:
Click on Global settings (in the HTTP Event Collector page)
Screen Shot 2020-01-20 at 10 27 25

The default port is 8088.

Troubleshooting

Index Validation Issues

In some cases, the Splunk API may not return a complete list of all available indexes. If you try to submit an event to an index that you know exists but the integration reports that it cannot be found, it may be due to this Splunk issue. The integration will log an error message specifying which indexes could not be verified.

Recommended Action:

Verify that the index name is spelled correctly in your request.
If the index exists and is accessible in Splunk but is not found by the integration, please contact Splunk support for assistance, as this is a known limitation with the Splunk API.

Connectivity Issues

If you encounter connectivity issues while using Splunk Cloud within Cortex XSOAR8 or Cortex XSIAM you may receive the following error:

requests.exceptions.ConnectTimeout:
HTTPSConnectionPool(host='<name>.splunkcloud.com', port=8089)
: Max retries exceeded with url: /services/auth/login (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7fc389a4e170>,
 'Connection to <name>.splunkcloud.com timed out. 
(connect timeout=None)'))

To resolve this issue, add the IP addresses of Cortex XSOAR8 or Cortex XSIAM to the Splunk Cloud whitelist.
You can find the relevant IP addresses at:
Cortex XSOAR Administrator Guide
Under Used for communication between Cortex XSOAR and customer resources. Choose the IP address corresponding to your Cortex XSOAR region.

Fetch Issues

If you encounter fetch issues and you have enriching enabled, the issue may be the result of pressing the Reset the "last run" timestamp button.
Note that the way to reset the mechanism is to run the splunk-reset-enriching-fetch-mechanism command.
See here.

Large Search Results

Commands that return large data (such as splunk-search) can cause performance issues in playbooks.

Recommendation: Limit results to approximately 30,000 events, depending on the data size. You can do this through one of the following:

Use the event_limit argument (where available).
Append | head 30000 directly to your Splunk query.

splunk-configuration-stanza-create

Creates a new stanza (configuration entry) in a Splunk .conf file, optionally with attributes.

Base Command

splunk-configuration-stanza-create

Input

Argument Name	Description	Required
conf_file	The configuration file name (without the .conf extension), for example, “transforms”, “props”, or “inputs”.	Required
stanza_name	The name of the new stanza to create.	Required
key_value_pairs	The JSON object string of attributes to set on creation, e.g., {“external_type”: “kvstore”, “collection”: “my_collection”}. If omitted, an empty stanza is created.	Optional
app	The name of the Splunk application namespace. Default is search.	Optional
owner	The Access Control List (ACL) owner for the namespace. Default is nobody.	Optional

Context Output

There is no context output for this command.

splunk-configuration-stanza-list

Lists the stanzas in a .conf file, or returns the key/value content of a single stanza when stanza_name is provided.

Base Command

splunk-configuration-stanza-list

Input

Argument Name	Description	Required
conf_file	The configuration file name (without the .conf extension).	Required
stanza_name	The name of the stanza to return. If provided, returns the key/value content of that single stanza. If omitted, returns the list of all stanza names in the configuration file.	Optional
app	The name of the Splunk application namespace. Default is search.	Optional
owner	The Access Control List (ACL) owner for the namespace. Default is nobody.	Optional
limit	The maximum number of stanzas to return when stanza_name is omitted. Range 1-500. Default is 50.	Optional

Context Output

Path	Type	Description
Splunk.ConfigurationStanza.StanzaName	String	The stanza name.
Splunk.ConfigurationStanza.App	String	The Splunk app namespace the stanza belongs to.
Splunk.ConfigurationStanza.Owner	String	The Access Control List (ACL) owner of the stanza.
Splunk.ConfigurationStanza.Sharing	String	The sharing level of the stanza.
Splunk.ConfigurationStanza.Content	Unknown	The key/value content of the stanza (only returned when a single stanza_name is provided).

splunk-configuration-file-create

Creates a new, empty configuration (.conf) file in the given Splunk app namespace.

Base Command

splunk-configuration-file-create

Input

Argument Name	Description	Required
conf_file_name	The name of the new configuration file to create (without the .conf extension).	Required
app	The name of the Splunk application namespace in which to create the file. Default is search.	Optional
owner	The Access Control List (ACL) owner for the namespace. Default is nobody.	Optional

Context Output

There is no context output for this command.

splunk-configuration-file-list

Lists the configuration (.conf) files available in the given Splunk app namespace.

Base Command

splunk-configuration-file-list

Input

Argument Name	Description	Required
app	The name of the Splunk application namespace. Default is search.	Optional
owner	The Access Control List (ACL) owner for the namespace. Default is nobody.	Optional
limit	The maximum number of configuration files to return. Range 1-500. Default is 50.	Optional

Context Output

Path	Type	Description
Splunk.ConfigurationFile.FileName	String	The configuration file name (without the .conf suffix).
Splunk.ConfigurationFile.App	String	The Splunk app namespace the configuration file belongs to.

splunk-configuration-stanza-delete

Deletes a stanza (configuration entry) from a Splunk .conf file (for example, transforms.conf) via the Splunk REST API configuration endpoints. This is useful for cleaning up KV Store transformations that remain after deleting KV Store records.
To identify the correct stanza for deletion, use the splunk-configuration-file-list and splunk-configuration-stanza-list commands. This command is potentially harmful as it irreversibly deletes a stanza from a .conf file.

Base Command

splunk-configuration-stanza-delete

Input

Argument Name	Description	Required
conf_file	The target configuration file name (without the .conf extension).	Required
stanza_name	The name of the stanza to be removed.	Required
app	The name of the Splunk application namespace. Default is search.	Optional
owner	The Access Control List (ACL) owner for the namespace. Default is nobody.	Optional

Context Output

There is no context output for this command.

splunk-configuration-stanza-update

Updates (upserts) attributes on an existing stanza in a Splunk .conf file.

Base Command

splunk-configuration-stanza-update

Input

Argument Name	Description	Required
conf_file	The configuration file name (without the .conf extension).	Required
stanza_name	The name of the existing stanza to update.	Required
key_value_pairs	The JSON object string of attributes to upsert, e.g., {“attribute_1”: “A_updated”, “new_attr”: “X”}. Existing keys are overwritten; missing keys are left untouched (Splunk’s properties endpoint is upsert-only).	Required
app	The name of the Splunk application namespace. Default is search.	Optional
owner	The Access Control List (ACL) owner for the namespace. Default is nobody.	Optional

Context Output

There is no context output for this command.

<~PLATFORM>

License Requirements

The following configuration parameters require one of these licenses: Cortex XSIAM or Agentix:

Fetch incidents

</~PLATFORM>

Configuration parameters

server_url — Server URL (required)
authentication — (required)
fetchQuery — Fetch events query
max_fetch — Fetch Limit (Max.- 200, Recommended less than 50)
isFetch — Fetch incidents
incidentType — Incident type
parseFindingEventsRaw — Parse Raw Part of Finding Events
replaceKeys — Replace with Underscore in Incident Fields
first_fetch — First fetch timestamp (<number> <time unit>, e.g., 12 hours, 7 days, 3 months, 1 year)
fetch_event_types — Event types to fetch
investigations_first_fetch — First fetch timestamp (Investigations)
investigations_fetch_query — Investigations fetch query
investigations_max_fetch — Maximum investigations per fetch
extractFields — Extract Fields - CSV fields that will be parsed out of raw finding events
mirror_direction — Incident Mirroring Direction
close_incident — Close Mirrored Cortex XSOAR Incidents (Incoming Mirroring)
close_extra_labels — Additional Splunk status labels to close on mirror (Incoming Mirroring)
close_end_status_statuses — Enable Splunk statuses marked as "End Status" to close on mirror (Incoming Mirroring)
close_finding — Close Mirrored Splunk ES Events (Outgoing Mirroring)
unsecure — Trust any certificate (not secure)
proxy — Use system proxy settings
app — The app context of the namespace
enabled_enrichments — Enrichment Types
asset_enrich_lookup_tables — Asset enrichment lookup tables
identity_enrich_lookup_tables — Identity enrichment lookup tables
enrichment_timeout — Enrichment Timeout (Minutes)
num_enrichment_events — Number of Events Per Enrichment Type
cred_hec_token —
hec_url — HEC BASE URL (e.g: https://localhost:8088 or https://example.splunkcloud.com/).
extensive_logs — Advanced: Extensive logging (for debugging purposes). Do not use this option unless advised otherwise.
finding_time_source — Advanced: Time type to use when fetching events
occurrence_look_behind — Advanced: Fetch backwards window for the events occurrence time (minutes)
unique_id_fields — Advanced: Unique ID Fields
userMapping — Enable user mapping
user_map_lookup_name — Users Lookup table name
xsoar_user_field — XSOAR user key
splunk_user_field — SPLUNK user key
note_tag_from_splunk — Note tag from Splunk
note_tag_to_splunk — Note tag to Splunk
incidentFetchInterval — Incidents Fetch Interval

Commands (33)

get-mapping-fields
Query Splunk to retrieve a list of sample alerts by alert type. Used for mapping fetched incidents through the Get Schema option.
get-modified-remote-data
Gets the list of finding events that were modified since the last update. This command should be used for debugging purposes, and is available from Cortex XSOAR version 6.1.
splunk-configuration-file-create
Creates a new, empty configuration (.conf) file in the given Splunk app namespace.
splunk-configuration-file-list
Lists the configuration (.conf) files available in the given Splunk app namespace.
splunk-configuration-stanza-create
Creates a new stanza (configuration entry) in a Splunk .conf file, optionally with attributes.
splunk-configuration-stanza-delete
Deletes a stanza (configuration entry) from a Splunk .conf file (for example, transforms.conf) via the Splunk REST API configuration endpoints. This is useful for cleaning up KV Store transformations that remain after deleting KV Store records. To identify the correct stanza for deletion, use the splunk-configuration-file-list and splunk-configuration-stanza-list commands. This command is potentially harmful as it irreversibly deletes a stanza from a .conf file.
splunk-configuration-stanza-list
Lists the stanzas in a .conf file, or returns the key/value content of a single stanza when stanza_name is provided.
splunk-configuration-stanza-update
Updates (upserts) attributes on an existing stanza in a Splunk .conf file.
splunk-finding-event-edit
Updates existing finding events in Splunk ES.
splunk-get-indexes
Prints all Splunk index names.
splunk-get-username-by-xsoar-user
Returns the Splunk's username matching the given Cortex XSOAR's username.
splunk-investigation-create
Creates a new investigation in Splunk Enterprise Security.
splunk-investigation-list
Lists investigations from Splunk Enterprise Security.
splunk-job-create
Creates a new search job in Splunk.
splunk-job-share
Change job settings to share its results to all Splunk users, and change its TTL.
splunk-job-status
Returns the status of a job.
splunk-kv-store-collection-add-entries
Adds objects to a KV store utilizing the batch-save API.
splunk-kv-store-collection-config
Configures the KV store fields.
splunk-kv-store-collection-create
Creates a new KV store table.
splunk-kv-store-collection-create-transform
Creates the KV store collection transform.
splunk-kv-store-collection-data-delete
Deletes all data within the specified KV store collection or collections.
splunk-kv-store-collection-data-list
Lists all data within a specific KV store collection or collections.
splunk-kv-store-collection-delete
Deletes the specified KV stores.
splunk-kv-store-collection-delete-entry
Deletes the specified object in store. The search can be a basic key-value pair or a full query.
splunk-kv-store-collection-search-entry
Searches for specific objects in a store. The search can be a basic key-value pair or a full query.
splunk-kv-store-collections-list
Lists all collections for the specified application.
splunk-parse-raw
Parses the raw part of the event.
splunk-reset-enriching-fetch-mechanism
Resets the enrichment mechanism of fetched findings.
splunk-results
Returns the results of a previous Splunk search. You can use this command in conjunction with the splunk-job-create command.
splunk-search
Searches Splunk for events. For human readable output, the table command is supported in the query argument. For example, `query=" * | table field1 field2 field3"` will generate a table with field1, field2, and field3 as headers.
splunk-submit-event
Creates a new event in Splunk.
splunk-submit-event-hec
Sends events to an HTTP Event Collector using the Splunk platform JSON event protocol.
splunk-update-investigation
Updates existing investigations in Splunk ES. Supports updating fields such as owner, status, urgency, disposition, name, and description, adding a note, and appending finding IDs to the investigation. Note that `findings` (and `finding_times`) can only be used when exactly one investigation ID is provided in `event_ids`.

Source

SplunkPyV2.py SplunkPyV2_test.py SplunkPyV2.yml SplunkPyV2_description.md

Download History Raw

category: Analytics & SIEM
provider: Cisco Systems
commonfields:
  id: SplunkPy v2
  version: -1
sectionorder:
- Connect
- Collect
configuration:
- display: Server URL
  name: server_url
  required: true
  type: 0
  section: Connect
  defaultvalue: 'https://splunk.example.com'
  additionalinfo: "The Splunk server URL. Port 8089 (Splunk's default REST API port) is used automatically. Only include the port in the URL if using a non-default port. Examples: 'https://splunk.example.com' (uses default port 8089) or 'https://splunk.example.com:8090' (uses custom port 8090)."
- display: ""
  displaypassword: Splunk Token
  hiddenusername: true
  name: authentication
  required: true
  type: 9
  section: Connect
- additionalinfo: The Splunk search query by which to fetch events. The default query fetches ES finding events. You can edit this query to fetch other types of events. Note, that to fetch ES finding events, make sure to include the \`notable\` macro in your query.
  defaultvalue: search `notable` | eval rule_name=if(isnull(rule_name),source,rule_name) | eval rule_title=if(isnull(rule_title),rule_name,rule_title) | `get_urgency` | `risk_correlation` | eval rule_description=if(isnull(rule_description),source,rule_description) | eval security_domain=if(isnull(security_domain),source,security_domain) | expandtoken
  display: Fetch events query
  name: fetchQuery
  type: 0
  section: Collect
  required: false
- defaultvalue: '50'
  display: Fetch Limit (Max.- 200, Recommended less than 50)
  name: max_fetch
  type: 0
  section: Collect
  required: false
  supportedModules:
  - agentix
  - xsiam
- display: Fetch incidents
  name: isFetch
  type: 8
  section: Collect
  required: false
  supportedModules:
  - agentix
  - xsiam
- display: Incident type
  name: incidentType
  type: 13
  section: Collect
  required: false
  supportedModules:
  - agentix
  - xsiam
- defaultvalue: 'false'
  display: Parse Raw Part of Finding Events
  name: parseFindingEventsRaw
  type: 8
  section: Collect
  advanced: true
  required: false
  additionalinfo: Whether to parse the raw part of the Findings, or not.
- defaultvalue: 'false'
  display: Replace with Underscore in Incident Fields
  name: replaceKeys
  type: 8
  section: Collect
  advanced: true
  required: false
  additionalinfo: Whether to replace special characters to underscore when parsing the raw data of the Findings, or not.
- additionalinfo: The amount of time to go back when performing the first fetch, or when creating a mapping using the Select Schema option.
  defaultvalue: 10 minutes
  display: First fetch timestamp (<number> <time unit>, e.g., 12 hours, 7 days, 3 months, 1 year)
  name: first_fetch
  type: 0
  section: Collect
  required: false
- display: Event types to fetch
  name: fetch_event_types
  type: 16
  section: Collect
  advanced: true
  required: false
  defaultvalue: Finding
  options:
  - Finding
  - Investigation
  additionalinfo: Select the Splunk event types to ingest. Default is `Finding`.
- display: First fetch timestamp (Investigations)
  name: investigations_first_fetch
  type: 0
  section: Collect
  advanced: true
  required: false
  defaultvalue: 10 minutes
  additionalinfo: The relative time interval to look back during the initial investigation fetch (for example, 12 hours, 7 days, 3 months).
- display: Investigations fetch query
  name: investigations_fetch_query
  type: 0
  section: Collect
  advanced: true
  required: false
  defaultvalue: |
    | rest "/servicesNS/nobody/missioncontrol/public/v2/investigations?search_format=true&FETCH_FILTER_PLACEHOLDER"
  additionalinfo: The SPL query used when "Investigation" is selected for "Event types to fetch". The query must include the `FETCH_FILTER_PLACEHOLDER` token. Do not modify or remove this token. For more information on customizing the query (for example, adding the filter &status=New), see the integration documentation under "Fetching investigation events".
- display: Maximum investigations per fetch
  name: investigations_max_fetch
  type: 0
  section: Collect
  advanced: true
  required: false
  defaultvalue: '50'
  additionalinfo: The maximum number of investigations to fetch per cycle. Limited to 100 by the Splunk investigations endpoint.
- display: Extract Fields - CSV fields that will be parsed out of raw finding events
  name: extractFields
  type: 0
  section: Collect
  advanced: true
  required: false
- additionalinfo: 'Choose the direction to mirror the incident: Incoming (from Splunk to Cortex XSOAR), Outgoing (from Cortex XSOAR to Splunk), or Incoming and Outgoing (from/to Cortex XSOAR and Splunk).'
  defaultvalue: None
  display: Incident Mirroring Direction
  name: mirror_direction
  options:
  - None
  - Incoming
  - Outgoing
  - Incoming And Outgoing
  type: 15
  section: Collect
  hidden:
  - marketplacev2
  - platform
  required: false
- additionalinfo: When selected, closing the Splunk finding event with a "Closed" status will close the Cortex XSOAR incident.
  defaultvalue: 'false'
  display: Close Mirrored Cortex XSOAR Incidents (Incoming Mirroring)
  name: close_incident
  type: 8
  section: Collect
  advanced: true
  hidden:
  - marketplacev2
  - platform
  required: false
- display: Additional Splunk status labels to close on mirror (Incoming Mirroring)
  name: close_extra_labels
  type: 0
  section: Collect
  advanced: true
  additionalinfo: "A comma-separated list of Splunk status labels to mirror as closed Cortex XSOAR incident (Example: Resolved,False-Positive)."
  required: false
- additionalinfo: When selected, automatically close the Cortex XSOAR incident when the Splunk ES event (Finding or Investigation) is marked as 'End Status'.
  defaultvalue: 'false'
  display: Enable Splunk statuses marked as "End Status" to close on mirror (Incoming Mirroring)
  name: close_end_status_statuses
  type: 8
  section: Collect
  advanced: true
  required: false
  hidden:
  - marketplacev2
  - platform
- display: Close Mirrored Splunk ES Events (Outgoing Mirroring)
  name: close_finding
  type: 8
  section: Collect
  advanced: true
  hidden:
  - marketplacev2
  - platform
  additionalinfo: When selected, automatically close the corresponding Splunk ES event (Finding or Investigation) when the Cortex XSOAR incident is closed.
  defaultvalue: 'false'
  required: false
- display: Trust any certificate (not secure)
  name: unsecure
  type: 8
  section: Connect
  advanced: true
  required: false
- name: proxy
  type: 8
  section: Connect
  advanced: true
  display: Use system proxy settings
  required: false
- display: 'The app context of the namespace'
  name: app
  type: 0
  section: Collect
  advanced: true
  required: false
- display: 'Enrichment Types'
  name: enabled_enrichments
  type: 16
  section: Collect
  advanced: true
  additionalinfo: Enrichment types to enrich each fetched finding. If none are selected, the integration will fetch findings as usual (without enrichment). For more info about enrichment types see the integration additional info.
  options:
  - Drilldown
  - Asset
  - Identity
  required: false
- additionalinfo: CSV of the Splunk lookup tables from which to take the Asset enrichment data.
  defaultvalue: asset_lookup_by_str,asset_lookup_by_cidr
  display: Asset enrichment lookup tables
  name: asset_enrich_lookup_tables
  type: 0
  required: false
  section: Collect
  advanced: true
- additionalinfo: CSV of the Splunk lookup tables from which to take the Identity enrichment data.
  defaultvalue: identity_lookup_expanded
  display: Identity enrichment lookup tables
  name: identity_enrich_lookup_tables
  type: 0
  required: false
  section: Collect
  advanced: true
- display: 'Enrichment Timeout (Minutes)'
  name: enrichment_timeout
  type: 0
  section: Collect
  advanced: true
  additionalinfo: When the selected timeout was reached, finding events that were not enriched will be saved without the enrichment.
  defaultvalue: '5'
  required: false
- additionalinfo: The limit of how many events to retrieve per each one of the enrichment types (Drilldown, Asset, and Identity). In a case of multiple drilldown enrichments the limit will apply for each drilldown search query. To retrieve all events, enter "0" (not recommended).
  display: 'Number of Events Per Enrichment Type'
  name: num_enrichment_events
  type: 0
  section: Collect
  advanced: true
  defaultvalue: '20'
  required: false
- name: cred_hec_token
  type: 9
  section: Collect
  advanced: true
  displaypassword: HEC Token (HTTP Event Collector)
  hiddenusername: true
  required: false
  display: ''
- display: 'HEC BASE URL (e.g: https://localhost:8088 or https://example.splunkcloud.com/).'
  name: hec_url
  type: 0
  section: Collect
  advanced: true
  required: false
- display: 'Advanced: Extensive logging (for debugging purposes). Do not use this option unless advised otherwise.'
  name: extensive_logs
  type: 8
  section: Collect
  advanced: true
  required: false
- display: 'Advanced: Time type to use when fetching events'
  name: finding_time_source
  type: 15
  defaultvalue: "creation time"
  options:
  - "creation time"
  - "index time (Beta)"
  additionalinfo: |
    Defines which timestamp will be used to filter the events:
    - creation time: Filters based on when the event actually occurred.
    - index time (Beta): *Beta feature* – Filters based on when the event was ingested into Splunk.  
      This option is still in testing and may not behave as expected in all scenarios.  
      When using this mode, the parameter "Fetch backwards window for the events occurrence time (minutes)" should be set to `0``, as indexing time ensures there are no delay-based gaps.
      The default is "creation time".
  section: Collect
  advanced: true
  required: false
- defaultvalue: '15'
  display: 'Advanced: Fetch backwards window for the events occurrence time (minutes)'
  name: occurrence_look_behind
  type: 0
  section: Collect
  advanced: true
  additionalinfo: The fetch time range will be at least the size specified here. This will support events that have a gap between their occurrence time and their index time in Splunk. To decide how long the backwards window should be, you need to determine the average time between them both in your Splunk environment.
  required: false
- display: 'Advanced: Unique ID Fields'
  name: unique_id_fields
  type: 0
  section: Collect
  advanced: true
  required: false
  additionalinfo: 'A comma-separated list of additional fields to use when generating unique incident IDs for events that are not findings (i.e., queries without the `notable` macro). By default, the integration uses: _cd, index, _time, _indextime, _raw. If these fields do not provide unique values in your environment, specify additional fields here to ensure incident uniqueness. Example: source,host,unique_field'
- defaultvalue: 'false'
  display: Enable user mapping
  name: userMapping
  type: 8
  section: Collect
  advanced: true
  required: false
  additionalinfo: Whether to enable the user mapping between Cortex XSOAR and Splunk, or not. For more information see https://xsoar.pan.dev/docs/reference/integrations/splunk-py#configure-user-mapping-between-splunk-and-cortex-xsoar
- defaultvalue: 'splunk_xsoar_users'
  display: Users Lookup table name
  name: user_map_lookup_name
  type: 0
  section: Collect
  advanced: true
  additionalinfo: The name of the lookup table in Splunk, containing the username's mapping data.
  required: false
- defaultvalue: 'xsoar_username'
  display: XSOAR user key
  name: xsoar_user_field
  type: 0
  section: Collect
  advanced: true
  additionalinfo: The name of the lookup column containing the Cortex XSOAR username.
  required: false
- defaultvalue: 'splunk_username'
  display: SPLUNK user key
  name: splunk_user_field
  type: 0
  section: Collect
  advanced: true
  additionalinfo: The name of the lookup table containing the Splunk username.
  required: false
- display: Note tag from Splunk
  name: note_tag_from_splunk
  defaultvalue: FROM SPLUNK
  type: 0
  section: Collect
  advanced: true
  required: false
  additionalinfo: Add this tag to an entry to mirror it as a note from Splunk.
- display: Note tag to Splunk
  name: note_tag_to_splunk
  defaultvalue: FROM XSOAR
  type: 0
  section: Collect
  advanced: true
  required: false
  additionalinfo: Add this tag to an entry to mirror it as a note to Splunk.
- defaultvalue: '1'
  display: Incidents Fetch Interval
  name: incidentFetchInterval
  type: 19
  section: Collect
  advanced: true
  required: false
  supportedModules:
  - agentix
  - xsiam
description: Run queries on Splunk and fetch Splunk ES Findings and Investigations (Splunk ES 8.2+).
display: SplunkPy v2
name: SplunkPy v2
script:
  commands:
  - arguments:
    - default: true
      description: ID of the search for which to return results.
      name: sid
      required: true
    - defaultValue: '100'
      description: The maximum number of returned results per search. To retrieve all results, enter "0" (not recommended).
      name: limit
    description: Returns the results of a previous Splunk search. You can use this command in conjunction with the splunk-job-create command.
    name: splunk-results
  - arguments:
    - default: true
      description: 'The Splunk search language string to execute. For example: "index=* | head 3". '
      name: query
      required: true
    - description: 'Specifies the earliest time in the time range to search. The time string can be a UTC time (with fractional seconds), a relative time specifier (to now), or a formatted time string. Default is 1 week ago, in the format "-7d". You can also specify time in the format: 2014-06-19T12:00:00.000-07:00.'
      name: earliest_time
    - description: 'Specifies the latest time in the time range to search. The time string can be a UTC time (with fractional seconds), a relative time specifier (to now), or a formatted time string. For example: "2014-06-19T12:00:00.000-07:00" or "-3d" (for 3 days ago).'
      name: latest_time
    - description: Maximum number of events to return. Default is 100. If "0", all results are returned.
      name: event_limit
    - defaultValue: '25000'
      description: The maximum number of returned results to process at a time. For example, if 100 results are returned, and you specify a batch_limit of 10, the results will be processed 10 at a time over 10 iterations. This does not effect the search or the context and outputs returned. In some cases, specifying a batch_size enhances search performance. If you think that the search execution is suboptimal, we recommend trying several batch_size values to determine which works best for your search. Default is 25,000.
      name: batch_limit
    - auto: PREDEFINED
      defaultValue: 'true'
      description: 'Determines whether the results will be entered into the context. Possible values: "true" and "false".'
      name: update_context
      predefined:
      - 'true'
      - 'false'
    - description: A string that contains the application namespace in which to restrict searches.
      name: app
    - auto: PREDEFINED
      description: Use XSOAR built-in polling to retrieve the result when it's ready.
      name: polling
      predefined:
      - 'true'
      - 'false'
    - defaultValue: '30'
      description: Interval in seconds between each poll.
      name: interval_in_seconds
    - description: The job sid.
      name: sid
    - auto: PREDEFINED
      defaultValue: 'false'
      description: The Fast mode prioritizes the performance of the search and does not return nonessential field or event data. This means that the search returns what is essential and required if fast_mode equals 'true'.
      name: fast_mode
      predefined:
      - 'true'
      - 'false'
    description: Searches Splunk for events. For human readable output, the table command is supported in the query argument. For example, `query=" * | table field1 field2 field3"` will generate a table with field1, field2, and field3 as headers.
    name: splunk-search
    polling: true
    outputs:
    - contextPath: Splunk.Result
      description: The results of the Splunk search. The results are a JSON array, in which each item is a Splunk event.
      type: Unknown
    - contextPath: Splunk.JobStatus.SID
      description: ID of the job.
      type: String
    - contextPath: Splunk.JobStatus.Status
      description: Status of the job.
      type: String
    - contextPath: Splunk.JobStatus.TotalResults
      description: The number of events that were returned by the job.
      type: String
  - arguments:
    - description: Splunk index in which to push data. Run the splunk-get-indexes command to get all indexes.
      name: index
      required: true
    - default: true
      description: The new event data to push. Can be any string.
      name: data
      required: true
    - description: Event source type.
      name: sourcetype
      required: true
    - description: Event host. Can be "Local" or "120.0.0.1".
      name: host
      required: true
    description: Creates a new event in Splunk.
    name: splunk-submit-event
  - description: Prints all Splunk index names.
    name: splunk-get-indexes
    arguments: []
  - arguments:
    - description: A comma-separated list of event IDs of finding events.
      name: event_ids
      required: true
      isArray: true
    - description: A Splunk user to assign to the finding events.
      name: owner
    - description: Note to add to the finding events.
      name: note
    - auto: PREDEFINED
      description: 'Finding event urgency. Possible values: "critical", "high", "medium", "low", and "informational".'
      name: urgency
      predefined:
      - critical
      - high
      - medium
      - low
      - informational
    - auto: PREDEFINED
      description: Finding event status.
      name: status
      predefined:
      - Unassigned
      - Assigned
      - In Progress
      - Pending
      - Resolved
      - Closed
    - name: disposition
      auto: PREDEFINED
      predefined:
      - Unassigned
      - True Positive - Suspicious Activity
      - Benign Positive - Suspicious But Expected
      - False Positive - Incorrect Analytic Logic
      - False Positive - Inaccurate Data
      - Other
      - Undetermined
      description: Disposition of the finding. If the more options exist on the server, specifying the disposition as `disposition:#` will work in place of choosing one of the default values from the list.
    - description: The time associated with the finding event (e.g., the `_time` field of the finding). Use this argument only when the command fails with error code MC_01202 or MC_0210, which indicate that the finding event time is required to complete the update.
      name: finding_time
    description: Updates existing finding events in Splunk ES.
    execution: true
    name: splunk-finding-event-edit
  - arguments:
    - description: A comma-separated list of investigation IDs.
      name: event_ids
      required: true
      isArray: true
    - description: The Splunk user to assign to the investigations.
      name: owner
    - description: The note to add to the investigation.
      name: note
    - name: disposition
      auto: PREDEFINED
      predefined:
      - Unassigned
      - True Positive - Suspicious Activity
      - Benign Positive - Suspicious But Expected
      - False Positive - Incorrect Analytic Logic
      - False Positive - Inaccurate Data
      - Other
      - Undetermined
      description: The disposition to set for the investigation. To use a custom disposition not available in the dropdown, provide the numerical ID using the format disposition:# (for example, disposition:12).
    - auto: PREDEFINED
      description: The investigation status.
      name: status
      predefined:
      - New
      - Unassigned
      - In progress
      - Pending
      - Resolved
      - Closed
    - auto: PREDEFINED
      description: 'The investigation urgency. Possible values: "critical", "high", "medium", "low", and "informational".'
      name: urgency
      predefined:
      - critical
      - high
      - medium
      - low
      - informational
    - description: Updated name for the investigation.
      name: name
    - description: Updated description for the investigation.
      name: description
    - description: Comma-separated list of finding IDs to add (append) to the investigation. Only allowed when exactly one investigation ID is provided in `event_ids`.
      name: findings
      isArray: true
    - description: The list of times for findings added to the investigation. Value can be in relative, ISO, or epoch time. Ignored when `findings` is not provided. Only allowed when exactly one investigation ID is provided in `event_ids`.
      name: finding_times
      isArray: true
    description: Updates existing investigations in Splunk ES. Supports updating fields such as owner, status, urgency, disposition, name, and description, adding a note, and appending finding IDs to the investigation. Note that `findings` (and `finding_times`) can only be used when exactly one investigation ID is provided in `event_ids`.
    execution: true
    name: splunk-update-investigation
  - arguments:
    - description: The Splunk search language string to execute. For example :"index=* | head 3".
      name: query
      required: true
    - description: A string that contains the application namespace in which to restrict searches.
      name: app
    description: Creates a new search job in Splunk.
    name: splunk-job-create
    outputs:
    - contextPath: Splunk.Job
      description: The SID of the created job.
      type: Unknown
  - arguments:
    - default: true
      defaultValue: ${Splunk.Result._raw}
      description: The raw data of the Splunk event (string).
      name: raw
    description: Parses the raw part of the event.
    name: splunk-parse-raw
    outputs:
    - contextPath: Splunk.Raw.Parsed
      description: The raw event data (parsed).
      type: unknown
  - arguments:
    - description: |-
        Event payload key-value pair.
        String example: "event": "Access log test message".
      name: event
    - description: Fields for indexing that do not occur in the event payload itself. Accepts multiple, comma-separated, fields.
      name: fields
    - description: The index name.
      name: index
    - description: The hostname.
      name: host
    - description: User-defined event source type.
      name: source_type
    - description: User-defined event source.
      name: source
    - description: Epoch-formatted time.
      name: time
    - description: A channel identifier (ID) where to send the request, must be a Globally Unique Identifier (GUID). If the indexer acknowledgment is turned on, a channel is required.
      name: request_channel
    - description: 'A  batch of events to send to Splunk. For example, `{"event": "something happened at 14/10/2024 12:29", "fields": {"severity": "INFO", "category": "test2, test2"}, "index": "index0","sourcetype": "sourcetype0","source": "/example/something" } {"event": "something happened at 14/10/2024 13:29", "index": "index1", "sourcetype": "sourcetype1","source": "/example/something", "fields":{ "fields" : "severity: INFO, category: test2, test2"}}`. If provided all arguments except of `request_channel` are ignored.'
      name: batch_event_data
    - description: The entry ID in Cortex XSOAR of the file containing a batch of events. If provided, the arguments related to a single event are ignored.
      name: entry_id
    description: Sends events to an HTTP Event Collector using the Splunk platform JSON event protocol.
    name: splunk-submit-event-hec
  - arguments:
    - description: Comma-separated list of job IDs for which to retrieve the statuses.
      name: sid
      required: true
      isArray: true
    description: Returns the status of a job.
    name: splunk-job-status
    outputs:
    - contextPath: Splunk.JobStatus.SID
      description: ID of the job.
      type: String
    - contextPath: Splunk.JobStatus.Status
      description: Status of the job.
      type: String
  - arguments:
    - description: The name of the KV store collection.
      name: kv_store_name
      required: true
    - default: true
      defaultValue: search
      description: The name of the Splunk application in which to create the KV store. The default is "search".
      name: app_name
      required: true
    description: Creates a new KV store table.
    name: splunk-kv-store-collection-create
  - arguments:
    - description: The name of the KV store collection.
      name: kv_store_collection_name
      required: true
    - description: |
        The list of names and value types used to define the KV store collection scheme, e.g., id=number, name=string, address=string.
      isArray: true
      name: kv_store_fields
      required: true
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store collection. The default is "search".
      name: app_name
      required: true
    description: Configures the KV store fields.
    name: splunk-kv-store-collection-config
  - arguments:
    - description: The name of the KV store collection.
      name: kv_store_collection_name
      required: true
    - description: |
        A comma-delimited list of the fields supported by the collection, e.g., _key,id,name,address. If no value is specified, the KV Store collection configuration will be used.
      name: supported_fields
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store collection.
      name: app_name
      required: true
    description: Creates the KV store collection transform.
    name: splunk-kv-store-collection-create-transform
  - arguments:
    - description: 'The data to add to the KV store collection, according to the collection JSON format, e.g., [{"name": "Splunk HQ", "id": 456, "address": { "street": "340 Brannan Street", "city": "San Francisco", "state": "CA", "zip": "121212"}}, {"name": "Splunk HQ", "id": 123, "address": { "street": "250 Brannan Street", "city": "San Francisco", "state": "CA", "zip": "94107"}}].'
      name: kv_store_data
      required: true
    - description: The name of the KV store collection.
      name: kv_store_collection_name
      required: true
    - description: The path to the indicator value in kv_store_data.
      name: indicator_path
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store collection. The default is "search".
      name: app_name
      required: true
    description: Adds objects to a KV store utilizing the batch-save API.
    name: splunk-kv-store-collection-add-entries
  - arguments:
    - default: true
      defaultValue: search
      description: The name of the Splunk application in which to create the KV store. The default is "search".
      name: app_name
      required: true
    description: Lists all collections for the specified application.
    name: splunk-kv-store-collections-list
    outputs:
    - contextPath: Splunk.CollectionList
      description: List of collections.
      type: String
  - arguments:
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store collection. The default is "search".
      name: app_name
      required: true
    - description: A comma-separated list of KV store collections.
      isArray: true
      name: kv_store_collection_name
      required: true
    - defaultValue: '50'
      description: Maximum number of records to return. The default is 50.
      name: limit
    description: Lists all data within a specific KV store collection or collections.
    name: splunk-kv-store-collection-data-list
    outputs:
    - contextPath: Splunk.KVstoreData
      description: An array of collection names. Each collection name will have an array of values, e.g., Splunk.KVstoreData.<collection_name> is a list of the data in the collection.
      type: Unknown
  - arguments:
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store collection. For example, "search".
      name: app_name
      required: true
    - description: A comma-separated list of KV store collections.
      isArray: true
      name: kv_store_collection_name
      required: true
    description: Deletes all data within the specified KV store collection or collections.
    name: splunk-kv-store-collection-data-delete
  - arguments:
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store. The default is "store".
      name: app_name
      required: true
    - description: A comma-separated list of KV stores.
      isArray: true
      name: kv_store_name
      required: true
    description: Deletes the specified KV stores.
    name: splunk-kv-store-collection-delete
  - arguments:
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store collection. The default is "search".
      name: app_name
      required: true
    - description: The name of the KV store collection.
      name: kv_store_collection_name
      required: true
    - description: The key name to search in the store. If the query argument is used, this argument will be ignored.
      name: key
    - description: The value to search in the store. If the query argument is used, this argument will be ignored.
      name: value
    - description: 'Complex query to search in the store with operators such as "and", "or", "not", etc. For more information, see the Splunk documentation: https://docs.splunk.com/Documentation/Splunk/8.0.3/RESTREF/RESTkvstore.'
      name: query
    description: Searches for specific objects in a store. The search can be a basic key-value pair or a full query.
    name: splunk-kv-store-collection-search-entry
    outputs:
    - contextPath: Splunk.KVstoreData
      description: An array of collection names. Each collection name will have an array of values, e.g., Splunk.KVstoreData.<collection_name> is a list of the data in the collection.
      type: Unknown
  - arguments:
    - default: true
      defaultValue: search
      description: The name of the Splunk application that contains the KV store collection. The default is "search".
      name: app_name
      required: true
    - description: The name of the KV store collection.
      name: kv_store_collection_name
      required: true
    - description: The path to the indicator value in kv_store_data.
      name: indicator_path
    - description: The key name to search in the store. If the query argument is used, this argument will be ignored.
      name: key
    - description: The value to search in the store. If the query argument is used, this argument will be ignored.
      name: value
    - description: |-
        Complex query to search in the store with operators such as "and", "or", "not", etc.
        For more information, see the Splunk documentation: https://docs.splunk.com/Documentation/Splunk/8.0.3/RESTREF/RESTkvstore.
      name: query
    description: Deletes the specified object in store. The search can be a basic key-value pair or a full query.
    name: splunk-kv-store-collection-delete-entry
  - arguments:
    - default: true
      defaultValue: search
      description: The name of the Splunk application namespace.
      name: app
      type: string
    - defaultValue: nobody
      description: The Access Control List (ACL) owner for the namespace.
      name: owner
      type: string
    - defaultValue: '50'
      description: The maximum number of configuration files to return. Range 1-500.
      name: limit
      type: number
    description: Lists the configuration (.conf) files available in the given Splunk app namespace.
    name: splunk-configuration-file-list
    outputs:
    - contextPath: Splunk.ConfigurationFile.FileName
      description: The configuration file name (without the .conf suffix).
      type: String
    - contextPath: Splunk.ConfigurationFile.App
      description: The Splunk app namespace the configuration file belongs to.
      type: String
  - arguments:
    - description: The name of the new configuration file to create (without the .conf extension).
      name: conf_file_name
      required: true
      type: string
    - default: true
      defaultValue: search
      description: The name of the Splunk application namespace in which to create the file.
      name: app
      type: string
    - defaultValue: nobody
      description: The Access Control List (ACL) owner for the namespace.
      name: owner
      type: string
    description: Creates a new, empty configuration (.conf) file in the given Splunk app namespace.
    name: splunk-configuration-file-create
  - arguments:
    - description: The configuration file name (without the .conf extension), for example, "transforms", "props", or "inputs".
      name: conf_file
      required: true
      type: string
    - description: The name of the new stanza to create.
      name: stanza_name
      required: true
      type: string
    - description: 'The JSON object string of attributes to set on creation, e.g., {"external_type": "kvstore", "collection": "my_collection"}. If omitted, an empty stanza is created.'
      name: key_value_pairs
      type: string
    - default: true
      defaultValue: search
      description: The name of the Splunk application namespace.
      name: app
      type: string
    - defaultValue: nobody
      description: The Access Control List (ACL) owner for the namespace.
      name: owner
      type: string
    description: Creates a new stanza (configuration entry) in a Splunk .conf file, optionally with attributes.
    name: splunk-configuration-stanza-create
  - arguments:
    - description: The configuration file name (without the .conf extension).
      name: conf_file
      required: true
      type: string
    - description: The name of the stanza to return. If provided, returns the key/value content of that single stanza. If omitted, returns the list of all stanza names in the configuration file.
      name: stanza_name
      type: string
    - default: true
      defaultValue: search
      description: The name of the Splunk application namespace.
      name: app
      type: string
    - defaultValue: nobody
      description: The Access Control List (ACL) owner for the namespace.
      name: owner
      type: string
    - defaultValue: '50'
      description: The maximum number of stanzas to return when stanza_name is omitted. Range 1-500.
      name: limit
      type: number
    description: Lists the stanzas in a .conf file, or returns the key/value content of a single stanza when stanza_name is provided.
    name: splunk-configuration-stanza-list
    outputs:
    - contextPath: Splunk.ConfigurationStanza.StanzaName
      description: The stanza name.
      type: String
    - contextPath: Splunk.ConfigurationStanza.App
      description: The Splunk app namespace the stanza belongs to.
      type: String
    - contextPath: Splunk.ConfigurationStanza.Owner
      description: The Access Control List (ACL) owner of the stanza.
      type: String
    - contextPath: Splunk.ConfigurationStanza.Sharing
      description: The sharing level of the stanza.
      type: String
    - contextPath: Splunk.ConfigurationStanza.Content
      description: The key/value content of the stanza (only returned when a single stanza_name is provided).
      type: Unknown
  - arguments:
    - description: The configuration file name (without the .conf extension).
      name: conf_file
      required: true
      type: string
    - description: The name of the existing stanza to update.
      name: stanza_name
      required: true
      type: string
    - description: 'The JSON object string of attributes to upsert, e.g., {"attribute_1": "A_updated", "new_attr": "X"}. Existing keys are overwritten; missing keys are left untouched (Splunk''s properties endpoint is upsert-only).'
      name: key_value_pairs
      required: true
      type: string
    - default: true
      defaultValue: search
      description: The name of the Splunk application namespace.
      name: app
      type: string
    - defaultValue: nobody
      description: The Access Control List (ACL) owner for the namespace.
      name: owner
      type: string
    description: Updates (upserts) attributes on an existing stanza in a Splunk .conf file.
    name: splunk-configuration-stanza-update
  - arguments:
    - description: The target configuration file name (without the .conf extension).
      name: conf_file
      required: true
      type: string
    - description: The name of the stanza to be removed.
      name: stanza_name
      required: true
      type: string
    - default: true
      defaultValue: search
      description: The name of the Splunk application namespace.
      name: app
      type: string
    - defaultValue: nobody
      description: The Access Control List (ACL) owner for the namespace.
      name: owner
      type: string
    description: |-
      Deletes a stanza (configuration entry) from a Splunk .conf file (for example, transforms.conf) via the Splunk REST API configuration endpoints. This is useful for cleaning up KV Store transformations that remain after deleting KV Store records.
      To identify the correct stanza for deletion, use the splunk-configuration-file-list and splunk-configuration-stanza-list commands. This command is potentially harmful as it irreversibly deletes a stanza from a .conf file.
    name: splunk-configuration-stanza-delete
  - description: Query Splunk to retrieve a list of sample alerts by alert type. Used for mapping fetched incidents through the Get Schema option.
    name: get-mapping-fields
    arguments: []
  - arguments:
    - description: ISO format date with timezone, e.g., 2021-02-09T16:41:30.589575+02:00. The incident is only returned if it was modified after the last update time.
      name: lastUpdate
    description: Gets the list of finding events that were modified since the last update. This command should be used for debugging purposes, and is available from Cortex XSOAR version 6.1.
    name: get-modified-remote-data
  - description: Resets the enrichment mechanism of fetched findings.
    name: splunk-reset-enriching-fetch-mechanism
    arguments: []
  - arguments:
    - default: true
      description: Cortex XSOAR username to match in Splunk's usernames records.
      isArray: true
      name: xsoar_username
      required: true
    description: Returns the Splunk's username matching the given Cortex XSOAR's username.
    name: splunk-get-username-by-xsoar-user
    outputs:
    - contextPath: Splunk.UserMapping.XsoarUser
      description: Cortex XSOAR user mapping.
      type: String
    - contextPath: Splunk.UserMapping.SplunkUser
      description: Splunk user mapping.
      type: String
  - arguments:
    - description: Comma-separated list of job IDs to share.
      isArray: true
      name: sid
      required: true
    - defaultValue: '1800'
      description: Time in seconds for the job's expiry time.
      name: ttl
    description: Change job settings to share its results to all Splunk users, and change its TTL.
    name: splunk-job-share
  - arguments:
    - description: The name of the investigation to be created.
      name: name
      required: true
    - description: The description of the investigation to be created.
      name: description
    - description: The type of the investigation to be created (for example, `default`).
      name: investigation_type
    - auto: PREDEFINED
      description: The status of the investigation to be created. Defaults to the out-of-the-box Splunk ES status labels; custom statuses are also supported by typing the status ID or label.
      name: status
      predefined:
      - New
      - In Progress
      - Pending
      - Resolved
      - Closed
    - auto: PREDEFINED
      description: The disposition of the investigation to be created. Defaults to the out-of-the-box Splunk ES disposition labels; custom dispositions are also supported by typing the disposition ID or label.
      name: disposition
      predefined:
      - Undetermined
      - 'True Positive - Suspicious Activity'
      - 'Benign Positive - Suspicious But Expected'
      - 'False Positive - Incorrect Analytic Logic'
      - 'False Positive - Inaccurate Data'
      - Other
    - description: The Splunk user to assign as the owner of the investigation.
      name: owner
    - auto: PREDEFINED
      description: The urgency of the investigation to be created.
      name: urgency
      predefined:
      - informational
      - low
      - medium
      - high
      - critical
      - unknown
    - auto: PREDEFINED
      description: The sensitivity of the investigation to be created.
      name: sensitivity
      predefined:
      - White
      - Green
      - Amber
      - Red
      - Unassigned
    description: Creates a new investigation in Splunk Enterprise Security.
    execution: true
    name: splunk-investigation-create
    outputs:
    - contextPath: Splunk.Investigation.investigation_guid
      description: The ID (GUID) of the investigation that was created.
      type: String
  - arguments:
    - description: A comma-separated list of investigation IDs (GUID or display ID such as `ES-00001`) to retrieve.
      name: investigation_ids
      isArray: true
    - defaultValue: '20'
      description: The maximum number of investigations to return on the page. Maximum is 100.
      name: limit
    - description: The pagination offset used together with `limit` to specify the starting point of the returned results.
      name: offset
    - description: The sort expression for the returned investigations (for example, `create_time:asc,status:desc`).
      name: sort
    - description: A comma-separated list of disposition IDs or disposition labels to filter investigations by (for example, `disposition:1,Undetermined`).
      name: disposition
      isArray: true
    - description: A comma-separated list of status IDs or status labels to filter investigations by (for example, `New,In progress`).
      name: status
      isArray: true
    - description: A comma-separated list of owners to filter investigations by.
      name: owner
      isArray: true
    - description: A comma-separated list of urgency values to filter investigations by (for example, `medium,high,critical`). Valid values are `informational`, `low`, `medium`, `high`, `critical`, or `unknown`.
      name: urgency
      isArray: true
    - description: A comma-separated list of sensitivity values to filter investigations by (for example, `Amber,Red`). Valid values are `White`, `Green`, `Amber`, `Red`, or `Unassigned`.
      name: sensitivity
      isArray: true
    - description: The minimum (epoch) time during which investigations were created.
      name: create_time_min
    - description: The maximum (epoch) time during which investigations were created.
      name: create_time_max
    - description: The minimum (epoch) time during which investigations were updated.
      name: update_time_min
    - description: The maximum (epoch) time during which investigations were updated.
      name: update_time_max
    description: Lists investigations from Splunk Enterprise Security.
    name: splunk-investigation-list
    outputs:
    - contextPath: Splunk.Investigation.investigation_guid
      description: The ID (GUID) of the investigation.
      type: String
    - contextPath: Splunk.Investigation.investigation_id
      description: The short display ID of the investigation (for example, `ES-00001`).
      type: String
    - contextPath: Splunk.Investigation.name
      description: The name of the investigation.
      type: String
    - contextPath: Splunk.Investigation.description
      description: The description of the investigation.
      type: String
    - contextPath: Splunk.Investigation.investigation_type
      description: The type of the investigation.
      type: String
    - contextPath: Splunk.Investigation.source
      description: The detection that generated the investigation.
      type: String
    - contextPath: Splunk.Investigation.incident_origin
      description: Where the investigation came from (for example, Splunk Enterprise Security or a risk-based alerting finding).
      type: String
    - contextPath: Splunk.Investigation.finding_id
      description: The ID of the originating Splunk Enterprise Security finding.
      type: String
    - contextPath: Splunk.Investigation.disposition
      description: The disposition ID of the investigation.
      type: String
    - contextPath: Splunk.Investigation.disposition_name
      description: The disposition name of the investigation.
      type: String
    - contextPath: Splunk.Investigation.status
      description: The status ID of the investigation.
      type: String
    - contextPath: Splunk.Investigation.status_name
      description: The status name of the investigation.
      type: String
    - contextPath: Splunk.Investigation.owner
      description: The person assigned to the investigation.
      type: String
    - contextPath: Splunk.Investigation.urgency
      description: The urgency of the investigation.
      type: String
    - contextPath: Splunk.Investigation.sensitivity
      description: The sensitivity of the investigation.
      type: String
    - contextPath: Splunk.Investigation.create_time
      description: The time when the investigation was created (epoch seconds).
      type: Number
    - contextPath: Splunk.Investigation.update_time
      description: The time when the investigation was last updated (epoch seconds).
      type: Number
    - contextPath: Splunk.Investigation.mc_create_time
      description: The time when the finding or investigation was created or imported into Splunk Enterprise Security (epoch seconds).
      type: Number
    - contextPath: Splunk.Investigation.count_findings
      description: The number of findings (or intermediate findings) associated with this investigation or finding-based-detection (FBD) group.
      type: Number
    - contextPath: Splunk.Investigation.risk_event_count
      description: The number of risk events associated with this investigation.
      type: Number
    - contextPath: Splunk.Investigation.risk_score
      description: The maximum risk score for all the findings added to the investigation.
      type: Number
    - contextPath: Splunk.Investigation.excluded_finding_ids
      description: A list of finding IDs (or intermediate findings in the finding groups) that are removed from the investigation.
      type: Unknown
    - contextPath: Splunk.Investigation.attachments
      description: An array of file IDs attached directly to the investigation.
      type: Unknown
    - contextPath: Splunk.Investigation.notes
      description: An array of note IDs added directly to the finding or investigation.
      type: Unknown
    - contextPath: Splunk.Investigation.findings.incident_ids
      description: The added finding IDs.
      type: Unknown
    - contextPath: Splunk.Investigation.findings.field_inheritors
      description: The added finding IDs that will inherit this investigation's owner, status, urgency, sensitivity, and disposition values.
      type: Unknown
    - contextPath: Splunk.Investigation.current_response_plan_phase.phase_id
      description: The ID of the current response plan phase.
      type: String
    - contextPath: Splunk.Investigation.current_response_plan_phase.response_plan_id
      description: The ID of the current response plan.
      type: String
    - contextPath: Splunk.Investigation.response_plans
      description: The array of response plans added to the investigation.
      type: Unknown
    - contextPath: Splunk.Investigation.consolidated_findings
      description: The consolidated list of fields for the findings and all the findings that are added to this investigation.
      type: Unknown
    - contextPath: Splunk.Investigation.finding
      description: The raw data of the originating finding.
      type: Unknown
    - contextPath: Splunk.Investigation.custom_fields
      description: The custom fields in the investigation.
      type: Unknown
    - contextPath: Splunk.Investigation.src
      description: A list of values for the `source` field.
      type: Unknown
    - contextPath: Splunk.Investigation.dest
      description: A list of values for the `destination` field.
      type: Unknown
    - contextPath: Splunk.Investigation.dvc
      description: A list of values for the `device` field.
      type: Unknown
    - contextPath: Splunk.Investigation.orig_host
      description: A list of values for the `host` field.
      type: Unknown
    - contextPath: Splunk.Investigation.src_user
      description: A list of values for the `source user` field.
      type: Unknown
    - contextPath: Splunk.Investigation.user
      description: A list of values for the `user` field.
      type: Unknown
    - contextPath: Splunk.Investigation.risk_object
      description: The list of entities for a finding, finding group, or investigation.
      type: Unknown
    - contextPath: Splunk.Investigation.risk_object_type
      description: The list of risk object types for a finding, finding group, or investigation.
      type: Unknown
  dockerimage: demisto/splunksdk-py3:1.0.0.10133006
  isfetch: true
  ismappable: true
  isremotesyncin: true
  isremotesyncout: true
  script: ''
  subtype: python3
  type: python
  runonce: false
tests:
- SplunkPy KV commands
- SplunkPy parse-raw - Test
- SplunkPy-Test-V2
fromversion: 6.0.0