Information Technology Risk Management

Assessing Application Security Risk Assessment

Earlier this month, the Comptroller of the Currency issued a bulletin (OCC 2008-16) outlining the importance of application security in an institution's Information Security program. For the folks who have been in the banking industry and are responsible for information security at their institutions, there was nothing new in this bulletin. Still, it does what it was designed to do - remind banking institutions to not forget application security, irrespective of whether an application was designed in-house, purchased from a third-party and managed by the institution internally or simply contracted by the institution and operated on its behalf by a Third-Party Service Provider (TSP). The bulletin recognizes the widely accepted practice of banks relying upon their vendors to provide secure applications. But it clearly states - "However, bank management remains responsible for ensuring that the application meets the bank's security requirements at acquisition and thereafter."

Reading this bulletin got me thinking as to how much efforts and resources do banks invest in evaluating third-party applications. For the sake of this discussion, let's narrow this down to an institution's core-banking application(s). While we are at it, let's add some of the Internet-enabled banking applications, such as the bank's Internet Banking systems. I picked these two unique categories of applications because a compromise in either one of these applications can have a devastating impact on an institution and it's relatively easy to envision this impact.

Now, this hypothetical compromise can be due to a breach in integrity (e.g., matching figures at the end of the day is no guarantee that for every fraudulent debit entry there isn't corresponding fraudulent credit entry); confidentiality (e.g., why does everyone at the institution know that a celebrity has an account with the institution and has received a significant 'sign-on' bonus to work on a entertainment project); or availability (e.g., un-availability of an institution's Internet Banking system can have an impact on a bank's reputation as well as prohibit a customer from conducting a transaction).

Even though expectations from the banking regulatory agencies have been communicated via several bulletins, guidance and Financial Institution Letters (FILs) in the past, the work in this area from institutions has been sparse. I don't know this for sure, but it sounds like that this could possibly be the reason for the issuance of this bulletin. And it's only fair to expect that some of the issues raised in this bulletin will be seen again in upcoming regulatory exams.

It's no surprise to anyone that a majority of the organizations use a combination of - developing applications in-house and acquiring and integrating third-party applications. The following items stand out to me as a good starting point for any institution to follow for third-party applications -

Does the vendor have an industry-recognized third party who conducts application vulnerability assessments on the application (including security)? If so, obtain the third party's name and determine how often the assessment is conducted, and:

The date of the last time an application vulnerability assessment was conducted for the application;
Whether the vendor is willing to share the results with the bank;
Whether the application has any known open vulnerabilities (including security). If so, is the vendor willing to share the nature of those vulnerabilities with the bank; and
Whether the vendor is willing to share its secure coding processes and practices with the bank.

If you ask yourself these questions and the answers are not satisfactory, you have got work cut out for you.

Your thoughts?



About the Author




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.eu, you agree to our use of cookies.