4 Services and Protocols (PA-DSS 8.2.c)

The application must only use or require the use of necessary and secure e-services, protocols, daemons, and components. PCI requires that you list all required protocols, services and dependent software and hardware that are necessary for any functionality of the payment application, including those provided by third parties.

Oracle Hospitality Cruise SPMS does not require the use of any insecure services or protocols. Here are the services and protocols that Oracle Hospitality Cruise SPMS does require:

TLS1.1/TLS1.2 — Depending on IIS configuration by customer site.

HTTPS — Used in Web Service

Never Store Cardholder Data on Internet-Accessible Systems (PA-DSS 9.1.c)

Never store cardholder data on Internet-accessible systems (for example, the web server and database server must not be on the same server).

PCI-Compliant Remote Access (PA-DSS 10.1)

The PCI standard requires that if employees, administrators, or vendors are granted remote access to the payment processing environment, access should be authenticated using a two-factor authentication mechanism. The means two of the following three authentication methods must be used:
  1. Something you know, such as a password or passphrase — user id/password for remote access.
  2. Something you have, such as token device or smart card — Token Device.
  3. Something you are, such as biometric — Not used.

PCI-Compliant Delivery of Updates (PA-DSS 7.2.3, 10.2.1.a)

  • How you communicate the availability of new patches and updates to customers.

  • Normally, email notification is sent to the customer.

  • Timely development and deployment of patches and updates. Patches are delivered in an average of twice a year.

  • Delivery in a secure manner with a known chain-of-trust. Customers are required to download patches themselves from MOS: https://support.oracle.com/

  • Delivery in a manner that maintains the integrity of the deliverable MOS.

  • Integrity testing of the patch or update by the target system prior to installation: There is a small tool program written to make sure all modules/interfaces are compiled correctly and no zero (0) size assembly is detected. As a development company, Oracle keeps abreast of the relevant security concerns and vulnerabilities in areas of development and expertise.

Oracle does this by using a Code Scanning Tool such as Fortify, doing code review, and extensive testing by QA team.

Once Oracle identifies a relevant vulnerability, the company works to develop and test a patch that helps protect Oracle Hospitality Cruise SPMS against the specific or new vulnerability. Oracle attempts to publish a patch within 30 days of the identification of the vulnerability and contact vendors and dealers to encourage them to install the patch. Typically, merchants are expected to respond quickly to and install available patches within 30 days.

We do not deliver software and/or updates by way of remote access to customer networks. Instead, software and updates are available by uploading them onto approved Oracle Automatic Release Update.

My Oracle Support employs the following security controls:

  • My Oracle Support is an HTTPS extranet website service using Secure Socket Layer (SSL) encryption.

  • Your registration on My Oracle Support uses a unique Customer Support Identifier (CSI) linked to your Support contract(s).

  • Delivery in a manner that maintains the integrity of the deliverable. When a patch is downloaded from My Oracle Support’s Automated Release Updates (ARU) page, the patch’s digital signature should be verified. This is a relatively simple manual process. There are several free file integrity validation tools available on the web that can verify the Message Digest 5 (MD5) or Secure Hash Algorithm (SHA-1) checksum for the downloaded patch file. You can use a tool like the Microsoft File Checksum Integrity Verifier, or a similar MD5 and SHA-1 checksum utility. Choose and download the validation tool that you want to use. Once a patch is downloaded, run your file integrity validation tool against it and compare the hash value generated by the validation tool to the hash value that corresponds to the patch on the ARU page. Both hash values should exactly match each other to confirm the file’s integrity. Once you have validated the patch file integrity, deploy the patch as soon as possible.

PCI-Compliant Remote Access (PA-DSS 10.3.2.a)

The PCI standard requires that if employees, administrators, or vendors are granted remote access to the payment processing environment; access should be authenticated using a two-factor authentication mechanism (username/ password and an additional authentication item such as a token or certificate),

In the case of vendor remote access accounts, in addition to the standard access controls, vendor accounts should only be active while access is required to provide service. Access rights should include only the access rights required for the service rendered, and should be robustly audited.

If users and hosts within the payment application environment may need to use third-party remote access software such as Remote Desktop (RDP)/Terminal Server and so on to access other hosts within the payment processing environment, special care must be taken.

In order to be compliant, every such session must be encrypted with at least 128-bit encryption (in addition to satisfying the requirement for two-factor authentication required for users connecting from outside the payment processing environment). For <RDP/Terminal Services> this means using the high encryption setting on the server, and for <PCAnywhere> it means using symmetric or public key options for encryption. Additionally, the PCI user account and password requirements will apply to these access methods as well.

When requesting support from a vendor, reseller, or integrator, customers are advised to take the following precautions:

  • Change default settings (such as usernames and passwords) on remote access software (for example, VNC)

  • Allow connections only from specific IP and/or MAC addresses.

  • Use strong authentication and complex passwords for logins according to PA-DSS 3.1.1 – 3.1.10 and PCI DSS 8.1, 8.3, and 8.5.8-8.5.15.

  • Enable encrypted data transmission according to PA-DSS 12.1 and PCI DSS 4.1.

  • Enable account lockouts after a certain number of failed login attempts according to PA-DSS 3.1.8 and PCI DSS 8.5.13.

  • Require that remote access takes place over a VPN throught a firewall as opposed to allowing connections directly from the internet.

  • Enable logging for auditing purposes.

  • Restrict access to customer passwords to authorized reseller/integrator personnel.

  • Establish customer passwords according to PA-DSS 3.1.1 – 3.1.10 and PCI DSS Requirements 8.1, 8.2, 8.4, and 8.5.

Data Transport Encryption (PA-DSS 11.1.b)

The PCI DSS requires the use of strong cryptography and encryption techniques with at least a 128-bit encryption strength (either at the transport layer with TLS or IPSEC; or at the data layer with algorithms such as RSA or Triple-DES) to safeguard cardholder data during transmission over public networks (this includes the Internet and the Internet accessible DMZ network segments).

PCI DSS Requirement 4.1: Use strong cryptography and security protocols such as transport layer security (TLS 1.1/TLS 1.2) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.

Examples of open, public networks that are in scope of the PCI DSS are:

  • The Internet

  • Wireless technologies

  • Global System for Mobile Communications (GSM)

  • General Packet Radio Service (GPRS)

See Credit/Debit Cardholder Dataflow Diagram in Typical Network Implementation for an understanding of the flow of encrypted data associated with Oracle Hospitality Cruise SPMS.

PCI-Compliant Use of End User Messaging Technologies (PA-DSS 11.2.b)

Oracle Hospitality Cruise SPMS does not allow or facilitate the sending of a Primary Account Number (PAN) from any end user messaging technology (for example, e-mail, instant messaging, and chat).

Non-Console Administration and Multi-Factor Authentication (PA-DSS 12.1,12.2)

Although Oracle Hospitality Cruise SPMS does not support non-console administration and we do not recommend using non-console administration, should you ever choose to do this, you must use SSH, VPN, or TLS 1.1 or higher for encryption of this non-console administrative access along with a multi-factor authentication solution.

Network Segmentation

The PCI DSS requires that firewall services be used (with NAT or PAT) to segment network segments into logical security domains based on the environmental needs for internet access. Traditionally, this corresponds to the creation of at least a DMZ and a trusted network segment where only authorized, business-justified traffic from the DMZ is allowed to connect to the trusted segment. No direct incoming internet traffic to the trusted application environment can be allowed. Additionally, outbound internet access from the trusted segment must be limited to required and justified ports and services.

See the standardized Network diagram for an understanding of the flow of encrypted data associated with Oracle Hospitality Cruise SPMS.

Maintain an Information Security Program

In addition to the preceding security recommendations, a comprehensive approach to assessing and maintaining the security compliance of the payment application environment is necessary to protect the organization and sensitive cardholder data.

The following is a very basic plan every merchant/service provider should adopt in developing and implementing a security policy and program:

  • Read the PCI DSS in full and perform a security gap analysis. Identify any gaps between existing practices in your organization and those outlined by the PCI requirements.

  • Once the gaps are identified, determine the steps to close the gaps and protect cardholder data. Changes could mean adding new technologies to shore up firewall and perimeter controls, or increasing the logging and archiving procedures associated with transaction data.

  • Create an action plan for on-going compliance and assessment.

  • Implement, monitor and maintain the plan. Compliance is not a one-time event. Regardless of merchant or service provider level, all entities should complete annual self-assessments using the PCI Self-Assessment Questionnaire.

  • Call in outside experts as needed.

Application System Configuration

Below are the operating systems and dependent application patch levels and configurations supported and tested for continued PCI DSS compliance.

  • Microsoft Windows 10 Professional. All latest updates and hot-fixes should be tested and applied.

  • 4Gb of RAM minimum, 8GB or higher recommended for Payment Application.

  • 128Gb of available hard-disk space.

  • TCP/IP network connectivity.

  • Oracle 12c. All latest updates and hot-fixes should be tested and applied.

Payment Application Initial Setup & Configuration

Performing Maintenance

We use ADPI tool to pre-select how long historical data are to be kept.

  • Credit Card Data is checked default which to compliance with PA-DSS.

  • The Credit Card Data purges the orphaned credit card data, authorization and settlement that were entered a specific number of days ago.

Figure 4-1 ADPI Setting Window


This figure shows the ADPI Setting Window
  1. Start the application ADPI.exe.
  2. Check on the respective date to be purged.
  3. Define the retention duration for the data.
  4. Click Process Now to purge the selected data.

Updating your Encryption Key on a Periodic Basis

  1. When the encryption key is due to expire in 14 days, the system prompts below warning, informing the shipboard user to renew the encryption key.

    Figure 4-2 Day Encryption Key Expiry Warning


    This figure shows the Day Encryption Key Expiry Warning

  2. Launch the Tools.exe.

  3. At the login screen, enter your login credentials.

  4. After a successful authentication, a user with access to the application will see the main screen as shown in below figure.

    Figure 4-3 Tools Main Screen


    This figure shows the Tools Main Screen

  5. Click the Change Database Encryption Key. The Encryption Key Manager screen opens.

  6. The key custodians must enter their part of the passphrase in the text boxes labeled Passphrase 1 and Passphrase 2. They must confirm the input and the application will validate the passphrases.

  7. Once the passphrase is entered and validated, another login to the database is required. The user needs to know the name of the Oracle connection and have a user ID and a password that grant necessary permissions to the targeted Oracle schema. See Figure 4–4 below.

    Figure 4-4 Encryption Key Manager


    This figure shows the Encryption Key Manager
  8. Once all information is filled, click Apply and the system prompts a reminder window. See Figure 4–5 below.

    Figure 4-5 Encryption Key Manager Prompt


    This figure shows the Encryption Key Manager Prompt

  9. During the rotation of the keys, all the database infrastructure is in place and the cardholder data information residing in the database will be unencrypted using the soon-to-be replaced DEK (old) and once the new DEK is in place the information will be encrypted using the new DEK. These processes takes place in memory, and the newly encrypted cardholder data is written to the database. The following screen appears once the process completes.

    Figure 4-6 Encryption Completes Notification


    This figure shows the Encryption Completes Notification