One of the first things we at Tines do when we meet a security team for the first time is to ask them about their current processes in order to help figure out where automation might be most effective for them.
Most teams we meet have a great understanding of what happens when one of their most common activities occurs whether it be analyzing a phishing email or responding to a malware alert. Sometimes this understanding exists in an individual's mind, more commonly it is written down in a knowledge base, or it might even have a reference flowchart. Each of these approaches produces a varying level of success when moving towards automation. No matter the approach, we find that taking those knowledge artifacts and then performing a 'rubber ducking' exercise is incredibly useful for any team. Rubber ducking is a process by which, and you can take this as literally as you wish, you explain each part of your processes at a granular level of detail to a non-sentient toy duck. This activity usually produces additional knowledge of shared processes across multiple flows that can lend themselves to better automation during implementation.
Teams that regularly perform a task or a set of tasks in multiple different stories can utilize the Send to Story action in Tines which enables a primary workflow to send data to a sub-story (I like to refer them as a parent story and a child story), which is a standardized procedure with set inputs and outputs (similar to functions in the programming world). Rather than build a common functionality into every story that needs it, you can build a standalone sub-story, and use it as often as you need to by leveraging the Send to Story action. For example, a threat intelligence story and a phishing response story may use the same procedure to analyze a URL. Similarly, a user de-provision story and a vulnerability management story may both require the creation of a Jira ticket. Breaking a complex workflow into shorter sub-stories can also make your automation story easier for your team to understand. To understand the basics of using Send to Story, check out this post.
Advances to Send to Story Technology
In the time since we unveiled the Send to Story action, we've added some capabilities to the Tines platform that empower Send to Story in new ways.
One of the first improvements we released is the ability to set multiple 'Exit Actions' for a Send to Story. This capability allows for a 'child' Send to Story to take multiple complex forks without the need to return to a single action in order to return results to the 'parent' story, which was a previous requirement. This allows for returning specific pieces of information based on the findings in the fork, like in the example below, where either a clean or malicious result would be returned along with additional pieces of data which led to that verdict.
The screenshot above also provides a look at another new feature. With the release of Teams in Tines, Send to Story actions can now offer limited access to only the Team they are a part of or can be referenced by other teams. Utilizing this feature provides a great way to reuse standard functionality and give access to services without having to share credentials with other groups.
Lastly, Send to Story has always functioned by using a sub-story's name to run. Recent changes to Tines allow for those names to be passed in dynamically to the Send to Story action. This can be utilized to match up alerts received on a webhook to specific sub-stories to respond to those alerts. In the example below, the Event Transformation action utilizes a Tines resource that maps known alerts to the story that should be run when the alert is received. If found, that story name is passed along to the 'Send to Dynamic Story' action, which will run the associated story if one exists while falling back to a 'generic story' that can handle any alert that might arrive.
Tips, Tricks, and Best Practices
Send to Story is an incredibly powerful feature that I would encourage anyone to use heavily. When beginning to use Send to Story for the first time, there are some #protips that can speed up implementation and adoption across multiple teams.
Tines has a cache of 'Public Templates,' which speed up the implementation of various products and services. Additionally, you can also create 'Private Templates' for any private or internal services. When creating new stories that will utilize Send to Story, it is helpful to add in Private Templates that correspond with a story name as well as the parameters that can be passed to the 'child' story. This allows for anyone in the tenant to drag, drop, and include Send to Stories in any workflow with the necessary configuration options already filled out.
A newer feature to Tines is the ability to 'Annotate' the storyboard with notes that describe what a story does. It can be helpful to use these annotations to not only describe what happens in a story, but also what should be passed to a Send to Story in order for it to function correctly and the data structure that will be returned when the Send to Story finishes.
Standardizing on a return format across multiple exit actions helps with managing the Send to Story from many other stories. It can also be helpful to always return a form of unmodified data payload back to the calling story in addition to a calculated response ('malicious' or 'clean' in the example above) in case the 'parent' story needs additional context for further action.
Furthermore, when using multiple exit actions, be very sensitive that multiple forked paths are not taken in your 'child' story (unless that is the intention!). Each event that reaches an exit action will return a result to the 'parent' story. This can result in multiple incident tickets being opened, multiple redundant analysis results being posted, or extra annoying Slack prompts!
Last up, while Send to Story requires an Event Transform action to be on the storyboard and configured as an exit action in the Send to Story configuration, that exit action is not required to be connected to any other actions. This results in a Send to Story which can end a fork for a 'parent' workflow. This is helpful if nothing needs to be returned to the 'parent' story and the 'child' story can, like in the example below, just send a Slack message and finish the fork in the workflow.
Don't Just Wing It
The Send to Story action reduces complexity and encourages standardization of processes across multiple teams using Tines. While Send to Story might seem like a complicated feature at first glance, using some of these new features, tips, and consulting your rubber ducky can help speed up implementing new repeatable stories in no time.