Fighting Cybercrime, One Line of Code at a Time

Financial institutions thrive on information. It is their lifeblood, but perhaps one of the biggest risks for them today is the danger of data haemorrhage. Online criminals across the globe are intent on cutting into financial companies’ infrastructures and bleeding out sensitive data.

If computer networks are the arterial system that shifts this information around, then software constitutes the ‘brain’ of the system. While all security flaws in financial IT systems are problematic, software security problems can be especially devastating. What security issues should financial institutions be wary of when it comes to building and using software applications to help run their businesses, and how can they mitigate these risks?

One of the biggest problems for financial companies, as with many others, is that security is difficult to implement across the whole business. Any company is forced to strike a balance between security and flexibility.

Security inserts checks and balances into business processes, to ensure that malicious actors don’t achieve their goals and damage the health of a company and its customers. However, these can be seen as speed bumps. Financial companies operate in a vibrant, fast-moving market where agility is a key survival trait. It is easy to see why management – sometimes all the way up to board level – focuses on getting things done, rather than on protective measures that can be perceived to be costly, and which could slow down the business.


To some extent, third parties have stepped in to impose regulative measures designed to protect financial data. A good example of this is the Payment Card Industry Data Security Standard (PCI-DSS), which was imposed by the PCI Standards Council as an operational standard for data security. PCI-DSS broadly covers the storage and processing of payment card data, setting specifications to ensure that it is handled securely. Within that standard, a specific sub-specification – the Payment Application Data Security Standard (PA-DSS) focuses on software development.

Whereas many security regulations are notably abstract and vague in their guidelines, PCI is notoriously detailed and prescriptive. However, PCI accreditation didn’t stop Heartland, the payment processing companies, from being hit by financial crime. In 2008, hacker Albert Gonzalez infiltrated its network, placing malicious software on the firm’s network to steal millions of credit card details.

The problem for Heartland, and for others who have achieved PCI certification, is that the accreditation only captures a company’s systems at one point in time. Criminals move quickly when money is at stake, and they make it their job to innovate, creating new techniques to exploit holes in financial systems. After the breach, Heartland went back and re-evaluated its infrastructure, creating an end-to-end data encryption system called E3.

Application Attacks

Threats don’t just come from unauthorised applications. Flaws in legitimate software can leave loopholes for attackers to exploit.

In the past, it was relatively easy to find basic flaws in the operating systems on which the software applications ran. Over time, however, operating system vendors such as Microsoft have become adept at software security, ironing out these software flaws and minimising the number of vulnerabilities that criminals can exploit. This has caused criminals to shift their attention from the operating systems to the software applications themselves, with fruitful results.

Application software is still relatively insecure, which leaves plenty of opportunities for hackers to worm their way into corporate systems – including those run by financial companies. There are a variety of vulnerabilities in modern software applications, particularly the web-based applications that comprise much of the customer-facing IT infrastructure in modern financial institutions.

Of the web applications across all of the sectors surveyed, Veracode found that eight in every 10 failed basic security standards as laid out by the Open Web Application Security Project (OWASP), a respected non-profit software industry group that focuses on best practices in web security.

Not all flaws are the kind that can be fixed with a simple software patch. Often, the bugs are baked directly into the workflow design of the application. In 2008, researchers at Michigan University published a paper claiming that 75% of the web-based banking applications it surveyed contained basic design flaws. These included putting sensitive interaction boxes and information on insecure pages, and breaking the chain of trust when handing off sessions to other web pages.

Mobile applications are getting even less scrutiny than web applications, as illustrated by the 2010 incident in which Citigroup revealed a major security flaw in its iPhone app. The application saved user credentials directly onto the phone in unencrypted form, making it possible for hackers to retrieve the data from a lost or stolen phone.

Evaluating Risk

In some ways, financial services companies are most at risk, even though their application software security is generally more mature than companies in other sectors. Veracode has produced the ‘State of Software Security Report’, in which it examined a random sample of 3000 software applications used by companies across a variety of sectors. The findings in its support were surprising.

The research found that, while the security of software used in the financial sector is generally better than in other sectors, it wasn’t commensurate with the risks involved to financial services companies.

The problem facing banks is that it isn’t enough to simply evaluate the level of security in an application. As with any sector, financial services has to navigate security against mission criticality to arrive at a true representation of risk. A security flaw in an application that deals with sensitive data, such as customer account information, will carry a different risk than the same flaw found in a less important application, such as software that calculates staff holiday schedules.

Banks have a high level of awareness when it comes to threats from poorly written code. Some of the most common technical flaws found in software overall are notably absent in the majority of financial services applications.

However, financial institutions are crippled by a poor understanding of how security flaws should be mapped against application risk. While their software security is robust compared to software across many other sectors, the same is not true when the sensitivity of their business is considered.

When adjusted for criticality, the percentage of applications from the financial sector that were deemed acceptable was just 44%. When analysed by subsector, banks fared badly, with just 37% of applications having acceptable security. Only 35% of applications used by insurance companies measured up, while 46% of applications used by other financial services companies (such as brokerages and credit card processors) applications were deemed to be secure enough to meet their criticality to the business.

A Question of Priorities

Like many other organisations, financial institutions aren’t properly defining their priorities when building software systems. When software is developed in-house, developers are concentrating on building functionality into applications to tight deadlines using a fixed set of resources, to meet commercial requirements. Against these pressures, software security takes a back seat.

Software contracted out to third party developers is even more difficult to control, because clients generally don’t get access to the source code. This means that financial institutions buy and run their software blindly.

The other option is to use open source code, developed by a community that makes the source code readily available. However, this also carries dangers. The ‘State of Software Security Report’ revealed that open source software passed an adequate level of security 42% of the time, meaning that well over half of the available open source software should not be considered secure.

Baked-in Security

What should financial institutions do, then, to make their software more secure? They should build security into their software development process from the early design stages all the way through to deployment and maintenance. Software should be adequately tested for security flaws. Companies could do worse than choose one of the appropriate secure software development frameworks, such as Microsoft’s Security Development Lifecycle (SDL).

Then, software security should be aligned with a broader IT security policy, incorporating robust policies in areas such as change management, data encryption, and de-perimeterisation, in which individual components inside the corporate firewall are heavily protected.

The road to a truly secure software and IT infrastructure can be a long one, but with the right roadmap, financial institutions can get themselves – and their customers – safely to their destination.


Related reading