PCI-C Device

Appliance and Management Process for Compliance with Payment Card Industry Data Security Standard (PCI DSS)

What is PCI DSS?

The Payment Card Industry (PCI) Data Security Standard is a world-wide benchmark mandated by the card schemes (VISA, MasterCard, Amex, Diners, JCB) for the protection of cardholder identity and transaction information. It requires users of card data to:

• Build and maintain a secure network
• Protect cardholder data
• Maintain a vulnerability management programme
• Implement strong access control measures
• Regularly monitor and test networks
• Maintain an information security policy

Each of theses six requirements is supported by one to three major recommendations, and these are subdivided into over 170 detailed controls on the storage, transmission and use of card data. This includes requirements for the management of computer systems, network devices and software used to store, process and transmit the data. Refer to PCI DSS 1.1 and PCI Audit Procedures 1.1, both in the PCI Security Standards Council (PCI SSC) web site.

Applying PCI DSS to Existing Systems

When the security standards mandated by PCI are applied to existing systems, five major areas of non-compliance re-occur time and again. If we take a typical production network as looking something like this:

Figure 1: MultiChannel Retail Network

We are very likely to find the following security vulnerabilities

Figure 2: Network Vulnerabilities

Insecure network and computers: computer networks outside of financial institutions are in the main designed to make information available, not to restrict its availability. PCIs detailed requirements mean that networks where payment processing systems reside must be secured to high standards. With a typically flat, open network, this can mean applying a high level of security (in the form of firewalls etc) to many systems which would not normally be thought to require it. PCI also required that computers hosting card data must be hardened i.e. insecure services and accounts should be removed before the system is put into service. Many such systems are in fact installed with out-of-the-box configurations which are not secure.

No protection of data: most systems have little protection of data, except perhaps access permissions on certain folders. Although PCI offers four methods of securing card data (hashing, truncation, one-time pad, strong cryptography) only strong cryptography (aka encryption) really satisfies requirements. This can be expensive to implement, with the expense often increasing in proportion to the number of systems participating in the encryption regime.

Weak access controls: many systems used shared or generic accounts. To re-engineer these across a large estate is potentially difficult and/or expensive.

No testing or monitoring: non-banking systems are generally not regularly subject to penetration testing either internal or external, but both are required by PCI. The cost of such tests is often based upon the number of IP addresses (roughly equivalent to the number of individual computers or network devices) to be tested. Monitoring systems such as intrusion detection (designed to detect unauthorised attempts to access networks) or intrusion prevention are expensive to implement and to operate on a network-wide basis.

Lack of security policy and secure operational procedures: the retail industry in particular, where most card data is found, has traditionally paid little more than lip service to security, and best-practice operational frameworks such as ITIL remain unusual outside finance and government.

Routes to PCI DSS Compliance

Achieving PCI DSS compliance means either making the as-is compliant, or re-architecting the payment processing systems to provide high levels of compliance. The former can entail large amounts of process and organisational change to manage security flaws in the technology as well as requiring technology change in the form of data encryption. The latter uses technology change to minimise organisational and business process impact, but may be harder to achieve particularly with legacy applications. PCI DSS remediation programmes usually include workstreams to

• Segment the core network, isolate and protect payment data stores, implement intrusion detection and prevention
• Improve access controls, add two-factor authentication for remote users and suppliers, document key processes and ensure audit trails are in place
• Commission an information security framework, create appropriate policy, processes, standards and guidelines
• Implement an encryption system, often based on up to four hardware security modules (HSMs) to provide encryption capabilities for all devices storing or processing card data.

Minimising the Impact of PCI DSS in the Betting Industry

Finsoft is a premier supplier of systems to the betting industry. Margin Maker is in widespread use, utilising a unique bus mechanism to interlink front-of-house and back-office functionality. Finsoft has engaged PCI specialists to review the processes and technology used to deliver and support Margin Maker, with a goal of reducing the impact of PCI DSS for its clients.

By re-architecting key elements of MarginMaker, Finsoft has concentrated processing of all card data security into a highly secure appliance-type unit known as Finsoft PCI-C. This device can be represented in diagrammatic form below. In simple terms, it provides three functions

Capture: When a card is first presented as a means of payment, the card number and associated data are sent to PCI-C. The sending application must be verified as being permitted to carry out such a transaction. The card data is encrypted and used with other information to generate a token which combines the encrypted card number with a reference to the encrypting key, to act as a token. This token is returned to the calling application, which can then store it with the customers other data. The encrypting key itself remains securely within the PCI-C device.

Authorise: To authorise a transaction, an application need only present the token. The application must present credentials to identify it as an authorised user, but need not directly access the card data.

Payments (settlement): When actual card numbers must be presented to the bank for payment, the authorised application retrieves the token from the transaction record, presents it to PCI-C and is given the decrypted card data. Note that acquiring banks require that card numbers are presented as clear text this is not within the scope of PCI DSS.

Figure 3: PCI-C Conceptual Architecture

PCI-C promotes PCI DSS compliance by

• Isolating card data in a single location. Once safely recorded, card payments can only be requested and processed using a token which maps directly on to the card number, but is not the card number. Card data is stored in encrypted form in a secure database
• Authenticating all programmatic access to card data. Any entity requiring card data must first identify itself. Only when this identify has been checked will PCI-C provide the required functions to the calling entity which allow it to process card payments
• Providing PCI DSS compliant encryption. PCI DSS requires a minimum of 3DES. PCI-C provides AES encryption, currently more secure than PCI DSSs minimum requirements

The PCI-C device is accompanied by a toolset of software interfaces to enable external programs to authenticate and use the device, and by a set of secure processes which ensure the continued security of the device itself. Finsoft also provides a maintenance service to future-proof PCI-C against any changes in standards.

How does PCI-C reduce PCI DSS impact?

The table below shows the business impact on PCI DSS compliance, and the various steps that need to be taken to address those impacts. It also lists ways of reducing the impact, and where appropriate, shows how use of PCI-C can help.

PCI-C Delivers Implementation and Operational Savings

Implementation

• Network Segmentation avoided locate PCI-C on separate LAN segment
• Additional firewalls avoided PCI-C has internal firewall
• Access Controls can remain the same PCI-C has internal compliant access control
• Encryption requirements minimised there is no un-encrypted card data outside PCI-C, and PCI-C has its own PCI compliant encryption

Operation

• Monitoring costs limited to monitoring PCI-C network segment
• Testing limited to PCI-C network segment

Planning for PCI DSS Compliance

To achieve certification under the standard, organisations processing card payments in excess of six million transactions per year, or conducting business over the internet (Tier 1 merchants) are obliged to have their payment processing systems and organisation inspected and certified by a Qualified Security Assessor (QSA). In practice, the process of achieving certification consists of

• Pre-compliance assessment: there are few organisations which would meet the DSS requirements out-of-the-box. A pre-certification assessment is highly recommended to gauge the likely level of non-compliance. The assessment requires knowledge of the DSS and of card payment processing systems. Normally an assessment will discover a number of gaps or issues with the organisations current management of payment card data

• Remediation: technology and process areas identified by the pre-certification assessment as likely to fail compliance need to be addressed. A remediation programme is normally required, and may be carried out by internal staff or with external assistance.

• Certification: post remediation, the certification itself should be straightforward. A QSA must provide the certification.

PCI-C reduces the cost and time to achieve compliance essentially by reducing the scope of the compliance project. By encrypting card data at source and providing secure key management, much of the corporate infrastructure can be placed out of scope. Assessment and remediation can be reduced from the entire corporate network to a small core area. Since no unencrypted card data exists outside PCI-C, assessors should have no concerns over administrative user access, patching, anti-virus etc. outside the PCI-C device itself.

Copyright Notice

Finsoft Ltd proprietary rights are included in the information disclosed herein. The recipient, by accepting this document, agrees that neither this document, nor the information disclosed herein, nor any part thereof shall be reproduced by any means graphic, electronic or mechanical, including photocopying, recording, taping or in information storage and retrieval systems or transferred to other documents or used or disclosed to others for manufacturing or for any other purpose except as specifically authorised in writing by Finsoft Ltd.