지금 지원 담당자와 채팅
지원 담당자와 채팅

One Identity Safeguard for Privileged Sessions 7.5 - 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 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 Cleaning up audit data Using plugins Forwarding data to third-party systems Starling integration
User management and access control
Login settings Managing One Identity Safeguard for Privileged Sessions (SPS) users locally Setting password policies for local users Managing local user groups Managing One Identity Safeguard for Privileged Sessions (SPS) users from an LDAP database Authenticating users to a RADIUS server Authenticating users with X.509 certificates Authenticating users with SAML2 Managing user rights and usergroups Creating rules for restricting access to search audit data Displaying the privileges of users and user groups Listing and searching configuration changes
Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing One Identity 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)
Network troubleshooting Gathering data about system problems Viewing logs on One Identity Safeguard for Privileged Sessions (SPS) Changing log verbosity level of One Identity Safeguard for Privileged Sessions (SPS) Collecting logs and system information for error reporting Collecting logs and system information of the boot process for error reporting Support hotfixes Status history and statistics Troubleshooting a One Identity Safeguard for Privileged Sessions (SPS) cluster Understanding One Identity Safeguard for Privileged Sessions (SPS) RAID status Restoring One Identity Safeguard for Privileged Sessions (SPS) configuration and data VNC is not working with TLS Configuring the IPMI from the BIOS after losing IPMI password Incomplete TSA response received Using UPN usernames in audited SSH connections
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

Audit trail downloads information on the Search interface

If you want to find out if the audit trail file of a relevant indexed session has already been downloaded (or you are interested in the details of the session's audit trail downloads), the Details tab will provide information.

Prerequisites

To log audit trail downloads of a certain connection, enable Log audit trail downloads in the Connections menu of the connection.

To display audit trail downloads information about the relevant indexed session

  1. Navigate to Sessions and find the relevant indexed session.
  2. Click and select the Details tab.

    Figure 282: Sessions > Details — The indexed session's available information displayed on the Details tab

    If no audit trail file has been downloaded for the relevant indexed session yet, the Details tab will display:

  3. If you want to download an audit trail file for the session, click Download audit trail. In this case, the displayed information will contain information about your current session.

    If a downloaded audit trail file already exists for the relevant indexed session, the Details tab will display similar information:

Displayed fields
  • Download date: The exact time when the user downloaded the audit trail file.
  • Username: The username that was used to download the audit trail file for the session.
  • IP address: The IP address from where the audit trail download was requested.
  • From API: Indicates if the audit trail file was downloaded through API or not.

Displaying statistics on search results

You can quickly sort and visualize the distribution of the sessions based on their various metadata, for example, username, server address, and so on.

To display statistics on search results

  1. Click the icon.

  2. Select the type of metadata you want to create statistics on from the Value distribution based on field, for example, select Username to display sessions based on username.

    Figure 283: Sessions — Displaying statistics

  3. To exclude items from the pie chart, click the icon next to the metadata you want to exclude.

    For example, if you want to exclude results by a user called testbot, select the icon next to the item.

    Figure 284: Sessions — Excluding items from the pie chart

    The pie chart now does not display results for the excluded item. The percentages always add up to 100%.

    You can continue to restrict or refine your search results and view statistics as required.

Analyzing data using One Identity Safeguard for Privileged Analytics

One Identity Safeguard for Privileged Sessions (SPS) integrates data from SPS to use as the basis of user behavior analysis. SPA uses machine learning algorithms to scrutinize behavioral characteristics (using data from SPS), and generates user behavior profiles for each individual privileged user. SPA compares actual user activity to user profiles in real time, with profiles being continually adjusted using machine learning. When SPA detects unusual activity, this is indicated on the user interface of SPS in the form of high scores and visualized insight.

Prerequisites

Make sure that you have session data from network traffic that:

  • contains real, unique usernames linked to users other than root/administrator or a shared account

    To check this, navigate to Sessions , and check whether the Username column contains data. This is important, because session data will be linked to users.

    If you do not have unique usernames in your session data, review your authentication settings and consult with the One Identity Professional Services team to learn about your options to tie accounts to users.

  • has commands extracted (using lightweight or full indexing, or in real-time through content policies)

    For instructions on how to configure indexing and include commands in the scope of indexing, see Indexing audit trails in the Administration Guide.

    For details on how to configure real-time command extraction using a content policy, see Creating a new content policy in the Administration Guide.

  • has keystrokes extracted (using lightweight or full indexing, or in real-time through content policies)

    The minimum required amount of data for reliable insight is 5 sessions with approximately 200 keystrokes each.

    For instructions on how to configure indexing and include typing biometrics in the scope of indexing, see Indexing audit trails in the Administration Guide.

    For details on how to configure real-time extraction of keystroke-related data using a content policy, see Creating a new content policy in the Administration Guide.

  • has pointing device (mouse) biometrics extracted (using lightweight or full indexing, or in real-time through content policies)

    For instructions on how to configure indexing and include pointing device biometrics in the scope of indexing, see Indexing audit trails in the Administration Guide.

    For details on how to configure real-time extraction of pointing device-related data using a content policy, see Creating a new content policy in the Administration Guide.

  • has window titles extracted (using lightweight or full indexing, or in real-time through content policies)

    For instructions on how to configure indexing and include window titles in the scope of indexing, see Indexing audit trails in the Administration Guide.

    For details on how to configure real-time window title extraction using a content policy, see Creating a new content policy in the Administration Guide.

The following describes how to analyze data using One Identity Safeguard for Privileged Analytics.

Limitations

SPS used in combination with SPA currently has the following limitations:

  • SPA requires at least 12GB RAM to operate. If you are interested in upgrading your appliance, contact our Support Team.

  • SPA requires a lot of computation, which can put pressure on SPS:

    • The keystroke algorithm is much more resource-hungry than the other algorithms, therefore our recommendation is to start analyzing data using the algorithms that require less resources.

    • Before you start using SPA, make sure that at least half the capacity of SPS is available.

  • SPA only analyzes audit trails and SPS metadata, it does not analyze log data.

To start using SPA

  1. Start getting scores.

    Scoring for sessions

    Scoring happens in real-time, meaning that as soon as new data (even data from an ongoing session) is available, SPA immediately scores it.

    TIP: When data is not immediately available to you and you are unable to wait until sufficient amount of data comes in from production traffic, you can resort to manually reindexing historical sessions. For details, see Reindex historical sessions in the Safeguard for Privileged Analytics Configuration Guide.

    Scores represent an aggregated amount. Session data is scored by multiple algorithms independent from each other. Scores given by individual algorithms are aggregated to create a single score.

    For detailed instructions on how to configure SPA, see Safeguard for Privileged Analytics Configuration Guide.

    Scoring for users

    The goal of the algorithm is to create a score for the user to represent recent activities. The algorithm does this by averaging recent event scores and weighing the top 3 highest scores and taking in consideration the elapsed time. The user score is calculated hourly and weighs more recent activities with a bias.

  2. Search for sessions with high scores.

    1. Go to Sessions .

      Sessions are displayed sorted by date. For ongoing sessions, the Search interface is updated in real-time to always show the most up-to-date information.

    2. In the Search query field, type analytics.score.aggregated: [80 TO 100], and click Search.

      A score between 80 and 100 indicates unusual user behavior.

      Figure 285: Searching for sessions with unusual user behavior using a search query

      Results that show sessions with high scores are displayed.

      Figure 286: Sessions with high scores — table view

      Figure 287: Sessions with high scores — card view

  3. Alternatively, search for scripted sessions.

    In the Search query field, type analytics.scripted:true, and click Search.

  4. View the details of a session.

    To view details of a session, click .

  5. View session analytics.

    Click the Analytics tab.

    The top of the page displays a summary of key insights about the session, such as:

    • The aggregated score (indicated by a gauge). The following color codes are used:

      • Scores between 80-100 indicate unusual behavior, their color code is red.

      • Scores between 70-79 indicate behavior that might require further analysis and attention, their color code is amber.

      • Scores between 0-69 indicate normal behavior, their color code is gray.

    • A one-sentence summary of each algorithm's verdict about the session and user behavior.

    The Anomalies found and Normal behavior sections of the page display detailed analyses provided by each of the configured algorithms. This includes short information on how a particular algorithm works and how to read the visualized insight, as well as scores given by the individual algorithms.

    Figure 288: Sessions — Viewing details on the Analytics tab: Anomalies found

    Figure 289: Sessions — Viewing details on the Analytics tab: Normal behavior

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 290: 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:

    indexerctl 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.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택