* 'Information System Audit Policy for Banking and Financial Sector dated October 2001 issued by RBI.'
* 'Internet Banking in India' dated 14/6/2001 issued by RBI.
* 'Information Technology Act 2000' and subsequent amendments.
* 'Storage of Electronic Records in Banks' issued by Indian Institute of Bankers in July 2006.
* Jilani Committee
* Narsimhan Committee – Second
* Vasudevan Committee
* Internet Banking Committee
* Working Group for Information System Security for the Banking & Financial Sector headed by Dr. R.B. Burman, ED. RBI
* Committee on Computer Audit under the Chairmanship of Shri A.L. Narsimhan, Chief General Manager, Institute of Chartered Accountants of India SBI, Citi Bank and ICICI Bank.
It would stand in good stead for all Bank Auditors to have perused these documents before commencement of Bank Audit in any role.
No matter how complex any discipline is, it is based on logic. Core Banking Safety is also based on some logic. If one can deduce the commonality of the elements one would be able to reduce the concerns addressed to a handful and any auditor would be able to go even beyond the specifications of the various RBI Circulars by assimilation the spirit of the various circulars and committee recommendations.
Core Banking Environment Defined
Core Banking Environment in India is akin to Centralised Data Management. In such an arrangement, the server or servers are located at one place called the Data Centre. All data as well as the application software is located here. Branches and Administrative offices are connected by some network. Earlier, leased line network was the popular one. However, being costly, other media have followed, such as VPN (Virtual Private Network which is through the internet) Wireless, VSAT (Very Small aperture terminal which uses satellite). A diagrammatic representation of a typical Core Banking Environment is shown here.
Logical Objectives of Core Banking Audit
The logical objectives of Core Bank Audit can be boiled down to 3Cs.
* Continuity
* Confidentiality
* Correctness
One can also claim these to be ‘RISKS” of Core Banking.
Continuity: Service to the Customers (account holders) of the Bank is the main reason why the computerization has taken place. Therefore, the Bank needs to take various measures to ensure that there is no disruption of service. If there is accidental disruption of service, what measures can be taken. Also, (more important) within what period of time will the normal services be restored. It would not be out of place to mention here that the ‘disruption period’ is very often not estimated. A concise example of continuity of service especially in a Core Banking Environment would be the disruption of communication. As seen in the diagram, each Bank is expected to have a ‘back-up’ network system. Once the primary network is down, the back-up network is expected to become active and continue the service to the customers. Of course, some Companies (unfortunately none of them Banks) have even the ‘active-active’ position where both networks continue to remain active to obviate even one second of disruption. How this aspect is addressed during audit can be seen when we list later in this paper, various activities to for the attainment of this objective.
Confidentiality: Data of the customer is confidential and should not be leaked into unauthorized hands. To ensure this, one way would be to ensure that access to the Bank’s database is given to authorized personnel only. A further filter would be ‘need to know’ policy where entire data access is not granted to persons whose job card does not justify so. This is why there are access levels in the application software.
Correctness: Correctness should be assured for every voucher entered as well as every processing and calculation. ‘Validations’ during data entry where the issued cheque number is matched with the distinctive number of cheques issued to the account holder is one stark example of data validation. Being a computer, the calculation of Interest earned and interest paid is expected to be accurate. However, this may not be so is the experience of some of the system auditors because, after all, it is a human who has written the processing code and he may have faltered and the Quality Control department may also not have detected it.
Addressing the Risks of Core Banking
Risk based audit is the recommended angle of audit of the times. Adapting it to Core Banking would be a natural extension which covers better the critical concerns especially in the area of a technology as new as core Banking. Addressing the risks is given below in the format of a checklist. These are merely illustrative and should serve the reader as incentive for development of more actions customized to the CBS environment under audit because each environment will most certainly have its own unique aspects having large implications on audit.
Does the Bank have the following policies is your first step of query. Mere existence of such a policy means some thought has gone into the matter and logically, execution is expected. However, in the days of outsourcing, we have noted that policy is created by a consultant merely for satisfaction of some regulatory checklist and consigned to the bottom drawer. In such a case, ‘non’ adherence’ to Bank’s own policy are some findings you can highlight in your report.
1. Information Technology (IT) Security Policy
2. Business Continuity and Disaster Recovery Policy. This should be at the level of Data Centre as well as the branches.
3. Escalation policy. Here, how to ensure the seniors are made abreast of issues/problems is what the policy spells in detail.
Risk of Continuity.
Data Centre(DC) Set-up
Risk defined: Neighborhood and Old building or buildings with non-maintained structure or with old electrical connections may endanger the safety of the computers in the Data Centre.
The Risk discussed : The physical location and condition of the building, its neighborhood bearing impact on the DC is covered here to explore the risks that are currently faced and might be faced in the future along with the caution notes if any. The intention is to explore the assurance of safety of the equipment implying continuity of service as well as confidentiality of data of the customers and that of the Bank.
Illustrative Checklist points:
1. Building housing the Data Centre should be sound if not new.
2. State of the building and electrical connections should be sufficiently safe and the building should not have a recent record of short circuit triggered fires.
3. If the location of the DC is on the last floor of the building, leakage prevention actions taken to prevent rain leakages should be examined.
4. Is there any high risk structure next door like a chemical company, Petrol Pump etc.?
Management of Data Centre and DR Site
Risk defined: The investment of the Bank in the assets of the Data Centre comprising of the Computer Hardware and environmental control can be protected and exploited only if these are managed prudently.
The Risk discussed: The management of this asset of the Bank has implications on efficiency and efficacy of the Bank's investment in the Data Centre. Therefore it is of value to evaluate the management practices to achieve this end. The personnel allocated for this critical department are the ones who determine the smooth functioning of this service to the branches and customers.
Illustrative Checklist points:
1. Does the Bank have an IT Committee which meets regularly and minutes its working?
2. Does the Management Chart of the IT Department display proper division of work with representation of each work centre for each shift? Work Centres in Data Centre are normally: Data Base Administrator, Application Controller, Network/Communications engineer.
3. Is there adequate level of seniority of the team as well as of the Head of the Department? (because the head reports directly to the CEO/MD of the Bank)
4. Is the general rotation policy of the Bank also followed here? There is merit in the rotation system and technical ability/knowledge is no excuse for such a critical policy to be abandoned.
5. Is the staff of the Data Centre involved in the primary function of their appointment? It is often seen that lack of technical knowledge on part of the senior executives forces the staff to perform other functions of Banking such as clearing or trouble shooting of clearing on a daily basis. This distracts them from their primary task.
Data Centre Layout & Control
Risk defined: Layout of the Data Centre is critical for the physical access and safety of the Hardware of the Data Centre.
The Risk discussed: The Hardware control of the assets of the Data Centre is one aspect of security and control of the data of the Bank and continuity. Security and environmental protection imply safe and continuous service to the branches and thus, customers.
Illustrative Checklist points:
Physical Access Controls
1. Does the DC have clear demarked zone of RED/YELLOW/GREEN status?
2. Is the entrance to the RED Zone (Server farm) restricted by biometric reader?
3. Is there sufficient security to ensure protection of the Costly equipment and equally costly data within?
4. Does the Bank ensure technical inputs of the IT department in the choice of vendor for IT?
Network Security Control
Risk defined: Network management in core Banking environment is critical for the communication with the branches which also translates to the success of core Banking but the failure of which implies low customer service as well as risk of transaction.
The Risk discussed: The Servers at the Data Centre do contain the software as well as data. However, the branches have no use of this data unless it is delivered to them through the network of the Bank. Choice of network providers and their uptime play a crucial role in a good network.
Illustrative Checklist points:
1. Is there sufficient staff to monitor the network to be ‘up’ for 24 hours?
2. Does the DC have a software which indicates the links to be down BEFORE the Branch phones and informs them? Free/Demo versions of software a commonly known to be used. But some are manually driven like the PING software. Either these are manually activated or automatic. Manually active or automatic. Manually activated procedures are good assurances for network condition appraisal especially of the Secondary / Back up network. To monitor the primary network this way would mean the operator does nothing the whole day but PING each branch in turn. If such an action is made automatic, then this would eat up the band with and the Bank would create its own denial of service.
3. Is the network down time logged to demand either refund where the promised uptime is not delivered by the service?
4. In case of repeated downtime affecting Service or reliance on only one network making the operations risky, does the IT committee contemplate change and have an evaluation procedure before the change?
Disaster Recovery (DR) and Business Continuity (BC)
Risk defined: Absence of proper DR and BC actions creates the risk of continuity of business in case of loss of data from the Main Server or Data Storage units of the DC or communication between the DC and the branches.
The Risk discussed: Despite best efforts by the Bank and Bank's vendors, there are certain circumstances which may render the best of efforts unsuccessful and the Data Centre may not perform the expected function of connectivity. In such circumstances, if there is a Disaster Recovery (DR) site located away from the Data Centre and confirming to internationally accepted standards, the branches can connect to the DR site and business continuity (BC) is achieved. Some initial points are mentioned below but a detailed coverage is done in a separate section of this report.
Illustrative Checklist points:
1. Does the Bank have a Disaster Recovery Centre as defined in the Bank’s DR and Continuity Policy?
2. Is the location of the DR Centre in a place that is in a different seismic zone? DR Centre in the same city is not a DR Center but a back-up centre.
3. Is the DR Centre properly manned and if so, are the personnel rotated to ensure they are alert?
4. If the DR Centre is not manned, then what arrangements are made to ensure the DR Centre can be activated remotely?
5. When was the last time DR Centre tested and is there a detailed report with full comparison of response time – actual against the expected? DR Centre testing at least once a year is a comfort assurance frequency.
Risk of Confidentiality
Logical Access Control
Risk defined: Application access control is the second level of control to ensure safety of data. Various control techniques are available and the implemented ones have to be evaluated for their appropriateness. How the Bank ensures unauthorized persons do not have access to the application system and database
The Risk discussed: Since the access to the servers is possible from physically remote locations of the Bank network, it is necessary to also secure the servers from an access outside the DC. This control is possible by a strong password algorithm.
Illustrative Checklist points for Logical access Control:
1. Logical Access would mean the USER ID and PASSWORD given to authorized users consisting of staff, auditors etc.
2. What is the policy of granting new user ID for newly appointed staff? Is it to your satisfaction to prevent accidental grant of access?
3. Are the transfers and retirements handled with equal security to ensure an ex-staff does not have access after his period of service?
4. How are the passwords granted to temporary users like Auditors and Software Engineers who have come to the Bank for maintenance and trouble shooting?
5. Is there a mechanism to ensure one person does not have more than one user ID?
6. Who decides the level of access in the application system? In your opinion, is this person the one with the best knowledge to perform this function?
7. Does the Application have a password quality control to ensure the password is alpha numeric preferably with special characters (@#$%^) and does the application control the periodic change of the passwords of all users as per the policy of the Bank?
Server Farm Security and management
Risk defined: Proper server farm management achieves the objective of ensuring only authorised access as well as environment control conducive for the servers and related hardware located in the server farm.
The Risk discussed: The server farm contains the costly hardware of servers and other networking equipment in addition to the priceless data of the account holders of the Bank. Physical protection and ensuring uptime (continuous service) is the crux of management of the server farm. This section therefore contains the relevant points in this regard.
Illustrative Checklist points for Server Farm Security Management:
Since authorized physical access is covered in the earlier points, protection to the servers other than unauthorized access is covered here.
1. Is the server room constructed with the right materials? Fireproof material is what the RBI Committee Report on Computer Audit recommends. (The para nos of the Report are mentioned in the box alongside)
2. Is the temperature and humidity controlled to the specifications of the hardware vendor? If exceeded, then the hardware may not last its average life span and even endanger the continuity of service.
3. Is a Heat Rise detector (found absent in most installations) and Smoke Alarm system installed in the Server Room of the Data Centre?
4. Is the Fire Extinguisher of outside the server room of sufficient size and composed of Carbon Dioxide? (Remember the foam type is not of use here as it corrodes the circuits whenever used)
Risk of Correctness
Computing Management Security
Risk defined: Computers are mere tools. They have to be managed well otherwise there is risk of data mismanagement, wrong processing or even total loss of data.
The Risk discussed: This point deals with the ‘process or methodology’ adopted by the Bank for proper use of the system. Such points are ‘around’ the computer which determines the success of execution of the system.
Illustrative Checklist points
1. What is the system of ensuring there is periodic check on the interest calculation levied and charged by the Bank? Often it is found that the Data Centre believes the Branch is in a better position to do this check while the Branches believe that since the interest ‘run’ is performed by the DC, it is their responsibility of test check.
2. Whenever interest rates are changed or new products introduced, is it tested in the test server and are the results recorded and stored and released to the production server only after proper satisfaction of the intended results? It is not uncommon to find last minute announcements precluding the IT Department from doing any testing since the new products are to be released within 12 hours. Such non testing is highly risky.
3. Is the ‘Version change’ from the vendor claiming to have solved all problems of the Bank needs tested in detail before installation on the production server?
4. Is there a system for detection of security intrusion? And if so, what is the escalation policy? (Escalation policy is to evaluate the degree of the problem and accordingly the next senior person is to be updated – sometimes the more serious problem requires by-passing the immediate senior)
Change and Problem Management
Risk defined: ‘Change’ of a passage of time ensures the Bank is with the demand of the present but the absence of which spells as a risk of being outdated.
The Risk discussed: Since most Banks purchase readymade software application, there is every possibility that over a period of time there might be some changes which the Bank desires which is currently not available in the delivered application. The reasons may be various, ranging from new service (like ATM) or a change in regulations. Though the aspect of change in regulations is admitted to be covered by the vendor in the AMC, the change management policy needs to be developed if not already done.
Illustrative Checklist points
1. Is there a change management policy is place? Absence of change management policy, the environment of the Bank is non conducive to observation of shortcomings and may be running a high risk and even revenue losses.
2. Is the Application software needs encoded and not in a position where the program lines can be changed?
3. Has the Bank conducted Software Audit before installation? Has such an exercise resulted in a ‘GAP’ Report where the Bank’s requirements are not available as per the Bank’s policy?
4. Are the serious incidents of Application software logged and action taken with the vendor after investigation on setting/parameter confirmation?
Conclusion
Core Banking system audit cannot be ignored because of the new role it plays in the aspect of Correctness, Confidentiality and Continuity in the Bank. However, the issues to check the mitigation of such risks are not too technical for the auditor to verify.
![BES’s Institute of Management Studies and Research [besimsr]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tuSl2jk9LTqfbzQDkfFrVpwublM5J0Bar_n3Xc2_dG_MKmzPFcmmb3Duq5rwcRAeYBelieW86SDiU1N5iL_2zstSiveCiANVvl8pTynHuB1W7G2P_q_XV82mQ3WKJ6ED7L0bHyMUg8yIS9ZUKMWNqS0wccyD-FHt_wjrZI5CPX274J6f62UjES5eLVRiOeTOefyB9XZOKhDubYvP8cEA=s0-d)
