PrivX Product Update

In PrivX 33, we are delivering many new features as well as improvements to existing functionality.

This feature provides an ability to upgrade a PrivX high availability environment without service interruptions. This allows users to log in and connect to targets/hosts during the upgrade process. PrivX is running in maintenance mode restricting API functionality and some tasks until the upgrade finished. This will prevent problems during the database schema migrations. Zero downtime upgrade can be done from PrivX version 32 onwards. Upgrade can be done to later minor releases or the next major version. (for example, from PrivX 33.0 to 33.1 or 34.0)

If you want to upgrade over multiple major versions at once, e.g., from 33 to 35 it can be done with the old upgrade process (with downtime).

With the improvements in home UI, it is easier to present relevant information and that way help users to be more productive and aware of what is going on. 

The feed of recent activities can be filtered based on activity type:

• Alerts

• Connections

• Role requests

• Role approvals

Home UI provides easier access to favorites and documentation search. Elements visible on the right side of the home UI can be configured by the user (Service Status, Favorites, documentation and My Roles). The current version is an enabler for future development.

Sometimes solving problems requires more detailed logs to be delivered to support engineers. Previously changing debug level required restarting PrivX, so enabling more detailed logging required planning and proper timing to avoid service interruptions. Now the debug level can be changed per microservice from UI without restart.

In some environments, it is important to hide some roles to be visible to everyone when requesting roles through a built-in workflow engine. Especially in Operational technology environments where the ecosystem consists in addition to internal users also multiple external organizations (vendors, System Integrators, maintenance engineers, etc.) In version 33 it is possible to limit the visibility of the role to be requested. Users need to have a specific requester role to see certain roles in the role request form's drop-down menu. Those roles are not visible for users without the requester role. As an example in pictures user can see the db-access-role in the dropdown menu only if he has System Integrator A role.

PrivX integrates seamlessly with multiple Identity Management Systems using them as a user directory. With Microsoft Entra ID (formerly known as Azure AD) the integration is done through Microsoft Graph API. You can map directory user attributes (source) to PrivX user attributes (target). 

Supported source fields since PrivX 33 are: principal, mail, name, cn, givenName, sn, usageLocation, mailNickname, city, companyName, onPremisesSAMAccountName, onPremisesUserPrincipalName, onPremisesDistinguishedName, country, department, officeLocation, jobTitle, preferredLanguage, employeeId, mailNickname, employeeType, state.

In addition to these supported source fields, it is possible to define custom attributes. 

PrivX documentation has moved to a new documentation platform. The move is transparent for users. You may access the latest version of PrivX docs as usual at https://privx.docs.ssh.com. If you need to access older documentation versions, specify the version in the URL. For example, PrivX 29 at https://privx.docs.ssh.com/v29.

For more details about the PrivX 33 release, read the full release notes.

Data regarding Roles, Users, Hosts, and Network Targets can be exported in CSV or JSON format.

When configuring session recording for the hosts, it is possible to disable clipboard and file transfer recording. You may optionally omit clipboards and/or file transfers from recordings. This can be useful for example if such content contains sensitive information like user credentials. 

Connections to the target host can be initiated straight from the host configuration page. Useful e.g., for testing connections during host configuration.

When transferring large files or large amounts of files user can continue working on the terminal window or remote desktop while files are being uploaded. Visible notification is shown when the file transfer is finished.

Already in PrivX release 8, we introduced the feature that enabled PrivX to manage access to Web resources based on roles (RBAC) through an isolated browser. All sessions can be recorded and played back afterward. Audit events are stored in syslogs for further analysis. The most common use cases would be accessing critical web resources with shared accounts. These could be Admin consoles of network devices, admin portals to the company’s SaaS services, or internal Web tools (Salesforce, Twitter, LinkedIn, etc.).

PrivX extender supports UDP protocol in addition to TCP/IP. This is needed for example for making Network Target connections through the Extender with applications using proprietary protocols over UDP or mixture of TCP/IP and UDP.

PrivX can be configured to fetch cloud instances or hosts through cloud APIs. In addition to existing host directories VMWare vSphere is also supported:
•    AWS EC2 as a Host Directory
•    Google Cloud Platform as a Host Directory
•    Microsoft Azure
•    OpenStack
•    New: VMWare vSphere

For more details about the PrivX 32 release, read the full release notes.

This release is a maintenance release, focusing on improving the product quality and architecture. In addition to improving functionality and fixing bugs, we managed to include features for Certification Authority key rotation and adding tags to connection history as search criteria. Improvements and fixes are listed in the release notes.

PrivX Authorizer CA key rotation

Certain authentication methods such as certificate-based authentication require target-systems to be configured to trust PrivX as a Certification Authority (CA). For example, with Linux hosts, this may involve configuring Tectia or OpenSSH to trust the PrivX Certificate Authority. 
PrivX Authorizer creates the ephemeral certificates needed to access SSH and RDP target hosts via certificate authentication. Each access group is associated with a distinct authorizer CA key and a certificate used during authentication to target hosts. The CA key and certificate must be renewed before the certificate expires, or they need to be rotated regularly per company policies.

The rotation process involves the following steps:

• Create a new CA key in Administration→Access Groups→CA Key Details by choosing Renew CA Key

• Update the CA public key or certificate on all target hosts belonging to that access group (more on this below)

• Select the new CA key as the Primary CA Key in the Access Groups view

• Remove the old CA key once it is no longer used by any hosts

Target hosts using stored credentials for authentication are unaffected by CA key rotation.

Using tags in connection history

Keeping track of specific connections can be done by adding tags to connection information. Connections can be easily searched by using tags as search criteria.

For more details about the PrivX 31 release, read the full release notes.

This release includes functionality for Role-Based Access Control for Databases and improvements for using PrivX as an SSO solution (OIDC provider). In addition, features improving usability are also delivered.

Database access control

A long-waited-for feature for controlling access to Databases using native clients is finally available. Making Database connections using native DB-clients can now be controlled based on a user’s role. Access control works for interactive and scripted m2m/a2a connections.

Connecting to the target database

PrivX DB access supports PostgreSQL and MySQL wire protocols. For these connections, PrivX manages target database credentials. Access control for other DB-protocols, like Oracle database, can be done via Passthrough modes (TLS or Passthrough). In this case, access to the target database is granted based on the PrivX user's roles, but PrivX does not manage target database credentials.

Connection flow:

• User opens SSH tunnel to PrivX SSH bastion and connects DB client to target database through SSH tunnel via the DP-Proxy (SSH tunnel provides secure communications for unencrypted database protocols)

• PrivX SSH bastion forwards DB connections to DB-Proxy

• DB-Proxy grants/rejects connections based on the user's role

Monitoring and terminating connections

DB connection metadata is stored and displayed in PrivX UI, including Audit Evens. Connections can be terminated by admin if/when needed. Recorded protocol streams can be downloaded from PrivX UI in “hex” and “jsonl” format.

Summary of supported protocols

PrivX as OIDC Provider- Route https sessions through Carrier

PrivX can be used as a Single-Sign-On (SSO) solution for web applications, where it can be used as an OIDC Provider. In other words, it can perform user authentication and issue tokens/claims for accessing applications supporting OIDC-relying party functionality. Users can access web applications by login into PrivX. Application-specific login credentials are not needed. By default, the connections are not going through PrivX (no session recording) only the authentication is done with PrivX. From PrivX 30 onwards it is possible to route connections through the Carrier component. This enables the possibility to record the sessions.

As a summary for Web access:

• Directly to Web applications using their own browser without PrivX. Users log in as themselves and will take care of their personal credentials. Applicable for personal and work-related Web applications

• Using PrivX for SSO. Users log in as themselves. PrivX provides SSO authentication (OIDC). Web applications are configured to trust PrivX as Identity Provider. Actual https connections are not going through PrivX.

• PrivX provides SSO authentication (OIDC). Web applications are configured to trust PrivX as Identity Provider. Web applications are running in an isolated browser in PrivX Carrier. Actual https connection is going through PrivX. Sessions can be recorded.

• Existing OIDC solution can be used in conjunction and can provide SSO to PrivX (identity provider chain).

Chromium as an alternative Carrier browser

In PrivX 30, Chromium can be used as an alternative to Carrier Browser, supporting password injection through Chromium’s password manager.

For more details about the PrivX 30 release, read the full release notes.

This release includes a feature for enabling routing web connections through PrivX Extenders. In addition, features improving usability are also delivered.

Route web connections through Extenders

The basic use case for accessing web servers and routing traffic (HTTP/HTTPS/WS/WSS) via PrivX requires three components:

• PrivX core server
• PrivX Carrier
• PrivX Web Proxy

Previously the Carrier and Web Proxy components needed to be in same network where the Web Servers and applications were. In some environments it would have leaded to a situation where multiple Carrier and Web Proxy components needed to be deployed, thus raising infrastructure and maintenance costs.

​​Now Extender can be used to route web traffic to different networks. This allows using a single Carrier+Web Proxy setup to reach multiple VPN networks, reducing infrastructure costs and simplifying maintenance.

Easier configuration of disclaimers, headings, and watermarks

Configuring disclaimers, headings, and watermarks was done in JSON format. Now there is a better UI for doing it using text fields, checkboxes, etc.

PrivX login form is collapsible

When SSO functionality is taken into use, users do not need to enter their username and password to log into PrivX. Clicking the SSO button is enough. The login form can be now hidden by collapsing it. This helps users to focus on the SSO button instead of putting credentials to the login form. 
(Configuration through /opt/privx/etc/shared-config.toml)

“Secret” tab can be disabled

In some cases, there is no need to give users the possibility to manage user secrets. Access to that functionality can be disabled from PrivX settings.
(Configuration through /opt/privx/etc/shared-config.toml)

Admin tool

The admin tool is a command-line tool that can be accessed on the PrivX server. To use the tool, you must log in as root. Admin tool helps to recover from critical situations easier than before:

• Resetting password of local admin user (e.g., superuser)
• Resetting PrivX role context limitations 
  • If you lose admin access to PrivX due to misconfigured context limitations on critical roles

New keyboard layouts for PrivX web client connections

When making RDP, VNC or Https connections using browser it is possible to change the keyboard layout through connection settings. In addition to existing layouts Portuguese, Dutch and Romanian are supported now.

For more details about the PrivX 29 release, read the full release notes.

This release is a maintenance release, focusing on improving product quality and architecture. In addition to improving old functionality and fixing bugs, we managed to include a feature for improving audit-event-search performance using a trigram index. Details of the improvements and fixes are listed in the release notes.

Audit-Event Indexing for Faster Searches

This feature improves search performance, especially in large environments where the number of daily connections is hundreds of thousands or more.

Supported Releases and Upgrade Path

After this release, we will produce security and stability fixes for PrivX 28.x, 27.x, and 26.x. Older versions are not officially supported. We recommend you upgrade as soon as you can if you are running an unsupported version.

Upgrading to version 28 is supported by three previous major versions (27.x, 26.x, 25.x). For more information about upgrading from older versions see the full release notes.

For more details about the PrivX 28 release, read the full release notes.

This release delivers a bunch of new features and enhances existing ones: Passwordless login to PrivX UI using Passkey, Custom headings/watermarks to distinguish sessions, live monitoring for RDP/Web/VNC connections, viewing active users in PrivX UI, additional settings for auditing (performance optimization) and SSO support for PrivX as an IDP (OIDC provider).

Passkeys login (passkey authentication)

Passkeys login (using WebAuthn authentication) allows users to log into PrivX using a passkey (such as a fingerprint, Face ID, PIN, or YubiKey).

Passkeys are a safer and easier replacement for passwords. A passkey can replace a password and a second factor in a single step. The user experience can be as simple as auto-filling a password form. Passkeys provide robust protection against phishing attacks, unlike SMS or app-based one-time passwords. Since passkeys are standardized, a single implementation enables a passwordless experience across different browsers and operating systems.

WebAuthn authentication is supported on browsers such as Chrome, Safari, and Edge. Firefox is only supported on Windows 10. Note that the available authentication methods depend on the user's hardware (such as having the appropriate biometric readers) and operating system.

The feature can be enabled from PrivX settings.

Color heading and watermark in connections

When making connections to multiple targets and simultaneously working in different types of environments, e.g. development, testing, and production, it might be possible to lose traction in which environment you're working. Unintentionally you might make changes to the production environment instead of the test environment.

Enhanced real-time connection monitoring

For SSH connections, real-time monitoring was introduced in the previous release (PrivX 26). Now the real-time monitoring covers also RDP, VNC, and Web connections.

Show active users

PrivX admin can see users who are currently logged into PrivX. This is handy, for example, in situations when doing an upgrade or restarting PrivX after configuration changes.

Admin view can list user-specific events and connections (ongoing/history) and can terminate the user session (kick out the user from PrivX).

Settings for performance optimizations

The new exclusion list setting allows filtering audit events that are written to a database; normally, audit events are transferred to external systems like SIEMs/log collectors anyway. This way it is possible to optimize the database usage by excluding irrelevant ones. That's beneficial especially when running many M2M connections.

Data collected by PrivX is stored in multiple places. In order to save storage space, it is possible to configure retention policies for:

• Audit events (database)
• Connections Metadata (database)
• Trails (file system)

For trails, it is now possible to separate settings for Trail expiration and Trail transferred files expiration.

Single sign-on support for OIDC (provider)

When PrivX is used as OIDC Provider - in other words, using PrivX as an identity provider to perform user authentication and issue tokens/claims for accessing applications supporting OIDC-relying party functionality. Users can access web applications by logging into PrivX. Application-specific login credentials are not needed. Connections are not going through PrivX (no session recording).

Now PrivX users can authenticate to multiple websites, once they are logged into PrivX.

For more details about the PrivX 27 release, read the full release notes.

In this release, we are adding new features and improving existing ones. To highlight a few of them: More secure SSH connections with Post-Quantum Computing algorithms, automatic detection of anomalous connections (UEBA), live monitoring of SSH connections, and the possibility to use PrivX as an OIDC Provider.

Post-Quantum Computing Algorithms

Quantum computers already exist and their power is increasing. Soon, they will reach the point where classical cryptography is in danger.

With more sophisticated quantum computing technology, all data encrypted with classic encryption is vulnerable. Now is the time to start using Post-Quantum Computing algorithms. PrivX now supports new SSH KEX algorithms:

• ​​​​​​​ecdh-nistp521-kyber1024-sha512@ssh.com
• curve25519-frodokem1344-sha512@ssh.com
• sntrup761x25519-sha512@openssh.com

New algorithms are used, for example, in connections from PrivX to OpenSSH and Tectia Servers.

User and Entity Behavioral Analytics (UEBA)

Using machine learning it is possible to automatically detect suspicious behavior and take necessary actions. In the case of PrivX, it is possible to automatically detect anomalous connections, e.g. when connections are made from unusual source addresses or when they are made at unusual times. Data collected by PrivX is used for training the UEBA to distinguish normal and anomalous connections. Results are based on customers' own data used in training. UEBA focuses initially on connection metadata, enabling alerting/blocking anomalous connections.

​​​​​​​High-level steps for UEBA setup involve:

1. UEBA-server setup.
2. Training UEBA to distinguish normal/anomalous connections.
3. Configuring anomaly thresholds and behavior.

Real-time SSH Connection Monitoring

Sometimes it is mandatory to survey what is being done in real-time. Now it is possible to start live connection monitoring, for example, when third parties are making changes to critical systems, handling privacy-related files, a connection needs to be shared in training situations, etc.

PrivX as an OpenID Connect Provider

OpenID Connect is the de-facto standard for handling authentication in the modern world. The OIDC Provider performs user authentication, user consent, and token issuance. The client or service requesting a user’s identity is normally called the Relying Party (RP).

PrivX 2.4 (2018) introduced the Relying Party functionality, meaning that it has been possible to log into PrivX using a single-sign-on (SSO) solution which supported OpenID Connect Provider functionality. Such solutions are provided by e.g. Okta, Google, Sailpoint, Forgerock, etc.

Now, PrivX can also work as an OIDC Provider. In other words, it can perform user authentication and issue tokens/claims for accessing applications supporting OIDC-relying party functionality. Users can access web applications by logging into PrivX. Application-specific login credentials are not needed. Connections are not going through PrivX (no session recording).

In addition to the features described above:

• Additional container support for Web carrier: Firefox, Firefox Lite, Chromium Lite
• Hostname as a parameter to password-rotation scripts
• Utility for cleaning up old daily backups
  
  

We also made a bunch of improvements and bug fixes.

For more details about the PrivX 26 release, read the full release notes.

This release is mainly a housekeeping release, focusing on improving product quality and architecture. In addition to improving old functionality and fixing bugs, we included a feature for restricting the commands used in SSH sessions.

In general, when providing access to target systems whether they are servers, applications, etc., you should:

• Make sure that only the right persons have access to the right resources (this applies to non-human users as well)
• Make sure that they have the right level of access rights (Just-Enough-Access, JEA)
• Make sure that they have access only when it is needed (Just-In-Time, JIT)
• Automate processes to avoid human errors

By default, PrivX has been designed for this. When it comes to accessing critical systems it is important to control what users can do on target systems. The recommended way to control what users are allowed to execute on target hosts is to implement proper access control and separation of duties using target system user accounts, groups, file system permissions, and sudoer configurations.

​​​​​​​However, sometimes re-configuring the target server is not possible or - due to the temporary nature of the need for access - it is not feasible. In such cases, the SSH command restrictions feature can be used to restrict the commands a user is allowed to execute when connecting to the target host through PrivX. The feature can also be used when the execution of commands should not be restricted, but certain commands should trigger alerts. This can be achieved by forwarding audit events to an external SIEM system. Command restriction is done through white lists. When SSH command restrictions are set, users may only perform whitelisted commands.

Restricting SSH commands might sound like a simple task to do, but because of the nature of SSH connections, it is actually quite difficult. It is impossible to reliably distinguish shell commands from program input/output by only inspecting SSH connection (stdin/stdout/stderr streams). One way to do the command restriction/filtering is to use agent software on target systems. The agent could control what commands the shell can execute and what files it could open. The downside is that this requires target server reconfiguration and target server OS/CPU architecture-specific agent binary to be developed, installed, and maintained.

We wanted to avoid this kind of configuration and maintenance burden on target systems. We have found a way to do the command restrictions on the gateway level in a secure way (agentless) and applied a patent for the solution.

For more details about the PrivX 25 release, read the full release notes.

In this release we have improved PrivX functionality in multiple areas:

• Real-Time Auditing SSH Connections
• Login to PrivX with a JWT token from a trusted token provider
• Displays certificates configured in PrivX
• Import filter for SCIM directory
• ICAP antivirus checks for file transfers using SFTP

In some situations, it is important to get real-time visibility of the content inside the SSH connections. PrivX can be configured so that it will send SSH events to the audit log. Supported SSH event types to audit are stdin, stdout, stderr, channel_request, and global_request. Output can be then integrated into the SIEM system for automatic event handling. 

Users, whether they are human or non-human, can log into PrivX using multiple authentication methods (LDAP, Azure AD, OIDC, Public-Key, Client-Certificate, etc.).

In addition to the existing methods, it is possible to use an external identity provider to issue and exchange a PrivX access token with a trusted external JWT token.

This can be used especially in machine-to-machine connections.

Certificates have different life cycles, and it is important to renew the needed certificates before they expire. Now it is possible to display Certificates used by PrivX directly from the UI. This helps the admin to identify the certificates which are expired or to be expired soon.

Introduction

The main feature of this release is Password Rotation. This helps companies in their journey towards passwordless privileged access management. In addition to that, we have improved some of our existing features:

• Network Target Access was introduced in PrivX 22. Now it is also possible to establish network target sessions to the non-routable targets behind Extenders.
• File scanning with external systems using ICAP can be now done for SSH proxy and native SCP.
• Support for Microsoft Graph as a user directory has been added in this release.
• Additional operating systems supported for host-deployment scripts.
• UI improvements on the PrivX status page.

With PrivX, we have been always promoting certificate-based authentication when providing access to critical resources (see the whitepaper – From permanent credentials to ephemeral certificates).

We want to help companies on their journey to move gradually to passwordless and keyless environments. We also understand there will be always systems where certificate-based authentication cannot be applied, and the security policies require password rotation. We have now introduced the password rotation feature for Linux and Windows accounts. Functionality is built based on password rotation requirements of large banking environments.​​​​​​​

PrivX will automatically rotate passwords:

• Assign a new password to target accounts according to your password rotation policy.
• Automatically store and update the new password to the PrivX vault.

Password rotation policies define:

• How often passwords are rotated.
• The strength of automatically generated passwords.
• Fall-back behavior in case of failures in automation.

Password rotation scripts are Shell scripts, which PrivX runs to rotate passwords on target accounts. In addition to predefined scripts, it is possible to create custom scripts.

For more details about the PrivX 22 release, read the full release notes.