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 2

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