Change Aritfact Dependency Default or Run a Playbook without an Artifact

[SOARt_of_Lost]

Due to some oddities of our environment, my team needs default fields in order to run some playbooks automatically. We've built these fields into the notable events which get sent over from Splunk. However, containers are built without an artifact when created manually. While we could certainly train people to follow some manual steps to create an artifact or toggle the Artifact Dependency switch, that goes against the nature of SOAR and it's easy to miss something. It's easier to have a playbook create an artifact with those fields we need. Unfortunately, the Artifact Dependency switch defaults to off.

So, the actual question: Has anyone found a way to change the default for the Artifact Dependency switch or to make a playbook run before an artifact is created?

[phanTom]

@SOARt_of_Lost the only way I can think of initially is to have a scheduled playbook to check for containers from notables without artifacts and then run the relevant playbook against them. Timer app would be used to create the container to kick the utility playbook off as regularly as you want. 

[SOARt_of_Lost · Accepted solution]

We didn't end up going this route since there are fairly long stretches of time where the check would be running unnecessarily, and it wouldn't have the immediate effect which is necessary for incident response (our main use case for this question). We did, however, keep another piece of @phanTom wisdom in mind. "There are many ways to do things in SOAR, just depends how janky you want to get!"

We ended up creating a new subplaybook to go at the beginning of those playbooks likely to be affected by missing the fields:

1. Check if an artifact with the required fields exists
   1. If it does, continue with the rest of the parent as normal
   2. If not, do the following
2. Use the Phantom app to add an artifact with the required fields
3. Create a custom code block which uses multiple API operations to
   1. Get the subplaybook's own ID
      • This is necessary since that number changes any time you edit the PB
   2. Get the audit data from the container
   3. Pull the json of the currently running subplaybook to get its parent's name and ID
      • runs_resp_json['misc']['parent_playbook_run']['parent_playbook_name']
      • runs_resp_json['misc']['parent_playbook_run']['parent_playbook_run_id']
   4. Use parent_playbook_name to call a new instance of the parent playbook
      • SOAR treats a PB called via API as independent while those called via block are children
      • This step is needed so the parent playbook interacts with the newly created artifact normally (we ran into problems referencing an artifact created within the same PB run)
   5. Use parent_playbook_run_id to cancel the original run since it's likely to run into the problem mentioned above
      • This must come at the very end since cancelling the parent cancels any children, including the playbook running this code