@shanto12 you should just be able to tar it up and install via the UI in the apps location? AFAIK py2 is still supported on 5.1.x on-prem.  ... View more

@djacquens if you are using the python sleep then I would highly recommend you undo asap as it will cause platform instability and halt automation for the duration of the sleep. If using something else then please ignore the above 😄   First, I would need to understand why playbooks are running on the same container more than once.  An immediate fix is to add a tag to the container when the playbook first runs, then have a decision at the front that checks if the tag exists and will just end if it does.  If you are adding artifacts to the container during automation and DON'T want the pb to run again make sure you are setting the 'run_automation' flag to false when creating the artifacts.  Hope this helps.  ... View more

@mrzn I would remove the 4 days wait and try to handle this in a different way as this is far from best-practise. Each playbook with a prompt waiting for response will be keeping a daemon resource active the whole time and is excessive, IMHO. It also isn't robust as if the server or daemon was ever restarted you would lose all existing prompts!! Depending on the use case I think you would be better to send an email with an encoded string that gets added to the HTML body, this usually contains the container_id the email was sent from and any other useful information to inform the automation upon reply and decryption. You then ingest the emails from the inbox where replies go to, have a playbook that grabs the encrypted key, decrypts and then takes the relevant action on the event. This way you are not keeping playbook(s) in a waiting state for up to 4 days.  There will likely be many ways to approach this, the above is something I have done a lot to get around the possible days' waiting for replies. Prompt timeouts should, again IMO, be no longer than an hour.  Happy to discuss further if you need ! ... View more

@jeffrey_berry I think I am struggling because although I think it adds great context in a SIEM where you are looking for time-based information, Splunk SOAR is a Security Automation Platform & I am failing to see the value add for automating security response.  Now I am not a daily administrator of the platform so appreciate your experience is completely different to mine!  If you are externalising your SOAR platform's data to an Externally Managed Splunk Enterprise instance then that is the best practise and best place to create the rich dashboards and that has always been my recommendation over the years. I am also only one person so don't let me stop you raising an idea! If you think it's valid then someone else might and you can always try to get some support from the community!  Happy Phantoming SOARing ... View more

@jeffrey_berry I understand the ask but Splunk doesn't do this so not sure the benefit. Surely if you put 1y and only have 9months of data it will only show 9months and I wouldn't call that misleading as such? However if you feel it worthy please add an idea to https://ideas.splunk.com/ and get people to up-vote it. This has been very successful in getting some great features into the platform! E.G. I asked for the scope toggle on action blocks and it only took a few months to make it to the platform!  ... View more

@iamraprap not quite sure what you mean.  The power of SOAR is the automation and an analyst/human should only be brought in if necessary. Playbooks should all be written to check for the data it needs to perform its function and if that means filtering artifacts based on some data before performing an action, that it what Splunk SOAR is made for. IMO, all analyst actions should be controlled by a playbook for consistency, even for relatively simple click-able tasks in the UI as it gives a lot more control and visibility of the analyst's use of the Platform and makes things a lot more efficient/consistent.  Scope is something that once understood makes a lot of sense, and is configurable on individual blocks in playbooks since 4.10.7. Happy SOARing! ... View more

The REST call to run a playbook takes an optional argument of "scope" which accepts a list of integers of artifact_ids, this will be how the playbook is called by the platform, invisible to you or I. The list of artifact ids will be passed to the playbook as parameters. No code in the playbook will show you how this works as it's "under the hood".  https://docs.splunk.com/Documentation/SOARonprem/5.1.0/PlatformAPI/RESTRunPlaybook  As for accessing the fields, this is where datapaths come in and you need to use them to retrieve the values you want from the fields you want. It's worth using decision to check if the field exists, and a filter to filter just the value you want else you may get invalid results with Nones.  ... View more

@iamraprap welcome to the community! There is no datapath for what you are asking as a playbook is totally unaware of any boxes being ticked on a container. However, depending on how the artifacts are created, you may be able to use a combination of conditions in a decision/filter to only act upon the relevant artifact in a playbook.  As for running from the UI; if you select an artifact and press the >Playbook button, in the bottom-left of the new window you can select "artifact" which will mean the playbook will only run against the selected artifact(s). To run an action against an artifact is different as actions will only run against values, these are contained in the artifacts. If you click a value and see a drop-down appear, this will contain all of the actions available for the type of data SOAR thinks the value is and you can run individual actions manually that way too.  Hope this helped, if so please mark as the solution. Or if you need more info please let me know.  ... View more