Application security is one of the hottest issues for financial institutions right now as more and more mobile applications and web-based offerings are rolled out internally or to customers. Duncan Jefferies looks at best practice

Financial institutions have invested a lot of time and money on their perimeter defences over the last decade, beefing up firewalls and monitoring tools to keep hackers out. But when it comes to securing their applications they've been nowhere near as pro-active - it's the equivalent of building a huge wall around your house, then leaving the back
gate unlocked.

For a hacker, there are many different paths through an application to sensitive data, some of which are more difficult to close off than others. For example, most web applications have a database containing sensitive information at their heart, which operates in conjunction with web scripting languages like SQL. Should external user input into the application include things like form fields, an attacker may be able to exploit the application via an SQL injection attack - 'injecting' malicious SQL commands that are then executed by the database.

According to Floris van den Dool, head of security for Europe, Middle-East & Africa (EMEA), at the Accenture consultancy, attackers are increasingly targeting web applications. "Criminals are no longer just trying to drop or deface a website. It's now more about doing an SQL injection to exploit an application and get at the customer data, allowing them to commit fraud."

Jeff Williams, chair of the Open Web Application Security Project (OWASP), which provides updates on the latest threats likely to impair web based applications [see boxout], says although there can certainly be big holes in public facing web applications, they are not the only area of vulnerability. "Don't forget about the rest of the iceberg - namely, your internal web applications. In your typical financial institution, there may be a hundred public facing web applications, but a thousand or five thousand internal web apps. These drive the business, and that's where the really serious information [what the criminal wants to get at] is kept."

A secure development
The development of web applications involves a trade off between functionality, timescale and cost; with security often squeezed out of the picture by these pressures. "It's an age old issue that occurs whether you happen to be in IT or whether you're building a house," says John Colley, EMEA managing director of the (ISC)2 professional training and security trade body, and formerly head of risk services at Barclays and group head of information security at RBS. "If you want to reduce the time or cost, something has to give on the functionality side. And similarly if you want to increase the functionality, it's either going to take longer or it's going to cost more. When push comes to shove, you find that some of the security functionality disappears."

Often a proper security review does not happen until the application is in production. But ideally, security requirements should be determined alongside the functional and business requirements early in the development cycle. A preliminary risk assessment done at this stage will help identify the core security features needed in the software. This security plan can then be adjusted as the development progresses.

"Good practice would dictate that you've got to look across the whole lifecycle, from the concept and the strategy, all the way through to planning, design implementation, operation and disposal," says Paul Lothian, head of enterprise security consulting at Symantec. "There's risk at different stages, and it will vary at different financial firms."

But if banks or insurers follow a process of not signing off on a development project until the security elements are fully in place, the security team can find themselves under tremendous pressure to push the application into production in order to meet tight deadlines. "In both the organisations I worked for, we implemented a process that meant we
got involved much earlier in the cycle - at the architectural stage - to make sure that everything was correct," says (ISC)2's Colley.

RBS used a key checkpoint, called Fit for Design, which meant a project wasn't allowed to go past the design stage until the security team had examined it and made sure the fundamentals were sound. A second checkpoint, Fit for Production, made sure the application agreed upon at the design stage was the one that was subsequently built. "Project managers the world over... they don't cut corners, but they certainly see what they can get away with," adds Colley.

Passing the test
Quality Assurance (QA) departments have traditionally concentrated on making sure an application works properly and performs the tasks assigned to it. But with web application security becoming more and more critical, their participation in security testing is also necessary.

Security testing should ideally be undertaken through the entire software development lifecycle (SDLC) of an application, though at present it is often an afterthought, performed retrospectively once the application is already operating in a live environment or just prior to launch when time pressures are severe.

It is expensive to retrofit security after an application is deployed - IBM estimate more than 30 to 100 times more costly than building in security during the development lifecycle. Symantec's Lothian reckons financial organisations are beginning to wake up to this fact. "In the past few years they have adopted much more of a cost/benefit approach to application security. Firms realise that the cost to fix or maintain in live operations is in factors of 10s if not 100s higher than the cost of fixing problems in the planning or even the design stage, so it actually makes sense to put in place security controls earlier in the lifecycle."

Ethical hacking
Penetration tools (also known as ethical hacking tools) have been used for some time by the security firms or internal teams employed at financial institutions to test application security. These are used to attack the surface of the application to expose vulnerabilities in the source code, and are typically used on applications already in operation. A penetration test can uncover sensitive information about an organisation. As such, most security firms are keen to demonstrate that their employees are trustworthy and adhere to strict ethical codes. The Council of Registered Ethical Security Testers (CREST), for example, is a not-for-profit association that provides industry-recognised certification for penetration testers. Organisations wishing to hire a security firm are able to view its register of accredited firms and individuals, giving them peace of mind that a penetration test will not inadvertently leave them open to attack. Aviva has been instrumental in launching CREST.

Accenture's Van den Dool advises all organisations to undertake penetration testing for their web applications. "Otherwise there are a whole bunch of hackers out there who will do the penetration testing for you instead," he says.

But according to OWASP's Williams there is no substitute for a full source code review. "For certain types of problems, it is absolutely the fastest and most accurate way of finding security holes. In some ways it's like cheating. You've got the code right there, so if you know how to read it you can find the holes really quickly." He says there is a role for penetration testing and scanning, "but having the code reviewed is just absolutely invaluable. I always tell people if you're getting a security review done, you want someone who knows how to read the code."

Physical code reviews can be done automatically, or manually by a code specialist, but the sheer amount of code that needs scanning (often 500,000 lines or more) typically makes this a Herculean task for a lone individual. The best approach, says Accenture's Van den Dool, is a combination of both automated and human testing. "There are very elaborate tools that do all of the checking automatically, but even then you still want to validate the recommendations they come forward with and look at the significance of the issues they find." Human intelligence here can be invaluable.

OWASP's Williams claims the quality of third-party security services available to financial institutions varies. "Some companies will just run an automated penetration tool and feed you the report, without any value add, and charge you £15,000 for it," he says. "Whereas for £15K, another company might do a code review, a penetration test, and really dig in and understand the business so as to produce a real report." Beware who you choose.

Human Error
Application security issues are a recurring problem. Issues in one application may get fixed, but if security is not driven into the real development methodology, perhaps because programmers are not trained sufficiently or are on short-term contracts or outsourced, the same mistakes can happen again when future applications are created and deployed or when apps are built on top of apps.

Organisations generally understand what they need to do to change this destructive cycle but embedding best practice across the business is difficult. "If you have got a large organisation with 60, 80 or 100 thousand employees globally, multiple business units, multiple geographies, and multiple working practices, then clearly trying to embed good practice across the key areas of security risk involves a big change programme," says Symantec's Lothian. "It's typically an evolution rather than a revolution."

Automated code programmes that operate overnight, running source code against the OWASP criteria and other known vulnerabilities, can help to bring consistency about. "They produce a list of recommended fixes, ready for developers to implement the following day," explains Accenture's Van den Dool. "This increases awareness as developers then have to go back, fix the problems, think about them, and hopefully it will prevent them from making the same mistakes in future."

Although network security remains hugely important for financial institutions, it's increasingly likely to be their applications that suffer the brunt of malicious attacks. "To me it seems that your spending ought to be fairly balanced between network security and application security," says OWASP's Williams. "But at the moment we see organisations spending
5-10 per cent of their IT budget on network security, and a tiny fraction of that, one per cent or less, on application security."

That will surely need to change if organisations are to avoid costly and damaging security breaches, for as Williams says: "Hackers aren't stupid. They'll go for the weakest link."

OWASP Top 10 Most Critical Web Application Security Risks 2010
1. Injection
2. Cross Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Failure to Restrict URL Access
8. Unvalidated Redirects and Forwards
9. Insecure Cryptographic Storage
10. Insufficient Transport Layer Protection.

Share Story: