Most banks have been through multiple examination and audit cycles since the much anticipated and discussed FFIEC Supplement to Authentication in an Internet Banking Environment (the Supplement) released June 28, 2011 (http://www.ffiec.gov/pdf/Auth-ITS-Final 6-22-11 (FFIEC Formated).pdf). Significant attention has been focused on three major areas. Initial examinations focused on Internet banking-specific risk assessment(s) to identify threats particular to Internet banking. These risk assessments likely revealed your controls needed to be strengthened. As the Supplement addressed in detail, weaknesses have developed in many traditional Internet banking technical controls due to the persistence and creativity of fraudsters. The third area of emphasis, customer awareness and education, has probably led to an expansion of your customer education initiatives. However, an area with serious information security implications may have slipped under your radar for years.
Ramifications Beyond Internet Banking?
Back in October 2005, the FFIEC released Authentication in an Internet Banking Environment (http://www.ffiec.gov/pdf/authentication_guidance.pdf.) This guidance defined "high-risk transactions" as those "involving access to customer information or the movement of funds to other parties." Although this guidance, an update released in August 2006 (http://www.ffiec.gov/pdf/authentication_faq.pdf) and the 2011 Supplement above have been generally applied exclusively to Internet banking solutions, the definition of "high-risk transactions" has implications beyond your Internet banking implementation.
Background: Software Metamorphosis
Only a few years ago, virtually all bank applications were client-based or used 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 and then set up a user account. While it was important to terminate the accounts of former employees, they could not continue to access the applications without physical access to a computer inside the bank.
Banks now utilize a wide range of services via the Internet—services like check ordering, obtaining and verifying consumer information (credit reports), sending and receiving ACH and/or wire transactions, remote deposit capture, managing ATMs, etc. As more of these services become web-based, IT may not be involved…or even aware…of the applications 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. (http://www.bankinfosecurity.com/fraudsters-target-bank-employees-a-5269/op-1).
This incident involved compromising the credentials of a current employee of the bank. However, the implications would be just as dire should a former bank employee access customer information using their unrevoked credentials. And, what if account credentials are shared, that is, a "generic" username and password shared by multiple employees is used (rather than each employee having their own account)? Attempting to establish forensically who-did-what might be a challenge, or even impossible, based on muddy access logs. Whether the former employee is disgruntled and has malicious intentions or is simply curious, the damage to the bank's reputation may be irreparable.
Now What?
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 current and available authentication controls (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 and initiate the implementation of 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 new 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.