Overview of Banking Application Security and PCI DSS Compliance for Banking Applications Thought Paper www.infosys.com/finacle Universal Banking Solution Systems Integration Consulting Business Process Outsourcing
Overview of banking application security and PCI DSS compliance for banking applications Card based transactions account for barely 1% of all non-cash transactions by value, in India. Security concerns rank high on the list of barriers to card adoption, not just in this country, but also in those with much higher penetration. The card ecosystem, comprising issuing banks, application developers, technology vendors and regulators, has taken several steps to secure banking applications and carrier networks against deliberate attack or unintentional breach. This paper discusses banking software application security practices in general, as well as banks compliance with the provisions of the Payment Card Industry Data Security Standard (PCI DSS), which focuses specifically on the safeguards for credit and debit card data. Software application security and security compliance Software applications, like Internet Banking, which are exposed to users on public networks, are vulnerable to security threats. Stories abound about individual or group hackers managing to penetrate public bank networks, to gain access to applications and databases. Banks employ either or a combination of the following approaches to secure their software applications: Proactive security: The banks deploy adequate security measures to protect networks and applications from cyber attack. Post incident security: The banks put a mechanism in place to constantly monitor activity logs, databases, webservers, networks etc., which alerts them the moment there is a security breach and also helps them reconstruct the sequence of events, which led up to it. In such an event, the banks isolate or de-alienate their applications, webservers, databases et al immediately and follow it up with a tightening of proactive security measures. The need for holistic security The securing of individual components, such as applications, networks, access controls etc. must be done in coordination with all other security systems, rather than piecemeal. A cohesive and holistic security approach is most effective. To illustrate, let us take the example of a banking application that is connected to a database; it is not only necessary to protect the application but also the database at the other end. We ve seen instances of databases using default passwords, hardly the recipe for foolproof safety! Current banking application security practices Typically, banks safeguard their applications at three levels: At the network level, banks use firewalls and filters to ensure security. At the core banking/ application level, the responsibility for security rests with the respective vendors. At the third party application level, banks protect middleware, databases, webservers etc. with security packs that are provided by their vendors. Security of banking applications in card transactions It is necessary to secure card transaction data while in storage and also during transactions. 02 Thought Paper
Debit/ credit card data is usually stored in databases, which are in turn stored in data centers. These must be safeguarded through regular information security audit. Also, the owners of the data must ensure that it is stored in encrypted form. Working of card based payments SWITCHING Services by external vendor SWITCH SWITCH (at Bank) (at Bank) BANK - A Core Banking It is also essential to protect card data as it transits through networks, routers, firewalls, filters, middleware, web services etc. during a transaction. POS/ATM BANK - A Core Banking POS/ATM (In)Famous card security breaches Despite elaborate measures, card security does get breached from time to time. Some past incidents resulted in massive losses for card owners and their banks. The most famous ones are listed below: The case of heartland payment systems Heartland, a payment processor of debit and credit card transactions, was the victim of an attack wherein the perpetrators planted malicious software onto its payment network to record data sent during payment processing. The attackers managed to capture the highly confidential digital data encoded on the reverse of credit/debit cards. It is estimated that 100 million or more credit/ debit cards were affected. The case of TJX companies This is a great example of how inadequate security measures allowed fraudsters to break in at two levels that of the network as well as the application. Hackers breached TJX Companies data security by penetrating the network security at Kiosks and Points of Sale (POS). They broke into TJX s network, which was not firewalled, and used USB keys to load software on to the POS terminals to gain access to the network. Their modus operandi was to remotely control the payment network and gain access to customer data, which was stored by TJX in an unencrypted form. Around 46 million card holder accounts were estimated to be affected by the attack. The case of card systems In this example of application security breach, hackers employed a sophisticated technique called SQL Injection to extract customers card information. Card Systems had not firewalled their web application. This inadequacy was exploited by the hackers, who planted a small code snippet (a database query that is run on a database to extract data) onto Card Systems database by means of a web application, which was used by customers to access their own data. The hackers used File Transfer Protocol to retrieve this information. Here again, the company s failure to erect network firewalls and encrypt important data was the reason for the breach. To make things worse, old transaction information had not been deleted, which added to the huge losses. Is PCI compliance a guarantee of security? The Heartland episode shot into the limelight especially because the company had been certified as PCI compliant. This unfortunate incident was a wake-up call for the payment card industry, which until then was not subject to a rigorous audit mandate. In those days, it was common for banks and other institutions to dismantle their security checks or encryption processes once they received a one-time audit certification. After the Heartland incident, it was decided to make periodic audit compulsory for the payment card industry to ensure adherence to data security standards. Thought Paper 03
Current card-related security practices of banks Most banks deploy a Hardware Security Module (HSM) at terminals involved in card payment transactions. This hardware could be in the form of a smart card, which must remain inserted for the transaction to take place. Another technique in use is End-to-End Encryption. Data is encrypted (or encoded) at its origin (Point A) and transmitted to its target (Point B), where it is decrypted (decoded). This technique employs both transport-level and data level security; the former to encrypt transmitted data using network protocols such as Transport Level Security (TLS) and Secure Socket Layer (SSL), and the latter to encrypt specific fields such as account number rather than the entire message. Tunneling refers to the encapsulation of a message, say, in Protocol A within another one, say, Protocol B, prior to transmission over a virtual private network (VPN) which can be set using Secure Shell (SSH) protocol. It is useful for sending unencrypted data within an encrypted network. Likewise, HTTPS (Secure HTTP) is another protocol that is used for tunneling. Of late, the JPOS library framework (Java library based ISO8583 framework) has come into use. Holes in current application security practices While tunneling is a useful encryption technique, it has its pitfalls. In fact, hackers can exploit it to bypass firewalls and breach the application level security of payment processors. Web pages are made vulnerable by insecure coding practices, which can be exploited by techniques such as SQL injection, script injection etc. Regular code audit can improve the security of web pages. The practice of keeping services such as telnet or File Transfer Protocol (FTP) running when not in use weakens security. The simple remedy to this problem is to shut down unused services and ports. PCI DSS V02 standard (payment card industry data security standard version 02) Payment Card Data Security Standards were developed to improve the safety of cardholders data and ensure adoption of consistent data security measures globally. The scope of PCI DSS covers security management, policies and procedures, network architecture, and software design. PA DSS and its impact on core banking systems The objectives of Payment Application Data Security Standards part of PCI DSS are as follows: To test applications for vulnerabilities including at the coding level and find ways to address them. To facilitate the implementation of a network which is secured from the lowest datagram level to the routing level. To ensure that the interfaces and database routines responsible for storing cardholder data are configured in a way that the data is not stored on servers with Internet connectivity, and to encourage the use of dedicated servers separated from the Internet for this purpose. To facilitate secure remote access governed by smart cards, tokens, i-keys to applications, and ensure the correct implementation of access policies. To encrypt sensitive traffic over public networks (with HTTPS or SSL) such that the data is safeguarded against sniffing tools and other threats. 04 Thought Paper
To encrypt all non-console administrative access to credit card holders data through specialized devices such as POS, Swap terminals, ATM switches and so on. To maintain instructional documentation and training programs for customers, resellers and integrators. It must be noted that application security is effective only if the user is trained to implement the right practices; integrators and customers who are direct stakeholders in the system must be supported with adequate documentation, explaining what is expected from them. Impact of PCI DSS compliance on core banking system Banks must achieve PCI compliance in order to standardize their security infrastructure for card based payment transactions. PCI compliance is a regular process containing various steps to ensure that the banks technological environment is compliant with security requirements. In fact, this move is led by the industry. Core Banking System (CBS) applications handle debit /credit card data through two distinct modes: Direct dealing with card based data Using vendor driven modules to deal with card based data Since PCI DSS standards are comprehensive, they impact virtually every aspect of core banking applications supporting card transactions. However, the biggest impact is the banks demand for complete security of the core b anking application, its environment and coding practices, and also of the data handled by other applications. Achieving PCI DSS continuity PCI DSS specifies periodic validation; banks and application vendors must periodically perform the assessment recommended by the standards in order to maintain security. Banks external dependency regarding PCI DSS The external dependency for compliance has two components: Compliance at the level of the application, at which code level dependency can be resolved. Compliance in the external environment in which card based data is processed, namely switches, token drivers or specified devices for hardware level security. Since PCI involves both layers, compliance usually requires multiple dependencies to be resolved. The way forward In India, PCI DSS compliance is at a nascent stage. At present, there is no regulatory thrust in this direction, nor adequate infrastructure and skilled manpower to perform audits. This is still a growing market, and may take a while to come to terms with the higher security expectations laid down by these standards. Makarand Madhukar Baji Senior Consultant, Finacle Payments, Infosys Sandhya Ravikumar Senior Systems Engineer, Finacle E-Banking and Channel Support, Infosys Thought Paper 05
About Finacle Finacle from Infosys partners with banks to transform process, product and customer experience, arming them with accelerated innovation that is key to building tomorrow s bank. For more information, contact Finacleweb@infosys.com www.infosys.com/finacle 2012 Infosys Limited, Bangalore, India, Infosys believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. Infosys acknowledges the proprietary rights of the trademarks and product names of other companies mentioned in this document.