One Identity Safeguard for Privileged Sessions 6.0.5 - Administration Guide

Application areas

Fastest return to value and extremely low TCO

One Identity Safeguard for Privileged Sessions (SPS) is a turnkey network appliance - its implementation and configuration is fast and simple. Compared to competitors, there is no need to purchase and install any additional software (for example, Windows or MS SQL servers) or hardware to have SPS fully functioning. Full implementation typically takes only 3-5 days! No need for long and costly professional services for implementation and customization. After deployment, SPS operates in the background like a black box of an airplane - there is no need for any extra workload to operate it.

Independent, agentless device

Compared to agent-based solutions, there is no need for installing and updating agents on clients or servers, eliminating unnecessary maintenance and potential security issues. As a host independent gateway, SPS can control and monitor access to any type of systems incl. all Windows/UNIX/Linux servers, mainframes, network devices, security devices, web-based applications or thin client environments, such as VMware Horizon View (formerly known as VMware View), Citrix Virtual Apps (formerly known as Citrix XenApp) or Citrix Virtual Desktops (formerly known as Citrix XenDesktop).

Transparent, “router-like” operation

As a proxy gateway, SPS can operate as a router in the network – invisible to the user and to the server. As a transparent solution, SPS requires minimal changes to the existing network. Also, since it operates on the network level, users can keep using the client applications they are familiar with, and do not have to change their work processes, unlike jump host solutions.

Granular access control

Since SPS has full access to the inspected traffic, security managers can granularly control who can access what and when on the servers. For example, they can selectively permit or deny access to protocol channels: enable terminal sessions in SSH, but disable port-forwarding and file transfers, or enable desktop access for RDP, but disable file sharing. In addition, SPS supports real-time shadowing allowing an authorizer to follow the administrator's session in real-time and terminate his/her connection in case of detecting a policy violation.

Real-time prevention of malicious activities

SPS can monitor transferred content in real time and can send alerts or even block connections if a certain pattern is detected in the traffic. Predefined patterns can be a risky command in a text-oriented protocol or a suspicious application in a graphical connection. This command and application level policy can prevent malicious user activities as they happen instead of just recording or reporting them.

Industry-leading session recording and auditing

SPS is the leading session auditing solution on the market offering Optical Character Recognition (OCR) capabilities to log ALL data about privileged actions in graphical user interfaces as well as text-based protocols. SPS can support and audit file transfers, as well. All data is recorded into searchable movie-like audit trails, making it easy to find relevant information in forensics or troubleshooting situations. In case of any problems (server misconfiguration, database manipulation, unexpected shutdown), the circumstances of the event are readily available in the audit trails, thus the cause of the incident can be easily identified. Auditors can do free-text searches in the content of text-based and graphical sessions. They can search for EVERY events (for example, mouse clicks, pressing Enter) and texts seen by the user.

To protect the sensitive information included in the communication, the two directions of the traffic (client-server and server-client) can be separated and encrypted with different keys, thus sensitive information like passwords are displayed only when necessary.

The concepts of One Identity Safeguard for Privileged Sessions (SPS)

This section discusses the technical concepts of One Identity Safeguard for Privileged Sessions (SPS).

The philosophy of One Identity Safeguard for Privileged Sessions (SPS)

One Identity Safeguard for Privileged Sessions (SPS) is a device that examines network traffic at the application level, that is, Layer 7 or the application layer of the OSI model. All communication must conform to the standards of the respective protocol. SPS examines Secure Shell (SSH, including forwarded X11 traffic), Secure Copy (SCP), SSH File Transfer Protocol (SFTP), Remote Desktop (RDP), HTTP, Independent Computing Architecture (Citrix ICA), Telnet, VMware Horizon View, and VNC connections, ignoring and simply forwarding all other types of traffic. SPS uses man-in-the-middle techniques to decrypt and terminate (when necessary) the inspected connections. It separates the connections into two parts (client — SPS, SPS — server) and inspects all traffic, so that no data can be directly transferred between the server and the client.

Figure 1: Inspecting SSH traffic with SPS

SPS has full control over the initial negotiation phase of the connection, when the client and the server decide the parameters of the encryption to be used in the communication. SPS can restrict the use of the various algorithms, forbidding the use of weak ones — an effective shield against downgrade attacks.

Since SPS isolates the client-server connection into two separate connections, the permitted algorithms can be different on the client and the server side.

SPS controls the connections right from the beginning — including user authentication. That way it is easy to mandate strong authentication for protocols where user information is available (for example, SSH), because SPS can limit the allowed authentication methods and also the users permitted to access the servers.

SPS uses various policies to restrict who, when, and how can access a connection or a specific channel of the protocol. These policies (based on username, authentication method used, and so on) can be applied to connections between particular clients and servers, or also to specific channels of a connection (for example, only to terminal-sessions in SSH, or desktop-sharing in RDP).

Figure 2: Controlling protocol channels

SPS is configured by an administrator or auditor using a web browser.

Policies

One Identity Safeguard for Privileged Sessions (SPS) controls access to connections through a set of policies. Policies let you specify various parameters of a connection, and so define the types of connections that SPS should monitor and restrict access to. When a connection request reaches SPS, SPS compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. The first connection policy completely matching the connection request is applied to the connection.

Figure 3: Processing policies

This section provides a brief definition of each policy type and also explains the hierarchy between them.

A connection policy allows you to specify details of the connection between a particular client and server that you want to restrict in any way. In addition to setting basic details (such as the source and destination addresses), or more advanced ones (such as authentication to SPS or the server), the connection policy also references other policies that allow you to define further specifics of the connections you wish to control.

Depending on the protocol, the connection policy may also allow you to configure:

• A Credential Store that allows users auto logon to the target server.

  For information on Credential Stores, see Credential Stores.

• A plugin that allows integration with external systems, which users can be optionally authenticated to (before authenticating to the target server).

  For information on plugins, see Plugin framework.

For details on configuring connection policies, see Configuring connections.

A channel policy serves to control channel usage (for example, terminal session and Secure Copy in SSH, or drawing and clipboard in RDP) within a given connection. It lists channels that are allowed within a connection, and it also lets you specify restriction rules based on user lists, user groups, or the IP address of the client or server. You can also reference a content policy and a time policy within the channel policy, and it is also within the channel policy that you enable auditing for a specific channel.

For details on configuring channel policies, see Creating and editing channel policies.

A content policy lets you log an event, send an alert, or terminate a connection if a particular command or text (that you specify in the policy) appears in the command line or on the screen.

For details on creating a content policy, see Creating a new content policy.

A time policy specifies the timeframe when users are permitted to access a particular channel and so restricts the availability of that channel.

For details on configuring time policies, see Configuring time policies.

An audit policy enables you to prevent the manipulation of audit trails files that store the recorded activities of privileged users by providing you with options to encrypt, timestamp, and sign these files.

For details on creating audit policies, see Audit policies.

An authentication policy defines those client-side and server-side authentication methods that can be used in a connection.

For details on creating authentication policies, see Authentication Policies.

An LDAP policy lets you set details of the LDAP server to which you wish to authenticate users of the connections you are controlling.

For details on creating an LDAP policy, see Authenticating users to an LDAP server.

A usermapping policy specifies the usernames that are allowed access to the remote server and the user groups that are allowed to use the specified username.

For details on configuring usermapping policies, see Configuring usermapping policies.

An archiving policy lets you configure details of the archiving process that enables you to archive connection-related data and audit trails. You can configure, for example, the target server where archived files are to be stored, or the directory structure in which to organize your archived files.

For details on creating archiving policies, see Archiving and cleanup.

A backup policy defines the address of the backup server where you can back up connection data, the protocol to use to access it, details of authenticating to the backup server, and so on.

For details on creating backup policies, see Data and configuration backups.

An analytics policy lets you specify the analytics that you wish to run for specific sessions, and also determine the weight that scores given by the selected analytics should have in the final aggregated score.

For details on configuring analytics policies, see "Configure analytics" in the Safeguard for Privileged Analytics Configuration Guide.

Figure 4: Policies of SPS