Splunk SOAR

playbook running multiple times on single container

ansusabu_25
Observer

Using SOAR export app in Splunk, we are pulling certain alerts to SOAR. Depending on the ip, the artifacts are grouped to a single container. Now I need to create 1 ticket for each container using playbook. But what happens is that if the container is having multiple artifacts, it creates 1 ticket for each artifact. Any idea on how to solve this?

Phantom  Splunk App for SOAR Export 

Labels (3)
0 Karma

jenniandthebets
Explorer

I'm a bit confused about how you're getting data to your SOAR instance - you say you're pulling, but you're also using the Splunk App for SOAR Export? When I hear pull, I'm assuming you have the SOAR App for Splunk configured to pull events in from SOAR (yes, I know the app names are all similar and this definitely caused some confusion for my team early on)

 

Assuming you just have the event forwarding configured, you can maybe try changing your advanced options to this:

jenniandthebets_0-1709134165003.png

This would send everything as a single artifact, rather than the multiple you have.

0 Karma

ansusabu_25
Observer

We are not ES app. This option is for es app right? We are forwarding the alerts from splunk to soar using soar export app

0 Karma

phanTom
SplunkTrust
SplunkTrust

@ansusabu_25 the app is not ES specific but can be installed on any SH. You should have the option already shown to you and this will stop the multiple artifacts being created. At the moment, multiple artifacts are created due to there being 1 or more MV fields in the results data. If you set the setting already shown then you will get 1 event with 1 artifact in but the values for some of the fields will be lists which you will need to handle in playbooks, as in configure any blocks to be able to process single and list items. Previously I have used a playbook on ingest to split the MV fields into artifacts without all the additional duplication. 

Hope this helps! Happy SOARing!! 

0 Karma

victor_menezes
Path Finder

A quick win will be tagging the container.
You can edit your playbook to check if the tag of the container is XYZ, which will be not in the first run (for the first artifact). Once you call your action to create an incident, change the tag of the container to XYZ, so even if the next artifact triggers the playbook, the tag will already by XYZ and the create incident action will not be called as it will not satisfy your condition.

While creating artifacts manually (via rest, for example), you can force the parameter "run_automation" to false, preventing that new artifact to trigger the playbook execution, but in your case data is coming from the export app so maybe you can find some settings in there to change this behavior (honestly I don't recall one, but maybe you can find something interesting)

0 Karma

ansusabu_25
Observer

I have tried the option to set the tag. But the problem is by the time the 1st artifact set the tag, the 2nd one have already completed the decision block and hence it repeats the playbook

0 Karma
Get Updates on the Splunk Community!

New Case Study Shows the Value of Partnering with Splunk Academic Alliance

The University of Nevada, Las Vegas (UNLV) is another premier research institution helping to shape the next ...

How to Monitor Google Kubernetes Engine (GKE)

We’ve looked at how to integrate Kubernetes environments with Splunk Observability Cloud, but what about ...

Index This | How can you make 45 using only 4?

October 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...