# Genesys Quality Management Suite 8.1.520 : PCI DSS Compliance

Created and last modified by

This chapter describes PCI DSS Compliance and how each issue is addressed.

## PCI DSS Compliance Overview

PCI DSS (Payment Card Industry Data Security Standard) is a worldwide information security standard defined by the Payment Card Industry Security Standards Council, an organization founded by the key electronic payment providers including, American Express, Visa, Inc, and MasterCard Worldwide. The standard aims to reduce or prevent credit card fraud by requiring that organizations in the payment card industry implement increased controls around cardholder data, thereby minimizing its exposure to compromise.

Certification as “PCI DSS compliant” is mandatory for large numbers of organizations in the credit card payment industry; the standard applies to all organizations that hold, process, or exchange cardholder information from any card branded with the logo of one of the PCI SSC members.

Genesys Quality Management Suite 8.1.51x introduces full compliancy with the following relevant PCI DSS directives:

Control Objectives | PCI DSS Requirements | Genesys Quality Management Suite 8.1.51x
--- | --- | ---
Build and Maintain a Secure Network | 1. Install and maintain a firewall configuration to protect cardholder data. | N/A
| 2. Do not use vendor-supplied defaults for system passwords and other security parameters. |
Protect Cardholder Data | 3. Protect stored cardholder data. |
| 4. Encrypt transmission of cardholder data across open, public networks. |
Maintain a Vulnerability Management Program | 5. Use and regularly update anti-virus software on all systems commonly affected by malware. | N/A
| 6. Develop and maintain secure systems and applications. | (ongoing)
Implement Strong Access Control Measures | 7. Restrict access to cardholder data by business need-to-know. |
| 8. Assign a unique ID to each person with computer access. |
| 9. Restrict physical access to cardholder data. | N/A
Regularly Monitor and Test Networks | 10. Track and monitor all access to network resources and cardholder data. |
| 11. Regularly test security systems and processes. | N/A
Maintain an Information Security Policy | 12. Maintain a policy that addresses information security. | N/A

## Genesys Quality Management Suite PCI Compliance Checklist

The PCI Compliance Status screen is not visible in the Call Recording Web UI until a valid license including the PCI Compliance feature is uploaded and Call Recording is restarted.

Navigate to Settings > PCI Compliance to view the PC Compliance Overall Status.

Sections marked with mean that this feature already complies with PCI DSS recommendations.

Sections marked with mean that this feature does not comply with PCI DSS recommendations and that further steps must be taken.

Ensure that the Genesys Quality Management Suite license includes the PCI Compliance property, that enables the following features in Genesys Quality Management Suite:

- Key Manager, for managing server and client encryption keys.
- The PCI Compliance Status page, in the Call Recording Web UI at Settings > PCI Compliance Status, that displays if the Genesys Quality Management Suite features influencing PCI Compliancy are correctly configured within the Genesys Quality Management Suite installation.

The following sub-topics cover how to achieve compliancy for each requirement that displays on the PCI Compliance Status page.

## Vendor-Supplied Default Passwords Are Not Used

By default after installation, the first time the system administrator logs in to the Call Recording Web UI using the default login credentials, the administrator is required to change the administrator password.

Resolution: none required.

## Pause/Resume Functionality Is Enabled

This functionality is currently available via the Pause/Resume and RMI API for third party applications, see the Genesys Quality Management Suite Developer API Guide.

Resolution: None required.

## Key Manager Is Active and Keys Are Valid for no Longer than 12 Months

PCI-DSS Compliance requires the authenticated and encrypted transmission of data across networks (see Appendix A Encrypt Tool)– which includes between clients and servers in distributed systems like Genesys Quality Management Suite. One of the functions of the Key Manager is to manage this secure transmission, including automatic transparent renewal of authentication certificates when they expire.

Resolution: Install authentication and encryption certificates and activate Key Manager. See Activating Key Manager.

## Self-Signed or Commercial Certificates

For standard production environments, use commercially signed authentication certificates with Key Manager. “Commercial certificates” are authentication certificates that are signed by a trusted commercial CA (Certificate Authority, such as, Thawte or Verisign).

Self-signed certificates are quick to create; they can be created during Genesys Quality Management Suite setup by answering ‘yes’ to the query "Do you want to create a self-signed certificate and keys for Key Manager?" (see the Genesys Quality Management Suite Implementation Guide).

However, self-signed certificates are not as secure or trusted as commercial certificates, so they can provoke warnings and security errors, particularly when used with web technologies, see the SSL section in this Guide. Only use them for testing purposes.

## Key Manager in Cluster Installations

To comply with PCI DSS recommendations, in cluster installations Key Manager must only be enabled on one server. Typically Key Manager is deployed on the server that runs Call Recording Core. The Key Manager service in the Genesys Quality Management Suite is selected by default in the service list during setup so the Key Manager service must be deselected on all the other servers in the cluster.

The following security precautions must be taken:

- Remote access to the key store must not be possible.
- The directory where the keys are stored must be protected by file system permissions and should only be accessible for the Key Manager process and the Key Manager administrator.
- Keys for communication between Key Manager and Key Manager clients should be distributed using safe transport, for example, distributed physically on a USB stick or in a protected SSH session.

There is a tool for importing and exporting certificates into and out of the key store.

## Activating Key Manager

Activate Key Manager using the following procedure:

Either:

Opt to create self-signed certificates and keys during setup. These self-signed certificates are usually only used for test purposes during the set up of the system. They are not recommended for use in a working environment.

Or:

Opt to use a commercial certificate and keys. In this case, do not create self-signed certificates and keys during setup, but after setup is complete, manually set up Key Manager with a commercial certificate and keys (see the Installing Commercially Signed Certificates section of this guide).

### Enabling Encryption in Client Setup

Navigate to Settings > Configuration > Key Manager > Client Setup.

1. Select the Enabled checkbox in the Encryption section to enable Key Manager and call encryption.
2. Click Save configuration.

The Key Manager settings tab is not visible in the Call Recording Web UI until a valid license including the PCI Compliance feature is uploaded, certificates, self-signed or commercial, installed and Call Recording restarted using the `service callrec restart` command.

In both cases, the key validation expiration dates are determined when generating the server keys, using the keygen command line tool. In the case of self-signed certificates created during Genesys Quality Management Suite setup, an expiration date of 365 days is set (the maximum allowable period for PCI Compliance).

### Installing Commercially Signed Certificates

Commercially signed certificates are created and installed using the following process. It is assumed that a Certification Authority (CA) such as Thawte or Verisign is available to process certificate signing requests:

- Generate server, encoder and decoder private keys and certificates.
- Generate certificate signing request (.csr) files for each certificate and send these for signing to the CA.
- Install a root (trust) certificate for the CA if required.
- Install the signed certificates from the CA in the server authorization store and encoder & decoder trust and authorization stores.
- Generate Key Manager encryption keys.

## Installing Commercial Certificates for Key Manager

If self-signed certificates are installed, remove them before attempting to install commercial certificates as follows:

Log in as `admin`. Enter `su` - to log in as the root user. Enter the password, the default is `zoomcallrec`.

    rm -rf /opt/callrec/keys
    /opt/callrec/bin/rc.callrec_keymanager restart
    Stopping Call Recording Key Manager: ........... [ OK ]
    Starting Call Recording Key Manager: .... [ OK ]

### Create Keys Directory, Private Keys and Certificate Request Files

1. Copy the following commands into a text file named `/home/admin/genkeys1.sh`, then modify the `CERTIFICATES_PASS` and `CERTIFICATES_PROPERTIES` information regarding password and organization details respectively.

       #!/bin/sh
       # # Set up and create request files (.csr) for commercially signed
       # certificates for Key Manager
       # ZOOM International - Genesys Quality Management Suite 5.1.x
       #
       ####### Modify as required #######
       # Password for all certificate stores
       CERTIFICATES_PASS=callrec
       # Organizational details for certificates
       # [first and last name, organizational unit, organization, city or locality, # state or province, two-letter country code]
       CERTIFICATES_PROPERTIES="CN=Administrator, OU=Dept, O=Company, L=City, S=State, C=US"
       ##################################
       ######## Standard Call Recording defaults #######
       CALLREC_HOME=/opt/callrec
       ERR_FILE=/tmp/installcerts.err
       KEYTOOL=/usr/java/default/bin/keytool KEYS_DIR=$CALLREC_HOME/keys
       ENC_DIR=$KEYS_DIR/enc
       DEC_DIR=$KEYS_DIR/dec
       PWDS_FILE=$KEYS_DIR/pwds.properties
       ########################################## # Create Call Recording keys directory if it doesn't exist
       # Creating /opt/callrec/keys directory tree including pwds.properties files
       if [ ! -e $KEYS_DIR ] ; then
       mkdir -p $KEYS_DIR
       fi
       if [ ! -e $ENC_DIR ] ; then
       mkdir -p $ENC_DIR
       fi
       if [ ! -e $DEC_DIR ] ; then
       mkdir -p $DEC_DIR
       fi # Generating content of PWDS file
       echo "authpwd=$CERTIFICATES_PASS" > $PWDS_FILE
       echo "trustpwd=$CERTIFICATES_PASS" >> $PWDS_FILE
       echo "keystorepwd=$CERTIFICATES_PASS" >> $PWDS_FILE
       echo "keyentriespwd=$CERTIFICATES_PASS" >> $PWDS_FILE
       cp $PWDS_FILE $ENC_DIR
       cp $PWDS_FILE $DEC_DIR # Generating content of PWDS file
       echo "authpwd=$CERTIFICATES_PASS" > $PWDS_FILE
       echo "trustpwd=$CERTIFICATES_PASS" >> $PWDS_FILE
       echo "keystorepwd=$CERTIFICATES_PASS" >> $PWDS_FILE
       echo "keyentriespwd=$CERTIFICATES_PASS" >> $PWDS_FILE
       cp $PWDS_FILE $ENC_DIR 2>&1 >> $ERR_FILE
       cp $PWDS_FILE $DEC_DIR 2>&1 >> $ERR_FILE # Create private certificates for server and encoder, decoder clients,
       # then generate certificate signing request files (server.csr, encoder.csr, # decoder.csr) in the /home/admin directory
       # NOTE: To export existing certificates instead, replace the '-certreq' # parameter with '-exportcert', which will export a .cer type # certificate file, e.g. server.cer.
       # Server
       $KEYTOOL -genkeypair -alias server -keyalg rsa -keysize 2048 -validity 365 -keypass $CERTIFICATES_PASS -keystore $KEYS_DIR/.auth_keystore -storetype jks
       -storepass $CERTIFICATES_PASS -dname "$CERTIFICATES_PROPERTIES" 2>&1 >> $ERR_FILE $KEYTOOL -certreq -alias server -file /home/admin/server.csr -keystore $KEYS_DIR/.auth_keystore -storetype jks -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE # Encoder
       $KEYTOOL -genkeypair -alias encoder -keyalg rsa -keysize 2048 |
       -validity 365
       -keypass $CERTIFICATES_PASS -keystore $ENC_DIR/.auth_keystore -storetype jks -storepass $CERTIFICATES_PASS -dname "$CERTIFICATES_PROPERTIES" 2>&1 >> $ERR_FILE $KEYTOOL -certreq -alias encoder -file /home/admin/encoder.csr -keystore $ENC_DIR/.auth_keystore -storetype jks -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE # Decoder $KEYTOOL -genkeypair -alias decoder -keyalg rsa -keysize 2048 -validity 365 -keypass $CERTIFICATES_PASS -keystore $DEC_DIR/.auth_keystore -storetype jks -storepass $CERTIFICATES_PASS -dname "$CERTIFICATES_PROPERTIES" 2>&1 >> $ERR_FILE $KEYTOOL -certreq -alias decoder -file /home/admin/decoder.csr -keystore $DEC_DIR/.auth_keystore -storetype jks -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE # Set permissions
       # Changing key file ownership to callrec/callrec
       chown -R callrec:callrec $KEYS_DIR 2>&1 >> $ERR_FILE

2. Execute the following commands to run the file. Three ‘`.csr`’ certificate signing request files (`server.csr, encoder.csr, decoder.csr`) are created in the`/home/admin` directory.

       chmod 755 /home/admin/genkeys1.sh
       /home/admin/genkeys1.sh

   Obtain Signed Certificates

3. Send the three certificate request files in the /home/admin directory to the chosen Certificate Authority (CA) and receive signed certificate files in return, upload them also to the /home/admin directory and rename them, if necessary, to server.cer, encoder.cer, decoder.cer

4. [OPTIONAL] Install a CA certificate file if CA is not included in the cacerts Java keystore

5. Check for the existence of your CA in the cacerts keystore with the following command that lists all CA owner names (the default password is changeit):

       /usr/java/default/bin/keytool -list -v -keystore /usr/java/default/jre/lib/security/cacerts | grep "Owner:"

6. To install a CA certificate, first modify the -alias and -file parameters in the following command to reflect a suitable reference name and location of certificate file before running it for certificate installation:

       /usr/java/default/bin/keytool -importcert -alias myCA -file /home/admin/myCA.cer -keystore /usr/java/default/jre/lib/security/cacerts -storepass changeit

### Install Signed Certificates and Create Encryption/Decryption Certificates

1. Copy the following commands into a second text file named `/home/admin/genkeys2.sh`, then modify the `CERTIFICATES_PASS` to match the value used for it in the earlier `genkeys1.sh` script.

       #!/bin/sh
       # # Install signed certificates in Key Manager for encryption/decryption
       # ZOOM International - Genesys Quality Management Suite 5.1.x
       #
       ####### Modify as required #######
       # Password for all certificate stores
       CERTIFICATES_PASS=callrec
       ##################################
       ######## Standard Call Recording defaults #######
       CALLREC_HOME=/opt/callrec
       ERR_FILE=/tmp/installcerts.err
       KEYTOOL=/usr/java/default/bin/keytool
       KEYS_DIR=$CALLREC_HOME/keys
       ENC_DIR=$KEYS_DIR/enc
       DEC_DIR=$KEYS_DIR/dec
       PWDS_FILE=$KEYS_DIR/pwds.properties
       CACHED_CFG_SERVER_IP=localhost
       DEFAULT_PORT="30400"
       ##########################################
       # OPTIONAL: Import CA certificates (only required if CA is not included # in java CACERTS keystore)
       # View current CACERTS entries like this (default password: changeit)
       #/usr/java/default/bin/keytool -list -v -keystore #/usr/java/jdk1.6.0_35/jre/lib/security/cacerts | grep "Owner:"
       #
       # To install a CA certificate, uncomment the following line, and modify # the -alias and -file parameters to reflect a suitable reference name and # location of certificate file:
       #/usr/java/default/bin/keytool -importcert -alias myCA -file #/home/admin/myCA.cer -keystore /usr/java/jdk1.6.0_35/jre/lib/security/cacerts #-storepass changeit # Import signed cerficates recieved from your Certificate Authority (CA)
       # Assumes that certificates are named server.cer, encoder.cer, decoder.cer # in the /home/admin directory # Server
       $KEYTOOL -importcert -noprompt -trustcacerts -alias server -file /home/admin/server.cer -keystore $KEYS_DIR/.trust_keystore -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE # Encoder (assumes CACERT certificate file is at $KEYS_DIR/.auth.cer)
       $KEYTOOL -importcert -noprompt -trustcacerts -alias encoder -file /home/admin/encoder.cer -keystore $KEYS_DIR/.trust_keystore -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE $KEYTOOL -importcert -noprompt -trustcacerts -alias server -file /home/admin/server.cer -keystore $ENC_DIR/.trust_keystore -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE # Decoder (assumes CACERT certificate file is at $KEYS_DIR/.auth.cer) $KEYTOOL -importcert -noprompt -trustcacerts -alias decoder -file /home/admin/decoder.cer -keystore $KEYS_DIR/.trust_keystore -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE $KEYTOOL -importcert -noprompt -trustcacerts -alias server -file /home/admin/server.cer -keystore $DEC_DIR/.trust_keystore -storepass $CERTIFICATES_PASS 2>&1 >> $ERR_FILE # Set permissions
       # Changing key file ownership to callrec/callrec
       chown -R callrec:callrec $KEYS_DIR 2>&1 >> $ERR_FILE # Restart Key Manager
       /opt/callrec/bin/rc.callrec_keymanager restart # Create encryption/decryption keys using Genesys Quality Management Suite genkeys utility
       # Default activation date = today (or format: dd-mm-yyyy)
       ACTIVATION_DATE=`date "+%d.%m.%Y"`
       # Default expiration date = today + 365 days (or format: dd-mm-yyyy)
       EXPIRATION_DATE=`date -d "+365 days" "+%d.%m.%Y"`
       $CALLREC_HOME/bin/genkeys -activationDate $ACTIVATION_DATE -algorithm AES -expirationDate $EXPIRATION_DATE -purpose Audio -strength 128 -config "//$CACHED_CFG_SERVER_IP:$DEFAULT_PORT/pci_compliance" 2>&1 >> $ERR_FILE

2. Execute the following two commands to run the file. Note the output below the commands.

       chmod 755 /home/admin/genkeys2.sh
       /home/admin/genkeys2.sh

   If the certificate installation was successful the sample output should be similar to:

       Certificate was added to keystore
       Certificate was added to keystore
       Certificate was added to keystore
       Certificate was added to keystore
       Certificate was added to keystore
       0 [main] INFO cz.zoom.callrec.keyman.client.cmd.KeyGeneratorClient - Fetched remote KeyVaultAdmin
       287 [main] INFO cz.zoom.callrec.keyman.client.cmd.KeyGeneratorClient - Generated key, uuid=87639aff-716f-41f3-a304-47594125edfe, algorithm=AES, strength=128
       287 [main] INFO cz.zoom.callrec.keyman.client.cmd.KeyGeneratorClient - Key generation completed successfully

   Otherwise check the default error file at `/tmp/installcerts.err`.

1. Switch on call encryption in the Call Recording Web UI (see Client Encryption ).

2. Restart Key Manager.

       /opt/callrec/bin/rc.callrec_keymanager restart
       Stopping Call Recording Key Manager: ........... [ OK ]
       Starting Call Recording Key Manager: .. [ OK ]

   More information on keys, certificates and the Java keytool utility: Java SE keytool reference

### Troubleshooting Key Errors

- If call encryption has been enabled in the Call Recording Web UI, but calls are represented by a warning icon with the message Decoder error (IO failure), check the decoder error log at `/opt/callrec/logs/ds.error.log`.
- If an exception containing text similar to: cz.zoom.callrec.keyman.KeyVaultException: No key with these parameters can be found, there is an issue with the encryption keys, which is preventing the decoder from working. They should be reinstalled as follows:
  Remove the existing keys and certificates: `rm -f /opt/callrec/keys`

1. Stop Call Recording: `service callrec stop`.
2. Run Genesys Quality Management Suite setup again, selecting options to create self-signed certificates if required: `/opt/callrec/bin/callrec-setup`.
3. Follow the earlier instructions to install commercial certificates if required, and enable call encryption again.
4. If the same key errors occur repeatedly, contact Genesys Tech Support.

## Configuring Key Manager

After Key Manager is activated through the installation of authentication keys and certificates, navigate to Settings > Configuration > Key Manager > Server Setup.

### Server Setup

The Server Setup section contains the following parameters:

Database

Database pool: Should be set to callrec this is the default. Note that before version 8.1.520. Key Manager had its own pool.

Key Management

Password file location: The Key Manager server’s key/certificate password lookup file. Key Manager uses this to manage the key stores in the event of authentication/encryption key expiration & re-creation.

Keystore location: The server key store, containing media encryption keys.

Authentication keystore location: Key Manager’s authentication key store, containing the K.M. server’s own private authentication key(s).

Trust keystore location: Key Manager’s trust key store, containing public authentication keys of trusted clients (for example, encryption & decryption clients).

Auto re-encryption enabled: Encrypted files automatically re-encrypt when their certificates expire.

RMI

Port number: RMI port number used by Key Manager, typically 30401.

### Client Setup

Navigate to Settings > Configuration > Key Manager > Client Setup.

Select the Enabled checkbox to enable call and screen capture encryption.

The Client Setup section contains the following parameters:

Key Manager Server

Server: the Key Manager server (defined in Call Recording Core settings).

Encryption

Enabled: Enable call and screen capture encryption. This only functions after both the authentication keys and encryption keys are configured, as described earlier in this document.

Password file location: The encryption client key/certificate password lookup. The client uses this to manage the key stores, in the event authentication/encryption key expiry and re-creation.

Authentication keystore location: The encryption client authentication key store, containing the client’s own private authentication keys.

Trust keystore location: The encryption client trust key store, containing public authentication keys of the trusted servers.

Algorithm: The type of cipher used for encryption and decryption. AES as standard is used.

Purpose: Specify the key set to use for encryption and decryption. The key set’s purpose is defined during key creation (audio is default).

Minimum strength: The lowest strength cipher to use if the server does not support stronger algorithms.

Maximum strength: The preferred (default) strength, used if server and client both support it. On a single server default installation this should always be used.

Decryption

Password file location: The decryption client key/certificate password lookup. The client uses this to manage the key stores in the event of authentication/encryption key expiration and re-creation.

Authentication keystore location: The decryption client authentication key store, containing the client’s own private authentication keys.

## Audio Files Are Encrypted

Once Key Manager activates, audio encryption is enabled automatically.

Resolution: None required

## Video Files Are Encrypted

Once Key Manager activates, video (Screen Capture) encryption is enabled automatically.

Resolution: None required

## Web Access Is Encrypted

By default, the Tomcat web server installed and configured for the Call Recording Web UI and Quality Manager applications, does not have secure-socket layer (SSL) encryption enabled. This is a requirement for PCI Compliance. Instructions are given in the section Secure Web Access.

Resolution: Manual configuration of SSL security in the Tomcat web server.

## Audit Logs Are Collected

By default, audit logs are collected in Genesys Quality Management Suite Call Recording. Audit logs are available in the following directory:`/opt/callrec/logs`. They can also be viewed in the Call Recording Web UI. Similarly, the Quality Manager audit log can be viewed and exported in Excel format.

Resolution: None required

## Password Management Is Enforced

Genesys Quality Management Suite includes advanced password management facilities, that are initially switched off by default, this enables weak passwords to be used. These settings also dictate the settings for Quality Manager. Where integration with external systems is used, the external system dictates password settings for external users.

The following settings are required to be modified from the default values in order for passwords to be marked as PCI Compliant. These are modified in the Call Recording Web UI > Settings > Configuration > Web UI > Web Interface > Password configuration section.

- Minimum characters: at least 8
- Minimum capital characters: at least 1
- Minimum numbers: at least 1

See the screenshot for more details:

For more information on password configuration settings, see the User Interface Configuration section.

Resolution: update the Password configuration settings in Call Recording Web UI.

## Brute-Force Protection is Enforced

In addition to the minimum password configuration settings above, PCI Compliance also requires protection against brute-force attacks, when a hacker makes use of automated password generation techniques to repeatedly attempt entry.

To safeguard against these attacks, the following two settings in the Password configuration section are required to be active (they are PCI Compliant by default):

- Unsuccessful logins before lockout: 6 or under.
- Time for which account is blocked (minutes): 30 or more.

To change these settings, navigate to Call Recording Web UI > Settings > Configuration > Web UI > Web Interface > Password configuration.

Resolution: None required if default settings are kept

## Data Retention Policies Are Enforced

For full PCI Compliance, both the Archive and Delete media lifecycle management (MLM) tools need to be configured and operational. Both of these can be enabled and configured in the Maintenance section of Call Recording Settings, Call Recording Web UI > Settings > Configuration > Maintenance.

Sample settings for these tools are shown in the following screenshots. It is critical that settings are configured according to the MLM requirements.

### Archive Tool

Enable the Archive tool, including Daemon sleep period (sec.) and email settings, Subject, Send to email, Send success mails, or Send failure emails, then add an archive task, including the Interval period.

### Delete Tool

Enable the Delete tool including Daemon sleep period (sec.), set to a different value than for the Archive tool in this example, then add a delete task, and enable the type of media to delete and an Interval period for each.

Resolution: Enable and configure the Archive and Delete MLM tools in Call Recording Maintenance settings.

## Encrypt Tool

The encrypt tool, found at `/opt/callrec/bin/encrypt` on a default Call Recording server installation, is used to encrypt un-encrypted media files, or re-encrypt compromised media files (the encryption keys are no longer valid or safe).

There is an optional parameter `-r` that enables the re-encryption of encrypted files. If run without this parameter, the tool only encrypts non-encrypted files.

There is an optional parameter `-ids` that allows the user to specify which couples shall be encrypted by this tool. The list of IDs has to be separated by commas.
Parameter `-ids` can be combined with parameter `-date` to narrow down filtering criteria.
Parameter `-ids` cannot be combined with parameter `-r`.

There is an optional parameter `-threads` that allows the user to specify the number of threads used for parallel processing by the encrypt tool. The default value is 4. The values which are allowed 1-128. It should be set to the number of logical CPU cores -1, for example in case of Intel 6-Core CPU with HT enabled it should be set to 11.

### Parameters

`-config pci_compliance`: Mandatory parameter, that points to PCI compliance related parameters in the Configuration Service.

`-r`: Optional re-encryption mode parameter. If specified, only encrypted (compromised) files are re-encrypted, otherwise only non-encrypted files are encrypted.

`-date`: Optional parameter, that specifies a time window filter ('from' date and 'to' date) for files to encrypt. Date format: `hh/dd/mm/yyyy`. For example, `-date 23/04/05/2011 00/05/05/2011` would process all files created between 11pm on May 4th 2011 and midnight on May 5th 2011.
If no date is provided, the tool displays a message similar to the following:
`WARNING! No time range has been specified. Processing may take a while and can cause a significant load on the server.`

`-logger`: Optional parameter, that is provided with the path to a log4j properties file, for a customized debug log.

`-ids`: Optional parameter, that specifies a list of couple IDs which shall be encrypted. The list has to be separated by commas, spaces are not allowed. For example: `-ids 701,702,703` would encrypt files for couples with IDs 701, 702 and 703. This parameter cannot be used together with parameter `-r`.

`-threads`: Optional parameter, that specifies the number of threads used for parallel processing by the encrypt tool. Allowed values 1-128. For example: `-threads 8`. This parameter can be combined with all other parameters.

### Examples:

1. Encrypt all non-encrypted files:

       /opt/callrec/bin/encrypt -config pci_compliance -logger </path/to/log4j/properties/file>

2. Encrypt all non-encrypted files within the given 1-hour time window:

       /opt/callrec/bin/encrypt -config pci_compliance -date 20/04/05/2011 00/04/05/2011 -logger </path/to/log4j/properties/file>

3. Re-encrypt all encrypted files:

       /opt/callrec/bin/encrypt -config pci_compliance -r -logger </path/to/log4j/properties/file>

4. Re-encrypt all encrypted files with a compromised key in the given time window:

       /opt/callrec/bin/encrypt -config pci_compliance -r -date date1 date2 -logger </path/to/log4j/properties/file>

5. Encrypt files for selected couple IDs

       /opt/callrec/bin/encrypt -config pci_compliance -ids 701,702,703 -logger </path/to/log4j/properties/file>

6. Set number of threads used for parallel processing

       /opt/callrec/bin/encrypt -config pci_compliance -threads 11 -logger </path/to/log4j/properties/file>

### Switching On Debug Logs

If the default debug output of a Call Recording tool or script is not enough to pinpoint the cause of the error, switch on more granular error reporting. This process is similar for virtually any other component in the Genesys Quality Management Suite product, since all use the same ‘log4j’ logging API.

1. Create a log configuration file with the following content using vi or other text editor and save it as: `/opt/callrec/etc/mydebuglog.log4j.properties`, modify the`/var/log/callrec/mydebuglog.log` output log location as required:

       log4j.rootLogger=TRACE, file
       # file
       log4j.appender.file=org.apache.log4j.RollingFileAppender
       log4j.appender.file.MaxFileSize=2500MB
       log4j.appender.file.MaxBackupIndex=0
       log4j.appender.file.File=/var/log/callrec/mydebuglog.log
       log4j.appender.file.layout=org.apache.log4j.PatternLayout
       log4j.appender.file.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %-5p [%t] %c - %m\n

2. Run the tool or script, using the `logger` parameter to specify the location of the configuration file created.
   For example, the following is how the `encrypt` tool is given the `logger` parameter:

       /opt/callrec/bin/encrypt -logger /opt/callrec/etc/mydebuglog.log4j.properties

3. View the output log at the location specified and search for errors and exceptions in the detailed output:

       less /var/log/callrec/mydebuglog.log

## Password Storage in Genesys Quality Management Suite

To meet PCI DSS requirements for password storage, passwords are stored in the Call Recording database as follows:

- A unique password salt is created for each user and stored in the database.
- The user's password is hashed with the salt using approx. 1000 passes of the SHA-1 encryption algorithm.

This procedure provides protection against brute force and rainbow table attacks. See the references below for more information.

References:

- Wikipedia entry for cryptographic salts: http://en.wikipedia.org/wiki/Salt_(cryptography)
- Wikipedia entry for the SHA-1 cryptographic hash function: http://en.wikipedia.org/wiki/Sha-1
- Wikipedia entry for Brute Force attacks: http://en.wikipedia.org/wiki/Brute-force_attack
- Wikipedia entry for Rainbow Tables: http://en.wikipedia.org/wiki/Rainbow_table

## HTTPS Configuration

As a last step for PCI DSS Compliance please peform Secure Web Access for Call Recording and Quality Manager.