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.