Why are so many security teams migrating from legacy SOAR tools to next-gen solutions? This was one of the topics up for discussion as Tines engineer Whitney Young joined host Adrian Sanabria on the Enterprise Security Weekly podcast. Read on for a behind-the-scenes look at Whitney’s process for legacy SOAR migrations, including her top tips for teams considering a switch. Or, for a deeper dive, you can watch the full episode here.
Shifting from Legacy SOAR: Tailoring the POC to Customer Needs
Adrian Sanabria: One thing I want to talk about is the move away from traditional SOAR. Pretty much everybody was pushed through the same POC experience, building the same automations about phishing and stuff like that. During the POC process, do you tend to build the same things each time, or do you ask the customer what they want to build?
Whitney Young: Great question. We always ask the customer. Typically, we try to scope, depending on POC and the prospect, at least two use cases. When I know they have a legacy SOAR tool already, I try to recommend that we build out one critical use case that’s already built and running in their existing SOAR.
I also have them build something that they haven't been able to build in their legacy system - whether that's because of a lack of integrations, they just haven't had the time, or something about it makes it very difficult to do.
I would say that phishing is probably one of the most common use cases. We have a dozen different phishing use cases that vary with different tech stacks and remediation processes. And so that's always a really great jumping-off point for people who want to implement quicker and not start from scratch.
The integration problem
Adrian: Throw out some ideas of things people have built with Tines that are not the typical ‘Hello, World’ that they're familiar with.
Whitney: Some of the most interesting things I've seen have been outside of security, so IT and engineering. I've also seen a Tines page embedded in somebody's website serving as the web application.
All the technical builders at Tines definitely have our own unique use cases that are not security-based, just because the tool is so flexible. I have lots of plants, so in the wintertime, our outside plants go into a shed. We have a smart thermometer with an API, and I have a Tines story running that will automatically turn on the heater if it goes below a certain temperature.
Adrian: Yeah, that's something I want to call out about Tines that I found really interesting. My experience with the traditional SOAR tools is that you have to build some kind of connector in Python. You end up seeing a lot of connectors that are thrown together really quickly; they don't include all the API elements.
With Tines, you don't have to build a connector, you can just use the raw API. That was huge for me.
Whitney: When we start talking to prospects that have a legacy SOAR tool in place, one of the first things we're trying to find out is why are they potentially migrating? Integrations is definitely one of the top reasons. While they might support an integration with a tool, maybe it doesn't support all the endpoints that would otherwise be available. Or maybe they're trying to connect to an internal system that has an API. The legacy SOAR tool doesn't really have much incentive to actually build and support that integration. With Tines it's just completely flexible.
Empowering a community of builders through the Tines library
Adrian: The fact that you don't even have to create an account to browse Tines’ library of pre-built workflows is very compelling for the product. One thing I'm not clear on about the library: Is this stuff that Tines created, customers created, or a mix of both?
Whitney: It's a mix of both. The technical builders at Tines, we build stuff, and we have an internal process and partner pairings for reviewing it. We also have a Labs team whose main focus is building out pre-built workflows and we also have that community aspect.
Anybody can go onto our website, view the pre-built workflows in the library and import them. They can also upload a workflow they've built or suggest a workflow they’d like to see in the library.
Of course, if somebody uploads a workflow, it still goes through our formal review process - it's not just immediately published. But it's nice that you can see which ones come from our community. And we also just did our annual “You Did What With Tines?!” competition, which is pretty cool. All of those submissions go into the library as community submissions.
Slashing implementation times
Adrian: Implementation time, or time-to-value, is really critical for security products. I remember back when I was an industry researcher at 451 Research, my colleague Javvad Malik did a report on the different products that would end up as shelfware. And they tend to be products with those long, grueling implementation times.
The first generation of SOAR products shouldn't have been that bad on implementation time, but the way it was set up was so complex. There was always something that broke, and the troubleshooting was difficult. Just getting them up and running was a lot of work.
I don't know if you actually have the metrics, but how much faster is Tines than the previous generation of SOAR tools?
Whitney: It depends on the prospect’s use cases and whether we’re starting from scratch. I have a customer migrating from a legacy SOAR tool to Tines who had a tight timeframe - just over 60 days. They built, and we were able to migrate, 45 workflows over within that time pretty easily.
Adrian: They already knew exactly what they wanted to build, right?
Whitney: Right, that was scoped. When people are migrating from legacy SOAR, there's definitely opportunity to optimize the way they are doing things. Obviously, the way that you build in Tines is a little bit different, so it's always interesting to see if people are open to that.
Some people want to stick with the exact same process and build it one-to-one, which is easy, because then you're just going in and building.
I personally prefer when customers are open to a more efficient process - taking a look at the use case itself, where we can improve on it and maybe add to it if the integration wasn’t supported previously. How can Tines continue to iterate on that?
We have a case study with Mars, who were able to migrate 200 workflows from their legacy SOAR tool to Tines in less than six months and onboard five different teams. So I think that's a pretty good metric, but again, it varies so much depending on the prospect.
Adrian: Yeah, and I can really relate to that. Before I got into security, I was on the IT side. One of my first jobs at a large payment processor was to find all these automated jobs and centralize them. And I really enjoyed that process. But in one case, the code was so bad, it turned into a full-time job for the person that was babysitting it. Once I got done ‘un-convoluting’ it, it was like a five-line shell script. I imagine that some of your job is to point out that, ‘You don't need these five steps right here, that could just be one step.’
Whitney: Exactly. The flexibility of being able to bring in data sources from multiple platforms into the same automation is sometimes really surprising to people, but it's so native to Tines. The ability to re-emit events and test in Tines makes the building process pretty seamless. I think building in Tines is really fun. But it’s always challenging when I ask somebody, ‘Why are you doing it that way?’ And their response is, ‘Well, we’ve always done it that way.’ And that's when I know there's room to transition away and into something a little bit more efficient.
Adrian: And delight the customer, right?
There's not a lot of opportunities in security to delight a customer, but I think anytime you uncomplicate something, you have that opportunity.
AI-driven data transformation
Adrian: Can you walk me through how AI in Tines, specifically Automatic Mode, works? Let’s say I’ve got some input data, and I need to transform it. I imagine there'd be a prompt interface and I would just say, ‘Hey, this input is JSON, and I need it to be CSV.’
Whitney: Yeah, exactly. In the same way that we would typically pass dynamic data from an upstream action, you set that path to the variable data, and then you just prompt it. So you'd say something like, ‘Can you turn this into a CSV?’ and it will immediately run the Python script and show you the output.
It'll also give you any errors if you need to adjust your prompt, so you can immediately validate if your prompt is accurate for the output you want. And then you can save it and go from there.
And let's say it's not exactly what you wanted. You have an option directly in the modal to copy that as a ‘Run script’. So you can paste that as an action and then just go and edit the raw Python.
Adrian: Very cool. So it’s kind of like a GitHub co-pilot built into the product, basically.
Whitney: Yeah, it’s great for being able to do a lot of data transformation in a single step. Definitely check it out, it's in our Community Edition.
Enabling real-time action with Tines Workbench
Adrian: It seems like Tines is finding those places where people get stuck and productivity stops. Tines is systematically finding these bottlenecks and building stuff to help people push through them.
Whitney: Yeah, and I think we've done it in a really thoughtful way. We recently released Workbench, which is basically an AI chat that allows you to interact with your automation, all powered by Tines.
Adrian: I imagine that Workbench comes in really handy once you have a whole bunch of stuff and you're looking for specific things, maybe one of the components that 40 of those workflows depend on.
Whitney: Yeah. Tines has a lot of pre-built templates, so when you're using Workbench, it’s as easy as going in and just authenticating it. If it's an OAuth credential, a text credential, or an API key, we have those workflows built into Tines. And once you pop that in, you’ll see a list of the different endpoints that we support.
And if, for some reason, there's something that we don't have a template for, it can be powered by a Tines workflow, especially if you’re taking multiple actions in one step.
Building in Tines is different than interacting with the data in Tines. No one’s going into the raw automation and looking at the JSON, right? They’re sending that data somewhere else. Whether it’s an external case management system, Slack, or Teams - wherever it’s living, Workbench just makes life easier and saves time so people aren’t going into multiple tools.
Let's say you're using Cases. It'll have the context of everything that's in that Case. And then you're able to say, “Now, go to AWS and give me this information about this S3 bucket. And then I need information also about this employee.” You can do all of those things from a single interface.
Adrian: That sounds more powerful than what I was thinking. So you're talking about getting more data, rather than just information, about the workflows and how they're constructed, and actually receiving data back from your integrations.
Whitney: Yeah, exactly, and then being able to take the remediation action from there. So if an S3 bucket is open, we can use AWS, CLI, or the API to go and apply that public block policy. Or, if a user has been compromised, we can reset their sessions and their passwords and notify them.
From total end-to-end use case, the analyst has everything they need to focus on it through Workbench.
Adrian: You're blowing my mind a bit. So if I've got an ad hoc, one-off thing I need to do, instead of building a story, I can just go use Workbench.
Whitney: If we have a template for it. You might need a workflow if it's something very specific.
"Building builders" through customer support
Adrian: Talking about the current generation of SOAR products versus the older ones - the community aspect was somewhat there with the older ones, but I would still consider community to be a big differentiator. Are there any others we haven't touched on yet?
Whitney: I think a huge differentiator is great pre-sale support. All of our customers go through onboarding. We have a philosophy of ‘building the builder’. We really want our customers to be successful, we want them to be able to build. We don't want them to be blocked if they have questions.
We do a lot of co-building sessions. On the pre-sale side and the POC, that looks like me walking you through what our step-by-step approach would be. Tines is so flexible that we want to make sure you're doing it in the best way.
We have a customer success engineer as a manager on the post-sale side. I really think the customer support that people get at Tines - and the way that we value product feedback to drive the product in a way that's best for our users - is very special.
Adrian: Yeah, I've been looking at products a long time. I've put together a database of all the companies and products in the industry, and I've worked at several vendors. One key thing I think other vendors miss is not incorporating that feedback loop from customers and not supporting them after they become a customer. And it’s plain to see, too.
I’m in private Slack communities where the only product that has a dedicated channel is Tines. You don't see that with any other security vendor.
I found that very revealing about how much people love and enjoy using the product.
Whitney: Yeah, we are excited every day to be building in Tines and be given new problems to solve and ways to think about things. At the end of the day, I’m a Tines user too.