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.
An additional layer of protection should be provided by quality assurance personnel who should be testing these applications. They should do so with respect to all aspects of how sensitive information is handled throughout the information life-cycle and the historical recording of resultant transactions. Yet many application test teams continue to focus their efforts on testing only the functionality, scalability, and loading requirements of application capabilities.
To their credit, some application testers may actually scan the various components with a generic vulnerability scanner, but lack the skill set to properly interpret the scanner output results. They may also be relying on how the application is deployed or on other external controls to provide the necessary security. Those tasks might have been tolerable long ago on non-Internet connected systems, but are vastly inadequate when the application is running on an open, publicly accessible networks.
Fortunately for those who rely on such commerce, which is everyone with a credit card, the PCI Security Standards Council (PCI SSC), the major card brands, card issuers, and Qualified Security Assessors across the industry are working in concert to permanently change things for the better. The posse, if you will, has been formed, and if the necessary fundamental changes can be made, the modern day Willie Sutton and his boys' days are numbered. Payment application security may ultimately become ubiquitous and considered just as important as any other system function.