The latest frontier in banks' efforts to defend their mobile and online banking software from phishers, hackers and other types of cybercriminals is to build security into the development and testing of the applications themselves.
A group of bank technologists at BITS, the technology division of the Financial Services Roundtable, has created a Software Assurance Framework that provides guidance to developers on how to write more secure code. In the past, this group has focused its security work on operations and network-based defenses against intrusions by hackers and malware. (Members come from many financial services companies including Bank of America, BNY Mellon, Capital One, JPMorgan Chase, PNC, Key Bank, PayPal and SunTrust as well as Microsoft.)
"Business as usual is not good enough, and a lot of the things that have been tried up to this point have been an expensive game of whack a mole," says David Ladd, principal group program manager, trustworthy computing, at Microsoft, and one of the writers of the framework. "A lot of application developers are not tasked with thinking about security up front, then they get into a situation where a system gets hacked and hundreds of thousands of people's personally identifiable information gets sold to the highest bidder and all sorts of pandemonium happens as a result. A number of customers are no longer satisfied with trying to throw up a firewall and antivirus and call it a day."
Sloppily written online and mobile banking applications are subject to a number of types of attack. In SQL injections, fraudsters insert SQL statements in a web form to get a poorly designed website to perform self-serving operations on the database (often to dump the database content to the attacker). In cross-site scripting, attackers inject client-side script into web pages that let them bypass access controls.
The framework strives to outline prescriptive secure development practices. "You have to make sure that when software applications are being written, they're being designed, written and tested with security in mind," Ladd says. Many developers unwittingly have unclean practices due to a simple lack of training, he adds.
To fight phishing, for instance, programmers need to consider the possibility of such attacks from the get-go, Ladd says. "When a bank wants a new app, usually someone will come up with a list of features they want to see," he says. "Often they fail to consider what dangers are in the operational environment before they come up with the list of requirements. An app developer could do something in the requirements or design phase that specifically calls out the types of security issues that the app needs to be resilient against. If you assume there will be people out there trying to compromise these apps and you build that into your design, you're in a much better position to expect or hope that the result with withstand threats."
One good development practice addressed in the framework is threat modeling, in which software architects, developers, project managers and testers get together and think through how they want an application to perform and what threats it might be exposed to.
Another best practice is attack surface analysis, in which the code that can be run by unauthenticated users is analyzed for vulnerabilities.
In Ladd's experience, hackers typically try to test several different paths of attack to access a database of personally identifiable information. "Usually they have to poke around the edges a bit and look for different vulnerabilities, errors or configuration problems, and use each of those as a means by which to get a little farther toward their ultimate goal," he says. "You're going to find a trampolining from one vulnerability to another to another until they finally get to the point where they have adequate permissions or they've got access to the thing they want to take down."
Some of the advice in the new framework is based on guidelines that already exist at software companies such as Microsoft, Adobe and Cisco.