| Oracle® Retail EFTLink Security Guide Release 19.0 F23632-01 |
|
 Previous |
 Next |
This chapter describes retailer and solution specific responsibilities for ensuring EFTLink is securely implemented and configured.
It is considered to be a best practice to have all Oracle Retail EFTLink support requests submitted through a single point of contact for that customer environment; the client designated administrator is usually designated to perform this role.
The link to use when submitting Service Requests (SR) is:
This section describes general principles to be observed.
The protection of sensitive data during transit and processing is paramount. Sensitive data includes personally identifiable information such as PAN Numbers and track 2 data. Ensure that if configurable, the EPS/payment terminal is set for PCI compliant masking of card PAN and track 2 data.
An instance of EFTLink and any third party EFT software (dependent on solution) will typically run on the POS hardware and communicate with each other to process EFT transactions when requested by the POS software.
The POS Terminals are located in the customer facing areas of the store in proximity to both customers and employees. Physical security of the hardware is the responsibility of the retailer in addition to operational practices like provisioning employees to appropriate application roles and shutting registers down when not in use.
Securing the in store network is a responsibility of the retailer and is assumed to be compliant with PCI-DSS requirements for topology, wireless access, and wan connections. The connection to the corporate data centers and the external credit authorizers also are assumed to follow PCI-DSS requirements for secured connections.
The PCI-DSS standards are available at:
https://www.pcisecuritystandards.org/pci_security/
It is recommended that all machines on the store network be kept up to date with vendor supplied patches, especially security patches. The operating systems on POS Terminals should be locked down by removing or disabling unneeded functionality, in particular ensure that the system cannot be used for browsing the internet.
POS security recommendations will vary according to the POS software being used. Please refer to the appropriate POS Security Guide or the POS Implementation Guide for your product.
EFTLink V15.0.1 onwards, secures the connection between the POS and the framework using TLS encryption. This is enabled by default.
TLS encryption between the POS and the EFTLink framework can be disabled by setting the Framework configuration file EftlinkConfig.properties TLSEnabled=false, but this should only be done after consultation with Oracle, as it reduces the security of the solution, and needs to be disabled at the POS side of the process as well.
This section gives core specific security guidance.
A password for Adyen is required to be encrypted in the adyen.properties file.
In order for the password to be entered, a keystore can be generated via a batch file which will be held in the data directory.
Subsequently the password may also be entered into the system for storage using the batch file, the encrypted password output and this can then be placed into the adyen.properties file.
AJBFiPay has an enable.signature.logging option. Enabling this property (setting to True) results in exposing the PII (customer signature). The enable. signature.logging option should therefore only be enabled when requested by Oracle Support for debugging purposes and should be turned off immediately debugging has been complete.
EFTLink V15.01 includes a modification to allow the core to be used for reading POS handled Cards (Gift Cards, Employee Cards and so on) removing the need for a card swipe attached to the POS itself.
To be able to use this feature, Oracle needs to be consulted, as special configuration needs to be applied to transfer the full card details of the required cards to the POS.
There are specific security implementation considerations for the Cayan Core. The Cayan Core will be shipped with a public root certificate. When the Cayan Core is initialized a Java Key Store (JKS) is created and secured. If there is no public certificate stored in the JKS then the root certificate file is located and converted to an encrypted certificate file and stored securely in the JKS. The public root certificate file is then deleted from the installation folder.
The certificate is required in order to create the secure socket required for the https session with the authorization host.
Once the encryption key has been created and stored, and the certificate also secured, the install procedure requires the entry of a number of details such as merchantid to be entered via the POS. As these are entered they are stored and encrypted as required, and connection to the pin terminal is then possible. Full details of the procedure are available in the installation guide for Cayan.
The Device is accessed by specifying an address based on the MAC address of the device.
No secure connection information is held within EFTLink.
The pointUs device is paired with EFTLink via a registration process, involving a four digit pin.
No secure connection information is held within EFTLink.
Verifone Ocius Sentinel requires a user login ID and PIN to be stored on the POS system.
These are transmitted by EFTLink to the Ocius Sentinel application as part of a login process which is required before Ocius Sentinel can accept EFT requests.
When it is running, the Ocius Sentinel application also has a GUI (GraphicalUserInterface) which can be accessed by an operator from the Windows System Tray. This GUI has a login screen. The login screen accepts the same ID and PIN as stored in the EFTLink core configuration file. Having manually logged into Ocius Sentinel a number of functions are available to the user, including processing payments and refunds which bypasses the POS software.
In order to prevent unauthorized use of the Ocius Sentinel application the user login ID and PIN should be stored encrypted in the EFTLink core configuration file. An encryption tool is provided to implementers for this purpose and details on its use can be found in the EFTLink Core Configuration Guide. It is recommended that batch encryption of user login ID and PIN data be carried out at a central location and the encrypted data then be distributed to stores as required. Once encryption has taken place the clear text copy of the data can be deleted.
|
Note: EFTLink is configured to expect encrypted ID and PIN data by default. |
The following table shows the comms and security for each payment system:
Table 1-1 Payment System Comms/Security
| Payment System | Driver/Server Application | Comms | Security | Notes |
|---|---|---|---|---|
|
EFTLink Framework |
- |
Socket XML |
TLS |
Self-certified certificate generated as part of build process. Certificate stored in a Java Keystore and included in release |
|
Adyen |
POS_JNI |
Not detailed |
None |
Uses provided POS_JNI |
|
MerchantLink/POSLynx |
POSLynx (LAN dongle) |
Socket XML |
SSL |
Certificate downloaded from server and loaded into Java SSLSocket class. Certificate stored in a Java Keystore. |
|
Cayan |
- |
WebService SOAP Socket |
TLS |
Encryption key stored in java keystore and included in release fileset. |
|
Verifone Point US |
- |
Verifone Point US |
Data includes encrypted security field |
Encryption key established by initial pairing using RSA exchange. Key stored in a Java Keystore. |
|
AJB FiPay |
FiPay |
Socket CSV Text |
None |
|
|
TLG SolveConnect |
SolveConnect |
Socket XML |
None |
|
|
Verifone Ocius Sentinel |
Ocius Sentinel |
Socket XML |
None |
|
|
FIS TransaxEFT |
TransaxEFT |
Socket XML |
None |
|
|
Six Payment Services |
MPD (OPI mode) |
Socket XML |
None |
|
|
Worldpay |
Worldpay |
Socket |
None |
|
|
(YesPay) |
CSV Text |
