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
-
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)
-
Center for Internet Security (CIS) Benchmarks (used for OS Hardening)
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
|
|||||||
Individual access to cardholder data is logged as follows:
|
||||||||
Components of the Payment Application |
The following application-vendor-developed components comprise 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:
|
||||||||
Required Third Party Payment Application Software |
The following are additional third-party payment application components required by the payment application: |
|||||||
Not Applicable |
||||||||
Supported Database Software |
The following are database management systems supported by the payment application: |
|||||||
The application utilizes Oracle 12c only |
||||||||
Other Required Third Party Software |
The following are other third-party software components required by the payment application: |
|||||||
Not applicable. |
||||||||
Supported Operating System(s) |
The following are Operating Systems supported or required by the payment application: |
|||||||
List Operating System(s) and versions/SP’s supported.
|
||||||||
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:
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>
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
Figure 1-3 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:
-
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