about fortify Software

The Evolution of Application Security in Online Banking

What Chief SeCurity OffiCer and SOftWare SeCurity prOfeSSiOnalS Can learn frOm Online banking
The economics of hacking are quite simple: Spend a little time breaking into a system and poof youre off to the Caribbean. On the flip side, security professionals put defenses in place to force adversaries to spend a lot of time undergoing unnatural contortions while attacking. Why? With strong defences, the hackers economic model, suddenly, looks most uneconomical. The result? Most hackers will seek out easier targets. And this illustrates the economics of securing online banking, which is best explained with an analogy: If you encounter a bear in the woods while hiking, you dont need to run faster than the bear. Just run faster than your fellow hikers. Moving online has been a crucial business initiative for banks, large and small, from the very beginning of the mass Internet adoption by consumers. As one senior banking executive commented, The firm used to be a bank that used technology. Today its a technology company that offers banking services. 1 In 2005, The New York Times profiled online banking initiatives, describing the rapid move to provide online services to customers spurred by recognition within the industry that Internet customers are more profitable than the unwired masses. Analysts said the cost per transaction is considerably lower for online banking than offline, but more important for financial institutions is that those who bank online are simply more desirable customers. 2 According to one online banking report,3 the transaction costs of the various banking channels are: Branch Call Center Automated Response System Automated Teller Machine Dialup PC Banking Internet Banking $1.07 $0.85 $0.44 $0.27 $0.015 $0.01

Today, security teams at 9 of the 0 largest banks in the US use Fortify. In fact, the code that touches nearly 67 percent of the deposits held in the US has been analyzed by Fortify. Along the way, weve learned some things about how the financial services industry approaches software security.

The message for retail banks: Move online or perish. The US is not the only place to see fast growth in online banking. For example, in the UK, online banking has grown 50 percent since 2005.4 In addition, over half of people surveyed (57 percent) said they used Internet banking more often this year than last, with just one in ten (11 percent) stating that they never manage their money online.5 In Finland, only 10 to 15 percent of all banking transactions are now done over-the-counter.6 The business drivers for online banking are absolutely clear, but they do not come without significant risk. If a consumer can access banking systems from the comfort of their own home, then a pathway to the core infrastructure and priceless data exists for hackers as well. However, the banking industry accepted the challenge and, for the most part, has succeeded where many others have failed. Through the effective use of network and application security, online banking has fended off an enormous onslaught of attacks mounted against their systems every day.
1 2

The potential gain from even one successful computer intrusion makes [hacking] an attractive, relatively low-risk option and the risk to sensitive information on US computer systems will increase.
US Defence Security Service, 2007

4 5

2007 Dilbert. Scott Adams

Fortify Software customer interview with a top five US-based online bank. http://select.nytimes.com/search/restricted/article?res=F70C14FC35590C 748CDDAA0894DD404482 http://www.arraydev.com/commerce/jibc/2007-04/AbdullahFinal_PDF version.pdf http://www.virsulist.com/en/news?id=208274029 http://www.financedaily.co.uk/News/ConfidenceinOnlineBankingGrows_ 264.html http://www.valt.helsinki.fi/comm/argo/anet00/Nicola1.htm

2300 GENG ROAD, SUITE 02 PALO ALTO, CA 94303 O 650 23 5600 f 650 843 424 WWW.fOrtifySOftWare.COM

The evolution of online banking serves as a model for software development teams in organizations within the industry and across any others insurance, transportation, healthcare, etc. In size, complexity and risk, online banks have the strongest security software needs. The adversaries attacking the bank include organized crime, hacking groups organized by foreign governments and cyber warfare groups within foreign governments. By studying best practices of online banking security, many organizations can learn lessons on improving the effectiveness of development and testing to improve software security levels. Outrunning the bears Today, most large US retail banks are doing an exemplary job of securing their online banking applications at the network level. While online banks have done all they can to erect defences with fire walls, anti-virus software and the like, the software inside these perimeter defences is vulnerable and thats what hackers target now. The real security challenge for online banks is at the application level, leveraging advanced security technology and improved software development processes. Strong evidence exists that online banking security teams have been successful in securing their applications: Strong user growth Online banking in the US grew to 44 million consumers in 2006. In fact, the total online banking customers at the top 10 online banks still surpasses overall Internet population growth.7 And this growth is taking place in an industry where consumer security sensitivity is very high. A 2006 study by the Ponemon Institute showed that 34 percent of customers would change their bank after one breach, and 45 percent would leave after two breaches.8 less hacking A 2006 Gartner survey showed only 8 percent of banks reported external hacks against their systems.9 By contrast, according to the Web Application Security Forum, 2006 was the worst year for Web application hacking in history. Stronger consumer perception US consumer perception of online banking security has improved. In a recent survey of consumers, 68 percent of respondents believe that their financial institutions Websites are more secure.10 new forms of attack required Since direct hacks against banking systems became very difficult, cyber criminals resorted to phishing consumers with dubious emails. Today, 60 percent of banks report suffering from phishing attacks.11 Indeed, the number of phishing attacks has soared more than 800 percent in the past year, and hit a record figure of 1,484 last month.12 While phishing schemes are a major problem today, they pale in comparison to the potential impact of the breach of core systems. If the banking infrastructure or software applications are compromised, then every account is compromised. Phishing, conversely, forces the adversary to follow the slow, painful process of compromising accounts one at a time. Today, most large retail banks are doing an exceptional job of securing their online banking systems at both the network and the application level through advanced security technology and improved software development processes. Weaker banks targeted Gartner reports that the majority of hacking attempts were targeted against smaller banks with less effective application defences, likely due to having few resources to devote to application security.13 The same report indicates that phishing attacks also disproportionately target smaller banks, as large banks tend to have more security resources.14

7 8 9 10 11 12 13 14

Ibid. http://www.csoonline.com/caveat/022707.html FFIEC Guidance Drives Online US Banking Security Upgrades, Gartner Research, January 2007. Comscore Networks, The State of Online Banking, April 2007. Ibid. http://www.itpro.co.uk/news/94589/consumers-not-playing-safe-when-banking-online.html?searchString=online+banking FFIEC Guidance Drives Online US Banking Security Upgrades, Gartner Research, January 2007. http://www.financedaily.co.uk/News/Online

technical background: Code and Vulnerabilities Supporting consumer needs for financial transactions requires a complex, time-consuming software development cycle. Typically, online applications often have quarterly release cycles. The bulk of the application updates focus on bug fixes, while new functionality is added about twice per year. The quarterly cycles typically devote two months to development with one month dedicated to testing and certification. As with the majority of enterprise systems today, online banking applications are typically built with Java or .NET and database languages like PLSQL (Oracle) and TSQL (MS SQL Server). Online banking has grown beyond simple consumer banking into investment management services e.g., 401(k)s, mortgages, auto loans and much more. Application sizes are often very large, with online banking applications easily exceeding 10 million lines of code. With several applications, the full portfolio of online applications can easily exceed several hundred applications totaling more than 50 million lines of code. Defending against hackers remains a top priority. The most common attacks hackers use are: 1. Cross-site scripting (XSS) This is the most common means of cyber attack against banks for a simple reason: Its the biggest avenue for phishing. There are a number of actions that an attacker can perform once they successfully execute an XSS vulnerability, including: Get password information with phony error page Transfer money Delete or modify data Essentially, any function that can be performed by a Web page script can be executed by a successful attacker without the innocent consumers knowledge. 2. SQl injection Financial accounts are complex, often relying heavily on numerous Web forms for input or query fields. Using SQL injection attacks, hackers leverage the numerous query and input fields to insert SQL code designed to trick systems into providing sensitive data, such as account numbers. In fact, SQL injections are the most common way to gain access to databases with credit card numbers, PINs or Social Security numbers. 3. privilege escalation This type of attack falls into two categories: - Vertical A hacker becomes an admin to add/delete users and transfers funds. - Horizontal A hacker gets a hold of someones access information. These are especially pernicious, since banks cannot easily identify when this takes place, as banks often dont know a specific consumers usage patterns. This is not an exhaustive list. Banks often have dozens more vulnerability categories on their radar screens that correspond with the OWASP vulnerability ranking. the evolution of the Software development life Cycle (SdlC) As with any new capability, the securing of complex software systems like an online bank requires significant effort and work. An organization will not achieve these goals overnight. Most online banks transitioned through several stages as they progressed toward the skills they possess today. For security professionals in any industry, this evolution can be a valuable benchmark.

By studying best practices of online banking security, many organizations can learn lessons on improving the effectiveness of development and testing to improve software security levels.

SDLC Stage : 00 Percent Reactionary

Code Developed Unit Tests Functional Tests Production

In the early days of online banking, many banks had a strong Software Development Lifecycle (SDLC) designed to meet customer specifications. From a functional standpoint, issues around load, user experience and general bugs were effectively addressed. By contrast, security teams were mostly staffed with old school network security people with some application security people plus a few white hat hackers. Overall, security is a very large team, but with nearly everyone focused on network security, the key question was not whether there would be a successful hack, but rather when would a successful hack take place. From a security perspective, the SDLC was: 1) code, 2) get hacked and 3) patch. Consequently, the banks security team lived in a constant state of fear knowing that a successful hack was inevitable. And when it happened, impromptu patch management teams had to spring into action. This also represents the most expensive security strategy vulnerabilities are put into production code on a regular basis. Worse, there is strong risk of: Loss of revenue from system downtime Damage to brand from a serious breach finding its way into the media Unscheduled development time For the banks security team, this means pagers continually buzzing and security teams constantly working to fix vulnerabilities on a reactionary basis. Stage 2: Ethical Hacking/Robo-hacking
Code Developed Unit Tests Functional Tests Pen Test Production

Recognizing there is a problem, the next logical step is to beat hackers at their own game and put in mitigating solutions. Most often, banks employed ethical hackers or manual pen testing to sniff out potential vulnerabilities. Alternatively, some chose to conduct some sort of penetration testing (aka, Black Box testing or Web app scanning) on production code in the hopes of finding vulnerabilities before the hackers did, or simply hiring ethical hackers to do the same. Although essential and critical, banks discovered that pen testing tools had tactical and strategic disadvantages. Tactically, there were two issues: 1. First, since the tests were taking place on production or staging sites, bank security teams had to test cautiously so as not to crash the system. Additionally, security had to coordinate with QA teams testing the application. If the system crashed, releases were jeopardized and delayed with a monetary loss. 2. The second major hurdle for Black Box testing was that it was not very useful for developers due to lack of code-level details. When security presented reports showing several SQL injections, developers would respond, Where is it, exactly? While developers trusted the results, without root cause information, fixing the issue was very difficult. For example, some cross-site scripting issues can result from application-level issues or via an incorrectly configured application server. But which one? Worst case, developers incorrectly guessed the root cause and implemented a patch in the wrong place, leaving a critical vulnerability unfixed. Strategically, pen testing proved to be an essential security practice; it didnt offer a clear indication of risk exposure. Banks soon realized that Black Box testing did add value, but it wasnt enough. While Black Box testing was and still is an important component of security testing, banks still could not answer several key questions:
4

 Where exactly is the application broken? How much code coverage am I actually getting? How many areas are truly at risk? Is the application fundamentally more secure? Are we curing the illness or just treating the symptoms? The answer became apparent when bank security teams were still putting out fires on a regular basis and it was clear that nothing much had changed. Stage 3: Code Reviews
Code Developed Unit Tests Code Reviews Functional Tests Pen Test Production

Truly understanding risk exposure required a more detailed understanding of the software, so banks slowly began to incorporate security source code reviews. These were helpful because: 1. They found real vulnerabilities in new and legacy code. 2. By examining real application code that was hacked, the security team could execute a shock and awe campaign showing developers exactly how hackers exploited the very code that the developers wrote. 3. Code reviews increased the security teams credibility, dramatically altering how security teams and developers interacted. Highlighting real or potential exploits gave the bank security team a chance to market themselves and push secure coding responsibility onto development. Eventually, this paved the way to the so-called gate model. For the highest sensitivity online banking applications, if the security team felt the application wasnt secure enough to go live, it didnt. Developers, forced to comply, made the necessary security fixes to meet security requirements. Instead of financial incentives, coding securely became a condition of employment. Although code reviews marked a critical shift in online bankings approach to application security, it was an expensive approach. The key issue: Where to start? Application size and complexity were growing at exponential rates, making thorough analyses impossible. With millions of lines of code and only a dozen or so security auditors, the process couldnt scale. To look at just one application manually could take weeks. A thorough application security strategy required a more rigorous approach. Stage 4: Leverage Source Code Analysis Technology
Code Developed Static Analysis Unit Tests Code Reviews Functional Tests Pen Test Production

To tackle large code bases, online banks turned to static analysis. Very quickly, security teams experienced a number of benefits resulting from static analysis: 1. Faster and more scalable than manual code review code review time was reduced by more than 50 percent, while code coverage increased exponentially. Moreover, security scanning could take place on a regular basis sometimes on a 24-hour basis. 2. Security knowledge was built in with predefined vulnerability definitions and descriptions. 3. Consistent results 4. Non-intrusive from a technical standpoint, static analysis allowed the security team to assemble a separate build infrastructure. Suddenly, security could test applications without interfering with development. 5. Freed human auditors to look for logic errors and other things that couldnt be found automatically.
5

However, a fundamental issue remained: zDevelopers were still writing vulnerabilities. Even though banks were catching them faster, the rate of vulnerability introduction into application code remained constant. Even though a static analysis tool may catch security holes early, if developers continued making the same errors, adopting a static analyzer remained an expensive strategy and didnt make sense. Stage 5: Homo Securus: Implementing a Full-scale Secure Development Lifecycle
Devs Trained Code Developed Static Analysis Unit Tests Code Reviews Pen and Functional Production

about fortify Software

Fortify Software is the global software security market leader. Our products Fortify Source Code Analysis Suite, Fortify Security Tester and Fortify Application Defense offer the most accurate and complete security solutions for results you can trust by protecting companies businesscritical software applications. We provide maximum security throughout the software development lifecycle to drive down costs and risks by automating key processes. Our top security experts and best practices developed within Fortune 00 enterprises and ISVs have enabled us to take a leading role in the security industry. We fortify the software for the largest, most demanding varied code bases, including five of the top six US banks, major infrastructure vendors, government agencies, telecommunications, e-commerce, publishing, insurance, systems integration and information management industries. For more information, visit www.fortifysoftware.com

In this final stage, security within the SDLC was a self-sustaining system. This way, the online banks security team moved on to oversee the security process in a fully proactive manner. The security team: Conducted periodic reviews of key applications on a regular basis. Performed in-depth, detailed analysis of critical projects Was no longer distracted by low-hanging fruit issues such as simple script kitties The best indicator of success: The security team could find zero S1 vulnerabilities in the system. Tactically, they implemented two critical changes to the SDLC: education Banks realized that smart developers produce fewer bugs and, therefore, education was needed. As a result, banks have introduced training focused on securely developing software. Many banks provide live and Web-based secure coding training. These programs alone reduced the number of vulnerabilities in the code by 20 percent. However, over the long run, banks learned not to rely on training alone. Although training can have a positive effect in the short term, but it can lose its effectiveness over time. Many firms have high turnover rates among their developers, while others rely on outside developers who do not receive training. Success is best achieved by an ongoing combination of training and tools. Static analysis technology, deployed at the desktop for unit tests and centrally for system tests, reinforces what developers learned. Combining pen testing with Qa With effective static and code reviews, the total number of vulnerabilities pen testing could find in online banking applications was dramatically reduced. However, pen testing was a vital exercise. By incorporating it into the QA process, pen testing became a final check for production and proved highly effective with configuration-related vulnerabilities.

COnCluSiOn
Since most security for Web applications can be implemented by a system administrator, application developers need not pay attention to the details of securing the application BEA WebLogic Server Security Documentation The quote above illustrates a grim reality: In todays world, leading-edge software development methods offer little or no provision for security. And, the road to Web application security can be difficult to navigate. Where do companies turn for guidance? Large online banks have successfully blazed a trail, creating a model for application security that others can follow. The results have been remarkable: 1. Online banking today is safer than offline banking real-time access to account information means both online banks and their customers have an instant ability to spot fraudulent account activity. 2. Online banks are avoiding negative press fewer vulnerabilities mean fewer exploits, which means fewer published incidents that can damage an organizations reputation. 3. Online banks are touting security as a competitive advantage many banks proudly use security as a way to attract customers.
6

2300 GENG ROAD, SUITE 02 PALO ALTO, CA 94303 O 650 23 5600 f 650 843 424 WWW.fOrtifySOftWare.COM