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
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
02 Thought Paper
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.
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. Weve
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.
 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.
It is also essential to protect card data as it
transits through networks, routers, firewalls,
filters, middleware, web services etc. during
a transaction.
(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 TJXs 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
SWITCHING
Services by external
vendor
SWITCH
(at Bank)
SWITCH
(at Bank)
BANK - A
Core Banking
BANK - A
Core Banking
POS/ATM POS/ATM
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
companys 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
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.
04 Thought Paper
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.
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.
 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
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
Senior Systems Engineer, Finacle E-Banking and Channel Support, Infosys
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.
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
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 tomorrows 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.