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

While Willy Sutton never really said it, the truth is that people rob banks because that is where the money is. Today's criminals don't walk into banks with loaded guns and get-away drivers. Rather they connect from a remote location using a browser and are armed with hacking tools and spyware.
Where criminals of old targeted the teller behind the counter, today's attackers target banking and e-commerce applications. So, although the targeted infrastructure has changed, not much else has really changed from a threat perspective since Willy Sutton robbed banks. Ask a hacker "where is the money?" They will tell you: behind and within the poorly written and poorly protected banking and e-commerce software applications.
The list of threats and their calamitous consequences targeting banking and payment applications is seemingly endless. Identity theft, data leakage, phishing, SQL injection, worms, application Denial of Service (DoS) attacks, and botnets just scratch the surface, but these are the threats critical applications have to be secured against today. The big problem is that the number of threats as well as the number of applications that need to be secured are increasing on a regular basis.
PCI and Application Security
To date, the industry has given short-shrift to the needs of application security, and we all have paid for it with continuing data breaches. Consider this, Microsoft finally got serious about application security in 2002 with its Trustworthy Computing (TWC) initiative. TWC was an outcome of devastating attacks against Microsoft operating systems with worms such as Code Red and Nimda.
TWC was announced in an all-employee email from Microsoft head Bill Gates. He redirected all software development activities at Microsoft to include a full security review. Even with that directive it still took years to get to the point where Microsoft's code could start to be secure. How many merchants in the PCI space have their founders tell everyone to code securely and that they will stop all development until it is done? The point was, and is, that application security needs to be taken seriously and this means, investing the time, effort, and resources to do it right.
Application security is at the heart of the Payment Card Industry (PCI) security standards and requirements. In the last few years, data breaches have resulted in hundreds of millions of data records being compromised. In most of these cases, the firewalls worked, the encryption worked, the logging worked, but the application contained security holes which obviated much of the security. It's like barring the front doors to the bank and leaving a back window open.
So why has PCI started focusing on web and payment applications? For the very reason that these applications are the most obvious entry point for attackers to gain access to back-end databases containing huge amounts of credit card data.
Within the PCI Data Security Standard (DSS), requirement 6.6 (which became mandatory on June 30, 2008) requires the validated security of web-based applications. PCI DSS requirement 6.6 requires organizations that process credit card transactions to address the security of web applications, either via manual or automated source code reviews or vulnerability scans, or via the installation of a web application firewall between a client and application.
PCI DSS Requirement 6.6
While the applications security requirements in PCI DSS section 6.6 comprise a mere 44 words, don't think that application security compliance is either unimportant or a piece of cake. The specifics of requirement 6.6 are:
Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
-- Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
-- Installing an application layer firewall in front of web-facing applications
First off, just what is this thing called an application layer firewall? Also termed a web application firewall, it is a network device that is placed in front of a web application to protect against application attacks. An application layer firewall can view and digest all application traffic, but has the enhanced capability to specifically filter session, presentation, and application layer network traffic (OSI model) in real time. This gives it the advantage of protecting the applications and all associated sensitive data from illegitimate access and unauthorized usage.
The security threats mitigated by an application layer firewall are very real. To give you a feel for things and to truly address business risk, note that the range of software security risks is significant. They can be divided into two distinct types; coding vulnerabilities and design flaws/policy violations. According to a leading software application security firm , they view the hierarchy as:
Coding vulnerabilities:
-- Buffer overflows
-- Format string vulnerabilities
-- Race conditions
-- Resource leaks
-- Input/output validation and encoding errors
o SQL injection
o Cross-site scripting
o Operating system S injection
Design flaws and policy violations
-- Cryptography
-- Network communication vulnerabilities
-- Application configuration vulnerabilities
-- Access control
-- Database and file system use
-- Dynamic code
-- Access control and authentication errors
-- Error handling and logging vulnerabilities
Insecure error handling
Insecure or inadequate logging
Native code loading
Data storage vulnerability
-- Insecure components
Malicious code
Unsafe native methods
Unsupported methods
Custom cookies/ hidden fields
While this one of a number of possible attempts at threat codification, the message should be clear that software security is a multifaceted effort that takes a directed and formalized approach.
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.
PCI Application Security Requirements
Currently, there are requirements for custom in-house or out-sourced applications and software that are not commercially re-sold to comply with all relevant requirements of PCI DSS, All custom applications must be developed, deployed, supported and refreshed according to these requirements.
They include the following:
1. Applications must be developed as a part of a well-defined Software Development Life Cycle (SDLC) with security principles incorporated into the development process.
2. Applications should reside on hardened operating systems and with discrete and well defined limitations on unnecessary functionality.
3. Applications should never store sensitive authentication data (card magnetic stripe, security codes, PINs, etc.)
4. Applications should not interfere with cyber-security controls such as antivirus, firewalls, cryptographic protections, secure authentication schemes, IDS/IPS, etc.
5. Web based applications must be developed in accordance with the Open Web Application Security Project (OWASP) guidelines for secure coding.
6. Web-facing applications (i.e.-Internet facing) must be protected either with a source code review by an authorized entity or be protected by application firewalls.
7. Applications should be tested for security vulnerabilities in addition to functionality testing by someone other than the authors of the actual code.
Application Security Action Items
Some business and IT leaders may be just starting to consider the security implications of their banking or commerce applications. There may be lingering uncertainty on what to do first. The following 5 steps are a great first start:
1. Update POS Applications. Visa maintains a list of Payment Application Best Practices compliant POS applications. Ensure that you are running a compliant version of POS.
2. Identify Poorly Coded Web Apps. Perform a code review for known coding flaws. Then follow-up with a vulnerability scan and an application-layer penetration test to ensure application code is PCI complaint and secure.
3. Perform Quarterly Vulnerability Scans. As detailed in DSS section 11.2, run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
4. Perform Annual Penetration Testing. Both internal and external (public facing) applications that process "sensitive" data should be penetration tested at least annually and whenever they undergo significant revision.
5. Create Formal SDLC Processes. Microsoft understood this via Trustworthy Computing. Make sure you formalize a Software Development Life Cycle that incorporates security analysis throughout that life cycle.
Note that these five steps will keep your development teams busy for a while. And make sure you have a good project manager to keep all of the tasks and teams in sync.
Visa PABP Replaced With PCI PA-DSS
COTS payment processing applications that are sold or leased to the public have more stringent requirements for application security compliance. These requirements were originally developed, implemented and enforced by Visa and were known as the Payment Application Best Practices (PABP) standard.
Over the years these requirements served the industry well and have helped to protect Visa credit card commerce wherever compliant applications have been implemented. Unfortunately, however, the PABP was focused primarily upon applications processing Visa payments, and the enhanced security benefits could not be shared across all payment card brands. It became obvious that a broader, more encompassing application security standard was in order; this is where PCI Payment Application Data Security Standard (PA-DSS) came into play.
In November 2007, the PCI Security Standards Council (SSC) announced that PABP will be transcended by the PCI Payment Application Digital Security Standard (PA-DSS). In doing so the PCI SSC became the sole entity to maintain these new card brand independent requirements and oversee compliance with this new security standard. Payment applications that have been previously certified as compliant with the most current versions of the PABP specification will have their certification grandfathered for a limited time, and be given a grace period before they must be recertified under the new PA -DSS.
Newly developed commerce applications, which are sold to the public, will have to be tested and found compliant with PA-DSS requirements starting in October 2008. The two standards are similar and indeed a majority of PA-DSS content is based upon the previously well-defined PABP requirements. There are some distinct differences between two, however, including a very stringent requirement for the PA-DSS QSA to validate the environment which is used for all application security testing.
In addition, the PA-DSS Implementation Guide (similar to PABP's Best Practices Implementation Guide) has detailed references on how to securely implement the payment application and related systems in a specific supported, compliant configuration. It also clearly states that any deviations from specific supported configurations may indeed jeopardize PCI DSS compliance for merchants and businesses who implement the chosen COTS payment application.
Additional Visa Mandates
Beginning in January 2008, Visa raised the bar on application security when they announced a series of new mandates. Ultimately, these mandates are designed to eliminate the use of what are deemed to be vulnerable payment applications from their Visa's payment processing networks. To quote from their announcement, "These mandates require acquirers to ensure their merchants and agents to not use payment applications known to retain prohibited data."
The initial Visa mandates will be focused primarily on new payment applications to be connected to the Visa payment processing system this year. As the other additional mandates are phased in over time, however, their overall objective is to force the eventual de-commissioning of all known vulnerable payment processing systems from Visa networks by July 2010.
In addition, Visa will be publishing a list of current known vulnerable applications and providing that information to acquirers. By doing so, Visa can ensure that acquirers will hold their merchants and agents accountable for using only non-vulnerable payment processing systems.
Conclusion
Web applications have become the backbone of banking and e-commerce. POS and payment processing applications leveraging web and web-like technologies are being deployed as the next generation alternative to similar legacy systems. They connect end-users, customers, merchants, agents, and partners and process sensitive data including personal and financial information which is of the highest value. They do so anywhere, everywhere, anytime, and in real time. The need for significantly enhanced application security becomes paramount, and as a result the importance of PCI DSS and PA-DSS application security requirements become even more focused.
While application security presents some of the most challenging, and possibly the most costly, barriers to compliance with PCI DSS, requires 6.6 is far too important to ignore, no matter how difficult it is, nor how high the cost. Your organization's future depends on securing web applications and the costs of an unauthorized breach will eclipse the costs of doing the right thing by protecting the applications and sensitive data in the first place.
Ben Rothke CISSP, QSA (ben.rothke@bt.com) is a Security Consultant with BT Professional Services and the author of Computer Security: 20 Things Every Employee Should Know (McGraw-Hill Professional Education). David Mundhenk CISSP, PCI-DSS & PA-DSS QSA, QPASP (stratamund@sbcglobal.net) is a Security Consultant with a major professional services firm.