Professional Documents
Culture Documents
Core Banking PDF
Core Banking PDF
M. Revathy Sriram
Managing Director
P.K. Ramanan
Director
R. Chandrasekhar
Director
Tejas Brainware Systems
Chennai
Delhi-110092
2010
.
.
CORE BANKING SOLUTION: Evaluation of Security and Controls
M. Revathy Sriram, P.K. Ramanan and R. Chandrasekhar
© 2008 by PHI Learning Private Limited, Delhi. All rights reserved. No part of this book may be reproduced in any form, by
mimeograph or any other means, without permission in writing from the publisher.
ISBN-978-81-203-3535-6
The export rights of this book are vested solely with the publisher.
Published by Asoke K. Ghosh, PHI Learning Private Limited, Rimjhim House, 111, Patparganj Industrial Estate, Delhi-110092 and
Printed by Mudrak, 30-A, Patparganj, Delhi-110091.
.
Contents
Foreword.........xiii
Introduction.........xv
Preface.........xvii
Acknowledgements.........xxi
C.R.L. Narasimhan
Business Editor
The Hindu
Introduction
Banks are facing new challenges with the implementation of Core Banking Solution. The BASEL
committee report of banking supervision builds on an evolving framework for managing risks in
financial services transactions. Operational and information risk management and IT controls are
essential in good corporate governance. Senior management oversight and good governance over the
financial system require that operational and information risk management and IT controls merge in a
seamless model. Governance, risk management and compliance are top business priorities. An
improved corporate governance requires many initiatives including
While governance, risk management and compliance are the primary responsibility of the Board of
Directors, all units are expected to implement the principles set by the management. A good
governance is about setting strategy, managing risks and delivering value.
Within banking services, risk categories include the following:
Credit risks
Market risks
Operational risks
Legal risks
Reputational risks
Operational risks cover the areas associated with potential failures in the overall operation of
financial services and specifically the underlying technology and infrastructures. Given the
complexity and scope of operational risks, governance, risk management and compliance need to
include all areas of an organization not directly linked to the other risk areas.
Information technology implementation requires additional emphasis on business alignment, roles
and responsibilities and technical competence. The internal environment component as discussed in
BASEL II principles, highlights certain important aspects:
S. Balasubramanian
Chairman
City Union Bank Limited
Preface
Implementation of technology in the banking industry is taking place at a very rapid pace. In the
beginning, it was originally a simple Advanced Ledger Posting Machine (ALPM). Then the banks
started computerizing their operation in bits and pieces. After that, Total Branch Automation (TBA)
was introduced. But this technology required a total makeover. So Core Banking Solution—a solution
to deal with all business processes of the bank with easy upgradability—became a necessity.
While the technology associated with the banking industry has been improving at a fast pace, the
steps that need to be taken to ensure that security concerns are paid attention to have not always been
considered either due to pressure of implementation or lack of adequate knowledge to evaluate the
security concerns. With every new technology, there will be new security concerns and therefore
require appropriate controls in place. The installed systems would not be able to protect themselves
and their data. There could be intrusive and destructive attacks.
This book is an attempt to bring various security aspects of core banking solution before the
technology experts and user communities, especially the professionals and regulatory boards who are
entrusted to ensure that controls are adequate and security concerns have been attended to.
Computer security issue, in the earlier years and sometimes even now, was understood as creating
in a computer system a group of access controls that would emulate or implement the processes of
prior paper world. The additional features, at the most considered, were those of protecting such
software against unauthorized change. Physical access to computers was supposedly taken care of by
cordoning off the computer area. The world has changed now. The Internet is flowing and the reality
of the World Wide Web is in place. Networking has exploded and communication among computer
systems is the rule rather than an exception. Many commercial transactions are web-based. All
financial institutions including banks have implemented web-based applications. The audit of various
branches of banks is no longer relevant excepting to review the reports that are furnished at the
branches—generated at the central office. The conventional audit methods have now become
irrelevant and misleading.
With branches being connected with each other by communication lines and through the Internet, the
evaluation of adequacy of security needs a greater understanding of the technology behind the core
banking solution. All the three authors, being basically chartered accountants, have taken utmost care
to write the book in a manner, which could be understood by the non-technical professionals who are
mostly statutory auditors officiating the Inspection and Audit Departments of various banks, officers
of Department of Banking Supervision of Reserve Bank of India, etc.
It needs to be mentioned that whenever configurations of systems are discussed, it is one of the
ways it could be done. We do not claim that this is the only way. There could be other different
methods of implementing the Core Banking Solution (CBS). We have considered one set-up and
discussed the same right through the book. Technology behind ATM, Internet Banking, RTGS, etc. has
been discussed. The methodology of generation of PIN Nos. has been explained. There could be other
methods too. We have explained the most commonly adopted methods. The methodology suggested
for testing the adequacy of security and suggested controls in place, are based on our experience and
knowledge in this area.
The book is the outcome of long cherished desire of the Tejas team to provide easily readable and
yet a comprehensive background material to understand the concept of Core Banking Solution (CBS)
in the proper perspective and be in a position to perform an effective systems audit. The book is
divided into two parts and five sections, A, B, C, D and E.
Section A containing 11 chapters deals with what core banking solution is and how it becomes an
inevitable technology alternative to most banks. Apart from the concepts of various modules in CBS,
its implementation procedure and best practices to be in place for a successful and effective
implementation are covered (Chapters 1 to 6).
Chapter 7 covers important aspects to be borne in mind while migrating existing branches with
earlier technology process of most of the modules in banking operation.
Business process and technology implications of ATM, Internet banking, RTGS, and Cash
Management Systems are discussed in Chapters 8 and 9.
Chapter 10 deals with security policy, and its importance for an organization. An abbreviated
version of a draft policy is provided.
Chapter 11 deals with Business Continuity Planning. It discusses broadly the methodology to be
adopted for evolving a Business Continuity Planning and Disaster Recovery Planning. The different
likely scenarios in a core banking solution implemented are considered.
Section B deals with audit approach in a bank which has implemented CBS. This section consists
of ten chapters and starts with what could be the scope of evaluation of security and controls in CBS
(Chapter 12). The scope is envisaged to be comprehensive.
Each of the chapters highlights the security concerns for Application software, Networks,
Operating Systems, etc. and the controls that need to be in place and their adequacy (Chapters 13 to
21).
The readers could pick up those chapters which may be appropriate.
Section C contains chapters on audit logs and usage of audit tools.
Chapter 22 on audit logs describes different types of logs, their importance and the auditor’s role in
reviewing the same. Chapter 23 on audit tools explains the need to use automated tools to perform
more effective and efficient audit in a technology environment. In particular, usage of Audit Command
Language (ACL) audit tool for a particular application, e.g. loan disbursement, is considered for
detailed explanation.
Section D dicsusses some instances of live case studies when lack of controls leads to frauds being
committed. The list of cases naturally is only illustrative but not necessarily exhaustive.
In section E a brief description of some of the standards, guidelines and procedures of ISACA
(Information Systems Audit and Control Association), USA has been included as they have relevance
to audit of Core Banking Solution (CBS). ISACA standards are internationally accepted and it would
be relevant to benchmark systems audit procedures against these.
Special permission has been obtained from ISACA who were kind enough to grant the same.
ISACA also provided similar support by permitting reproduction/summary reference to their
professional standards.
The Reserve Bank of India (RBI) has been periodically issuing circulars and notifications in the
area of performing systems audit in banks. Extracts of relevant Circulars of the Reserve Bank of India
have been provided in Appendix.
The book includes a glossary of terms with some pictorial representations for a better
understanding of the concepts discussed. A list of useful websites references has been given to enable
the readers to constantly update their knowledge and also look for useful audit programs.
The book would be useful to the bank officers who want to understand the CBS. It will also help
the inspection and audit department of banks to have a guideline for performing a systems audit. The
chartered accountants who are the auditors of the bank along with the external systems auditors who
are offered special assignments would find the book extremely useful. This book can also be used to
advantage by auditors who are required to perform concurrent systems audit of banks and by the
officers of the department of banking supervision of RBI and others who are responsible for
regulating security and controls in banks where CBS technology has been implemented.
Security is not a product but a process. Security is not a one time effort. It requires constant and
continuous attention.
It would be appropriate to quote Dr. Paul Doreas, Driector, Digital Business Security BP Ltd. in
this context. “Information security provides management processes, technology and assurance to
allow business management to ensure business transactions can be trusted, ensure IT services are
usable and can appropriately resist and recover from failures due to error, deliberate attacks or
disaster and ensure critical confidential information is withheld from those who should not have
access to it.”
Practicing strong information security is a non-negotiable requirement for all business
organizations including banking industry. However building security into an existing corporate culture
is a complex undertaking.
We welcome suggestions for improvement of the contents of the book. The authors could be
contacted at [email protected]
M. Revathy Sriram
P.K. Ramanan
R. Chandrasekhar
.
Acknowledgements
We offer our special thanks to Mr. S. Balasubramanian, Chairman, City Union Bank, for having so
kindly agreed to pen the “Introduction” to the book.
We are also indebted to Mr. C.R.L. Narasimhan, Business Editor,
The Hindu, who readily agreed to provide “The Foreword”.
We were not able to request Mr. N. Vittal, former Central Vigilance Commissioner, earlier, due to
his non-availability. Though we established contact rather late and had limited space to have him
express his views on our book, he was gracious enough to offer his comments, committed as he is to
security in a computerized environment.
We would be failing in our duty if we do not acknowledge our deep felt gratitude to the Senior
Management of City Union Bank, Chennai, more particularly the Senior General Manager Mr. S.
Sridharan, General Manager Mr. S. Sekar, the present team members of the Computer Systems
Department, Mr. K. Swaminathan, Mr. J. Ramaswami, Mr. G. Sankaran, Mr. V. Sivakumar, Mr. S.
Senthil, Mr. K. Venkatraghavan, Ms. B. Lakshmi, Mr. N. Bagavathy and also Mr. N.V. Nathan, for
their invaluable contributions in different ways. We had professional association with them during
performance of systems audit of their core banking solution.
We also express our gratitude to:
Mr. S. Chandran, Former General Manager of Bharat Overseas Bank (now Indian Overseas
Bank).
Mr. A. Vijayakumar, Assistant General Manager of Karur Vysya Bank, formerly the Assistant
General Manager of the IT Department of Bharat Overseas Bank and his team members
including Mr. Anand Sharma and Mr. Ramanathan.
Mrs. Jamuna Swamy, Head, Information Security, Hexaware Technologies.
Mr. Sai Sridhar, formerly General Manager of Bank of Madura.
Mr. Krishnakumar, General Manager, Information Security, of the State Bank of India.
Mr. S. Venkataraman, Mr. V. Rajendran, Mr. J. Venkatesan,
Mr. V. Desikan, Mr. R. Selvaraju, Mr. S. Ravi Auvudiappan and other members in the CPPD
and associated departments dealing with inhouse developed Core Banking Solution in Indian
Overseas Bank.
Senior members of the IT and Inspection Audit Department as also Disaster Recovery Team
of Corporation Bank, Mangalore.
The Information Systems Audit Control Association (ISACA) of USA which has so kindly
permitted us to refer to their Standards and Guidelines.
Mr. S. Ranganathan, Mr. Ramjee and Mr. Viswanathan who patiently provided excellent
secretarial support to complete the Herculean task.
Our thanks are due to our other team members of Tejas, Mr. S. Swaminathan,
Mr. B. Chandrasekhar, Mr. A. A. Raj, Mrs. B. Sathya Bhama who enthusiastically supported the
project by making useful contributions. Our special thanks to
Mr. S. Ganesh Ram, our former colleague, for proofreading the manuscript and also having patiently
drawn all the diagrams in the book which was fine- tuned several times before it was finally accepted
by all of us.
We have accessed public information available on websites and taken the essence of useful and
relevant knowledge. We express our gratitude to the concerned websites.
We would like to thank the Editorial and Production staff of PHI Learning, who made a neat
execution of the book.
There are many others also who have spared their time, shared their knowledge and experience to
make the completion of the book possible. We wish to thank them also.
M. Revathy Sriram
P.K. Ramanan
R. Chandrasekhar
PART 1 CORE BANKING SOLUTION: ITS FUNCTIONS, APPLICATIONS
AND MANAGEMENT SYSTEM
This part deals with the relevance of the Core Banking Solution in banking system. It explains what actually the core banking
solution is and how it has nowadays become indispensable to the banking system. This part discusses concepts of various
modules in Core Banking Solution (CBS), its implementation and security measures along with Business Continuity Planning
(BCP) and Disaster Recovery Planning (DRP).
SECTION A.........................................................CHAPTER 1
It was possible for different branches of the same bank to have different versions of the
programs. This situation arose due to the fact that while originally same copies of a single
program was loaded in the different branches, over a period of time, when some changes
required to be made to the computer program either due to change in functionality or a bug in
the programs brought to the notice of the Computer Planning and Policy Department (CPPD)
by some branches, different versions of the original program were available in different
branches. This, in turn, led to the associated problems.
Any time any changes were made in the Master Data like rate of interest for savings bank
account, for fixed deposits, loans etc., these changes had to be introduced by means of a
floppy being sent from the head office to the branches. Generally, the banks ensured that
correct copy of the floppy was taken personally by personnel of CPPD and loaded on to the
servers at the respective branches. However, due to paucity of personnel and due to certain
amount of complacency developed over a period of time, the floppies were sent to the
branches and the branch manager was requested to take the assistance of the systems
administrator to change the Master Data. This was in some cases leading to either the changed
interest rates not being implemented as expected, or wrong floppies being loaded either
inadvertantly or intentionally. The necessary procedures to ensure that the correct Master Data
was uploaded were not strictly adhered to, ostensibly due to the branch managers being busy
with operations and performance rather than paying attention to technology requirements.
As more and more branches were coming into the scheme of total branch automation, some
banks decided for operational reasons to have a small group of people from the CPPD to be
available at the regional offices of the bank. Decisions were also taken that those team
members would have a copy of the source code so that if branches experienced some
difficulties in the execution of the program which was leading to problems and delays in
operations, the necessary corrective actions could be taken by this group and could correct the
source code and load the modified executable of the program onto the server at the branches.
These decisions while it seemed to ease operational problems gave rise to the following
security concerns:
Copies of the Source Code were available at the regional offices which is in direct contrast to
best practices. The source code should be available only at the library in the CPPD at the head
office.
Different versions of the program running at different places also created problems at
consolidation.
As end of day operations have to be done and it would not be completed unless books tallied,
possibilities of creating suspense account and tallying trial balances became a routine rather
than an exception.
As the practice of maintaining manual cash scrolls was disconti-nued and as computer
operations were localized at the branches, the possibility of fraudulent employees to exploit
the weakness was heightened.
It was also becoming extremely difficult to upgrade the program functionality, for example
introduction of ATM, introduction of Anywhere Banking etc. The programs were already
precarious with great deal of patch work. In addition, it was just not possible any way to
provide additional products with the existing program.
1.2 WHAT IS CORE BANKING SOLUTION?
The banks were facing stiff competition. Markets were expanding. Costs had to be brought down. The
available technology was far more advanced. It was at this juncture, the concept of core banking
solution appeared on the horizon. In an increasingly competitive environment, banks took a reality
check on their technology environment to ensure that their Information Technology (IT) strategy is
aligned to their business objectives. Introduction of core banking was inevitable (see Figure 1.2).
The continually changing business dynamics in the new age economy required banks to respond
with a high degree of agility. Today technology has emerged as both the key enabler and driver of
change. This process was accelerated by the enhanced expectation of the regulatory body Reserve
Bank of India (RBI).
Products were not only functionally rich and technically robust and scalable, but their new
generation architecture based on the web paradigm, true 24X7 solutions was providing the facility to
gain and retain competitive leadership in the consumer banking space.
Core Baning Solution (CBS) empowers banks to transform their business, leveraging agile new
generation technologies.
This modular solution addresses the core banking, consumer and corporate e-banking, mobile
banking and web based cash management requirements. Products offer powerful and differentiating
features making them most comprehensive, flexible and scalable solutions.
Core banking solutions are leaving an indelible mark as banks embark on a total overhaul of their
legacy platforms.
Banks needed to take a holistic view while considering a replacement by core banking platform. A
packaged new generation core banking solution has its obvious benefits but the considerable risks
associated with the replacement need to be mitigated and managed carefully and successfully.
Core banking solution is a set of robust software components designed to meet the challenges of
today’s banking market. The advanced technology infrastructure supporting the core banking solution
and high standard of business functionality provides financial institutions a competitive advantage.
Core banking solution is a set of integrated core banking components, as mentioned earlier which
could be tailored to fit the Institution’s individual business requirements. Core banking solutions
bring significant benefits to the organization as follows:
However, sometimes due to rushed implementation without proper preparation and planning,
introduction of core banking solution becomes a nightmare and it is not uncommon to see notices
being put in front of bank branches reading as follows:
‘We have introduced core banking solution and hence, there would be hiccups and delays and the
customers are requested to bear with the inconvenience’.
In the initial stages of implementation it is also not uncommon for the customers to wait for long
periods as harassed bank staffs were trying to establish connectivity to put through a simple
transaction. Both the customers and the bank staff were made to believe that inconvenience and delay
and the mystery of the unknown had to be accepted as inevitable hazards of implementation of core
banking solution!
The initial frustrations also lead to sarcastic but humorous comments appearing in magazines.
One of them expressed the core banking solution implementation by means of a chemical equation
as follows:
T + 0 0 = C 0 0 + CC
The equation describes the scenario when core banking solution (CBS) is
implemented in a bank without proper planning and adequate training of staff.
The equation when translated into English meant that when new techno-logy (T) is implemented in
an old organization (OO) it transforms it into a costly old organization (COO) generating lots of
confusion and chaos (CC)!
These wry comments were justified as a great deal of money was spent on hardware, software and
networking. However, in view of the shortage of time for the implementation due to tight time
schedule, proper planning was not done. The bandwidth was initially, totally insufficient leading to
slow access speed or even non-accessibility of the server and the untrained staff being in the dark as
to how to face the new system.
However, after the banks got over the teething problems, they were able to derive all the benefits of
implementing CBS. Only the control objectives and audit procedures needed to be changed.
SECTION A.........................................................CHAPTER 2
Technology behind
Core Banking Solution (CBS)
2.1 INTRODUCTION
In a core banking solution all the servers are centrally located, normally called as the central data
center. All the branches are connected to the data center through a leased line or any other network
connectivity with security and redundancy built in.
Figure 2.1 depicts the technology and connectivity details in the implementation of CBS.
Most of the servers like the application servers and database servers are placed behind the firewall
and protected from unauthorized access. In order to manage the load and also to build redundancy,
multiple servers performing the same function are clustered. All the servers are not in the same Local
Area Network (LAN). They are segregated using the concept of Virtual Local Area Network
(VLAN), which has its own built in security.
The following paragraphs describe the various servers, their functions and as to how they are
secured.
2.1.1 Requirements
Core banking environment consists of following:
The antivirus program updated with the latest virus signatures is pushed to all the systems in
the bank’s network from a central location.
It facilitates better administration as the antivirus software is updated in the central location
and becomes available to all the systems in the bank’s network unlike in the previous setup,
TBA, where antivirus updates have to be installed individually in each system.
Location: Antivirus server is placed in the trusted inside zone in a separate VLAN.
Automated Teller Machine (ATM) server
Automated Teller Machine (ATM) server contains the details of all ATM account holders. Also
ATM server temporarily holds data that is converted by the middleware as requested by the ATM
switch.
When the central database is not accessible a file containing account balances, referred to as
Positive Balance File (PBF) of the ATM customers is sent to the ATM switch. During this period, the
ATM transactions are based on the balance available in its server. Once the central database server
is restored, these transactions are updated in the central database.
Location: ATM server is placed in the trusted inside zone in a separate VLAN.
Web server
The web server hosts the bank’s website. There is a web host attached to the web server. The web
host has an operating system and runs the services from the web server. It accepts web page requests
from the customers and processes the same. The web host generates a dynamic web page for each
user while processing his services. It facilitates, when properly configured, secured (encrypted)
connection whenever confidential data are to be transferred.
Location: Web server is placed inside the de-militarized zone in a separate VLAN that contains the
proxy server, mail server, Internet Banking Application Server (IBAS) and Internet Banking Database
Server (IBDS).
Internet Banking Application Server (IBAS)
The internet banking application is hosted in the Internet Banking Application Server (IBAS). All
internet banking service requests are received by the IBAS from the web server. Internet Banking
Application Server works with the support of IBDS, middleware and central database server to
process the internet banking services requests. Internet Banking Application Server is placed inside
the de-militarized zone.
Location: IBAS is placed inside the de-militarized zone in a separate VLAN that contains the
proxy server, mail server, web server and IBDS.
Internet Banking Database Server (IBDS)
Internet Banking Database Server (IBDS) stores the user name and password of all the internet
banking customers. It also contains the home branch details of each internet banking customer.
Whenever an internet banking customer attempts to login to the bank’s website, the IBAS
authenticates the customer with the login details stored in IBDS. Also IBDS temporarily stores the
data requested by the customer while performing an internet banking transaction. IBDS retrieves this
data of the customer based on a request from IBAS. IBDS accesses the central database server
through a middleware and a firewall to retrieve the required customer details.
Location: IBDS is placed inside the de-militarized zone in a separate VLAN that contains the
proxy server, mail server, web server and IBAS.
Middleware
Middleware is a software that formats the data to make it compatible with different applications.
Thus, a middleware is required when more than one application with different data requirements
processes a common database.
Example: web based applications.
Location: Middleware is placed in the trusted inside zone in a separate VLAN.
Proxy server
A proxy server acts in conjunction with the firewall and provides network security by filtering
malicious data from entering the network. Also the proxy server secures the internal Internet Protocol
(IP) addresses of the Bank’s servers by performing a Network Address Translation (NAT) whenever
data are transferred from the bank’s network to a public network like internet.
Location: Proxy server is placed inside the de-militarized zone in a separate VLAN that contains
the mail server, web server, Internet Banking Application Server (IBAS) and Internet Banking
Database Server (IBDS).
Domain controller
Domain controller is primarily used for authentication. Access to a set of servers is controlled by the
domain controller.
Location: Domain name server is placed in the trusted inside zone in a separate VLAN.
Mail server
Mail server sends and receives mails across the network. Email security services are deployed in the
mail server to protect the users against spam mails and malicious attachments.
Location: Mail server is placed inside the de-militarized zone in a separate VLAN that contains
the proxy server, web server, IBAS and IBDS.
Implementation of
Core Banking Solution (CBS)
3.1 INTRODUCTION
Banks need to necessarily have had to implement core banking solution not only to meet growing
business needs but also to bring down costs. More importantly, they have to catch up with the current
technology which is fast growing and extremely useful for banking industry.
It is in this background of inevitable situation, that banks are implementing Core Banking Solution
(CBS).
As regards the implementation, responsibility of implementing could be given to:
As the investment is very high and as the banking solution has to be viewed from a long term
perspective, the decision is that of the senior management of the Bank.
Auditor is not involved in this decision generally as he appears on the scene much later after the
decision has been taken and the solution has been implemented.
It is important to mention that auditors’ role vary depending upon the decision taken.
User creation
Branch creation
Products creation
Ø FD interest
Ø Charges etc.
Process of day-end and day-begin
Responsibility for deploying new version of the program
Librarian is required to maintain a register for all the above-mentioned items. Change management
is one of the most critical functions performed by the librarian that help in maintaining software
version control.
4.7.1 Change Management Procedures
In the normal course, it becomes essential to upgrade hardware, utility software, and also make
changes to application software. The changes are warranted either due to technological developments
or bugs in the program.
Change management procedure for application software
There needs to be a version control for the software. At the stage of implementation, a specific
version number would be provided. There needs to be a document containing details of the version
number, date of implementation etc. For all subsequent changes, the procedure would be that:
There would be a request from an authorized person like the manager of the user department.
The request would be approved by the person in charges of the systems department.
Changes to the programs would be made in the test environment.
The correct program would be handed over to the librarian who would then give a different
version number for the changed program.
The documentation would contain details of changes made and the date when made.
Asset register
Risk management process
Network and security operating procedures manual
Server operating procedures manual
Anti virus operating procedures manual
Business continuity planning for data center
All the information assets of the bank’s data center are to be maintained in the form of asset
register. The details of the owner, custodian and user of these assets are to be maintained in
the asset register.
Risk management is to be performed for all the information assets. The assets are to be valued
and threats are to be identified. The existing safeguard measures, the exposure to the threats,
and the possibility of occurrence of the threats are to be considered along with the controls to
be put in place.
Owners of assets are to have total responsibility for the protection of the information under
their control.
The asset register is to be updated whenever there is a change.
Risk analysis
Risk management exercise is to be conducted for all the assets in the bank’s data center. The
assets would include servers, routers, firewall etc. The risk management is to be based on the
risk management manual prepared separately.
The bank’s project team responsible for the data center is to prepare the risk management
report after identifying all the threats/vulnerabilities to the assets, taking note of the existing
safeguard measures in place and the controls required to mitigate the perceived threats.
The risk management is to be reviewed by the manager in charge of security and any changes
as may be necessary are to be made by him.
This risk assessment would also be verified and audited by external competent party.
The final risk management report is to be submitted to the bank’s management.
Physical security guards are to be in place on all days through the year.
Access cards to be given only to authorized personnel of the data center.
The credentials of the security personnel posted at the bank’s data center should be verified.
The security guards should be trained to follow the physical security policy. Secure area at the
data center should be clearly defined and marked.
Personnel working on Sundays or holidays should enter their visit details in the register
maintained with the security personnel.
Checking of bags is to be done both at the time of entry and departure.
Carrying of bags inside should be permitted only if absolutely necessary.
Usage of photographic video or cellphones inside the data center should not be allowed.
Equipment security
Automatic fire detection, fire suppression systems and audible alarms should be installed at
the bank’s data center to identify any fire outbreak.
These equipments need to be tested periodically.
Temperature and humidity need to be controlled and monitored. Earth connections, circuit
breakers, air conditioners etc. need to be examined periodically and reports maintained by the
data center team.
Switches and controls which permit emergency shut-down of important systems are to be
physically protected to prevent unauthorized access.
Fire extinguishers are to be positioned throughout the premises and their locations clearly
highlighted.
Procedures to safely evacuate personnel out of the premises in case of emergency like fire etc.
need to be in place.
Power supply
It should be ensured that the electricity supply is protected by means of voltage stabilizer and
such other equipments.
There should be standby supply through UPS and diesel generators.
Cabling security
It is to be ensured that cables both for power and tele-communication are appropriately
protected and not left open.
Equipment maintenance
Prior approval is absolutely essential for entry or removal of sensitive equipment from the
premises.
Critical assets should be properly covered by insurance policy.
The data center team is responsible for the secure disposal of the information on computer
media.
There should be adequate back up for all information that may be in the machine to be
disposed off. The information should be thereafter deleted from the machine to be disposed
off.
Removal of property
All the properties like laptops, printers, CDs etc. entering or leaving the data center will have
to obtain prior approval and must be supported by properties movement pass, containing
details as mentioned in the security policy.
It is the responsibility of the security officer to preserve all evidence, review the cause of the
incident and restore the system.
Segregation of duties
There should be clear segregation of duties and responsibilities to avoid/reduce opportunities for
unauthorized modification or misuse of information (see Table 5.2).
Table 5.2 Segregation of responsibilities
Name of
Responsibility
the person
Managing the IT infrastructure of the bank’s data center
Monitoring security of bank’s network
Monitoring security of the various systems of the bank
Developing, maintaining and testing of the bank’s applications
Administration of compliance procedures relating to access
control to the premises and general safety of the building
Approving of the changes in the bank’s infrastructure
Details are also to be contained in the network and security procedures manual.
Separation of development/test and operational facilities
It is important to separate the development/test and operational facilities, both physically and
logically. Proper authorization procedures should be in place to move IT assets (n.w., s.w. to
production/live area people etc.) from development/test area.
Patches and upgrades
A specific individual in the bank’s systems team is to be responsible for updation of the latest patches
for all of the systems like the servers, routers and Intrusion Detection System (IDS). The downloaded
patches should be run in a test machine to ensure that implementation of the patches do not adversely
impact the services. After satisfactory verification in the test environment and authorization by the
bank’s administrator, the patches should be implemented in the live environment.
Internet use
Storage space
Network
CPU utilization of servers
System acceptance
All new systems to be added to the bank’s data center should be done only after strictly adhering to
the change management procedure. The systems administrator is responsible for testing the new
system considering the following:
Fault logging
The systems team of the bank should maintain logs of all the faults reported by the users regarding
problems faced in the area of data processing or communication systems. The bank’s data center team
should identify the cause of the problem and rectify the problems.
5.2.6 Network Management
Network management
Internet services
Various internet services should be reviewed and those that are not needed should be disabled
with the approval of the bank’s management.
Only with the approval of the manager of the bank’s data center, should inbound Terminal
Emulation Network access from the internet be allowed.
In the absence of such an approval, such access should be denied.
If inbound Telnet access is to be permitted, the following procedures are to be complied with:
• Strong authentication mechanism is used.
• All outbound Telnet access is using Secure Shell (SSH).
• All Telnet sessions are logged.
• Telnet is allowed only into port designated for Telnet services.
• Use of Trivial File Transfer Protocol (TFTP) is prohibited on public network.
• File Transfer Protocol (FTP) access is denied to all the Bank’s servers.
Firewall standards
Natted IP address should be used to protect the internal network (network address translation)
wherever applicable.
Access to firewall needs to be constantly analysed.
If it is observed that the firewall is compromised, it should be reconfigured.
A formal change management process should always be followed in changing a firewall
policy.
All the users communicating through the firewall system should be identified and logged.
All non-essential networking or system services from the firewall should be removed.
There should be a weekly review of all the system logs generated from the firewall.
Strong authentication methodology is to be implemented to the firewall authentication server.
Firewall system indicated is to be verified on a regular basis.
Removable computer media is to be stored in a safe and secure environment both offsite and
within the bank’s data center.
It has to be in accordance with the manufacturer’s specifications.
If any storage media is required to be reused, previous contents of the same should be erased
upon approval by the manager of the data center.
All removal of media should be done only with the approval of the appropriate authority and
records should be maintained for all such movements.
Disposal of media
All confidential and sensitive documents should be disposed of using appropriate shredders.
When a user leaves any position, the following procedure should be followed:
The immediate supervisor reviews both computer resident files and papers to decide on the
subsequent custodian of such files.
If the files need to be disposed of, appropriate methods are to be adopted.
Bank should maintain a log of disposal of sensitive data.
User access details for high risk and sensitive applications are to be reviewed at short
intervals.
Network share existence and Access Control List (ACL) for the users are to be periodically
reviewed.
Terminals should be locked when users are away from the desk.
Screen savers should be set to activate within say five minutes of inactivity.
Clock synchronization: Clock synchronisation for all servers and nodes needs to be controlled
centrally from the data centre. (Using protocols like Network Time Protocol (NTP) and Simple
Network Time Protocol (SNTP).
1. Hardware Platform
2. Server Operating System
3. Server Role
4. Server Operations Procedures
5. Patch Management Process
6. Password Management
7. Hardware Procurement Process
8. Hardening Procedure
9. Escalation Process
Each of the sections would describe in detail the operations undertaken under these heads.
This would enable automatic receipt of messages regarding updates instead of the bank having
to access the URL to find out whether there are any patches.
The data center administrators would test the patches on test servers and after satisfying
themselves would document the procedure for implementation.
The data center administrator would follow change management procedures and then only
implement the patches.
1. Switches
2. Routers
3. Firewalls
4. Intrusion detection systems
5. Communication links
6. Hardware procurement process
7. Password management
Switches
Switches provide the Local Area Network (LAN) connectivity to all devices and servers in the data
center of the bank. Servers would be divided into public and private zones. The documentation
should specify the configuration management mentioning specific details about the switches,
communication lines etc.
Change management: The procedure for change management is expected to be in accordance with
the change management procedures as specified in the security process document of the bank’s data
center.
Routers
The location of the routers and usage of the same need to be documented.
Configuration management: The network administrator configures and maintains the routers.
Details of router hardware procedures need to be recorded. The hardware and software configuration
details need to be recorded. Access lists need to be implemented to filter and restrict the access to
network as also the router.
Change management: The change management procedures should again be in line with the bank’s
data center security process.
Back up of router configuration: The router configuration and Internetworking Operating Systems
(IOS) need to be documented and the backup procedures need to be formulated and complied with in
a systematic manner.
Firewalls
Firewall is an important part of a network. It plays the role of preventing unauthorized access to and
from a private network. Firewall may be implemented both as a hardware and a software or as a
combination of both. The details of the implementation of firewall need to be clearly documented.
Configuration management: Configuration of firewalls needs to be documented in a firewall
configuration sheet.
Change management: The procedure for change management needs to be in accordance with the
change management procedures documented in the data center security process manual.
Security log management: Procedures to generate firewall logs need to be put in place to enable
troubleshooting. More importantly, the logs should be enabled for the following:
Standby firewall: It is advisable to have a standby firewall so that in case of failure of the primary
firewall, stateful failover mechanism could be implemented where the standby firewall can take over
the network without disconnecting the active zone.
Incident handling: Firewall logs need to be reviewed for established connections, as also for
reviewing any attempts for tracking any incidents through the firewall. There needs to be a procedure
to escalate to senior management any firewall incident detected by the firewall administrator.
Intrusion Detection System (IDS)
An intrusion detection system generally aids in detection and response for attack that may originate
from across the network. Configuration management of Intrusion Detection System (IDS) needs to be
documented. Change management should be in accordance with change management procedures of the
bank’s data centre security process manual.
Security log management: Logs should be analysed. Security administrator should monitor the log
file and alert the appropriate person in case of any suspicious activities. Logs should be retained for a
reasonable length of time, say, at least six months.
Communication links
Communication links would connect the bank’s data center to the bank’s disaster recovery site as also
to the bank’s branches. Configuration management details should be documented.
Hardware procurement process
Hardware procurement process should be documented and should be strictly adhered to. Also the
same should be monitored.
Password management
Policy on password management would be mentioned in the security
policy. Monitoring mechanism to ensure that recommended procedures
are strictly adhered to, need to be put in place. It is essential that default passwords should never be
assigned. Access to sensitive files should always be through complex password authentication. The
sensitive password should generally be maintained in a sealed envelope at the data center. A register
should be maintained in which each opening and sealing of the envelope is recorded.
Password selection: Set of Guidelines for password selection should be provided with ‘Dos’ and
‘Dont’s’. Password should be changed at least once a month.
5.5.1 Introduction
This should contain operational details for various server resources that are managed by the server
administrators at the data center. This document should also mention details of the hardware
configuration of the server, network devices and storage details.
Purpose of the document
The purpose of the document is to provide guidance to the bank’s network administrators to follow
and carry out their operations. It should also provide guidance on the associated procedures for the
various network components managed by the system administrator
Intended audience of the document
Operating System—WINDOWS 2003: This service pack ‘X’ installed. ‘Y’ antivirus, scan
version ‘Z’ software is installed with updated _______ scan engine (see Table 5.4).
Table 5.4 Hotfix
Patch Name Description
RAID: Redundant Array of Inexpensive Disks (RAID) could normally be installed and a mention
should be made of the RAID level and also mention that the RAID level is configured for the hard
drive in the database server.
Application: Mention should be made of the database running on the database server, e.g. SQL ___
database server. Mention could also be made of the number of the service pack. Mention should be
made as to which is the active server and which is the passive server. Details should be available
and mentioned as to where the SQL INSTANCE is installed. Details of the file name and path should
be mentioned.
Application server
The document should contain the details, preferably as shown in Table 5.5.
Table 5.5 Application server
Server Name IP address Sub Net Mask Service Running
APP….. ……….. ……….. *
* Mention could be made of the core banking solution, e.g. FINNACLE, FLEXCUBE, QUARTZ.
* e.g. IIS
Note: The name of the antivirus software with the status of updation should be mentioned.
Application: This should mention the process details. Internet Information Services (IIS). The
client accesses the pages hosted by the IIS and the web-server will interact with the application
server for processing the transactions and the information stored in the database server.
Backup server
Details should be available as shown in Table 5.9.
Table 5.9 Details of backup server
Server Name IP address Sub Net Mask Service Running
Veritas/Oracle
BKSRV ……….. ………..
Dataguard
Hardware configuration: The details of the backup server should be mentioned here.
RAID: Mention should be made of the RAID level which is configured for the drive in the back-up
server needs to be mentioned.
Operating system: WINDOWS 2003, this service pack no. ________ is installed (see Table
5.10).
Hotfix
Table 5.10 Patch name with description
Patch Name Description
Application: Mention should be made of how the back-up is done. For example, back-up tape,
library is connected with this server. A trust relationship is established with disaster recovery site.
The trust relationship is established with the active directory server of the disaster recovery site.
5.5.3 Network
Details of the router e.g. CISCO XXXX router
Configuration: Details may be recorded as shown in Table 5.11:
Table 5.11 Details of router
Router Sl. No. Description Quantity
………............................ ………............................ ………............................
The password should never be entered in soft copy document for obvious reasons. Confidentiality
to be maintained.
SNMP configuration: SNMP configuration consists of following:
READ only
READ
WRITE
Slots/Ports details: The details should be in the following format as shown in Table 5.13.
TABLE 5.13 Details of slots/ports
Description Total Used Free
Serial (Sync) 4 3 1
IP and interface configuration: The details could be presented as shown in Table 5.14.
Table 5.14 Configuration of IP and interface
Sl. No. Interface Name IP Address Sub Net Mask Remarks
For each of the IP addresses details should be available regarding the connection.
OSPF (Open Shortest Path First)
Configuration details to enable OSPF routing to be mentioned.
Access List: WAN Access List No. ____. Applied at _____. Similarly for all application lists
should be mentioned. The rules need to be recorded, preferably as shown in Table 5.15.
Table 5.15 Recording of rules
Sl. No. Rule Remarks
1. *
2.
3.
* Remarks would contain narration as ‘allow all PING replies’ or ‘allow all PING requests’, ‘allow data from ‘x’ place’.
Router hardening configuration. This should contain details of global configuration and also
interface configuration and version of the Internetworking Operating System (IOS).
Firewall
A brief description of the firewall installed needs to be mentioned. e.g. CISCO PIX.
XXXX Firewall Primary
XXXX Firewall Secondary
For each of the firewalls the details should be available as shown in
Table 5.16.
Table 5.16 Details of firewall
Sl. Interface IP Sub Net Security
Remarks
No. Name Address Mask Level
.............. .............. .............. .............. .............. ..............
Dynamic NAT
The details mentioned as shown in Table 5.18.
Table 5.18 Command with description
Command Description
................................................................ ................................................................
Routing: Details of routing done through the firewall need to be mentioned. It may be described as
shown in Table 5.19:
Table 5.19 Details of routing
Sl.No. Network Mask Gateway Interface
Access list: Details of objects created for purposes of administrating access lists need to be
mentioned and a table needs to be created to record the following details as shown in Table 5.20.
Table 5.20 Access list
Sl. No. Network IP Mask Remarks
Access list name: The rules applicable need to be contained in a proforma which could be
represented as shown in Table 5.21.
Table 5.21 Applicable rules
Sl. No. Rule Remarks
Passwords
Administrator user name Xxxxxx
Administrator password ...................... ...................... .........................
Access list: The details of the host computer permitted to communicate with the intrusion detection
system need to be recorded in a tabular column as shown in Table 5.26.
Table 5.26 Intrusion detection system
Sl. No. Access Type Allowed Network/IP Mask
................ ................................. ................................... ...................................
Interface details: Details of all the available interfaces to be recorded in this section. For
example:
Fiber port: 1
Maximum data rate
Current data rate
World-wide port name
World-wide node name
Fiber port: 2
Maximum data rate
Current data rate
World-wide port name
World-wide node name
Ethernet port: 0
MAC address
Host name
IP address
Subnet mask
Gateway
RAID configuration: The RAID level and storage medium details are to be mentioned.
Performance details of the RAID level configured could also be mentioned (see Table 5.28).
Array 1
Table 5.28(a) Performance details of RAID configuration
Sl. No. Logical Drive Name Controller Size
...................... ................................ ...................... ...................... ...................
Array 2
Table 5.28(b) Performance details of RAID configuration
Sl. No. Logical Drive Name Controller Size
...................... ................................ ...................... ...................... ....................
Mapping storage partitioning: Logical drive names and its mappings may be mentioned in a
format as shown in Table 5.29.
Table 5.29 Mapping the storage partitioning
Sl. No. Logical Drive Name Host Group
...................... ................................ ...................... ...................... ....................
Daily 9.05 AM
Tape backup of database server should normally take place after the day end process. Weekly
backup of the production server system may be done with the weekly backup of database.
Backup verification
To ensure the integrity of the backup, test drill should be conducted at the end of every week. This
should be mentioned in the manual to ensure that both the tapes and the backup procedures were
properly adhered to.
Storage access and security
When it is not in use, the media should be stored in fire-proof safe and away from magnetic fields like
diesel generator and other motor rooms. All backup media should be stored in a secure area which is
accessible only to the bank’s data center staff and to the authorized personnel of the computer
department.
Offsite storage
Another copy of the backup in tape should be managed by the bank’s management staff. This may be
stored at the bank itself and this backup will normally be taken on a weekly basis. However, off-site
storage must be secured and available only to the bank’s data center staff and the computer systems
department staff.
Restore request
Request for restoration of data should be by proper authorization of a member of the bank staff duly
authorized to perform such function.
Tape inventory
It is important to maintain inventory of tapes. This provides a clear picture of the backedup data
which could be used for restoration. The inventory should preferably be maintained in a register in
the following format as shown in Table 5.32.
Table 5.32 Maintaining inventory of tapes
Date of backup Backup start time Backup end time Duration of backup Backup tape’s name or tape label Size of backedup data Status of backup Scratch date*
* This column needs to be filled at a later date when the tape is used for a new back up—Recycling.
Tape retention
Mention should be made of the period of time the tapes will be retained. Generally after six months,
tapes would be demagnetized and new set of tapes would be used for backup. This would be the case
when the tapes are stored in the offsite location as well.
Tape labelling
Table 5.33 shows the tape labelling.
Table 5.33 Backup solution and labelling for daily backup
Scenario: 1. Per day __ GB of data to be backedup
2. ___ Copies need to be taken (onsite and offsite)
3. ___ Tape is used for this purpose
4. Data retention period is __ days for daily backup
5. Maximum tape usage period is ___ year
6. All ODD Nos. represent tapes at onsite
7. All EVEN Nos. represent tapes at offsite
8. At the end of 6th day the Monday tapes at offsite will be sent to onsite for overwriting the data
9. The above step is carried out for all days.
10. The labelling convention, CYYYMTZZZ is followed for labelling of backup media.
Where C denotes the backup generated
at the bank’s data center
YYY denotes the project name or
server name
F - floppy
M denotes the media type
C - CD
which can be
D - DAT
W - weekly
5.6.5 Recovery
Recovery plan should be in place to provide all possible recovery options. This would facilitate
speeding up of the restoration and recovery process during a database crash. Recovery methods will
vary. However, the methods should be described in great detail in a methodic fashion step by step.
This procedure should cover each of the databases.
Application Program
Modules and their Functionality
6.1 INTRODUCTION
This chapter deals with business processes of the different modules of the banking functionality. It is
necessary to have clarity on the basic business requirements of each of the business functions.
Information technology is an enabler. It is envisaged to provide the support to achieve the business
objectives. After understanding the business objectives, one needs to look at the system to verify
whether these objectives are being achieved.
Banks in India have converted their total branch automation system computerization branches to
core banking solutions which enable the banks to have centralized control over the systems,
procedures and operations. This involves creation of a customer ID which will be unique and can be
accessed across all the branches for better and quick customer service.
Reserve Bank of India (RBI) has issued circulars and guidelines for effective implementation of
know your customer (KYC) norms and has laid down the following rules:
In order to prevent identity theft, identity fraud, money laundering, terrorist financing, etc., the
RBI had directed all banks and financial institutions to put in place a policy framework to
know their customers before opening any account.
This involves verifying customers’ identity and address by requiring them to submit
documents that are accepted as relevant proof.
Mandatory details required under know your customer (KYC) norms are
• proof of identity and
• proof of address.
Passport, voter’s ID card, PAN card or driving license are accepted as proof of identity, and
proof of residence can be a ration card, an electricity or telephone bill or a letter from the
employer or any recognised public authority certifying the address.
Some banks may even ask for introduction by an existing account holder. Though the standard
documents which are accepted as proof of identity and residence remain the same across
various banks, some deviations are permitted, which differ from bank to bank.
All documents shall be checked against banks requirements to ascertain whether they meet the
requirements or not before initiating an account opening process with any bank. Thus for
opening a new bank account a set of procedures need to be followed.
In 2004, the RBI had come up with more specific guidelines regarding KYC. These were divided
into four parts as follows:
Customer acceptance policy: All banks shall develop criteria for accepting a person as their
customer and to restrict any anonymous accounts and to ensure submission of documentation
mentioned in KYC.
Customer identification procedures: A customer needs to be identified not only while
opening the account, but also at the time when the bank has a doubt about their transactions.
Monitoring of transactions: Know Your Customer (KYC) can be made effective by regular
monitoring of transactions. Identifying an abnormal or unusual transaction and keeping a watch
on higher risk group of accounts is essential for this purpose.
Risk management: This is about managing internal work to reduce the risk of any unwanted
activity and also managing responsibilities, duties and performing audits in addition to regular
employee training for KYC procedures.
In this background it has become all the more important to ensure that the systems operate with
necessary application/access controls and as per the procedures and guidelines set forth by concerned
banks, during evaluation of controls.
Essentials of each of the processes are listed out so as to help the reader to get an overall view of
what should be expected in the process. An understanding of the flow of process helps the reader to
ensure that all of the features are built into the system. However, it should be noted that the business
process discussed may have variations in different banks. It is essential to understand the specific
requirements of the bank before verifying the functionality of the application.
Name
Address
Age
Occupation
Constitution
Residential status (resident/non-resident)
Photo
Passport details (for non-residents)
Specimen signature
The introduction by an existing customer is mandatory for opening a new account. The bank
officials authorize the acceptance of the customer after satisfying themselves about his credentials and
compliance as per the norms and procedures laid down by Reserve Bank of India (RBI) under know
your customer (KYC) norms.
The details of the customers obtained are fed into the system which go through a process of
validating the above-mentioned details and generate the customer ID. The customer will be in a
position to avail of the various products and facilities offered by the bank after being accepted as a
customer. Banks can refuse to open the accounts for persons not eligible to contract or for persons
whose track record is not satisfactory.
System provides for verifying the existence for such details. The details manually presented are
acknowledged by the data entry operator by making an entry in the system and the same is endorsed
by a supervisory staff or officer.
Customer once accepted by the bank, requests for opening a savings account to deposit his
savings in cash or cheques periodically and withdraw as and when he requires it for various
purposes.
The bank authorizes opening of the savings account after the customer furnishes the mode of
operation, viz. individually, jointly, either or survivor etc. The customer is issued a cheque
book on his request. The cheque numbers are entered in the system.
Savings account is mainly maintained for non-commercial purposes and also earns interest
which is payable on the monthly minimum balance, once in six months.
The banks stipulate a minimum balance to be maintained in the savings accounts and some
penalty is levied for not maintaining the required balance.
The banks cannot refuse payment even if the withdrawal causes the balance to come below the
minimum balance. They can only charge a levy.
Nomination facilities are available which can be registered at the time of opening an account
or even afterwards. This facility is more useful if customer chooses to open the account singly
and not in joint accounts.
Some banks restrict the number of withdrawals per quarter in the savings account.
Since minors can only be beneficiary to a contract, it requires the guardian (natural/court
appointed) to operate the account.
These procedures and guidelines are applicable in the case of the non-resident accounts also.
The NRIs can choose to have a separate non-resident ordinary account for the purpose of
depositing any dividends, rent or any other local credits.
In a core banking solution (CBS) environment these accounts can be opened and operated
from any core banking solution (CBS) branch—a feature called ‘anywhere banking’.
The customer can have the facility of having an ATM/Debit card issued in his name which can
be used to transact through the ATMs and merchant establishments. These facilities are
available only for the individual customers.
In CBS, there would be drop down menus to mark receipt of the above-mentioned documents.
Procedures for opening of current accounts apply for cash credit accounts also.
Cash credit is a credit facility extended as working capital limit to customers whose
transactions are commercial in nature.
This working capital is funded by the banks, and a margin is to be provided by the customer.
The banks provide cash credit limits against hypothecation of raw materials, work in progress
and finished goods in case of manufacturing concerns and stock of goods in case of traders.
The stocks hypothecated to the bank are the primary security and banks may stipulate
additional securities on a case to case basis.
The customers are expected to submit details of paid-up stock held by them every fifteen days
or the period stipulated by the bank in the prescribed format.
The banks calculate the advance value, net of stipulated margin and fix the drawing limit up to
which the customer can avail the credit facility.
The drawing limit will be lower or equal to the limit sanctioned.
In case of high profile cash-credit accounts, the customers are required to furnish the
projections for the next year and their plan for quarterly targets.
The stocks hypothecated with the bank should be insured for all possible risks for the full
value. After manual verification of the insurance policy the data may be entered in the system.
6.3.4 Overdraft
Overdraft is a credit facility sanctioned to the customers against bank deposits, shares,
government and other securities.
Banks also allow clean overdraft facility on selective basis to their reputed customers.
Customers can avail overdraft against their bank term deposits up to the maximum limit fixed
by the bank. Instead of disbursing the entire amount, the bank fixes a limit upto which the
customer can operate in his overdraft account.
The banks mark lien over the term deposits against which the overdraft has been allowed and
unless the overdraft liability is cleared, banks will not release the deposit receipts as the lien
will be marked on the deposits and the system will not allow release.
In case of advances against shares, the stocks should be listed in the approved stock exchanges
and should be freely traded. As the trading in shares are governed by the rules of Security and
Exchange Board of India (SEBI) and most of the shares are held in demat form instead
physical form, banks stipulate higher margin and also take care to register their interests (lien)
with the depositories who maintain the demat accounts.
The banks accept/dispense cash in respect of their customers for different types of transactions
like savings, current and deposit accounts and also for purchase of demand drafts, gift cheques
etc.
Banks follow different methods of recording cash entries. Some banks make direct entries into
the system while some maintain physical registers. The control procedures need to be
evaluated.
The facility of remitting cash for purchase of Demand Drafts (DD), Telegraphic Transfers
(TT), Government transactions are available to the non-customers also (called as walk-in-
customers).
Facility to customers to deposit/withdraw cash at a different branch is available in a core
banking solution (CBS) environment, as part of ‘anywhere’ banking.
Exchange of soiled/mutilated currency can be made through the bank subject to note exchange
regulation rules.
The cash of the branch would be at the vault or with head cashier and tellers.
There are procedures to be followed for moving cash from the vault to the head cashier and in
turn to the tellers at the beginning of the day and shifting the cash balance at the end of the day
to the vault.
The tellers limit for dispensing cash is based on the size of the branch. For the amounts
beyond that limit, authorization for payment by higher authorities is required.
A cash holding limit for every branch of a bank is fixed which is based upon the size/need of
the branch.
Any excess cash balance is to be remitted to the bank’s currency chest/other branches/other
banks, as security risk is involved and also such cash will not earn any interest. However, this
can be verified only manually.
6.5 CLEARING
The cheques/DDs/POs deposited by the customers of the bank are entered in the system which
is done by batch processing.
All the details such as account type, account name, account number, name of the bank and
branch drawn on, instrument number, date and amount are entered in the system.
The banks branches, then present these instruments to the clearing house through the bank’s
link office.
After their account is credited with net of returned instruments, the bank’s branches release the
credits to the concerned customer’s accounts.
The cheques issued by the customers from their accounts maintained in the bank will be
presented by other banks/branches through the clearing house to the bank’s link office, i.e.
service branch.
The instruments drawn on the concerned drawing branch are received from the link office
after the debit of the drawee bank branch account.
The branch verifies the instruments for correctness and then debits the relevant accounts
depending upon availability of funds in the accounts.
The instruments which are not in order (stale/post-dated cheques/incorrectly drawn, want of
funds) are then returned to the banks through the link office.
The core banking solution (CBS) or any software would need to have Master Data.
For instance, in a pay roll software, there would be Master Data for each category of
employees. The basic salary, allowances etc. for that needs to be created so that it is
permanent and is accessed and referred to by all entries for which the Master Data is
applicable.
In case of core banking system (CBS), there could be a parameter for interest application in
the software. This could accept two values, either interest earned or interest paid. For
different products like savings, deposits, loans etc. there would be different interest rates.
There could also be a parameter for interest type which could be either simple or compound
interest.
There could be interest application frequency which could be monthly, quarterly, half-yearly
etc.
The interest application module will work based on all the above-said parameters. Different
parameter values give different outputs.
Thus, it is evident that apart from the way the system is designed, the functioning of the system
is also largely influenced by the parameter settings assigned.
It is important that these parameters are entered in the system with due care.
Some of these parameters might require regular updations like interest rates, charges etc. as
per the business requirements.
The parameterization entries are entered by one individual and authorized by another.
The following are some of the critical parameters used by a Core Banking Application:
(a) List of holidays: There can be no operations on the computer during holidays.
( b ) Authorization rights for exception transaction: This will ensure that whenever
exception transactions are entered/generated, it will not be further processed unless those who
have the right to authorize have done so.
(c) Deposit type maintenance: The list of deposit products available with the bank and the
details regarding interest rate, tenor etc.
(d) Recurring Deposit (RD) penalty master maintenance: In case Recurring Deposit (RD)
installment is not paid on due date, the penalty interest rate that needs to be levied.
(e) Operational parameters
• Account type wise operational parameters
• End of Day (EOD) parameters
• Tax Deducted at Source (TDS) parameters
• ATM parameters
• Anywhere banking parameters
(f) Charges parameters
• Standing instruction charge
• Stop payment instruction charges
• Chequebook charges
• Account closing charges
(g) User related parameters
• Password change parameters
• Signing into the system
• Signing off from the system
(h) Interest related parameters
• Term Deposit interest rate parameters
• Interest calculation for advances
• Interest calculation for staff loans
• Interest calculation for senior citizens
(i) Authorization parameters
• Authorization of users
• Authorization for exceptional transactions
6.7 LOG MAINTENANCE
Logs are the records of activities or events that have taken place in the system across all
modules.
These give details about
• The activity
• Users, system
• Date and time
These logs provide important evidence to prove that a transaction occurred. It is important that
these logs are preserved properly.
Also these logs should be confidential and should not be modifiable as otherwise the very
purpose of the log is lost.
It must be ensured that logs are accessible only by the authorized persons.
The bank guarantees are those issued by the banks on behalf of their customers in favour of the
third parties guaranteeing to fulfill the terms of the guarantee in case of any default/non-
performance of the contract entered into by the customers with the third parties.
Normally, the guarantees are classified as performance and deferred payment guarantees. The
customers approach their bankers for the issue of guarantees for purchase of goods,
machineries, etc. and also for receiving their dues after executing the contracts.
For the issue of guarantees, the banks stipulate certain margins and also collaterals depending
on the creditworthiness of the customers and business requirements.
The banks collect commission for issue of the guarantees depending on the period of the
guarantee and also the claim period.
The period of guarantee will also cover the claim period within which the claim, if any should
be made.
The various government departments and certain other organizations seek issue of guarantees
as per their required format. The terms of the guarantee can be invoked in case of non-
performance. The banks are required to have these formats approved by the banks’ legal
adviser for any onerous clauses so that the banks may not face any problems if their guarantees
are invoked and claim made.
Deferred payment guarantees are those which are issued by the banks for their customers to
enable them to purchase machineries and equipments on a medium or long term basis.
The customers and their suppliers enter into an agreement wherein the suppliers agree to
supply the machineries, subject to the customers furnishing a guarantee from their bankers
towards the cost of the machineries in case of any default by the buyers.
The customers have to meet their commitments over a period of time by way of accepting the
Hundi bills drawn payable on different dates which may even extend over a period of 10
years or more, duly guaranteed by the bank.
The customer has to furnish a counter guarantee in favour of the bank undertaking to meet the
liability if guarantee is invoked.
If the beneficiary invokes the guarantee for non-performance/payment and if the customer fails
to meet the liability created, the bank will debit the defaulted account and make the payment
(up to the value of the guarantee) demanded by the beneficiary.
The bank recovers the defaulted guarantee amount from the customer along with the prevailing
interest.
6.9 BILLS
The up country banks/branches send the cheques/bills drawn on the customers for collection
and the cheques are debited to the customers account subject to the availability of funds and
the proceeds are remitted to the drawer bank.
In case of bills, the bank sends intimation to their customers for having received the bills
drawn on them and with an instruction to retire the same as per the terms and conditions
stipulated by the drawer (charges, demand and usance).
The customer pays the bill amount and receives the documents, viz. invoice and transport
documents.
Letter of credit means any arrangement whereby a bank (issuing bank) acts on the request and
on the instructions of a customer (applicant). The instructions would include:
• to making payment to or to the order of a third party (beneficiary), or accepting and paying
bills of exchange drawn by the beneficiary; or
• Authorising another bank to effect such payment, or accepting and paying such bills or
exchange; or
• Authorising another bank to negotiate against stipulated documents provided the terms and
conditions of the credit are complied with.
The customers who are engaged in the manufacture/trade approach bank for opening letters of
credit for purchase of goods/machinery etc. with which supplier is willing to execute the
order subject to the customers’ bank assuring payment by way of letters of credit.
Letter of credit can be revocable or irrevocable based on the requirements of the
customer/supplier.
Beneficiaries in some cases may insist for confirmation of the Letter of credit by a different
bank called the confirming bank.
A confirmation of an irrevocable credit by another bank (confirming bank) upon the
authorization or request of the issuing bank, constitutes a definite undertaking of the confirming
bank in addition to that of the issuing bank.
Letters of credit can be opened for supply on sight/usance basis and terms and conditions as
per the agreement with the suppliers.
The customers can opt to have cash credit/term loan limits for covering the bills drawn under
letters of credit.
In case of letters of credit (foreign), the customer is expected to have to importers/exporters
code allotted by the Reserve Bank of India (RBI).
The shipping terms (viz. Trans-shipment, part shipment) and documents required (Invoice,
certificate of origin, shipping, insurance, and any other documents as the case may be) are
incorporated in the letters of credit established.
The letters of credit so opened should be accepted by the supplier for the correctness and if
any amendments are required, it should be informed to the issuing bank to carry out necessary
amendments.
All requirements for business process would need to be the contents of the different screens of
the particular module.
6.11 REMITTANCES
The process involves remittance of money by way of demand drafts and mail transfers drawn
on upcountry branches and only where the banks are having their branches, at the request of
the purchasers (customers and non-customers).
The remittance can be by way of bankers cheques where the branches of the banks are situated
locally. This type of transfer of money is named as remittances under banking jargon.
The remittances so made are paid to the payee at the paying branch.
Normally, the remitting banks dispatch advices for having emanated the transactions
(applicable in case of non-CBS branches to CBS branches and vice versa). In case of CBS,
this will be inter-branch transaction.
If the demand drafts are presented before the advices are received, the paying branches pay
and then debit the ‘Demand drafts paid without advice’ and this head is reversed as soon as
advices are received.
The transactions are reported in the Inter branch daily report both by the issuing and paying
branches and the reconciliation of the entries are carried out. The pending entries are
followed up for reversing the same.
The banks collect exchange for issuing these remittances as per the guidelines of their
corporate office.
As per the present Reserve Bank of India (RBI) guidelines, remittances by way of CASH are
restricted to Rs. 50000 including the exchange and any remittance over and above this amount
can be done only through the customers’ account.
Thus, non-customers cannot apply for a CASH DD/MT/TT/BC in excess of Rs. 50000.
6.13 DEPOSITS
6.14 ADVANCES
The banks collect both demand deposits and term deposits and out of the same they are
expected to maintain Statutory Liquidity Ratio (SLR) and Cash Reserve Ratio (CRR) with the
RBI and out of the balance available they lend to priority and non-priority sectors.
• Priority sectors:
• Agriculture
• Small scale industry
• Small transport operators
• Small business enterprises
• Government sponsored schemes
• Exports
• Housing (under National Housing Bank)
• Non-renewable energy
• Non-priority sectors:
• Consumer loans
• Transport
• Real estate
• Large and medium scale industries
• Housing
• Wholesale traders
The advances are made to entities in India both in local currency and also in foreign currency.
The loans are classified as unsecured (clean) and secured advances. The secured advances
are those backed by securities (primary and collateral).
The primary security is one where assets are created out of the loan amount and collateral
securities are those which are obtained by the banks in addition to the primary securities.
These securities are charged to the bank by way of lien (e.g. bank deposits), hypothecation and
pledge (e.g. stocks, goods, vehicles, plant and machinery) and mortgage (e.g. immovable
properties).
Drop down menus/list of values will be available in the system to choose the nature of charge
on the securities.
Maker checker concept is required to execute the process.
In the event of the advances becoming bad and doubtful of recovery the banks fall back upon
these securities to realize the dues.
In addition, the banks also have the right of general lien over the assets even if they are not
charged to them.
SECTION A.........................................................CHAPTER 7
The team will consist of senior experienced staff with a thorough knowledge of banking processes.
This team will participate in customisation. Customisation would include all areas of input, process
output and also generation of reports. Customisation is a process wherein the software as provided by
the vendor, is modified wherever necessary to suit specific additional requirements of the bank. This
team will freeze the specification for the CBS. Eventually, this team will participate in the acceptance
testing. (Final testing of the software before it can go live.)
The above-mentioned process of customisation and testing is very critical and is an important
phase. After the completion of these processes, data migration and implementation process is
commenced.
The process of migration could be broken into the following phases.
1. Customer data migration: All the existing individual customers and corporate customers,
having either one or more accounts along with the linkage of deposits/loans are to be
migrated.
2. Account migration: All existing savings bank accounts, current accounts, cash credit accounts
and overdraft accounts linked with valid customer IDs need to be migrated with a few
exceptions, if any.
3. Deposit migration: All deposit account details need to be migrated along with instalments
paid and unpaid details. It should also include details regarding interest applied, interest
liquidated, the tax deducted at source etc.
For all deposit accounts for which TDS has been applied, such details along with the date of
such deduction need to be migrated.
Details of deposits overdue for renewal should be migrated for application of correct interest.
4. Loan migration: All live loan accounts properly linked to a valid customer ID are to be
migrated. For all loan master details successfully migrated, the following further details also
need to be included:
• Loan instalments/EMI collected, not collected
• Interest amount due and interest amount paid
• Arrears and overdue repayments
5. Bills migration: All pending bills—Outward Bills Collection (OBC), Inward Bills Collection
(IBC) and Usance Bills Collection (USB) which have linkage to savings bank accounts,
current accounts, cash credit accounts and overdraft accounts need to be migrated. Contra
entries are also to be migrated.
6. Bank guarantee/letter of credit: All pending Bank Guarantee (BG)/Letter of Credit (LC)
amounts which are linked to savings bank accounts, current accounts, cash credit accounts and
overdraft accounts need to be migrated.
7. Chequebook issue migration: All savings bank accounts, current accounts, cash credit
accounts and overdraft accounts for which cheques have been issued need to be migrated.
8. Cheques ‘stop payment’ migration: All stop payment instructions for cheques issued need to
be migrated.
9. Cheques status migration: Status of issued cheque leaves/books are to be migrated.
10. Transaction data migration: For all successfully migrated savings bank accounts, current
accounts, cash credit accounts and overdraft accounts, deposits and loans, balances as on the
date of migration are to be migrated.
11. Remittance issue migration: All DD, pay orders issued for the last six months are to be
migrated.
12. Remittance advice migration: Pending Demand Drafts (DDs) payable, Demand Draft Paid
Without Advice (DPWA) pending as on the date of migration are to be migrated.
13. Stock statement migration: For all Open Loan Cash Credit (OLCC) accounts successfully
migrated, default stock statement as on the date of migration with a drawing power to the tune
of 100% of the limit will be migrated. This would be corrected later at the front end to come
in line with the exact drawing power entered after the migration is completed.
14. Savings bank minimum balance migration: For a savings bank account successfully
migrated, savings bank minimum balance as on the date of migration is to be migrated.
15. Limit migration: For all bills, bank guarantees, letter of credits, customer’s limits are to be
migrated based on customer ID as no limit is required to be migrated for cash credit, overdraft
accounts.
16. FTF Related: All foreign currency related transactions, may not be migrated as the same may
be separately migrated at the time of Foreign Trade Finance (FTF) migration.
As part of the migration, the branch at the minimum has to ensure the following
Once the branch is ready for migration in all aspects, the data as obtained from the branch will be
taken for a test run. A mock migration is arranged at computer systems department for confirmation
that the branch may be taken for migration.
CSD has to ensure that there are no problems in file format changes. It has to be further ensured that
the extracted data is correct in all respects. This is done by verifying the pre-migration general ledger
with that of the extracted general ledger.
While in the process of migration, it would be useful to have exception reports being generated to
facilitate correct and complete migration.
A suggested data migration exception reports list is as follows. It is illustrative only and not
exhaustive.
1. Deposit amount and interest rates should be within the Min and Max permissible deposit
amount as defined in product parameter.
2. Last and next interest accrual/application date
3. Next interest fixing date should be greater than or equal to next interest credit date.
4. Next interest fixing date should not be greater than the maturity date in case of cumulative
deposits.
5. Interest committed to the depositor at the time of opening should be taken care of.
6. Total applied/settled interest should be taken care of.
7. Mandate for receipt/payment of interest to be given effect only if such accounts are already
migrated.
8. Number of paid instalment in case of Recurring Deposit (RD) and loans has to be checked.
9. Non-Performing Assets (NPA) details need to be manually uploaded. (Protested bills—suites
filed and decreed; Principal and memorandum of interest; security details; NPA classification
—substandard, doubtful and loss assets)
Compatibility of fields
Fields additionally provided or available in the core banking solution (CBS) after migration and not
required to be masked.
Transaction listing
Transaction listing is to be uploaded in case of bills and inter branch transactions, while making sure
that the listing of transactions is available at the branch in the legacy database.
Bills migration
Bills/cheques discounted, due date, accrued interest, particulars are to be migrated.
Inventory
On hand stock of all numbered items like cheques/DDs are to be migrated.
Clearing
Pending clearing details of all instruments are to be migrated.
Permanent Account Number (PAN)
Permanent Account Number (PAN) details are to be migrated, wherever it is mandatory.
As a parallel activity, technical personnel need to verify the network connectivity of the branch to
the central data center. The details as mentioned in Annexure A of this chapter need to be collected.
Tests as mentioned in Annexure B need to be performed.
ANNEXURE A
BRANCH ACTIVITY ACCEPTANCE REPORT
BRANCH DETAILS
Phone ................................................
Phone ................................................
Manager (Mobile and Residence)
................................................
.
WAN EQUIPMENT DETAILS
Item Model/Description Serial No
ANNEXURE B
RESPONSE TIME TESTS—NEXT HOP ROUTER
1. Ping test with packet size of different bytes
Command: ping -t <next hop nodal router IP>
Sl. No. Source IP Destination IP Response Time Acceptance Value
Machine 1
Machines 1 and 2
Machines 1, 2 and 3
Step VI: Start ping test again, ISDN link should come up automatically.
PASS FAIL
Step VII: While ping is running, switch on the leased Line modem.
Step VIII: The ISDN Link should go down after few seconds. Ping should continue now through
leased line.
PASS FAIL
ROUTER CONFIGURATION
<ATTACH ROUTER CONFIGURATION>
SECTION A.........................................................CHAPTER 8
ATM Functionality—
How It Works
8.1 INTRODUCTION
Automated Teller Machine (ATM) is a computerized telecommunication device that provides the
customer of a financial institution with access to financial transactions in a public space without the
need for a bank teller.
Cash withdrawal
Balance enquiry
Mini statement of account
Registering request for cheque book etc.
Personal Identification No. (PIN) change
All of the ATMs are connected to a switch and the switch is connected to the server of the bank
through internet connection. A switch is also a server.
The ATMs may be connected to the switch by any of the following means:
Leased Line
VSAT (Very Small Aperture Terminal)
Dial Up Line
A single database of all of the customers of the bank is stored in a database server located in the
data center of the bank.
It is possible by arrangement that an ATM of Bank-A could be used not only by the customers of
Bank-A, but also of banks-B and C etc.
The banks which provide facility for the customers of multiple banks would have executed an
agreement to provide such facility. There would be bilateral agreements so that switches of
participating banks are linked. The service at the switch may be provided also by a third party switch
service provider.
Brief description of the functioning of the ATM
Step 1: A customer who has been provided with an ATM card swipes the card through the specific
place provided in the ATM hardware. The information provided in the magnetic strip is read by the
machine.
Step 2: The customer has to key in, his Personal Identification Number (PIN).
Step 3: The PIN which is a very sensitive data is encrypted. The encryption process may be by
means of a hardware (also called as PIN machine) or software which forms part of the ATM. The
Security Model (Hardware Security Model—HSM or Software Security Model—SSM) encrypts the
PIN by means of an encryption algorithm loaded into the machine by the officers of the bank when the
ATM is commissioned to ensure that security of the algorithm is maintained. The banks generally
ensure that it is performed by two the officers of the bank—one officer performs one part of the
function and the second officer performs the balance of the function.
Step 4: When the account number and PIN provided by the customer tally with the data available at
the database of the switch and the PIN generated by the PIN machine, the customer who swiped the
ATM card is authenticated as a genuine customer of the bank. It needs to be noted that any person who
picks up an ATM card would not be able to initiate an operation unless he also has information about
the PIN associated with the card.
Step 5: The switch having authenticated the customer, passes on the information through the
communication line to the database of the bank which is held in the server of the bank. This operation
is to ensure that the authorized customer has sufficient balance in his account to perform the operation
which he desires to do, e.g. cash withdrawal.
The customer would have mentioned the amount he wishes to withdraw by giving the data at the
ATM. The ATM switch passes the data to the database server which in turn would authorize
dispensation of cash required as the customer has the requisite balance.
The operation of activating the cash dispenser is triggered by the facility available at the ATM
switch. Then the cash is dispensed to the customer who picks up the required cash.
Step 6: Once the cash has been picked up by the customer, the reverse process would take place by
which the ATM switch has information that the cash has been dispensed and from the switch, the
information is passed on to the database.
Step 7: At the ATM, cash journal and ATM log are generated. These are the important documents
used for the reconciliation purposes. Also there are electronic journals which are generated at the
ATM. These can be accessed and retrieved from a remote location through a process called as
Electronic Journal Pulling (EJP).
Step 8: Inter Bank Transactions—While the process is similar, it is to be observed that soon after
the ATM card is swiped by the customer, information is available as to which bank the card belongs
to, and hence, is directed to the ATM switch of the corresponding bank. The process of authentication
and authorization would be similar. The database of the card issuing bank would be accessed and
information sent back to the ATM for completing the operation of cash dispensation.
In case, ATM reports error, e.g. the cash may not have been taken out by the customer in time, (in
such a case, the cash is pulled back into the machine) the ATM would report the error. The switch
would request the host for reversal of entry. The switch and the host computer log all the events (see
Figure 8.3).
It should be noted that only by knowing the PIN of a customer one cannot access the machine unless
he inserts the ATM card of that customer. If card and PIN, both are available to a third party, misuse
is possible.
Change of PIN by customers
When customer wants to change the PIN, he has to convey the fact that he plans to change the number
by pressing on the Key pad—‘Change No.’ He will be expected to give the old PIN and then only key
in the new PIN. When he keys in the old PIN natural PIN is generated and card number compared
with that stored to satisfy itself that he is an existing ATM card holder. The corresponding offset
value is pickedup and internally the existing PIN of card holder is generated. This is compared with
the PIN keyed in by the customer before asking for a change. When they tally, the customer is
permitted to key in the new PIN. As the natural PIN value is available, new offset value is computed
and old offset value is erased. The old PIN or the new PIN should not be stored anywhere.
Confirmation of natural PIN generated from the card of customer and new offset number would be
the basis for generating the customer PIN for comparison with the PIN keyed in by the customer.
Special circumstances: When ATM may not be operational:
If there is a hardware problem the monitoring team contacts the vendor of the hardware, who
would act according to the service level agreement entered into with him and take necessary
steps to put the machine back in action.
If cash is inadequate, either the branch manager (if the ATM is connected to the branch) or an
independent cash loader who is responsible for loading the cash would be intimated about the
inadequacy of cash to facilitate immediate action being taken to load the cash at the ATM
kiosk.
If the journal paper roll has been exhausted, necessary steps will be taken to replace the used
up paper roll with a new paper roll.
In case of use of a card, a cardholder is expected to key in his Pin. If he makes a mistake, he gets
three attempts altogether to do it correctly. However, after the third attempt the card is rejected.
A customer might lose a card or his card might have been stolen. He would have informed the
concerned bank and it would have been hotlisted, i.e. to say that the card would not be accepted if
ever presented. However, if a person who has stolen the card or a person who is wrongly in
possession of the hotlisted card inserts in the ATM machine, it will be swallowed by the machine.
Customer applies to the bank branch for Internet banking facility. In most banks, this facility is
automatically provided when a bank account is opened. The customer is provided with user
ID and password and is advised to change the password soon after the first logon.
The customer using a browser (like Internet Explorer) accesses the website of the bank in the
normal course.
The website is hosted in the web server that is placed in a de-militarized zone behind a
firewall. The firewall filters all the traffic except that which are addressed to the web server
through the authorized port.
The web server displays the bank’s web page to the customer.
The web page has provision for customer to enter the user ID and password.
The user ID and password of the customer is encrypted and sent to the bank’s web server.
The web server forwards the customer details to Internet Banking Application Server (IBAS)
which authenticates the customer by verifying the user ID and password with the data stored in
the Internet Banking Application Server (IBAS).
Based on the authentication check, the Internet Banking Application Server (IBAS) sends an
acknowledgement to the web server which in turn informs the customer (in the browser).
If the user ID or password is not correct, an error message is displayed. After consecutive
failed login attempts (usually three), the bank freezes the customer’s internet banking facility.
The customer has to request the bank to re-activate the facility in some cases after a few hours
the facility is automatically re-activated.
Once the customer is logged in, Internet banking services offered by the bank are displayed.
The following are the Internet banking services provided by many banks:
(a) Balance enquiry
(b) Fund transfer
(c) Chequebook request
(d) Stop payment request
(e) Cheque status enquiry
(f) ATM/credit card related queries
(g) Password change
The customer chooses the service from the web page. The web server directs the service
request to the Internet banking application server for processing.
To process the service request, the Internet Banking Application Server will need customer
details which are stored in the central database server. The bank’s central database server
being a critical server can be accessed only through a firewall.
The Internet Banking Application Server (IBAS) sends the data requirement to the Internet
Banking Database Server (IBDS) which retrieves the data from the central database server
that is accessed through a middleware and a firewall. The middleware converts the data to
suit the requirements of the Internet Banking Database Server where the data is temporarily
stored.
The Internet Banking Database Server (IBDS) now sends the customer data to the Internet
Banking Application Server (IBAS) which processes the transaction.
After processing the customer service request, the Internet Banking Application Server
(IBAS) sends the details to the web browser.
The web server generates a dynamic web page for the service request and presents it to the
web browser in encrypted form.
The customer may choose to log out or perform any other transaction.
Once the customer is logged out, the customer’s session on the web server is closed and the
transaction details in the Internet Banking Database Server (IBDS) are purged.
The customer is advised to clear the cookies (cache) that were created and stored temporarily
in the customer’s system when the customer was logged on to his Internet banking account as
these contain confidential information. (To clear internet cookies, one may go to
C:\Documents and Settings\“Windows login name”\Cookies.)
It needs to be emphasized that if internet banking is not properly implemented, it could lead to
security issues ranging between privacy issues to wrong or fraudulent transfer of funds by
account holders.
A pictorial presentation of internet banking data flow has been shown in Figure 9.1.
Figure 9.1 Internet banking—data flow.
The objective of utilizing Real Time Gross Settlement (RTGS) is to the enable a customer
belonging to one branch of a bank (say Bank-A) to transfer funds to customer of another bank (say
Bank-B) on a real-time basis. This facility is also used to transfer funds between the banks.
This is possible only if both the banks are recognized as participant banks by RBI.
The transaction, which represents the amount a customer wishes to transfer through RTGS to
another account in Bank-B, is entered in the client machine at the Bank-A. The client machine is
connected to the server.
Each of the participant banks is allotted a code number—Indian Financial System Code (IFSC).
Similarly, each of the branches of the participant bank of RTGS is allotted a unique code (called as
RTGS branch code). A combination of these two codes act as the identification.
The transaction entered is transmitted to the bank’s focal point, where the Participant Interface (PI)
is located. The PI handles the creation and processing of inward and outward messages. The
messages are encrypted and transferred to the Inter Bank Funds Transfer Processor (IFTP) which in
turn transmits the same to the RTGS system at Reserve Bank of India (RBI).
From RBI, the message is transmitted to IFTP which is transmitted to the focal point of the recipient
bank where its Participant Interface (PI) is located. The message is transmitted from that PI to the
appropriate branch of that bank which would credit the account of the intended recipient. This whole
process takes place in ‘Real Time’. The transactions are handled individually. The transactions are
settled individually on a ‘Gross’ basis as against the normal clearing which happens on a ‘Net’ basis.
This briefly describes the Real Time Gross Settlement System.
Figure 9.3 shows a diagrammatic description of the flow of transactions. The figure includes more
details which are discussed in the paragraphs following the figure.
The clearing entities to the banks participate in RTGS system for settling high volume payments.
The RTGS system, consists of, as we have observed, the following main components:
(a) Participant Interface (PI)
(b) Inter Bank Funds Transfer Processor (IFTP) at RBI
(c) RTGS system at RBI
(d) Communication system
(e) Encryption process of transaction.
The participant interface comprises of three modules at the server level as follows:
(a) Gateway module (GM) on GM server
(b) Outward Message Manager (OMM) on OMM server
(c) Inward Message Manager (IMM) on the IMM server
The Participant Interface (PI) client is a common front end for all three—OMM, IMM and GM.
Using the PI client, one can not only enter and verify messages but also perform enquires and generate
reports. It contains a tool—User Control Tool (UCT) available at the client which enables
configuration of the required parameters at the server.
The RTGS branches are connected through WAN to the RTGS focal points of the bank.
The PI server stores the user profile. User access is controlled vide user profile and smart cards (if
configured).
Smart card is a plastic card with a micro-processor embedded in it which contains the digital
certificate and encryption keys specially created for the user. Smart cards are used to verify a user’s
identity and to digitally sign messages sent by the user.
The profiles are retrieved, based on the user information and is displayed in the form of many
options in the PI client. All PI server modules run as background processors on the PI server. A PI
uses the queue concept to route messages.
Gateway module (GM): The gateway module which is part of the Participant Interface (PI)
manages the connectivity and transfer of messages between PI and the Inter-Bank Funds Transfer
Processor (IFTP) (Please refer to Figure 9.3 of the chapter). Using the GM, PI connects to the RTGS
system vide the IFTP. The main purpose of GM is the transferring of messages between Participant
Interface (PI) and IFTP. Messages sent to the IFTP (outward messages) are assigned message
sequence numbers by the GM before they are sent. The GM starts receiving all inward messages from
IFTP after establishing a connection with it. The PI client controls the flow of outward messages, but
inward messages are not controlled. They continue to flow as long as its connection with the IFTP is
active. This ensures that PI (Participant Interface) and IFTP receive all messages and that no
messages are lost.
However, message is sent and encrypted before being released to IFTP and decrypted on receipt
from IFTP using the crypto server. The crypto server is on a dedicated server. The crypto server is a
cryptographic system. The system could be either a smart card or a hardware security module. This is
supplied by Institute for Development and Research in Banking (IDRBT).
Outward message manager (OMM): The Outward Message Manager (OMM) module supports the
entry, authorization and release of outgoing messages. In addition to creation of messages, PI also
receives messages from external applications such as the bank’s host system. The messages when
being created could be completed or saved as a draft. Messages are classified as ‘awaiting
completion’, ‘awaiting authorization’, and ‘awaiting release’ and suitably allotted to the appropriate
queue.
Messages can be modified while they are in the ‘awaiting completion’ or ‘receive sub queue’. If no
modification is needed, they are marked as complete.
(a) Message authorization: As sort of authorization process, certain fields must be re-entered
(key verification). The authorization is successful only when the key verification is successful.
Messages in the ‘awaiting authorization’ sub-queue need to be authorized by a supervisor with
appropriate permission.
(b) Message release: When the outward message status is set to “sending”, the GM sends payment
messages from the ‘awaiting release’ sub queue to the IFTP. Payment messages are moved to the
awaiting IFTP acknowledgment sub-queue after releasing them to IFTP.
(c) Settlement: When a payment is settled, the GM receives the settlement notification from the
IFTP. The original payment message is moved to the settlement sub-queue. If the settlement fails, the
IFTP sends a negative settlement notification and the original message is moved to the cancelled sub-
queue.
It is also possible to send a cancellation request to cancel the initiated payment. If the cancellation
request is successful, original payment message is moved to the cancellation sub-queue.
The payment message is final only when it is in the settled, cancelled or rejected sub-queues.
Inward message manager (IMM): The Inward Message Manager (IMM) handles the management of
incoming messages from the IFTP. It also processes responses, notifications and acknowledgments.
The IMM also has separate queues for different purposes. Acknowledgments are provided by the
IFTP to the IMM for outward financial transaction requests, sent originally through OMM.
The IMM module also supports the creation of output files for the payment messages received.
The acknowledgment received from IFTP may be positive or negative. A positive acknowledgment
means that the message was accepted and has been forwarded to the RTGS system for processing.
Table 9.1 shows a comparative study between the present clearing system and RTGs.
Table 9.1 Comparison between the present clearing system and RTGS
Basis of distinction Present clearing system RTGS
Sattlement basis Net Gross
Time of Settlement As specified in-house Continuous basis
Based on Physical instruments Electronic messages
Initiated by Person receiving (payee) Person making payment (drawer)
High value—day 0
Local instruments
Receipt of funds Continuous basis
T + 1 Outstation—
More time
Immediate, final and
Finality of settlement Only after clearing return
irrevocable
Insufficient funds
Due to operational mistakes
Returns Instrument being stale
like incorrect A/c number
Stop payment
Multiple collection centers across the country where the instruments can be deposited.
No separate account is required to be opened in different centers.
Credit is offered to the clients on an agreed mandate in clients’ main account at the pooling
center the same day as cleared—even credit against uncleared instruments may be offered on a
discretionary basis.
Customized MIS to customers—location wise/party wise etc. even advanced features like
MIS through E-Mail, SMS are also available.
SECTION A............................................CHAPTER 10
Security Policy
10.1 INTRODUCTION
The objective of security policy is to provide management direction and support for information
security within the bank. The policy applies to the entire bank and to all of its employees, vendors
dealing with the bank and others who may be authorised to deal with the information assets of the
bank. The policy will clearly lay down that employees who have deviated from the best practices
prescribed in the policy would be deemed to be guilty of dereliction of duty and accordingly,
disciplinary action will be taken, which may also lead to termination of employment.
The security policy document would enunciate the policies. It will also be supported by the
guidelines which represent the best recommended practices and the rationale behind the policy.
Procedure would also be laid down for implementing policy. It would be generally preferable to
have a separate policy document and have the guidelines and procedures in yet another document.
In the following pages, a specimen ‘security policy’ is provided. It has been drafted for a
hypothetical organization. It is intended to be illustrative and not exhaustive.
It is essential for all the organizations including banks to have a security policy duly approved by
the management to be in place. There needs to be a machinery to implement the policy.
RBI has laid down that all banks need to have a security policy in place. The existence of the
policy and its implementation is a matter of importance.
10.2.1 Introduction
The document details the information security policy of xxx Bank Limited. It is intended to provide a
common basis for developing effective security management practice across the organization and to
provide confidence in inter-organizational dealings. Adherence to the specific policies listed in this
document is mandatory for all employees of the organization, and vendors dealing with the
organization.
The company security policy document also contains the procedures for implementing the policies
and guidelines along with do’s and don’ts.
10.2.2 Objective
The objective of this information security policy is to provide the management with direction and
support for information security within the organization in accordance with the business requirements
and relevant laws and regulations.
This policy shall be approved by the management, published and communicated to all the
employees and relevant external parties. This policy shall be reviewed at planned intervals or in case
of the occurrence of any significant change.
10.2.3 Scope
This security policy applies to the entire organization and to all its employees, customers who have
been provided direct access to the organization’s assets and vendors dealing with the organization.
10.2.4 Enforcement
Any employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment. The external service providers found to have violated this
policy may be subject to financial penalties, up to and including termination of the contract.
10.2.5 Exception
Any exception to the policies shall be formulated by the Information Security Committee and
approved by the steering committee.
10.8.8 Monitoring
To detect unauthorized information processing activities, audit logs recording user activities,
exceptions and information security events shall be produced and kept for an agreed period to assist
in future investigations and access control monitoring. Procedures for monitoring the use of
information processing facilities shall be established and the results of the monitoring activities need
to be reviewed regularly.
Logging facilities and log information shall be protected against tampering and unauthorized
access.
The system administrator and system operator activities shall be logged. All kinds of faults shall be
logged, analyzed, and an appropriate action taken. The clocks of all relevant information processing
systems within an organization or security domain shall be synchronized with an agreed upon accurate
time source.
10.12 COMPLIANCE
10.12.1 Compliance with Legal Requirements
To avoid breaches of any criminal and civil law, statutory, regulatory or contractual obligations and
of any security requirements, all relevant statutory, regulatory and contractual requirements and the
organization’s approach to meet these requirements, shall be explicitly defined, documented, and kept
up-to-date.
The appropriate procedures shall be implemented to ensure a proper compliance with legislative,
regulatory, and contractual requirements on the use of material in respect of which there may be
intellectual property rights and proprietary software products.
All the important records shall be protected from loss, destruction and falsification in accordance
with statutory, regulatory, contractual, and business requirements. Data protection and privacy shall
be taken care of as required in relevant legislation, regulations and applicable contractual clauses.
Users shall be deterred from using information processing facilities for unauthorized purposes.
10.12.2 Compliance with Security Policies and Standards, and Technical Compliance
To ensure the compliance of systems with organizational security policies and standards, managers
shall make sure that all security procedures within their area of responsibility are carried out
correctly. All the information systems shall be regularly checked for compliance with security
implementation standards.
Branch operations
Savings bank
Current account
Fixed deposit
Draft issuing, etc.
ATM operations
Internet banking
RTGS etc.
Risk value calculations need to be done for Information Technology (IT) assets also as in a bank
dependency on the same is very critical.
A template as shown in Table 11.1 could be used for computing risk value for the assets.
Table 11.1 Computation of risk value
Probability
Risk ID Type of risk Existing DR mechanism Effect on service Impact Aggregate risk value
of occurrence of risk
Some of the IT assets to be included for risk assessment are mentioned hereunder:
(a) Core banking database server
(b) Application server
(c) Web server
(d) FTF server
(e) Internet banking server
(f) RTGS server
(g) ATM server
(h) Network Infrastructure
(i) Personnel making critical functions
11.2.1 Type of Risks
The various risks to be considered (depending upon the type of service, certain risks may not apply)
would include the following:
1. Failure of primary Wide Area Network (WAN) links between the branches and the data center
2. Complete failure of the router
3. Router Internetworking Operating System (IOS) failure
4. Router configuration corruption
5. Router serial port failure
6. Router serial port cable failure
7. Router ethernet port failure
8. Failure of the router backup BR 1 ports providing backup connectivity to branches
9. Failure of power supply module
10. Non-availability of support personnel
As regards the firewall and intrusion detection systems, following could be the failures:
Assessment of risks
The risks associated with various business processes and IT resources are assessed. A general
relational rating system of ‘High’, ‘Medium’, ‘Low’ and ‘Very low’ is used initially to identify the
probability of threat occurring (see Table 11.2).
Table 11.2 Risk assessment
Impact value range
Impact class
From To
High 1000 3100
Medium 500 999
Low 100 499
Very low 0 99
The impact of each type of potential threat on various functions or departments within the bank is
considered in the Risk Analysis Report.
An illustrative table summarizing threat with impact on the business processes is provided. Impact
value is arrived at after initially considering the individual processes and thereafter the total impact
is calculated by summing them.
These values are arrived at without taking into account the containment measures that are in place.
The values thus arrived is classified as high, medium, low and very low. In an exercise performed the
values ranged from 200 to 3100. The classification of range was done as shown in Table 11.3.
Table 11.3 Classification of range
Impact
Sl. No. Threats description % of total impact value Criticality
value
1. Telecommunication failure 3060.0 11.17 High
2. Employee resignations 2304.0 8.41 High
3. Network failure 2160.0 7.89 High
4. System software failure 2124.0 7.76 High
5. System failure 2124.0 7.76 High
6. Application software failure 2016.0 7.36 High
7. Fire/explosion (external) 1848.0 6.75 High
8. VA/C failure 1608.0 5.87 High
9. Computer crime 1488.0 5.43 High
10. Power failure 1120.0 4.09 High
11. Fire/explosion (Internal) 1044.0 3.81 High
12. Flood (internal) 876.0 3.20 Medium
13. Flood (external) 732.0 2.67 Medium
Failure of detection/alarm
14. 640.0 2.34 Medium
system (technology)
Failure of detection/alarm
15. 640.0 2.34 Medium
system (human)
Failure of detection/alarm
16. 584.0 2.13 Medium
system (natural)
17. Robbery/burglary 400.0 1.46 Low
18. Major accident 392.0 1.43 Low
19. Storm 342.0 1.25 Low
20. Structural collapse 324.0 1.18 Low
21. Embezzlement 312.0 1.14 Low
22. Earthquake 244.0 0.89 Low
23. Epidemic 234.0 0.85 Low
24. Vandalism 232.0 0.85 Low
25. Terrorism 232.0 0.85 Low
26. Bomb threats 228.0 0.83 Low
27. RSCC 41.0 0.15 Very Low
28. Work stoppage 37.0 0.14 Very Low
Potential vulnerabilities that exist or may exist in the bank should be evaluated to ensure
appropriate threat containment measures are in place to protect the assets with high impact.
For arriving at final risk value for purposes of prioritizing control measures, information is
collected as shown in Table 11.5.
Table 11.5 Collection of information
Existing Probability
Threat control Vulnerability of Impact Risk value
mechanism occurrence
Employees resignation
Fire
Flood etc.
The study of business process of bank would remain the same, irrespective of the supporting
technologies. As the emphasis of the book is on core banking solution, examples of possible risks
scenarios could be as mentioned below.
The scenarios given below are likely to occur and cause disruptions. For each scenario, certain
steps are to be taken which are mentioned herein below along with the acronyms:
Scenario 1: No Access to Computer Services Department (CSD) building and also to the Data
Center (DC) site.
Steps to be taken
1. Call the team members to meet in the designated Center (ABC City) which would be the
alternate site.
2. Disaster recovery files have to be manually brought up.
3. Call all the branches except ABC City branches.
4. All other branches will connect through the Integrated Subscribers Digital Network (ISDN) to
the disaster recovery site.
5. Continue the process until normalcy is restored.
1. The ABC City branches will not have connectivity, but all the other branches will be
connected to data center.
2. Call for a meeting at a designated place.
3. Re-route the city branches to the data centre.
Note: xxx minutes data will be lost. All the branches to be informed to key in the data lost. Similar
procedure applies for other delivery channels like ATM, Internet Banking, FTF. The transactions
which have been processed through the channels have to be manually entered into the system.
Scenario 4: CSD and DC sites are available, but no connection to all branches and head office.
Since there is redundancy in the network, DC will be accessible through other communication
channels. Disaster recovery site will be accessible. The network diagram is enclosed for ready
reference.
Scenario 5: CSD and DC sites are available, but no connection to certain branches. As redundancy
is built, network connectivity could be established through ISDN. If both fail (primary and
secondary), the branch is advised to go to the nearby branch and complete the transaction.
Scenario 6: DR site goes down. DC and CSD are available.
Because of disruption, log shipping would be affected.
Steps to be taken
ANNEXURE
Contents of a sample business continuity plan document
Sl. No. Description
Section A: Introduction
1 Background
2 Objectives
3 Definition of disaster
4 Organization for business continuity/disaster recovery
5 Roles and responsibilities of the team and its members
6 Activation of the plans
7 Emergency Operation Center (EOC)
8 Placement of documents
Section B: Business continuity plan
1 Objective
2 Scope
3 Alternate site
4 BCP scenarios
5 Processwise BCP procedures and BCP teams
Section C: Disaster recovery plan
1 Introduction
2 Purpose
3 Threats considered/not considered for the plan
4 Disaster recovery team
5 Emergency calls
6 Disaster recovery procedures—non-IT related
— Fire
— Power outage
— Flood
7 Disaster recovery procedures—IT related
— Failure of hardware
— Failure of system software
— Failure of application software
— Cyber intrusion and cyber crime
8 Contingency operations procedures
9 Recovery and restoration
— Recovery of lost data
— Liaison with application users
— Restoration and return to normal operations
Section D: Emergency response plan
1 Introduction
2 Definition of crisis
3 Emergency response teams
4 Emergency response activation
5 Establishing an alert level
6 Emergency response—Local escalation procedures
7 Action consideration lists
Section E: Maintenance and testing of the plans
Annexures
Annexure 1: Constituents of the BCP, DRP, EMT committees
Annexure 2 : Employee call tree
Annexure 3: List of branches and contact persons
Annexure 4 : Building site plan
Annexure 5: Emergency contact numbers of support services
Annexure 6: Contact numbers of third party service providers (IT)
Annexure 7: Contact numbers of vendors (Non-IT )
Annexure 8: Contact numbers of vendors (IT)
Annexure 9: Formula to be used for computation of customer dues
Annexure A to C: BCP procedures
Annexure D: Formats of documents used during business continuity
Annexure E: Hardware inventory list
Annexure F: List of software used (vendor based )
Annexure G: List of software developed in-house
Annexure H: List of data files used
Annexure I: Media used to store files
Annexure J: Test preplanning checklist
Annexure K: Format for test evaluation sheet
Annexure L: Format for BCP/DRP test report
PART 2 EVALUATION OF SECURITY AND CONTROL
This part deals with evaluation of security and controls in an environment where the core banking solution has been implemented.
In Part 1 we discussed the relevance, appli-cations and functionalities of CBS. In this part we discuss methodology of evaluation
of adequacy of security and the control and the impact of lack of controls.
SECTION B............................................CHAPTER 12
Scope of Evaluation of
Security and Controls in a
Core Banking Solution
12.1 INTRODUCTION
A leading public sector bank while calling for the consultants to bid to evaluate their core banking
solution (CBS) including Internet Banking, defined the scope for evaluation of security and controls in
CBS and for Internet banking. They had also specified the deliverables for each of the systems. The
contents which were downloaded from the Internet are being reproduced below with very slight
modifications, regarding numbering of paragraphs etc.
Study the implemented functionality of the core banking application, Internet banking solution,
and other suite of applications as per the scope of this audit.
Perform application functionality and controls review.
Study the core banking application, internet banking and other suite of applications for
adequate input, processing and output controls.
Develop suitable testing methodology/testing strategy document.
Conduct various tests to verify existence and effectiveness of the controls for all
functionalities, schemes and products supported by the application under review.
Perform a test of controls and functionality setup in the core banking application, Internet
banking and other suits of applications.
Identify ineffectiveness of the intended controls in the software and analyze the cause for its
ineffectiveness.
Review controls over automated processing/updations of records, review or check critical
calculations such as interest rates, etc., review the functioning of automated scheduled tasks,
output reports design, reports distribution etc.
A vendor should also take care of the following measures:
Auditability both at client side and server side including sufficiency and accuracy of event
logging, database level logging etc.
Extent of parameterization.
Internal control built in at application software level, database level, server and client side.
Backup/Fallback/Restoration procedures and contingency planning.
Suggestion on segregation of roles and responsibilities with respect to application software to
improve internal controls.
Adequacy, accuracy, data integrity of the Management Iformation Scheme (MIS) reports and
audit reports.
Manageability with respect to ease of configuration, transaction roll backs, time taken for end
of day, day-begin operations and recovery procedures.
A special focused audit is to be made on following items:
• Hard coded and virtual user-ID and password
• Interfaces with CBS software of many other applications/services both in house and third
party systems/solutions—security, confidentiality, integrity, accuracy and non-repudiation of
the data between systems.
• Recovery and restart procedures.
Review of customizations done to the software and the SDLC policy followed for such
customizations.
Proposed change management procedure during conversion, migration of data, version
control, application, replication, etc.
Suggest any application specific audit tools of programs.
Adequacy of audit trails and logs.
Adherence to legal and statutory requirements.
Input controls
Output controls
Processing controls
Interface controls
Authorization controls
Data integrity
Purging date
Database controls
Volume test
Server controls—application, web, database, firewall, etc.
Backup/fall back/restoration procedures
Physical Authentication mechanism
Security checks/controls
Physical access controls and logical access controls
Operating system controls
Management controls
• Change management
• Incident management
Logs management
Aspects related to segregation of duties
Adequacy of audit trails
Adherence to legal, statutory requirements
Performance controls
Controls of parameter setup/verification/testing, etc.
Regression testing
Prevalence of proper version controls
specific operating system security features used and the parameters set
identification of security weakness and recommend solutions
sample user profiles against job roles.
The service provider should provide a detailed technical report directed to the bank’s technical
and operational staff which should state each noted vulnerability, the systems affected by the
vulnerability, a detailed step-by-step fix for all security enhancements and the recommended counter
measures.
Data base security controls
For each of the applications under audit, i.e., core banking application, internet banking application
and other suite of applications, audit the data base systems security through automated security scans
and manual reviews. As part of this phase:
Review specific data base system security features used and the parameters set.
Review user profiles created at the database level against job roles.
Check the database security parameters and settings.
Check the procedures adopted for database/application backup.
Provide a detailed technical report directed to the Bank’s technical and operational staff which
should state each vulnerability noted, the systems affected by the vulnerability, a detailed step-by-step
fix for all security enhancements and counter measures recommended.
The vendor should benchmark the policies, procedures/processes. Standards against the standards
recommended by RBI and identify gaps. The vendors should report the areas where they have
observed the bank to be non-compliant with the RBI guidelines.
Internet banking IT infrastructure review
Logs of activity
Review and report on adequacy of audit logs and procedures for review of audit logs as a
preventive and corrective control.
De-militarized zone and firewall—Review and report on:
• Firewall policy, firewall configuration and deployment
• Vulnerability Assessment (VA) of operating system, web server, application server and
database server
• Intrusion detection system used for Internet banking
• Router for net banking infrastructure
• Demilitarized zone
Security review of all services used for Internet banking:
Review and report on:
• Adequacy of operating system security
• Report on parameterization as per security policy
Database administration, security administration and system administration—Review and
report on:
• Roles and responsibilities of DBA and system administrator for OS and server security.
• Process flow documentation
• Adequacy of controls to monitor activities of super users
• Menu options in different modules as per the intent of the policy
Operational activities:
• Procedures for opening and operating account with thrust on legal aspects in internet banking
scenario
• Maintenance of records in internet banking scenario
Application control review of Internet banking application:
• Review and report on adequacy of logical access control procedures
Application security:
• Review and report on adequacy of testing and security infrastructures at various stages of
acquisition process
Audit plan and procedure for each of the CBS suite of application packages as per the scope.
Interim report covering all the points as mentioned under the scope of work including specific
observations on the previous IS audit report. All observations will be thoroughly discussed
with the process owners before the finalization of the report.
Final audit reports with sign off by the bank and the Information System Auditor. (To be
submitted within 6 working days of completion of audit and the report should be submitted in
soft copy as word document and PDF format document besides a signed hardcopy). This
should also include report on the regression test. The final report shall, inter alia, contain:
• Present status of the pending observations of the previous audit.
• List of bugs found and key functionalities not supported, as per the current audit assignment,
segregating them as ‘critical’, ‘medium’ and ‘minor’.
• List of enhancements required and feasibility analysis of these requirements in the CBS.
• Suggestions for improvement in the performance of the software audited.
• Report highlighting gaps in input, processing and output controls with recommendations to
remedy the gaps.
• Screen dumps of testing and testing reports.
• Security process audit report and recommendations against best practices.
Report on risk analysis and risk mitigation methodologies.
Review audit report—covering the latest status at the time of review, of all the observations
made in the final audit report.
Report on the gaps between the mentioned documents and standards mandated by the RBI and
recommendations to comply with RBI guidelines and security practices being followed.
Vulnerability assessment report covering:
• Vulnerabilities found in all components like, network devices, operating systems,
application servers, database servers.
• Attacks and penetrations found and recommendations to address the same.
A report on all points including controls review covered under ‘Internet Banking IT
Infrastructure review/security review’ and the recommendations.
Compliance status report—After resolution of the areas where the bank was initially non-
compliant, the vendor should perform final compliance review and submit the final report as
part of the review audit report.
Certificate of level of compliance indicating complete compliance with the RBI standards as
per RBI guidelines on Internet banking vide circular no.
DBOD.COMP.BC.No.130/07.03.23/2000-1 and BOD.COMP.BC.14/07.03.29/2005-06.
The above describe the extent to which evaluation of security of the Core Banking Solution needs
to be undertaken.
The following chapters deal with the process of evaluation.
SECTION B............................................CHAPTER 13
Review of Security
Policy Implementation
13.1 IMPLEMENTATION
It is imperative that there should be a security policy approved by the senior management. This should
contain policies for ensuring security of assets and information. Confidentiality, integrity and
availability need to be ensured.
In Chapter 10 of Section A, a draft security policy has been provided to illustrate the contents of a
security policy. The policy should be updated by the senior management periodically when
circumstances warrant due to change in technology or due to experience gained while analyzing
certain security incidents (i.e. incident of security lapses).
1. The Disaster Recovery (DR) site has been identified and configured to meet the processing
requirements.
2. Redundant network connectivity has been provided for all branches to the data center as well
as the DR site.
3. The data replication has been configured between the data center and the DR site (i.e. through
log shipment etc.). Is the log shipment periodicity in line with the Recovery Point Objective
(RPO) specified in the plan?
4. Has the bank tested the recovery procedure? If so, is there a document evidencing the DR
drill?
5. All the disaster scenarios envisaged (e.g: No access to CSD building and data center, main
server at DC is down, network failure etc.) have been tested?
6. During the DR drill whether the networks and servers at the DR site handled the processing as
per the banks’ requirements. That is, whether there were any performance issues.
7. Appropriate personnel have been identified for DR processes and training has been provided
to them to handle a disaster scenario.
8. Proper co-ordination between various vendors and service providers established for support
during DR?
9. All delivery channels like ATM, Internet banking etc. handled during DR?
10. Banks has plan for re-synchronisation of the DR database and the core database at the data
center? Is reverse log shipment enabled between DR and DC during the drill process? Is there
any data logs?
11. Any directory maintained of contact persons and their mobile and telephone numbers?
12. Any disaster had occurred and lessons learnt have been documented.
13. Review of plan undertaken to ensure that it is currently taking into consideration technology
changes and/or scenario changes.
1. The application server and database server are configured in such a manner that in the event of
one failing the other will take over.
2. Verifying with what frequency data from data center is replicated to disaster recovery site.
3. Verifying whether application backup is taken whenever any changes are made.
4. Verifying whether there is any concern of ‘single point of failure’, like availability of one
router only and no standby router being available.
5. Verifying whether there is a proper procedure and service level agreement with IDRBT so
that traffic will be routed to the disaster recovery center in case disaster has been declared at
the primary center?
6. Verify whether there is a facility for other banks also using the client bankers ATM facility. In
such cases verify whether measures are in place so that third party connectivity will not be
lost. This would happen if third party links terminate at primary data center only with no such
facility at disaster recovery site.
DR activity—Segment
Date and time of activity
DR activity planned
Level of DR activity/test
Failure scenario if any simulated in the test
Nature of down time, if any
Duration of down time
Details of approval obtained for taking a down time
Third parties involved
Activity involved
Team members at DR site
Final outcome of activity
Brief account of the activity planned to be conducted
Brief account of the activity that could be completed
Problems faced during the DR activity
Whether problems faced have been reported to higher authorities immediately?
After reporting whether any decision points have been arrived at for conclusion of the
activity/test?
Any shortcoming found in the hardware set up
Any shortcoming found in the application
Any shortcoming found in the DR procedure itself
Data loss if any due to the DR activity
Whether all the recovery mechanisms have been taken up to reduce the data loss
In case of activity involving switching over from primary to DR site whether the same was
smooth or whether any problems faced?
In case of an unscheduled activity, which of the persons/agencies could not be contacted for
response?
Whether proper alert has been given to such persons/agencies subsequently?
Activity details documented
Details of deviation if any from the prescribed/specified DR drill document
Action points arising out of the present DR activity
Action owner for rectification/compliance of the above action points
Co-ordinator for the above rectification/compliance
Probable deadline for above compliance (Approximately)
Whether the DR activity has helped in augmenting the DR capacity of the bank and if so
provide details?
The Disaster Recovery (DR) drill are not conducted regularly in all banks. Even if conducted, no
document giving details of the drill are maintained. At the most, it may be contained in the personal
diaries of the concerned members of the staff. Procedures should be in place to ensure that contents of
‘Redo log file, the DBMS’ are taken. As it is time consuming, there should be adequate procedures in
place so that in case of a sudden disaster when data and Redo log files are not available, alternate
procedures are in place.
1. Balance enquiry
2. Transaction history details
3. Request for
(a) Chequebook
(b) Demand draft
(c) Fund transfer
4. Payment
(a) For taxes
(b) For insurance
5. Stop payment instruction
The process for evaluation of effectiveness of Business Continuity Planning (BCP) would include
the following:
1. Verifying what backup and standby is implemented for Database server. Ensure its adequacy.
2. Verifying whether there is a standby server for web server.
3. Reviewing current backup mechanism for its effectiveness.
4. Verifying whether there is redundant power supply for web server and database server? In the
absence of adequate power supply, Internet operations would be affected and the recovery
time objective may be exceeded.
5. Verifying whether web server is configured at the disaster recovery site also.
6. Verifying whether asynchronous replicator is configured to ensure data loss is minimal.
7. Verifying whether established procedures are in place for reverse replication. This process
consists of replication from disaster recovery site to data center soon after database server
and web servers are brought up after disaster. This alone would ensure continued data
integrity.
8. Review service level agreements with third party service providers to ensure they include
procedures envisaged for backup and recovery of data.
Whether business process and systems are designed and implemented with adequate internal
controls?
Whether the required business functionality is achieved?
Whether the project team is using a structured approach for monitoring systems development
activity, systems quality and adherence to organisation policy.
The Information Systems Audit Control Association of USA (ISACA) has published auditing
standards, guidelines and procedures. Standards are mandatory. The guidelines while may be
followed, the onus is on the systems auditor to justify any deviation from the guidelines.
The guideline No. 23 of ISACA deals with Systems Development Life Cycle reviews. The
Guideline envisages that during SDLC of an application, various risks could be encountered
which include the following:
• Inadequate controls in the SDLC process
• User requirements and objectives not being met by the application system
• Lack of management support
• Inappropriate technology and architecture
• Scope variations
• Time over runs
• Cost over runs
• Insufficient attention to security and controls (including validations and audit control in the
application systems)
• Insufficient documentation
• Inadequate contractual protection
• Inadequate adherence to chosen SDLC/development methodology
• Insufficient attention to inter-dependency on other applications and processes
• Inadequate configuration management
• Insufficient planning for data conversion/migration post cut-off
• Disruption of business
The IS audition should study the systems documentation to get a clear understanding of
hardware configuration, the contents of the various modules of the total system and their inter-
dependence.
In this chapter, our attention would be more on the SDLC methodology being tested before the
system goes live.
Quite a few progressive banks have taken the initiative to have the SDLC methodology to be
critically reviewed and tested either by an independent team of systems auditors internally or by
appointing competent third party systems auditors. The procedures to be followed would be to verify
that there is a formal procedure in existence for the following activities.
Also it should be noted that whenever a program has been changed to set right a particular bug, the
entire program should be tested (it is called regression testing) to ensure that the changed program has
not been affected in any adverse manner and that it continues to perform in the same manner in which
it was performing before the change was effected.
It is also not uncommon to come across such instances when due to a program change being
effected, the program which was working satisfactorily prior to the change, could malfunction due to
the improper implementation.
Each of the modules will have to be tested extensively. The test data would have to be
comprehensive and exhaustive so as to ensure that all aspects of the module are tested effectively. For
example, the systems acceptance of negative values, pre-dated entries, post-dated entries, all are of
equal importance. The system should be tested to ensure that it does not fail under any circumstance.
There needs to be a procedure to have a control on change management The following should be
considered:
1. The use and existence of a methodology for authorizing and prioritizing change requests from
the user department.
2. Verifying whether there is a formal procedure for change controls for both the user and the
development team.
3. Whether the change control log ensures that all changes shown were resolved (It is likely that
it may be only partially resolved).
4. Whether emergency change procedures are addressed in the operations manual (It is a
practical situation that all organizations will face after a system is implemented).
5. There would be emergency situations when a change would require to be made immediately
without there being adequate time to comply with the structured procedures for change
management. This situation needs to be envisaged and procedures put in place.
6. The best practice is that the change is effected in a controlled environment and the situation
under which emergency procedure have been invoked is documented. Soon after the
emergency has been tackled, the formal procedures which should have been adopted for a
change would be gone through and a formal testing process would be complied with. The
results obtained after the emergency changes were effected, would be compared with those
obtained after the change control procedures have been formally implemented. This would
ensure that emergency changes though unavoidable are controlled and well-documented.
Example: The fixed deposit product may have to be implemented within a very short time. A new
home loan product may need to be implemented to beat the competition.
In this connection, the adequacy of the security access restrictions over the use of the emergency log
on ID need to be reviewed. Only certain personnel should be authorized. They only should have a
right to exercise emergency log on ID.
Change management
All instances of changes made should be recorded through a change control software or a register.
The log should be reviewed critically bearing the following points in mind:
(a) Ensure that changes to requirements resulted in appropriate change development documents such
as program operations document.
(b) Ensure that the changes were made as documented. Instances are not rare when all changes may
not be documented or documented changes may not represent the actual changes.
(c) In view of the above, determine whether current documentation reflects the changed environment.
(d) Verify the adequacy of procedures being followed for testing changes to system e.g. Regression
testing—testing the whole program again and not only the change.
(e) Review critically the documents evidencing test plans and test results to ensure that best practices
and as laid down in organizational standards are in force.
(f) Verify the library procedures in place which ensure the integrity of source code and executables of
software. Procedures for movement of files and access rights to library need special review. Special
attention needs to be paid to ensure incompatible functions are not clubbed in the responsibility of
one individual.
(g) Review whether every production executable version of the software is supported by an
appropriate authorized version of source code?
(h) Defective compliance of standard library procedures may result in a wrong executable being
loaded in the production version though correct version of changed source code is available.
(i) Absence of procedures, wrong or defective compliance of accepted best practices are likely to be
explained away as computer problems!
SECTION B............................................CHAPTER 16
Network Security
16.1 INTRODUCTION
In a core banking solution (CBS) there is a complicated and complex network system. Performing a
vulnerability assessment is extremely essential. The vulnerability arises due to some ports which
should never be opened are kept open or due to patch updation not being done regularly to the
operating systems, database management system (DBMS) or networking components like the
firewalls, routers and switches.
Domain server.............XXX.XXX.XXX.XXX
Mail server..................XXX.XXX.XXX.XXX
ATL server..................XXX.XXX.XXX.XXX
Unix server..................XXX.XXX.XXX.XXX
Router..........................XXX.XXX.XXX.XXX
A soft copy of the detailed report has been handed over to your systems department for taking
appropriate action. In the detailed report vulnerabilities are classified into:
Our summarised observations are based on the Windows version of the VA tool. (See Table 16.1).
Table 16.1 Comparative Statement of High Risk Vulnerability
IP address Results of Results of
Name
through LAN latest VA earlier VA
xxx.xxx.xxx.xxx Domain server 2 0
xxx.xxx.xxx.xxx Mail server 2 0
xxx.xxx.xxx.xxx Database server 10 1
xxx.xxx.xxx.xxx Unix server 13 9
xxx.xxx.xxx.xxx Switch 0 0
Observation
The high risk vulnerability has increased considerably and immediate action is required for updating
with suitable patches.
A. Domain server
1. KPASSWD (464/tcp): This service is used for changing the password for Kerberos
Authentication System. We understand that the company is not using Kerberos.
Recommendation: Since this service is vulnerable to attacks, the same may be disabled.
2. Microsoft-ds (445/tcp): Arbitrary code can be executed on the server by an unauthorized
person with system privileges. The server is vulnerable to a buffer overrun.
Recommendation: Apply Microsoft set of patches for Windows 2000, XP and 2003.
B. Mail server
1. SMTP (25/tcp): The remote Simple Mail Transport Protocol (SMTP) server can be disabled
by a malicious message which will crash the system.
Recommendation: Simple mail transport protocol message transfer agent is the most
important mail transfer agent in the domain environment and is vulnerable to external attack
and hence, we recommend that it should be reconfigured or upgraded.
2. Microsoft-ds (445/tcp): The version of Windows contains a flaw in the Server Message
Block (SMB) implementation which may allow an unauthorized person to execute arbitrary
code on the server.
Recommendation: Apply Microsoft patches for Windows.
C. Database server
1. Name (42/tcp): The remote Windows Internet Naming Service (WINS) has a flaw which
could allow an unauthorized person to execute arbitrary code on this host.
Recommendation: Apply patches.
2. PCG-Radar (1036/tcp): The remote version of Windows contains a version of Microsoft
Data Transaction Coordinator (MSDTC) service which is vulnerable to several remote code
execution and denial of service vulnerabilities.
An unauthorized person may obtain the complete control of the server (2000, NT4) or crash
the remote service (XP, 2003).
Recommendation: Apply Microsoft set of patches for Windows 2000, XP and 2003.
3. Microsoft-ds (445/tcp)
• An unauthorized person who can execute code on the server can crash the print spooler
service (PSS).
• The remote version of Windows contains a flaw in the Server Message Block (SMB)
implementation which may allow an unauthorized person to execute arbitrary code on the
server.
• It is possible to anonymously read the event logs of the remote Windows 2000 host. An
unauthorized person may use this flaw to anonymously read the system logs of the server. As
system logs typically include valuable information, an unauthorized person may use them to
perform a better attack against the server.
• Arbitrary code can be executed on this server due to a flaw in the ‘server’ service. This has
a vulnerability of heap overflow in the ‘server’ service which may allow an unauthorized
person to execute arbitrary command with the ‘system’ privileges. In addition to this, the
server is also vulnerable to information disclosure vulnerability in SMB which may allow the
person to obtain portions of the memory.
• The arbitrary code can be executed on this server due to a flaw in the ‘server’ service which
will lead to a buffer overflow attack.
Recommendation: Install suitable Microsoft security patches.
4. EPMAP (135/udp): Security vulnerability exists in the messenger service that could allow
arbitrary code execution on an affected system. An unauthorized person who successfully
exploited this vulnerability could run code with local system privileges, or could cause the
messenger service to fail.
Recommendation: Disable the messenger service.
5. Unknown (7938/tcp): A backup software namely ‘Legato’ is running, which has inherent flaw
which will not prevent an unauthorized person from executing a malicious program that could
bring down the system. This was reported in our early vulnerability report also.
Recommendation: Apply patches for the backup software. If this service is not needed,
disable it or filter incoming traffic to this port.
6. Netbios-ns (137/tcp): Arbitrary code can be executed on the server as the server is running a
windows internet naming service (WINS).
Recommendation: Apply security patches.
D. UNIX SERVER
1. FTP (21/tcp): An FTP (File Transfer Protocol) server is running, which is vulnerable to the
‘glob heap corruption’ flaw. An unauthorized person may use this problem to execute arbitrary
commands on this host.
Recommendation: Upgrade ftp server software to the latest version.
2. SMTP (25/tcp): The send mail server in the Unix system has the following vulnerabilities:
An unauthorized person can execute an arbitrary code and cause:
• A ‘buffer flow’ in the DNS handling code
• Buffer overflow and gain ‘root privileges’
• Local privilege escalation when using forward files
• ‘-bt overflow attack’ which allows any local user to execute arbitrary commands as root.
Recommendation: Upgrade the send mail to the latest version.
3. SHELL (514/tcp): It is possible to remotely log into this server using the account ‘atufin’!
without a password or the account is mis configured in ~/.rhosts.
Recommendation: Remove ~/.rhosts or set a password.
4. Sometimes-rpc9 (32773/tcp): The server is running the sadmind Remote Procedure Call
(RPC) service. It is possible to misuse this service to execute arbitrary commands on this
system as root.
Recommendation: Disable this service as Sun does not intend to provide a patch.
5. Sometimes-rpc13 (32775/tcp): The tooltalk RPC service is running.
A possible implementation fault in the ToolTalk object database server may allow an
unauthorized person to execute arbitrary commands as root.
Recommendation: Disable this service.
6. Unknown (32782/tcp): The remote Remote Procedure Call (RPC) service 100249 may be
vulnerable to a heap overflow which allows any user to obtain a root shell on this system.
Recommendation: Disable this service
7. SNMP (161/udp): It is possible to obtain the default community names of the remote SNMP
server. An unauthorized person may use this information to gain more knowledge about the
server, or to change the configuration of the remote system.
Recommendation: Disable the SNMP service on the server if not used. Or filter incoming
UDP packets going to this port, or change the default community string.
SECTION B............................................CHAPTER 17
Evaluation of Controls in
Operating System
17.1 INTRODUCTION
The Operating System (OS) is a set of computer programs that manage the hardware and software
resources of a computer. These operating systems act as the resource manager. These systems manage
input-output devices, the central processor and all of the files containing information. Figure 17.1
broadly describes the role played by the operating system.
Figure 17.1
The operating system is like a traffic constable. It makes sure that different programs and its users
using the computer at the same time do not interfere with each other. The operating system provides a
software platform on top of which other programs known as ‘Application Programs’, can run.
Operating system is also responsible for the security, ensuring that the unauthorized users do not
access the system.
There are various policies which need to be configured based on the security requirements of the
bank.
Overview
Windows server 2003 baseline policy
Audit policy
• Audit account logon events
• Audit account management
• Audit logon events
• Audit object access
• Audit policy change
• Audit privilege use
• Audit process tracking
• Audit system events
User rights assignments
• Access this computer from the network
• Act as part of the operating system
• Adjust memory quotas for a process
• Allow log on locally
• Allow log on through terminal services
• Backup files and directories
• Managing auditing and security log
Security options
• Accounts settings
Accounts : Administrator account status
Accounts : Guest account status
Accounts : Limit local account use of blank passwords to console logon only
• Audit settings
Audit : Audit the access of global system objects
Audit : Audit the use of backup and restore privilege
Audit : Shut down system immediately if unable to log security audits.
Devices settings
Domain member settings
Interactive logon settings
• Interactive Logon : Display user information when the session is locked
• Interactive Logon : Do not display last user name
• Interactive Logon : Do not require CTRL+ALT+DEL
• Interactive Logon : Message text for users attempting to long on
• Interactive Logon : Message title for users attempting to long on
• Interactive Logon : Number of previous logons to cache (in case domain controller is not
available.)
• Interactive Logon : Prompt user to change password before its expiration
Microsoft network server settings
Network access settings
Network security settings
Shutdown settings
System settings
• System settings : Optional subsystems
• System settings : User certificate rules on Windows executables for software restriction
policies
Event log
• Maximum application log size
• Maximum security log size
• Maximum system log size
• Prevent local guests group from accessing application log
• Prevent local guests group from accessing security log
• Prevent local guests group from accessing system log
• Retention method for application log
• Retention method for security log
• Retention method for system log
Additional security settings
• Manual hardening procedures
Overview
• Domain controller baseline policy
Audit policy settings
• Audit directory service access
User rights assignment Settings
• Access this computer from the network
• Add workstations to domain
• Allow log on locally
• Allow log on through terminal services
• Change the system time
• Enable computer and user accounts to be trusted for delegation
• Load and unload device drivers
• Restore files and directories
• Shutdown the system
Security options
Event log settings
Restricted groups
Additional security settings
There are other servers like the infrastructure server, file server, print server, web server, Internet
Information Services (iIs) server, certificate services server and the bastion host which require
suitable operating system hardening procedures to be followed.
Windows 2003 server hardening guide has several appendices of which are some listed below:
Appendix A to this document deals with security tools, its configuration and formats.
Appendix B deals with key settings to be considered for hardening the operating system. Many
security countermeasures and security settings are discussed. It keeps emphasizing on a few of them
which will have the biggest impact.
Appendix C provides a templates summary.
Appendix D deals with testing the Windows 2003 security that includes test methodology, types of
tests and bug classification.
In all the above cases only the environment ‘Specialised security—limited functionality’ has been
considered. In legacy client and enterprise client environment, the setting may vary.
It is important that at an appropriate senior level in the organization structure, decisions are taken
as to who creates, modifies or deletes both domain and local account.
Unauthorized changes give room for security concern. The logs help to determine which accounts
have been unauthorizedly modified or created. This could be by mistake or intentional. Whatever be
the cause, the logs should be generated and reviewed.
The guide envisages more than thirty event IDs. For each such event ID, corresponding event
description is shown.
A few of the event IDs and event description are provided below:
Table 17.2 Event IDs with event description
Event IDs Event description
624 A user account was created
627 A user password was changed
628 A user password was set
630 A user account was deleted
631 A global group was created
645 A computer account was created
A local security group with security disabled was created.
648 Note: SECURITY_DISABLED in the formal name means that
the group cannot be used to grant permissions in access checks
17.4.3 Audit Log on Events
This policy setting determines whether to audit each instance of user log on and log off from a
computer. The audit log on events setting generates records to monitor domain account activity. If ‘No
auditing is set’, it is difficult to determine which user has logged on or attempted to log on computers
in the organization. However, if ‘success’ value of the audit log on events is set, an event will be
generated each time if someone logs on to the network.
The audit log on event setting is configured in legacy clients and enterprise clients. Table 17.3
includes important security events that this policy setting records in the security log.
Table 17.3 Important security events recorded in the security log
Event IDs Event description
528 A user successfully logged on to a computer
529 Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password
530 Logon failure. A logon attempt was made outside the allowed time
531 Logon failure. A logon attempt was made using a disabled account
532 Logon failure. A logon attempt was made using an expired account
535 Logon failure. The password for the specified account has expired
539 Logon failure. The account was locked out at the time the logon attempt was made.
Note: The WINDOWS Server 2003 Guide mentions many more security setting events.
Debug programs
Create a token object
Replace process level token
Generate security audits
Backup files and directories
Restore files and directories
Table 17.6 gives some of the important security events which this setting records in the security
log.
Table 17.6 Security events recorded in security log
Event ID Event description
Specified privileges were added to a user’s access token
576
Note: This event is generated when the user logs on
577 A user attempted to perform a privileged system service operation
578 Privileges were used on an already open handle to a protected object
1. The system should automatically fetch the data from the Master data already created, once the
customer ID is entered. Test should ensure that the mandatory fields are not be capable of
deletion.
2. (a) Staff accounts:
Whenever a staff code is entered, the system should permit specific facilities available to staff
members only. This needs to be tested on the system.
(b) Senior citizen accounts:
Similar procedure should be followed to verify whether specific facilities are available to
them. This needs to be tested on the system.
3. Validation should be in place for not allowing cash receipts/local credits in Non-Resident
External Accounts. As the non-residents can freely repatriate the funds in their NRE accounts
only remittances from other countries/transfers from other NRE accounts should be allowed
(As per present RBI regulations).
4. It needs to be tested whether NRE accounts are treated separately as is meant for NRE
customers and not as normal savings bank customers.
5. Formal procedures should be available for limit creation, standing instruction, auto debits,
blocking and unblocking accounts. The proper implementation of these procedures should be
tested.
6. There should be a procedure to generate a specific account number for each customer and it
should be linked to his customer ID. This needs to be tested on the system.
7. Verify whether the system allows withdrawal in excess of the balance available which may
result in overdraft and whether system automatically awaits further authorization before
processing such cases.
8. The system should have a built-in control to ensure that appropriate documents are presented
for the non-individual customers, e.g. partnership-partnership deed; company-board
resolution.
9. The system should be in a position to capture signatures, tenures and permissible transaction
limits of the authorized signatories and should be in a position to display the same as and
when required for the verification.
10. Verify whether the system accepts a cheque that is not forming part of the series issued to that
customer.
11. Verify whether the system recovers charges for:
• Cheques returned
• Cheque book issue
• Minimum balance not maintained
If the above charges are not recovered, the presence of compensatory controls needs to be
verified.
12. Verify whether the inoperative and unclaimed accounts are segregated and the system calls for
authorization by the branch manager for the operations of such accounts.
13. Confirm that withdrawals are permitted by the system even if the balance goes below the
minimum balance after the debit.
1. Verify whether the system automatically generates a message for submission of stock
statements at stipulated intervals.
2. Verify whether the drawing power arrived at is net of the margin and also least of the limit
sanctioned and advance value.
3. Verify whether the drawing power arrived at is authorized at appropriate level.
4. Verify whether it is possible to modify the drawing power after
authorization.
5. Verify whether the system prompts for review/renewal of the credit facilities.
6. In case of advance to limited companies, verify whether the system automatically generates a
message for creation of charges with regis-trar of companies.
7. In cases where overdraft has been sanctioned against the bank depo-sits, verify whether lien is
marked on these deposits.
8. Verify whether the system calculates over due interest if the balance exceeds the sanctioned
limit/drawing power.
9. In cases where the cash credit/overdrafts are repayable in instalments, verify whether the
origional limit sanctioned is reduced to the extent of the instalment amounts repaid.
10. Verify whether all the excesses over the limit allowed, have the necessary authorizations and
are included in the exception report.
11. To verify how the system treats the existing borrowal accounts where sanctions have
expired/not renewed.
12. To verify whether the system recognizes the interest towards income in non-performing
advances. It should be verified that the interest so calculated is considered separately only and
not to Profit and Loss Account.
1. Verify who are authorized by the bank management to be cash tellers and also the limit fixed
for each of the tellers.
2. Verify whether the system prompts for Permanent Account Numbers (PAN) numbers for
receipts above Rs. 50,000 in cash. Issue of cash DDs/Banker’s cheques/TTs should not be
permitted by the system in case of remittance by cash above Rs. 50,000 as per the present RBI
guidelines.
3. To verify how the shortage/excess cash is accounted for by the system at the end of the day.
4. The system should capture and maintain denomination details right from the release of cash
from the vault.
5. For cash receipt/payment the system should note the denomination details and allow the
transaction only after tallying with the receipt/payment amount.
6. System should have a control for monitoring the movement of cash between the cash counters.
7. Verify whether the transaction can be modified by the maker only before authorization by the
checker and not afterwards.
8. Check whether the transaction is uniquely identifiable (by generating an ID and a time stamp).
9. Verify whether the system restricts payment per transaction in excess of teller’s limit.
10. Check whether system restricts any transaction in the account before initial deposit is made for
the opening of such accounts.
11. If there is a facility for cash withdrawal relating to an account of a different branch, it should
be verified whether the system enforces any upper limit fixed by the head office.
18.5 CLEARING
The clearing operations are generally done through batch processing and the main object of
evaluation of security is to verify how such batch data are controlled and if it control the totals match
with the total of individual instruments.
1. System should automatically reject cheques that are stale, post-dated, cheques which are
stopped for payment or drawn on accounts which are already closed.
2. The system should prompt for authorization by the concerned official in inoperative accounts
and accounts where sufficient balances are not available.
3. It should be verified whether it is possible to honour a cheque when the available balance in
the account is inadequate unless the cash block is lifted.
Note: Cash block is a specific amount in the account balance which is kept blocked.
4. System should have in-built controls to ensure that duplicate processing of the same
cheque/batch is not permitted.
1. Check all logs prepared by the system that are required for the business.
2. Check the levels at which the logs are accessible. Since they are
confidential in nature it must be accessible on a ‘need to know’ basis.
3. Check if controls are in place to ensure that the logs cannot be modified or deleted.
4. Check if all exceptional transactions are reported in the log.
5. Check if the details in the log are adequate.
1. The functionality of normal guarantee and deferred guarantee as available in the system needs
to be verified to ensure that the business requirements are provided for.
2. The deferred payment guarantee is a secured guarantee since the machineries, equipments etc.
purchased out of the guarantee issued favouring the suppliers form the primary security and
hence, the system should generate a message highlighting the need to comply with legal
requirements.
3. It should be ensured that the system passes necessary entries towards contingent liability at the
time of issue/reversing the guarantees.
4. To verify whether the recovery of applicable charges have been made and in the case of
deferred payment guarantees, only the charges payable for the particular financial year should
be taken to income account even though the charges for the entire period of the guarantee is
recovered at the time of issue of guarantee. Otherwise it will result in income being over
stated for that period.
5. To verify the availability of MIS reports for the review/renewal and expired guarantees.
6. To check for claim period in the guarantee issued as otherwise the guarantee will expire on
the due dates.
7. In case of the beneficiary invoking the guarantee and the guarantee becoming defaulted
guarantee, the accounting procedures need to be verified.
8. Verify the availability of provision in the system to acknowledge the counter-guarantee from
the customer as per the approved format linking it to the terms of the guarantee issued by the
bank.
9. Verify, whether the requisite cash margin as stipulated in the
guarantee sanction has been recovered and whether lien has been marked against such cash
margin deposit.
10. Verify whether it is possible for the system to accept payment of the guarantee amount if the
claim is made after the expiry of the guarantee.
18.9 BILLS
The process involves verification of the cheques/bills and the procedure in place in the system for
such transactions.
1. Check for the availability of provision for recording the details of the documents and
instruments. Inward/outward collections are to be distinctly identifiable.
2. Verify, whether the customer is having valid sanction for bill purchase limits.
3. Verify, whether the total liabilities can exceed the sanctioned limit and if so, whether the same
has been authorized.
4. Verify, whether the modification or waiver of charges are possible without the concurrence of
the authorizing official.
5. Test and verify the configuration of commission, interest charges, numbering of bills and bill
due date (usance) for accuracy and for prevention of leakage of income.
6. Verify, whether the grace period allowed for payment is to be within stipulated range.
7. Verify, whether provision is available for recording details of bills presented and in the case
of non-payment, whether particulars for sending non-payment advice to the drawer bank is
available.
8. In case of the transport documents, verify whether the transporter is in the approved list of
transport operators.
9. Verify, appropriation of proceeds of collection or realization to the total amount due including
the charges.
10. Verify, the correctness of the generated MIS reports for review of the pending bills and
returning the bills outstanding for a considerable period.
11. In case of IDBI/SIDBI bills under re-discounting scheme (applicable in the case of usance
bills), verify whether all such bills are reported to the banks link office.
12. Under drawee bill scheme, verify whether the amount utilized by the customer is reduced from
their cash credit/overdraft limits. This is to avoid double financing.
13. In case of bills purchased, returned by the drawee bank, verify whether the system prompts
recovery of charges concurrently or any procedure is set in motion by system (say MIS) to
follow-up recovery of charges.
14. Verify, whether system accepts bills having future dates or outdated bills which should have
been already paid as on the date of deposit of the same by the customer for purchase/discount.
1. The system should prompt for all the following required details:
• Importer/exporter code
• Import license details (specific/open general license)
• Shipping details
• Trans-shipment details if applicable
• Partial shipment details if applicable
• Letter of credit expiry date
• Document details—sight or usance
• Usance period if applicable
• Last date for shipment
• Last date for negotiation
• Letter of credit amount in rupees or foreign currency
• Letter of credit expiry date
• If revolving letter of credit, number of times or the amount revolving
• Details of merchandise
• Recovery of charges (opening, amendment and confirmation) from customer/beneficiary
2. Verify, whether the last date for shipment is within the date of negotiation and in turn, should
not fall beyond the expiry date of Letter of Credit (LC).
3. Ensure, in case of a foreign LC, whether the bank is having its own branch or a correspondent
bank to advise/confirm the letter of credit and also for presentation of the documents by the
supplier as per the terms of LC.
4. Verify whether the LC terms are as per the INCO terms 2000, which is a set of uniform rules
codifying the interpretation of trade terms defining the rights and obligations of buyer and
sellers in international transactions. Confusion over these terms may result in sale being lost
or in financial loss.
Example: Free on Board (FOB), Cost Insurance and Freight (CIF), Ex Works (EXW) and
Carriage Paid To (CPT).
5. Verify, whether the charges for opening, amendments, advice, commitment, postages are
recovered and if provision is available in the system for all of them.
6. If it is a revolving LC, verify whether necessary validations are in place to confirm the
number of times or the amount up to which the LC can revolve.
7. Verify whether there is a ‘revolving’ or ‘non-revolving’ flag when the LC is opened.
8. When an LC is devolved due to the customer not meeting the bills drawn under LC, verify
whether the system prompts for recovery of the devolved LC/bill amount and charges from the
customer.
9. Verify, whether the contingent liability vouchers under LC is debited at the time of opening
and reversed at the time of closing.
10. Verify, whether the system prompts for recovery of stipulated margin at the time of opening of
Letter of Credit and whether lien is marked on this margin amount.
18.11 REMITTANCES
To verify whether the system complies with the business requirements and Reserve Bank of India
(RBI) guidelines regarding remittances.
1. Verify, whether consideration has been received before the remittance is made (like receipt of
cash, account debit and cleared cheques) along with the applicable commission/exchange.
2. Verify, whether the remittance amount/exchange cannot be modified after authorization.
3. Verify, whether the charges for remittances and issue of duplicate instruments are factored into
the system.
4. Verify, whether the system allows issue/payment by way of cash
an amount exceeding Rs. 50,000/- since only account debit/credit is allowed and these
instruments should be necessarily marked ‘account payee’.
5. Verify, the methodology for revalidation of stale (more than six months old) Demand Drafts
(DDs)/Bankers Cheques (BCs) as per the laid down procedures.
6. Check, whether it is possible to issue duplicate DDs/BCs in case of lost instruments without
noting caution/or confirmation by the paying branch that the instrument has not been paid.
7. Verify, whether control is in place for sending advices in case of issue on non-CBS branches.
8. Verify, whether it is possible to print the same DD/BC by the system. This is to ensure that
duplicates cannot be printed.
9. Verify if the procedures for the reconciliation and the treatment of DDs/BCs issued but not
encashed for a considerable length of time is as per established procedures.
10. Verify, whether the system permits payment of DD/BC drawn on different branches to the
debit of DDs payable account.
11. Verify, whether, maker-checker concept is in place for issue/payment of instruments.
12. Verify, whether the system allows payment of the original/duplicate DD/BC when the
duplicates/original were presented and already paid.
1. Verify, whether all chequebooks are issued to the customers against the request and whether
such issues are accounted for in the
system.
2. Verify, whether it is possible to issue any series of numbered items without the system itself
allocating such issue.
3. Verify, whether there is any procedure in place to keep track of the chequebooks issued but
not taken delivery by the customer.
4. Verify, whether subsequent issue of chequebooks is possible without ensuring that a
reasonable utilization of the chequebooks already
issued.
5. Ensure system recovers charges against issue of chequebooks.
6. Verify, the procedures for implementation of ‘stop payments’ of the cheques requested by the
customers.
7. If ‘stop payment’ instructions are revoked, verify whether the system allows payment of such
instruments.
8. Verify whether the corporate office guidelines are followed before issue of chequebooks to
newly opened accounts.
18.13 DEPOSITS
The main object of the audit process is to verify whether they are in line with the established
procedures and controls as advised by RBI or the head office. Given below are suggested procedures
to be adopted for testing the deposit module:
1. Verify, whether validations are in place to ensure that system does not accept negative values
with regard to the deposit amount, interest rates, maturity amount and period of deposit. Apart
from other things, the system would automatically calculate and produce misleading figures.
2. Verify, whether appropriate interest rates are correctly applied (normal and additional) as
advised by the head office from time to time.
3. Verify, whether interest amounts payable on monthly basis is in line with accepted practice.
4. Verify, whether data can be modified after authorization.
5. Review procedures in place for renewal of matured deposits and for interest calculations.
Test, whether these procedures are in place in the system.
6. Verify, treatment of deposits on account of foreclosure as interest is payable only at a lesser
rate for the period, the deposit was held with the bank and not for the entire contracted period.
7. Verify, whether it is possible for the system to close the deposit without lifting the lien, if any,
on the deposits.
8. Ensure controls exist to prompt for the proof of identification for special deposits (staff,
senior citizens and other preferential cate-gories).
9. Study the procedures in the system for treatment of matured deposits not claimed.
10. Verify as to how the deposit numbers are generated and what are the controls in place for
duplicate receipt generation. Verify the procedures for generation of numbers and the controls
available over serial number.
11. Check the process of handling NRE TDS (Non-residential external term deposit).
12. Verify, how the unclaimed deposits (> 10 years old) are dealt with.
13. Verify, controls for renewal notice generation.
14. Verify, whether the range in interest rates are available for privileged category customers.
15. Since Government sponsored loans attract interest net of the subsidy amount only, verify,
whether the system has control to desist from paying interest for subsidy deposits.
16. In the case of recurring deposits, verify how delayed payment of instalments is handled in the
system for collection of penal interest.
17. Lien marked against recurring deposits—Is the interest amount considered for security? The
interest payable is kept in accrued interest account only and not credited to the account before
the maturity.
18. Verify, as to how the post maturity interest is calculated for the overdue instalments for few
months.
19. Verify, as to how the foreclosure is treated and whether only simple interest is applied.
20. Verify, whether any prescribed policy is in place to allow apportioning of the penal interest
for delayed payment of instalments against the concession allowed for advance payment of the
instalments.
18.14 ADVANCES
The main object of the audit is to check if the system has necessary controls to ensure that business
and RBI requirements regarding loan eligibility, interest rates, securities and follow up are strictly
adhered to.
1. Verify, whether the eligibility criteria and product parameters are clearly complied within the
system.
2. Verify, whether any unauthorized modifications are possible in the set parameters.
3. Verify, whether the interest calculation applied, is as per the stipulated rates for that particular
product/category and if there are any deviations, verify whether such deviations has the
necessary approval and is reflected in an exception report.
4. Verify, whether the loan amount is reduced by the value of the instalments on repayment and
the drawing limit is arrived accordingly.
5. Verify, whether the system prompts for review/renewal of advances. Any advance continued
without renewal sanction would attract overdue interest.
6. Verify, whether the existence of mandatory document details like:
(a) Demand promissory note
(b) Necessary stipulated agreement details
(c) Board resolution wherever applicable
(d) Mortgage details
(e) Lawyers’ opinion details
(f) Appraiser’ valuation details are captured by the system.
7. In case of company customers, verify, whether the system enforces acknowledgement (by way
of drop down menu or check box) for creation and registration of charges.
8. Verify, whether the system enforces acknowledgement (by way of drop down menu or check
box) for having insured the assets created out of loans.
9. Verify, whether the system prompts for renewal of necessary documents received from the
customers, at defined intervals.
10. Verify, whether appropriate approvals are required by the system for waiving penal interest
and other charges. Also verify, whether the same is reflected in the exception report.
11. Verify, whether the system captures the appropriate appraiser details for different types of
securities. Also verify, whether the system checks if the appraiser value covers the advance
value requested by the customer.
12. Verify, whether the system does not process the loans of customer whose date of birth
indicates that he is a minor.
13. Verify, whether the interest calculation is applied on the loan amount net of subsidies as the
subsidy amount kept as deposit is not eligible for interest.
14. Verify, whether the system enforces the guidelines adopted regarding income recognition and
non-performing assets as improper classification may have impact on revenue calculations.
15. Verify, whether the system processes advances to non residents as per the Foreign Exchange
Management Act and RBI guidelines.
SECTION B............................................CHAPTER 19
Evaluation of Controls in
ATM Operations
19.1 INTRODUCTION
The Automated Teller Machine (ATM) is one of the critical components of the Banking process.
Under the following sub-headings the main aspects reviewed for evaluation of security concerns
are provided in the form of checklist wherever possible.
Are separate departments and staff used for card and PIN generation?
Are procedures for production of cards and PINs fully documented?
Does the PIN mailer tape have card or account number?
Is there reconciliation procedure for the number of cards and PIN mailers produced?
Are records maintained for cards and PINs produced, mailed and spoiled?
Are the security procedures for the following adequate?
(a) Access
(b) Storage
(c) Staff
Does security evaluation include the following:
(a) Access to building
(b) Stocks of blank cards
(c) Stocks of cards and PIN mailers
Are monitoring procedures in place to ensure that computer jobs are run only once?
Are spoilt cards and PIN mailers reconciled?
When cards are destroyed, are suitable measures adopted to ensure that the confidential and
sensitive information is not available?
Are PINs encrypted on to the tape?
Are suitable measures in place to prevent unauthorised copying or dumping?
Are the departments producing cards and PINs physically separated?
In case PINs are printed on a fly sheet, are procedures in place to ensure destruction of the
same is in a manner suitable for sensitive data?
Is access to both of the production areas restricted to only authorised personnel?
Are procedures in place to ensure that live cards and PIN mailers are despatched separately
from different locations?
Are proper records maintained for all cards delivered?
Are procedures in place to ensure that the cards are returned to branch offices and not to the
office from where the cards are generated?
Are the procedures in place to ensure that no single officer is in charge of holding stock of
returned cards and returned PIN mailers?
Are there clear documented procedures with regard to surrendered and captured cards?
Are clear instructions provided to customers regarding the return of cards?
Are there documented procedures in place for issuing replacement cards and PIN?
Are captured cards made ineffective by the cardholder/by the bank?
Are clear instructions given to the customers that PIN should not be kept along with card or
written on the card itself?
Are clear instructions given to the customers that PIN should not be returned to the bank?
Are there documented procedures in the bank for opening of secure mail?
Are registers maintained of surrendered cards?
Are captured cards bin opened on dual control with proper records being maintained?
Is stop instructions in place immediately on the associated accounts when a card is returned
by:
(a) A customer or
(b) By a personal representative of the deceased card-holder?
Does the ATM lock off all details of a captured card?
Are captured cards removed from the ATM on a regular basis under dual control and
reconciled with the journal roll?
Is the report of captured cards produced on the host computer?
Are there procedures in writing regarding re-issue of cards and/or change of PIN following
card capture?
Is there a control in place by which the ATM retains a customer’s card after a said number of
failed attempts to key the correct PIN?
Is there a procedure in place to stop the card operation when a card-holder reports that PIN
has been compromised?
Have customers been formally advised never to keep the PIN and card together?
Are the customers advised not to disclose the PIN to anyone including the police?
Is there procedure in place to ensure that verbal or written request from customers for
specified PIN are accepted? Customers should be able to select their PIN only at the ATM.
Is there a documented procedure in place for action to be taken when a customer forgets
his/her PIN?
Is there a procedure in place for generating a new PIN on a timely basis if PIN numbers are
lost or stolen?
Are PINs held on Data files in encrypted form?
Are PIN offsets encrypted?
Is hardware encryption used?
Is software encryption used?—If software encryption is used the key would be easily
available and are generally to be avoided.
Does the encryption routine incorporate the customer account number so that any substitution
would easily be highlighted?
Are work and storage areas used for PIN encryption immediately zeroized after each
calculation?
Are there procedures in place to ensure that no hard copy records of PINs produced are
anywhere in the system?
Does the host system record instances of PIN changes?
Does the PIN selection prevent combinations such as “1111” or “0000”?
Are there documented procedures describing in detail the cash control and balancing process?
Are all the insertions and withdrawals of cassettes automatically recorded on the audit roll?
Is there a duel control procedure in place when cassettes are reinserted or removed?
Are there documented procedures and controls in place to monitor movement and storage of
cassettes?
Are there records maintained of the amount of cash inserted into each cassette?
Is there a daily reconciliation made by the bank staff reconciling the amount shown on the
audit roll regarding
(a) Cash inserted
(b) Cash dispensed
(c) Cash remaining
(d) Mis-fed notes
Are all reconciliation discrepancies investigated?
Is reconciliation of totals performed by person different from the person responsible for cash
management?
Are there checks in place to ensure that
(a) Wrong denomination notes are not inserted into the cassette?
(b) Incorrect denomination cassettes are not placed into the ATM?
Does daily balancing process ensure that
(a) Confirmation is given by branch staff.
(b) The currency deposited and dispensed agree with ATM accumulated total.
(c) The total of the deposit and withdrawal transactions generated by the ATM has been
received and logged by the host computer and branch system.
(d) The net movement of the host computer account file is in agreement with the total branch
transaction.
Card number and corresponding offset value (offset value explained under section 8.2 in
Chapter 8 of Part I)
Hotlisted cards—Details
Surrendered cards—Details
Account balance of customers
The account balance of customers is made available in the ATM switch database so that the
balance (also called as Positive Balance File–PBF) is provided when ATM is offline.
A switch is a focal point in the ATM infrastructure and the audit at the switch would include the
following:
Evaluation of Controls in
Internet Banking
20.1 INTRODUCTION
Internet Banking permits the customers to conduct financial transactions on a secured website.
The following questionnaire deals with various areas and the aspects related to the security and
controls of Internet banking. It is comprehensive but not necessarily exhaustive (See Table 20.1).
Table 20.1 Questionnaire on security and controls of Internet Banking
S.
Description
No.
1. Security policy and procedures
1.1 Are the security policy and procedures pertaining to Internet Banking approved by the management?
1.2 Are the security policy and procedures reviewed on a regular interval?
1.3 Does the Internet Banking security policy include existing service access policy and firewall security policy?
1.4 Is there a documented procedure in place for handling security incidents?
2. Security policy and procedures - Relating to personnel associated with Internet Banking
2.1 Does the management conduct periodic Information security awareness programmes?
2.2 Does the security policy and procedures talk about access controls to be enforced and action to be taken in case of access violations?
Does the security policy and procedures cover security procedures for all the access points namely:
• User system and front end application
• Router, switch, firewall
2.3 • Web and application server
• Local area network
• Mainframe
• Internet infrastructure
3. Security features relating to user identification
3.1 Review, whether the security mechanisms are in place to prevent unauthorized access to other accounts.
3.2 Verify whether the access control mechanisms are employed to control access both in and out of the internal network.
Review whether the access control mechanisms are employed to control the access of unauthorized persons to the transaction
3.3
processing functions of the application programs.
3.4 Review whether there are adequate log reporting and monitoring facilities within the system.
3.5 Review whether the log administration and monitoring procedures have been implemented.
Verify whether the automated tools are in use to highlight log entries that suggest an attempt to penetrate the network, e.g. Intrusion
3.6
Detection System (IDS).
Review whether proactive and detective monitoring measures are performed to highlight attempted or successful security breaches of the
3.7
system.
3.8 Verify whether logs of successful and unsuccessful attempts to penetrate the system are reviewed on a daily basis.
Verify whether there are procedures in place to log multiple unsuccessful log in attempts and to highlight the same to the system
3.9
administrator for immediate action.
3.10 Verify whether adequate restrictions have been enforced over access to software logs and audit trails.
4. Access controls to Internet Banking operation facilities, applications and data
4.1 Verify whether there is adequate segregation of duties.
Verify whether there is a password identification process which ensures that access is given only to the users with valid user IDs and
4.2
relevant passwords.
4.3 Verify whether after prescribed log on failures (say three times), user access is automatically disabled.
Verify whether there are procedures in place to ensure that log on ID and passwords are revoked soon after employees resign or
4.4
transferred.
4.5 Verify whether there is periodical maintenance of both Internet Banking hardware and software.
Verify whether there is an operational manual regarding Internet Banking operations and whether procedures are in place to keep it
4.6
updated.
4.7 Review change control procedures to verify whether they are clearly defined, documented and implemented.
4.8 Verify whether all the recovery procedures for operational failures are adequately documented.
Review whether the physical access to critical Internet Banking System components is secured and only authorised personnel are
4.9
permitted access.
5. Roles and responsibilities of system administrator
5.1 Verify whether responsibility for the security administration of Internet Banking has been assigned to a particular individual?
5.2 Verify whether roles and responsibilities have been clearly stated?
5.3 Verify whether adequate segregation of duties exists within the information system administration?
5.4 Verify whether the staffs are properly trained?
5.5 Verify whether there is a procedure manual detailing the guidelines for the information systems’ administration function?
5.6 Verify whether access violation attempts are monitored and reported to the appropriate authorities?
6. Firewall configurations and security
6.1 Review whether firewall architecture has been defined and implemented in order to adequately support the Internet Banking services?
6.2 Verify whether the Internet Banking services are delivered through a dedicated firewall architecture?
6.3 Verify whether a penetration test has been carried out.
6.4 Verify whether the vulnerabilities identified in the penetration test have been evaluated and appropriate corrective action taken.
6.5 Verify whether there are automated tools in use to highlight the entries which may suggest a penetration attempt.
6.6 Verify whether within the firewall software adequate log in reporting and monitoring facilities are available.
6.7 Verify whether both proactive and detective procedures are in place to highlight attempted security breaches to the system.
6.8 Verify whether the log administration and monitoring procedures have been implemented.
6.9 Verify whether access restrictions are in place for access to software logs and audit trails.
6.10 Verify whether firewall logs are stored in the firewall system itself or elsewhere.
Verify whether a network time protocol is used to synchronize the firewall system clocks. This is to enable accurate and consistent time
6.11
stamping of events.
6.12 Verify whether adequate firewall change control procedures as approved by senior management are in place.
6.13 Verify whether there are procedures in place to monitor and manage changes.
6.14 Verify whether management approval is obtained before firewall, system, routers or their operating systems are altered or upgraded?
Verify whether there are procedures in place to ensure that access control rules of the firewall can be modified only after approval of the
6.15
management.
Verify whether there are procedures in place to test firewall applications after changes have been made. This is to ensure that changes do
6.16
not give room for new vulnerabilities.
6.17 Verify whether there are procedures in place to regularly update the firewall application with latest patches.
Review the physical access procedures to the firewall systems components to ensure that access is restricted to authorized personnel
6.18
only.
6.19 Verify whether there is a clear definition of what are the emergency access procedures for a firewall.
13.2 Application is tested to ensure that all validity criteria are complied with before transaction is processed.
Test the application with sample transaction to verify the validations built in the application.
The validation could be
13.3 • The application directly validating the data against specific tables;
• The data is validated for appropriate data type; or
• The data is checked if is within a specified range.
13.4 Exception reports are produced listing unusual, unmatched items to facilitate programmed check digits.
13.5 Review whether overrides of the system by the users are automatically logged for independent approval and authorization.
13.6 Verify whether security measures have been defined and implemented to ensure the integrity of the application data is assured.
14. Operational controls—User authentication
14.1 Verify, identification techniques and ensure that they meet the business requirements.
14.2 Review user authentication mechanism to ensure that access is restricted to authorized personnel.
15. Operational controls—Incomplete and cancelled transactions
15.1 Test the program to ensure that errors are returned so that information is provided that the transaction has not been recorded.
15.2 Verify whether the program permits a user to cancel the transaction which has already been accepted.
15.3 Verify whether the specified file of rejected transactions are corrected and re-introduced into the system.
15.4 Review the procedure for incomplete processing.
Verify whether there is a compensating control outside the system to ensure all rejected entries are corrected and fed into the main
15.5
system.
16. Operational Controls—Data security
16.1 Verify whether critical data are encrypted.
16.2 Verify whether keys used for encryption are managed in line with best practices.
16.3 Verify whether keys are stored in a physically secure environment.
16.4 Verify to ensure that critical encryption keys reside in a physically secure hardware like HSM (Hardware Security Model).
17. Operational controls—Application functionality
17.1 Verify whether restart/recovery procedures are in place.
17.2 Ensure that as a result of re-processing due to interruption no transactions are lost.
17.3 Any unauthorized or erroneous entries generated by the system are logged for further investigation.
17.4 Application is tested for reasonableness check, completeness of fields, etc.
18. Change management procedures
18.1 Verify the organization structure in place for system development and change management.
18.2 Verify whether there is a formal mechanism put in place for effecting changes.
18.3 Review the testing procedure to verify whether they are fully documented and cover unit testing, system testing and regression testing.
18.4 Review migration procedures to ensure that they have been formally recorded and strictly followed.
18.5 Verify whether emergency change procedures have been defined and documented.
18.6 Verify existence and adequacy of testing plans.
18.7 Verify whether there is a procedure for accepting the program.
18.8 Verify whether the version number of each release is recorded.
18.9 Verify the procedures in place to ensure that corrections have been made to the correct version of the software.
18.10 Verify whether each version of the program is properly approved for release.
18.11 Comprehensively test the library functions.
19. Acceptance of new system
19.1 Verify whether testing is comprehensive
19.2 Verify whether business objectives have all been achieved.
19.3 Verify whether after successful testing formal sign off documents have been completed.
19. Incident management procedures
• Review the following:
• Problem management procedures
19.1
• Crisis management procedures
• Escalation procedures
Verify whether documented procedures are in place for roles and responsibilities for problem and incident management and ensure that
19.2
they are strictly adhered to.
19.3 Verify whether post-incident reviews are carried out and reports presented to appropriate authorities.
SECTION B............................................CHAPTER 21
Customer payment
Inter bank payment
Own account transfer
Responses are received from Real Time Gross Settlement (RTGS) and indicate that a message has
been processed.
Weekly
Monthly
There could be other logs also. One needs to enquire and verify their existence.
The organization should use several types of network-based and host-based security software, as
detailed below, to detect malicious activity, protect systems and data, and support incident response
efforts and the logs should be generated and archived.
The specimens of a few logs are provided below which reveal information regarding security
concerns.
Intrusion detection system: [**] [1:1407:9] SNMP trap udp [**] [Classification: Attempted
Information Leak] [Priority: 2] 03/06-8:14:09.082119 192.168.1.167:1052 -> 172.30.128.27:162
UDP TTL:118 TOS:0x0 ID:29101 IpLen:20 DgmLen:87
Firewall: 3/6/2006 8:14:07 AM, ‘Rule’ ‘Block Windows File Sharing’ ‘blocked (192.168.1. XXX,
netbios-ssn(139)).’, ‘Rule’ ‘Block Windows File Sharing’ blocked (192.168.1.54, netbios-ssn(139)).
Inbound TCP connection. Local address, service is (XXX(172.30.128.XXX), netbios-ssn(139)).
Remote address, service is (192.168.1.54,39922). Process name is ‘System’. 3/3/2006 9:04:04 AM,
Firewall configuration updated: 398 rules. Firewall configuration updated: 398 rules.
Antivirus software, log 1: 3/4/2006 9:33:50 AM, Definition File Download, XXX, userk,
Definition downloader 3/4/2006 9:33:09 AM, Antivirus Startup, XXX, userk, System 3/3/2006
3:56:46 PM, Antivirus Shutdown, XXX, userk, System
Anti-spyware software: DSO exploit: Data source object exploit (Registry change, nothing done)
HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\0\1004!=W=3
Other important logs
1. Operating system logs: Operating Systems (OS) for servers, workstations, and networking
devices (e.g., routers, switches) usually log a variety of information related to security. The following
types of security-related OS data logs should be generated and archived.
(a) System events
(b) Audit record
Operating system log entry: Event type: Success Audit Event Source: Security Event Category:
(1) Event ID: 517 Date: 3/6/2006 Time: 2:56:40 PM User: WIN AUTHORITY\SYSTEM Computer:
KENT Description: The audit log was cleared Primary User Name: SYSTEM Primary Domain: WIN
AUTHORITY Primary Logon ID: (0x0,0x3F7) Client User Name: userk Client Domain: XXX Client
Logon ID: (0x0,0x28BFD)
2. Application logs: Some applications generate their own log files, while others use the logging
capabilities of the OS on which they are installed. Different types of security-related logs could be
generated and archived.
3. Log management infrastructure: A log management infrastructure consisting of the hardware,
software, networks, and media should be in place to generate, transmit, store, analyze, and dispose of
log data.
A log management infrastructure should comprise the following three tiers:
(a) Log generation: The first tier contains the hosts that generate the log data. Some hosts run
logging client applications or services that make their log data available through networks to log
servers in the second tier. Other hosts make their logs available through other means, such as
allowing those servers to authenticate themselves and retrieve copies of the log files.
(b) Log analysis and storage: The second tier is composed of one or more log servers that receive
log data or copies of log data from the hosts in the first tier. The data is transferred to the servers
either in a real-time or near-real-time manner, or in occasional batches based on a schedule or
the amount of log data waiting to be transferred. Servers that receive the log data from multiple
log generators are sometimes called collectors or aggregators. The log data may be stored on
the log servers themselves or on separate database servers.
(c) Log monitoring: The third tier contains consoles that may be used to monitor and review log
data and the results of automated analysis. The log monitoring the consoles can also be used to
generate reports. In some log management infrastructures, the consoles can also be used to
provide management of the log servers and clients. Also, console user privileges sometimes can
be limited to only the necessary functions and data sources for each user.
General
The log management infrastructures should perform several functions that assist in the storage,
analysis, and disposal of log data. These functions are normally performed in such a way that they do
not alter the original logs. The following items describe common log management infrastructure
functions:
(a) Log parsing is extracting data from a log so that the parsed values can be used as input for
another logging process. A simple example of parsing is reading a text-based log file that
contains 10 comma-separated values per line and extracting the 10 values from each line. Parsing
is performed as part of many other logging functions, such as log conversion and log viewing.
(b) Event filtering is the suppression of log entries from analysis, reporting, or long-term storage
because their characteristics indicate that they are unlikely to contain information of interest. For
example, duplicate log entries and standard informational entries might be filtered because they
do not provide useful information to log analysts. Typically, filtering does not affect the
generation or short-term storage of events because it does not alter the original log files.
(c) In event aggregation, similar entries are consolidated into a single entry containing a count of
the number of occurrences of the event. For example, a thousand entries that each record part of a
scan could be aggregated into a single entry that indicates how many hosts were scanned. An
aggregation is often performed as the logs are originally generated (the generator counts similar
related events and periodically writes a log entry containing the count), and it can also be
performed as part of log reduction or event correlation processes which are described below:
Storage
(a) A log rotation is closing a log file and opening a new one when the first file is considered to be
complete. Log rotation is typically performed according to a schedule (e.g. hourly, daily, weekly)
or when a log file reaches a certain size. The primary benefits of log rotation are preserving the
log entries and keeping the size of log files manageable. When a log file is rotated, the preserved
log file can be compressed to save space. Also, during a log rotation, scripts are often run that act
on the archived log. For example, a script might analyze the old log to identify malicious activity,
or might perform filtering that causes only some log entries meeting certain characteristics to be
preserved. Many log generators offer log rotation capabilities; many log files can also be rotated
through simple scripts or third-party utilities, which in some cases, offer features not provided by
the log generators.
(b) Log archival is retaining the logs for an extended period of time, typically on removable media,
a Storage Area Network (SAN), or a specialized log archival appliance or server. The logs often
need to be preserved to meet legal or regulatory requirements.
There are two types of log archival: retention and preservation. Log retention is archiving logs on
a regular basis as part of standard operational activities.
Log preservation is keeping the logs that normally would be discarded, because they contain
records of activity of particular interest. Log preservation is typically performed in support of
incident handling or investigations or requirement by law, e.g. Information Technology Act.
(c) Log reduction is removing the ‘not needed’ entries from a log to create a smaller new log. A
similar process is event reduction, which removes ‘not needed’ data fields from all log entries.
The log and event reduction are often performed in conjunction with log archival so that only the
log entries and data fields of interest are placed into long-term storage.
(d) Log conversion is parsing a log in one format and storing its entries in a second format. For
example, conversion could take data from a log stored in a database and save it in an XML
format in a text file. Many log generators can convert their own logs to another format; third-party
conversion utilities are also available. A log conversion sometimes includes actions such as
filtering, aggregation, and normalization.
(e) Log normalization is the process in which each log data field is converted to a particular data
representation and categorized consistently. One of the most common uses of normalization is
storing dates and times in a single format. Normalizing the data makes analysis and reporting
much easier when multiple log formats are in use. However, normalization can be very resource-
intensive, especially for complex log entries (e.g., typical intrusion detection logs).
Analysis
(a) Event correlation is finding relationships between two or more log entries. The most common
form of event correlation is rule-based correlation, which matches multiple log entries from a
single source or multiple sources based on logged values, such as timestamps, IP addresses, and
event types. Event correlation can also be performed in other ways, such as using statistical
methods or visualization tools. If correlation is performed through automated methods, generally
the result of successful correlation is a new log entry that brings together the pieces of
information into a single place. Depending on the nature of that information, the infrastructure
might also generate an alert to indicate that the identified event needs further investigation.
(b) Log viewing is displaying log entries in a human-readable format. Most log generators provide
some sort of log viewing capability; third-party log viewing utilities are also available. Some log
viewers provide filtering and aggregation capabilities.
(c) Log reporting is displaying the results of log analysis. Log reporting is often performed to
summarize significant activity over a particular period of time or to record detailed information
related to a particular event or series of events.
Disposal
Log clearing is removing all entries from a log that precede a certain date
and time. Log clearing is often performed to remove old log data that is no longer needed on a system
because it is not of importance or it has been archived.
The logs should be rotated. The confidentiality, integrity, and availability of each type of log data
should be protected while in storage (at both the system level and the infrastructure level).
The period up to which each type of log data is to be preserved should be based on the
organization’s document retention policy and applicable legal regulations. The log data, not needed
should be disposed off as per company’s policy.
The System Administrator is responsible for the following functionalities:
(a) Monitoring the logging status of all log sources.
(b) Monitoring log rotation and archival processes.
(c) Checking for upgrades and patches to logging software, and acquiring, testing, and deploying
them.
(d) Ensuring that each logging host’s clock is synchronized to a common time source.
(e) Reconfiguring logging as needed, based on policy changes, techno-logy changes, and other
factors.
(f) Documenting and reporting anomalies in log settings, configurations, and processes.
(g) Contacting system-level administrators to get additional information regarding an event or to
request that they investigate a particular event.
(h) Identifying changes needed to system logging configurations (e.g., which entries and data fields
are sent to the centralized log servers, what log format should be used) and informing system-
level
administrators of the necessary changes.
(i) Initiating responses to events, including incident handling and operational problems (e.g., a
failure of a log management infrastructure component).
(j) Ensuring that old log data is archived to removable media and disposed of properly once it is no
longer needed.
(k) Co-operating with requests from legal counsel, auditors, and others.
(l) Monitoring the status of the log management infrastructure (e.g. failures in logging software or
log archival media, failures of local systems to transfer their log data) and initiating appropriate
responses when problems occur.
(m) Testing and implementing upgrades and updates to the log management infrastructure’s
components.
(n) Maintaining the security of the log management infrastructure.
SECTION C............................................CHAPTER 23
Audit Tools
23.1 INTRODUCTION
In an advanced computerized environment, it is impossible to carry out testing of systems manually.
The objectives of testing in a computerized environment are the same as in manual system. The
methodology of testing alone changes. The computer based tools and techniques facilitate a more
effective performance of computer assurance audit. The type of tool to be used is dependent upon the
technology, the type of application to be reviewed and most importantly, the expertise and knowledge
of the individual who proposes to use the tool. The procedures for obtaining audit evidence according
to Information Systems Audit and Control Association, USA (ISACA)–IS Auditing Standard 14 are:
Inspection
Observation
Inquiry and confirm
Computation, and
Analytical procedure
To obtain that above evidences in a computerized environment, it becomes necessary to test the
completeness, authorization and accuracy of
Input
Standing data
Processing and output
detect
analyze and
create data definition
However, most of the databases have no capabilities to save data in flat or .dbf or.txt files. In the
circumstances, it becomes necessary to save the files to be analyzed in one of the above-mentioned
formats. Also, on saving, relation or index is not saved. The files are saved as records and fields
appear physically in the files. The audit tool ACL has the capacity to set relation, index and sort files.
In case the production system which needs to be analyzed for audit purposes does not have the
capacity to save the files as one of the above-mentioned category, the system needs to be Open Data
Base Connectivity (ODBC) compliant. For the system to be ODBC compliant, it becomes necessary
to have ODBC drivers as they only enable access to the database.
It is possible that the view can be formatted. It is possible to add a computed column. It is also
possible to delete a column from the view.
Overview
An overview window provides a few of the input file definitions as:
Batches
Input file definition
Views
Work places
Indexes
Last result
The last result window shows the results of the last command issued. These results can be printed for
review and verification.
Command log
Whenever the ACL document is opened, it automatically opens a log file. This log file captures every
activity, command and message which can be effectively used as working papers by the auditor.
Creation of ACL document
Initial steps for using the ACL tool would be to create an ACL document which has:
Batches
Input file definition
Indexes
Views
Workplaces
Log file
A document maintains a description of the data in the data file, reports and automated procedures.
An ACL has the facilities which enable an auditor to understand the data and verify its validity.
Understanding of data includes:
Analysis of files: The file may contain a collection of data. If the objective of the audit is to sieve a
set of data or a portion of the file which satisfies a particular condition, ‘if’ command would be
given. When the command is executed the required data would be extracted from the file and given as
a report to the auditor.
Filter: The filters enable selection of records depending upon the filter conditions. It enables the
selection of transactions that satisfy a given condition.
Examples: 1. Loans above Rs. 5,00,000
2. Transactions after 30th September and before 31st March
3. Transactions authorized by particular user ID that year
Output files: Whenever an output file is created, the audit tool ACL creates a record of the
commands and options used to create the file. This record is called the ‘file history’. This is of great
use to the auditor as information is always available as to on what basis an output file has been
obtained.
Use of ACL for auditing different information systems: The audit tool is versatile and it is upto a
competent individual to effectively use the tool and obtain critical information to form an opinion on
the effectiveness of controls within the system. An illustrative situation when ACL Audit tool could
be used in a banking environment could be analyzing the data base of the loan module.
The usage of the tool effectively depends upon the individual and his competence in performing an
effective audit.
Given below is an example of various tests which could be conducted in the Loan Module.
Illustrative use of ‘ACL’ Tool for analyzing the data in a loan module
The features of ACL for drilling down, filtering the field, sorting, linking the tables, selection of
different tables and fields, selecting customer view etc. were utilized to analyse the database. The
database was analyzed for the following:
1. It is a policy that maker and checker rules will be observed strictly, i.e. the person who enters
the transaction cannot also authorize the same. Whether the same person who creates a record
has also autho-rized it.
2. Whether the sanctioned amount is less than the disbursed amount or amount disbursed is more
than the sanctioned amount.
3. Whether in case, a customer has got loans in multiple schemes (CC, LC etc.) it does not
exceed its total overdraft limit.
4. Whether loan sanctioned is linked to transactions file containing Post-dated Cheques (PDC).
Sanction should cover the PDC.
5. Whether loans treated as closed in the system has ‘Nil’ balance as outstanding or a very
insignificant amount.
6. Verify whether sanction criteria have been adhered to, i.e. whether a loan amount has been
disbursed without a loan having been sanctioned actually in the system. This could happen by
bypassing controls.
7. Whether charges have been collected in all cases of cheques returned.
8. Whether the system shows as if the loan has been sanctioned by a proper authority while
evidence is to the contrary.
9. Whether the sanctioned amount is greater than the loan requirement and also verify the user
IDs.
10. Whether there are cases where sanction is pending, but the loan amounts have been disbursed.
11. Whether the approval process is in order. Verify whether authorization is back-dated.
12. Whether tenure of the loan is in line with minimum prescribed time-frame.
13. Whether the authorization procedures are in line with Company’s policy?
14. Whether the authorization procedures are in conformity with approved procedures regarding
stages of disbursement?
15. Whether when loans are sanctioned at the branch level, they are in line with company policy.
Check whether there are compensating controls?
16. Whether all procedures have been followed in ‘Closed Loan’ account to be verified by
choosing a sample closed loan?
17. Whether in the case of a pre-closure loan, computation is in order could be verified? Whether
correct related charges are collected?
18. New loan disbursement—Review pending list of new loans on any specific categorization.
Instances of Frauds,
Its Causes and Controls
So far in this book, both in Section A and Section B, the various concepts of the Core Banking
Solution and the best method of implementing the same are covered. The chapters in Section B
specifically covered the methodologies to be adopted, for evaluating controls in a computerized
environment. As professional auditors and members of Inspection and Audit Department know
income leakages and frauds still occur frequently. These leakages and frauds are discussed and
published in print media as computer frauds in banks! These misleading headlines sometimes lead to
a misunderstanding of the situation. It is not that frauds are occurring in computerized environments
only. Sometimes, there are individuals with fraudulent intentions who always want to exploit the
vulnerable situations and weak controls and indulge in frauds. This is done with an intention to have
illegal financial gains. These frauds could be done faster in a computerized environment. There could
be more income leakage.
It would not be out of context to discuss the Equity Funding Case, which has been an eye-opener.
The fraud committed in the Equity Funding Case in the year 1973 in California, laid the foundation for
the evolvement of the profession of systems audit or auditing in a computerized environment. In the
Equity Funding Case, the brief particulars are as follows:
It was an insurance company and the management decided to adopt some means by which they
could make the performance of the company look better than what it was and thus, have the value of
the shares of the company go up. In the process, the management decided that they would create fake
insurance policies so that income would be enhanced and correspondingly sundry debtors are also
enhanced. This company had its presence in very many states in the United States of America. The
company’s auditors included the Big 4 (maybe the Big 6 then). After two years, the management got
further emboldened and they decided that it would be faster to fake insurance policies if they use the
computers in the place of the manual systems.
It was thus that the computers came into the picture. The role played by the computers was nothing
more than a facilitator for printing the insurance policies faster.
Two or three years of the usage of the computers resulted in projection of greater profits and the
expected results of the share value of the company going up happened. The Directors of the company
were happy and the auditors of the company had given a clean chit all through the years. It was a
chance revelation by a disgruntled employee which burst the bubble. The share values crashed. The
Securities and Exchange Commission (SEC), a body in USA similar to SEBI of India, had to
investigate the matter. The subsequent events as they say is history.
The auditors were hauled up for dereliction of duty, negligence and also fraud. The Board of
Directors was also held guilty of fraud. Some of the auditors settled the case outside the court. It was
in those days as shocking an event as ENRON, WORLDCOM etc., which occurred recently.
A detailed examination of the sequence of events was conducted by the Government. It was then
brought to light that while some of the auditors were fraudulent, many others were ignorant of
performing an audit in a computerized environment. They believed that as computers are infallible
any statement prepared by the computer also is infallible. They were not aware of the controls which
have to be in place if they have to rely on the computer statements. They were also not aware that in
the absence of controls within the computer systems there should be at least compensating controls
outside the system.
In view of total lack of appropriate knowledge with the auditors, it was realized that auditors need
to have a different type of knowledge to perform audits in a computerized environment effectively and
efficiently.
It is in this background that we need to understand that however advanced the computer technology
may be, unless the associated controls are in place, it would be a misconception to believe that, the
environment is foolproof and that no fraud can occur. As a matter of fact, it needs to be realized that
fraudsters who are intelligent would be making use of the sophisticated environment as a tool to
perpetuate unconventional frauds.
In the following paragraphs, it is proposed to consider a few of the live cases, where frauds have
occurred in a computerized banking environment. Many frauds have occurred in other industries also.
These are the cases known to the authors of the book due to their association with many bank
officials, as also auditors and faculty members in their academic activities, meeting participants and
professionals.
The methodology proposed for presentation of some the live cases of fraud would be:
All the cases discussed are not relating to Core Banking Solution (CBS). They include the cases of
real occurrence in Total Branch Automation (TBA) also— the technology environment which was in
existence before implementation of CBS.
The Scenario
In a bank, there was a senior clerk who worked very hard, much beyond the call of duty. He was
knowledgeable and could discharge different responsibilities. The manager of the branch was
understandably very impressed by the ‘selfless support’ being provided by the staff member. After a
year of operation of the branch, it was discovered that a sum of about approximately Rs. 2.5 lakhs has
been defrauded. In other words, customers’ money which was supposedly deposited in the bank, was
not accounted for. The bank had, after some deep analysis, the reason to believe that the particular
employee would have committed the fraud. But they had no conclusive evidence to prove their
suspicion. The concerned employee had indeed committed the fraud.
CONTROLS THAT WERE NOT IN PLACE
The bank did not follow the procedure of giving the access rights on a ‘need to know’/‘need to do’
basis. The access rights were provided on the request of the branch manager. User IDs and
passwords are provided for the different individuals. If an individuals has access to different user
IDs and passwords, he would be in a position to perform different duties and more importantly the
duties higher than his position in the bank would warrant. In this particular case discussed, the bank
did not follow the procedure as laid down by the security policy of the bank. The policy document of
the bank had clearly mentioned that;
(i) user access rights need to be given on a need to know basis.
(ii) there should be a register maintained with the following headings:
• Name of the individual
• Date of assigning the user ID
• Date of removing the user ID
• Signature of the employee
This register was envisaged by the security policy so that accountability of the individuals would
be established. The register which is originally started falls into disuse in many banks. This bank was
no exception. The concerned individual had not signed the document and hence he had not, legally
speaking, accepted the user ID allotted to him. The bank by exchange of mails had established within
itself that a particular user ID was assigned to the individual without ensuring that the employee also
accepted it as his user ID by signing the register.
The employee was encouraged by the manager to use different user IDs and the corresponding
passwords. There was no evidence that this particular individual used those user IDs and passwords.
On the other hand, he was encouraged to use other user IDs also by which process it apparently
looked that the transactions were performed by somebody other than the particular individual. He was
given rights of database administrator also. He fiddled with the database. He had created one
database for printing passbook and another for ledger purposes!
The Scenario
A bank in the process of implementing CBS had a central support team at the CPPD. These users
were allowed unrestricted remote access to the branches. One employee used this facility to transfer
funds from in-operative accounts of branches to a particular account of her relative. The money was
subsequently withdrawn. This came to light during regular concurrent audit of the bank when the
auditor noted that there was movement in the in-operative account.
The Scenario
An employee of a bank used an ATM card number and the pin mailer available at the branch to
withdraw money from a customer account to the extent of Rs. 1 lakh over a couple of days. The
customer in whose favour the ATM card was issued by the bank, had not yet collected the card but
was debited with the sum of Rs. 1 lakh.
Understandably, the customer was shocked to find that a sum of Rs. 1 lakh was withdrawn from his
account, while the fact was that he had not even received the ATM card.
The Scenario
Parameterization like creating new products etc., is done at the central location. In the present case, a
bank which was celebrating its 25th year had decided at a special rate of interest for the fixed deposit
for a period of 25 months. However, due to wrong parameterization, while creating the product, it
was possible for a customer to earn the same interest for a shorter period. It was discovered that
while the original duration was for a period of 25 months, the interest which was reasonably high
was applicable for premature closure of the same. Interest was paid at a much higher rate, in
contravention of Reserve Bank of India (RBI) regulations.
The Scenario
In a bank, the deposit module was functioning properly. A fixed deposit could be created. There was
facility for a loan to be granted on the security of the fixed deposit. A lien was marked on the fixed
deposit. The functionality as implemented originally was that a fixed deposit would not be repaid if a
loan is outstanding on a fixed deposit, in view of the link having been established. Only after the loan
is cleared, would the link between the fixed deposit and the loan be released.
This particular module was in force for more than two years and functioning properly. However, in
a particular branch, it was able to repay the fixed deposit in spite of the loan being outstanding. As a
result, the loan became a clean loan without any security. A general investigation of bad debts
revealed that in spite of the fixed deposit having been offered as collateral to the loan, the fixed
deposit was paid on maturity.
The Scenario
The following is not a case of fraud but a security concern. The bank management were concerned
about privacy issue being violated and corrective action was taken.
The customers were given the facility of viewing their own account on the net. The customers were
given a user ID and password as a response to their request for the same. By using the user ID and
password and requesting for a statement of account, they would be able to view their own account
only and also be in a position to get a printout of the same. In one of the cases, in a bank, a customer
was not only able to view his own account, but was also in a position to view six other accounts and
he could get printouts of the same and gave it to the bank. The customer’s concern quite correctly was
that if he could view the accounts of 6 other individuals, it was possible that his account also could
be viewed by the other customers. This was gross violation of the professional service assured by the
bank which includes maintaining privacy and secracy.
16 standards
39 guidelines
11 procedures
The complete details of the standards, guidelines and the procedures are available at the ISACA
website, www.isaca.org. In the following pages with the permission of ISACA, excerpts of some of
the standards, guidelines and procedures are being included. According to ISACA, the standards are
mandatory, while the guidelines are recommendatory. The objective of the auditing guidelines is to
provide additional information on how to apply the IS auditing standards. However, though the
guidelines are not mandatory, any departure needs to be justified by the systems auditor. The
procedures provide details of procedures to be followed under different circumstances to comply
with the standards. Given below are the list of standards, guidelines and procedures which may be
found relevant and appropriate for performing systems audit of banks.
25.1.1 Standards
S3 — Professional ethics and standards
S4 — Competence
S11 — Use of risk assessment in audit planning
S13 — Using the work of other experts
S14 — Audit evidence
25.1.2 Guidelines
G1 Using the work of other auditors
G2 Audit evidence requirements
G4 Outsourcing of IS activities to other organization
G7 Due professional care
G9 Audit consideration for irregularities
G11 Effect of pervasive IS controls
G13 Uses of risk assessment in audit planning
G14 Application system review
G24 Internet banking
G28 Computer forensics
G30 Competence
G31 Privacy
G32 Business continuity planning—review from IT perspective
G33 General consideration on the use of the Internet
25.1.3 Procedures
P1 Electronic fund transfer
P3 Intrusion detection
P6 Firewalls
Contents of a few of the standards, guidelines and procedures are given below:
supplemented
by comments
by authors.
Standard 3: Professional ethics and standards
This Standard apart from expecting the auditors to strictly adhere to the code of professional ethics
expects them to exercise Due Professional Care in conducting audit assignments.
The guideline number 7 deals with due professional care. The definition provided for ‘Due Care’
is as follows: ‘The standard of due care is that level of diligence which a prudent and competent
person would exercise under a given set of circumstances’.
‘Due Professional Care’ applies to an individual who professes to exercise a special skill such as
Information Systems Auditing. The guideline proceeds further to state that an individual exercising
due professional care should exercise the special skill to a level commonly possessed by
practitioners of that speciality.
Due Professional Care implies that the professional auditor approaches the work with professional
diligence. This care extends to every aspect of the audit extending to:
The Standard further states that the intended recipients of the reports have, understandably an
appropriate expectation that the Information System auditor has exercised due professional care
throughout the process of audit.
The Standard categorically states that an IS auditor should not accept the assignment unless he has
the adequate skills and knowledge to complete the work in a manner expected of a professional.
The auditor is expected to disclose the circumstances of non-compliance with professional
standards to all those who receive the communication of the audit results.
However, this Standard also states, that a situation may arise when in spite of the auditor exercising
due professional care, an incorrect conclusion may be drawn based on a diligent review of the facts
and circumstances. The subsequent discovery does not indicate lack of diligence on the part of the IS
auditor. As long as he has exercised due professional care, and has the evidence to prove it,
subsequent discovery of incorrect conclusion does not prove lack of exercise of due professional
care by the auditor.
Standard 4: Competence
This Standard lays down that a person who performs an Information Systems Audit should be
professionally competent and have the proper skills and knowledge to conduct such an audit.
In the present scenario of highly technical environment of a core banking solution, it becomes very
relevant to perform an audit of a core banking solution by an individual or group of individuals and
he/they should be highly competent. It is in this context that the Reserve Bank of India has issued the
guidelines that the auditors should be a Information Systems Auditors certified by ISACA. For
example, the banks proposing to introduce Internet banking need to get a certificate that there are
appropriate controls including effective intrusion detection systems. A certificate from a competent
person is required by Reserve Bank of India as a pre-requisite before the bank is permitted to use
Internet Banking for processing transactions. Earlier Reserve Bank of India (RBI) insisted on
certification even for just commencing Internet Banking, e.g. viewing of website.
Similarly, in other areas also systems auditors should have the competence and need to maintain it
by continual upgrading of knowledge and skills which become necessary with the technology getting
upgraded so often. The guideline further proceeds to lay down the following:
IS auditors need to have the desired level of competence which will be applied with due care
and diligence.
IS auditors who are not competent to perform should refrain from performing such services.
The audit management is responsible to entrust the audit assignments after ensuring that the IS
auditor possesses required professional and technical skills (it will be observed that in most of the
tender documents, calling for the audit of banks in a computerized environment, details of the profile
of the concerned consultants supported by documentary evidence is called for). Skills and knowledge
include proficiency in identification and management of risks and controls.
Competence means and includes possession of skills and knowledge supported by educational
qualifications and experience.
The Information System auditor and/or audit management should provide reasonable assurance
about the skills and educational qualifications and experience prior to accepting the assignment.
Where there are gaps between the actual level of competence and the expected level of
competence, this needs to be recorded and concurrence of the auditee needs to be obtained for
continuation of the audit.
Importantly, the auditors should not portray themselves as having expertise and competence which
they do not possess.
When any part of the expertise or knowledge is not available with the auditor, it is acceptable to
outsource that part of the assignment to an expert. However, there needs to be reasonable assurance
provided that the outsourced agency possesses the required competence!
Standard 11: Use of risk assessment in audit planning
The systems auditor is expected to use an appropriate risk assessment technique in developing an
audit plan and in determining priorities.
Use of risk assessment in the selection of audit projects facilitate the auditor to quantify the amount
of IS audit resource.
Comments: While performing IS audit, a competent auditor would know where the risks are likely
to be high. For example, inappropriate access rights, or lack of good password practices are the high
risk factors.
Similar would be the scenario with vulnerabilities in network. (Also refer to Guideline No. 13
which deals with use of risk assessment in audit planning)
Standard 13: Using the work of other experts
The Standard states that Information System auditor should consider the work of other experts, after
satisfying themselves about their professional competence, relevant experience and quality control
processes before engaging them.
It is necessary for the IS auditor to assess whether the work of the other expert is adequate and
complete so as to help him to conclude on the current audit objectives. If the work of the other expert
does not provide adequate evidence, it is necessary for the auditor to apply additional audit
procedures to obtain appropriate audit evidence. When such additional evidence is not obtained
through additional test procedures, he needs to mention the same and thereafter provide an audit
opinion. When there are constraints that could impair the work to be performed, auditor is
mandatorily expected to consider, using the work of other experts. The expert could be internal to the
organization or external. The auditor should have access to all work papers, supporting
documentation and reports of other experts, provided there are no legal issues.
IS auditing standard number 6 states that he should obtain sufficient, reliable and relevant evidence
which would be useful to achieve the audit objectives.
Guideline 4: Outsourcing of IS activities to other organizations
This Guideline categorically states that when any aspect of the IS functions has been outsourced to a
service provider, the scope of audit charter should include these services also. The audit charter
should include review of the service level agreement with the service provider, the performance of
systems audit work of the outsourced function and report the findings to the service user.
The auditor should obtain the following information:
The Guideline proceeds to state that if irregularities have been detected, the IS auditor should
assess the effect of these activities on the audit objectives and reliability of audit evidence collected.
The Guideline more importantly states, that the auditor should consider whether to continue the
audit or not when the effect of the irregularities appears to be so significant that sufficient reliable
audit evidence cannot be obtained.
If the audit indicates that irregularities could occur, the IS auditor should recommend to the
management that the matter be investigated further.
Reporting
The detection of irregularities should be reported to the appropriate authorities within the
organization, as occurrence and effect of irregularities is a sensitive issue, reporting itself carries its
own risk as following:
Further abuse of control weakness as a result of publicizing the details of the irregularities.
Loss of image to the organization.
It is recommended that the irregularity be separately reported from other audit issues. If audit scope
has been restricted, the auditor should include an explanation of the nature of the effect of this
restriction in the report.
Guideline 13: Use of risk assessment in audit planning
The Guideline 13 states that any appropriate risk methodology could be used.
IS auditor should consider the following aspects:
Inherent risk
Control risk
Detection risk
Internal risk is the susceptibility of an audit area to error, unless there is an appropriate internal
control.
Inherent risk with operating systems is high, unless security settings are set properly and patches
are updated regularly.
The guideline goes on to state that the auditor while assessing the inherent risk should consider both
pervasive and detailed controls. When services are outsourced and there is direct access by
customers, auditor should review pervasive control to the appropriate level.
At the detailed control level, the Information System auditor should consider to the level
appropriate for the audit area. Special attention needs to be paid to the complexity of the systems
involved, susceptibility to loss or misappropriation of the assets controlled by the system.
Comments: In a core banking solution, technology is complex.
In Internet banking, fund transfer is effected, which is a highly sensitive function.
Control risk: The control risk is the risk that an error which could occur in an audit area which
will not be prevented or detected on a timely basis by the internal control system.
Comments: Manual controls in a complicated technology environment are inappropriate and
ineffective. Appropriate built-in controls in the computer system is needed at all the stages of input
and output process.
The audit logs need to be enabled and the logs need to be reviewed. If neither the logs are enabled
nor are they reviewed, there is a control risk.
Detection risk tuat
Detection risk is the risk that an auditor’s substantive procedures will not detect an error.
The guideline states that the documentation of the auditor should describe the risk assessment
methodology and identification of significant exposures and the corresponding risks.
The document should also include the audit evidence, used to support the auditor’s assessment of
risk.
IS auditing procedure number 1 deals with ‘IS Risk Assessment Measurement Procedure’. It
defines risk ‘as the possibility of an act or event occurring that would have an adverse effect on the
organization and its information systems. Risk-based audit approach is the expectation in the current
scenario.
In a risk-based audit approach, audit or assesses the risk and based on the information, decides
whether the compliance testing or substantive testing would be performed or not. Auditors are relying
on internal and operational controls as well as the knowledge of the organization. The procedure
clearly enunciates that IS auditor is interested in uncontrolled risks and in critical controls. Thus, in a
risk-based audit approach, IS auditor will be interested on technology-based systems which provide
controls for business functions where there is high inherent risk and in technology-based functions
where there is higher than acceptable residual risk.
The procedure deals with IS risk assessment methods and provides sufficient reading material and
examples to understand and perform risk assessment for an audit.
Guideline 14: Application systems review
This Guideline describes the recommended practices in performing an application systems review.
The IS auditor should gain an understanding of the organization’s business objectives as also the
level and manner in which information technology and information systems are used to support the
organization. The auditor should have an understanding of the organizational structure including the
roles and responsibilities of key Information System staff and the business process of the application
systems.
The Guideline further provides application level risks at the system and data level including the
following:
Application controls may consist of purely built-in controls of the system or a combination of built-
in controls and controls outside the system.
The objectives and scope of the application systems review would cover the following criteria:
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability of information
The Guideline while discussing the details of performance of audit, expects that an auditor should
prepare a high level audit flow diagram or utilize the system documentation, if provided. Application
interfaces with other systems should also be documented.
An auditor is expected to obtain an assurance that the controls are operating as intended. This could
be accomplished through inquiry and observation, review of documentation, testing of application
system controls etc. Effectiveness of computer’s controls is dependent on strong general IT controls.
If general IT controls are not reviewed, ability to place reliance on the application controls may be
severely limited and auditor should consider alternative procedure.
If weaknesses are identified, during the application systems review and they are considered to be
significant or material, appropriate level of management should be advised to undertake immediate
corrective action. The Information System auditor should include in his report appropriate
recommendations to strengthen controls.
Guideline 24: Internet banking
The term Internet banking is defined as the use of the Internet as a remote delivery channel for banking
services including opening of accounts, transferring of funds and electronic on-line payment.
Internet banking activities do not raise risks that were not already identified in traditional banking,
but increase and modify some of the traditional risks.
The core banking and information technology environment are tightly coupled thereby influencing
the overall business profile of Internet banking.
The Guideline states that risk management is the responsibility of the Board of Directors and senior
management. Implementing technology is the responsibility of information technology senior
management. They are expected to have the skill to effectively evaluate banking technology and
products. The bank should consider contracting with a third party, if capabilities are not available
within the organization. The Board of Directors should receive regular reports on the technologies,
implied risks assumed, and how those risks are managed. The review of internal control in the
Internet banking environment must help the IS auditor to provide a reasonable assurance that the
controls are appropriate and functioning appropriately.
Control objective for a bank’s internet would include the following:
In the case of Internet banking involving payments or fund transfers, non-repudiation and integrity of
the transactions are essential. It is essential in Internet banking to confirm that any communication,
transaction or access requests is legitimate. Accordingly, banks should use reliable methods.
Auditability has more significance in the Internet banking environment because a significant
proportion of the transactions takes place in paperless environment.
Following are some of the competence that are expected from an Information System auditor:
Skills and knowledge: The Information System auditor should have the necessary technical and
operational skill and knowledge to carry out the review of the technology employed and risks
associated with Internet banking.
The technical knowledge necessarily would include competence to evaluate aspects such as web
hosting technology, encryption technologies, network security architecture, and security technologies
such as firewalls, intrusion detection systems and virus protection. Where expert advice or expert
input is necessary, appropriate use should be made of external professional resources and the
management be informed of the need to do so.
Planning: The Information System auditor should gather information regarding Internet banking
objectives of the bank, such that it helps in carrying out a high level assessment of the banking risks as
well as the risks pertaining to information criteria.
The IS auditor should follow a risk assessment approach for evaluating the main potential, general
and specific threats connected with the implementation of Internet banking, possible manifestations,
the potential effect on the bank, the likelihood of occurrence and the possible risks management
measures. The following risks should be evaluated:
Strategic risks
Security risks
Legal risks
Reputational risks
The IS auditor, in consultation with the bank’s management should, clearly define the scope and
objective of the review of Internet banking. The auditor should formulate the approach in such a way
that the scope and objectives of the review would be fulfilled in an objective and professional
manner. The approach would depend on whether the review is pre-implementation review or post-
implementation review.
Performance of Internet banking review: In general while analyzing and interpreting an Internet
banking environment, a study should be made of available documents including:
To review problems in Internet banking which have been noted previously and which may require
follow-up, the IS auditor should review the following:
Earlier reports
Follow-up activities
Work papers
Internal and external audit reports
As part of IS risk assessment, external IS threats should be evaluated depending on the nature of
product offered by the banks. These threats include the following:
Denial of service
Unauthorized access to data
Unauthorized use of the computer equipment.
Depending on the nature of the pre- or post-implementation review, the IS auditor should satisfy
himself that the processes are functioning as intended. These tests include the following:
Testing of balance enquiry
Testing of bill presentation and payment
Testing of security mechanism using penetration testing
Network mapping
Network routing
Network security assessment
Internal and external intrusions
To identify any problems relating to the Internet banking, the IS auditor’s review should include the
following aspects:
Organizational aspect: The organizational aspects to be reviewed would include the following:
Due diligence and risk analysis have been performed BEFORE the Bank provides internet
banking facilities.
Due diligence and risk analysis have been performed where cross-border activities are
conducted.
Internet banking is consistent with the bank’s overall mission.
Internet banking system and services are managed inhouse or outsourced with third party.
Personnel of the organization display acceptable knowledge and technical skills to manage
Internet banking.
Segregation of duties are in place.
Management reports are adequate to manage Internet banking transactions and payment
services activities.
Policy aspect:
(a) Review whether suitable policies are in place regarding:
• Acquisition of customers
• Engagement of suppliers
• Customers authentication
• Privacy of customers data
• Audit trail
• Review of usage logs
• Updated knowledge on legal developments associated with
Internet banking
(b) Bank is providing accurate privacy and disclosure associated with Internet banking product.
(c) Information is provided on the website to allow customers to make enough judgment about the
identity and regulatory status.
(d) There are appropriate procedures in place regarding:
• Change control
• Review of audit trail
• Review of usage logs
Planning aspect: Planning aspect should review whether:
(a) The planned technology architecture is feasible and will result in safe and sound operations.
(b) There are appropriate incident response plans in place.
(c) There is an internet product life cycle and is strictly followed for developing, maintenance and
upgrading of internet applications.
(d) Business continuity plans (BCP) for critical processes are in place and regularly tested.
System infrastructure aspect: The review should include the following:
Computer forensics has been applied in a number of cases including, but not limited to:
Fraud
Computer misuse
Technology abuse
Malicious mail
Information leakage
Hacking
Illegal transfer of funds
Data protection
Data acquisition
Imaging
Extraction
Interrogation
Ingestion/normalisation
Reporting
The challenge to computer forensics is finding the data, collecting it, preserving it and presenting in
a manner acceptable to a court of law.
Guideline 30: Competence
An IS auditor needs to acquire the necessary skill and required knowledge to carry out assignments.
The additional challenge is to maintain competence by continuously upgrading knowledge and skill.
The IS auditor has the following responsibilities;
1. Skills and knowledge: The IS auditor is responsible for acquiring the required professional
and technical skills and knowledge to carry out any assignment that he agrees to perform.
2. Audit management is responsible for ensuring that the audit assignment is entrusted to an
individual or a firm, only after ascertaining that the concerned person has the required
professional and technical skills and knowledge to perform the task.
3. Competence: Competence implies possessing skills and knowledge and expertise through an
adequate level of education and experience. The IS auditor should provide reasonable
assurance that he/she possesses the skills and knowledge necessary to attain the required level
of competence.
4. Continual maintenance: The IS auditors should continually monitor their skills and
knowledge to maintain an acceptable level of competence.
5. Evaluation: An appropriate level of management is required to evaluate the performance of
an internal IS auditor and wherever appropriate and necessary, the performance of an external
IS auditor.
6. Gaps noticed during evaluation should be addressed appropriately.
7. Availability of competent resources: IS Auditor-Audit management should provide
reasonable assurance that requisite resources with the necessary skill, knowledge and
required level of competency are available before commencing an audit assignment.
The Information System (IS) auditors should not portray themselves as having expertise,
competence or experience they do not possess.
Outsourcing: When any part of the audit assignment is outsourced, reasonable assurance must
be provided that the outsourced agency possesses the requisite competence.
Guideline 32: Business Continuity Plan (BCP)—review from
IT perspective
This Guideline deals with Business Continuity Planning (BCP). It recognizes that organizations are
more vulnerable than ever to possibility of technical difficulties, disrupting business. Any disaster
from floods, fire, viruses and cyber terrorism can affect the availability, integrity and confidentiality
of information that is critical to business.
The purpose of this Guideline is to describe the recommended practices in performing a business
continuity plan review from an IT perspective. The purpose also is to identify, document, testing and
evaluating the controls and the associated risks relating to the process of BCP from an IT perspective
as implemented in an organization. This Guideline highlights the application of IS Standard S-6.
Performance of audit work to obtain sufficient, reliable, relevant and useful audit evidence during the
review of BCP from an IT perspective.
The Guideline gives an explanation for the various acronyms used. e.g. Business Continuity Plan
(BCP), Business Impact Analysis (BIA), Disaster Recovery Planning (DRP) etc.
The Guideline while providing an overview of BCP from an IT perspective, mentions the
components of BCP as follows:
It lays down the key factors of BCP. Most importantly, this Guideline under the heading
‘Competence’ and sub heading ‘Skills and Knowledge’ lays down that IS auditor should provide
reasonable assurance that he has the required knowledge and skill to carry out the review of the BCP
and its components.
The Guideline further discusses the impact of outsourcing of IS activities by the organization. It
emphasizes the fact that in such circumstances, the auditor should review whether the service
providers’ BCP process conforms to the organization’s BCP.
The Guideline concludes by providing the contents of the final report that an IS auditor should
produce on the processes, facilities and technologies involved in the BCP, the risks assumed and how
those risks are managed in case of contingency. It highlights the fact that monitoring the performance
of the review of BPC is the key success factor. The report produced as a result of the BCP review
should importantly highlight the fact that there is reasonable assurance on the BCP process and
relevant internal controls to ensure that IT systems can be recovered within an acceptable timeframe
in the event of disruption.
Guideline 33: General considerations on the use of Internet
This Guideline needs to be read along with Guideline No. 22 dealing with B2C E-Commerce review
as also Guideline No. 24 dealing with Internet banking. It also suggests that this Guideline needs to be
linked to the following procedures:
The enterprise is exposed to many threats by connecting to the Internet. To deal with those threats,
it is important to run a risk analysis and take the necessary security precautions. As Internet is not
static, threats also change, and consequently there would be changes for the security measures to be
taken. This Guideline explains various threats like;
Technical failure
User errors
Misuse of systems or disloyal employees spreading confidential information.
It considers also the various services available on the Internet like Email, www, ftp, Telnet etc. It
considers the various security measures under the following heads:
This Guideline most importantly highlights major factors to be considered while performing
audit/security review.
The Guideline provides the various factors to be considered while performing a detailed review.
It recommends that documentation routine for monitoring should contain, as a minimum, description
of responsibility for administration and maintenance of Internet connection including back up
resources. The procedures to review includes the following:
This Guideline also discusses the technical issues and security measures.
Procedure 3: Intrusion Detection
This Procedure defines IDS. Intrusion Detection is the process of detecting unauthorized use of
systems and network through the use of specialized software and/or hardware. The procedure
describes a number of types of Intrusion Detection Systems (IDs), e.g. user-based. network-based. It
discusses the procedures to review IDS implementation.
Procedure 6: Firewalls
The Procedure deals with evaluation of security concerns in firewalls. It is primarily intended for IS
auditors—internal as well as external. The Procedure further goes on to mention that documents can
be used by other IS security professionals with responsibilities in firewall configuration. The
Procedure deals with types of firewalls. It contains details of common functions and features related
to firewalls. It includes also a description of Intrusion Detection Systems (IDS). The Procedure also
has got details of all common firewall configurations. The procedure highlights the risks controlled
by firewalls. It contains procedures to review firewalls under the following heads:
Configuration
Monitoring of data and incident response
Backup and recovery
APPENDIX
Date change
Posting of balances after EoD operations (End of Day explained later in this document) are
run
Generation of reports.
Boundary control: Each object in an application should accept values only within a particular
range. This is enforced by boundary controls by fixing an outer limit for the values that an object can
accept.
Bridge: A bridge is network device that acts at Layer 2 of the OSI model. It facilitates the
following:
Bridges have fewer ports compared to switches and can connect only few systems. Also bridges
are not as efficient as switches in managing MAC address table and in forwarding data. Hence,
switches are slowly replacing bridges.
Browser: Browser is a software that enables a user to display and interact with the data stored of a
website on the World Wide Web or Local Area Network.
CISA: The Certified Information Systems Auditor (CISA) is a certification offered by Information
Systems Audit and Control Association (ISACA), USA for recognising professionals conducting
Information systems audits, control and security. For more information about CISA, visit
www.isaca.org
Client-server: The client-server architecture is an architecture where there is a server with very
high processing capabilities and clients (computers connected to the server) that has basic processing
capabilities. Thus most of the processing is done centrally at the server which is read by the clients
connected to the server. This takes off the processing load from the clients. It also facilitates effective
resource sharing with all the clients accessing a common resource at the server.
Confidentiality: Confidentiality means the protection of sensitive information from unauthorized
disclosure.
Contingency plan: Contingency plans are made for specific situations to cope with any mishaps.
This is a part of BCP.
Conversion audit: Conversion audits are done before data is migrated from one application to
another application. During this process:
The controls that were available in the old application but not available in the new one are
identified and analyzed.
The new control requirements and controls are identified and analyzed.
Core banking: Core banking describes the banking services provided by a group of networked
bank branches. Customers can access their accounts and perform certain transactions from any of the
branches.
Core banking solution: The core banking solution is a combination of application software and
networking devices. All the bank branches are connected to the bank’s data center. The main
application resides in an application server at the data center and a client version is installed in all
the systems connected to the core banking network. Thus, it facilitates anywhere banking and anytime
banking.
Corrective control: A corrective control identifies a problem and minimizes impact from the
same. To be more effective, the corrective control has to coexist with preventive and detective
controls.
Data center: A data center is a large data-housing infrastructure that provides secure, high
bandwidth access to the clients, for a range of network related services. Essentially, it comprises of
servers, firewalls, high bandwidth network links and stringent physical and logical access security
facilities.
Data conversion: Data conversion is the process of converting data from one form to another.
Whenever there is a change in the application or operating platform, the data has to be converted to
be compatible with the new requirements.
Data storage: Data storage is all about securely storing all data generated by processing the
application. The data should be accessible only on a need to know basis. For the data that is very
critical that there must be some facility to take data backups at regular intervals.
Data Entry Screen: Data entry screen is the interface presented to the user by the application to
input data. The application after processing the data, stores it in the database.
Database administration: Database administration is about maintaining the database to provide
for recoverability, integrity, security, availability and efficient performance.
De-militarized zone (DMZ): De-militarized zone (DMZ) is a border network that connects both to
the internal network (intranet) and to the external network (internet). This is a security zone for the
internal network as a firewall is configured here to block unauthorized and malicious traffic.
Default gateway: Default gateway is a device (router or layer 3 switch) in the network that acts as
an access point to another network. Thus, it is placed at the border of between two networks.
Denial of Service (DOS): Denial of Service is a state during which the computer resource is
unavailable to the legitimate users. This usually happens when the system memory is flooded with
service request (mostly malicious in nature) such that the illegitimate service requests are addressed
slowly or dropped.
Detective control: Detective controls are those which detect and report the occurrences of an
error, omission or malicious activity.
Disaster Recovery Planning (DRP): Disaster Recovery Planning (DRP) is done by an
organization to resume critical business processes following a disaster by gaining access to the
required data, hardware and software. DRP is a part of a larger process called Business Continuity
Planning (BCP).
Distributed Denial of Service (DDoS): The Distributed Denial of Service (DDoS) is a network
attack in which many compromised computers flood the server with service requests thereby
rendering the server to be inaccessible to the legitimate users.
Dumb terminal: A dumb terminal is a computer with limited functionality. In a client-server
architecture, the client computers have limited processing ability and acts as a dumb terminal.
Electronic Fund Transfer (EFT): Electronic Fund Transfer (EFT) is the process of money
transfer from one account to another electronically. This computerized transaction is very fast and
happens on a real-time basis.
Enable password: ‘Enable password’ is with regard to router security. The default password
should be set to something else and the same should be encrypted and stored so that it cannot be
compromised.
EoD (End of Day): EoD (End of Day) is a set of activities programmed in the application that is
performed before closing the application for the day. The EoD activities differ from one application
to another but it mainly do the following operations:
Interest application
Posting of charges
Posting of entries in various accounts
Escrow mechanism for software source code: Escrow is a legal arrangement in which the
software source code is delivered to a third party who have agreed to act as an escrow agent who
shall release the same to the aggrieved party if the terms of contract (like failure to maintain
application, transfer of ownership and liquidation of the developer’s company) are not complied
with.
Exception reporting: Exception report is a report generated by the application tracking all
exception items during processing like the following:
The IDSs are of two types—Host-based Intrusion Detection System (HIDS) and Network-based
Intrusion Detection System (NIDS).
IP address: The IP address is a unique address that is assigned to all computers in a network. The
IP address along with MAC address is used to send and receive data between computers in a
network. These addresses are represented in ‘dotted decimal format’.
IP Address — version 4 contains 32 bits. Example: “192.168.138.10”
IP Address — version 6 contains 128 bits is slowly being introduced as the number of computers
that are being networked are increasing significantly. Example:
“2001:0db8:85a3:08d3:1319:8a2e:0370:7334”
IP spoofing: IP spoofing is the creation of IP data packets with forged source address. The senders
IP address is concealed to impersonate that of another computer.
Local Area Network (LAN): Local Area Network (LAN) is a computer network covering a small
geographic area. Example: Network in an office connecting few computers.
Librarian: Librarian is the person in whose custody all the software executables and source code,
license and user manuals are available. Any new software that has to be deployed should first go to
the librarian.
Limit check: It is a validation to ensure that the data does not exceed a particular limit.
Logon ID: Logon IDs are similar to the user IDs.
Logs: Logs are record of events that has happened in the system. It contains the date, time, user ID
and event summary for all activities in the system. Thus, it serves as an important evidence to prove
the activities in the system. Control should be there to ensure that logs are accessible only on a need
to know basis and it should not be possible to modify or delete logs.
Maker-Checker concept: Under the Maker-Checker concept, there will be one person to enter
data in the system through his user account and there will be another person who logs in with his user
name and password to verify and authorize the data entered. Thus, no transactions will be processed
by a single person.
Middleware: Middleware is a system that converts data to a usable format when the same data has
to be used by different applications.
Monthly backup: Monthly backup is the backup taken at the end of a month. Usually, on a day-to-
day basis incremental backups are taken and at the end of the month, a complete backup is taken.
Multiplexing: Multiplexing is done when multiple data signals (analog or digital) are combined.
Thus, even if data signals are received from different channels, they are combined for processing.
Network cabling: Network cables are those that physically connect computers and other
peripherals in a network. There are different types of cable like fiber optic cable, twisted pair cable
and ethernet cable.
Network Interface Card (NIC): A Network Interface Card (NIC) enables computers to
communicate across a network using cables or even without using wires. Each NIC will have a
unique ID, called the hardware ID or Media Access Control (MAC) address that is used along with
IP address to send and receive data between computers in a network.
Switches have more ports compared to the bridges. Thus, it can connect more devices. Besides,
switches are more efficient in managing MAC address table and in forwarding packets compared to
bridges.
Switch
System administrator: A system administrator is responsible for managing a computer system.
The system administrators are super users and have complete access to the system.
System intrusion: System intrusion is breaking into a security system to access confidential
information and perform attacks like denial of service. The intruder may or may not have an intention
to trespass the security system. Techniques that an intruder could use for this purpose include hacking,
spoofing, sniffing and social engineering.
Test data: Test data is used to test the functionality of the application. It is important that the test
data should be comprehensive to cover all possible business cases.
Total Branch Automation (TBA): Total Branch Automation is computerization at the branch
level. In this set-up a server in each branch hosts the application and database. All the computers
connected to the server will access the application and database through the Local Area Network
(LAN).
Trailer label: Trailer label is used to check the completeness of processing. It is available at the
end of each record and the summation will be checked against the control total.
URL: Uniform Resource Locator (URL) is a unique address for locating a web page in the Internet.
USB ports: Universal Serial Bus (USB) ports are used to connect computer peripherals such a
mouse, keyboard, printers, scanners and flash memory. These devices have the plug and play
capability (devices can be connected or disconnected without rebooting the computer).
Universal Serial Bus Ports
User Acceptance Testing (UAT): User Acceptance Testing (UAT) is done before product
implementation to make the users get accustomed to the application. In the process, the users will also
check if the application serves the business requirement.
User IDs: User IDs are unique names that identify each computer user. User access rights are
specified against each user ID in the system. To gain access into the system, user has to enter the user
ID and the password which will be verified by the system.
Version check: Version check is a verification, conducted for confirmation of the version used.
Version control: Version control is the process of differentiating software releases with a unique
serial version number. Thus, it distinguishes each release of the software. It is important the librarian
holds all the versions of the software.
Vulnerability testing: Vulnerability testing is done to assess the adequacy of controls and identify
any security threats in the system. Nessus is a popular vulnerability scanner tool that is used by many
companies. For more information on Nessus, visit www.nessus.org.
Virtual Local Area Network (VLAN): VLAN is the method of creating virtual networks within a
physical network. Each virtual network thus created, will act as a separate network. Advantages of
VLANs include:
Backup process, 52
Backup server, 44
Bank guarantee, 67, 177
BCP and DR, 112
Bills, 68, 178
Branches, 200
Business continuity management, 110
Business continuity plan, 249
Business continuity planning, 141
Database administration, 21
Database events auditing, 209
Database log, 207
Database security control, 128
Database server, 11
Data centre, 23, 36, 41, 51
Data migration, 75
Data process tracking, 170
Deposits, 71, 182
Disaster recovery—cash management system, 146
Disaster recovery—Internet banking, 145
Disaster recovery for ATM, 144
Disposal of media, 32
Domain controller, 13
Domain controller baseline policy, 164
Domain policy, 161
Domain server, 155
Dynamic web, 9
Fault logging, 30
Firewall, 40, 252
Firewall and router security policy, 106
Firewall standards, 31
Front office operations, 200
Raid, 43
Redundant network connectivity, 142
Remittances, 70, 180
Restore request, 53
Risk analysis, 25
Risk computation, 114
Risk management, 117
Risks type, 114
Router security policy, 137
Routers, 14, 39
RTGS, 94
RTGS system, 204
Tape lebelling, 54
Tape management, 53
Tape retention, 54
Technical vulnerability, 109
Test environment, 150
Third party service delivery, 105
Total branch automation, 1