>> Customer Area

For more information contact us on:

T:0118 948 2588
E:enquiries@ackltd.co.uk

------------------------------------

PCI DSS

The ACK solution >More

The ACK solution diagram >More

PCI background >More

Frequently asked questions >More

Information resource >More

Glossary of terms used within PCI >More

Why acronyms cost retailers money >More

PABP

Information resource on Payment Application Best Practice >More



ACK - PCI DSS Solution Overview

Introduction

ACK, as a company, has always focused on getting the core fundamentals right and keeping things simple; as a consequence, our products meet retailers' requirements for simple-to-operate and reliable code. Helping our customers meet the requirements of PCI DSS is no exception to these principles.

The focus of PCI DSS is to ensure that wherever credit/debit card data is stored it is secure and not readily accessible to the criminal fraternity. The fact that card data is stored both in retail store and at retailers' head offices is challenging, but the ACK solution is designed to overcome this challenge by securing sensitive data at each location individually and collectively.

The following details are designed to give a broad outline of how ACK products help retailers meet the requirements of PCI DSS with integrated EFT in a retail environment.

Background

Card data during the authorisation phase is handled in clear. This is necessary because the card data must be known by the various elements involved in the validation and authorisation of a transaction, including the acquirers' authorisation host, and must be recorded on the merchant copy receipt. Card data security during this phase falls into the network security part of PCI DSS regulations as it is singular and transient and is not persisted in clear.

Card data is only recorded after the authorisation phase has completed where it falls into the secure storage part of PCI DSS regulations and is the focus of this document.

The card data recorded by an integrated EFT system within a retail store environment during the trading day is referred to as the transaction log file which will store accumulated card data to disk. At the completion of the trading day, these log files must be submitted to the acquiring bank so that the retailer gets paid. The two most common methods of submission of the log files are; polled or central. Polled submission is where a bank-approved polling bureau retrieves the log file from each store using the APACS 50 protocol. Central submission is where the log file from each store it pulled or pushed to the retailer's head office where they are consolidated into a single APACS 29b or NatWest Standard formatted file for submission in bulk, under the retailer's control, directly to the acquiring bank for settlement.

Daily transaction log files at most retail stores will rarely contain enough card data, even in a busy stores, to rise above Level 4 in the PCI DSS risk assessment. However, the cumulative total of card transaction data collected from across an entire estate and held centrally will be significant and could raise the PCI DSS risk to Level 1.


The ACK Solution

The ACK PCI DSS compliant software solution is the result of detailed research into the provision of effective data security for stored card data which can be implemented with full consideration of the operational constraints of a retail environment both at the retail store level and at the head-office level.

Design Objectives

ACK set itself a number of product design objectives when considering the implementations of encrypting transaction log files. The design objectives:

Do Not:

  • Require existing ACK chip and PIN solutions to be re-accredited.
  • Adversely affect system performance.
  • Mandate the use of additional third party products (hardware or software) and associated licence fees
  • Alter the operator or cardholder experience

Do:

  • Provide a simple method of securing sensitive information.
  • Allow hardware security modules to be used if required.
  • Keep the management of encryption keys as simple as possible (and therefore used!).
  • Provide fully automated functions wherever possible.

These objectives also happen to satisfy the business objectives of most retail organisations.

Philosophy

Human nature being what it is, any system which is not automated and/or easy to use is liable to be neglected, ignored completely or subverted.

Furthermore, the impact of security on the functionality of a system and the organisation must be considered. ACK have analysed the options and devised a system that takes into account the operational and business needs of a retailer: We felt it important that the shop staff and IT department should not be burdened with unnecessary additional procedures nor have their jobs made more complicated.

With the above in mind, ACK have devised a data security system which;

  • Uses techniques which ensures data is secured at each stage.
  • Operates seamlessly as far as shop staff are concerned.
  • Has minimal impact on system implementation and maintenance.
  • Places only minimal responsibility on those responsible for IT functions.

ACK have applied the following two rules for maintaining effective security:

  1. Key storage must be secure itself - like any other security system, the locks may be adequate to resist unauthorised intrusion, but will be useless if the key is not held securely.
  2. Key management must be simple to operate - complex systems are more vulnerable to abuse.

Having devised an effective security system, ironically, the weakest point for card security are the APACS Standards which currently expect unencrypted card data to be presented and processed by APACS compliant host systems.

Acquiring banks are therefore in the invidious position of insisting that the retailers adhere fully with PCI DSS requirements, whilst at the same time expecting transaction data to be made available to them in an insecure format.

Method of operation

Single Site Installations

For retail environments that do not involve centralised submission the ACK software is self managing.

The only prerequisite is that the ACK software is running under Windows NT and above - this is because the ACK software uses the CryptoAPI which comes as standard within these Windows operating systems.

Thereafter, the PCI DSS compliant ACK software will self-manage the encryption of transaction data as it is written to the transaction log. Key-mutation is automatic and ensures the data will be impossible to be decrypted on any other machine and may therefore be transmitted safely across private and public networks.

The ACK software will also perform automatic deletion of transactions over seven days old, thereby ensuring the cumulative number of card transactions potentially do not exceed PCI DSS Level 4 data volumes.

The only area of risk is that encrypted transaction data cannot be decrypted should the public and private keys become lost or destroyed as these keys are specific to each machine where encryption takes place. Therefore, any catastrophic failure of the individual machine will render the transaction log files unreadable. However, the keys can be stored separately and re-instated on a new machine in the event that a new machine is to be deployed - clearly the management of these keys must be secure. Note that all is not lost should catastrophe strike as individual transactions can be recovered from the hardcopy merchant receipts.

Multi-Site Installations

For retail environments which operate across multiple sites and where centralised submission is in operation using the ACK Bulk Delivery System, the following will take place:

The ACK software components at the store remain the same as for single-site installation, but an estate public key will be used. The estate public key is created on, and used by, the ACK Bulk Delivery System machine using the ACK Estate Key Manager which creates two keys: 1) the private key which BDS uses to decrypt the incoming transaction log files and 2) the estate public key which must be distributed to each store where ACK software is running.

At the end-of-day, the ACK software at the store will decrypt the transaction data using its local public key (as used in the single-site installation), and re-encrypt the data with the BDS estate public key. The transaction data is therefore still secure and can be transmitted over the network (public or private) to the central site where it will be imported, still encrypted, into the database. BDS only decrypts the data once it is ready to create and transmit the settlement file to the acquirer.

Conclusion

If you are concerned about how to comply with PCI DSS requirements, ACK are here to help and inform you. We have put together useful background information which can be found on other pages of the ACK web site.

Download .PDF version of this information >Here