Screaming in the Cloud - Third Wave Security with Alex Marshall of Twingate

Episode Date: September 1, 2022

About AlexAlex is the Chief Product Officer of Twingate, which he cofounded in 2019. Alex has held a range of product leadership roles in the enterprise software market over the last 16 years, including at Dropbox, where he was the first enterprise hire in the company's transformation from consumer to enterprise business. A focus of his product career has been using the power of design thinking to make technically complex products intuitive and easy to use. Alex graduated from Stanford University with a degree in Electrical Engineering.Links Referenced:twingate.com: https://twingate.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run.

They believe, as do I, that DevOps and security are inextricably linked. If you want to learn more about how they view this, check out their blog. It's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit sysdig.com and tell them that I sent you. That's S-Y-S-D-I-G.com. And my thanks to them for their continued support of this ridiculous nonsense. This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally.

Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other. Which one is up to you? Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business, production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaming in the cloud. Observability, it's more than just hipster monitoring. Welcome to Screaming in the Cloud. I'm Corey Quinn.

This promoted episode is brought to us by our friends at TwinGate. And in addition to bringing you this episode, they also brought me a guest. Alex Marshall is the Chief Product Officer at TwinGate. Alex, thank you for joining me. And what is a TwinGate? Yeah, well, thanks. It's great to be here. What is a TwinGate. Alex, thank you for joining me. And what is a TwinGate? Yeah, well, thanks. It's great to be here. What is a TwinGate? Well, the way to think about TwinGate is we're really a network overlay layer. And so the experience you have when you're running TwinGate as a user is that network resources or network destinations that wouldn't otherwise be accessible to you

are magically accessible to you and you're properly authenticated and authorized to access them. When you say it's a network overlay, what I tend to hear, and the context I usually see that in, in the real world, is, well, we're running some things in AWS and some things in Google Cloud, and I don't know, because of a sudden sharp blow to the head, maybe Azure as well. And how do you get all of the various security network models of security groups on one side to talk to their equivalent on the other side. And the correct answer is generally that you don't, and you use something else that more or less makes the rest of that irrelevant. Is that the direction you're coming at this from, or do you view it differently? Yeah, so I think the way that we view this in terms of like what, why we decided to build the product in the first place is that if you look at sort of like the

internet in 2022, like there's one thing that's missing from the network routing table, which is authentication and authorization on each row. And so the way that we designed the product is we said, okay, we're not going to worry about everything basically above the network layer. And we're going to focus on making sure that what we're controlling with the client is looking at outbound network connections and making sure that when someone accesses something and only when they access it, that we check to make sure that they're allowed access. We're basically holding those network connections until someone's proven that they're allowed to access it, then we let it go. And so from the standpoint of like figuring out

like security groups and all that kind of stuff, we're basically saying like, if you're allowed to access the database in AWS or your home assistant on your home network, fine, we'll let you do that, but we'll only let you go there once you've proven you're allowed to. And then once you're there, then we'll let you figure out how you want to authenticate into the destination system. So our view is like, let's start the network layer, and then that solves a lot of problems. When I call this a VPN, I know a couple of things are going to be true. One, you're almost certainly going to correct me on that, because this is all about zero trust. This is the year of our Lord 2022, after all. But also when I round to what basically becomes a VPN to my mind, there are usually two

implementations or implementation patterns that I think about. One of them is the idea of client access, where I have a laptop, I'm in a Starbucks, I want to connect to a thing, and the other is historically been considered as site-to-site, or, oh, I have a data center that I want to have constantly connected to my cloud environment. Which side of that mental model do you tend to fall on, or is that the wrong way to frame it? The way we look at it, and sort of the vision that we have for what the product should be, the problem that we should be solving for customers, is what we want to solve for customers

is that TwinGate is a product that lets you be certain that your employees can work securely from anywhere. And so you need a little bit of a different model to do that. And the two examples you gave are actually both entirely valid, especially given the fact that people just work from everywhere now. Resources everywhere, they use a lot of different devices, just work from everywhere now, like resources everywhere. They use a lot of different devices. People work for lots of different networks.

And so it's a really hard problem to solve. And so the way that we look at it is that you really want to be running something or have a system in place that's always taking into account the context that user's in. So in your example, if someone's at a Starbucks, you know, on the public Wi-Fi, last time I checked, Starbucks Wi-Fi was unencrypted, so it's pretty bad for security. So what we should do is we should take that context into account and then make sure that all that traffic is encrypted. But at the same time, you might be in the corporate office, network is perfectly safe, but you still want to make sure that you're authorizing people at the point in time they

try to access something to make sure that they actually are entitled to access that database in the AWS network. And so we're trying to get people away from thinking about this point-to-point connection with the VPN, where the usual experience we've all had as employees is, great, now I need to fire up the VPN, my internet traffic is going to be horrible, my battery is probably going to die. Pull out the manual token that rotates with an RSA token that spits out a different digital code every 30 seconds if the battery hasn't died or they haven't gotten their seeds leaked again. And then log in and the rest and some horrible implementations type that code after your password

for some godforsaken reason. Yeah, we've all been down that path. And it's like, yeah, sign into the corporate VPN. It's like, did you just tell me to go screw myself? Because that's what I heard. Exactly. And that is exactly the situation that we're in. And the fact is, VPNs were invented a long time ago, and they were designed to connect two networks. They're designed to connect a branch office to a corporate office, and they're just to join all the devices on that network. So everybody that's had this experience with VPN is suffering from the fact that it's the wrong tool for the job. Going back to this idea of us being the network overlay, we don't want

to touch any traffic that isn't intended to go to something that the company or that the organization or the team wants to protect. And so we're only going to gate traffic that goes to those network destinations that you actually want to protect. And then we're going to make sure that when that happens, it's painless. So for example, I don't know, again, use your example. You've been to Starbucks, you've been working on your email, you don't really need access to anything that's private. And all of a sudden, you need to, as part of your work that you're doing on the Starbucks Wi-Fi, is access something that's in AWS. Well, then the moment you do that, then maybe you're actually fine to access it.

Because you've been authenticated, and you're within the window, it's just going to work. So you don't have to go through this painful process of firing the VPN like you're just talking about. There are a number of companies out there that first self-describe as being, oh, we do zero trust. And when I hear that, what I immediately hear in my own mind is I have something to sell you, which fair enough. We live in an industry. We're trying to have a society here. I get it. The next part that I wind up getting confused by then is it seems like one of those deeply overloaded terms that exists to more or less, in some cases, to be very direct. Well, we've been selling this thing for 15 years and that's the buzzword. So now we're going to describe it as the thing we do with a fresh coat of paint on it. Other times it seems to be something radically different. And on some level, I feel like I could wind up building an entire security suite out of nothing other than

things self-billing themselves as Zero Trust. What is it that makes TwinGate different compared to a wide variety of other offerings ranging from SIEM to whatever the hell an XDR might be to, apparently, according to RSA, a breakfast cereal. So you're right. Like zero trust is this completely like overused word. And so what's different about TwinGate is that really, I think goes back to like why we started the company in the first place, which is that we started looking at the remote workspace. And this is, of course, before the pandemic, before everybody was actually working remotely and it became a really urgent problem. During the pandemic, of course, a lot remotely, and it became a really urgent problem.

During the pandemic, of course, a lot of the traditional VPN companies are, huh, why is the VPN concentrator glowing white in the rack and melting? And it sounds like screaming, what's going on? Yeah, it turns out capacity provisioning and bottlenecking of an entire company tends to be a thing at scale. And so you're right, like that is exactly the conversation we've had a bunch of customers over the last couple of years that like their VPN game is just blowing up because it used to be that 10% of the workforce used it on average, and all of a sudden, everybody had to use it. What's different about our approach in terms of what we observed when we

started the company is that what we noticed is that this term Zero Trust is kind of flowing out there, but the only company that actually implemented Zero Trust was Google. flowing out there, but the only company that actually implemented Zero Trust was Google. So if you think about the situations that you look at, Zero Trust is obvious. It's what you would want to do if you redesigned the internet, which is you'd want to say every network connection has to be authorized every single time it's made. But the internet isn't actually designed that way. It's designed default open instead of default closed. And so we looked at industry and we're like, great, Google's done done it. Google has like tons and tons of resources. So why hasn't anyone

else done it? And the example that I like to talk about when we talk about the inception of the business is that we went to some products that are out there that were implementing the right technological approach. And one of these products is still in use today, believe it or not. But I went to the documentation page and I hit print and it was almost 50 pages of documentation to implement it. And so when you look at that, you're like, okay, like maybe there's a, there's a usability problem here. And so, so what we really, really focus on is how do we make this product as easy as possible to deploy? And that gets into like this area of like change management. And so if you're in IT

or DevOps or engineering or security, and you're listening to this, I'm sure you've been through this process where it's taken months to deploy something because it was just really technically difficult and because you had to change user behavior. So the thing that we focus on is making sure that you didn't have to change user behavior. Every time you expect people to start doing things completely differently, congratulations, you've already lost before you started. Yes, exactly. And so the difference with our product is that you can switch off the VPN one day, have people install the TwinGate client, and then tomorrow they still access things with exactly the same addresses they used before.

And this seems like such a minor point, but the fact that I don't have to rewrite scripts, I don't have to change my SSH proxy configuration, I don't have to do anything, all of those private DNS addresses or those private IP addresses, they'll still work because of the way that our client works on the device. So what you're saying is fundamentally, you can even do a slow rollout. It doesn't need to be a knife switch cut over at two in the morning where you're scrambling around and, oh my god, we forgot the entire accounting department. Yep, that's exactly right. And that is an attraction of deploying this, is that you can actually deploy a department by department and not have to change our infrastructure at the same time. So again, it's a pretty fundamental point here. It's like, if you're

going to get adoption of technology, it's not just about how cool the technology is under the hood and how advanced it is. It's actually thinking about, from a customer and a business standpoint, how much is actually going to cost time-wise and effort-wise to move over to the new solution. So we've really, really focused on that. Yeah, that is generally one of those things that seems to be the hardest approach. I mean, let's back up a little bit here because I will challenge lightly something that you said a few minutes ago,

which is that Google was the first and only company for a little while doing zero trust. Back in 2012, it turned out that we weren't calling it that then, but that is fundamentally what I built out at the 10-person startup that I was at, where I was the first ops hire, which generally comes in right around Series B, when developers realize, okay, we can no longer lie to ourselves that we know what we're doing on an op side. Everything's on fire and no one can sleep through the night. Help, help, help, which is fine.

I've never had tolerance or patience for ops people who insult people in those situations. It's, well, they got far enough along to hire you, didn't they? So maybe show some respect. But one of the things that I did was being on the corporate network got you access to the printer in the corner, and that was it. There was no special treatment of that network. And I didn't think much of it at the time, but I got some very strange looks and had some, we'll call it interesting, a decade later, most of the pain has faded, discussions with our auditor when we were going through some PCI work, and they showed up and said, great,

okay, what are the credentials for your directory? My response was, our what now? That's when I realized there's a certain point of scale. Back when I started as an independent consultant, everything I did for single sign-on, for example, was my one password vault. Easy enough. Now that we've scaled up beyond that, I'm starting to see the value of things like single sign-on in a way that I never did before. And in hindsight, yeah, I'd like to go back and do things very differently as a result. Scale matters. What is the point of scale that you find is your sweet spot? Is it one person trying to connect to a whole bunch of nonsense?

Is it small to mid-sized companies? And we should probably bound that, because to me, a big company is still one that has 200 people there. You raise an interesting point, which is that, yeah, kudos to you for like implementing that like back then, because we've had problems. That was just being lazy. It was what was there. It's like, why do I want to maintain a server in

the closet? Honestly, I'm not sure that the office is that secure, and all it's going to do, what am I going to put on that? A SharePoint server? Please, we're using Macs. Yeah, exactly. Yeah, so we've had, I don't know, at this point, thousands of customer conversations. The number of people that have actually gone down that route, implementing things themselves, is a very small number. And I think that just shows how hard it is. So again, kudos. And I think the scale point is, I think, really critical. So I think it's changed over time. But actually, the point at which a customer gets a scale where I think a solution like this has leveraged high value is when you get to maybe only 50, 75 people, which is a pretty small business. And the reason is that that's the point at which a bunch of tools start

getting implemented at a company, right? When you're five people, you're not going to install like an MDM or something on people's devices, right? When you get to 50, 75, 100, you start hiring your first IT team members. That's the point where them being able to like centralize management of things inside the company becomes really critical. And so one of the other aspects that makes us a little bit different in terms of approach is that what we see is that there's a huge number of tools how to manage, and they have different configuration settings. You can't even get consistency on MDMs across different platforms necessarily.

Linux, Windows, Mac are all going to have slight differences. And so what we've been working the platform towards is actually being the centralization point where we integrate with these different systems and then pull together like a consistent way to create those authentication authorization policies i was talking about before and the last thing on sso just to sort of reiterate that i think that that you're talking about you're seeing the value of that the other thing that we've like made a deliberate decision on is that we're not going to try to like re-solve like a bunch of these problems. So one of the things that we do on the user authentication

point is that we rely on there being an SSO user directory that handles authentication, that handles creating user groups, and we want to reuse that when people are using TwinGate to control access to network destinations. So for us, it's actually that point of scale comes fairly early. It only gets harder from there. control access to network destinations. So for us, like it's actually, you know, that point of scale comes fairly early. It only gets harder from there. And it's especially when that IT team is like a relatively small number of people compared to number of employees where it becomes really critical to be able to leverage all the technology that they have to deploy. I guess this might be one of those areas where I'm not deep enough in your space to really see it the same way that

you do, which is the whole reason I have people like you on the show, so I can ask these questions directly. What is the painful position that I find myself in that I should say, ah, I should bring TwinGate in to solve this obnoxious, painful problem so I never have to think about it again? What is that that you solve? Yeah, I mean, I think for what our customers tell us, it's providing a consistent way to get access into a wide variety of internal resources and generally in multi-cloud environments.

That's where it gets really tricky. And the consistency is really important because you're trying to provide access to your team, often like it's DevOps teams, but all kinds of people need access to these things. Trying to provide access into multiple different environments. Again, there's that consistency problem

where there are multiple different ways to provide that, and there isn't a single place to manage all that. And so it gets really challenging to understand who has access to what, make sure that credentials expire when they're supposed to expire, make sure that all the routing inside those remote destinations is set up correctly, and it just becomes like a real hassle to manage those things. So that's the big one. And usually where people are coming from is that they've been using VPNs to do that because they

don't know that anything better exists, or they haven't found anything that's easy enough to deploy, right? So that's really the problem that they're running into. There's also a lot of tribal knowledge that gets passed down. The oral tradition of, I have this problem. What should I do? I know I will consult the wise old sage. Well, where can you find the wise old sage? Under the rack of servers swearing at them.

Great. Cool. Well, use a VPN. That's what we've used since time immemorial. And then the sins are visited onto yet another generation. There's a sense that I have that companies that are started now are going to have a radically different security posture and a different way of thinking about these things than the quote-unquote legacy companies. Legacy, of course, being that condescending engineering term for it makes money, who are migrating their way into a brave new world because they had the temerity to found themselves as companies before 2012. Absolutely. When we're working with customers, there is a sort of a sweet spot,

both in terms of like the sort of size and role they were talking about before, but also just in terms of like where they are and sort of like the sort of life cycle of their company. And I think one of the most exciting things for us is that we get to work with companies that are figuring this stuff out for the first time, and they're taking a fresh look at what the capabilities are out there in the landscape. That's what makes this whole space super, super interesting. There's some really, really fantastic things you can do. I'll just give you an example that I think might resonate with your audience quite a bit. It's this whole topic of automation. You're talking about the tribal knowledge of like, oh, of course,

we set up a VPN and so on. One of the things that I don't think is necessarily obvious in this space is that for the teams at companies that are deploying, configuring, managing internal network infrastructure, is that in the past, you've had to make compromises with that infrastructure in order to accommodate access. Because it's kind of a pain to deploy much like VPN gateways, mostly for the end user, because they've got to choose which one they're connecting to. You potentially had to open up traffic routes to accommodate the VPN gateway that you wouldn't otherwise want to open up.

And so one of the things that's really fascinating about a new way of looking at things is that what we allow with TwinGate, and part of this is because we've really made sure that the products like API first in the very beginning, which allows us to very easily integrate and with things like Terraform or Pulumi for deployment automation, is that now you have a new way of looking at things, which is that you can build a network infrastructure that you want with the data flow rules that you want, and very easily provide access into points of that infrastructure, whether that's an entire subnet

or just a single host somewhere. I think these are the ways the capabilities of people don't realize are possible until they understand some of these new technologies. This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now, EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years,

and now Enterprise DB has you covered wherever you deploy PostgreSQL, on-premises, private cloud, and they just announced a fully managed service on AWS and Azure called Big Animal. All one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money. They can even help you migrate legacy applications, including Oracle, to the cloud. To learn more, try Big Animal for free.

Go to biganimal.com slash snark and tell them Corey sent you. This feels like one of those technologies where the place that a customer starts from and where they wind up going are very far apart. Because I can see the metaphorical camel's nose under the tent flap being, ah, this is a VPN, except it doesn't suck. Great. But once you wind up with effectively an overlay network connecting all the things that you care about within an organization, it feels like that unlocks a whole universe of possibility. Yeah, definitely. I mean, I think you hit the nail on the head there. A lot of people approach this because they're having a lot of pain at VPN and all the operational

difficulties that we were talking about earlier. But I think what sort of starts to open up is there's some sort of like not obvious things that happen. And one of them is that all of a sudden, when you can limit access at a network connection level, you start to think about like credentials and access management a little differently, right? So one of the problems that well known is people set a bastion host, and they set a bastion host so that there's like a limited way into network. And all the, you know, keys are stored by bastion host, they said bastion host so that there's like a limited way into network and all that you know keys are stored by bastion host so on so you basically have a system where fine we have a bastion host set up because a we want limited ingress and b we want to make sure that we know exactly has access to our internal resources you can do away with that and with a simple configuration change you can can basically say, even if this employee,

for whatever reason, we've forgotten to remove or revoke their SSH keys, and they still have those keys, they can't access the destination, because we're blocking network access at their actual device, then you have a very different way to restrict access. So it's still important to manage credentials, but you now have a way to actually block things at a network level. And I think it's like when people start to realize that these capabilities are possible, that they definitely start thinking about things a little bit differently. VPNs just don't allow this level of granularity. I am a firm believer in the idea that any product with any kind of longevity gets an awful lot of

its use case and product market fit, not from the people building it, but from the things that those folks learn from their customers. What have you learned from customers rolling out TwinGate that reshaped how you thought about the space or surprised you as far as use cases go? Yeah, so I think it's a really interesting question because one of the benefits of having a small business and being early on is that you have very close relationships with all your customers and they're really passionate about your product. And what that leads to is just a lot of knowledge sharing around how they're using their product,

which then helps inform the types of things that we build. So one of the things that we've done internally to help us learn, but then also help us respond more quickly to customers is we have this group called TwinGate Labs. And it's really just a group of folks that are outside the engineering org. They're just allowed to build whatever they want

to try to prove out interesting concepts. And a lot of those, I'd say a lot, honestly, probably all of those concepts have come from our customers. And so we've been able to push the boundaries on that. And so just to give you an example, I mean, AWS can be sometimes a challenging product to manage and interact with.

And so that team has, for example, built some capabilities, again, using just the regular TwinGate API to show that it's possible to automatically configure resources in AWS based on tags. Now, that's not something that's in our product, but it's us showing our customers

that we can respond quickly to them and then actually try to accommodate some of these special use cases they have. And if that works out, then great, we'll pull it into the product. So I think that's the nice thing about being a smaller business is that you get a lot of that back and forth with your customers. And they help us generate ideas too. One thing that stands out to me from the testimonials from customers you have on your website has been a recurring theme that crops up.

That speaks to, I guess, once I spend more than 10 seconds thinking about it, one of the most obvious reasons that I would say, oh, TwinGate, that sounds great for somebody else. We're never rolling it out here. And that is the ease of adoption into environments that are not Greenfield. Because I don't believe that something like this product will ever get deployed to something Greenfield. Because this is exactly the kind of problem that you don't realize exists and don't have to solve for until it's too late because you already have that painful problem.

It's an early optimization until suddenly it's something you should have done six months ago. What is the rolling it out process for a company that presumably already is built out, has hired a bunch of people, and they already have something that quote unquote works for granting access to things? Yeah, so the beauty is that you can really deploy this side-by-side with an existing solution. So whatever that happens to be, I mean, whether it's a VPN or something else, is you can put this side-by-side. And the deployment process, just to talk a little bit about the architecture, we've talked a lot about this client that runs on the user's device. But on the remote network side, just to be really clear on this,

there's a component called a connector that gets deployed inside the remote network, and it does not have to be installed on every single destination host. You're sort of thinking about it sort of like this routing point inside that network, and that connector controls what traffic is allowed to go to internal locations based on the rules. So from a deployment standpoint, it's really just put a connector in place and put it in place in whatever subnet you want to provide access to. And so if you're unlikely, but if your entire company has one subnet, great, you're done with one connector. But it does mean you can sort of gradually roll it out as it goes. And the connector can be deployed in a bunch of different environments. So we're just talking about AWS, maybe it's inside of VPC,

but we have a lot of people that actually just want to control access to specific services inside a Kubernetes cluster. And so you can deploy it as a container right inside Kubernetes. And so you can be like really specific about how you do that and then gradually roll it out to teams as they need it. And without having to necessarily on that day actually shut off the old solution. So just your comment, by the way, on the Greenfield versus sort of like Brownfield, I think the Greenfield story I think is changing a little bit. I think especially to your comment earlier around younger companies i think younger companies are realizing that this is this type of capability is an option and that they want to get

in earlier but the reality is that you know 98 of people are really in the in the established network situation and so that's where that that rollout process is really important as you take a look throughout what you're seeing customers doing, what you see the industry doing as a result of that, because customers are, in fact, the industry. Let's be clear here. What do you think is, I guess, the next wave of security offerings? I guess what I'm trying to do here is read the tea leaves and predict what buzzwords will be all over the place at next RSA. But on a slightly more serious note, what do you see this is building towards? What are the trends that you're identifying in the space?

There's a couple things that we see. So one sort of way to look at this is that we're sort of in this third wave. And I think these things change more slowly than all due respect to marketers and the marketers would have you believe. And so if we think about where we are, there's like wave one is like good old happy days. We're all in the office. Like your computer can't move. Like all the data is in the office. Like everything is in one place. Right. What if someone steals your desktop? Well, they're probably going to give themselves a hernia because that thing's heavy. Yeah, exactly. And is it really worth stealing? Right. But the wave one is really like network security was actually just physical security to that point. That's all it was just

like physically secure the premises. Wave two, and arguably you could say we're kind of still in this is actually the transition to cloud. So let's convert all CapEx to OpEx. But that also introduces a different problem, which is that everything is off network. So you have to like figure out, you know, what you do about that. But Wave 3 is really, I think, and again, just to be clear, Wave 2, these are multi-decade things that happen. And I'd say we're in the middle of Wave 3. And I think that everyone is still gradually adapting to this,

which is what we describe it as people everywhere, applications are everywhere, people are using a whole bunch of different devices. There was no such thing as BYOD in the early 2000s, late 90s. And people are accessing things from all kinds of different networks. And this presents a really, really challenging problem. So I would argue to your question, I think we're still in the middle of that wave three, and it's going to take a long time to see that play through the industry. Just things change slowly. That tribal knowledge takes time to change. The other thing that I think we

very strongly believe in is that, and again, this is sort of like coming from our customers too, is that people basically with security industry have had a tough time trying things out and adopting them because a lot of vendors have put a lot of blockers in place of doing that. There's no public documentation. You can't just go use the product. You've got to talk to a salesperson who then filters you through. We have our fifth call with the sales team. We're hoping this is the one where they'll tell us how much it costs. Exactly. Or like, you know, now you get to the sales engineer, so you gradually adopt this knowledge. But ultimately, people just want to try the darn thing, right? So I think we're big

believers that I think hopefully what we'll see in the security industry is that we're trying to set an example here is really that there's an old way of doing things, but the new way of doing things is make the product available for people to use, document the heck out of it, explain all the different use cases that exist for how to be successful with your product, and then have the users actually then reach out to you when they want to have more in-depth conversation around things. So those are the two big things I'd say. I don't know if those are translated buzzwords at RSA, but those are two big trends we see.

I look forward to having you back in a year or two and seeing how close we get to the reality. Well, I guess we didn't see that acronym coming, but don't worry. We've been doing it for the last 15 years and under different names. So it works out. I really want to thank you for being as generous with your time as you have been. If people want to learn more, where should they go? Well, as we were just talking about, you can try the product at twingate.com.

So that's, that should be your first stop. And we will of course put links to that in the show notes. Thank you so much for being as forthcoming as you have been about all this stuff. I really appreciate your time. Yeah, thank you, Corey. Really appreciate it. Thanks. Alex Marshall, Chief Product Officer at TwinGate. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice,

along with a long, angry, ranty comment about what you hated about the episode, which will inevitably get lost when it fails to submit because your crappy VPN concentrator just dropped it on the floor. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

This has been a HumblePod production. Stay humble.