I am wanting to kick off a playbook when the container owner value changes from NULL to Not NULL. So far I have created a playbook which will trigger on events with an assigned label and check if container owner value has been populated(NOT NULL).
If this condition is met, it will trigger off a sub-playbook. If condition is not met(i.e. container owner value is NULL), the no op Phantom API action is run to sleep for 60 seconds. I would like to insert a custom function after no op sleep() to loop back to the first step of checking container owner value. Can someone assist with this?
@fhq one other way is to externalise your Splunk capability on Phantom and have an SPL search that kicks off a playbook when the value of a container changes in the data. https://docs.splunk.com/Documentation/Phantom/4.9/Install/ExternalSplunk
I prefer any non-scripted way first as external scripts can sometimes add unnecessary overheads in future management etc.
If you want to check for values at some regular interval, recommend using the Timer App.
We use it to schedule playbooks at a couple of intervals, based on label, similar to your own. This way your playbook can gracefully end. and pick up again when this new "Timer" container is made. You will need to use some custom code to pull up containers with this "NULL" or "NOTNULL" user or whatever.
Definitely don't ever do sleep or keep playbooks open all the time that are checking for values that are or are not there. phanotm_mhike is right, it will DOS your instance!
There are ways that you can accomplish this in a playbook but none of them are strategically sound options if you want to maintain a stable and consistent phantom environment. In general, looping playbooks is one of the easiest ways to make sure that your phantom host stops processing any other automation which is not what you are going for here.
I am listing three good options here in order of level of effort. I recommend suggestion 1 but any of them will work.
1 ) You could write a python script that uses the rest api to check for containers that have owners set but have not run your playbook yet and execute the playbook from there. You can schedule that cron job fairly frequently without having any serious impact on performance.
2 ) Another option would be to create a playbook that essentially does the same thing as the cron script described and use a timer asset and label to execute that playbook. you will take a larger performance hit running it this way especially if you have a lot of automation going. But this does allow you to keep your automation in the UI and not hiding in a cron script.
3 ) A better option than the timer would be to write a simple custom phantom app and use the on_poll function to execute the operation described in the cron script above.