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

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

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 Securityapplication 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:

1 2 Page 1
Page 1 of 2
7 hot cybersecurity trends (and 2 going cold)