Much attention has been focused on the major areas of emphasis in the FFIEC Supplement to Authentication in an Internet Banking Environment (the Supplement) released June 28, 2011. Any analysis of the threats associated with Internet banking must necessarily begin with a risk assessment. Your risk assessments frequently reveal your controls need to be strengthened. The Supplement addresses in detail weaknesses which have developed in many Internet banking technical controls due to the persistence and creativity of fraudsters. A third area of emphasis, customer awareness and education, has led (or is leading) to a strengthening in customer education initiatives. However, an area with serious information security implications may have slipped under your radar for years.
Broader Ramifications?
Back in October 2005, the FFIEC released Authentication in an Internet Banking Environment. This guidance defined "high-risk transactions" as "involving access to customer information or the movement of funds to other parties." Although this guidance, an update released the following August and the 2011 Supplement above have been generally applied exclusively to Internet banking solutions, the definition of "high-risk transactions" may have implications outside of your Internet banking implementation.
Software Metamorphosis
Only a few years ago, virtually all software used by banks was client-based software or external point-to-point connections via leased data lines. In either case, someone, generally in your IT department, had to install the necessary software on each workstation where the particular software was to be used and set up a user account. Under this system, while it was important to terminate the accounts of former employees, they could not access the systems without physical access to the software on a computer inside the bank.
Financial institutions now utilize a wide range of services via the Internet—services like ordering checks, obtaining and verifying consumer information (credit reports), sending and receiving ACH transactions, sending and receiving wire transfers, and remote deposit capture. As these services become web-based, IT may not be involved…or even aware…of the software being utilized in the bank and may not have access to the user list.
So What?
If the repercussions are not already obvious, maybe the following story will paint a vivid picture. In September 2011, hackers compromised an employee account at the former Abilene Telco Federal Credit Union, now First Priority Credit Union. The institution's branch manager reportedly told Bloomberg News in late October that hackers broke into an employee's computer and accessed login credentials to the credit union's online account with Experian, the credit reporting organization. Experian confirmed the breach and said the incident wound up exposing personally identifiable information of about 702 Experian users, including Social Security numbers, dates of birth and financial data.
While this incident involved compromising the credentials of a current employee of the financial institution, are not the implications just as dire if a former employee of the bank accessed customer information using their own credentials which were never deleted when they left the bank's employ? What if account credentials are shared, that is, what if the bank uses a "generic" username and password that everyone using this particular application shares (rather than each user having their own account)? Attempting to establish who did what might be a challenge forensically, based on the muddy access logs. If the former employee was disgruntled and had malicious intentions (rather than just being curious), the damage to the bank's reputation could be irreparable.
What Should We Do
Conduct a survey of all departments to identify all web-based applications. Thereafter:
- Perform a risk assessment to evaluate all web-based applications. A simple risk assessment should:
- Determine if the applications are high-risk (i.e. access to customer or consumer nonpublic information and/or the transfer of funds to other parties).
- Evaluate the authentication requirements (username, password, token, biometric, password complexity, digital certificates, etc.).
- Evaluate additional application security controls (e.g., IP address controls, time of day controls, transaction amount limits, batch amount limits, transaction authentication, out-of-band authentication, etc.).
- Determine if the bank has enabled any of the additional application security controls. Implement additional application security controls, as appropriate.
- Include a report of findings to the IT oversight committee.
- Require all departments to obtain approval from the IT oversight committee prior to the implementation of any additional web-based applications.
- Integrate the granting and revocation of access to all web-based applications into formal hire/termination procedures, including the resetting of passwords for shared account credentials.