Home » Data Protection » Application Security

In Depth

PCI Application Security: Who's Guarding the Data Bank?

Ben Rothke and David Mundhenk offer compliance strategies for PCI's new application security requirements

By Ben Rothke and David Mundhenk

Page 3

Insecure Banking Applications
Resting 50 feet below sea level, on the solid bedrock of Wall Street, the Federal Reserve gold vault [links to .pdf] contains hundreds of billions of dollars worth of gold. Besides the extravagant layers of security implemented around, and within, this facility the reality is that gold being quite heavy, bulky, and is difficult to move. Even if an attacker got in, it would be hard to get out with a significant amount of gold.

While getting gold out is difficult, data is light and very fluid. Transferring a gigabyte of data today is almost trivial. The data contained in today's banking applications have the value of gold, yet are light enough to access and move with ease. These applications will contain from tens of thousands to hundreds of millions of records. The application will connect to a database that serves as the repository for sensitive personal data. The hacker's booty will be contained within these applications, and the currency can take many forms; but usually is comprised of customer account information and other personal identifiers that the modern day Willie Sutton can use for ill-gotten gains. And getting the currency out is merely transferring strings of ones and zeros from one computer to another, hardly like attempting a haul of heavy gold bars.

In the case of PCI Data Security Standards (DSS) the 'money' or currency, aka sensitive information that most needs to be protected, includes:

primary account numbers (PAN)
cardholder name
various service codes
expiration date
other items that are allowed to be digitally stored if suitably protected
magnetic card stripe data including security codes and PIN's

In fact, based on merchant compromises, Visa has found that the storage of prohibited data (full track, CVV2, PIN blocks, etc.) was the prime cause for most cardholder information data breaches. Often, the data stored in these databases should have never been stored there in the first place once the requested credit card transaction was authorized. But time and time again there are instances of proprietary and commercial off-the-shelf (COTS) applications being compromised because they are not developed to be in compliance with PCI DSS and secure coding requirements. In some instances the reported code flaws violated just plain common sense application development standards, such as OWASP.

As security professionals and PCI Qualified Security Assessors (QSA) [links to .pdf], based on our own experience and insight into the market, the authors are surprised that in 2008, there are still banking applications that are deployed without a formal security-based SDLC and security code review. Compounding this, far too few organizations have effectively trained their developers in security development practices. It is almost criminal that in late 2008, developers creating such payment processing applications don't even know what the PCI DSS requirements for the proper processing and storage of sensitive information are.