Core banking (1/2) – Security Testing Handbook for Banking Applications

4: Security Testing Repository
86
o Check if sensitive information is visible in page
source/JavaScripts/source code of the application.
o Check if error messages reveal sensitive data.
An attacker takes control of the underlying server:
o Check if the underlying server is patched for all
known vulnerabilities.
An attacker evades audit trails:
o Check if application has audit trails for sensitive
operations.
o Check if application records error conditions and
suspicious activity in audit trails.
o Check if application records login failures and
privilege violation attempts in audit trails.
o Check if audit trail tampering can be detected.
o Check if audit trail logs are stored securely with
restricted access.
Core banking
Banks these days provide a large and varied set of services
catering to different types of customers. These services
range from providing a savings account for the average user
to providing large loans to corporations and businesses to
performing advanced foreign exchange (forex) transactions
with other businesses on behalf of users. The funds that the
bank processes on a daily basis are astronomical and the
smallest of mistakes can have a huge impact and lead to
loss of customer confidence.
In the pre-digital era, bank branches weren’t networked and
each customer could withdraw money only from the branch
where they had an account. The customer used to go to the
branch to get their savings passbook updated with all their
4: Security Testing Repository
87
monthly transactions and monthly interest earned. As the
size of banks grew it became harder for these processes to
work effectively. Manual entry was error prone and time
consuming and legacy software wasn’t capable of handling
the ever-increasing number of real-time transactions. It was
clear that a more robust and scalable solution was desired.
That’s when core banking was born.
Core banking is at the heart of the banking industry today
and is an electronic replacement for the old, manual
banking methodology. It serves the most critical needs of
banking, hence the name ‘core banking’. These include
opening and closing accounts, holding all personal and
financial details of the bank’s customers, calculating
interest to be paid and collected, providing account
statements, creating periodic reports for specific branches,
account types or customers. Core banking functions also
include processing data related to loans and mortgages.
Recently it has also started taking care of financial trade
activities and facilitates online real-time settlement of funds
across banks.
How is access control taken care of? Core banking modules
are not directly accessible to the public. All the services are
made available across channels like ATMs, Internet
banking, mobile banking and bank branches. Every
transaction made by the user using any of the above
interfaces is ultimately handled by one or more modules of
core banking. For example, a teller at the branch is an
initiator for each core banking transaction, e.g. cash
deposit, withdrawal, term deposit. Each transaction is
authorised by a manager at the branch. Authorisation can be
either local (authoriser physically present at teller desktop)
or remote (at authoriser’s desk with their own login).
4: Security Testing Repository
88
Almost every application which we’ve described in this
chapter ensures that its data is in sync with that held by the
core banking database – both Internet-facing applications,
as well as internal-facing applications.
The core banking software is installed at different branches
of the bank. Data is transferred to the main datacentre
which houses the main servers over leased lines, direct dial-
up lines or even PSTN lines in case of smaller branches.
This allows bank staff and indirectly customers to access
customer accounts from any core banking enabled branch.
The servers that are used to host the core banking
application as well as the databases which store all the
customer data are almost always connected in a cluster to
ensure 24×7 availability. Banks ensure that the network
equipment used to interconnect the servers and the
databases meets high quality standards, is fast and
guarantees high uptime. The customer data stored in the
databases is often stored in storage area network (SAN)
servers with terabytes of storage. All of these servers are
also placed in separate network segments segmented by a
firewall and monitored by intruder detection system (IDS)
sensors.
The core banking application can be the recipient of
unwanted attention by attackers as it is at the centre of the
bank’s operations. Hence regular application security tests
are recommended for this application.
Every application that we’ve described so far is important
and has its place in the banking industry but none of them is
as important as core banking. We recommend that you
rigorously test all the modules of core banking.
4: Security Testing Repository
89
Threat profile
An attacker opens a fraudulent account bypassing
background verification.
An attacker opens an account with less than the required
balance.
An attacker views/adds/deletes/edits confidential details
of customers on behalf of other users.
An attacker performs fraudulent transactions on new
accounts that have not yet been approved.
An attacker issues a chequebook on behalf of another
user.
An attacker performs fraudulent transactions by using a
bounced cheque.
An attacker credits the interest of a time deposit to
another user’s account.
An attacker performs fraudulent transactions on frozen
accounts as part of transactions.
An attacker enter another user’s account to repay a term
deposit.
An attacker enters an already paid demand draft for
payment.
An attacker modifies the maturity amount in the term
deposit account on behalf of another user.
An attacker performs transaction in non-working hours.
An attacker places a standing instruction (SI) to debit
another customer’s account.
An attacker executes an SI even if an account is frozen.
An attacker submits post-dated cheques to debit the
amount from other user’s account.
An attacker performs remittance operations on another
user’s account.
4: Security Testing Repository
90
An attacker modifies details of customer of another
branch.
An attacker grants/stops payment of a cheque without
proper authorisation.
An attacker closes an account without running the
interest calculation on it.
Test plan
An attacker opens a fraudulent account bypassing
background verification:
o Check if a user can open an account even though their
documents have not been verified using parameter
manipulation.
An attacker opens an account with less than the required
balance:
o Check if a user can open a new account without the
minimum balance using parameter manipulation.
o Check if validations performed at the browser can be
bypassed.
An attacker views/adds/deletes/edits confidential details
of customers on behalf of other users:
o Check if a user can modify details of other users
using parameter manipulation.
o Check if a user can delete all accounts using SQL
injection.
An attacker performs fraudulent transactions on new
accounts that have not yet been approved:
o Check if a user can perform transactions on
unapproved accounts using parameter manipulation.