Considerations for the Implementation of Payment Application in a PCI-Compliant Environment

Remove Historical Sensitive Authentication Data (PA-DSS 1.1.4)

Sensitive Authentication Data (SAD) includes security-related information, including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks used to authenticate cardholders and/or authorize payment card transactions. See the Glossary of Terms, Abbreviations, and Acronyms in the PCI SSC for the definition of Sensitive Authentication Data

The previous versions of Oracle Hospitality Cruise SPMS stored SAD, including

7.30.x

Historical SAD stored by previous versions of Oracle Hospitality Cruise SPMS must be securely deleted and removal is absolutely necessary for PCI DSS compliance. Oracle Hospitality Cruise SPMS includes capabilities to securely delete historical SAD as follows:

When authorization response is received from Credit Card authorization server, the track data is automatically removed by the Credit Card Interface.

Handling of Sensitive Authentication Data (PA-DSS 1.1.5)

Oracle Hospitality Cruise SPMS store SAD. The following guideline must be followed when dealing with SAD used for pre-authorization (swipe data, validation values or codes, PIN or PIN block data):

Collect SAD only when needed to solve a specific problem
Store such data only in specific, known locations with limited access
Collect only the limited amount of data needed to solve a specific problem
Encrypt such data while stored
Securely delete such data immediately after use

Oracle Hospitality Cruise SPMS securely deletes Cardholder Data automatically by:

Removing Track Data automatically when initial Authorization is received from Credit Card provider. (It performs 4 pass clearing, first update it to ALL ‘0’, next all ‘1’, then ‘F’, finally the value set to NULL)
Authorization/settlement file is encrypted with PGP encryption. The file is handled by the user with care.
We do not perform memory clearance for cardholder data.

It is against Oracle Hospitality Cruise’s policy to collect any SAD (including any track data, card validation codes or PIN data) or Cardholder Data for any reason. Our troubleshooting processes do not require the collection of SAD or Cardholder Data, nor should it be accepted from a customer.

Secure Deletion of Cardholder Data (PA-DSS 2.1)

The following guidelines must be followed when dealing with Cardholder Data (Primary Account Number (PAN); Cardholder Name; Expiration Date; or Service Code):

A customer-defined retention period must be defined with a business justification.

Figure 2-1 ADPI Configuration Screen
Cardholder data exceeding the customer-defined retention period or when no longer required for legal, regulatory, or business purposes must be securely deleted.
Here are the locations of the cardholder data you must securely delete: SPMS Database Schema, CRD, CCA, CCT, POS table.
In order to remove the Credit Card related data from the database schema:
- Select ‘Credit Card Data’ – this option is to remove CRD, CCA, and CCT table’s data.
- Then, define the business operation justified retention period. After the purge process completes, Data is retained per the duration defined in the application.
To securely delete Cardholder Data, you must do the following:
Oracle Hospitality Cruise SPMS securely deletes Cardholder Data by:
- Removing Track data automatically when initial Authorization is received from Credit Card provider. (It perform 4 pass clearing, first update it to ALL’0’, next all ‘1’, then ‘F’, and finally the record is removed).
- Authorization/settlement file is encrypted with PGP encryption. The file is handled by the user with care.
- We do not perform memory clearance for cardholder data.
All underlying software (this includes operating systems and/or database systems) must be configured to prevent the inadvertent capture of PAN. Instructions for configuring the underlying operating systems and/or databases can be found in Appendix A.

All PAN is Masked by Default (PA-DSS 2.2)

Oracle Hospitality Cruise SPMS masks all PAN by default in all locations that displays PAN (screens, paper receipts, printouts, reports, etc.) by displaying only:

ALL but the last four digits of the PAN numbers is masked.

The payment application displays PAN in the following locations:

printed receipts — optional
all generated card reports in the reports menu; these include the following reports: customer invoice report with payment — optional
all PAN is masked by Default and, the PAN is controlled by access right.

Select wether your application displays full PAN or not and then update based on the functionality of your application. Below are the modules/screen to view the masked PAN.

Card Entry Screen (Manual and Swipe Entry) — Full PAN is displayed, which uses as verification against the credit card given on registration.
Invoice Payment Screen — Full PAN/Masked PAN
Quick Check-In Reservation Screen — Full PAN or Masked PAN
Pop-up message Guest Reservation Screen — Full PAN
Credit Card Authorization Screen — Full PAN/Masked PAN
Credit Card Settlement Screen — Full PAN/Masked PAN
Passenger Invoices Report (Final Statement Invoice, Detail Statement Invoice)
User Log File Output — Truncated to show Last four

Oracle Hospitality Cruise SPMS does not have the ability to display full PAN and this is controlled by the user access rights

Cardholder Data Encryption & Key Management (PA-DSS 2.3, 2.4 and 2.5)

Oracle Hospitality Cruise SPMS stores cardholder data and can output PAN data for storage outside of the payment application. All PAN must be rendered unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs. The payment application uses an encryption methodology with statically generated keys to automatically encrypt all locations/methods where cardholder data is stored.

A list of all locations where PAN can be output by the merchant includes:

Interface Log for debugging purposes — All PAN output is encrypted.

Note:
All PAN output by the merchant, to be stored in the merchant environment must be rendered unreadable using strong cryptographic methods.

The following key management activities must be performed per PCI DSS:

You must restrict access to encryption keys to the fewest number of custodians necessary.
You must store encryption keys securely in the fewest possible locations and forms.
Key custodians must sign the Key Custodian form provided in Appendix A to acknowledge that they understand and accept their key-custodian responsibilities.
Generation of strong cryptographic keys. The application uses AES 256 bit with SHA hashing.
Secure cryptographic key distribution. They key is not distributed outside the system.
DEK is stored in the database and encrypted using AES256.

KEK is stored in an IIS Server local disk file protected using DPAPI. The Client will communicate with the IIS Server using HTTPS and authenticates with a user login + password before it is allowed to retrieve the KEK.

Once the KEK is retrieved, it will store it in a local disk file protected with DPAPI. There is a hash of DEK store in DB: this is used to detect if the key has changed. Once the key is found to have changed, it will retrieve a new key from IIS again.

Cryptographic key changes for keys that have reached the end of their crypto period.
- The defined crypto period for each key type is
  - The key will expire after one year and is hard-coded.
- Oracle Hospitality Cruise SPMS enforces key changes at the end of the defined crypto period by
  - All applications will stop loading when the key is expired, except for the key changed application tool.
Retire or replace keys when the integrity of the key has been weakened and/or when known or suspected compromise. If retired or replaced cryptographic keys are retained, the application cannot use these keys for encryption operations. The key is destroyed upon change; the application does not keep a history of the key.
Manual clear-text cryptographic key-management procedures require split knowledge and dual control of keys.
- The following key types are manual clear-text cryptographic keys: None.
In order to enforce split knowledge and dual control, the key is split into two entries by two individuals.
1. One person is to enter first part of the Key in Passphrase 1 and confirm Passphrase 1.
2. Second person is to enter the key in Passphrase 2 and confirm Passphrase 2.
3. No one person knows the complete key.

Figure 2-2 Passphrase Input Field

This figure shows the Passphrase Input Field

Prevention of unauthorized substitution of cryptographic keys. DEK is protected with KEK using AES256. KEK is protected with DPAPI. Hash of DEK is stored in DB to prevent unauthorized modification.

The following is PGP key management functionality (PGP is an encryption program that provides cryptographic privacy and authentication for data communication).

The Public and Private PGP key is upload into database through the Oracle Hospitality Cruise SPMS program, and the key is encrypted with AES methodology before being stored in the database.
The physical Public and Private PGP key is deleted and removed from the local folder and recycling bin once the keys are uploaded into the database.

Removal of Historical Cryptographic Material (PA-DSS 2.6)

Oracle Hospitality Cruise SPMS has the following versions that previously encrypt the cardholder data:

7.30x

If the historical Cardholder data is no longer needed, the following must be completed to ensure it is PCI Compliant:
All cryptographic material for previous versions of the payment application (encryption keys and encrypted cardholder data) must be rendered irretrievable when no longer needed.
To render historical encryption keys and/or cryptograms irretrievable you must do the following to decrypt and re-encrypt the data with new encryption keys:
- Oracle Hospitality Cruise SPMS uses previously validated encryption algorithms that are PCI Compliant. Therefore, there is no need to render historical cryptographic keys or cryptograms irretrievable as they are still in use by the payment application.

Set up Strong Access Controls (PA-DSS 3.1 and 3.2)

The PCI DSS requires that access to all systems in the payment processing environment be protected through the use of unique users and complex passwords. Unique user accounts indicate that every account used is associated with an individual user and/or process with no use of generic group accounts used by more than one user or process.

The following roles and default accounts within the application have administrative access:

Internal Administrator Account for debugging purpose only

All authentication credentials are generated and managed by the application. Secure authentication is enforced automatically by the payment application for all credentials by the completion of the initial installation and for any subsequent changes (for example, any changes that result in user accounts reverting to default settings, any changes to existing account settings, or changes that generate new accounts or recreate existing accounts). To maintain PCI DSS compliance the following 11 points must be followed per the PCI DSS:

The payment application must not use or require the use of default administrative accounts for other necessary or required software (for example, database default administrative accounts) (PCI DSS 2.1 / PA-DSS 3.1.1)
The payment application must enforce the changing of all default application passwords for all accounts that are generated or managed by the application, by the completion of installation and for subsequent changes after the installation (this applies to all accounts, including user accounts, application and service accounts, and accounts used by Oracle Hospitality Cruise SPMS only for support purposes) (PCI DSS 2.1 / PA-DSS 3.1.2)
The payment application must assign unique IDs for all user accounts. (PCI DSS 8.1.1 / PA-DSS 3.1.3)
The payment application must provide at least one of the following three methods to authenticate users: (PCI DSS 8.2 / PA-DSS 3.1.4)
1. Something you know, such as a password or a passphrase.
2. Something you have, such as a token device or smart card.
3. Something you are, such as a biometric.
The payment application must NOT require or use any group, shared, or generic accounts and passwords (PCI DSS 8.5 / PA-DSS 3.1.5)
The payment application requires passwords to be at least seven characters and to include both numeric and alphabetic characters (PCI DSS 8.2.3 / PA-DSS 3.1.6)
The payment application requires passwords to be changed at least every 90 days (PCI DSS 8.2.4 / PA-DSS 3.1.7)
The payment application keeps password history and requires that a new password is different from any of the last four passwords used (PCI DSS 8.2.5 / PA-DSS 3.1.8)
The payment application limits repeated access attempts by locking out the user account after not more than six logon attempts (PCI DSS 8.1.6 / PA-DSS 3.1.9)
The payment application sets the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID. (PCI DSS 8.1.7 / PA-DSS 3.1.10)
The payment application requires the user to re-authenticate to re-activate the session if the application session has been idle for more than 15 minutes. (PCI DSS 8.1.8 / PA-DSS 3.1.11)

PCI Compliant Password in Oracle Hospitality Cruise Shipboard Property Management System

To comply with the PCI Data Security Standard, change your Oracle Hospitality Cruise SPMS’s Username and Password.

Navigate to the Utilities tab in the Launch Panel module.

Figure 2-3 Launch Panel Tabs
Double-click User Security to open the User Security program.
Click the Change Password to change the user password and then click Apply.

Figure 2-4 User Password Change Screen

You must assign a strong password to any default accounts (even if they will not be used), and then disable or do not use the accounts.

To ensure strict access control of the Oracle Hospitality Cruise SPMS application, always assign unique usernames and complex passwords to each account. Oracle Hospitality Cruise mandates applying these guidelines to not only program password but to Microsoft Windows operating system passwords as well. Furthermore, Oracle Hospitality Cruise advises users to control access, using unique usernames and PCI-Compliant complex passwords, to any PCs, servers, and databases with payment applications and cardholder data.

Creating Secure Password

To comply with PCI Data Security Standard, ensure the following options in the Oracle Hospitality Cruise SPMS program are configured as shown below:

Figure 2-5 Creating Secure Password

This figure shows Creating Secure Password

In the Oracle Hospitality Cruise SPMS program, Administrative module, from the main menu, navigate to Administration, System Setup, Database Parameters. Ensure these available options are configured per the following:

Ensure the Password History is at least four.
Ensure the Password Max Length is at least 14 characters.
Ensure the Password Min Age is one.
Ensure the Password Min Length is at least eight characters.
Ensure the Password Never Expires is zero (disabled).
Ensure the Password Require Char Lower is at least one character.
Ensure the Password Require Char Upper is at least one character.
Ensure the Password Require number is at least one number.
Ensure the Password Require spec char is at least one character.
Ensure the Password change every # days not greater than 90 days.
Ensure the Max Login is not greater than six.

Properly Train and Monitor Admin Personnel

It is your responsibility to institute proper personnel management techniques for allowing administrator user access to cardholder data, site data, and so on. You can control whether each individual administrator user can see credit card PAN (or only last four).

In most systems, a security breach is the result of unethical personnel. Pay special attention to whom you entrust your administration site to and who you allow to view full decrypted and unmasked payment information.

Log Settings Must be Compliant (PA-DSS 4.1.b and 4.4b)

4.1.b: Oracle Hospitality Cruise SPMS has PA-DSS compliant logging enabled by default. This logging is not configurable and may not be disabled.

Implement automated assessment trails for all system components to reconstruct the following events:

10.2.1 All individual user accesses to cardholder data from the application.
10.2.2 All actions taken by any individual with administrative privileges in the application.
10.2.3 Access to application audit trails managed by or within the application.
10.2.4 Invalid logical access attempts.
10.2.5 Use of the application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, and so on) and all changes, additions, and deletions to application accounts with root or administrative privileges.
10.2.6 Initialization, stopping, or pausing of the application audit logs.
10.2.7 Creation and deletion of system-level objects within or by the application record at least the following assessment trail entries for all system components for each event from 10.2.x above:

Record at least the following assessment trail entries for all system components for each event from the 10.2.x above:
10.3.1 User identification.
10.3.2 Type of event.
10.3.3 Date and time.
10.3.4 Success or failure indication.
10.3.5 Origination of event.
10.3.6 Identity or name of affected data, system component or resource.

Disabling or subverting the logging function of Oracle Hospitality Cruise SPMS in any way will result in non-compliance with PCI DSS. You can access logs by:

Oracle provides a comprehensive audit trail within SPMS that allows privileged users to track Oracle Hospitality Cruise specific activities. The open database structure allows anyone with system level access to access the database server (Oracle) and system components covered under this requirement, and thus would require logging of user access and activity. Oracle Hospitality Cruise strongly recommends logging of activity on the database server. The log accessibility depends on the user access right.

4.4.b: Oracle Hospitality Cruise SPMS facilitates centralized logging.

The Oracle Hospitality Cruise User Activity Log records a ‘history’ of user activity in the Oracle Hospitality Cruise SPMS database and is accessed using Security>User Logfile. This logs data related to credit card registration, authorization, settlement, batch authorization, batch settlement and other transactions. The log file can be exported to support the workstation’s format (for example, if the workstation is installed with Microsoft Office is able to export the file to the Office file format.

Figure 2-6 User Log File Screen

This figure shows the User Log File Screen

Lockout Duration Configuration (PCI DSS 8.1.6 / PA-DSS 3.1.9)

To comply with PCI Data Security Standard, ensure the following options in the Oracle Hospitality Cruise SPMS program are configured as shown below:

Figure 2-7 Lockout Duration

In the Oracle Hospitality Cruise SPMS program, Administrative module, from the main menu, navigate to Administration, System Setup, Database Parameters. Ensure these available options are configured as below:

Ensure the Lockout Minutes is 30
Ensure the Max Login at 6
Ensure the Idle Minutes is 15

Test Data and Accounts: (PA-DSS 5.1.2 & 5.1.3)

Oracle Hospitality Cruise removes all test data and test accounts before the application is released to customers. In addition, all custom payment application accounts, user ID’s and passwords are removed before the payment application is released to customers.

During a new/upgrade deployment, installer will run the PL/SQL script to remove all older test data from the database.