This is Dan Conrad from One Identity, and today I'm going to do a quick whiteboarding session on securing privileged remote access. So in my whiteboard here, I have my data center, which is typical of any on-prem data center with systems and applications and operating systems running in it, and that could be a Windows operating system, Unix operating systems, networking devices, all that make up this data center. And then I have my remote administrator.
So through years of system administration, we used to connect into our data centers a long time ago via things like dial-up access, and we would actually dial directly into the data center when all of your traveling laptops had modems in them. Of course, nobody does that anymore. So what we do today is we actually connect via the internet.
So I'm going to connect my remote administrator to the internet via access point, which is typically the way we do it-- we all have our Wi-Fi hotspots at home, or this could be sitting in a coffee shop somewhere connected to the local-- coffee shop's Wi-Fi. Now that Wi-Fi is providing us access to the internet, but the internet is actually providing us access to that data center.
Now the data center is rarely ever connected directly to the internet, so they're going to be traversing a firewall. The firewall is designed to protect the internal IP space from the external IP space and only publish things to that firewall that are required for external use. So that firewall is going to be the part that's actually connected to the internet. Let me go ahead and connect that here.
So as a remote administrator, I need to get from this point to, say, a server in that data center, I need to traverse that firewall and have that controlled. Now publishing the ports that are required to do that is usually not recommended. In the case of a Windows operating system, the ports are going to be port 3389, which is remote desktop protocol-- RDP-- and in the non-Windows environment, which is your Unix platforms and your network devices, that's going to be a secure shell protocol-- SSH-- which runs over port 22. We really never recommend publishing those ports to the internet because there's a lot of vulnerabilities that go along with that, and attackers are constantly looking for ways to exploit those ports.
So what we do is we bring in something like a VPN concentrator or virtual private network. Most of us that work remotely or very familiar with VPNs. We use them to access internal resources-- virtual private network. So it's designed to make it seem like you are working in the building when you're actually remote.
And those are great for things like especially the traveling worker. And the way it works is there's a VPN client running on the system down here, whether it's an in-home office workstation or a traveling laptop, what have you. That VPN client, when you launch that VPN client, it encrypts all the traffic destined for that target network. So all of that would be unreadable to anybody in between, and it's decrypted at the VPN concentrator, and then the VPN makes that connection out to your end systems or applications. So that applies to both users and administrators.
So you can see that it provides a significant level of security traversing the internet. It also provides a level of security based on things like unsecured Wi-Fi. So if you're sitting in a coffee shop somewhere and you're connected to a Wi-Fi, there's really no guarantee of the encryption of that Wi-Fi, and there's no guarantee that that Wi-Fi even is who it says it is.
So somebody may be listening to that traffic off of that Wi-Fi or they may have even stood up a Wi-Fi, something called a rogue-- or an evil twin and be able to mirror somebody else's Wi-Fi and sniff traffic in between, capturing things like authentication and even passwords that are passed in clear text-- hopefully you're not doing that. But it gives them a lot of capability to analyze that traffic. We want to eliminate that. We want to encrypt it at every opportunity that we have, and the VPN provides that.
So once I'm at the VPN, and I can now can launch my remote desktop or my SSH down here and connect out to these end systems. So I've got a auditing mechanism at the VPN, so I know when people are connecting to my VPN because that's going to write an event log and that's going to fire out to my SIM and I'm going to go back and look at that traffic later. Then I'll have events on the end systems that I'm actually connecting to, so I can see when people are connecting and authenticating.
That's really about all I can do from that perspective. Unless there's some level of auditing involved on these other systems, I'm not going to have any capabilities beyond just that. So administrators, when they connect to these VPNs or they come in and they administer the network, they're very familiar with the carte blanche capabilities that they have to launch connections out to end systems and authenticate anywhere they need to.
And this may or may not be a problem in your environment, you might want to think about what that means to you. So what I want to do is show you the opportunity to add a level of trust to that so that I can actually add a layer of security between that VPN and the end systems. The way this would work is this is Safeguard for Privilege Sessions, and this is a sessions management appliance. It's designed specifically to manage sessions between remote administrators or even contractors in this case and give them a secure session to the end system that they need to manage, and give me levels of auditing that I can actually make actionable.
So it works the same way. The administrator's is not going to know any difference, there's not going to be any changes in business processes at this end, but what's going to happen, he's going to launch the VPN client and say he's going to launch-- if this is a Windows system right here, then I'm going to launch in connection out to that end system via RDP, it's going to traverse the internet, and then it's going to come through my firewall and on my VPN concentrator.
At that point, it's going to connect to this Safeguard for Privilege Sessions appliance. Then that appliance is going make the connection out to the system seamlessly for me. It can even be invisible to the end user. So that all of the traffic coming off of there is actually routed through the Safeguard for Privilege Sessions appliance, and it ends up on the end system. So now I'm proxying that protocol, it gives me the capability to control which end systems they can actually connect to. At the same time, it gives me a level of auditing within that session. So I can invoke full session recording, I can even build audit policies around that session that tell me exactly what they're doing and when they're doing it.
If they start to deviate from designated policies, I can do things like freeze their session or even terminate it. That gives me the also the capability to do things like blacklisting and whitelisting commands. So if they're not supposed to run certain MMCs on Windows consoles, if they launch that MMC, I can either freeze a session or terminate the session.
With that auditing comes something that gives me the ability to do behavior analytics. So when I turn on the auditing, I can actually analyze the sessions themselves to see what's typical for Joe Admin sitting here in the field and things like time of day and systems they can connect to, even commands that they run or MMCs that they typically launch, and that builds up what's called a profile of that person, and then are able to tell you when they deviate from what's called normal behavior.
If they start to connect at odd hours or if they start to run commands that they've never run before, you know you might want to raise a little bit of a risk index on that person. But that even comes down to things like keyboard patterns, their typing speeds, and mouse movements. So if it becomes evident that maybe the identity of that end user has been compromised, you can take action at the Safegaurd for Privileged Sessions appliance and do things like, again, terminate the session or freeze the session.
It gives you a lot of capabilities as far as auditing goes. It adds a significant layer to anything that the VPN was going to offer. But if you think about it from a contractor perspective, so if I have the opportunity or I have the need to provide contractor access to these end systems or maybe a specialized appliance in that environment, I can provide that through Safeguard for Privileged Sessions. So when the contractor would connect via their protocol, whether it's SSH or RDP, they would only see the end system that they're allowed to connect to. Then I can do a full recording of that and end system or of that session and give me a complete audit trail of everything they did.
And that can be used for anything from training material all the way down to if something were to happen catastrophic in their environment, we can actually go back and see who did it and when they did it.
So again, that is a Safeguard for Privilege Sessions. If you have any questions, please connect to oneidentity.com/safeguard and give us a call. Thanks