Why financials must implement Web application security best practices

Can we agree, for the sake of argument, that the financial services sector is a primary target for Internet attackers, and consequently, the one sector that must take a stronger stance with regard to Web application security?

There are simply too many opportunities for criminals to abuse your online offerings and exploit your customers. Yet financial-services firms, like companies in other industries, put themselves at risk by not investing in Web application security best practices. According to the Security Spending Benchmarks Project Report, Web application security makes up less than 10% of overall security spending in 36% of companies. Another 33% don't even know what portion of their security spending is on Web applications. Finance was the largest group represented in the survey.

My research illustrates the industry's lack of attention to Web security. As part of a rec...

RELATED CONTENT Security Architecture Insider Considerations for buying and implementing DLP solutions Best practices to secure wireless networks Weighing the pros and cons of end-to-end encryption and tokenization Multifactor authentication options to secure online banking Security benefits of virtual desktop infrastructures How to secure data backup Too many encryption methods make secure communications difficult How to streamline role-based access control Five considerations for choosing network access control products Fighting fraud: Understanding technology and threats SaaS and Web application security Banks have room to improve Web security The PCI compliance case for source code review Security questions to ask SaaS vendors when outsourcing services SSLstrip hacking tool bypasses SSL to trick users, steal passwords Study of banking malware analyzes underground economy Gartner advises banks to shore up online channels Security on the street with SearchFinancialSecurity.com: Mobile banking Verizon security chief says protect your data first The security risks of Google Notebook Developing a patch management policy for third-party applications Secure software design Companies lagging in PA DSS compliance The PCI compliance case for source code review Software testing within financial firms PA-DSS secures payment applications Inside application assessments: Pen testing vs. code review Static and dynamic code analysis: A key factor for application security success Improve Web application security with threat modeling Finjan: Attackers wild about widgets Adjusting a Web application's ability to cache in, log out

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary NASDAQ  (SearchFinancialSecurity.com) password cracker  (SearchFinancialSecurity.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

ent campaign I call Online Finance Flaws , I've uncovered and reported Web application vulnerabilities in sites operated by American International Group Inc. (AIG), American Express, JP Morgan Chase & Co., Fiserv Inc., Merrill Lynch & Co. Inc., National City Bank, TIAA-CREF, U.S. Bank, and Visa Inc. Most recently, I revealed a flaw in a Citibank Hungary online offering. In addition, there are findings I have not yet disclosed, or was told very specifically that doing so would bring legal challenges.

I must note that in all cases, the above mentioned financial-services providers made swift repairs and were attentive and courteous in their responses to my reports. The single shortcoming in some cases was timely escalation to the appropriate teams for repair.

However, in each case, I was able to perform cross-site scripting or cross-site request forgeries in the context of the vulnerable financial site. See below for an example involving a Spanish-language Visa site succumbing to a cross-site scripting flaw:

Two elements were consistent in most of my findings; typically a "one or the other" scenario:

1. The Web application was developed by a third party, or
2. The Web application was included in an acquisition as part of venture integration.

In all scenarios, two practices would have gone a long way in preventing these issues:

1. Ensuring use of a security development lifecycle (SDL), both in-house, and as a requirement of all third parties conducting work on behalf of the financial providers.
2. Application threat modeling: Determine all possible use case scenarios for the Web application (vision); conduct high level to detailed/granular diagramming sessions of the Web application's data flow (model/diagram); determine all entry points and trust boundaries by thinking like an attacker (identify threats); determine all possible ways to prevent those threats from being realized (mitigate); and confirm all assumptions made in each prior step (validate).

This is a process that can implemented as a cycle, a perpetual undertaking inherent to enterprise security practices; in essence, wash, rinse, repeat.

While current Microsoft guidance regarding the SDL and threat modeling is development-centric, you needn't be a developer or a security expert to threat model. To that end, there is the SDL Threat Modeling Tool to aid you in the process. There's another useful tool called Practical Threat Analysis (PTA). Also, consider as a resource my article specific to analyzing threats to Web applications.

Financial-services providers who commit to these practices will reduce the threats to their Web applications and computing environments significantly. Further, ensuring that third parties take these steps as part of their contractual commitment will instill increased confidence in the financial firms utilizing them, as well as consumers at large.

But if the OWASP survey is any indication, it's going to take a big shift in priorities for organizations to dedicate the needed resources to online security. Compliance was cited by survey respondents most frequently (40%) as the most important driver behind security spending. Companies that suffered a public data breach in the last two years were more likely (86% to 52%) to have a specific IT security budget. Thus, fear and catastrophe are motivators? My research indicates that financial-services providers have much of which to be afraid.

About the author:

Russ McRee is a security analyst, researcher, and founder of holisticinfosec.org, where he advocates a holistic approach to the practice of information assurance. He also writes toolsmith, a monthly column for the ISSA Journal, and has written for numerous other publications