Listen to the following security experts share their insights in the webinar:

• Garrett Bekker, senior research analyst at 451 Research
• Jasson Casey, CTO at Beyond Identity
• Mario Duarte, VP of Security at Snowflake

Transcription

Malik

Hello, everyone. This is Malik. And on behalf of Beyond Identity and 451 Research, which is now a part of S&P Global Market Intelligence, I would like to welcome you all and to thank you for attending today's roundtable titled What role does passwordless MFA, device trust, and managing developer keys play in Zero Trust? 

Leading off today's discussion will be Garrett Bekker, who is senior research analyst at 451 Research. Joining Garrett will be Jasson Casey, who is Chief Technical Officer at Beyond Identity.

We also have Mario Duarte, who is VP of security at Snowflake. And with that, I will turn it over to Garrett to kick off the session.

Garrett

So very happy to have Mario and Jasson with us today to talk about a topic that's been really near and dear to my heart and certainly been big in the news for the past couple of years, certainly around passwordless and also around the notion of zero trust.

So looking forward to having a lively discussion, but I think, before we jump in, I think, Mario, maybe you had a slide you wanted to talk to about Snowflake before we jump in.

Mario

Yes. Thank you, Garrett. And thank you, everybody, for joining us today. I look forward to hearing some questions from you folks as well. So let's keep it lively. You know, Snowflake is a data cloud company. We've, you know, been around for over nine, 10 years now.

So data for Snowflake is the most important thing that we need to protect. Our customers are trusting us with the keys to the kingdom in the form of their data. And so we take that very seriously. And for years, what we've done is we've looked at the threat landscape and continue to harden or employ more security tools and techniques to reduce the potential for data to be compromised, things such as IP whitelisting, multi-factor authentication, encryption at rest, bring your own keys.

And we've also tested these through the years through independent pen testers and auditors, and we have, you know, a significant number of certifications, including FedRAMP Moderate, and HITRUST, SOC1 and SOC2, and more, you know. So even with all those efforts, it always continues to see the same challenge over and over, and that is, no matter what our mission we employ, no matter how we restrict access to these production environments, to the keys to the kingdom, or hold the keys to the kingdom.

It always has to go back to the user. Who is the user creating this automation? Who is this user interacting with this production environment? And where are they coming from? In other words, what systems are they using? And oftentimes, you'll see people employ things like passwords. And I have to tell you that that is just not working anymore. It never worked, but nowadays, at the speed of light, with cloud computing, it's just failing. So I look forward to this conversation, Garrett and Jasson. Thank you.

Garrett

Awesome. Thanks, Mario. So some interesting points there. I guess, maybe we can start off with an easy question, you know. What is passwordless really? There's a lot of talk about it. Why do we need it? What are some of the benefits that, you know, passwordless addresses?

Jasson

So I'll jump on that one. This is Jasson. I'm the CTO of Beyond Identity. And again, thanks for having us here. Passwordless can mean many things to different people, right? And ultimately, I'm going to talk about what it should mean, right? So a password is this secret that you and I know that we use to prove to some system that you are who you say you are, right? It's a knowledge factor. 

But appropriate knowledge factors are high-entropy strings that are rotated on a regular basis. From a usability perspective, that's not something that my brother and my sister, my parents, or non-tech workers understand to start with, and it's also not something that people really can kind of conceive of carrying out. So they end up reusing passwords. Passwords get breached in datasets. And those datasets that are breached get used to launch stuffing-style attacks. It's somewhat of a flawed factor to authenticate an end user. 

So passwordless for Beyond Identity it's about really thinking about how do I authenticate and authorize the person or the claimed identity and the device, right, because the device has just as important a role in deciding whether you want to allow someone access to a piece of data or a service. What's the risk of the identity that's actually being claimed is who they say they are, and what's the risk of the device to either receive the data or carry out the operation that it's asking to do? 

So the way that we achieve or solve those problems is to use things like strong authentication, right? So if a database is compromised, it yields public keys. It doesn't yield private keys. Those public keys aren't really useful for anything. It's to leverage things like hardware-based encryption and key management. So passwords or the private key, if you will, become immobile. They physically can't move, right? If a password's not moving, it's harder to be intercepted. It's harder to be reused in ways it's not intended and to wrap both of those things up into a framework that understands behavior of a person and a device over time, to try and really allow people to make fine-grained decisions on every access.

What's the risk of a device? What's the risk of a personal claim? What's the criticality of what they're trying to do? And am I mitigating that risk effectively to allow that transaction? And if I'm not, let's deny it. And maybe there's some middle ground where, technically, the mitigations aren't there, but maybe the user could do something to achieve the appropriate level of mitigation. And so, to interact with them and, you know, in the simplest form, act for a step-up, or a biometric, or in a more extreme extent, require someone to a re-identity group.

So, like, these are the types of things that we focus on with kind of this concept of zero trust access. And passwordless is really kind of a mile marker or a waypoint in the journey. It's not the destination.

Garrett

Interesting. Thanks. So maybe one of the things I want to get to too is we all know passwords are [inaudible]. I got a story I like to share on this. But I came across, in my office, last year, a really compelling article about why passwords were going to be completely obsolete in the next few years and for some of the reasons you mentioned earlier.

The only problem is that that report was dated 2001, so it's now 20 years old. Here we are 20 years later and passwords are still everywhere. And you would think that the logical response to that would be multi-factor authentication, right? We hear a lot about that. Yet our own data at 451 shows the last few years that MFA adoption in the enterprise has been kind of stuck in neutral, right? For the last couple of years, MFA adoption in the enterprise has been around 50%, 51%, 52%. 

We got a nice bump due to COVID and work from home last year, bumped up in the 60% range, but it's still way below other security technologies, things like firewalls, and intrusion detection, and email security, and SIM, what have you.

I've got some views, on that but I was just curious if you or Mario had any view on, you know, what are some of the drawbacks that traditional 2FA, MFA, and why it hadn't become more prevalent.

Mario

You know, I'll take a stab at it. I think multi-factor authentication is important, but it's only one piece of the solution. You know, it's interesting, you mentioned this old 2001 article, but I would argue the reason why passwordless solutions haven't been embraced by people, by the market, by the industries, is that it hasn't been made easy.

It's difficult. It's complicated back in 2001. And really what vendors need to figure out is an eloquent solution that can leverage the existing advancements in technologies that are now available to all of us in our hands, our laptops, our iPhones. 

You know, Jasson talked about things like, you know, like an enclave chip. Enclave chips, in 2001, yeah, they were around. You know, we got NCiphers, you got Rainbow Technologies, etc. But that wasn't available to the broad audience, broad folks like, you know, now, with economics, with the advancements in technology making things cheaper to build. Now, you have enclave on your laptops, and you have it on your smart devices as well. And that, I believe, now is the right time to revisit a passwordless solution.

Garrett

I'm just going to say, all of our research shows... maybe it supports that, but our research has shown, overwhelmingly, one of the biggest objections to traditional MFA has been just a bad user experience.

Jasson

I would double down on that and say, you know, there's a push and there's a pull. The cost of incidence is real today. It wasn't necessarily real in 2004, at least from a business perspective, or an executive's perspective, or a budget perspective. So that's the push. And the pull is availability and pervasiveness, right? 

To do business with the federal government, you're going to have to have TPM protections on devices to actually manage keys. That's going to get mandated. It has quite the availability of whether it's TPMs or enclaves, but the concept of hardware devices that are tamper-proof that are managing keys and authorization policies on the use of those keys, right, outside of the normal stream of software that's running in the U.S.

These are all common today, and they certainly weren't before. And just kind of hitting the final nail on usability, half the reason passwords don't work is because they don't fit UX or usability on how people actually behave and what's easy for them. And security solutions that are hard on your end users, your end users end up just finding easier paths around those solutions as opposed to embracing them.

Mario

Yeah. You know, I'll give you an example to add to what Jasson's saying on those passwords, you know. You create these wonderful huge passwords, 20-character passwords, but employees hate them, and what they'll do is they'll always adjust the last two digits or three digits of those passwords or the first three digits, right? So they're smart, right? 

Like, look, LinkedIn, right? LinkedIn had a major password breach years ago, right? And you'd be surprised how many of your employees are reusing those LinkedIn passwords, the same ones or maybe just with a change in one last digit, right? And guess what, the bad guys know that, and they target our people, and they're very successful at it.

Garrett

Yeah. All it takes is one easy password, right, and you're in. So maybe switch gears a little bit. You know, one of our themes in the title is to talk about zero trust, and that's another big, I guess you'd say buzzword these days, it's certainly something that I've spent a lot of time on. 

Maybe we just spend a second, what does zero trust mean to you? How do you think about it?

Because there's a lot of different definitions, and I think if you probably talk to 10 different vendors, you get 15 different answers on what zero trust means. What does zero trust mean to you, and how do you see passwordless and device trust fitting into a zero trust framework?

Mario

Well, I can take a stab at that. I'm going to make it really simple. I think very simply on some of these topics. For many years, working from your corporate office, that was meant to be, you know, your home, your protection, your fortress behind firewalls, IPSes, etc. And so once you started building ACLs that would, you know, "I trust that network. I trust my office. Anything coming from my office can access X." And, well, I don't think that was ever very useful quite honestly, but it definitely is showing its age. That approach is showing its age with the proliferation of SaaS applications and cloud infrastructure.

So we, at Snowflake, about six years ago, decided to make all our offices to be untrusted. We didn't call it zero trust. We just called it untrusted. Just think of it as any office from Snowflake that you're working at. It's just like working from Peet's Coffee, or Starbucks, or some local coffee shop.

So ultimately, it was the endpoint. It's the Snowflake-provided, the corporate-provided laptop that becomes the trust.

Garrett

Yeah, yeah. It's similar, so for me, I agree with you. Everything's left the building, right? Users have left the building thanks to work from home and COVID. Devices have left the building. Apps have left the building, SaaS apps. And in that world, an old perimeter model doesn't work anymore.

So for me, zero trust, if you boil it down to its essence, it's about access to resources. It's not about where you are or what network segment you are, but it's about your identity, who are you, right? And if you can't get that part right and if we can't get MFA adoption above 50%, to me, that's fundamental to getting to zero trust.

Jasson

I was just going to jump in and say, I would make a stronger statement and say that perimeter security never worked. It was a way to spend money and feel good, right? Everyone's always talking about the M&M model of security, and that came from the fact that when we looked at these perimeter structures, we realized, "All right, so we just need to go through the firewall, right, or we just ride around the firewall."

And, like, the key insight and the origin of zero trust started a lot earlier around people realizing that anytime there's data copied to a machine, there's a chance for exploiting the program or the software that's going to read that piece of data. And that can happen through a web browser, that can happen through a USB stick, that can happen through an OS update.

So what is the core thing that I'm going to trust? How do I make it as small as possible? And every time I want to expand that ring, if you will, it requires some sort of mechanical proof, right? And you know, we do that now with TPMs, and cryptography, and cryptographic operations. And you know, the tools in that tool belt right now, they're not that big. They're pretty small, but they're getting bigger. 

And so we can prove things not just about, you know, keys that haven't moved around but also software state. We can prove that this TPM and this platform have not been modified, that the peripherals on the actual PCI bus are the same peripherals that shift with the system, that the checksum of the boot loader, in fact, has not been modified and that's actually what was loaded.

So that toolset is there today, and it's getting bigger, but zero trust, you know, at a core, it's about building that interactive proof of what we trust and why we trust it, and having, you know, the fancy word is axioms, but really what are the things you assume, how do we make that as small as possible, and then using that, and looking at that in a continuous way, and over time, just trying to get better at "Do I understand what's going on in the device? What's going on with the person with respect to what they're trying to do? And should I allow it?"

Mario

I also want to add that it, when I think of zero trust as well, is doubling down on the investments that the company has made, right? So if you think about the money we spend on hardening and securing our endpoints, that we buy DLPs, we buy tools to protect against malware, etc., and all of that goes out the door when an employee can use their own laptop or their own device that's not being monitored.

So think about all that investment goes out the door, right? It's whatever million divided by zero in the end.

Garrett

Well, that makes me think about what Jasson said, I was just thinking. What are some of the use cases? Because Jasson mentioned some of the things you can do with the TPM and with device trust. What are some of the applications? I'm thinking whether it be, you know, code signing, or in the case of developers, you and I talked about that in the past. Anything you want to elaborate on Mario, the potential application that you just mentioned?

Mario

Yeah. So, yes, definitely. If you start with the basics, right, you start with passwordless, then you start with, "Okay, not only are we going to use passwordless and use these TPM chips, but also we're going to give the device, you know, authentication on enforcement," right? I'm only going to be able to connect to these SaaS applications with no password from this laptop that's managed by your company and that you've invested all that money in to secure it and harden it.

Well, then you start moving up the chain. And the next logical thing is, "Well, what about my employees?" What about employees who are, you know, uploading to GitHub, for example, GitLab, or something out there where you're uploading your code, or even internally? How do you ensure that that employee was the one who uploaded that code and that it came from that machine that you trust?

So you can start seeing how this becomes this whole passwordless, this whole device authentication and verification, becomes an interesting play in code signing. Because now, think about what happens...I hate to mention SolarWinds. I'm sorry, SolarWinds folks, if they're here. But we learned from some of these things, right?

And if I remember correctly, it was a password, it was an easily guessable password for a code repository that eventually was used by an external entity to upload code as that person. Well, they did it from a different machine, at least my understanding, that's my understanding for the SolarWinds. Well, if you can enforce not only who can sign code but what devices they can sign that code from, it makes that much harder for the attackers. It's not impossible, but it makes it harder for them to upload the code from a different device.

Jasson

So the way we look at it from Beyond Identity it's identical to what Mario had just said, and we think of it in terms of chain of custody, right? So when you have an access request and you want to authenticate that request and determine an authorization, you can't ignore the state of the machine issuing the request as well as your understanding of the context of the request.

So in code signing, I think that gets to the same point, right? Like, not only is this the developer that I think it is and no one else, but are they operating from a machine that I feel is reasonably free of bad actors? Does it have the controls I expect to be present, right? And going one step further than are they present, they weren't just turned on before someone tried to commit the code, right? They were on the whole time. 

So it really is about a chain of custody, and a continuum, and sort of a continuous process of understanding the current risk and how history led up to the current risk in coding that as part of every access request, or as every code signing, or of every code commit. And we kind of view that as part of the zero trust ethos, if you will, but also doing it in a mechanically proven way.

So if something does happen, and eventually, you know, you will have incidents, but it should never be the case, understand what happened or where something went wrong. It should never be the case that you don't really know what developer committed that code object that went into CI/CD and ended up in this particular customer. 

You should always be able to track the custody to the developer as well as the status of their machine. Like, those are kind of the concepts if you're talking very much about code signing, but I don't think it takes much imagination on the audience part to see where that has implications on any type of access with key material.

You're going to want to understand the security state of the device, you're going to want to understand the providence and the custody of what they're trying to do, and you're going to want forensics that you know are tamper-proof, right?

Mario

And, Jasson, I think maybe one point that maybe we haven't highlighted enough, the whole idea of the certificate...I mean, a couple of things. Certificates have been around forever, right? Not forever, but long enough, right? Since 1999, at least when I was working on it.

But the big problem has always been about, look, okay, I go through all these investments, PKIs, certificate authorities, etc., and some big things to administer and manage. And then when you download that certificate onto a laptop, well, in the old days, you could strap that key. So all that investment you made, you can easily pull that key, put it on a different machine, and there you go, off to the races, we go again.

But with this new TPM enclave technology, that makes it near impossible, because it goes in, it's like the roach motel, they go in but it never comes out. That, to me, was important.

Garrett

What about FIREapps? You mentioned SaaS apps before. I'm just curious. You know, have you thought about how much of an issue has that been for you at Snowflake managing access to SaaS? I know our internal data shows that, I think in the next two years, SaaS apps will be the number one way to deploy workloads in the next two years. And it'll be followed shortly by infrastructure as a service. 

So I think it's fair to say that work from home has accelerated that trend, so I'm just curious, you know, your thoughts on that.

Mario

Well, I think we've gone through a journey, like most organizations. So, at Snowflake, we're probably using 200 to 300 SaaS applications. We have nothing on-prem. We were born in the cloud, we use everything in the cloud. So our challenge was it makes it easier for IT but it also makes it harder on security to secure these hundreds of SaaS applications.

So the first stage, you know, three, four years ago, was to have centralization for authentication and authorization in the form of IdPs, right? You get an IdP. Otherwise, you're having to manage different SaaS applications, so users and credentials, individuals, which becomes impossible after 10 or 20 SaaS applications. So one, get into the IdP.

Then even with multi-factor authentication perhaps, that helps, but again comes the problem of how do I know it's Mario? How do I know Mario is coming from a device that I can trust? And so many people have tried to make different things such as, "Oh, I'm going to use CASBs." And you often hear me, if you know me, that I can't stand CASBs, right?

I've been burned by them, all right? It's terrible. If you have questions about CASBs, talk to your engineering team and see how they liked it and how much they break productivity. Or they're people who go with the traditional solutions, they go with VPNs. They're going to say, "Well, you got to go to a VPN, VPN first, and multi-factor authentication on the VPN, and then you can access all the SaaS applications."

Fine. Tell that to your CEO. Tell that to your CFO. That they need to, in order to get access to their Salesforce, or whatever tool they're using, or you know, financial tools, have to VPN first. And you can see how all of this just starts falling apart. That's why it's really important. This is why I think passwordless, with this whole TPM enclave solution, is much more eloquent.

In fact, I know, we rolled it out to Snowflake, all our employees, and they love it.

Garrett

We can take a few audience questions if we want to open up to the audience Q&A.

Malik

The first question that we have received is, is SMS-based MFA required by regulations?

Mario

SMS-based, like as in text, sending a text for MFA? Yeah, yeah. You know, I will...well, I haven't heard that, and in fact, what I've heard...you know, I haven't seen that, and I've heard, if we're thinking about, like, sending text, SMS, sending text for verification, what I've seen is that it's not very useful or there are ways to exploit that.

So I think that's just my feedback. I haven't seen SMS as being a regulation requirement yet.

Garrett

Yeah. I didn't quite understand that question myself, but I would say exactly the opposite, right? Like, SMS, I can see regs actually eliminating SMS. In fact, I believe, NIST has deprecated SMS-based MFA simply because of some of the issues with man-in-the-middle attacks, what have you.

So if anything, for me, from an analyst perspective, I think the industry is moving away from SMS-based MFA and more towards more secure methods such as some of PKI-based stuff that's out there, FITA-based stuff, and some of the different technologies that, you know, we've talked about today. I don't know, Jasson, you have anything to add to that?

Jasson

Yeah. I mean, the SS7 network or the PSTN, the thing that carries text messages is notoriously insecure. It was never built for security. When you can hook into it and tell it you are whoever you want to be, and it will believe you. It's also not that difficult to get...there's no privacy protections in place for messages as well. So you know, it's never been a good idea.

Additional factors through other mediums, have always been kind of the preferred stronger techniques.

Malik

Thanks, Jasson. We have another one. The question is, how did Snowflake add all their users to Beyond Identity?

Mario

I always say it was magic. You know, I'm sure Beyond Identity has a different model. Well, you can go directly to them.

I mean, they, themselves, can be considered...they are an IdP, right? Jasson, I mean, do you see yourself partially an IdP as well?

Jasson

Yeah, no. We, 100%, we're an IdP. We have a directory store. We also hook into SSO as a delegate IdP.

Mario

Yeah. And so that's what we did. We invested heavily on our own IdP. You know, no surprise here, we used Okta, and so there was a lot of investments that we've put in Okta through the years. And what really makes things compelling with Beyond Identity is this whole, you know, trust where Okta will look to Beyond Identity to say, "Hey, do you trust...is that Mario? If so, great. Wonderful."

And so there's a relationship that happens, a trust relationship between Beyond Identity and Okta, which made it really seamless. And when I meant magic, I was...I'm sure I'm kidding around here, but it took less than 10 minutes to configure. It was pretty fast.

Jasson

Yeah. Just to add on to that, like, you know, the models that we support are pretty standard. We delegate through SAML or OIDC. So whether you're an SSO or an app, you can talk to us directly in that way. We provision identities in our directory using either a custom API or a SCIM interface that we've set in place.

And in Snowflake's case, I believe we're using the APIs of the SSO, because that's just how that particular SSO works. But again, it's all designed to let people experience what it's like in a very quick way. So give us 10 minutes, you can turn a bunch of people and see exactly what it's about.

Mario

Yeah. And I mean, just to add a little flavor to that. Even though we were able to integrate within 10 minutes, we slowly rolled it out. So you have those capabilities as well. It's not like you turn this thing on and it's game over. Everybody has to use Beyond Identity. You can actually control how many users are going to become your pilot users without packing the rest of the organization.

So we did a slow rollout. It took us about three to four months before we completely deployed it across the Snowflake enterprise, but it was about Beyond Identity technology. It was more about, you know, me and my level, my risk tolerance for turning things on right away.

Garrett

Mario, I'll put you on the spot here, did you look at any other solutions besides Beyond Identity? I'm just curious what options did you see out there in the market.

Mario

We did. No, there are other solutions out there, you know, and you should all do your homework. You know, all I can say is I've found Beyond Identity solution to be very eloquent, very easy to work with. So whatever solution you're looking at, you know, always think about, you know, how much is it going to take my team, or IT, or whoever's going to manage this, how much work is it going to require, how much administrative work, how easy it is this to integrate into your environment, how well supported it is.

And you know, Jasson has been a terrific partner for Snowflake. They are always...they listen to us, and they help us with some of our crazy ideas on how to use their tool.

Garrett

Thanks. And again, I didn't mean to put you on the spot, but in terms of not necessarily denigrating another vendor, I mean, kind of what were some of the key requirements that were really important to you? What were some of the things that, you know, maybe you absolutely had to have as you looked for something?

Mario

You know, again, the ease of use, the implementation, the ability to daisy chain, I don't think we've talked about that with Beyond Identity, again, I'm not selling you on Beyond Identity. I'm just telling what we did, right?

One of those things, remember, the whole trust thing, about trusting the device, well, I mean, you're going to get to employees' home devices, their smart devices, their phones, their tablets. They need to look at their email, corporate email, or their Slack, or whatever they're using. And so that integration with Beyond Identity, that seamless integration and enforcing, so this is a little bit of looking at or enforcing potentially the hygiene of those devices owned by employees was really useful.

So in other words, that daisy chain method that Beyond Identity has made it really eloquent for us. That's what I mean by ease of use. Jasson, do you have anything on that?

Jasson

I mean, I would say you need a solution that anchors keys, keys can't move, period. Every operation initiated from the device has to have, you know, fresh data, real-time data about the state of the device. Obviously, simple integration with the systems that exist.

There's a more holistic view about being able to integrate kind of this whole context, right, because you're going to have high trust devices and low trust devices, and low trust devices, you know, you're going to go ask for a limited set of information because you're never going to give them access to anything other than low trust apps, but for high trust devices, you may want a full-spectrum view with information from the EDR that's running with information from the MDM policy that's in place.

So those are some of the things that we definitely may be accelerated for some of Mario's use cases.

Garrett

Does Beyond Identity replace your MDM?

Jasson

So it depends on what you're using your MDM for, but we're not going to modify the state of a device, right? So when you're using your MDM to push configuration and manage configuration state of a service or a machine, we're certainly not going to replace that. And in fact, in those situations, we can integrate with those MDMs to kind of help you build that full-spectrum picture of what's going on.

But if you're just using MDM to establish a level of device awareness as part of your authentication and authorization strategy, then we can certainly give you a similar set of data that's fresh in response to every access request.

Mario

Yeah. I think where that comes in handy is when you're bringing your own devices, you have employees...I mean, you get into this whole, you know, I know we want to make our employees productive. Correct, absolutely, 100%. And especially working remotely, people want to use maybe their phones again. But you run into this whole privacy issue.

If you start being very...if you're modifying somebody's personal devices, it gets a little bit challenging legally. So better, and what I like about Beyond Identity is that they give you at least a picture of what the device looks like, right?

Is it using passwords, easy passwords? Is it using biometrics or not? Is it encrypted or not? Is it being [inaudible], rooted, etc.? It gives you a picture to then take an action and then maybe say, "Well, you know, Employee X, you're not going to use your phone under those conditions."

Garrett

What do you think about the use of VPNs to address secure access? I got some opinions there, but I'll see if either of you guys want to start out.

Mario

I'm not ready to give up on VPNs yet, right? I don't know if I'm comfortable saying I'm willing to do that. I think there's a place for VPNs still in this world.

But too much of those VPNs, and you know, for many years, VPNs have been enforcing insecure authentication. In other words, not only do I trust that VPN server or device, but is that endpoint trusted by the organization as well?

And so that's always been very useful, but it just falls apart when you're able to grab that certificate on that laptop or endpoint and put it on some other machine. And so I think that's where things kind of fall with VPN is that false sense of security. I think VPNs armed with a smart, you know, product, and the likes of Beyond Identity will make those VPN investments better and more useful maybe in the next five, you know, three, four years.

Garrett

You know, interesting because a lot of our data shows that, over the last year, so obviously, there's a big jump in VPN usage just to get everyone working remote, you know, initially, due to COVID, but we're also showing a big increase in things like ZTNA, zero trust network access, which seems to be synonymous with software-defined perimeter or SDP, which is essentially an alternative to VPNs.

And one of the common issues I've heard with respect to VPNs is, you know, they're expensive and you often need a fat client, and you don't necessarily want to roll it out to your entire workforce. But I also get what you're saying, that there's definitely a role in this world for VPNs. So maybe VPNs will become one of several methods of remote access. Maybe ZTNA will open up new use cases and new user groups for remote access, all of which, I think, you know, call for increased need for doing some form of stronger authentication or passwordless.

I don't know if Jasson had anything to weigh in there or not.

Jasson

I would say a VPN is a tool, and it gets used for a lot of different use cases. And you know, the original use case of VPN was created from was to provide a bridge from my host or one network to another network. And it does that job really, really well. 

When you start using a VPN to try and assert device trust, when you start using a VPN for really kind of some of these other health checks and whatnot to protect the applications that are fundamentally protected in a very different way that aren't inside of Amazon or aren't inside of Google or Azure, you're sending your traffic in kind of a spaghetti of tunnels adding latency, complexity, and cost, and transit fees for really a question that you could answer a lot simpler with footprint on the device tied into your identity system.

Mario

And I think some of the signals for when VPNs are going to be less important is, you know, as you start automating, your CI/CD, so you never, never SSH your terminal into one of your cloud environments to your protective environment. Once people never have that terminal access, I think once that starts happening, I can start seeing the usefulness of VPNs just not being...as data utility not been so useful.

Garrett

Yeah. So just maybe one final thought to point on that. We put out some survey data recently where we asked enterprises, "What are the most deployed security tools?" Not surprisingly, I might have mentioned earlier things like firewalls and email security, what have you. But when we asked, "What are you most likely to deploy in the next six to 12 months, six to 24 months," number one was zero trust, right, zero trust or zero trust network access.

So clearly, there's a lot of interest in zero trust going forward. So with that, I think we're out of questions and we're out of time. So on behalf of 451 Research and S&P Global, I want to thank Mario for joining us and for a lively discussion. And thanks, Jasson, and thanks, everyone, for joining us.

‍