A Case Study in Using Playbooks with Spaces Apps
How to use Playbooks to make spaces apps more effective
You can find the Indicator Importer spaces app discussed in this post here.
There are two goals for this blog post:
- To introduce the “Indicator Importer” spaces app (designed, open-sourced, and maintained by ThreatConnect users).
- How to use the Indicator Importer app to show how to use Playbooks to make spaces apps more effective.
First, an introduction to the Indicator Importer spaces app. The Indicator Importer app has been open-sourced by its creator here. It is a spaces app for quickly and accurately creating indicators and adding metadata (like attributes and tags) to them. Here is a demo:
The app is really useful, but there is a challenge: part of the app allows users to add attributes to indicators. It has a nice interface for doing so, but it requires data specifying which attributes can be added to which indicator types.
Ideally, this attribute data should be easy to change and update without having to repackage the spaces app, so we don’t want to put this data inside of the app. It would be better to put it in the datastore using a Playbook (as documented here). The goal is to make a Playbook which creates content in the datastore that can be used by a spaces app. Something like: playbook => datastore => spaces app.
There are Playbooks to create the attribute data for the Indicator Importer spaces app here. As it says in the readme, there are two versions of the playbook to be used for different versions of ThreatConnect. Both versions of the Playbooks, however, do the same thing (just in slightly different ways appropriate for the resident ThreatConnect version):
They are triggered via an HTTP request, set a variable for the URL from which the attributes will be collected:
They then request that url:
And escape the content for proper creation in the datastore. The component (named “[utility] Escape String for Datastore”) is made up of two find-and-replace apps to make sure the content is properly created in the datastore:
You can watch a video describing why components are useful here, but, in short, the component named “[utility] Escape String for Datastore” was made into a component so it can also be used for escaping content from any other playbooks and components. Generalizing the functionality to escape data destined for the datastore makes it much easier to use the functionality later and in other places.
So how does using a Playbook make the Indicator Importer spaces app more effective? Using a Playbook to create attribute data in the datastore keeps the data out of the spaces app which means that the spaces app does not have to be repackaged to update the attribute data; we just have to run a Playbook to create/update the data. Additionally, because the attribute data is stored in the datastore, it is also accessible to other spaces apps, Playbooks, and tcex apps.
Using a Playbook to put data in the datastore for a spaces app is just one of the possible uses for marrying Playbooks and spaces apps. If you have any ideas or questions about other use-cases, please raise an issue in our Playbook repository to discuss them!