Ali Alaswad, ITIL, PMPG, PMP
The advent of the Payment Card Industry Data Security Standard (PCI DSS) resulted in many organizations mandating its use. However, in many initiatives, the regulatory compliance projects face difficulties in funds allocation because it is easier to justify and calculate the projected cash benefits for projects that deliver products or services than for projects of regulatory compliance deliverables such as those related to PCI DSS.
One of the important factors that impact the cost and time in PCI DSS compliance projects is the lack of a realistic definition of scope of work. A major challenge to the project sponsors and managers is defining the gap between where the organization stands on PCI DSS requirements and the amount of work required for it to become compliant. Spending more effort on the planning phase can help to control the cost and time spent in the later phases of the project.
There is no doubt that the reliance on credit cards as a method of payment has increased, and the necessity of providing security, integrity and availability around the credit card environment is continuously pressing as the number of merchants and service providers, processes, stores, and transmissions of credit card data is projected to increase in the future. In 2011, IT research firm Gartner’s survey of 77 US retailers revealed that PCI compliance continues to be aggressively enforced by the card brands and spending with credit cards has continued to increase since 2008.1 A survey conducted by Federal Reserve Bank of Boston in 2010 found that 72.2 percent of consumers had used a credit card in 2009.2 On the other side, the number of credit card holders has increased in the US from 159 million in 2000, to 164 million in 2003 and 176 million in 2008,3 and in 2012 the estimated number of credit card holders in the US is 181 million.4 Visa made US $6.3 trillion worth of transactions (payments and cash transactions) over the four quarters ending 30 September 2012.5
The challenges of bringing a PCI environment into a new compliance system include, but are not limited to, the following:
The current approach to securing credit card holder information focuses on securing the credit card client’s (merchant’s) environment in compliance with industry standards to protect card information from theft and fraud.6 The proposed Smart Credit Card (SCC) approach looks to secure the credit card holder information from a different perspective.
SCC intends to eliminate the risk at its source: the credit card. This entails replacing the current credit card with one with more features and intelligence. This proposed credit card will resemble a small, ultrathin calculator with a smart chip that contains all the credit card holder information. It also contains a minimal processing capability to generate a random and temporary credit card number (TCCN) at each transaction. The random numbers are derived from the unique and individual credit card for each cardholder based on a strong algorithm. Each cardholder will have a unique set of temporary numbers, generated randomly on usage. To use the SCC, the user needs to enter a password on the credit card itself, preventing misuse of the credit card in the case of loss.
The SCC, which weighs no more than and is similar in size to a current card, has the following technical features (figure 1):
Money transactions will have two processes based on business requirements: standard (STD) and request for confirmation (RC). The STD process is for a regular money transaction through a merchant point-of-sale (POS) device. This transaction is only for one-time use and for a specific amount of money. The steps for an STD transaction are:
The RC process is designed to satisfy the business requirement of confirmation of money transactions. It is appropriate to use with credit card number provisions for purchases made over the phone, when filling out an electronic application or filling out a paper application. It can also be used with a merchant’s POS device. The steps for an RC transaction are:
The buyer can also go to the bank and personally ask the teller to confirm the pending requests. The buyer must provide confirmation within 72 hours from the purchase date and time; otherwise, the transaction will automatically proceed and the buyer will have all responsibility in the case of false representation.
The buyer’s confirmation for each purchase is important for two reasons:
The SCC solution has two payment processes. In the STD process, the TCCN is valid for one usage only, and if the TCCN is stored, processed or transmitted, it will require no implementation of PCI compliance security measures.
In the RC process, the TCCN can be used multiple times, and gets stored at the merchant environment, but in the SCC solution, the liability shifts from the merchant to the cardholder by providing the cardholder the ability to confirm each transaction. For a transaction to complete, the cardholder must provide approval within 72 hours of the transaction initiation. The cardholder is legally responsible for any breach. Merchants, service providers and credit card issuers must make sure cardholders are aware of this responsibility.
In the SCC solution, the real work of PCI DSS compliance requirements implementation is mainly focused at the card-issuing bank where the primary account number (PAN) of the cardholder is stored, processed and transmitted. Furthermore, the environment where the encryption keys are stored and the keys used to decrypt the TCCN to identify the actual account number, cardholder name and other required information to complete the transaction must be secured in accordance with PCI DSS requirements.
The proposed SCC solution provides the technical capabilities to enable the credit card to generate the TCCN by itself. An alternative solution would be adding a wireless feature to the credit card. In this approach, the same steps of the SCC process are followed with the single exception of generating the TCCN remotely and, in case of the RC process of payment, having the confirmation request received on the card itself.
The alternative wireless approach works with the credit card sending a remote request for a TCCN to the card-issuing bank through a wireless connection; the card-issuing bank processes the request, identifies the card holder account, generates a temporary and unique TCCN based on a strong algorithm, and sends a TCCN to the credit card. If the transaction requires confirmation from the cardholder, a request for confirmation is received on the card itself, and the cardholder is given the capability to approve or decline through the credit card. Serious considerations would need to be taken into account when adopting this approach, specifically:
The SCC solution is proposed to provide a different security framework that provides peace of mind to all parties—the merchants, the credit card issuers and the customers (credit card holders). The current PCI compliance implementations focus on securing all merchants’ environments by adding controls to business processes, modifying applications, removing data with credit card information and changing network configurations as needed. The proposed solution adds control at the credit card level. The solution features and components can be summarized as follows:
1 Gartner Survey, “PCI Compliance Activity Shifts Downstream as Aggressive Enforcement Continues,” June 20112 Federal Reserve Bank of Boston, “The Survey of Consumer Payment Choice,” www.bos.frb.org/economic/ppdp/2011/ppdp1101.pdf, 20103 US Census Bureau, 20104 Visually Inc., “2012 US Credit Card Usage Statistics,” http://visual.ly/2012-us-credit-card-usage-statistics5 Visa Inc., “Visa Inc. Corporate Overview,” http://corporate.visa.com/_media/visa-corporate-overview.pdf6 Javelin Strategy & Research, “Identity Fraud Industry Survey Report,” 2012, https://www.javelinstrategy.com/brochure/239#DownloadReport
Ali Alaswad, ITIL, PMPG, PMP, is president of Nadine Technology Solutions Inc. With more than 20 years of experience in IT, he has been working in diversified technical domains with a focus on IT standards and compliance and project management. Alaswad has worked in various industries including government, aviation, telecommunications, energy (oil and gas), IT service, retail and health care.
Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2013 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.