What if dozens (even hundreds) of banks all used one vendor's solution to provide online banking services?
What if that solution had a security flaw thus affecting all users of said solution? A finding of considerable concern, yes?
I must preface this discussion with the fact that the vendor in question has proven to be trustworthy, capable, reputable, responsible, and responsive.
Precision Computer Systems, a FISERV company, provides outsourced online banking solutions to a plethora of banks.
My desire to discuss the vulnerability with Precision Computer Systems (PCS) was forwarded to FISERV for consideration, and the reply came directly from the Vice President | Head of Security.
"As you might imagine, no higher priority exists for our organization than the protection of our client’s information, and that of their customers. To that end, we’ll always welcome constructive feedback such as yours with enthusiasm."
As responses to reported vulnerabilities go, PCS/FISERV handled the process in ideal fashion and are to be applauded for doing so.
While flaws in web applications are a dime a dozen, and nearly every web app yields a vulnerability at some point, the more important piece is how the vendor responds when said vulnerability is disclosed to them.
For this software as as service (SAAS) offering, while each bank's web site is unique, when the user decides to login to the Online Banking service, they're redirected to https://ibank.pcs-sd.net/onlinebanking8/login.r?t-bank=bank id.
Thus, all banks utilizing PCS for this particular feature all take advantage of this specific application to handle logins, amongst other things.
The login form, in particular, suffered from a cross-site scripting (XSS) vulnerability; as discussed in earlier posts, the potential risks to consumers are obvious.
This graphic has specific bank information redacted, and the specifics of the vulnerability are unnecessary. My preference is to treat this discussion as a learning opportunity, rather than nitpick needlessly.
At the risk of overstating the point, the one flawed variable affected all PCS customers utilizing the service.
Again, PCS/FISERV, as indicated above, handled this vulnerability quickly and admirably; they immediately assigned a PM and development resources to repair and release a fix to production.
The lessons here are many.
1) Other online finance vendors, particularly those falling in the SAAS category, take note: this is how to respond to reported vulnerabilities.
2) SAAS customers, take note: ensure that the vendor you contract with for service is very clear about their secure development practices. Don't be afraid to ask very pointed questions such as:
"How quickly will you respond if a vulnerability is disclosed to you?"
"Do you employ a Secure Development Lifecycle standard?"
"How often, and by whom, is the security posture of your product reviewed, preferably with the appropriate compliance frameworks (PCI, SOX) in mind as well as the given web application security standards (input validation, sanitize output, etc.)?"
3) Customers and vendors alike: trust no trustmark (security badge) provider to actually provide you any actual security value...conversions yes, security not so much. At least one bank on the PCS customer list utilize the likes of Control Scan. You'd think Control Scan might have found or reported this vulnerability to the bank or PCS, yes? I think not. SSL-related trustmarks are also nice but no encryption in the world will help you under these circumstances.
The responsibility bestowed upon SAAS providers is of a magnitude at least similar to that of typical application product providers, if not more.
Where a single "boxed" product falls under the scrutiny of vulnerability managers such as CVE and OSVDB, no such scrutiny exists for SAAS offerings.
As more enterprises take advantage of SAAS and cloud-based offerings, they do so for obvious cost and efficiency reasons, but may not have assessed the changing dynamic of their risk posture.
As we consider the premise of one flaw to rule them all, vendor response will be paramount. May the PCS/FISERV standard become commonplace.
del.icio.us | digg | Submit to Slashdot
1 comment:
@Russ - well done. I have had occasion to meet [in a professional capacity] some of the heads of security at Fiserv - great group of talented folks.
Sadly, as you know to every good there is a bad... and one perfect example is the less-than-intelligent folks that created a piece of banking software that a previous company of mine purchased. "iFlex Flexcube" I believe was the name of the product and it was hilariously bad. What is even more alarming is that when I reported these issues to them they claimed it would take >1yr to fix them in accordance with their stringent release cycles (laughable) and then proceeded to tell me that the vulns weren't really a big deal because "hundreds of European banks" had already used their software and weren't seeing any issues.
*sigh*
Post a Comment