Get Live Help
You can now forward the log messages and events related to what happens in the privileged sessions to an external SIEM, such as Splunk or Arcsight, or other third-party systems that enable you to search, analyze, and visualize the forwarded data. SPS can send these events as industry-standard RFC3164 syslog messages, with the data formatted either as JSON or in Common Event Format (CEF).
For more information, see "Using the universal SIEM forwarder" in the Administration Guide.
SPS now provides a way to authenticate non-transparent HTTP/HTTPS connections on SPS to local and external backends (LDAP, Microsoft Active Directory, RADIUS). The client must support proxy authentication.
For more information, see "Creating a new HTTP authentication policy" in the Administration Guide.
To make the text displayed in graphical sessions (for example, RDP) SPS uses optical character recognition. The way this is done has been greatly optimized. Depending on the exact scenario and the contents of the session, this can significantly decrease the time required to index the audit trails.
The gapminder algorithm is able to detect scripted sessions based on the time gaps between the sessions that belong to a given account. When the time gaps between sessions have typical, repeating values, then that suggests unnatural periodic behavior.
You can now use an Authentication Policy with GSSAPI and a Usermapping Policy in SSH connections. When an SSH Connection Policy uses an Authentication Policy with GSSAPI, and a Usermapping Policy, then SPS stores the user principal as the Gateway username, and the username used on the target as the Server username.
Note that this change has the following side effect: when using an Authentication Policy with GSSAPI, earlier versions of SPS used the client-username@REALM username to authenticate on the target server. Starting with version 5.9.0, it uses the client-username as username. Configure your servers accordingly, or configure a Usermapping Policy for your SSH connections in SPS.