Hello and welcome to One Identity Unite. My name is Dan Petersen and I'm the lead architect of the Privileged Access Management products here at One Identity. Today I'm going to talk to you about VPN-less Privileged Access Management. In order to introduce this topic, we're going to talk about how networks and systems have evolved over the years, and some of the trends in IT and cybersecurity. Then I will show you some of One Identity's solutions and how they deliver access to critical resources and management of disconnected assets safely and securely without requiring a VPN.
Here is the agenda for this talk. If we are going to discuss VPN-less PAM, I should talk a little about the problems with remote access VPNs and why we might want to avoid them for certain use cases. I'll go over what alternatives exist in the market today for remote access VPNs, and then we will look at Safeguard Remote Access, or SRA, and how it can be deployed and what some of the exciting new features are. After introducing SRA, I'll get to talk to you about Connect for Safeguard Assets, and along the way, I'll be sure to do lots of demos.
Those of you who work in information technology and cybersecurity have such a difficult job. The goal of IT is to enhance the capabilities and improve the efficiency of employees and business processes by providing access to data and applications and services. Contractors and employees must have the access they need to do their jobs. This can be extra complicated when you need to support older technologies and legacy systems. Safely providing the necessary access is exceptionally difficult because modern threats to your business and your data have moved well beyond the simple malware of years of the past.
Today, IT organizations are threatened by data breaches and ransomware that can completely stop business operations and hold the company hostage. So it becomes a delicate balance to try to grant the necessary access without putting the company at too much risk. When the access you need to grant is for privileged accounts or privileged operations, the stakes are even higher. This should be reflected in the security controls that are deployed when granting access.
Access control is a complicated topic, so let's just focus for a moment on network access. The safest networks in the world are completely inaccessible from the outside. Not very many networks look like this, but they do make sense for certain very secure use cases. No data is transmitted in or out. If someone wants access, they have to physically enter the data center, and there's physical security controls that we can put in place that are very well understood. It's easy to verify someone's Identity in person and keep unwanted visitors out.
That's great, but for most use cases, our networks require at least outbound access to an external network. This is OK, but when someone inside the network can bring in a threat by clicking on a link or downloading a file in a phishing attack, this is more risk than the air gap use case, but the real trouble begins when inbound access is granted to our private network. If the external network is the internet, then the number of threat actors becomes unmeasurable. This sort of access is necessary in the modern world. All of us have someone who exists outside the network that needs to have access into the network because they can't present themselves physically.
The way we work has evolved. Years ago, nearly everyone came into the office to work, so access to systems and data in the on-premises data center came from inside the private network. There was a well-defined network perimeter that was relatively easy to protect, and it faced fewer threats. A firewall and a remote access VPN for those out traveling did the job well.
As time moved on, most companies evolved to have multiple data centers, and networks evolved to include clouds and virtualized resources no longer hosted in the corporate data center. Information technology evolved, as well, to include Software Defined Networking and SaaS applications. Some workers still that came to work every day, but there were more and more external contractors and remote workers.
Fast forward to today, and many companies are closing down data centers. Most things that can move to the cloud have a roadmap to get to the cloud or they're already there. Where the network is concerned, it's hard to even recognize a network perimeter, and legacy techniques for securing the network seem no longer to apply. Work from home is the norm for many companies, and more contractors are being hired in both business and technology roles.
Back to the balance between security and access, some of you may be familiar with the CIA triad. When evaluating security, it helps to think in terms of confidentiality, integrity, and availability. A key point of the CIA triad is that availability is part of security. We have to provide access. We can't just air gap all networks because it is the most secure approach, but we need to provide just the right amount of access with just the right amount of security controls, especially when we are talking about privileged access.
So what is wrong with remote access VPNs? The short answer is remote access VPNs grant too much access. A VPN access point is available to anyone anywhere with valid credentials. Unfortunately, valid credentials aren't that hard to come by. Phishing attacks are common. Many companies are seeing spear phishing and whaling attacks to try to get employees to click links or load files that compromise credentials. EvilProxy is a phishing as a service platform that can bypass MFA in certain circumstances.
When remote users connect to the VPN, they are often given access to the same network that stores business critical information. This is because fine grained access control is difficult at the networking layer. Some attackers will just use the first machine inside the network as a jump host to access the rest of the network. A successful connection exposes a large attack surface to threat actors searching for vulnerabilities. This can allow hackers to do reconnaissance against the private network. Direct corporate network access allows threat actors to deploy toolkits. Attackers don't even need to be sophisticated anymore. They simply run the tools provided by others.
Another problem is that remote access VPNs are an older technology based on many legacy components. Searching for vulnerabilities in remote access VPNs yields many results. Legacy interfaces suffer from cross-site scripting vulnerabilities and injection vulnerabilities that make it easy for an attacker to attack the remote access device itself.
So what are some of the alternatives to remote access VPNs? Zero Trust Network Access products are a much better fit to modern networks where there isn't a clearly defined perimeter. They are deployed with modern authentication technologies, they expose only systems, protocols, and applications authorized to a particular end user, and they don't provide direct network access, which limits an attacker's ability to perform reconnaissance and lateral movement. ZTNA is a much better least privileged solution.
So why might we want to look beyond ZTNA for an even better solution? One reason is that ZTNA solutions often require an agent on each endpoint, which is a little bit additional infrastructure and configuration management. Another is that security controls are not quite sufficient for privileged access use cases. Even with modern authentication and MFA, those things can still be defeated by EvilProxy, allowing access to someone who isn't exactly who they say they are.
So why is SRA a better option? One way to illustrate the importance of privileged remote access is to use the Mitre ATT&CK framework. For those that have never used it before, I highly recommend that you visit attack.mitre.org. The Mitre ATT&CK framework is a database of adversary tactics and techniques. The best part about it is that it is based on real world observations. This isn't just speculation on what threats might exist out there. Rather, these are attacks that have been executed in the real world and reported to Mitre. That is what you want to focus on and defend yourself against. Along with the tactics and techniques, Mitre also publishes recommendations for detection and mitigation.
This is Mitre ATT&CK. It's organized into a matrix. We are going to look at the matrix for Enterprise, which is most relevant to our discussion today. For an attacker to exploit you, one of the first things they need is initial access. They have to get into where the critical systems and data live. We will drill deeper into initial access in a minute, but before we do, let's look at other tactics relevant to privileged remote access. Privileged escalation and lateral movement are additional tactics that apply to the PAM use case. Attackers might try to exploit a privileged escalation mechanism or steal privileged account credentials. Lateral movement involves the exploitation of additional remote services accessible as part of the remote access offering.
So clearly, Privileged remote access is very risky. The threat tactics are attacker initial access, privilege escalation, and lateral movement. Back to the ATT&CK matrix, let's double click on the initial access tactic external remote services technique, and see what the examples and recommendations are.
Well what do you know? A lot of real world attacks are executed against remote access VPNs, most of the time using credentials the attackers had already stolen. One mitigation not listed is covered by SRA. Attackers cannot easily steal credentials that are never exposed because users never know what they are. SRA supports this mitigation. Other mitigations include blocking unnecessary services, central management, and strong authentication. SRA only provides access to the systems listed in centralized policy and supports modern authentication. Under detections, Mitre lists many of the capabilities of SPS and SPA. SPS will have a full audit recording of all the anomalous activity.
So when you need privileged remote access, be sure to grant it safely with appropriate security controls in place. SRA provides those security controls.
Let's talk about a few ways that SRA can be deployed to solve your remote access use cases, and let's do some demos along the way. SRA is an add-on product that provides an interface in the One Identity Cloud for launching remote access sessions based on policy. The Safeguard for Privileged Sessions appliance creates a secure gateway into the private network without requiring a VPN. Administrators and auditors are able to leverage the full audit and monitoring capabilities of SPS. This means that there is an indelible audit recording of every action taken.
There is command detection, and the recording can feed the analytics that can be added on to SPS with the Safeguard for Privileged Analytics module. This is an effective control to prevent threat actors from using your remote access solution for persistence on your network. A similar use case example with a similar architecture is for secure cloud access. The SPS appliance is a cloud ready component that can be deployed to protect a secure cloud network segment while safely granting necessary access. This may be ops or developer access to production environment to debug or fix a critical issue. This sort of access produces an audit trail that can satisfy the security and compliance requirements that you have in your environment.
Let's see a simple demo of the SRA portal. I'm logged in here to the One Identity cloud that we call Starling. I'm just signed into a test organization as a test user. The One Identity cloud offers services and products based on subscriptions. Clicking on the SRA tile opens the SRA portal. Inside the portal, we see lists of targets along with the privileged accounts that will be used to access them. Those target servers come from an associated connection policy in Safeguard for privileged sessions. This SSH connection policy contains the list of targets. This particular SSH policy has been configured for access with credential injection. So clicking on the Connect button logs in without prompting for a password.
There is a brief loading screen while SRA and SPS set up the secure connection into the private network. SRA uses an embedded SSH client that loads directly into the web browser. At the prompt, I just put in a few commands that we can look for during the session playback. HTOP is a good one because it uses a cursors interface. It exercises the terminal a little bit. And just a-- I'll broadcast a hello, world message using wall, then log out with the Exit command.
You'll notice that if I pop back over to the SRA portal, I can see that the session is active. If I close the browser, the active tag goes away. Now let's try an RDP connection. Click on Connect. It is setup the same way, using an SPS connection policy. This one is also configured for credential injection. It takes a while to load the desktop because it's a pretty leanly provisioned test to be in, and this is the first login on this VM in a while.
Again, the RDP client is embedded directly in the web browser. I'll just run the Task Manager so we can see that app in the playback, then I'll do something more realistic for an administrative task, like open MMC, which is something likely that I would need to do if I had a ticket to administer this machine.
On the left hand side of the RDP client, there are some tools. An on screen keyboard might come in handy. There's also copy and paste for clipboard operations. These are there because the Control-C and Control-V are sometimes captured by the browser and not passed through properly to the RDP endpoint. The red X is a Disconnect button that closes the session immediately, and that is the basic SRA portal interface.
Heading back over to the SPS UI, we can log in to the search portal to find the sessions that we just ran through SRA. The most recent sessions show up at the top. You can see that I ran several sessions before I recorded this. If I were using privileged analytics, those scores would show up here. I can click on the Details button to see the actual commands. I could play back, too. But to show that this is the session we actually did, we can look at the command events. There you can see my HTOP and hello, world commands. SPS includes command detection security controls that can even terminate a session if a malicious command is detected.
Let's go over to the RDP session now. The window title detection will show what was on the screen. I can see the Task Manager was loaded, as well as the MMC console. Let's play this one back so that we can see the video rendering. In this case, I'm using the online player. You'll see that the playback shows you exactly what the original user saw on their screen. It also includes this wait for a slow connection.
Along the bottom, you can see highlights for the mouse movements and text input. This allows you to quickly review a trail by seeking to the most important parts. That concludes the demo of the basic SRA portal interface and the playback that's available through SPS.
Another deployment mode for SRA is to use SPP initiated sessions. This means that the session is approved via approval workflow before it can be launched through SRA. So let's consider a contractor or a remote user who wants access to a critical company asset via SSH or RDP. Before the access is granted, the individual must request access from SPP. SPP controls the credential and must authorize the session before the credential can be injected into the session.
In this scenario, it is important to point out that approval workflow serves as an additional security control protecting the remote access. The remote access is still protected by the same SPS security controls that were included in the SRA portal demo. This particular diagram shows how this access scenario would be configured for an on premises private network.
The next diagram is generally the same, except it highlights that SPP and SPS are cloud ready solutions. They can be deployed into your own private cloud environment. This last diagram shows the same contractor a remote access scenario, except in this deployment model, everything is hosted by One Identity in the One Identity cloud via Safeguard on Demand. The approval workflow is the same in that the remote worker must first request access, get approval, then launch the session through SRA. The credential is controlled by SPP and only injected into the session when the approvals have been satisfied.
In this demo, I'm going to show an SPP initiated Safeguard remote access session launch for RDP access to a Windows Server. I'm going to show how an approver could use the One Identity cloud assistant to approve the session from within Microsoft Teams. Those who need to approve Secure Remote Access may not be where they can log in to Safeguard to give an approval, but usually, they have access to Teams or another messaging service from a laptop or from their phone.
This is the Microsoft Teams running on my workstation. This is the same Teams interface that I use every day, so I've blurred out everything but messages coming from the One Identity cloud assistant bot. Now I'm going to head over to the SPP access request interface. I'm going to use a favorite to request RDP access to a Windows host named Client as an administrative AD user whose credential is controlled by SPP.
As the request is submitted, I get a notification from Teams of a new message. The message details what is being requested, but instead of just being a notification, I can actually take action on this access request right here from within Teams-- the same place where I collaborate with colleagues throughout the day. As a side note, cloud assistant also supports Slack. When I come back to the SPP interface, I can see the approval take effect, and then I can see a Launch Web Session button. This button instructs SPP to launch this session through SRA rather than via the local RDP client or an RDP file.
SPP securely communicates with SRA to setup the session and provides a URL that can be used to launch the RDP client via SRA in a separate tab. The RDP client runs directly in the browser. The client credential is automatically injected from SPP into the session and is never exposed to the end user. The login is using an AD administrator account.
Once I'm in the RDP session, I'm going to launch an old version of the authentication services control center that I have installed on this host just to give us something to view in the audit experience. When I'm done, I can just sign out in the usual way using the Windows button. The browser tab with SRA just returns to a disconnected screen.
Let's open up another browser tab and log into SPS to show the audit playback. To find the information about our session, I go to the search portal in the SPS interface. After finding the most recent session at the top, I can click on Details and see the commands that were detected from within the session. I can see that control center was run, but I want to see the video. Clicking on the Play Video button launches the online player.
Along the bottom of the player, you can see the index for the interesting parts of the video-- those times when new elements were drawn to the screen or where there were mouse movements or keystrokes. This allows you to quickly review access while focusing on the most important audit events. That wraps up the demo on SPP initiated SRA.
The most recent release of SRA has some cool new features. SRA is built as a multi-tenant SaaS service, so all customers benefit from these new features immediately upon release. The first feature is called lightweight managed networks. This is important for deployment models of SRA that don't include SPP. SPP has the concept of managed networks that can be configured to align with the network segmentation of the sites within your own environments.
Managed networks allow you to assign an affinity between network segments and particular Safeguard appliances. SRA, with this new feature, has been given a lightweight version of managed networks to add this capability where SPP is not involved. Managed networks make it so privileged session traffic flows through the appliances that are close to the target assets. You don't want to launch an SRA session for an asset in New York and have the traffic flow through a session recording appliance in Chicago.
The next two features are related to the next generation browser based SSH client. This new SSH client includes a terminal emulator running natively in JavaScript, which dramatically improves the end user experience. The new SSH client also includes the ability to upload and download files during the recorded session. This can be incredibly helpful when you need to upload configuration files, scripts, or patches as part of an administrative task or to download logs as part of debugging a problem.
This is a demo of the next generation browser based SSH client included with SRA. The best way to show the capabilities of the new SSH experience is to contrast it with the old experience. I have configured SRA in one environment for SPP initiated sessions that will launch using the old SSH experience. In order to launch an SPP initiated session, I have to create an access request from the SPP portal. I click on the Launch Web Session button and wait a bit for my session to securely connect in a new browser window.
Inside the session, I'm going to run HTOP, which is a command line cursors interface process monitor on Linux. The reason I launched this is because it makes full use of the terminal columns and rows. When I resize the screen, you can see that I'm actually interacting with a picture of a terminal instead of a real terminal itself in my browser. So the picture just shrinks when I resize. All of the text gets smaller, but my terminal dimensions remain exactly the same. This can make it much harder to interact with.
I have a separate SRA environment configured to launch sessions through the SRA portal. In this environment, when I look at the SRA settings, I can see that the next generation SSH client is enabled. I click on the tile to launch the session. When this connection goes through, you can see the terminal looks slightly different.
Let's execute the same test by running HTOP and modifying the screen size. You can see that when I resize the terminal, the text remains the same. This is because the actual dimensions of the terminal are changing, and I'm interacting directly with the SSH protocol, just as if I had launched the session from my desktop using a normal terminal. SRA's next generation SSH client is built on top of the same JavaScript technology that powers many other cloud shells. It's also embedded in popular code editors such as Visual Studio Code to provide terminal emulation.
I now have full control over the terminal display that I'm given when I start a session through SRA. This means that I can make the text bigger. I can even pick ugly colors if I want to. My terminal emulator adjusts accordingly. I can get just the experience that I want. Now let's talk about the file transfer capability in the new SSH client. I'll start by listing the files in the current directory. Let me create a new file called Test TXT using the touch command. Let's open up that file with VI and enter some text.
Hello, everyone, and then just a bunch of garbage text. I can see that my small file is now in the current directory. Let's use SRA to download it. Open the Files tab. I can see all the files in the current directory, including the size-- 44 bytes. If I click on the file, it downloads into my browser. I can open it up and see the text that you saw me type earlier within the session. I'll just go back and cat the text files so we can see them side by side.
Now let's upload a file through the connection. I have a file here called Notes.text. You can see that it is roughly 2 kilobytes. If I click Open, it uploads through SRA to the target server. If I list the contents of the current working directory again, I can see that Notes.text is here and has a size of 1322 bytes.
Now let's close out the session and check out the recording in SPS. So first I have to navigate over to the SPS appliance where this SRA session was recorded. Once that loads and I'm logging in, I can open the search portal and find the most recent sessions from SRA.
Opening up the session we ran together, going to the details, you can see all of my commands and keystrokes in the event viewer. If I go to the details here, I can see the different SSH channels that were used during the session. You can see that SFTP is used to list the directories. Looking closer at the SEP information, you can see the names of the files that I used when I was uploading and downloading. This allows you to audit the actions of your admins related to file transfer, as well, during their recorded sessions. And that is the next generation SSH client for SRA.
Now I want to shift gears and talk about another problem related to VPN-less PAM. This problem has to do with what I like to call disconnected assets. Disconnected assets don't work well with traditional PAM solutions that require network line of sight between the credential management vault and the target system. Let's consider the situation for a standard work from home employee today.
In years past, work from home employees would get up in the morning, connect to the VPN, and start using the tools that they need to do their jobs. Many of these tools were hosted in the corporate data center as internet applications or file servers in databases. Today, however, many of the productivity applications our employees need are available directly from the cloud and host their data in the cloud. It has gotten to the point where work from home users never need to connect to the remote access VPN. This is great because we can really lock down remote access to our private networks, raising the bar of security controls to things that admins might be more comfortable with than regular employees.
The problem that comes up is that the end user laptop also has a privileged credential or privileged account for which the credential ought to be managed. When the laptop never connects to the VPN, the vault never gets direct access to check or change this route or administrator credential. The laptop is a disconnected asset. Enter Connect for Safeguard assets. This is a new service hosted in the One Identity Cloud. This service can securely broker password check and change operations for these disconnected assets. SPP communicates with Connect four Safeguard assets via HTTPS using a secure channel negotiated when SPP is joined to the One Identity Cloud.
Connect for Safeguard assets includes an agent that can be installed on disconnected assets. It can be enrolled with the cloud service. The agent is built for Windows, Mac OS, and Linux. SPP has a new capability to discover enrolled agents and have them create assets. It is worth noting that laptops at home are not the only type of disconnected asset that exists. The same solution can easily be deployed as part of a cloud only solution with Safeguard on Demand or self-hosted Safeguard running in the cloud. You may have secure network segments in your private data centers or private clouds that do not have direct network line of sight to where Safeguard is going to run in your environment. Safeguard can rotate these privileged credentials on disconnected assets running in these types of networks, as well.
This is a demo of Connect for Safeguard assets. In this demo, I'm going to show the new service in the One Identity Cloud portal and I'm going to show how to install the agent and roll it and get it connected as an asset in Safeguard. I'm going to show a manual enrollment process, but these steps could easily be automated. From the One Identity Cloud portal, you will see Connect for Safeguard assets as a new service. Clicking on the tile will take you to the agent download page.
You can see that there are agents available for Windows, Mac OS on Intel, Mac OS on Apple Silicon, and Linux. In this demo, I'm going to show you Windows, so we will start by clicking on that. This downloads a zip file containing the agent. In order to enroll the agent, we will need to request an enrollment token. This downloads as a text file. This token.txt file contains a constrained One Identity Cloud token that can only be used to enroll agents. It may be used for up to 30 days to enroll agents.
Now we will copy the agent payload and the enrollment token to the disconnected asset. In this case, I'm enrolling a Windows VM that is running on my local hypervisor, and I'll just copy them over via an RDP connection. I'll start with the zip file containing the agent, then I'll extract that onto the desktop. Rather than having the agent run from the desktop, I'm going to create a directory for it in program data. Let's just call the new directory Safeguard. I'll copy the extracted agent into that directory. You can see the contents are there. Now let's copy the enrollment token to the same location.
Now I'm going to execute the enrollment manually, but all of these steps could be automated through any software distribution system. I'll start by opening a command prompt. I'm going to change into the directory containing the extracted payload. Executing the agent with no parameters causes the usage to display. The first supported command verb is Enroll. Executing Enroll with no parameters presents the usage for Enroll. On Windows, you can see that I need to specify a service account that the agent will run under, so I'll rerun the command with Enroll and specify the local service account that will be used to run the agent.
The command prompts me for the password on Windows, but I could have included it on the command line. The command prompt also asked me to confirm the password. Then enrollment begins. The agent contacts the One Identity Cloud service and enrolls itself. The caller sees a message saying the enrollment has succeeded. Now I'm going to log into my instance of Safeguard on Demand, where I'm going to add this as an asset.
Returning to the One Identity Cloud portal, I'll click on the Safeguard on Demand tile. This brings me to my Safeguard on Demand Starling edition dashboard. I click on the Go to Module button to open my instance of SPP. I quickly log in using a test administrator account that I set up for this demo, and I see the familiar SPP dashboard.
Now that I'm inside SPP, I'm going to navigate to asset management and click on Assets. I'm going to show how to add a disconnected asset manually, but this could also be done using asset discovery, which can find enrolled agents and create assets for them. The first thing I need to do is give my new asset a name, then I Need to select the platform type. There are three new platforms that go along with Connect for Safeguard assets. These are Linux Starling Connect, Mac Starling Connect, and Windows Starling Connect. I'm going to select the desktop variety of Windows Starling Connect, then I can browse to select a Starling agent.
This view will display the host name of the computer where you installed the agent. There is only one in my list, so I will just select that. The authentication type for this platform is always Starling Connect. Now I can run a test connection, and this is going to operate differently because the agent is not always connected to the internet. Instead of an immediate progress, the platform task is submitted to the cloud and is pending the agent refresh. The reason for this is because a laptop or another type of disconnected asset may be turned off when not in use. The agent isn't continuously pulling. It has a configurable refresh interval. Continuous pulling would waste resources on a disconnected asset and in the cloud, so rather than waiting, we will just click OK to create the asset.
I am going to set this asset up to manage a local user password. So I go to the account view and I add that account to the list. The same account security tasks exist for these accounts as for other types of platforms. Because I know the password to this account that's currently set on the object, I'm going to set it in SPP and run a check password.
Once the task is submitted, I can check the log, and it shows again as pending. Rather than wait for the refresh loop, we can fast forward. As we go forward in time, you can see that the password check has successfully completed. Notice that for this task, along with the completion message, there is a duration that shows how long it took for the agent to refresh, pick up the task, and complete it.
Now let's go and submit a change password request so that no one knows the password to this account. Once I've done that and submitted it, I go back into the check and change log to show that it is pending, as well. Again, rather than waiting, I'll fast forward. After the refresh on the agent, the task shows completed successfully in SPP, and that's a simple manual demo of Connect for Safeguard assets in SPP.
This concludes the presentation on VPN-less PAM. I hope this information has been helpful, and I encourage you to use Safeguard Remote Access and Connect for Safeguard assets to solve the modern problems you face with privileged access management. I hope you enjoyed Unite and have benefited from all of the presentations. I'd like to thank our wonderful partners and sponsors that make Unite possible.