Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 6.0.1 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS) 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 Forwarding data to third-party systems Joining to One Identity Starling
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 RDP-specific settings SSH-specific settings Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Searching session data on a central node in a cluster Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) RPC API 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) Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help LDAP user and group resolution in SPS Appendix: Deprecated features

Querying trail content with the lucene-search function

Caution:

This function works only if you have enabled indexing for the audit trails.

The lucene_search function allows you to search the content of indexed audit trails for a specific keyword and return the IDs of the channels that contain the search keyword. The lucene_search function requires four parameters:

  • search phrase: The keyword or keyphrase you are looking for, for example, a command issued in an SSH session (exit). The keyphrase can contain the following special operators to be used & (AND), | (OR), ! (NOT). Brackets can be used to group parts of the keyphrase.

  • beginning_timestamp: The date in UNIX-timestamp format. Only audit trails created after this date will be queried.

  • ending_timestamp: The date in UNIX-timestamp format. Only audit trails created before this date will be queried.

For example:

select lucene_search
from lucene_search('root', 1287402232, 1318938150);
       
# Sample output:
(1,2,3,1)
(1 row)

The output of this query is a formatted as the following:

(<channel_id>,<trail_id>,<hits_count>,<rank>)

Alternatively, you can use the following query format that returns a header of the displayed columns, and uses the pipe (|) character for separator:

For example:

select * from lucene_search('tmp',1496885628,1496954028);
channel_id | trail_id | hits_count | rank
-----------------------------+-----
1    | 2    | 3    | 1
(1 row)

The output contains the following columns:

  • channel_id: The ID of the channel within the audit trail (an audit trail file can contain audit trails of multiple channels).

  • trail_id: Identifies the audit trail using the unique identifier of the session (the _connection_channel_id of the channel for which the audit trail was created).

  • hits_count: The number of hits in the audit trail.

  • rank: Shows the relevance of the search result on a 0-1 scale, where 1 is the most relevant. Note that on the SPS search page, this information is scaled to 0-5 (and shown graphically with stars).

For details on how to use more complex keyphrases, see the Apache Lucene documentation.

For details of content indexing, see Configuring the internal indexer.

Generating partial reports

The following describes how to generate a report manually for a period that has not been already covered in an automatic report.

Caution:

Generating a report that includes an Advanced statistics chapter that returns several thousands of entries requires significant CPU and memory resources from One Identity Safeguard for Privileged Sessions (SPS). While generating such a partial report, the web interface of SPS can become slow or unresponsive.

To generate a report manually for a period that has not been already covered in an automatic report

  1. Log in to the SPS web interface, and navigate to Reporting > Configuration.

    Figure 269: Reporting > Configuration — Configuring custom reports

  2. Select the report you want to generate.

  3. Click any of the following buttons:

    • To create a report from the last daily report till now, click Generate partial daily report. For example, if you click this button at 11:30 AM, the report will include the period from 00:01 to 11:30.

    • To create a report from the last weekly report till now, click Generate partial weekly report. For example, if you click this button on Wednesday at 11:30 AM, the report will include the period from Monday 00:01 to Wednesday 11:30.

    • To create a report from the last monthly report till now, click Generate partial monthly report. For example, if you click this button at 11:30 AM, December 13, the report will include the period from December 1, 00:01 to December 13, 11:30.

    The report will be automatically added in the list of reports (Reporting > Reports), and also sent in an e-mail to the regular recipients of the report.

  4. Click Commit.

Creating PCI DSS reports

To help you comply with the regulations of the Payment Card Industry Data Security Standard (PCI DSS), One Identity Safeguard for Privileged Sessions (SPS) can generate reports on the compliance status of SPS. Note that this is not a fully-featured compliance report: it is a tool to enhance and complement your compliance report by providing information available in SPS. The report corresponds with the document Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.0, published by the PCI Security Standards Council.

For details on the contents of the report, see Contents of PCI DSS reports.

To create PCI DSS reports

  1. Log in to the SPS web interface, and navigate to Reporting > PCI DSS.

    Figure 270: Reporting > PCI DSS — Generating PCI DSS reports

  1. By default, members of the report group can access the custom reports via the SPS web interface. To change this, enter the name of a different group into the Reports are accessible by the following groups field, or click to grant access to other groups.

    NOTE:

    Members of the listed groups will be able to access only these custom reports even if their groups does not have read access to the Reporting > Reports page. However, only those reports will be listed, to which their group has access to.

  2. By default, SPS sends out the reports in e-mail to the address set in the Basic Settings > Management > Mail settings > Send reports to field.

    NOTE:

    If this address is not set, the report is sent to the SPS administrator's e-mail address.

    • To disable e-mail sending, unselect the Send reports in e-mail option.

    • To e-mail the reports to a different address, select Recipient > Custom address, and enter the e-mail address where the reports should be sent. Click to list multiple e-mail addresses if needed.

  3. Click .

  1. Click Generate report.

    The report will be automatically added in the list of reports (Reporting > Reports), and also sent in an e-mail to the regular recipients of the report.

Contents of PCI DSS reports

To help you comply with the regulations of the Payment Card Industry Data Security Standard (PCI DSS), One Identity Safeguard for Privileged Sessions (SPS) can generate reports on the compliance status of SPS. Note that this is not a fully-featured compliance report: it is a tool to enhance and complement your compliance report by providing information available in SPS. The report corresponds with the document Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.0, published by the PCI Security Standards Council.

For details on creating PCI DSS reports, see Creating PCI DSS reports. The following table details the information included in the SPS PCI DSS reports, and the relevant PCI compliance requirement.

Table 31: Contents of PCI DSS reports
PCI DSS Requirement Compliance details
Requirement 1.1.6

Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.

The report lists the insecure connection policies configured in SPS, including SNMP server and agent settings, and the list of connection policies that permit unencrypted HTTP and Telnet. This list does not include any insecure connections that can be used to access SPS itself.
Requirement 2.1

Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP)community strings, etc.).

SPS can be accessed as "root" via the local management console, or - if explicitly enabled - remotely using a Secure Shell (SSH v2) connection. The report lists the local web user accounts that can access SPS. For details on configuring these accounts, see Managing One Identity Safeguard for Privileged Sessions (SPS) users locally.
Requirement 2.2.2

Enable only necessary services, protocols, daemons, etc., as required for the function of the system.

The report includes the list of services running on SPS.
Requirement 2.2.3

Implement additional security features for any required services, protocols, or daemons that are considered to be insecure, for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

The report lists the connection policies enabling unencrypted HTTP and Telnet access, and any such session that was active when the report was generated.
Requirement 2.3

Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Use HTTPS to connect to SPS. HTTP connections are forbidden.
Requirement 3.5.2

Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

  • Encrypted with a key-encrypting key that is at least as strong as the dataencrypting key, and that is stored separately from the data-encrypting key

  • Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device)

  • As at least two full-length key components or key shares, in accordance with an industry-accepted method

Note: It is not required that public keys be stored in one of these forms.

Audit trails are encrypted with AES128-GCM (audit trails recorded with SPS 5 F3 and earlier are encrypted with AES128-CBC). The master key is encrypted with the key you provided.
Requirement 5.1.2

For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.

SPS is an appliance running minimal services and using a hardened operating system. One Identity, the vendor of SPS, continuously monitors vulnerabilities and CVEs that might affect the components of SPS, and publishes security updates and announcements as needed. Using an up-to-date SPS version should keep the risk of SPS being affected by malicious software at a minimum level.
Requirement 6.2

Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

The report includes the firmware version running on SPS. You can check which is the latest version at the Downloads page.
Requirement 8.1.8

If a session has been idle for more than 15 minutes, require the user to reauthenticate to re-activate the terminal or session.

The report includes the timeout value to the SPS web interface (10 minutes by default). To change this value, see Web interface timeout.
Requirement 8.2.1

Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.

The report lists where SPS stores passwords, and the hash used to secure them.
Requirement 8.2.4

Change user passwords/passphrases at least every 90 days.

The report lists the password expiry settings of local web users of SPS, and also the last time the password of each user was changed. For details on configuring these accounts, see Managing One Identity Safeguard for Privileged Sessions (SPS) users locally. For details on configuring password expiry for these accounts, see Setting password policies for local users.
Requirement 8.2.5

Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.

The report includes the password history settings of local web users of SPS. For details on configuring password history for these accounts, see Setting password policies for local users.
Requirement 10.5.3

Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

The report lists the addresses of the logservers where SPS forwards its log messages. For details on forwarding log messages, see Configuring system logging.
Requirement 10.5.4

Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.

The report lists the security settings of the communication between SPS and the logservers where SPS forwards its log messages. For details on forwarding log messages, see Configuring system logging.
Requirement 10.7

Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

The retention time for local logs of SPS is seven days. To retain them longer, forward them to a remote logserver.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating