Remove Historical Sensitive Authentication Data
Handling of Sensitive Authentication Data
Secure Deletion of Cardholder Data
All PAN is masked by default
Cardholder Data Encryption & Key Management
Removal of Historical Cryptographic Material
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. Refer to the Glossary of Terms, Abbreviations, and Acronyms in the PCI SSC for the definition of Sensitive Authentication Data
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.
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 immedicately after use
Oracle Hospitality Cruise SPMS automatically securely deletes Cardholder Data by
Track Data is removed 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.
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.
Choose ‘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 as per duration defined in the application.
To securely delete Cardholder Data, you must do the following:
Oracle Hospitality Cruise SPMS securely deletes Cardholder Data by:
Track data is removed 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’, finally the record is removed).
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 but the last four digits of the PAN numbers is masked.
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.
Card Entry Screen (Manual and Swipe Entry) — Full PAN is displayed, which use 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 4
Oracle Hospitality Cruise SPMS do not have the ability to display full PAN and this is controlled by the user access right.
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.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 IIS Server local disk file protected using DPAPI, the Client will communicate with the IIS Server using HTTPS and authenticate with user login + password before it is allowed to retrieve the KEK.
The key will expire after 1 year and is hard-coded.
All application 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; we do not keep the history of 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.
One person is to enter first part of the Key in Passphrase 1 and confirm Passphrase 1.
Second person is to enter the key in Passphrase 2 and confirm Passphrase 2.
No one person knows the complete key.
Figure 2-2 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 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 stored into database.
The physical Public and Private PGP key is deleted and removed from the local folder and recycle bin once the keys are uploaded into the database.
7.30x
If the historical Cardholder data is no longer needed, the following must be completed to ensure it is PCI Compliance:
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 SOMS 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.
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.
Internal Administrator Account for debugging purpose only
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)
Something you know, such as a password or a passphrase.
Something you have, such as a token device or smart card.
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)
Navigate to Utilities tab in 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, via unique usernames and PCI-compliant complex passwords, to any PCs, servers, and databases with payment applications and cardholder data.
Figure 2-5 Creating Secure Password
Ensure the Password History is at least 4
Ensure the Password Max Length is at least 14 characters
Ensure the Password Min Age is 1
Ensure the Password Min Length is at least 8 characters
Ensure the Password Never Expires is 0 (disabled)
Ensure the Password Require Char Lower is at least 1 character
Ensure the Password Require Char Upper is at least 1 character
Ensure the Password Require number is at least 1 number
Ensure the Password Require spec char is at least 1 character
Ensure the Password change every # days not greater than 90 days
Ensure the Max Logins is not greater than 6
It is your responsibility to institute proper personnel management techniques for allowing administrator user access to cardholder data, site data, etc. You can control whether each individual administrator user can see credit card PAN (or only last 4).
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.
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.
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, etc.) and all changes, additions, 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 ecent 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 facilites 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 via Security>User Logfile. This logs data related to credit card registration, authorization, settlement, batch authorization, batch settlement and others transactions. The log file can be export to supported workstation’s format. (for example, if the workstation is installed with Microsoft Office will be able to export file to Office file format.
Figure 2-6 User Log File Screen
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:
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 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 (if we detected any created by the customer and we never supply test data for deployment).