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

Thought Paper

Thought Paper02 Thought Paper 03

Overview of banking application security and PCI DSS compliance for banking applicationsCard 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

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

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

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 andfilters to ensure security.

• At the core banking/ application level, theresponsibility for security rests with the respective vendors.

• At the third party application level, banksprotect 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.

Thought Paper02 Thought Paper 03

• Debit/ credit card data is usually stored indatabases, 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.

• It is also essential to protect card data as ittransits through networks, routers, firewalls, filters, middleware, web services etc. during a transaction.

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 millionormorecredit/debitcardswereaffected.

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.

Working of card based payments

(In)Famous card security breachesThe 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.

SWITCHING

Services by external

vendor

SWITCH

(at Bank)

POS/ATM

SWITCH

(at Bank)

POS/ATM

BANK - A

Core BankingBANK - A

Core Banking

Thought Paper04 Thought Paper 05

• 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 insecurecoding 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.

PCIDSSV02standard(payment card industry – data security standard version02)

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.

Holes in current application security practicesPA 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 networkwhich is secured from the lowest datagram level to the routing level.

• To ensure that the interfaces and databaseroutines 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 andother threats.

Current card-related security practices of banks

• Most banks deploy a Hardware Security Module (HSM) at terminals involved in cardpayment 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-EndEncryption. 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 amessage, 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.

• Oflate,theJPOSlibraryframework(Javalibrarybased ISO8583 framework) has come into use.

Thought Paper04 Thought Paper 05

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/creditcarddatathroughtwodistinctmodes:

• Directdealingwithcardbaseddata

• Usingvendordrivenmodulestodealwithcardbased 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

Impact of PCI DSS compliance on core banking system

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, atwhich code level dependency can be resolved.

• Compliance in the external environment inwhich 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 BajiSenior Consultant, Finacle Payments, Infosys

Sandhya RavikumarSeniorSystemsEngineer,FinacleE-BankingandChannelSupport,Infosys

• To encrypt all non-console administrative access to credit card holders’ data through specialized devices such as POS, Swap terminals,ATMswitchesandsoon.

• To maintain instructional documentation andtraining 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.

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.

About 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.

www.infosys.com/finacleFor more information, contact Finacleweb@infosys.com