Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 6.11.1 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS)
The philosophy of One Identity Safeguard for Privileged Sessions (SPS) Policies Credential Stores Plugin framework Indexing Supported protocols and client applications Modes of operation Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) Archive and backup concepts Maximizing the scope of auditing IPv6 in One Identity Safeguard for Privileged Sessions (SPS) SSH host keys Authenticating clients using public-key authentication in SSH The gateway authentication process Four-eyes authorization Network interfaces High Availability support in One Identity Safeguard for Privileged Sessions (SPS) Versions and releases of One Identity Safeguard for Privileged Sessions (SPS) Accessing and configuring One Identity Safeguard for Privileged Sessions (SPS)
Cloud deployment considerations The Welcome Wizard and the first login Basic settings
Supported web browsers and operating systems The structure of the web interface Network settings Configuring date and time System logging, SNMP and e-mail alerts Configuring system monitoring on SPS Data and configuration backups Archiving and cleanup Using plugins Forwarding data to third-party systems Starling integration
User management and access control Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing Safeguard for Privileged Sessions (SPS) clusters Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster Upgrading One Identity Safeguard for Privileged Sessions (SPS) Managing the One Identity Safeguard for Privileged Sessions (SPS) license Accessing the One Identity Safeguard for Privileged Sessions (SPS) console Sealed mode Out-of-band management of One Identity Safeguard for Privileged Sessions (SPS) Managing the certificates used on One Identity Safeguard for Privileged Sessions (SPS)
General connection settings HTTP-specific settings ICA-specific settings MSSQL-specific settings RDP-specific settings SSH-specific settings Using Sudo with SPS Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) REST API One Identity Safeguard for Privileged Sessions (SPS) scenarios Troubleshooting One Identity Safeguard for Privileged Sessions (SPS) Using SPS with SPP Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help Configuring SPS to use an LDAP backend Glossary

The search and filter process

The screen content is first indexed, then processed with the search backend, and finally, the filter expressions are applied. This process is described in detail in the following sections.

Figure 284: The search and filter process

Prerequisites - Indexing phase

First, as a prerequisite of the search process, screen content is indexed. The indexing phase generates a database that the search and filter processes will run on.

The indexer parses the audit trail files, and builds an "inventory" of the privileged user's activity data based on what appeared on their screen.

  1. In the case of a terminal session, screen content corresponds to the activity data that is captured in a terminal window. In the case of graphical protocols, screen content is whatever is visible in the graphical user interface of the applications the user is interacting with. In the latter case, the indexer's Optical Character Recognition (OCR) engine extracts text that appeared on the screen (for example, window titles).

    NOTE: If a piece of text is displayed for less than 1 second, it is not extracted.

  2. The indexer returns the information extracted from the parsed audit trail files to One Identity Safeguard for Privileged Sessions (SPS). In the case of a terminal session, the captured text is put in the backend database as one document per one second of screen content. Because of this, the content that you have searched for might only partially appear in the screenshot. In the case of graphical protocols, the captured text is put in the backend database as one document per screenshot.

  3. The queries will be run on this database during the search process.

For details on indexing, see Indexing audit trails.

Search and filter process phases

The search and filter process consists of three major phases:

  • Query phase

  • Grouping phase

  • Filter phase

Query phase

In the query phase, the backend ranks and then limits the number of results.

  1. The result of one query is the top 3000 documents, ordered by the default ranking system of the backend.

    This means that if there are more than 3000 results, those of the lowest rank will not be passed to the next phase at all.

    The ranking system cannot be modified, so there is no way to "upvote" those results of lower ranks.

    If you want to ensure that all important results are passed to the grouping phase, use a smaller time range that you run the query on. If there are fewer than 3000 results, it is certain that the events you are interested in will be included in the grouping phase.

  2. The grouping phase receives the results.

Grouping phase

The grouping phase groups the results that were passed on from the query phase.

  1. First, the results with the same trail IDs are grouped together. A trail ID group contains all search hits that are in that trail.

  2. The trail ID groups are then further grouped by seach expression and time range. This group is essentially the time range during which the expression is displayed on the screen (for example, if the text root is displayed from 00:00:12 to 00:01:45, this will be one group).

  3. This grouped result is displayed in the search screen as one row.

Filter phase

The filter phase applies filter expressions to these grouped results.

NOTE: If there were screen content search results that were excluded during the query phase, the filter expressions will not be applied to them.

Example: Filtering for search results that were excluded in the query phase

For example, if you want to filter for Telnet connections where the text root was displayed, the following can happen:

You search for the Screen content: root. There are 3100 search results that consist of 3050 SSH connections and 50 Telnet connections. In this example, Telnet connections received the lowest ranks for some reason. 100 results that have received the lowest rank are excluded, and in this example it means all Telnet connections.

If you filter for protocol Telnet now, you will not see any results.

To remedy this situation, try searching in a smaller time range to make sure that there are less than 3000 search results. If you are unsure about the time range, you might want to attempt fine-tuning the backend search manually. For details, see: Fine-tuning the backend search manually.

Fine-tuning the backend search manually

You can fine-tune your search manually with the command line utility lucenectl. To do this, log on to the core shell. For details, see Accessing the One Identity Safeguard for Privileged Sessions (SPS) console.

  • Specify more exact time ranges (use Unix timestamps).

    For example, to limit the time range to Thursday, June 30, 2016 11:39:51 AM - Thursday, November 3, 2016 2:44:46 PM, enter the following command:

    lucenectl search --from-to 1467286791 1478184286 --text remote --limit 3000 --aggregate-by-trail --normalize-rank

    NOTE: For converting timestamps to Unix timestamp, use https://www.epochconverter.com/.

  • Increase the query limit of 3000 to a limit of your choice.

    For example, to increase the query limit of 3000 to 4500, enter the following command:

    lucenectl search --from-to 1467286791 1478184286 --text <your-screen-content-search-expression> --limit 4500 --aggregate-by-trail --normalize-rank
    lucenectl search --from-to 1467286791 1478184286 --text remote --limit 4500 --aggregate-by-trail --normalize-rank

    NOTE: If you do not receive more results with a larger query limit, it means that you have found all results with your search expression.

However, the downside of using lucenectl to fine-tune your search is that after the cli search, you have to manually extract the trails that you find interesting with the help of the metadb.

The following example shows the output of a lucenectl search:

{
 "hits": [
   {
     "hits_count": 1,
     "channel_id": 1,
     "trail_id": "58",
     "rank": 0.4068610216585047
   },
   {
     "hits_count": 7,
     "channel_id": 761,
     "trail_id": "12",
     "rank": 1.0
   },
   {
     "hits_count": 2,
     "channel_id": 1,
     "trail_id": "139",
     "rank": 0.5923645275802537
   }
 ]
}
  • rank: the larger the number, the higher the rank

  • hits_count: the number of times the screen content search expression is displayed in the audit trail

  • trail_id: the ID of the trail

  • channel_id: the ID of the channel

The most relevant audit trail will probably be the one with the highest rank.

If you have determined which audit trail you are interested in, enter the following command. The value of _connection_channel_id will be the value of the trail_id from the lucenectl output that you have determined as most relevant.

psql -U scb scb -c "select audit from channels where _connection_channel_id = 12;"

The output of this command will be:

/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:2
/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:1

From this output, the audit trail file name path is as follows: /<audittrailpath>/audit-scb_rdp-1467274538-0.zat

NOTE: If you cannot find the file at the path, check whether it has been archived and search for the file in the archive path. Use the following command:

psql -U scb scb -c "select audit, _archive_path  from channels where _connection_channel_id = 12;"

The output of this command will be:

                    audit                                | _archive_path
---------------------------------------------------------+---------------
/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:2 | /<myarchive/path>/
/<audittrailpath>/audit-scb_rdp-1467274538-0.zat:1 | /<myarchive/path>/
                                                         | 

If you still cannot find the audit trail, contact our Support Team.

Viewing session details

View the session details of each session for in-depth information on each of the indexed session stored in the connection database. You can use it to gain contextual insight about the indexed session and its events.

You can view session details for data recorded by:

Frequent Item Set (FIS) flow view visuals

Frequent Item Set (FIS) flow view visuals are also available on the Analytics tab. The FIS flow view is similar to the flow view analytics overview, except that the FIS flow view only displays data narrowed down to a single user's previous sessions in the analysis period (which is the previous 90 days by default). For more information, see Visualizing Frequent Item Sets on the FIS flow view.

Session tags

Session tags allow you to get basic information about the session and its contents at a glance.

Scripted session tag: One Identity Safeguard for Privileged Sessions (SPS) currently supports the scripted session tag. SPS uses One Identity Safeguard for Privileged Analytics to detect if sessions are generated using human interaction or automation. If sessions are generated using automation, SPS displays the scripted tag in the search interface as shown below:

  • Scripted sessions are shown on the main search screen.

    Figure 285: Scripted sessions — cards view

  • Scripted sessions are shown on the Overview tab.

    Figure 286: Scripted sessions — Overview tab

Viewing session details for data recorded by SPS

From the Search interface, you can view session details for data recorded by SPS. To view session details for data recorded by Safeguard for Privileged Passwords (SPP), see Viewing session details for data recorded by SPP.

The icon in the Search interface indicates that data was recorded by SPS. To search only for data recorded by SPS, enter origin:("RECORDING") in the Search query field.

To view session details, click the button in the last column of the relevant session.

Figure 287: Search — Accessing session details

Figure 288: SPS session details

The session details window provides details about the sessions on tabs.

Overview tab

The Overview tab is divided into the following main areas:

  • The Events area displays session events in chronological order.

    View the date and time of the event, the event type and event details. To filter events, use the Timeline tab.

  • The Score area shows the risk score that the Analytics Module assigned to the session. Ranges from 0 to 100, 100 is the highest risk score.
  • The Quick look area contains user information, for example, gateway and server username, start and end time of the session, and so on.

    The gateway username corresponds to the Username field of the connection metadata database, so note the following:

    • If the user performed inband gateway authentication in the connection, the field contains the username from the gateway authentication (gateway username).

    • Otherwise, the field contains the username used on the remote server.

  • The Interesting events area displays events selected as interesting, for example, a list of commands and window titles from the session that could be interesting from a security point of view.

    The list of interesting events is currently hard-coded and cannot be modified. For terminal sessions it includes commands such as chmod, ssh, shutdown, sudo, su, mount, adduser, addgroup. For graphical sessions, it contains window titles such as Management Console, Control Panel, Server Manager, PowerShell, Security Settings, Windows Security Center.

  • The Network area displays session information, for example, verdict, protocol, connection policy, client and server address.

Details tab

In addition to the Quick look, Interesting events, and Network screen areas, the Details tab provides monitoring information, audit trail downloads information, and channels information, too.

If there is a gateway authentication or authorization failure due to an AA plugin, the reason of the failure is displayed in the Deny reason field.

Timeline tab

On the Timeline of the Search interface, for data recorded by SPS, you can do the following:

  • View session events and alerts.

  • Search in the contents of the audit trail.

  • Watch the video of an audit trail from a selected event.

The Timeline tab replaces the now deprecated Events, Alerts, and Contents tabs.

Figure 289: Timeline tab

Events:

  • Session events in chronological order.

    You can narrow the event list by entering the event name in the Search in session field.

  • Date and time of the event.

  • Event type (command, screen content, window title).

  • Event details.

  • Screenshots.

Alerts:

  • Content policy alerts triggered in the session, in chronological order.

    You can narrow the alert list by entering the alert name in the Search in session field.

  • Date and time of the alert.

  • Alert details.

  • Screenshots.

Contents:

You can search in the contents of the audit trail using plain-text search. Searching using complex keyphrases is not supported from the Timeline tab.

Screenshots:

If screenshots are available for the session, you can click each event or alert to view the corresponding screenshot.

Screenshots are not available for:

  • Ongoing sessions.

  • Unindexed sessions.

  • Trails of HTTP sessions.

  • Encrypted trails (without the necessary certificate).

    If screenshots are encrypted, you have to upload the necessary encryption key to your keystore. For more information, see Viewing encrypted screenshots.

Analytics tab

If you use the One Identity Safeguard for Privileged Analytics, you can view detailed analyses provided by the configured algorithms. For more information, see Analyzing data using One Identity Safeguard for Privileged Analytics.

Managing active sessions

For information on how to follow and terminate active sessions, see section Following active sessions.

Viewing session details for data recorded by SPP

From the Search interface, you can view session details for data recorded by SPP. To view session details for data recorded by SPS, see Viewing session details for data recorded by SPS.

If you have linked your SPS to your SPP deployment, the icon in the Search interface indicates that data was recorded by SPP.

To search only for data recorded by SPP, enter origin:("VAULT") in the Search query field.

To view session details, click the button in the last column of the relevant session.

Figure 290: Search — Accessing session details

Figure 291: SPP session details

You can quickly visualize the session details in a timeline. To access the color legend for the timeline, click (Timeline Color Legend). Hovering your mouse over an event shows the position of that event in the timeline sidebar. It also shows the event as active.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating