Hello. My name is Istvan Jagri. I'm a product owner at One Identity. Today I'm going to show you the latest news around the web application auditing in Safeguard for Privileged Sessions. As you might know, Safeguard for Privileged Sessions is already able to control HTTP traffic. The design of it is a great fit for on-prem use cases where you have simple and legacy web interfaces to monitor.
On the conference side, it has many features that can enhance the security of the monitoring systems, but it lacks the ability to inject credentials, so users must have direct access to the passwords. On the other side, the feature set is less improved than in other proxies in the product. A current approach has many possibilities, both transparent and non-transparent modes of operation are supported.
So it is up to the network configuration and possibilities that their users address the target systems directly or address the proxy instance first. It can enhance the security level of the target applications because even if an application does not support multifactor authentication, users can be forced to enter a one-time password or other additional information next to their passwords during the proxy authentication. The communication can be encrypted with TLS between the client and the proxy, making sure that the password and the OTP cannot be stolen by eavesdropping the network traffic.
Despite its limitations, this technology still has a lot of potential and it might be a great fit for many use cases. When it comes to API access all the things, we think that this solution could be the building block of controlling and recording sessions over HTTPS to cloud-based based service management. Currently, we are at the beginning of the feature discovery phase and we try to make contact with customers that have requirements in this topic, and they also ask for help from you. If you have a story about problems and needs an API auditing, then please contact us. We are more than happy to hear you out.
This approach, however, has several limitations, too. Upfront, the only way to connect clients that are proxied is using it as a forward proxy, meaning you have to specify the SPS address in the client's browser settings. It's not an issue in most cases, but as you will see later, there are certain situations when It's not possible to do that. Based on how the HTTP control handles TCP connections, SPS sometimes can't keep together those proxy sessions and it could happen that certain requests in a session will initiate new sessions, making the auditing process more complicated.
With this solution, it's not possible to identify the unique ways how a random target application displays the login form to the user, so credential injection is not an option here. Recorded audit trail files cannot be replayed as videos as in the case of other proxies. Only the HTTP requests and responses can be exported in PCAP format and the auditor has to use Wireshark or other third party tools to investigate further what happened in the session.
That was a rather current offering for HTTP control in SPS. In the next section, I'd like to share with you what we learned in the recent past about the changes in the use cases from a couple of aspects. First, we are not talking about HTTP control anymore, but web application auditing. The biggest difference between the two is that in the former case, the audited system is a standalone and simple web interface, but in the latter case, there's a complex cloud-based combination of services.
The two use different technologies and require different approaches from the auditing perspective, too. Traditionally, high privileged users on the network or database administrators who connect the remote servers by a graphical or console-based administrative protocols to perform their maintenance tasks on these systems. Today, a privileged user can be the sales rep with his Salesforce account, managing variable business-related data in the company's customer database.
Or a privileged user can be the marketing manager with the possession of the company's Twitter account. Also, these new privileged users are not located inside the local undefined network zones of the company, but can access these systems from anywhere-- from home or from a coffee shop with any device they use. This is specifically true for today's pandemic situation.
As most of the applications move to the web, the browser became the most important client. These users use traditional [INAUDIBLE] clients, such as RDP or SSH client less and less frequently, but access even these remote machines with the browser. Considering this paradigm shift is sober on us, we started to think on how to respond to these new challenges in our product.
We define a handful of requirements that solve the issues I mentioned before. These requirements also helped us to shape the future of the next generation of the web application auditing. First, we have to assume that there's no access to the client's browser settings. So it has to work without specifying an explicit proxy address in the browser. Credential injection is also a requirement because the password of the high privileged accounts must be stored in the credential store. So this solution has to support credential injection into web applications.
This is a must have for SAS targets, as we don't have any other way of controlling access to these systems. If users know their passwords, they can log in directly. And finally, as the majority of your customers install their temp solutions on-prem today and will continue to do that for many years to come, this solution has to run a locally installed SPS instance without requiring insane amount of resources.
A few words about the general future SAS that we have here. The solution works with a bunch of injected scripts into the original page of the application. These scripts are responsible for transforming every part of any elements presented in the HTML file in order the connection to flow to the proxy, changing the paths back and forth between the client and the server. As you can see in this example, this is how a path in a script looks like. And this is how the proxy transforms it on the fly.
With this approach, the security features of the browser, the application, and the web server won't be degraded as the proxy stays undetected in the middle. Another set of scripts creates snapshots from the generated DOM of the web page and after some optimization steps, the simplified and compressed content is sent back to SPS to store in the audit trail files for further processing.
During the auditing process, the snapshots can be replayed as a slideshow, so the auditor will see exactly the same that the user saw in his browser during the session. Let me show you the action. You have to use the user interface of SPS because this is how the access control selects the available targets based on the group membership of the authenticated user.
In this version, you can type in the target into this URL bar, but later, we want to offer other options as well. If the access control allows accessing the target system, a new tab is opening where the web page is loaded and the session recording is being started. As you can see in the address bar, the proxy uses random generated subdomains to keep the whole session together. Even there are redirections in the application or resources along with from other locations, from SPS point of view, they are treated as a single session.
Now, let's try in the credential injection. Because of the client-side validation, the form must be filled in with valid, but dummy data in order to POST it to the server. During its way up to the server, the proxy intercepts the data and changes the dummy credentials with the real ones on the fly. You can navigate between the functions of the application. And as you can see, the proxy can keep every element under the same subdomain. Besides recording everything in the same session, this feature has security benefits as well because origin-based security features in the browser can be utilized, such as cookie separation between the visited sites, supporting cross-origin resource sharing headers, just to name a few.
All right. Let's close this session and let's check out how it can be displayed to the auditor. You can find your session under the search menu. We have to wait for a bit and order the proxy to close the session. In the details view, you can find all the HTTP requests as performed, but without understanding the details is under the slideshow button.
These are the generated HTML pages from the simplified DOM content. [INAUDIBLE] back by the scripts, and with the Next and Previous buttons, you can walk through the whole session. Of course, later we want to make it more user-friendly and offer a similar experience than watching a video. In the near future, this feature goes into the product as an experimental feature. That means the code will be there, but you have to turn it on manually to use it.
Unite's code is experimental because the features that will be limited to the bare minimum in order to get feedback from you as soon as possible. The limited feature set will enable a couple of settings on the SPS user interface. For instance, a simplified group based access control, session persistence in audit trail files, publishing basic method information for the underlying database, back up, [INAUDIBLE] high functionality, just to name a few. Within 2021 Q1/Q2, there is this feature set.
Our next goal is the feature completeness, meaning this new proxy gets all the features that other proxies already got, including session initiation from [INAUDIBLE] for previous passwords in 2021 Q3, by the current plans. In the long run, we believe that web application auditing is a fundamental building block of our path to SAS direction. In cloud environments with scalable resources, we have opportunities to offer more functionality to control the features of the browsers and record the sessions in a more granular way.
This would also mean a different technological use because of the different architecture of cloud Infrastructure. This phase contains the most uncertainties today, but the planned time frame to go to the market is 2021 Q3/Q4. In the previous minutes, you've been learning about already from HTTP controlling to web application auditing. We believe the solution to reshape the way browser access is monitored, and it is the most important new feature we have introduced since [INAUDIBLE] joined the One Identity family.
It's a bleeding edge technology, so it will have a lot of rough edges at the beginning. If you want to participate and help us put in the finishing touches on it, then feel free to contact us. We are more than happy to hear your questions and opinion in this topic. Well, that's all for today. Thank you for your attention. Enjoy the rest of your day. Goodbye.
11:50