Financial technology (fintech) applications such as internet/mobile banking and electronic payment applications has disrupted the traditional "brick and mortar" banking that we all have been accustomed to over the years. The introduction of internet banking (a.k.a. online banking) and mobile banking brought about easy and convenient access to banking services and solutions that would have required users to be physically present in the banking halls. Some of the services that can be accessed via internet/mobile Banking apps are self account to account funds transfer, funds transfer to accounts within the same bank (intrabank transfer), funds transfer between accounts in two different banks (interbank transfer), Account Balance inquiry, Bills and utility Payment (e.g. electricity/energy bills, water bills, cable tv bills, govt tax payment, etc.), airtime and data subscription recharge, international funds transfer via SWIFT platform, cheque/check book requisition, ATM/debit card requisition, ATM/debit PIN issuance and reset, credit card requisition and PIN reset, hard/soft token (2nd factor authentication) request and reset, loan facility request and disbursement, among other services. Accessing these services via internet/mobile banking apps or other electronic payment applications is critical to maintaining strong customer base, market share and customer satisfaction, which is central to the sustainability of any banking business. Also, with the proliferation of Fintech firms with cutting edge solutions, the distinguishing factor will be how faster, convenient and reliable is the digital service channel as well as the competitiveness of transaction fees.
Would you imagine a situation where these applications/solutions are not available/accessible to customers who need them and what will become of banking services of today. Of course, one cannot imagine how terrible banking service would be and how crowded most banking halls will be. There is no doubt that internet/mobile banking platforms deployed by financial institutions and Fintech companies have led to the decongestion of banking halls and have revolutionized banking services globally. From the comfort of their homes, offices or on the go, customers can access banking services and do their transactions without having any interface with their brick and mortar banks. While this solutions provided a lot of convenience and flexibility to customers, it also presents enormous security and privacy risk both to the financial institutions and their customers, which if not checked could lead to loss of funds (both to banks and customers) through fraud, customer data breaches, reputational/brand damage, among others. The greatest risk posed to internet/mobile banking and other e-payment applications are the risk of confidentiality, integrity and availability (CIA). Because the solutions are access through the internet and mobile phones, they could easily be compromised by hackers with malicious intentions where the solutions are not hardened with appropriate security controls and measures. Therefore, it is important that the solutions are reviewed/audited in line with the organization's information security policies, best practice standards and applicable regulatory requirements to forestall any compromise and protect both the bank and their customers from financial losses and data leakages.
To ensure a successful audit of internet/mobile banking app as well as other electronic payment applications, the audit team must understand the business environment in which they operating in and the prevailing conditions such as regulatory requirements, business requirements and stakeholders'needs. The audit team need to put together a robust Internet/Mobile Banking & Electronic Payment Application Audit Program to effectively identify risk inherent in the solution, existing controls that are mitigating the risk and their adequacy and procedures to test the controls to ascertain their effectiveness in mitigating identified risks. The audit program also highlights the objectives and scope of the audit based on initial assessments. Where controls are inadequate, the residual risk are identified and communicated to management for action. New and emerging risk can also be identified during the audit and form part of the audit findings, which will eventually feed into the risk register of the organization to enable tracking of the risk. Highlighted below are some of the areas of the internet/mobile banking applications and supporting IT infrastructure that should be reviewed to confirm the adequacy of controls to mitigate risk and ensure security of internet/mobile banking applications in addition to things to look out for in the course of auditing.
1. Application Security Review:
Here, the application controls are reviewed in line with business rules set through organization's information security policies, standard operating procedures and regulatory requirements to drive transactions and other services rendered through the application. Such business rules are not limited to risk-based transaction limits/thresholds (daily, weekly or monthly limits) for individual, corporates, MSMEs, etc. Other controls include authentication/authorization controls such as password security controls (Alphanumeric, special characters, length, ageing and complexity requirements), security questions and answers, geo tagging control, multti-factor authentication (MFAs such as One time passwords, tokens). The functional requirement of the application are validated during the audit to confirm that the application is fit for purpose and meeting the need of stakeholders (e.g., customers, investors, shareholders, suppliers, etc.). Revenue assurance review are also performed to confirm that all applicable transaction fees, interest charges and loan repayment deductions setup are working as expected to forestall instance of underpayment by customers or overpayment to the institutions. Given that applications such as internet/mobile banking Apps are not standalone systems but are usually integrated with the core banking/business solution of the financial institution or payment provider, the interface through which the Internet/Mobile Banking application is integrated with core banking/business application should be reviewed to ensure that it complies with security standard/leading practice for Web Service/Application Programmable Interface (API) such as Open Web Application Security Project (OWASP) top 10 API controls. In addition to the OWASP security standards, the Audit team should also ensure that valid digital certificate(s) signed by appropriate Certificate Authority (CA) are deployed on the web client interface of the Internet/Mobile Banking and other electronic payment applications for end-to-end encryption of transactions and communication/data exchange at all levels of the application. For detail Application Securtiy Audit Program, click here.
You will find detailed audit test procedures for the review of Oracle (8i, 9i, 10g, 11g, & 12c), Microsoft SQL Server and MySQL databases here. 2. Database Security Review:
Here, the database controls are reviewed in line with the approved database security configuration baseline of the database management system (DBMS) in use. For detailed test procedure for database security audit for Oracle, Microsoft SQL (MSSQL), and MySQL databases, Download Our Database Security Audit programs, which will show you in details how you can review the above mentioned databases used for Internet/Mobile Banking & other electronic payment application. The following general database controls should be considered:
3. Operating System (OS) Security Review:
Here, the Internet/Mobile Banking & Other electronic payment Application Servers are reviewed in line with the adopted security configuration baseline of the organization or at least the System Software Vendors' security baseline (e.g. Microsoft Windows, IBM AIX-UNIX, Oracle UX, etc.). Depending on the architecture of the application, the Internet/Mobile Banking app could have its web servers (e.g. IIS, Apache or TomCat), Application Servers and Database Server physically and logically separated from each other to ensure security and prevent single point of failure. Depending on the Operating system version or platform that the application is running on, applicable security baseline requirements for Windows, LINUX or UNIX (AIX/SOLARIS/HP) servers can be used to review the adequacy of security of the different server OS. For audit program/security review checklists of the most popular Operating System platforms, see below.
4. Network Security Architecture Review:
To ensure the security of the application data and to separate user interface traffic from the rest of the backend systems, the web server where the client/web interface application is hosted in the Demilitarized zone (DMZ), a segment of the organization's network where internet traffic are available but filtered to specific systems, applications and service ports to restrict access. The DMZ segment usually host systems/servers/applications that are internet facing but with backend systems that reside within the organization's network. The DMZ segment is separated from the internet using the organization's Internet Firewall (also known as Frontend Firewall). While the DMZ segment is the inside of the internet firewall with security level of say 50, the outside segment of the internet firewall, which is the internet has security level of 0. Internet/Mobile Banking users who are typically on the internet can reach the client/web application residing on the web server in the DMZ segment of the network. Their requests are then routed to the application and database servers inside the organization's server farm or server V-LANs in the Data Center through connectivity established between the web server and the application/database servers. Typically, the server farm V-LAN are behind a backend firewall with security level at 100% or higher. The reason for this type of architecture is to ensure that attackers are not able to reach the application and database servers in the local segment of the network, typically the server farm V-LAN even if they are able to compromise or reach the web server hosting the client/web application. This layered architecture or approach to security ensures the security of the entire system end-to-end, contrary of which could expose the application to data breach or attacks that could lead to financial or data losses. For detailed audit program/checklists for network and perimeter security review, click here.
5. Logical Access Controls Review:
Review of users' access who carry out admin and support functions on the Internet/Mobile Banking or other electronic payment application(s) and databases to ensure that such access are still valid and relevant for their job functions. All disengaged staff of the organization who perform admin or support functions on the Internet/Mobile Banking or other electronic payment should be disabled/deactivated on the application to prevent their credentials from being used for unauthorized access into the system. Also, support staff members who are on vacation/leave or re-assignment/redeployment to other functions should be disabled from the application. A procedure for access review should be put in place to ensure regular review of users' access on the application and invalid access are promptly deleted/deactivated to prevent unauthorized access. Also access logs or audit trails such as, login audit trail (successful/failed/attempted), logout audit trail, activity audit trail should be captured to aid in the investigation of security breaches in the application when the need arise. Also, IP addresses or hostnames from where users and other support personnel (administrators) access the application from should be captured in the audit trail.
6. Password Security Review:
Password parameters selected for the application should be secure and conform to the organization's adopted password psecurity olicy. Password requirements such as, password length (e.g. minimum of 8 characters), alphanumeric and special character, complexity requirement, password reuse, ageing and lockout controls should be implemented as appropriate. This is to ensure that users are made to conform to the organization's password policy while selecting password to guarantee strong passwords.
7. Data Integrity:
The development, test and live environments of the Internet.Mobile Banking application must be logically separated and this can be achieved by installed the different environment using different/unique static IP addresses. This is to prevent compromise and ensure segregation of duties among the operations/support and development teams. Application support function should be separated from development and database adminsitration functions to prevent conflict of interest. Also, user access management function should not be handled by the operations/support team. Live data should not be used as test data in the test environment without obfuscation or concealment to prevent data leaks in the test environment since test environment are known to be accessible to vendors and third party employees and security is not always emphasized on the test environment. Confidential customer information such as debit or credit card data (e.g. PAN, PIN offset, expiry date & CVV) and other confidential customer data and personal identifiable information should be encrypted in the database where they are stored as well as while in transit in line with PCIDSS requirements.
8. Redundancy:
The architecture to be adopted for Internet/Mobile Banking or electronic payment application should be such that will ensure high availability for the application. Due to high volume of transactions witnessed on Internet/Mobile Banking application, the architecture should encourage high processing capacity by building adequate redundancies into the application. To be able to handle high volume of requests/transactions from online users, the web server should be load balanced among for instance 3 to 4 servers connected in mesh topology. Virtual servers can be used for this purpose as well. Mesh load balancing architecture is where each of the servers are interconnected for even distribution of traffic or load on the application in a manner that unavailability of any of the servers will not bring about downtime of the application services and as such, would not be noticed by application users. Same goes for the application server, which should be load balanced among for instance 3 to 4 servers (all virtual) connected in mesh topology. The live database can running on two connected databases that are in active-active or active-passive replication mode. For example, both servers are in sync with each other and update themselves in real-time or passively such that at any given point in time, they are holding exactly the same level of data. This architecture will prevent data loss, ensure even distribution of load and high database availability. 9. Business Continuity Management & Disaster Revovery:
Given the importance of the Internet/Mobile Banking and other electronic payment application to the financial institution or FINTECH in delivering financial/payment services to their customers, the application should be part of the institution's business continuity and disaster recovery plan. As such, the application should be recoverable in the institution's disaster recovery (DR) site (hold, warm or cold). Hence, the application's infrastructures (servers) should be available at the DR site and an active replication established between the main processing facility and the DR site. The application should also be scheduled for simulation testing as part of the institution's disaster recoverability testing plan where critical services, solutions and applications identified in the business impact analysis (BIA) assessment of the institution are periodically tested to ensure their recoverability in the event of disaster or service disruption at the primary processing facility. Evidence of such recoverability test should be requested and reviewed by the audit team for their adequacy. Lessons drawn from such test must be captured, internalized and used as a basis to improve on future tests while reports are sent to management accordingly. A disaster recovery procedure/plan should be developed for the Internet/Mobile Banking & payment application and circulated among stakeholders for use during emergency.
Nwabueze Ohia
(Tech Blogger, Cybersecurity Expert and Author)
Will appreciate your questions and contributions on this post. For sponsorship, ad placement, speaking opportunity and training bookings, please Contact US or Send us an email at info@oxleyconsults.com.ng.