	Contact
	Home
	Search

The challenges of PCI

Article by Steve Edwards

The PCI standards were originally introduced after attacks on e-Commerce merchant acquirers resulted in a number of high profile cases in the press reporting the loss of cardholder data and in some cases the making of this information available on the Internet. This issue was bought into the spotlight in 2005 with the theft of millions of card numbers from a US e-Commerce acquirer. This resulted not only in significant problems to all US banks– but focussed the whole payments community on this issue. Although the scope of the PCI audit requirements was originally defined only for e-commerce acquirers – this incident resulted in the need for the standard and audit to cover also traditional acquirer services (POS and ATM) and provides a sign post that many of the requirements will need in the future to be covered in issuer systems.

Implementation Impact

The question to ask is why will this be a challenge? First of all the key requirement to protect cardholder data will result in a number of technical changes as the cardholder details are one of the key data elements of any payment transaction! To support the hiding of this data through whatever mechanism will require careful implementation – especially if loss of flexibility is to be minimised. Other technical issues may be the performance impact on the online transaction flow result from encrypting data, the implementation of procedures if the data security is somehow compromised and recovery of encrypted data in the event of a major catastrophe.

The next point to consider is that as soon as we are considering the changes required to the application, these are only a small part of the impact of implementing these standards. The implementation of PCI impacts the whole workflow and operation of the business on a daily basis. The sensitive data held in the application is only part of it – what about the data used to administer the system, what about the clearing data, the billing reports and statistics?

And then finally, we need to consider who the “hackers” are; traditionally we see these people as outsiders in darkened rooms hunched over their workstations logged into the internet and trying to hack in to access our systems. This threat is real – but a more significant type of “hacker” who has already been associated with some of the largest frauds related to identity theft have been made by insiders with internal technical knowledge. Therefore the solution is not simply locking the system up – we also have to hide the keys.

The eps approach to PCI compliance

Our approach to meeting the challenge of PCI is three fold – on a practical level we must ensure that all the aspects of the audit requirements are met. This will require that there are changes to the products to meet the requirements on a technical level but in addition to this we will also provide responses to even the issues that are beyond the scope of the product, for instance define standard user access security profiles that can be used for any customer.

Secondly our solution must be flexible so that it can support Acquirer and/or Issuer functionally within a configurable framework that meets our customers business and legal obligations in this area. It is no point encrypting all card data if our customer is an issuer (no current PCI obligation) and by doing so current business processes are made more difficult and slower.

Finally the scope of our solution needs not only to cover the documented requirements but it also needs to be based on our unique experience of implementing our products at many different types of customers. And not only in terms of functionality – but also other aspects of system security – for instance how do you know that the version of software running in production only contains the code lists held in your change control system?

Analysis First

The impact on the systems can vary a lot and needs to be analysed on an individual basis. Only on the basis of the impact analysis, the scope of the compliance work can be established. There are also procedural mandates - such as the need to implement formal security policies and vulnerability management programs - that will require IT resources. eps can provide consultancy and analysis of the existing security infrastructure to evaluate the gap.