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

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.

• Email
• Print
• Comments
• Digg This
• SlashDot

• All About the PCI Data Security Standard
• How to Evaluate (and Use) Web Application Security Scanners
• Eyeballing the Security of Application Service Providers
• FUD Watch | Vendor Hype Escalates Over PCI Deadline
• Strong Authentication for Online Banking: Success Factors