Sophos CTO Joe Levy On Surging MDR Demand And Endpoint Security Updates

Managed detection and response (MDR) ‘continues to be the fastest-growing offering in the history of Sophos as a company,’ Levy tells CRN.

Services Revolution

Since transitioning its managed threat response offering to a managed detection and response (MDR) service at the end of November, Sophos has seen strong demand that’s not expected to be slowing down anytime soon, Sophos CTO Joe Levy told CRN. The cybersecurity giant disclosed a suite of new endpoint security capabilities that will help feed into the MDR service — as well as the underlying extended detection and response (XDR) platform that helps to power the MDR. The updates include new account health check capabilities and “adaptive active adversary protection,” which offers the ability to disrupt attacks that are in progress and “buy more time for responders,” Levy said.

In just the three months since the MDR launch, Sophos has already added 2,500 new customers for the offering, now reaching 15,000 MDR customers in total. “This continues to be the fastest-growing offering in the history of Sophos as a company,” Levy said in an interview. The surge in demand for MDR — coming amid a massive global shortage of cybersecurity talent — is also helping to prove the company’s thesis that services are the future of security, he said. Ultimately, “I believe that services are going to become the primary consumption model of cybersecurity in the industry over time,” Levy said.

Levy also discussed the new endpoint security updates that aim to help with security automation, including around fixing insecure configurations.

What follows is an edited portion of CRN’s interview with Levy.

In terms of your MDR service, how does that fit with what MSPs and MSSPs are offering? Isn’t there some overlap?

We wrestled with this for quite some time before we brought MTR to market. This was our single biggest concern — the potential for channel conflict. We are a very channel-oriented company. We always have been. The success of Sophos to this point has been predicated on the health of the relationship that we have with our channel. That’s unchanged. We spent a lot of time with our advisory councils with our channel community at large. We basically described what it was that we were going to do, what it is that they will continue to do, and the benefits that will be conferred to them when they begin to sell this service that we now have. So I would say that on the margins, there are potential conflicts between business models. But for the vast, vast majority of cases, all of the relationships that we have with our partners, and our MSPs in particular, have been significantly aided by us bringing MTR and MDR to market. In fact, if you look at the activity that we see in the sale of MDR, and you break it down between our partner community, and our MSPs as a specialized partner community — there’s a lot more activity occurring within MSP. In other words, the MSPs have embraced it more than non-MSP partners have, which was a very pleasant surprise to us. But I think it validates the work that we had done just to conclude that yes, indeed, this is going to be something that’s very complementary to our partners rather than something that’s competitive.

Can you provide a few examples of the things that MSPs still do when they’re using your MDR?

One of the interesting things that we did is when we brought MTR to market in the first place, we introduced three different modes of engagement. So the customer and the partner can elect to have us just notify them — one or both of them — in the event that we see some kind of a security incident. They can elect to have us collaborate with them, meaning that we can jointly sit inside the Sophos Central console, and we can jointly perform security operations, do threat hunting, respond to threats or incidents as they might be occurring. Or they could say, “authorized” — we just authorize Sophos to take care of absolutely everything for us. That’s effectively where they just turn the keys over to us and they say, “Go for it. If you see something happen, just take care of it on our behalf.” So it’s the fact that we provided those options, which was unprecedented at the time in the industry. And I believe that it still is perhaps. It gave them the flexibility to be able to continue to do what it was that they were doing, and do it in concert with us. So rather than saying they needed to do it exclusively, or we needed to do it exclusively, we had a setting that allowed them to choose what that engagement model looked like between us and then as the partner — and us, them and the customer. That’s one of the big differentiators. We think that we did something pretty special in that respect.

What are some other key differentiators for your MDR?

The next thing that we did is we are the only endpoint security vendor at this point that offers a fully vendor-agnostic MDR service, [thanks in part to] our ability to now work with the variety of different third-party integrations that we have. If you look at the set of endpoint security companies who are in operation today, some of them provide an MDR service — but we are the only ones who provide an MDR service that will actually operate across the entire vendor ecosystem.

So what are the others doing who say that they have third-party integrations, then?

They’re not providing “response” with a capital “R” the way that we do. This is another differentiator. MDR sometimes it’s a little “r” and sometimes it’s a big “R,” and I like to say that we’re a big “R.” So little “r” basically means that it’s an offering that can ingest signal from any kind of a source, and then the output would be, “Hey, customer, there’s a problem that we’ve seen from this IPS [intrusion prevention system] alert that you received, or this alert that we received from your email security platform — go take care of it.” We do have that available as an option, with our Notify offering, but we don’t stop there. Big “R” would be, we actually perform incident response, or we respond to the case and perform a full investigation on behalf of the customer when we see such a thing.

There are pure-play MDR vendors out there. There’s Arctic Wolf, and eSentire, and Expel, and Red Canary, and Binary Defense. There’s no shortage of competitors in the MDR space today, and all of them are strong in their own respects. But none of those that I mentioned bring an actual technology stack as an option for customers. What they say is, we’ll use whatever technology investment you have, but they don’t provide a set of options on their own. Perhaps they have a set of tools or sensors that they can deploy, but they’re not in the commercial market, where they have 300,000 endpoint customers, for example, or 300,000 firewall customers.

So the advantage there is that your MDR can work with any customer?

Our MDR will. Historically, when we launched our managed threat response, it was a really, really big hit. Massive uptake, the partner reception was fantastic, customer satisfaction was through the roof. The only issue with it was, we didn’t work with third-party products. We just worked with the Sophos ecosystem. So it was great, so long as a customer was using us on the endpoint and us on the network and us for email. But if a customer was using us for network and endpoint, and they were using somebody else for email, we didn’t want to go to them, and say well, “Displace whatever it is that you’ve gotten, buy our stuff instead, so that we can get the full benefit.” That’s not the kind of behavior that you would [want] from a vendor. So now we have the ability to say, “Whatever it is you’ve got, we can use that. And if there’s anything that you would like to upgrade or consolidate, or if you’re missing a solution within your environment, just look at the menu of options that you have within the Sophos portfolio, and we can provide some complementary support there.”

Does the XDR work with all the third-party products in the same way?

That’s coming. We launched it first for MDR. So one of the one of the interesting things that we do is we introduce capabilities first in the service, and we sort of hone it in the fires of actually running in a live service environment. And then we port it over to the product as a set of capabilities. And that that kind of pattern is something that we’ve been doing for three years now, and it’s served us really well. We’re in the middle of the same thing right now. So the third-party capabilities for XDR are going to be coming a little later this calendar year — probably early second half at this point.

Would you say the vast majority of your customers are choosing MDR rather than XDR though?

That’s right. We talk about the cybersecurity skills shortage a lot. There’s just a lot of competition for hiring, training, retaining this kind of skill set. There’s difficulty in running a 24/7 global security operations center. Not all businesses are equipped to be able to do it. And the problem is attackers are clever. So they wait for the most opportune times to actually launch attacks. They’re going to do it on holidays. They’re going to do it at two o’clock in the morning. They’re going to do it on weekends, when the vast majority of organizations are not sitting there in front of a console keeping watch of things.

We’ve got customers of all sizes from two-person flower shops up to 200,000-seat, Fortune 100 environments. It tends to be the smaller enterprises that are least well-equipped to be able to deal with the threat landscape. And they’re the ones who could potentially most benefit from these kinds of service offerings. So we did invent this with them in mind. And one of the interesting things is just the volume of customers that we deal with today. So again, we’ve got over 15,000 MDR customers — by that measure, we’re one of the largest, if not the largest, MDR providers in the world. There are some other MDR vendors who have a fraction of the number of customers that we have — maybe a tenth of the number of customers — but their customers are 10 times larger. So you might end up with comparable billings to what we have. But we’ve built the entire machine to be able to serve the channel and serve large volumes of small customers.

We have this internal notion of “an endpoint is an endpoint,” meaning that it doesn’t make a difference to our operation. Whether we have one customer with 1,000 endpoints, or 10 customers with 100 endpoints, or 100 customers with 10 endpoints, we just treat them all the same way. So that’s another differentiator that permits us to operate in a certain way that many of our competitors can’t do.

It needs to be consumable for small enterprise, as well. You need to make sure that the engagement model is something that people are actually able to deal with. That requires that your sales model, your channel support model, facilitates the kind of engagement at volume with these small businesses.

What’s ahead in terms of new capabilities for your MDR offering?

We’re going to continue to build out the set of third parties that we integrate with. We’re effectively into the tail of it now. We’re just going to continue to build out the tail. As we’ve already discussed, we’re going to be bringing it from the service to the product. So we’ll bring all the third party integrations into the XDR offering. We continue to make really significant enhancements in the endpoint protection capabilities as well.

We’re disclosing a set of enhancements to our XDR product, which benefits the MDR service customers as well. There’s a few that I’m really excited about. One is, one of the things we discovered when we started our MDR service, as the MTR offering, was that in order for us to be able to protect a customer environment, we first needed validation that their configurations were not “pathological.” Meaning, “did something happen in the configuration at some point — maybe by an administrator who no longer works for the company — that is fundamentally undermining the effectiveness of the product?” It was sort of a theoretical question we asked ourselves. So we built a health check into MTR. From the day we launched it, we started doing an account health check. We evaluated the policy, and lo and behold, there were a lot of “pathological” policies out there. We had the suspicion that this would be the case. This is why we did it. And the data supported our thinking. So this is prevalent within the industry today — whether it’s an endpoint policy or network policy, or a cloud guardrail policy that might be in place. Oftentimes, there’s configuration creep, and bad policies begin to undermine the effectiveness of the protection technology itself. So we leveraged that into our products. So the same way I was saying we have this really effective model now, where we test something out in the service, and then we bring it into the product — we brought that health check into the product. So now, all of our endpoint customers have this health check capability, where we just let them know if something bad has happened to their configuration, whether it was intentional or accidental. We just notify them very clearly. We give them the information necessary to be able to remediate it.

We’re about to introduce auto-remediation. So not only do we tell them what’s wrong now, but we say, “Click this button, it’ll fix it for you.” This I think is one of the most fundamental contributors to failures of security products in the world — bad configurations. And we’ve taken the technological steps to be able to improve that.

Another interesting thing that we’ve done is “adaptive active adversary protection” — or 3AP for short. It’s a new set of logic that we were able to construct from all of our interactions within our MDR customer population and our engagements with our incident response service. We’ve taken the learnings from [IR] engagements and from the protection of our MDR customers, and we’ve encoded that logic into the product. And what it does is, it puts the product into what we call a “breach mode.” Basically, there’s a set of logic that will trigger a number of conditions, whereby the product just goes, “It appears we’re under attack.” And under attack could mean, we really believe that it’s an active adversary who is about to launch some kind of significantly harmful attack on the network. Or it could be a pen test. So it’s very difficult to distinguish a well done pen test from an actual active adversary. So what this capability does is, it will flag both of those, and it will transition the product into a “disrupt” mode. You could think of “disrupt” as being a “skepticism” — where the product has become skeptical of things that it would normally tolerate — it becomes less tolerant and goes, “I’ve never seen that executable before. I’m going to prevent it from running.” Or, “I’ve never seen this connection to this particular endpoint before — I’m going to prohibit that from happening from this particular process.” So I think this is just going to buy more time for responders.