When security teams initially jump into Tines, we often get asked where the best place to "put all your stuff" is. Generally, the first thing the teams are looking to handle is security alerts. Alerts can come from all over and in all different shapes and sizes. Alerts end up being the crux of nearly any security team. Depending on the size of your security program, alerts can range from "too many and unreliable" for large organizations to "unorganized and unacknowledged" in smaller organizations. Teams may have done some work already to centralize many of their alerts into a hub like a SIEM or data lake, but then there are always some alerts that can't get into the SIEM for one reason or another. Likewise, reports of phishing emails might end up going to a monitored email inbox as a standard procedure which can leave them disconnected from the central hub. Forgive me if this is starting to sound far too familiar. Tines can help across this spectrum by using some techniques outlined below.
Tines operates using Stories, which represent workflows, as the canvas to build automations on. Using the name Story is not just branding. Like in many books, one can think of Stories as a narrative with a beginning, middle, some plot twists, and an end. Books also come in many different genres like romance, non-fiction, and even "choose your own adventure"! Tines Stories are flexible and can be designed in many different ways as well. This analogy of Tines Stories to book stories can be a helpful guide when organizing your workflows.
Preface
Continuing the novel analogy we've started, a couple of small tips to lay the groundwork. Most of these suggestions will adhere to the golden answer to everything in IT: "It depends." We have seen a lot of success with the techniques described below, but they might not work in every situation.
As mentioned above, there are many paths to getting data into Tines in order for Actions to take place. For each source of alerts, it is helpful to understand and organize those sources into their own categories and create plotlines to play out in a Story. One key attribute when performing this organization I like to start with is the similarity of format in the data which will be sent to Tines. For example, all Okta alerts are formatted in their proprietary format. All SIEM alerts (should) have a common set of fields for every alert, no matter what generated the alert. All emails sent in for analysis will have the same format (RFC-822/RFC-5322).
Wait, all SIEM alerts are the same? No, not at all! But, by recognizing those alerts as a single source (the SIEM) and their common formatting, the easier it will be to design Tines Stories.
Chapter One: Single Product Type, Multiple Instances
Having multiple instances of the same product or vendor can manifest itself in many different ways in an organization. Three that immediately come to mind are:
Having separate production and development instances of the same tool.
Different teams running separate services for their own needs.
Shared control over a tool that is used by a third party or part of a merger and acquisition activity.
No matter the reason, there will be one type of tool involved and one data format in this situation. In accordance with the design ideals outlined above, it is entirely possible only a single Story in Tines would be needed to handle the alerts, but that Story could have two separate webhooks leading into the beginning of the Story. Once the data is within the Story, features like the Trigger Action can be used to perform specific decision-making based on the details in the alert.
Chapter Two: Email Inboxes and API Polling
Aside from webhooks, the other most common ways to bring data into Tines are via HTTP Request Actions polling an API (for products that do not push alerts) and connecting to email inboxes. Generally, both of these Actions are set on a schedule to run intermittently. For each, the Story which the Actions take in data will likely be purpose-built for a specific workflow the Actions are a part of. For example, in a phishing response Story, the email (the 'data format') will be read in, headers will be analyzed, attachments will be sandboxed, and suspicious URLs will be blocked.
Sometimes an organization will have a phishing report inbox and an email security product creating two different data sources and formats. In this situation, it is best to walk through current processes step-by-step to see if one data source generally proceeds the other or if either is a "source of truth." Instead of cramming everything into a single Story, perhaps design workflows for each while looking for opportunities to utilize each other. For instance, when analyzing the phishing report inbox, utilize Send to Story to check the email security gateway for alerts and enrich the analysis of the email reported as phishing.
Chapter Three: Alerts from a SIEM
Alluded to previously, alerts generated by a SIEM are a hot topic when looking to organize Stories appropriately in Tines. Recent research suggests that even some of the smallest organizations will utilize a minimum of 15 different security tools. If those tools are all sending data to a SIEM platform for alert management, does that mean the SIEM will need to send to 15 different Tines Stories?
Not quite! By thinking of the SIEM as a single product with a single data format, a single webhook can be used to take in the alert and make determinations based on the data payload. For instance, if there is a field that describes the product sending logs to the SIEM, which triggered the alert (like "CrowdStrike" in the example above), Tines can then utilize a Send to Story Action to branch off into another story that could handle any product specific workflows required in a "Choose Your Own Adventure" style. Bonus points are awarded to any IT domain-specific Stories (identity, cloud, endpoint, email, etc.) that can be created in place of product-specific ones, which can come in handy if a product ever needs to be swapped out.
Epilogue
Some time has passed since we caught up with our security team using Tines. With newfound knowledge of how to plan and design Stories in Tines, the team has since created clear workflows, reduced time to response to a majority of alerts, and is finally able to use their time performing engaging cybersecurity work. By thinking of Tines workflows like narratives in books, it becomes easier and easier to build a new or extend an existing Story whenever an opportunity for automation presents itself.