Executive Summary

1 Executive Summary

Oracle Hospitality Cruise SPMS 20.x has been Payment Application - Data Security Standard (PA-DSS) validated, in accordance with PA-DSS Version 3.2. For the PA-DSS assessment, we worked with the following PCI SSC approved Payment Application Qualified Security Assessor (PAQSA):

This document also explains the Payment Card Industry (PCI) initiative and the Payment Application Data Security Standard (PA-DSS) guidelines. The document also provides specific installation, configuration, and ongoing management best practices for using Oracle Hospitality Cruise SPMS only, Oracle Hospitality Cruise Shipboard Property Management System Version 20.x as a PA-DSS validated application operating in a PCI DSS compliant environment.

PCI Security Standards Council Reference Documents

The following documents provides additional details surrounding the PCI SSC and related security programs:

Payment Card Industry Payment Applications — Data Security Standard (PCI PA-DSS)

https://www.pcisecuritystandards.org/security_standards/index.php
Payment Card Industry Data Security Standard (PCI DSS)

https://www.pcisecuritystandards.org/security_standards/index.php
Open Web Application Security Project (OWASP)

http://www.owasp.org
Center for Internet Security (CIS) Benchmarks (used for OS Hardening)

https://benchmarks.cisecurity.org/downloads/multiform/

Payment Application Summary

Table 1-1 Payment Application Summary

Payment Application Name	Oracle Hospitality Cruise SPMS		Payment Application Version			20.x
Payment Application Description	Oracle Hospitality Cruise SPMS is a Cruise Property Management System that enables registration of the Guest/Crew payment type to its account. One of its supported payment types is by credit/debit card. To identify the type of Credit Card payment, you must read the card using a supported card swipe device that recognizes the card type from the Primary Account Number (PAN) number, or the information can be obtained directly from the card authorization processing system (EMV) when integrated with a third-party authorization system to provide batch authorization and settlement.
Typical Role of the Payment Application	Oracle Hospitality Cruise SPMS is a payment application used on a cruise ship for processing credit card transactions and handling authorization and settlement. The authorization and settlement are sent to the merchant for processing using an online or a batch file format through a secured communication.
Target Market for Payment Application (check all that apply)	☐	Retail	☐	Processors		☐	Gas/Oil
	☐	e-Commerce	☐	Small/medium merchants
	X	Others (please specify): Hospitality Cruise
Stored Cardholder Data	The following is a brief description of the files and tables that stores the cardholder data.
	File or Table Name				Description of Stored Cardholder Data
	CRD CCA CCT POS Authorization file Settlement file				The following Cardholder Data is stored Full PAN capture include track 1 + track 2 (Track 1 + Track 2 can be disabled by parameter) Full PAN shows on screen Full PAN will be encrypted before saving into database
	Individual access to cardholder data is logged as follows: Every Card Registration is logged in the LOG Table under activity “GETCRD”. Whenever there is any modification on the card transactions. It is logged in the LOG table. Any access or modification to these tables throught the application is logged by the table’s trigger in Oracle 12c database.
Components of the Payment Application	The following application-vendor-developed components comprise the payment application:
Components of the Payment Application	List all the components of the application suite that could be installed in a typical merchant network environment, and provide a short description of each component’s functionality. Examples: Management.exe – Main SPMS Guest Handling Module that records and manages the guest reservation details, posting, invoice and payment handling. Quick Check In.exe – A Quick embarkation check-in module that allows capturing of credit card payment data of the guest, as well as an overview of all other guest-related activities. Crew.exe – Main SPMS Crew Handling Module for Crew details management, posting, invoice and payment handling, as well as an overview of all other crew related activities. Data Import.exe (flat file import module that allows importing of Guest/Crew data from a flat file including importing of credit card data. DGS Res Online.exe – This program interacts directly with RES Online at shoreside and writes the data to the database Credit Card Transfer.exe – Batch Credit Card Generation Interface that generates the Batch Authorization/Settlement file to various provider. Tools – A program used to upload the PGP key and, change/update the database encryption key. ADPI – A program used to purge the data/transaction from the database.
Required Third Party Payment Application Software	The following are additional third-party payment application components required by the payment application:
Required Third Party Payment Application Software	Not Applicable
Supported Database Software	The following are database management systems supported by the payment application:
Supported Database Software	The application utilizes Oracle 12c only
Other Required Third Party Software	The following are other third-party software components required by the payment application:
Other Required Third Party Software	Not applicable.
Supported Operating System(s)	The following are Operating Systems supported or required by the payment application:
Supported Operating System(s)	List Operating System(s) and versions/SP’s supported. Windows 10
Payment Application Authentication	The application uses PBKDF method to apply pseudorandom function and hashes the user password using random SALT along with the hash value stored in the database.
Payment Application Encryption	Define here the payment application’s encryption methodology, including key management, encryption used, encryption strength, data storage security and others, including encryption, access controls, truncation, and so on. Encryption Method: AES Encryption Method Key: SHA256 Hash Key Management: DEK stored in the database is encrypted using AES256. KEK is stored in the IIS Server local disk file and is protected using DPAPI. The user communicates with the IIS Server using a HTTPS protocol and authenticates with the user login + password before it is allowed to retrieve the KEK. Once the KEK is retrieved, it is stored in the local disk file protected with DPAPI. There is a hash of DEK store in DB, this is used to detect if the key had changed. Once the key changes, it will retrieve the new key from IIS again. Encryption Length: 256bits Padding method: PKCS7 Mode: CBC BlockSize: 128 Note: When the encryption key is due to expire in 14 days, the system prompts a warning to the user to change the encryption key using Tools.
Supported Payment Application Functionality	☐	Automated Fuel Dispenser	☐	POS Kiosk		☐		Payment Gateway/ Switch
	☐	Card-Not-Present	☐	POS Specialized		☐		Payment Middleware
	☐	POS Admin	☐	POS Suite/General		☐		Payment Module
	☒	POS Face-to-Face/POI	☐	Payment Back Office		☐		Shopping Card & Store Front
Payment Processing Connections	Under online scenario: Initial Authorization is captured during Credit Card registration. The card is inserted into the card reader (normally provided by payment processor). If the authorization is successful, a valid token or reference details with approval code details are returned to SPMS. This token or cc reference will be stored and used for subsequent request of incremental authorization for the same card. The same token/ref is used for settlement at a later stage. Currently supported payment processors are: Servebase/PXP Paypoint Ingenico Under batch authorization scenario: Initial authorizations are generated using the Credit Card Transfer after Credit Card registration. The response authorization file from the merchant is read using the Credit Card Transfer. This response file corresponds to the initial authorization request to approve or decline the transaction. Posting is performed in the Management module. If the posting amount is less than the initial authorization amount, no incremental authorization is required, or else the authorization is generated using the Credit Card Transfer. Once the settlement completes in the Management module, a settlement authorization transaction can be generated using the Credit Card Transfer module. The authorization file is encrypted with PGP encryption. The Authorization File is handled by the user with care to transmit to the merchant accordingly. The response file given by merchant is encrypted with PGP encryption as well. SPMS program will decrypt the response file using the PGP encryption, and insert into SPMS.
Description of Listing Versioning Methodology	Oracle Hospitality Cruise SPMS versioning follows Oracle versioning methodology. It has four levels, Major, Minor, Patch and Build: <Major>.<Minor>.<Patch> .<Build Number> Major Version indicates Fiscal Year (Last two digits). For year 2020, Major Version to be 20. Minor Version indicates Nth of release for this Year. If that is the first release for 2020, minor version will be 1. Minor Version will be represented as wildcard x. Changes at this level will not affect PA-DSS requirements or the security of the application indicated by PA-DSS. Patch Version only deploy to address production bug fixes. Patch version will be represented as wildcard x. Changes at this level will not affect PA-DSS requirements or the security of the application indicated by PA-DSS. Build number is changed on every internal compile for testing/deployment. Every single compile has a unique build number for every version and not customer facing. Based on the above versioning methodology, the application version listed with the PCI SSC is: 20.x

Typical Network Implementation

Figure 1-1 Typical Network Implementation

Figure 1-2 Credit/Debit Cardholder Dataflow Diagram

This figure shows the Credit/Debit Cardholder Dataflow Diagram

Figure 1-3 Paypoint Credit Card Functional Flow Chart

This figure shows the Paypoint Credit Card Functional Flow Chart

Difference between PCI Compliance and PA-DSS Validation

As the software and payment application developer, our responsibility is to be PA-DSS validated. We have tested, assessed, and validated the payment application against PA-DSS Version 3.2 with our independent assessment firm (PAQSA) to ensure that our platform conforms to industry best practices when handling, managing, and storing payment-related information.

The PA-DSS Validation is intended to ensure that Oracle Hospitality Cruise SPMS will help you facilitate and maintain PCI Compliance with respect to how the payment application handles user accounts, passwords, encryption, and other payment data related information.

The Payment Card Industry (PCI) has developed security standards for handling cardholder information in a published standard called the PCI Data Security Standard (DSS). The security requirements defined in the DSS apply to all members, merchants, and service providers that store, process, or transmit cardholder data.

The PCI DSS requirements apply to all system components within the payment application environment, which is defined as any network device, host, or application, included in, or connected to, a network segment where cardholder data is stored, processed or transmitted.

PCI Compliance is an assessment of your actual server (or hosting) environment called the Cardholder Data Environment (CDE). It is the responsibility of you, as the merchant, and your hosting provider to work together to use PCI compliant architecture with proper hardware and software configurations and access control procedures.

The 12 Requirements of the PCI DSS:

Build and Maintain a Secure Network and Systems

Install and maintain a firewall configuration to protect cardholder data
Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data
Protect stored cardholder data
Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program
Protect all systems against malware and regularly update anti-virus software or programs
Develop and maintain secure systems and applications

Implement Strong Access Control Measures
Restrict access to cardholder data by business need-to-know
Identify and authenticate access to system components
Restrict physical access to cardholder data

Regularly Monitor and Test Networks
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes

Maintain an Information Security Policy
Maintain a policy that addresses information security for all personnel