Uptivity Security Overview

This topic provides an overview of Uptivity system topology, providing context for discussions about transport and file security. It also discusses basic and enhanced security features built into Uptivity.

Uptivity Design

Depending on the integration, Uptivity receives call audio from either the PBXClosedAn acronym for Private Branch Exchange. A telephone switching device owned by a private company that serves a particular business or office. or agent telephone. Call data comes from the PBX. Screen recording data is received from the agent’s PC over the LAN/WAN. All recording is done on one or more servers located at the customer's site(s).

The audio and screen recording files may be stored only on the recording server(s), or they can alternatively be stored there temporarily and later written to another server or file storage location based on schedules and available bandwidth. In this scenario, the local files are deleted after the recordings are moved. Long-term storage, or archiving, of recordings can be managed in a variety of ways, including variable retention periods and automated purging.

Database records for each recording are created in Uptivity for file and quality management purposes. These records let the files be located so that users with appropriate permissions can listen to and view the files via the NICE Uptivity Web Portal. The database can be housed on the recording server, on a separate server, or as an instance in an organization's SQL cluster.

Interactions between Uptivity components (for example, servers, Web Portal), file servers, and archive devices can be configured to use SSL.

If users are recorded from remote locations or access recordings from remote locations, it is recommended that a VPN be established to support PCI certification.

Appropriate physical and IT security measures must be used with any servers and workstations included in recording and storage of recording files and data. This is especially true in contact centers that are concerned with PCI compliance. Consider:

  • One or more Windows file servers may be used for storing recording files with cardholder data.
  • Servers, network attached storage devices, removable media, or other devices may be used in archiving recording files with cardholder data.
  • Screen Capture Servers may be used, resulting in video files that are stored in a different location from the associated audio files.

The accounts and passwords used to manage these devices and files should also comply with overall security measures. The following is recommended:

  • As a precaution, any account used to manage Uptivity system servers should be secured in order to prevent anyone from tampering with the system’s operations.
  • Uptivity uses a SQL database, as mentioned previously. For SQL servers, the following is recommended:
    • NT Authority\System for SQL Server Database Engine
    • NT Authority\Network Service for SQL Server Reporting Services
    • NT Authority\Local Service for SQL Server Browser

    Talk to your deployment engineer, or support team for more information.

  • When separate Screen Capture Servers are used, the system requires a UNC path for the recording storage location and a user account and password with Write permission for that location. This account should also be secured.

Access Control

Access to Uptivity configuration, certain features and functionality, and even recording files themselves, can all be limited through user roles and permissions. PermissionsClosedA type of setting that allows or restricts users’ access to information and functionality. Permissions are added to roles, then roles are assigned to users. that can be assigned to these rolesClosedA type of categorical setting that gives users access to the information and functionality they need based on permissions. Roles are assigned to users after permissions are added. are very granular, providing a great deal of flexibility in the way organizations implement the system.

Enhanced Security Features

Uptivity offers several enhanced security features, including blackouts and encryption. Manual blackout functionality is controlled by permissions. Encryption and automated blackouts are chargeable options.

If these were not originally included with your system, and you would like to add one or both features, consult your NICE Uptivity representative.

Secure Storage and Transport

Interactions between recording servers, NICE Uptivity Web Portal servers, file servers, and archive devices can use SSL (Secure Socket Layer) and TLS (Transport Layer Security) for data in transit. The use of SSL/TLS requires special configuration, and customers must obtain their own SSL certificate(s). NICE Uptivity and all related services are compatible with TLS 1.2.

For transport security to be effective, all communication starting and ending points should be secured. Bear in mind that SSL and TLS are all-or-nothing solutions. For example, if you enable SSL, TLS, or both, on the Screen Capture Server, but do not enable these features for the Screen Capture Clients, the clients and server will not be able to communicate.

If users are recorded or access recordings from remote locations, they must go through a VPN for this level of security.

TLS is typically used in conjunction with encryption (discussed in the previous section). The following table summarizes the impacts of encryption and TLS on an Uptivity system.

Encryption

TLS

Effects
On On All files stored in supported formats on disk are encrypted.

All live monitoring communications are encrypted.
On Off

All files stored in supported formats on disk are encrypted.

Live monitoring communications are not encrypted.
Off On

Files stored in supported formats on disk are not encrypted.

All live monitoring communications are encrypted.
Off Off

Files stored in supported formats on disk are not encrypted.

Live monitoring communications are not encrypted.

SSL Certificate Guidelines

The certificate you use must be one of these types of certificates:

  • An in-house certificate authority (CA) to create a certificate for the Web Portal IIS server.
    • This option requires an installation of the root certificate for the CA on all agent workstations.
    • The Certificate Request can be using IIS on App server, certreq.exe, or Openssl. Refer to the appropriate documentation for information about using these methods for a SAN certificate with your internal Certificate Authority (CA).
  • An intranet certificate from a vendor.
    • This option requires an installation of the vendor's root certificate on all agent workstations.
  • A self-signed certificate.
    • Certificate can be generated from within IIS. If you have a certificate scanner that creates self-signed certificates on the fly for HTTPS sites, add the following network exception URL: *. nice-incontact.com. A self-signed requires explicit "trusting" on all agent workstations. You must install the certificate into the Trusted root for all agent workstations.
  • A publicly-trusted wildcard certificate.
    • This option requires that you purchase a wildcard SSL certificate for the externally-facing web server, deploy that certificate to the Web Portal server, and ensure that the Web Portal server is accessible using the same root domain name as the externally-facing web server.
    • This option does not require any changes to agent workstations.

In addition, your certificate must meet these requirements: