Protecting RDP with Zero Trust (EP 857)

Hello friends, Uncle Marv here with another episode of the IT Business Podcast, recording live from Pax8 Beyond in Denver. Day two is rolling on, we're here outside of the vendor hall, and I'm joined by one of the partners of the program, Peter with TruGrid is joining me at the table here, Peter welcome to the show. Thank you Marvin, I'm happy to be here.

Alright, so you guys, I tried to bring some people up to your booth, your booth has been packed, what's going on? Well, as you may know, we're launching on Pax8 Marketplace next week, we've been in pilot with them for the last two weeks, and we've been working on integration now for about three months, and so this is the culmination of it, and also we had a chance to provide a 30 second pitch yesterday, and I think that drove some people to our booth as well. Yeah, I heard that people, they were excited, confused, and amazed with your pitch, and we had to go figure out what was going on there. I'm glad you brought that up, I think what people don't realize, and what I try to deliver is the truth.

For example, RDP is actually a well-known, I would say one of the, one of the features of the Microsoft Windows operating system, right? Yes. It's actually the most widely used method for remotely connecting to Windows operating systems. It powers Microsoft AVD.

Microsoft has been singing the praise of AVD, everybody should come to the cloud, right? So RDP is the underpinning of AVD, Microsoft RDS, it's a feature of the Windows operating system, widely used across many organizations until today. It is actually the very first VDI solution, and the desktop operating system solution in the world. That's the Windows operating system.

But RDP really is the underpinning, and many people just don't realize, so I just had to remind them that. So one of the things, if you don't mind me asking, I'll do it real quick, is a few folks come to our booth on Sunday night, and one guy said, secure RDP is an oxymoron, right? The implication is that RDP is not secure. RDP is actually secure, right? Saying RDP is not secure, it's like saying your car is not secure if you leave it unlocked.

You chose to leave your car unlocked, so anybody can break into it. Well, RDP is a feature, you just have to protect it, and TruGrid really is the best at protecting Yeah, the bad rap that RDP has gotten over the years is not the fault of RDP, it's the fault of us leaving ports open on the firewall. I tell customers, it's like people drive by your house all day long, and as long as your door is closed and locked, no big deal.

But if they see your door open, lights on, or off, but if they see your door open, people are going to walk through, and that's what open RDP is. Closing 3389 is something that, I think the problem is people didn't know, well what do we do if we close the port, then we can't access it. Well, having a secure VPN, a reverse proxy, TruGrid is the solution, which that's what I've done with my clients, and I can't believe it took me so long to get on board with you guys.

You've been with us four years now, we're thankful for that. Oh, you looked it up. I had to.

In case Marvin asks me, I want to be ready to say it's been four years, February of 2021. So, I mean, the easiest explanation, secure RDP, it's a way to allow users to connect back into a network, whether it's a RDS server, their own workstation, or you guys now are setting it up to where if you're doing AVD in the cloud, virtual desktops, you can use TruGrid as the multi-factor VPN connection there. I didn't prep you for this, and we just kind of came up with this, but of course the buzz right now is all about SASE, ZTNA, and I don't want to say argued with people, but in my case, scenario with my clients, SASE and ZTNA are a little overkill, in my opinion.

That doesn't mean that they're not secure, but TruGrid has been something that has been easy to implement, easy for users to install the agent on their own, and once you set up syncing with Active Directory or Azure, you're good. Well, I'm glad you brought it up. You may not know this, but TruGrid actually uses SASE.

The foundation of TruGrid is SASE. We have this thing called Cloud Shield in Azure, but it's transparent to our customers, and that's the way technology should be. You shouldn't have to worry too much about the complexity behind it, right? Let us deal with that.

Let your users just come in, click, and run. So now I'll be honest with you, when we built TruGrid seven years ago, I didn't know what SASE was. I did not know, but the architecture that we came up with, because my background is in Citrix.

I'm a Citrix architect, and so in building TruGrid, myself as a co-founder and a CTO, we worked together to design a solution that was impenetrable and that didn't have any open firewall. And when we looked at all possibilities, what we came up with was a reverse process solution that would come to sort of like something in Azure that was the underpin of how people are going to connect. I mean, the end user will connect to that stuff in Azure transparently and will rather move off of optics.

We didn't know we were creating SASE. Ah, okay. Exactly.

So we did SASE before the time was coined. I think Gartner coined it right about, I don't know, 2020? I was going to say the year before COVID. Yeah, 2020, yeah.

We launched TruGrid in 2018. So we were doing SASE before they coined it. Okay.

We were doing ZTNA before it was coined ZTNA. We just architected it the best way we could find it and it turns out there's a name for it. Very nice.

You did have the phrase Zero Trust. Yes. Zero Trust.

From the beginning. Exactly. That was in there.

That was in there. And that's because almost every solution that's out there today, and if you don't mind, I'll say something very quickly about the origin of how we got here. Okay.

People are not wrong to think the right way to access IDP was open for 3389. Because if you remember, 20 years ago there weren't as many attacks as we have today. Right.

Right, okay. So things are just getting more dangerous. I was liking this to when there was a time in our lives in America where we didn't wear seatbelts.

Okay? True. Okay. We just drove around without seatbelts.

So when people started encouraging people to wear seatbelts, some of the reaction was, why? Oh, to prevent death. Well, I've been driving without a seatbelt forever. Why would I worry about wearing it now? Right.

Right? Until they made it a law only because of a rising incidence of death among teenagers that are drunk and that kind of stuff. Right? Okay. It's the same thing with technology here.

IDP has been widely used and exposed without any threat. So when you're telling people not to expose it today, they go, well, I've been doing it like this before. Why should I change it? It's getting more dangerous.

Same thing with VPN. Believe it or not, Marvin, when people came to our booth, I would always ask them, what are you doing today for remote access? Because I don't want to just start telling people about what you're doing. I want to know what you're doing, what your use case is.

How can I help you? Right? The predominant thing I heard were people running RDP or VPN. Yep. Or people using an RDS gateway.

Those are the two number one use cases I heard yesterday. And the danger with VPN is twofold. There are traditional VPNs and there are SaaS-based VPNs.

The difference, traditional VPNs have exposure on both sides. On the host side, on the firewall, or if you have a dedicated appliance for VPN, it is exposed over 443 to the internet. That's an attack surface.

Okay? That's a force. You have to prevent that, right? Right. On the client side, because people have to log into VPN client and log in, the VPN encapsulation exposes the entire network stack.

So if you're using BYOD, you have to be concerned about malware or that stuff that could be on that device. They will see the open... Well, yeah, they can just basically traverse the tunnel. You got it.

And get right to the network. Those are the dangers. So that's why traditional VPN is actually not good for an RDP, because any malware can see the port open and attack it as well.

Okay. Now, the SaaS VPN, I won't name names, but the newer companies that are doing SaaS-based VPN, they've solved the whole side of it. Meaning that now you don't have the exposure on the host side, but they haven't solved the client side of it, because it's still the same VPN encapsulation is what they're using.

So the threat of exposing BYOD device is still there. I've seen people say things like, oh, yeah, we have this endpoint EOP. It's like endpoint check.

It would check to make sure the BYOD device is secure. Because that's fine, too. But that's been reactive now, right? Because it's very hard to... Every system is different, and you're just doing more work instead of actually making sure the foundation is secure to begin with.

And that's where Triggered is different, right? On both ends of the spectrum, on the host side, Triggered has no exposure. On the end-user side, Triggered has no exposure. How do we do it? Triggered on the client side is not based on VPN encapsulation.

Not. Not. It is based on TLS version 1.2. Only the Triggered connector app can see our tunnel.

If you have malware, if you have any software on that operating system, they cannot see our tunnel. And that's why when it comes to RDP, Triggered is by far the best solution for securing and protecting RDP. Okay? So that has been an argument that I've been using with customers that, you know, look at Triggered, and they'll hear about those other solutions.

A couple of them are a little less money. And they're like, oh, well, why can't we do this? It's cheaper. And I'm like, well, it's not as secure.

And trying to explain to them, well, as long as I have MFA, it's secure. And it's like, not exactly. So I'm glad that you explained that.

I'm glad that, you know, other MSPs are starting to hear this because it is. It is. Not me.

A friend of mine called me to assist with a situation where they were doing VPN between branch offices and the main office. It was just basically a firewall VPN. And the workstation on the branch side got infected.

And they couldn't understand how all of a sudden files on the main server were being infected through the VPN. I've taken the position where I've got customers that are in branch offices. We don't do the VPN tunnel anymore.

We make them do Triggered. And what's funny is it's actually easier because now they use the same connection at the office as they do at the home, as they do on the road. And they get used to it, and they're fine.

It's transparently easy. Yeah. Yes.

Thank you. Thank you for that. What you just described there, so when we discussed that at the booth for some folks that came by, the good thing is I didn't get any argument from any of the MSPs.

They kind of knew the danger on the client side. For those who have gone SASE VPN, they know they've protected that, but they also know this is a gaping hole. So when we were explaining that to them, they said, well, I'm so glad I came by because I've always wondered how can I protect this? So many of them said they wouldn't allow BYOD because of that.

Now with us, they can support BYOD if they wish. Even those who are doing traditional VPN said the same thing. So what you brought up is very important.

See, the danger with people getting the VPN is because, again, it's been here for so long. So when something has been around for so long and it's worked well for you, it's very hard to just get rid of it even though the threat against it is increasing. So our job as technologists, MSPs, vendors that provide services to MSPs is to be proactive.

We don't need to wait until there's an attack against our client because I would suspect that most MSPs, one of the things that would cause them to lose sleep is the potential, the prospect that any of our customers can be attacked because it becomes a knock on them. Especially if they've told the client this is a better solution and the client refuses. It makes it even worse, right? But not knowing that it's a better way out there is also equally bad for the MSPs.

Let me ask one question and I don't know if you can answer now or if we have to table it and come back later. One of the features that the SASE products tout is being able to look at the connection so that if somebody is at home complaining that the internet's slow, they're choppy, they're getting disconnected, with that SASE client somebody can look at the traffic and say, oh, here's why. Yes.

That, as far as I know, doesn't exist with TruGrid. Not yet. So is it coming? It's coming.

Okay. Because we have two road maps. We have internally developed roadmaps and the one driven by you, our customers.

So what we do is when we get enough of a request, it bubbles up to the surface. Okay. So being able to, even though without technology you probably already know this, what we promise customers is as long as you have a decent ISP on either side, on the end user side, on the host side, we take care of the rest.

Unlike every other technology out there, when you leave your ISP, normal traditional VPN and SASE-based VPNs, you now use the public internet as your foundation, right? Right. So you're on your own. TruGrid is the only solution that we know of and we've looked, where we provide a fiber optic mesh between your end users and the host environment they're trying to connect to.

So as long as you have a decent ISP on the other side, we bridge you on a fiber optic mesh through the Microsoft Azure backbone. And that goes all over the world. So to answer your question, what you're saying for our listeners, our audience, is that Marvin is saying, look, Peter, sometimes when there's a problem, we just want to know where it's coming from.

Right. And it's incumbent on us to make that available to you. Yeah, because I'll be honest, I've had maybe two or three times where a user is complaining that, oh, you know, can you please check the office and see what's going on? And I'm like, look, I've got 30 other people working just fine, so it's nothing on our end.

It's got to be on your end. And, you know, they want to push back and say, oh, well, I can browse the internet, I can open it. I'm like, well, that's different.

But you have a point. If we can, since we have an app on the end user side and we have an agent on the other side, it would be nice to be able to train that traffic and find a path. It should come up.

Like a dashboard, maybe they'll have a green, yellow, red, something like that. And then if you say green, you know it's not us. If you say yellow, you can dig in and see more.

That would be perfect. Yes, thank you. All right.

I'm glad I submitted a feature request for you. Thank you. All right.

Well, Peter, again, thank you for stopping by, and I'm happy to see all the success you guys are having. Tell Brandon and Jennifer it was nice to hang out with them last night. I didn't need to see all the pictures of the pool.

Maybe it's true to you anyways. May I deliver one closing remark? Sure. For all of us out there, Marvin has been a great partner of ours.

He's been a client for the last four years. We also partner with his show. And for all of you out there, I want to encourage you, if you have any customer that has a remote into the office, onto any PC, any Windows machine, on any network, but are using RDS, if you have any form of exposure on your firewall, we want you to give us a look because of the way we protect RDP from end to end.

And I may announce that by the end of this year, we're coming out with a private access solution, meaning that, yes, the same technology that we used to develop RDP, you'll now be able to deliver any protocol, HTTP, HTTPS, SSH, FTP, whatever it is, it's a TCP protocol. You'll be able to protect it with zero exposure, not just RDP. Interesting. 

All right. We'll be looking forward to that. And when that's announced, I'm going to be looking for you guys to get you back on here and explain it more for us.

All right? Thank you very much. All right, Peter, thank you much. And, again, tell Brandon and Jennifer hello for me.

And we'll be chatting with you soon. Thank you. All right. 

That's going to do it, folks. Thank you. And we'll be back with more from PAX 8 Beyond.

See you soon. Holla