1. SSF Implementation Guide
  2. Executive Summary

1 Executive Summary

Oracle Hospitality Cruise SPMS 23.1 has been Software Security Framework (SSF) validated, in accordance with SSF Version 1.1. For the SSF assessment, we worked with the following PCI SSC approved Secure Software Assessor:


This figure shows the Coalfire

This figure shows the Coalfire Address

This document also explains the Payment Card Industry (PCI) initiative and the Software Security Framework (SSF) 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 23.1 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 Application Summary

Table 1-1 Payment Application Summary

Software Name Oracle Hospitality Cruise SPMS Software version: 23.1

Application Product Category

Payment Application Functionality:

[ ] (01) POS Suite/General

[ ] (02) Payment Middleware

[ ] (03) Payment Gateway/Switch

[ ] (04) Payment Back Office

[ ] (05) POS Admin

[ ] (06) POS Specialized

[ ] (07) POS Kiosk

[x] (08) POS Face-to-Face/POI

[ ] (09) Shopping Cart / Store Front

[ ] (10) Card-Not-Present

[ ] (11) Automated Fuel Dispenser

[ ] (12) Payment Component

Software Function & Purpose

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.

Software Sales/Distribution/Licensing

The application is sold directly to customers. Integrators and resellers are not used.

Software Design Description

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.

Typical Software Implementation

Below are all the components of the application suite that could be installed in a typical merchant network environment:

  1. Management.exe – Main SPMS Guest Handling Module that records and manages the guest reservation details, posting, invoice and payment handling.

  2. 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.

  3. 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.

  4. Data Import.exe (flat file import module that allows importing of Guest/Crew data from a flat file including importing of credit card data.

  5. DGS Res Online.exe – This program interacts directly with RES Online at shoreside and writes the data to the database

  6. Credit Card Transfer.exe – Batch Credit Card Generation Interface that generates the Batch Authorization/Settlement file to various provider.

  7. Tools – A program used to upload the PGP key and, change/ update the database encryption key.

  8. ADPI – A program used to purge the data/transaction from the database.

Target Market for Payment Application (check all that apply)

[ ] Retail [ ] Processor [ ] 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:

  1. Every Card Registration is logged in the LOG Table under activity “GETCRD”.

  2. Whenever there is any modification on the card transactions. It is logged in the LOG table.

  3. Any access or modification to these tables through the application is logged by the table’s trigger in Oracle 19c 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: GCM

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.

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

  • Oracle Payment Interface (OPI)

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.

Hardware Platform Dependency

The following are additional third-party Hardware Platforms required by the software:

Not applicable.

Software Platform Dependency

The following are third-party Software Platforms required by the software:

Not Applicable.

Other Required Third Party Software

The following are other required third party software components required by the payment application:

Not applicable.

Description of Listing Versioning Methodology

SPMS versioning follows Oracle versioning methodology. It has three levels, Major, Minor, and patch/bug fix:

<Major>.<Minor>

  • Major Version is indicated with a Fiscal Year (Last two digits). For the year 2023. Major Version is 23.

  • Minor Version is indicated with Nth of release for the Year. If that is the first release for 2023, the minor version will be 1

Based on the above versioning methodology, the application version listed with the PCI SSC is: 23.1

Typical Network Implementation

Figure 1-1 Typical Network Implementation


This figure shows the 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 SSF Validation

As the software and payment application developer, our responsibility is to be “SSF validated”. We have performed an assessment and payment application validation review with our independent assessment firm to ensure that our platform conforms to industry best practices when handling, managing, and storing payment- related information.

SSF is the standard against which the Payment Application has been tested, assessed, and validated.

PCI Compliance is then later obtained by the merchant, and is an assessment of your actual server (or hosting) environment called the Cardholder Data Environment (CDE).

Obtaining “PCI Compliance” is the responsibility of you the merchant and your hosting provider, working together, using PCI compliant architecture with proper hardware & software configurations and access control procedures.

The SSF 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.

The 12 Requirements of the PCI DSS:

Build and Maintain a Secure Network and Systems

  1. Install and maintain a firewall configuration to protect cardholder data

  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. Protect all systems against malware and regularly update anti-virus software or programs

  6. Develop and maintain secure systems and applications

    Implement Strong Access Control Measures

  7. Restrict access to cardholder data by business need-to-know

  8. Identify and authenticate access to system components

  9. Restrict physical access to cardholder data

    Regularly Monitor and Test Networks

  10. Track and monitor all access to network resources and cardholder data

  11. Regularly test security systems and processes

    Maintain an Information Security Policy

  12. Maintain a policy that addresses information security for all personnel