CyberCast: Secure Remote Access for Administrators

Katy Martin (00:00:13):

Hello, everybody on behalf of Centrify, I'd like to introduce our speakers for today's cyber cast. We have Brad Shewmake, the director of corporate communications at Centrify. Tony Golding. He is our senior director at Centrify products marketing. I'm going to go ahead and pass that on over to Brad and Tony.

Brad Shewmake (00:01:33):

All right. Thank you, Katie. And thanks everyone for joining on a Monday morning. Welcome to Centrify's first Cybercast live.

Brad Shewmake (00:02:27):

The global pandemics changed our way of life in ways that nobody really could have expected. Most organizations have prioritized secure mode access for all of their employees and, rightfully so. But for hackers it's really just another day at the office. In fact, a lot of them are probably more emboldened than ever to be trying to get into networks, to be trying to exploit weak users, to be trying to gain privilege access. So, in fact, we released a poll in the UK last week that revealed that 71% of UK businesses believe the shift that completely remote workforces has actually increased their likelihood of experiencing a cyber breach. So, we're going to take our first poll of the day.

Brad Shewmake (00:03:27):

And the poll question is, “Do you believe the move to a hundred percent remote workforce has increased your organization's likelihood of a breach?” and while you're all taking poll, you should know that the survey we did in the UK also revealed that 53% of its business decision makers believe that privilege it administrative remote access is at risk of a security breach now more than ever.

Brad Shewmake (00:04:16):

I see about 83% believe that the move has increased the likelihood of experiencing a data breach with about 15 - 16% saying no.

Brad Shewmake (00:05:24):

Wow. That's even more people than we saw in the UK poll. So, obviously this is a hot issue. Depending where you are in the world, even four to eight weeks after being in a situation where you have a fully remote workforce, people are still dealing with this. They're still battling with it and trying to figure out the best approach secure access for all people, certainly for administrators. And that's what we're here to talk about today. We want to help be a resource to you for reducing the risk of a breach during the, the new now, if you will. Administrators tend to be, there'll be included obviously as part of those regular employees, but a lot of times they can be the kind of forgotten loophole if you will.

Brad Shewmake (00:06:22):

And this is especially true when you talk about third parties, outsourced IT, managed service providers and, some other people who may not even fall into the employee category, that often have access to critical infrastructure and sensitive data. But let's take a step back. So, you know, we want this to be interactive and we can see a lot of activity happening in the Q and A. So thank you. Keep that going, but really quickly, Tony, what kind of business challenges are we hearing about from customers there's about securing remote access for administrators.

Tony Goulding: (00:07:13):

So, this represents some of the main issues that our customers are trying to battle with. This is feedback that we've got fairly recently as well, over the last sort of 12 to 24 months, but these are the main issues that our customers are trying to do battle with. We're not going to go through each of these one by one at this point in time, we're going to revisit this at the end and see how these were addressed in the conversation and during the demo, et cetera. So during this session, we'll talk about the ways that we solve them and how we talk to our customers about solving these problems. And as I said, we'll come back to this slide as we progress.

Brad Shewmake (00:07:58):

Okay, great. Tony, thanks for the communicating, some of the challenges that we're hearing about from our customers. So, at a high level, what's the problem that we are trying to solve for them? A lot of our conversations are very specific. It's about getting legitimate users access to resources. So I want to focus on two words in that phrase, which is resources and legitimate. And what do we mean by that? Because it's very specific. So, when we talk about resources, we mean the windows boxes, the Linux boxes, the UNIX systems as network devices

Tony Goulding (00:08:56):

That is in their infrastructure to run the business. And these could be in lots of different places. So they could be in a private data center. They may be in the DMZ. So, for example, a lot of people have servers in the DMZ running a web service, for example, they may be in the cloud, or there may be a combination of all of that. Something we often refer to as that as a hybrid IT infrastructure, but they may also be in different cloud providers. So a lot of our customers are not just focusing on a single cloud provider like AWS they're actually, they don't want to put all of their eggs in a single basket and maybe because of business reasons that they go in multiple directions, but now they're putting workloads, they're standing up workloads in AWS, in Azure and Google cloud, et cetera.

Tony Goulding (00:09:47):

Uh, and that's something that you're going to hear a lot more about, certainly from the analyst community, they refer to this as multi-cloud. So, you know, this kind of exacerbates the problem, but that's what we mean by resources in that sentence now by legitimate users, what we mean there is the people whose job function it is to touch those resources, to keep them healthy, to keep them running and to protect them. And so, we're talking internal it, we're also talking about a lot of organizations outsourced IT and maybe even third-party contractors. And just like the resources may be in a lot of different places. Now, these, these users, maybe in a lot of different places, they still may find users in the office, on the land itself, but clearly in today's climate that the pendulum has swung very much to the other side. And so the vast majority of it, administrators, whether they're internal or outsourced then are remote. So secure remote access is all about getting those legitimate users’ access to that infrastructure, wherever it may be, wherever they may be, as well as keeping the attackers out.

Brad Shewmake (00:11:09):

Yeah. Yeah, exactly. So, I think that's a good way to, at a very basic level, that's a very good way to look at it, right? So, it's all about the resources you need to manage. And then the users you need to make sure that are legitimate. They're the ones who are accessing the resources, right. There's an increase in the amount of nefarious activity that's out there trying to take advantage of the current environment. So, every organization has to ensure that they have secure remote access and they really should have already done this, but, you know, even if they have, they should really be revisiting their approach and the solutions they have available to make sure it's enough. So Tony, what should they be looking at? Let's get into some of the more, the more technical aspects of secure mode access for administrators,

Tony Goulding (00:12:43):

Right? So, you know, lots of ways of skinning this cat, obviously. So, for the purposes of trying to be as clear and kind of succinct as, as we can, from a security perspective, we can break this problem down into perhaps three different options for our customers, good, better and best. So, we'll kind of skin it like that.

Brad Shewmake (00:13:06):

Yeah. So, this makes me think of the PAM maturity model that Centrify has, and, maybe we can come back and touch on that later. Tell us about the three options. So we have good, better and best.

Tony Goulding (00:13:22):

Yes, exactly. Let me bring up this first slide, and we'll start talking about it. So, so basically, what we're talking about here is the first scenario, which is the good, the good scenario, and, you know, this is using a VPN. So, let's talk about that. Let's talk about the use of a VPN. There are pros to the VPN and there are drawbacks to the VPN.

Tony Goulding (00:14:17):

I guess some of the pros are that that most organizations who are looking for some kind of remote access mechanism, they've already got a VPN infrastructure in place. And so, you know, on the pro side, admins are familiar with, with VPNs, it's a known quantity it's already in place. And in terms of audience, it can accommodate anybody that's remote. So it could be internal it as well as outsourced it or third parties. So, it's kind of accessible from anywhere. I mean, it will provide people with a VPN client obviously, and a password, and technically speaking, they can get into the network. It is a secure connection. And with some of them you can enable MFA, some of the drawbacks though, from a secure remote access perspective is that your network attached. So for many organizations that we've spoken to, they've been very, very worried about the risk of exposing individuals that come in from the outside to the broader network.

Tony Goulding (00:15:16):

Obviously, they have less concerns if it's, quote, unquote, internal IT, but certainly in terms of outsourced service providers, they worry about putting them onto the network. So in the diagram here, you see on the right hand side of the resources that we have, which are prying to become available to the users on the left and the resource on the right, maybe on a, on a private network attends, there is zero X, but as soon as you VPN and then on the left, you're part of that 10 zeros or X network, you are network attached. Sometimes these MFA solutions, they can be complex to configure. They don't generally speaking provide a cost granular level of access control. So any access control is usually broad brushstrokes, it's kind of group level, uh, memberships. And, um, what else, I guess, MFA, if it, if it exists, it tends to be on or off.

Tony Goulding (00:16:13):

And we'll touch on that later when we talk about security and productivity, but always on MFA is never a brilliant thing. So, it does lead to frazzled users who don't like being challenged every five minutes for an MFA. But back to the fact that your network attached, as I said, there's a risk of exposing a user to the broader network. So, if somebody on the outside was phished, their VPN connection was taken over there on the broader network, and it gives them more room, more opportunity to move laterally throughout the broader network. It's also not a clean source. So a lot of our customers say it is overwhelmed as it is. But now with that, with VPN based, connectivity from the outside, they're having to try their best to make sure that the users' workstations or laptops are virus free.

Tony Goulding (00:17:03):

They're clean, it's a clean source. The last thing they want is for viruses to spread from the left to the right. And of course, if your network attached, there's always that risk. So there's a lot of it and help desk overhead with having to deploy software and solutions to try and avoid that scenario like Cisco NAC, antivirus, anti-malware making sure that the signatures are up to date, et cetera, et cetera, that can be heavy lifting for it on the right hand side. So those are some of the kind of pros and drawbacks of VPN bread. Yeah. Okay. I mean, I guess, you know, obviously I get how that's good, right. So, having a VPN is, is better than nothing, clearly,

Brad Shewmake (00:17:50):

I keep thinking back to the Target breach back in, what was it? 2013, 2014, you know, they had, they had legitimate credentials from, I think it was like a third party HVAC company. And, they really used those legit credentials over a VPN to just walk right in the door. Target, I know they had to pay some kind of a big fine, there was something like 60 or 70 million customers that were compromised, and it does reveal that, yes, having a VPN is good. It's better than nothing, but it certainly is not going to be the best way to make sure that you're securing remote access for your administrators no matter who they are. Tony, I don't know if you've had a chance to read the questions, but are there any of those that you want to address while we're taking a to stop, you're in real time?

Tony Goulding (00:18:47):

I haven't yet, but I will. Going back to what you said about the Target breach. It's interesting that you mentioned that because one of the things we've been saying for quite a while now is that hackers don't hack anymore. They don't hack in; they just walk in through the front door with a legitimate credential that they've fished.

Brad Shewmake (00:19:16):

Yeah. They don't, they don't hack in, they log in. Right. Just another day at the office for a hacker. One question you have here is, Tony, did you mean that having VPN is good and should be made use of, just, it should be a VPN managed by their own IT, or instead of the VPN managed by a third party?

Tony Goulding (00:19:38):

Yeah. I mean, it's all levels, it's all degrees of maturity and degrees of security and risk avoidance. In the diagram here, we've got the VPN, it serves its purpose. It provides a secure remote link into the internal network. You do have the ability to mitigate certain risks of being breached. But what we're getting to here in a kind of a good, better best scenario is that there are other options beyond just the plain VPN that can help you mitigate more risks in regard to secure remote access. I think that was a good segue into the next slide, which I will now put up on the screen. This is kind of a better approach. So you'll notice, and again, back to the, the person asking the question, we are still using a VPN.

Tony Goulding (00:20:30):

We're talking about incremental security, not kind of like, Hey, we're going to rip everything out and throw it away. This is a better approach. It is still leveraging the investment that you might've made in a VPN, but now we're introducing some Centrify components. In particular here, you see the little red cloud, that's the Centrify privileged access service also known as our vault. And what we're doing now is we're putting that in place so that we can have better control, better security and better operational efficiencies. So now we actually removed the link from the VPN to the network on the right. So you'll notice that the pathway goes VPN client to VPN server, and then up to this other component, which is called our gateway connector. In our architecture, which is like a hub and a spoke, the privileged access service there, the vault is a cloud based service.

Tony Goulding (00:21:31):

That's the hub. And we can have multiple of these gateway connectors that sit down where your resources app happens to live. So now what you do as a user on the left, you VPN into a controlled network where the only access to those resources on the right is that gateway connector acting as a kind of a jump host. And so that connector is a bridge, but it's the only bridge to the servers and the network devices that you see on the right. In other words, from the outside, you can't address those services directly, even on the inside, you can't address them directly. There's no direct path. For better security, you can configure your firewall to only allow the VPN users to access the gateway connector. Again, there's no direct access to the servers or the network devices.

Tony Goulding (00:22:24):

Now they can still on the left, they could still use their favorite client of choice. Whether they're using something like Microsoft, remote desktop, to get access to the windows servers in the network, or they may be using PuTTY or something like, on the Mac, they may be using terminal with SSH on the command line. Irrespective your users on the left can still use their favorite clients of choice in order to establish a connection with the resources on the right. But the difference is that once that connection traverses the VPN, it goes to our gateway connector. And that's the thing, the brokers, the access to the resources. And you'll notice in the cloud, they're there, we define the users, the resources that they're allowed to access and the roles. And so the users on the left are governed and constrained by those roles. Those Centrify roles say, you know, Tony is only allowed to log into so server a and C and F, but not be in D. And so, you've got much tighter control and you've got more granularity of what the users are allowed to do once they've traversed that VPN connection.

Brad Shewmake (00:23:46):

You’re still using a VPN; we've already covered that. That is definitely a good practice. But now basically we're just adding an additional layer of security with a gateway connector. And as Tony mentioned, that's part of Centrify's Privileged Access Service. We talked about that a little bit later. We’re going to go to another poll here, but before we do that, Tony, did you want to take a look and see if there's any questions in the Q and A? Would MFA, multi-factor authentication, would that remediate risk related to VPN phishing?

Tony Goulding (00:24:44):

It's all about lead security, MFA, not phishing per se. I mean, take that Target breach. That occurred irrespective of any PAM solution that was in place because somebody in the outsourced IT organization got phished. Maybe they received an email with a link in it and they clicked on the link. It took them to a rogue website and that website downloaded malware to their laptop. And then the hacker got command and control of the laptop and from their access to the VPN and they connected in, so PAM doesn't necessarily stop that. Privileged access management is meant to put more controls around the users, the use of the identities and the logins and whatever they're doing on a system. So MFA in this case could have prevented that attack from happening because if MFA was pushed in the face of that attacker, maybe at multiple places, and they were challenged for a second factor of authentication, the likelihood is that they would have been blocked because I doubt very much whether they would have phished that HVAC consultants credentials, as well as let's say, physically obtaining their phone.

Tony Goulding (00:26:05):

So sending a second factor of authentication to the phone, they wouldn't have been able to respond. So MFA is great in that respect. We're going to talk a little bit more about MFA as we go through this, but, but yeah, MFA is low hanging fruit. And if it's done in the right way, you can add that extra layer of identity assurance and risk mitigation without overburdening people. So the whole security at the expense of productivity thing has always been a challenge, but in today's MFA, you can do it in a way that doesn't impact the users in a significant fashion. So hopefully that helped answer that question.

Brad Shewmake (00:26:48):

Thanks. I'm going to consolidate a few questions down now. So one question was, “how and where is the gateway connector installed and is it a software or hardware deployment?

Tony Goulding (00:27:06):

I wasn't going to get into the architecture, but I can certainly talk a little bit about it iin lieu of maybe the next slide, which we will get to the best scenario. We were kind of lucky here at Centrify because we architected our solution literally five years ago. So, we're not a PAM solution. That's kind of 20 years old that was designed for on-premises in a single land, in a single tenant. We designed it as cloud native. And because of that, we really thought through what does a cloud native architecture require? And so we built a hub and spoke model. The SaaS service is the hub. That's where all of the brains are. That's kind of the vault, if you will. But we go beyond that. We have lots of capabilities built into there, such as a platform of capabilities, including an authentication provider, the conservative passwords and SAML and tokens and all these things to dev Ops.

Tony Goulding (00:28:08):

But that thing sits in the cloud and then these gateway connectors or lightweight windows services. So, so literally when you sign up for our service, you can go to the cloud, you can sign up, you'll get a SaaS based privileged access service tenant in the cloud in 20 minutes. And then you can, from the cloud, you can install on a windows server, a gateway connector. And the only thing that that gateway connector is, as I said, it's a lightweight windows service. It will reach back up to the cloud to enroll. We have a mutual trust. It's an [unintelligible] based trust model, so that we get a root of trust with our platform, so that both ends of mutually authenticated and trusted. And then that gateway connector establishes itself as that bridge between the users and the resources on the inside.

Tony Goulding (00:29:02):

So it provides that separation, that isolation between the two, which helps as I mentioned earlier, in terms of having a clean source, but it also has all those capabilities built in. It has a web server. It has an [unintelligible] that proxy so that we can authenticate against a LDAP. It can talk to ID, you can talk to Google cloud, if your users happen to be up there, it has an RDP proxy in it. It has Nessus H proxy in it. So it's very functional, but it's very, very lightweight. And because of that architecture, it allows us to scale that out. So I think that's a good segue. Let's see what if we got anything from the poll and then we'll segue to the best approach that kind of pulls all of that together.

Brad Shewmake (00:29:47):

But hopefully that kind of helped with the architecture. It's kind of a client server hub and spoke, infinite really, really scalable and, and, and definitely suited to a more distributed kind of hybrid approach to IT. As we mentioned earlier, where your resources may be anywhere, you may have resources in the DMZ, how do you allow administrators with an ID account on the inside of your network to log in with their ADA account to a web server that's in the DMZ without exposing ads?

Tony Goulding (00:30:53):
This gateway connector could sit there and it can talk to the cloud and allow the cloud to authenticate or the SaaS service to authenticate against ADA on the inside without exposing things. So it's a great architecture.

Tony Goulding (00:31:25):

A few people have asked about what the performance impact to the network is by adding the new layer of it, the gateway connectors performance impact. It's almost negligible because if you look at this… The SaaS service there is massively scalable because it is a native SaaS service.

Tony Goulding (00:32:26):

So it's designed to take advantage of the cloud economy. It's not a monolithic vault designed from premises. That's just been put up in a VM image and, and running in the cloud. It really is native cloud and leveraging the ability to scale elastically as the demands on it. So that's scalable in itself, this gateway connector, as I said, it is a lightweight windows service. It does have a UI, but it pretty much runs in the background. I'm trying to remember what the system parameters for that are. But I know in my own demo environments where I have this running, I've actually got a lot of other things running on there. And we do not, I don't believe in our recommendations that we insist on it being a dedicated box. I have other things running on there as well.

Tony Goulding (00:33:23):

I don't have numbers. We can probably get those. If whoever asked the question, we can respond to you and provide you with some criteria for what is a recommended sizing for that particular system. But the interesting thing is that because of this hub and spoke model, we've actually got customers who have deployed these gateway connectors on multiple servers. So, within the cloud service get a view of the connectors. There's a menu item that says, these are your connectors. And these connectors can be dedicated to different IP address ranges or different sets of systems on the right hand side. So, for example, we've got people who say, we'll have a gateway connector for our windows servers, we'll have a different one for our UNIX servers. Maybe we'll have one for our PCI servers, whatever. So you can scale those out and you can either, and you can put them on multiple systems, it's just hub and spoke. So they will scale to as many as you need. And if for some reason, one of them is not performing on a box. You increase the virtual RAM. These can run in the cloud as well, right? On virtual instances. So it is designed for scalability and they are pretty lightweight in that respect.

Tony Goulding (00:34:42):

This is  what we would consider to be the best scenario. So, you'll notice here that in this scenario, we're avoiding the VPN all together. So here we're using the full capabilities of the Centrify Privileged Access Service, so that we can further improve on the benefits of number two, right? So probably the major benefit of this of this scenario is that it completely keeps the users off the network. So one of the biggest challenges with a VPN based remote access scenario is that network attachment. We're putting them on the network. We're putting them on a jump host, which ultimately potentially gives them access to lots of servers that aren't physically on that network. So by not doing that, we, we get two main benefits. One is that we are a clean source.

Tony Goulding (00:35:39):

Because we're not network attached on the left, the left is not network attached to the right. We are truly isolating both, right? So the user's laptop or workstation, which it may not have much control over. Certainly, if it's internal IT, I guess there could be corporate issued and you could have corporates. I don't know clients on there that they're making sure that the signatures are up to date, et cetera, et cetera, et cetera. But when it comes to third parties and outsource, you have less control over that. You know, maybe you have a relationship, an agreement with them that's written that says, thou shalt do this, but there's no guarantee that they're going to do it. And so if you want to do it, then it has overhead. They're already busy enough. So now they have to manage VPN clients and servers and help desk has to deal with password changes, but it also has to deal with how do we make sure that the left hand side is up to policy?

Tony Goulding (00:36:36):

Maybe they have to deploy solutions like Cisco NAC to make sure that this thing is at policy, but it's all overhead in this scenario. You don't need any of that. You're not network attached. The other one is that, again, referring to the jump host VPN model is that you are being placed on another host. That's not necessarily your target with this system. The user on the left will log into the privileged access service portal. And based on the roles that they've been given, they will only have visibility to a list of servers that they are allowed to log into, okay. Based on their job function. So if I was a database admin, I would probably only see the servers in the list that have databases on them. If I was a PCI admin, I would probably only see the servers that have credit card related processing on them.

Tony Goulding (00:37:31):

And I could only potentially log in to those. So where, so first of all, we're constraining the visibility of the target systems through that. That's a portal UI. Secondly, the user will select which server they want to log into and with which account, and once they select that and assuming they have the roles and rights that allows them to log in with that account onto that server or network device, then the privilege access service we'll log them in, but we're placing them surgically on that target system, not on the broader network. Again, unlike a VPN, you're not exposed to, to a bigger asset pool, if you will, you're placed surgically on the server that you select in the UI at the privileged access service level. So that's a little different as well. And of course, if an attacker happens to compromise the user's account, they are similarly constrained.

Tony Goulding (00:38:35):

If they come in through a VPN, they can hack into the broader network. If they come in through this mechanism, they're put on server a and constrained from being able to move laterally from server eight other servers in the network. So another benefit of, of using this method is that, um, and I think it's true of most volt solutions, but, um, when you log into the vault and you say, I would like to log in to that server there, then the vault will create a session on its behalf and it won't reveal the password. So the password is not revealed unlike with the VPN where, you know, the ID and a password. So there's a likely, you know, there's a risk of being compromised here. Um, you don't know the passwords to the accounts on the target system, so the vault will log you in.

Tony Goulding (00:39:21):

It will take those passwords out of the vault and inject them in without you seeing it. So, there's no risk of you having the password and trying to bypass the vault, or an attacker trying to bypass the vault and subsequently go directly to the server in order to log in. The other thing is that once a session has been used or a password has been used in that type of fashion, the vault will automatically rotate it. So I log into the vault. I asked for a session to a server. I finished my session that password gets automatically rotated. And because the user no longer needs to know that password, then the vault can set that password to something long and complex, right? So it's not going to be the name of your dog. It's going to be something that assuming the system supports it, I know 15, 20, 30 characters long and complex.

Tony Goulding (00:40:20):

It’s harder for an attacker to guess. You get an extra layer of risk mitigation there as well. You can probably see that certainly for outsourced IT, this is an ideal scenario. And even for outsourced IT with this, which adds a lot more layers of security, you can further mitigate their risks and add a more secure kind of interface by using federated login to the vault. SAML-based federation, we’ll come to that in a second. I just want to finish on this slide before I turn it back to Brad. So here you'll notice that because of our architecture, we can have multiple of those gateway connectors. Going back to the previous question we had from the audience about how this thing scales, here's an example of scaling horizontally to different systems.

Tony Goulding (00:41:17):

So, in this fictitious example, we might have servers in the DMZ, so we can put a gateway connector there in roll it in the cloud, bang. We're now able to do remote login to the servers in that DMZ using our AD credentials, for example, or our LDAP credentials. And we don't need to expose the internal AD into the DMZ in order to achieve that. Similarly, we may have workloads up in AWS or Azure, or we may get an M and A, so one day somebody knocks on its door and says, Hey, we're about to acquire somebody. Their IT systems are over here. How do we hook them into our AD and make sure that they are authenticated against our AD, and that they're only allowed to log into servers that they're allowed to log into. You put a gateway connector on a windows box within their network.

Tony Goulding (00:42:04):

That thing has a mutually authenticated trust with our platform. And now the administrators, wherever they happen to be whether they're with the merged company or the acquired company, or the original IT organization, they browse to the vault. They log in with their credentials, their AD account, and then they can see whatever servers they need to access irrespective of where those servers are, in the M&A organization in Azure and AWS and the DMZ and the data center. And they can log in remotely from there wherever they happen to be. So that's kind of the beauty of this hybrid environment that we've architected specifically to be native SaaS and for the cloud. So, let me just go back to a statement I just made, and I'll turn it back to Brad. On the left, if you're outsourced IT, we also support the ability to log into the vault using SAML-based Federation, which is actually quite important from a security perspective as well. So anyway, back to Brad.

Brad Shewmake (00:43:09):

That's good. So actually, where you were talking about, you know, this being a SaaS solution, there are a lot of questions about that. “What happens when the cloud is unavailable?” Then, “Are credentials cached in the gateway connector if the PAS goes offline for some reason.

Tony Goulding (00:43:34):

So, our SaaS service is available in lots of points of presence. Geographically, we have what we call “pods“ in North American, South America and Asia and Europe. And, AWS has outages, right? First of all, our PAS is redundant, internally, but it also has a redundancy by virtue of the fact that it has presence in multiple availability zones throughout the world. So in the unlikely event that our service in every single pod goes down or that AWS or Azure goes down in its entirety. I mean, we've seen examples where an AWS region may suffer an outage, but then everything kind of fails over to another region.

Tony Goulding (00:44:35):

And as I say, we're in multiple regions. Part of that is just because we want to make sure that for our customers, we have a lot of multi-national customers that their gateway connectors and the SaaS service are kind of more together within continent. So, they're closer together physically, um, just for a slightly better performance perhaps. But because of that architecture and the multi-region architecture of the cloud, , I mean, we've had this service up since 2015, and I think you can go to our website to centrify.com/trust or something like that, where it shows you the uptime of our service over the last five years. We're the only vendor that's had a SaaS service like this. And ours has been there for five years. So, you can look to see what our uptime is, and that gives you a sense of, you know, has any cloud impact or even any Centrify outage impacted the availability of that service. There was another bit to that question, Brad, I don't recall what it was.

Brad Shewmake (00:45:48):

The bits of that question was whether credentials are cached in the privileged access service.

Tony Goulding:

No, I mean, so certainly it is a vault. This is a hardened vault. So clearly we are storing vaulted passwords and we are encrypting them and we're securing them within the vault. But when it comes to the systems on the right, we have scenarios where, from an IT perspective, their service, so they're static. They're not mobile, so they don't suffer offline or outages as often. The clients that run, for example, they're on a windows box, that might be a user's laptop that's remote, or you're on a plane and you've lost connectivity with the vault.

Tony Goulding: (00:46:50):

Then we have offline capabilities. So we have the ability to give users an offline login to their laptop when they're on a plane or they're off the network, so that they can log in and do their work. And of course, we have to make sure that, that the mechanism, I'm not quite sure how it's architected, but the mechanism that we use for that is secure, that it's safe because, caching is great for speed. And for making sure that that certain configuration elements are current. But it's also good in a kind of an offline mode. We also have a mobile app on Android and iOS. So for example, let's say a particular server within it went down, let's say it's off the network. Actually, let's say it's a Linux server that's in single user mode.

Tony Goulding (00:47:45):

And, you have to check out the root password from the vault in order to log in and, and do a root cause analysis. And you're in the depths of the data center where there's no, uh, you're off the network. So you could use your mobile phone with a cellular connection …, um, the app that we have to talk to the vault in the cloud and to check out the password at that point. And then you can use it to manually log in, triage the problem, and then check it back out, back in again, and we'll rotate it. So there's another mechanism that you can use there if services are unavailable.

Brad Shewmake (00:48:25):

All right. I know we've got about 10 minutes left, so I want to try and hammer through some of these questions as quickly as possible. Thanks to everyone for submitting all the questions. One question here is, “does the gateway connector call out to the cloud for the connection, or do I need to poke holes in my firewall?”

Tony Goulding (00:48:42):

The former, so basically, well actually, sorry, let me rephrase that. So the gateway connector has a permanent outbound connection to the SaaS service. So there is no need to poke additional firewall ports, so it will reach out to the cloud. So if there were arrows on the diagram, they would be pointing from the gateway connector to the cloud, they'd be in that direction. So hopefully that answers that question.

Brad Shewmake (00:49:13):

Okay. then a follow up item here, Tony had mentioned, that we publicly make our system status available, and that URL is uptime.centrify.com. So if you want to go with it that, also all systems are operational right now, which is good news. Another question is, “do I need to install an agent on each server, the gateway connector talks to?”

Tony Goulding (00:49:39):

So the way that we work, first of all, if you had a gateway connector there and you wanted to go into the SaaS service, you can add servers to the SaaS service, even without a client running on the box. So let's distinguish — there's the pass layer, the service, the SaaS service, the vault, then the gateway connected acts as that bridge or that proxy. And then there's the potential for having a client on a server. So without a client on the server, I could still manually, or, or using an API or whatever. I could still add servers and accounts to our, to our password vault. And the gateway connector can still establish a remote session to that, right. So I can still remotely log in using that mechanism.

Tony Goulding (00:50:32):

Now where the client comes into play is that if you want to leverage, us for governing a login directly to the box, then you can use our clients to log you in. And that client can run on windows or Linux. So in the Linux world, and this is really talking about a slightly different product called privileged elevation which governs what you can do on the box once you've logged in, but that client ostensibly will bridge a Linux box to active directory so that we can manage that Linux box or any of the Linux boxes on the right hand side from active directory. I think we're going to come to that in the next webinar, which is privileged elevation, but that client, and if it's there can also reach out to the cloud to do things like MFA on login, right?

Tony Goulding (00:51:28):

So we define our MFA policies in the cloud. And if you want to leverage MFA on log into those servers on the right, or even on privileged elevation on the right, then the client, there can be used to talk to the cloud and fetch the various different MFA, second factors and present them to the user and take the input and potentially, um, potentially it can talk to other services like radius for authentication or a LDAP, as I said earlier, or auth, so it can do a lot of different things. It's not essential, but it helps provide some of the more advanced capabilities that you're going to want to need. Also, as we move on, there are client functions that help improve our overall functionality. Let me give you an example. So within our SaaS service, we have the ability to reconcile passwords.

Tony Goulding (00:52:32):

So, what that means is that vault is the source of truth, and it is owning the passwords for the accounts that are local on the systems. So every now and again, it will rotate those passwords to make sure that they are fresh. But if somebody was to go behind the scenes directly to the box, if they had enough privilege to reset the password on the box, then we're out of sync. So the vault has the ability to reconcile that and put that password back to a known password, that it is the source of truth for. And you can do that in one or two ways. One is that the vault can use an account and administrative accounts to log in to that box and change the password back. But then just perpetuates kind of a security issue of you've got yet standing privileges around.

Tony Goulding (00:53:27):

You've got another privileged account that's local. That could be compromised. Now, that's great if you don't have a client on the box, but because we do have clients, then we can do that in a much more effective and efficient way. The client can recognize the change to the local password, right? And then it can ask the vault to reconcile that password. So we're using a local client. We don't have to use another local account. That's highly privileged that has the risk of being compromised. So that is an example of, of maybe multiple examples that we could give you of where a client is advantageous. And also in terms of privilege elevation in the next webinar, that client is absolutely critical in doing a much, much better job of securing access on the box than you could ever do with just the vault on its own. But I'll leave that to, to the next webinar, right? Yeah. I got to save something for later in the month.

Brad Shewmake:

Okay. I know we have about five minutes left, but we do want to serve the second poll question out. Yeah, I did push it and I think we have answers. Great. Okay. It’s all live folks.

Brad Shewmake (00:54:52):

Okay. Tony let's do one more question while everyone's answering the poll. So, what happens when there's a man in the middle attack on the left hand side between the user and the PDB server, what the bad guys see the answers the servers are sending back to the to the user? What happens when there's a man in the middle of remit in the middle of attack on the left hand side, I'm assuming that means a left hand side of your sketch drawing between the user and the PDB server. What the bad guys see the answer is the server is, are sending back to the user. I'm not sure what answers are being referred to there, but, so the connection between the users and the Centrify privileged access service is a secured connection.

Tony Goulding (00:55:48):

It’s a browser based connection unless you're coming in using SAML, in which case, it's harder to be a man in the middle when you're using a SAML-based token X 5 and 9 based anyway, even when you're coming in through the browser.

Tony Goulding (00:56:52):

“So, is your organization using anything beyond the VPN to secure remote access, whether employees or third parties? 50% said yes. 34% said no. And 17% said, I don't know.

Brad Shewmake (00:57:11):

Okay. Yeah. That's I mean, that's pretty good. We've got half the users saying yes. So, that's better than, being below 50%. Well, we are just about out of time, Tony, let's go ahead. And, if you want to revisit the slide you showed at the beginning really quickly, and

Brad Shewmake (00:57:31):

It runs through some of those business challenges and what we discussed.

Tony Goulding:

I think that's, that's being live right now. So, let me see if I can go through this. Okay. So let's go through these. So allow access to the resources required, not the entire network. So I hope you've seen that. That's if you're a user and you're logging into our vault, then you get presented with only the resources that you're allowed to see based on your job functions. So that includes, you can say, I want to log in to this server and the vault will surgically put you on the server. It's not putting you on the broader network. So, we're not like a VPN where you're on a jump host on the network and potentially you can then, sort of move around. The second one, provide granular privilege, not just administrator or roots.

Tony Goulding (00:58:22):

Not everyone with access truly needs a complete administrative access. So this is kind of a duel part. From a purely vault perspective. Centrify roles and rights within the vault, constrain what the user is allowed to access, what system they're allowed to log into using what account now our best practice, which is very different to a lot of other vendors is that you should only use roots administrator, Oracle, these highly privileged accounts in an emergency break glass scenarios, 5% of the time, 80, 90, 95% of the time, you should be logging into the vault as yourself. And you should only log in to the end point using that same account. Use it, let's say your AD account. That way we have full accountability. It constrains what you're allowed to do.

Tony Goulding (00:59:16):

And then for the next webinar, when we talk about privileged elevation, we can then use elevation as a least privileged best practice for getting the access you need, but only to the things you need to do, to do your job, and only when it's necessary to do that. So we want to avoid the use of administrator or root or anything, highly privileged like that, and use a least privilege model. The next one is ensure a higher level of certainty that it's truly the admin taking the action. So again, with the least privilege model, you should be doing everything as yourself, not as administrator. Administrators, anonymous routers anonymous. Oracle is anonymous. Cisco is anonymous. So we should avoid using them altogether, unless it's an emergency. So you should be logging into the vault. Let's say we do radio account. And then everything you do in the vault and everything you do on the system that you log into is accountable to you as an individual.

Tony Goulding (01:00:11):

And so that end to end visibility is really essential. Not only for IT instant response, but also for compliance, right? We want to make sure that there'll be no, who is doing what managed resources anywhere without requiring knowledge. I hope you see that with our architecture, with the SaaS service and the gateway connectors, we have visibility to all of the resources wherever they may be. So, if I'm an administrator logging into the password vault, I don't need to worry about where things are. I see a list of servers that it's my job responsibility to potentially log into. And I log into them. It's as simple as that. And again, without a VPN. So, if I establish a connection from the vault to a downstream server, that can be exposed to me through a built-in web server capability in our vaults.

Tony Goulding (01:01:01):

In other words, it's a browser-based session. There's no VPN involved. Similarly, if I want to use my own clients, PuTTY or RDP or something like that, then I can get a remote connection to the downstream without requiring a VPN, because it goes through our service. It goes through the gateway connector, and it's the gateway connector that has the RDP or the SSH to the downstream, but it can tunnel that back through either direct SSH or RDP or through a web-based session, and then allow an admin to access the resources they have a business need to manage. So I kind of alluded to this. So again, and outsourced IT, they're not corporate owned machines. You cannot guarantee it's a clean source. So VPN-less remote access means they're not network attached. You get a clean source, you don't have the IT overhead of knack and, VPN clients and, and help desk calls because they forgotten their password  so on. So you get a benefit from that perspective. I also, now I'm at the end of this, we were going to show a demo, which we haven't got time to do. But I think the link is going to be provided to you so that you can look at that at your leisure, Brad.