Our recent webinar with Forrester’s Allie Mellen and D3 Founder Gordon Benoit featured a fascinating debate and discussion on the state and future of SOAR.
In case you prefer to read rather than watch or listen, we’ve transcribed the most important parts of their exchange below. Read on for Allie and Gordon’s insights and analysis on a wide range of topics around the evolution of the SOAR market, major trends affecting enterprise and MSSP/MDR, the argument for and against vendor-agnostic SOAR, top tips for SOAR buyers, and more.
You can watch the entire webinar on-demand here.
The Fragmented Nature of the SOAR Market
Allie Mellen: The SOAR market is really interesting, because it’s changed a lot over the past 10 years. And even beyond the past 10 years, we’ve seen it really evolve from a brief moment as a standalone market into what’s become kind of a piecemeal consolidation in their markets. The way that we’re seeing the shift right now is for different types of SOAR in the market today.
There’s the Security Analytics Platform approach, which is a tight integration into an existing security analytics platform stack, which includes typically SIEM, SOAR, UBA, and sometimes Threat Intel Platforms as well.
Then there’s a second category, which is more of the Security Analytics Portfolio, which is an integration with a portfolio of different vendors, and also gives you the ability to use it externally as a standalone SOAR in addition. So typically, the portfolio approach is associated with a SIEM and with SUBA with other modular capabilities, but you can also purchase the SOAR as a standalone.
There’s a third category, which is Threat Intelligence. And we see this quite often with many SOAR vendors who either started out with SOAR, or maybe they started out in the TIP space and have now expanded into SOAR, they tend to offer a combination of a SOAR platform, a Threat Intelligence Platform, and in some cases, vulnerability management.
Then, there’s the fourth category. Automation Portfolios. These are vendors who aren’t classically associated with security. But they are classically associated with automation. And they want to expand their capabilities into automation in security in the SOC, in addition to other areas like it, for example.
And the last one and the one that we are here to talk about today is the Pure Play Vendor-Agnostic SOAR. And these are the vendors who have a pure focus on security automation, not just automation itself. But automation for security.
I think this is a very important use case for security teams because one of the jokes that I make quite often is that security teams get a lot of the hand-me-downs of it when it comes to the tooling. SOAR that is based on a pure focus on security automation, it’s not that it is the opposite. In fact, it’s a platform that’s designed for security teams to use automation better. And that can add a lot of value to a security team if it’s on the right. It also opens up the opportunity for the vendor to have a real focus on innovation in the space and make sure that they’re constantly pushing the boundaries of the way that we think about automation being used in the SOC.
The Challenge for Pure Play SOAR Vendors
Allie Mellen: The challenge is – a lot of security teams would prefer to buy their automation built into an existing portfolio. And that’s why we see the Security Analytics Platform and Security Analytics Portfolio, almost having a requirement of having a SOAR as part of what they do is because they view SOAR as something to enable the workflows with these other technologies. And they, of course, are selling these other technologies. So it makes sense as a natural fit as part of a portfolio. But that doesn’t necessarily mean that it’s going to be more effective than a pure play or vendor-agnostic SOAR, because ultimately, you can’t get that same level of focus and attention and care as you can with that pure Play SOAR, which is just, you know, the company’s whole mission is around improving automation in the SOC. So I think that that’s a very compelling message that can sometimes get lost. That clients really value if this company is specifically focused on building a product that’s made for automation in the SOC.
Strengths of Pure Play SOAR
Gordon Benoit: A big part of SOAR is the integrations. We have over 500 integrations. And when you’re doing the integration, you can do superficial integrations, or you can do deep integration. On the superficial side, anybody watching this video can go to any of the cybersecurity tech vendors and download their public API. And when you work with that, you’ll get about three calls to action that you could do. But if you do a deep integration with the vendor, you can do 20-30 actions. And that’s what we do.
We work closely with all these vendors – over 500 now, and we do deep integrations. We do that because we’re not a threat to these companies, we’re not a cybersecurity conglomerate that has conflicts with another vendor site. We’re also not part of a conglomerate, and we don’t have a vested interest in protecting their products within a customer. Our customers love the fact that we’re independent. Also, we’re very open to new ideas. And I think you’ll see that when we talk about the Event Pipeline, we’re pushing the boundary of what SOAR can do. And we’re listening to customers, and we have an extremely open mind as to what can be done. Things that you wouldn’t think a traditional software tool would do.
Our customers love the fact that we’re vendor agnostic, they love the fact that we’re independent, that we can get the deep integrations, and work with any product that they have. And remember, a lot of these customers have, 20 or 30, different cybersecurity products, and they count on us being independent and, and working with those vendors. And sometimes, we’ll have to send vendors an account or have to firewall vendors in an account. Obviously, there’s no issue with D3 – you could switch firewall vendors, and you can keep your SOAR and there’s no change to your playbooks back in D3, it’s literally drag and drop. We let you take your Cisco firewall, drag it out, and then bring in a firewall from say, Fortinet into your playbooks – no change to your playbooks, and the integration is taken care of.
What Makes Pure Play SOAR So Compelling
Allie Mellen: SOAR is ultimately made to make up for weaknesses in existing security products. With regards to workflow, there’s so little customizability that you can bring to existing security tools, they tend to be very rigid. They integrate with the things that they want to integrate with – a lot of times their own portfolio, and everything else gets kind of pushed to the side or not given as much TLC as it maybe deserves.
One of the compelling things about the pure play SOAR market is that they really don’t have a dog in that fight. It’s more of – let us support all these products that have weaknesses in providing more comprehensive workflows for analysts and make their lives easier. We can do this through our SOAR offering, which allows for customizability and ease of use. I think it’s interesting to think about it in the context of making your analysts’ lives better. And that is the ultimate goal of SOAR. Making up for all of these weaknesses and existing point solutions and existing products that the products vendors themselves haven’t been willing to do.
How Security Teams Can Build a Process for Success
Gordon Benoit: So first off, you have the data ingestion. Step one is data ingestion, again, 500 integrations. And with these deep integrations, we’re able to ingest events from all these products. And the event, the incident, can start from any point, from the email protection system, EDR, it doesn’t matter. We ingest the events, we normalize the data, we put it into our repository, which is a big data repository, a big database, that has to be quite powerful to do all the work that we’ll get to in this dismissal escalation stage.
We normalize the data, extract all the artifacts, and start doing first-level correlation. And then we move on to triage. That is all being done without a SOC analyst involved at this point. In triage, the first thing you do is deduplication, we remove the duplicates, we enrich the data with threat intelligence, we have customers that have 30, or 40 threat intelligence feeds, which were able to query. All that’s being added to the event record. Eventually, when we hand it off to a SOC analyst, they will have everything they need in that record, including all the correlations. Then we do lookups in a product, for instance, ServiceNow. And then we extract only asset details. This is a VIP asset, is this a high-risk asset, who’s the owner of the asset… we put all that into their event record. And then we do event correlation.
The event correlation is correlating events across the entire cyber tech stack. That’s where SOAR 1.0 fell down. They did not correlate across the entire tech stack. So we have these IOCs and IOBs and we’re able to query. If an event comes in from an EDR product, we’re able to go in and start querying the email system, network, and other systems to find events, correlate it all. And then a final step – TTP labeling. I give credit to EDR vendors, a lot of the antivirus EDR vendors are sending us events with techniques and sub techniques from MITRE. We’re able to load those in. D3 can also do it on its own, but we have to load those into the event so that the SOC analyst has all the techniques and sub-techniques.
Then we move on to dismissal and escalation, this is where the reduction happens. We can reduce, in a lot of cases, false positives by 90%. We have dismissal rules in, we’re able to do lookups on and dismiss false positives. And then finally it gets to the SOC analysts, and then triage rules are kicked off. And the triage rules tie back to the ServiceNow queries, depending on the asset. You might have different triage rules. And then it gets auto-assigned, again based on the criteria in the event. And then finally, you have all the responses in the final stage, and there are a lot of notifications going off within the SOC team and outside of the SOC team. And the automated actions, which is SOAR automation. So those actions again, if you have 20, to 30 actions that you can do, based on deep integrations, you can go and resolve the incident through automation.
And then finally reporting. You need to do trend reporting, also the TTP labeling that ties back. If you have the techniques and sub techniques built into your event, you can do trending, and you can see which techniques are being used most frequently against your organization. And then you can alter your defense mechanisms to counter that.
That was a lot to do in a very short amount of time. But that’s the process. Build this process, and you do not need D3 software for this. I hope you do buy D3 software, but you don’t have to, you can do this through open-source tools. But follow a process similar to this, or this process, and you will reduce the noise. And you will become, as you build your SOC, an MDR-based SOC.
On Building the Right Process in the SOC
Allie Mellen: Building the right process is critical. That’s one of the first things that I recommend to security teams that come to me and ask, “Hey, we’re thinking about getting SOAR?” I ask them, have you defined processes for things, because if they haven’t, then they’re not gonna get a lot of use out of SOAR. Through no fault of the tool. You need to understand what actions to take, or could take regularly to improve your existing workflows so that you can automate those. So it’s just a basic requirement of any type of automation taking this form.
What I like about this is that it’s very structured around enrichment. I think that the reporting side of things is one of the areas that most often is not called out with SOAR. But there’s a ton of really interesting metrics you can use SOAR to collect, that will add a lot of value.
And this kind of ties back to what Gordon said about making your SOC into an MDR. A lot of the leading MDR providers do a ton of analysis on the metrics that are coming in, on how well their analysts are performing to help make the product better so that they can then perform better. And it’s a huge problem to be able to get that information in the SOC. It’s a huge challenge because you’ve got enough to do without worrying about collecting metrics and trying to optimize or at least cut out the fat with certain activities. Having a tool that can help you get to the point where you can track these metrics and track how you’re performing against them is incredibly valuable because it lets you then see, hey, is this information that we’re bringing in helping us or hurting us? Are we actually finding things? Or are these detections not doing their job? How can we measure that? How can we measure how much time it takes an analyst to work through and alert based on the context that we’re providing them? It’s something that MDR providers have because they have the luxury of having a product team behind them and a data team and all of the things that security operations teams internally just don’t have.
When SOCs Put Technology Before Process
Allie Mellen: It’s quite common that security teams and CISOs come to me and they say, “Hey, we want to, we want to get started with the automation in the SOC.” And I asked them, what’s the driver for that? And ultimately, it’s other parts of the business wanting to use automation more across the business.
And this raises a bit of a problem, the drivers are not around, “Hey, we have this process that we do all the time, and we want to automate it, so we can stop doing it all the time.” It’s more of, we know that the business needs to be automating as much as possible to save time, and we want to get technology that’s going to let us do that. There’s a huge gap there, which comes into play with defining that process, like what you’re showing here. And that is the main thing where I usually say, hold up, let’s map out at least a few examples of what you guys do on a regular basis so that we can then make sure that you’re getting SOAR and using it the most effective way possible. And also that you’re getting a SOAR that has integrations with the tools that you’re talking about.
There are several SOARs that are limited on the depth of their integrations or the breadth of their integrations. And if you don’t go into it, knowing what those limitations are, and knowing how those are going to affect your implementation of the automation of these processes, then you’re going to be in trouble.
I think that if anything, we see that the security teams that I talked to are skipping a step, and they’re jumping to automation before they’ve been able to fully define the processes. And a huge part of what we do together is trying to take a step back and re-align to defining these processes, making sure that they’re written down somewhere, and then using SOAR to automate them.
The Most Critical Trends Facing Enterprise SOCs and MSSPs
Allie Mellen: At Forrester, we do a yearly survey of thousands of security leaders to try and better understand where they’re at, not just from a SOC perspective, but generally, what the CISO’s responsibilities are, where they’re struggling, where they’re getting more budget, pretty much all the questions you could imagine asking in the world. And, of course, we always start with what are your top challenges, and every single year, the top three challenges are the same. They’re always: a) The changing and evolving nature of IT threats, b) The complexity of their IT environment, and c) Day-to-day tactical activities taking up too much time.
No matter how much more advanced we get, no matter what new tools are introduced, it’s the same three problems every single time. The most critical trends are the ones that continue to plague security teams year after year after year.
When you drill down into the data and try to separate it into enterprise versus MSSPs. A lot of the focus comes more around on the enterprise side, things like maintaining the skillset of the security team, finding new security analysts that are going to be able to support the team effectively, getting business buy-in, getting alignment. These are things that you don’t see as much on the MSSP side, or they’re at least different because obviously, they’re a profit center instead of a cost center like the enterprise SOC is.
A lot of the challenges from the enterprise side are on budget constraints, and how that impacts their ability not only to hire but also to have the tools that they want to make the most use of, to continue to train their team to keep and retain talent. Whereas on the MSSP side, it’s mostly focused on cost-cutting, and being able to find and access more customers building trust.
Gordon Benoit: I think enterprise and MSSPs are facing similar, similar issues. I’ll give an example. One of our customers had an MSSP they were using, and the MSSP was complaining that the alerts keep growing, and the enterprise said, well, we’re going to implement a SOAR tool, and we’re going to reduce the number of alerts and the MSSP obviously, was skeptical.
Six months later, they reduced the alerts by 90% by going through and building, something very similar to the process I showed before, the Event Pipeline process. And unfortunately, the MSSP were fired. So not only did their business not grow, but they lost the entire account because they only were dealing with 10% of the incidents that they were dealing with, at that time. So they were able to do the work in-house, and they became an MDR shop, an internal MDR shop.
With the MSSPs, we talk to them every day. They come to us with the promise, hey, listen, we want to grow our customer base from 100 to 200 customers, but we don’t want to go from 40 analysts to 80 analysts. Again, being more efficient is key. Automation is key. So they count on our SOAR tool, and probably other SOAR tools on the market to help them be more efficient.
The MSSPs are under tremendous pressure from what we’re seeing. They’re threatened by the EDR vendors that have MDR services, and they’re threatened by the independent MDR vendors who are really doing a great job. And then they have the tech conglomerates who have everything. They’re under a tremendous amount of pressure, and they need to move to more of an MDR-centric approach, become an MDR, don’t become that MSSP that got fired.
The MDR vendors that are out there, independent vendors, claim that they can reduce events by 80 to 90%, similar to D3, with their proprietary software and their experience team. When the customer looks at that and says, “Why am I paying this MSSP when the alerts are down by 80% or 90%?”. I don’t think you want to have that discussion with your customer. So, again, I go back to the process of building up the process. Either build it yourself or use some tools that are on the market.
Read: How adding SOAR turned ineffective MSSP into valuable asset
Advice for Busy Security Teams
Allie Mellen: When it comes to using SOAR – the first thing that I of course have to say is define processes. That is the most important thing that you can do when you’re considering starting to use SOAR.
The second thing that I would recommend is: If you’re looking for a place to start, the most common and the most achievable use cases are improving investigation and enrichment. When you’re thinking about how your team most often does enrichment and investigation manually, what aspects do you do every single time that you can just automate right now? That’s a great place to just get started and get at least one playbook going. That will make sense and will be a benefit to your team and show the value of SOAR early on. This is also great for teams that are hesitant to automate response, which I see quite a bit even now. There are certain aspects of response that they’re willing to automate, but not across the board. Some of the most value you get out of SOAR is automating aspects of enrichment investigation.
Take advantage of the orchestration element of SOAR. You don’t have to automate response. You can use it to orchestrate response across tools across your environment. That is incredibly valuable. It’s not very achievable with many other security tools outside of the SOAR market. And it’s a good balance between not necessarily automating response outright, but still giving your analysts control and the ability to say, “this isn’t going to be the right action to take here.” But still speeding up their response times quite a bit.
Lastly, set yourself up to move towards a zero-trust approach. It’s kind of in my job description since Forrester came up with the term. But ultimately SOAR can help you move towards zero trust as well and set you up to be on a better path towards zero trust, because of the way that you’re able to control individual systems to orchestrate that response to manage and have visibility into your environment. And monitoring, even though it’s not commonly associated with zero trust, is an incredibly important part of it, as is detection and response.
Gordon Benoit: Build a process for your incident management, and incident response. Use MITRE and other frameworks. Embedding those TTPs into your event processing and leveraging them is extremely important. Once you’ve performed the remediation, you need to look at the root cause and perform corrective action.
The Role of the SIEM in the SOC
Allie Mellen: This is something that SIEM vendors and security analytics vendors are trying to come to terms with as well. When SIEM started, it was the collection point for all this telemetry. It was the place where you were able to consolidate all these alerts. But we needed other things too. And that’s ultimately where SOAR came into play. And SOAR was able to provide additional benefits, like being able to do this really tailored enrichment, being able to allow for response. SIEMs, even though they have been the center of the SOC for a long time realize that without addressing more aspects of the incident response lifecycle. Think – additional enrichment. Think – response aspects as well, then they wouldn’t be able to maintain themselves as the center of the SOC. This is the reason why we’ve seen SIEM vendors, either building or in a lot of cases, acquiring SOAR vendors, because they want to maintain that position as the center of the SOC. Without the ability to automate and orchestrate response and investigation, they’re not going to be able to do that.
So ultimately, the role that we’ve seen with SIEM in the SOC is about being the place where all that telemetry is brought and kept. Now that’s changing because of the advancements in their integration with SOAR technology that they have acquired. Or in some cases, we see that they just build it right into the product itself and try to not keep it as a separate product. Now, there are pluses and minuses to that, because by building it directly into the product, it ties you to a particular SIEM when maybe you want to be using a different one for compliance use cases, or what have you. But ultimately, the goal is to still position SIEM as the center of the SOC, just a lot of work is being done on the source side because that’s where we see a lot of the focus happening with practitioners.
Now, when it comes to pure play, or standalone SOAR. Ultimately, the SIEM is still an important requirement because of things like compliance use cases, because you’re able to collect all that telemetry in one place. But for those that don’t have automation, and response and orchestration capabilities built-in, you still really need a SOAR. Otherwise, you’re not going to be able to get that ultimate benefit of being able to connect all the pieces and build a more comprehensive workflow for analysts. You’re going to run into a similar problem that you’ve seen with point solutions, where they just aren’t able to produce the outcomes that you want your security team to be able to have, to improve the workflows that your security team has.
Read: SIEM vs. SOAR: How they Differ and Why they Work Well Together
Is Open XDR Losing Ground to Native XDR/SIEM? What Does That Mean for SOAR?
Allie Mellen: Ultimately, I see a big difference between XDR, SIEM, and SOAR. I described them in my first report as “on a collision course”. I very intentionally chose the word collision as opposed to consolidation. Because I think that they’re addressing different things and are not looking to be the same thing at all.
XDR is very focused on improving those workflows. The thing is, it’s the product vendor doing it. They are looking to build those workflows in, and not have the security team need to do as much customization, as we’ve seen, has to take place with the SIEM and with SOAR because these points solutions haven’t been able to tie the pieces together.
What XDR is looking to do is tie those pieces together for you to help build better detections, by limiting the scope of what’s coming into the system, by focusing in, around a couple of telemetry sources that can provide valuable detections, like from the endpoint, like from cloud.
This is very different from SIEM because it’s very targeted and customized. And it’s based on what MDR providers are doing. Most often, the most compelling XDR product providers are those who have an associated and successful MDR because they’ve built this system that is optimized for practitioners. Because their practitioners use it every single day.
This has built a very simplified system that is very tailored to particular use cases, as opposed to SIEM, which we see as much more general. You can build your own detections, you can do your own things, great, but it can be difficult when you don’t have the talent to be able to customize it.
I see these things as continuing to be very separate and as we are seeing these potential acquisitions taking place, ultimately, they are getting closer to one another as competitors, not necessarily as combined consolidated offerings.
In the case of certain vendors, you can see that taking place already, where they see the complementary use cases of XDR and SIEM, or XDR and SIEM and SOAR. They have both offerings for different use cases. It’s just a matter of addressing the use cases that the security team has, based on what flexibility they need, how much staff they have, how much ability to customize or to build playbooks they have. All these factors need to come into play. XDR and SIEM do that in very different ways.
Read: Why XDR is Not a Replacement for SOAR
Top Reasons Why Customers Are Gravitating to Independent Vendors (Like D3 Security)
Gordon Benoit: Because you could change your entire cyber tech stack, and you could keep D3 or other independent SOAR vendors. Basically, and literally in D3, you can drag and drop the vendor away. You could move from Cisco to Fortinet. You simply go into the playbook, the workflow editor, and you simply drag and drop Cisco, and then you add Fortinet, and D3 already has the integrations built-in. With a tiny amount of configuration. You’re not dependent on any vendor.
The processes you follow for your incident management stay the same, no matter what vendor you help. I think that that’s a big reason. The fact is, we’re focused; this is all we do. They can come up to us and work with us to build things like the Event Pipeline. We have no conflicts, we’re able to think about it, work with them, we’re open-minded.
Our SOAR comes automatically with 500 integrations. Guaranteed, the 30 or 40 products that you use are probably on that integration list. Take advantage of that data and take advantage of the deep integrations that we have.
And the fact that we have no conflicts – for example, Fortinet talking to Palo Alto about integration, I don’t know how deep that integration is going to be. With D3, it’ll be a deep integration, and then that’ll allow you to do deep searching, correlation, and, and actions, multiple actions.
Allie Mellen: The depth and breadth of integrations are a huge positive that I see clients looking for, from independent or pure play SOAR. The first question that I get when talking about automation in the SOC is “Who are the independent and pure play SOAR vendors out there?” Because that’s a huge priority for clients. They want a tool that they know is going to have broader, more effective integrations with other products that aren’t tied to a particular portfolio of products, that doesn’t have specific requirements around the rest of that portfolio, and they can buy on their own.
The second is the focus on the actual vision and mission of the product around security and automation. And around making that better through innovation. That’s a huge positive for clients, they want to see something that’s going to be evolving with them, they don’t want to see something that’s a checked box on the part of the vendor.
And sometimes that happens, especially when you’re thinking about it in the context of automation technology, which is difficult to innovate in this space. They want someone who’s going to be able to keep up and to have a point of view on the market and to push that forward.
And then lastly, the quality of customer support. A lot of times when you have a portfolio or a platform vendor, SOAR is not their main offering, it’s usually SIEM or some other offering in their portfolio. And that means that you don’t always get the level of customer support and product support that you might like to see. And that’s where a pure play vendor is incredibly beneficial because everyone on that team is focused on improving the automation of the product and improving the ability of the SOC to automate. So that can also be a huge plus for security teams.
Watch: Forrester and D3 Debate the Future of SOAR
