Interview: How To Combat Alert Fatigue With Next-Gen SOAR

SOC teams are currently facing a huge shortage of talent. When an understaffed, overworked team is trying to deal with hundreds or even thousands of repetitive alerts monthly, they quickly begin to experience alert fatigue. Combine this with the challenge of managing overly complex orchestration and response systems, and you get a SOC that’s so preoccupied with plugging holes in their ship that they don’t notice the sail has a hole in it.

To find out how organizations can help their SOC teams regain control of their security orchestration and response processes, we spoke with Josh McCarthy, Co-Founder and Chief Product Officer at Revelstoke, and Nick Graves, Chief Architect at Revelstoke. Revelstoke is a low-code, next-gen Security Orchestration, Automation, and Response (SOAR) platform designed to enable SOC teams to spend less time addressing menial alerts and more time mitigating new and unknown threats.

In this interview, we discussed the main challenges that SOC teams are facing today—from alert fatigue and an ever-increasing analyst skills gap to managing complex, fragile solutions that don’t scale. We also spoke about the benefits of next-gen SOAR over legacy solutions, the power of automation, and the perks of implementing a low-code platform.  

What are some of the biggest challenges your customers are facing at the moment, and why are existing SOAR solutions not helping them to solve those challenges?

McCarthy: Our team worked together on another company in the automation space. After we sold that company and moved on to another company, we would go back to the customers that we’ve sold to over the years, and at the end of the conversation, they would pull us aside and say, “Hey, I know you guys sold us XYZ product, but I’m not going to renew the product that I purchased now. So, what should I buy instead? You guys know the space well, what’s your opinion?”

We had that conversation pretty often, so we started digging to find out what had changed since these customers had purchased those solutions, which they’d been happy with initially. And the overwhelming number one reason why people were unhappy was the complexity. They didn’t have developers attached to their SOC that could help them write and maintain the playbooks they’d developed, so as soon as the POC wrapped up and the vendor walked away, all the progress with SOAR for most of these guys just halted because they couldn’t maintain what they had purchased.

Around eight out of 10 customers fell into that complexity bucket. The next two did have programmers attached to the SOC, so they could progress, but they ran right into the issue of scale.  A lot of gen one platforms will tip over in various ways when they get to about 500 to 1000 alerts. That stopped those guys in their tracks; they could maybe automate a couple of big things, but after that, the systems just fell over.

And that leads to the final problem of fragility. Over time, while they were trying to maintain these playbooks and changing out technologies, a flaw was exposed with the code-heavy SOAR platforms where they had a really hard time going back through their playbooks and figuring out all the places that had used custom code to make these things work. And as soon as they tried to introduce something new or make a change, it would just break everything.

So those are the three things and conversations that we knew we had to solve.

How does the Revelstoke platform help organizations address those challenges, and what differentiates you from other tools in the SOAR space?

McCarthy: We solve these challenges in a few ways. First, is the fragility issue. We have a normalized integration model that we call our Unified Data Layer. We normalize all the data on the inbound end of the product, like when you consume alerts, but we also normalize data regarding how you interact with the integrations. For example, CrowdStrike and SentinelOne both can acquire a file from an endpoint, but how you do that is different for each of those platforms using their APIs. We present you with one command that just does it however each vendor does it. You don’t need to know the plumbing or the inner workings that make it happen, you just need to know, “I want to grab the file.” Using our abstracted commands lets you switch out integrations and removes a lot of that fragility problem because we fix all the plumbing and the data transformations—you don’t need to worry about that. It’s just going to work.

In addition, besides just making it work, M&A or MSSPs can use the same workflows—other products sometimes call these “playbooks”—across different tech stacks without having to change them, because they’re using our generic commands, so it’s not directly tied to the vendor.

The next piece is scalability. We have a microservice-based architecture and a cloud-native design that can scale up and down automatically. As I said, most other vendors tend to tip over at around 500 to 1000 alerts an hour. We tested about 8000 an hour and we’ve not even reached our limit! And honestly, we could go higher, we just have to requisition more AWS resources to do it.

Last is the complexity issue, which we solve with our workflow designer and case management components. We decided to move away from the typical flowchart design to a Kanban design. This is because we saw most organizations wanting to group different tasks in different Incident Response phases, which was hard to do in a flowchart. It grew out of control, and trying to figure out which tasks were executed was quite difficult. The Kanban design makes that clear and helps drive analysts to know what they actually have to work on for a case.

So, that’s a big visual element right away, which is a difference between us and the competition. And because of the Unified Data Layer and the Kanban design, we reduce the overall number of tasks quite considerably, which helps simplicity because it’s less to maintain and it’s much clearer to see what’s happening.

Graves: Another area of focus for us with simplicity in mind is case management. Case management is essential to the SOC and helps improve efficiency. Unfortunately, many first-generation SOAR solutions either have extremely complex case management solutions or no case management at all. We have built simplicity into our tool by allowing analysts to follow efficient, guided tasks that help them stay focused on the important tasks at hand. That, coupled with our out-of-the-box category-specific case layouts, empowers users to focus on the important data as it’s represented from our UDL.

Could you tell us a little more about how the Unified Data Layer works?

McCarthy: Sure. I liken the Unified Data Layer to the Rosetta Stone; each product out there speaks a different language, and we bring that all together, so you only need to know how to talk to us. And we’ll worry about how all the other products talk to us.

Most software vendors out there are sticking the customer with the technical debt and managing the data model. We decided from day one, that’s not how this should happen; we should take on that technical debt and the customer should not be saddled with it.

So, that’s how I best describe the data layers: we own the data model so that the customer doesn’t have to figure it out.

Graves: We’ve also reduced the complexity of establishing secure communications, along with advanced business logic for each vendor integration to assist with command abstraction and normalized data processing. This allows users to focus on the meaningful data that is normalized through our data layer and reduces the need to investigate API errors or multiple command outputs.

The cybersecurity industry is becoming an increasingly crowded market, with security teams having to manage multiple tools at once. How real is the problem of alert fatigue, and how can automation help reduce it?

McCarthy: In conversations with our customers, alert fatigue is at the top of their minds. They’re short staffed and they can’t hire enough SOC analysts to deal with the alert volume because there’s currently negative employment for that role.

SOAR helps the existing analyst to be much more efficient in dealing with alerts coming in, so they get more bang for their buck.

Most alerts out there can be knocked out or significantly reduced with automation. The number one alert that people have to address is phishing—they get several hundred of these a week, and most of the customers we deal with spend somewhere between 30 and 60 minutes working on each phishing case. Phishing is generally worked by tier one analysts—it’s generally a simpler type of case to work. And the simpler the case, the more you can automate it, generally speaking. So, we can go from 30 to 60 minutes of the analysts’ time to about five to 10 minutes, depending on how much automation they’re comfortable with. And that’s just one case. Some kind of endpoint or malware threat is typically the number two; again, there could be several hundreds of these a month and they’re spending an hour or more on each one. We can take them down to 10 to 15 minutes spent working them. That time saving is huge.

We want humans to focus on things that actually need to be solved by a human, not just clicking “next” and filling in boxes for cases that can be mostly automated away. That’s not fun for anybody, and it prevents the analysts from looking for new and novel threats that they just don’t have time for because they’re spent working these phishing cases and things that we can automate away.

You mention the benefit of time savings there, and another element of the platform that helps with that is its low-code nature. Could you tell us a little more about that?

McCarthy: Absolutely. At our previous company, we found that the most successful customers were ones where the developer and the person writing the playbook logic were the same person. And that was rare. Normally, it’s a developer working with someone that knows the response logic, and they go back and forth trying to make something and it doesn’t come out right.

So, we’ve built our platform so that you don’t need to code or it’s very little effort to do so, and that lets the person that knows how to respond to it actually write the workflow themselves. That offers big-time savings and empowers that person a little bit.

And if they want to do their own coding, we support that. We are low-code, not no-code; we think that’s pretty impossible. Most customers have some crazy use case or some report they want, and that’s fine—we’ll happily let them do it. But with us managing the data model, those programmers don’t have to do as much work.

We’ve touched today on the issue of the cyber skills gap. How important is it for businesses to balance tech-centric solutions to that—such as the automation and low-code features offered by Revelstoke—with human-centric solutions, such as cross-training and upskilling?

McCarthy: That’s super important—it’s actually why we built case management into our platform, because that experience is critical. Coming back to the SOC analysts that you can never hire, you’re always onboarding, and—when you’re running case management inside your SOAR—the new people can go back and reference previous cases that other people worked on. So, when they get a new one, they’re like, “Cool, how was the last one of these solved?” They can get help without actually having to ask and get a much more guided response flow for how they should be working on that case.

That helps consistency, making sure people are responding to things the same way, and it helps new people get up to speed faster. And that’s absolutely critical.

Graves: Another important point to make here is that coupling our simple, efficient workflow design with guided case management gives analysts of all levels the ability to follow a predictable, repeatable action plan. Especially for new users to an organization, as they need to get up to speed quite quickly and have a predictable action plan to make this possible.

What would your final piece of advice be to organizations that want to improve their security orchestration and response process?

McCarthy: Before you buy SOAR, you need to reach a certain maturity level. SOAR is never going to be the first thing in an environment. On the other hand, some people want to go too far; they think they have to have everything else before SOAR. And that’s not true, either; it should be a little bit of a middle ground.

So, I’d advise people to look at SOAR once they have a SIEM and they’re getting a few hundred to a thousand alerts every month or so, which they have a general idea of how they respond to normally. Once they reach that level of maturity, it makes a lot of sense to bring in a SOAR because it can help drive other product purchases. Whatever you want to do, you want to ensure that APIs support that from the products you’re purchasing. So, you want to bring SOAR not crazy early, but on the earlier side, to make sure that what you’re purchasing is going to be compatible and fit into how you want to work your cases.

Graves:  As organizations fit SOAR into their business model, they focus on ingesting alerts from their primary detection sources. If those detection source integrations are implemented early on in the SOAR adoption process, it will allow users to identify if those detection sources need any additional tuning. As an example, Revelstoke retrieves alerts from a SIEM and identifies 1000 false positive alerts processed every day. Revelstoke can help identify where there may be a potential issue with a SIEM alert rule definition or something similar. This will allow users to quickly respond and act on that. So, Revelstoke does help them become more efficient in terms of how they’re building out those other systems that they’re implementing in their environment today.

Thank you to Josh McCarthy and Nick Graves for taking part in this interview. You can find out more about Revelstoke’s next-gen SOAR platform via their website.

Expert Insights provides leading research, reviews, and interviews to help organizations confidently make the right IT purchasing decisions.