This tip is part of SearchSecurity.com's Compliance School lesson, PCI DSS compliance: Two years later. For more learning resources, visit either the lesson page or the Compliance School main page.
If you're like most Web users, chances are you've made a purchase or a payment by entering your credit card number into an online Web form. Retail sites, online travel agencies, bill-pay portals for utilities and services and even government entities commonly support credit card payments via the Web.
This results in millions of credit card numbers circulating through Web applications every day. And where there are credit cards, there are the Payment Card Industry Data Security Standard (PCI DSS) requirements.
Section 6 of the PCI DSS states that entities must "Develop and maintain secure systems and applications." The PCI DSS applies to any system that gathers credit card data. In this tip, we'll concentrate on requirements for Web applications, but don't forget that brick-and-mortar point-of-sale (POS) systems are also subject to PCI DSS requirements. The key PCI DSS sub-requirements for Web applications include:
- 6.3 "Develop software applications based on industry best practices and incorporate security throughout the software development life cycle."
- 6.3.7 "Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability."
- 6.5 "Develop all Web applications based on secure coding guidelines such as the Open Web Application Security Project Guidelines."
- 6.6 "Ensure that all Web-facing applications are protected against known attacks by either of the following methods:
- Having all customer 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."
Source: Payment Card Industry Data Security Standards v1.1
Let's take these one by one. To weave security throughout a Web infrastructure, according to the strict best practices outlines in the software development life cycle (SDLC), requires a ...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
commitment to incorporating security and risk analysis at each critical phase of the life cycle. There are a number of guides that organizations can use to better understand where and how to insert security into the SDLC. Some of the most well-known are Microsoft's Secure Development Lifecycle, Cigital's TouchPoints and OWASP's Comprehensive Lightweight Application Security Process (CLASP). Organizations can adopt one of the known frameworks listed or develop one of their own.
The following table shows a linking between the phases in the SDLC and how PCI DSS protection needs can be mapped to them.
Lifecycle Phase
Tools and Methods
PCI Question Examples
Requirements gathering
Include security requirements
Do PANs need to be stored?
Design and architecture
Perform risk analysis
Who needs access?
Can individual user accounts be supported for access to databases?
Development
Frameworks and approved libraries
Code scanning and review
What encryption algorithms are approved?
Are inputs validated?
Testing
Application vulnerability scanners and penetration testing
All test data removed?
Is account access working properly?
Deployment
Monitoring and audit
Are transcripts logged?
Is sensitive authentication data (SAD) eliminated after authorization?
Reviews of custom code can be done manually, using an automated scanning tool or by combining the two. Manual code reviews are labor intensive and reviewers need to have experience in reviewing code; not just for coding errors, but also for potential security problems, vulnerability to cross-site scripting or SQL injection because inputs were not properly validated.
Scanning tools come in a variety of options. Static source code scanners, such as those from Fortify Software Inc. and Ounce Labs Inc., can be used by developers in the IDE or as a standalone by auditors. Compiled binaries can be scanned using Veracode Inc.'s software-as-a-service (SaaS) scanner. And Web applications can be scanned using Web application vulnerability scanners, or scanning services from Cenzic Inc., Hewlett-Packard Co. (SPI Dynamics), IBM (Watchfire), NT OBJECTives Inc. and WhiteHat Security Inc.
The PCI DSS recommends using secure coding guidelines such as the OWASP Guide. OWASP also provides in-depth testing guidance for finding the "OWASP Top 10" Web application vulnerabilities, which are expressly mentioned in the PCI DSS. The Web application scanning tools listed above can also be used to check for a majority of the OWASP's top 10 vulnerabilities.
Another good resource is Visa's Payment Application Best Practices (PABP) document. Organizations can use the PABP for application development guidance and as an assessment tool when purchasing payment applications. Visa also provides certification against the PABP for payment applications.
For customers that opt to meet the 6.6 requirement using an application-layer firewall, there are a number of options. Application-layer-aware firewalls include Cisco Systems Inc. PIX and Check Point Software Technologies Ltd.'s NG. For more granular Web application-aware protection, there are specialized Web application firewalls available from vendors including Breach Security Inc., Citrix Systems Inc., F5 Networks Inc., Imperva Inc., Barracuda Networks (NetContinuum) and Protegrity Corp. It's worth noting that many organizations have interpreted the phrase "application-layer" to mean Web application firewall. It is possible that this wording will be qualified to explicitly require a Web application firewall in subsequent versions of the PCI DSS.
In closing, weaving security throughout the SDLC is becoming a way of development life for many organizations. If yours is already integrating security into the SDLC, meeting the PCI DSS application security requirements should not be a challenge. For organizations that aren't there yet, the PCI DSS requirements are a great motivator.
About the author:
Diana Kelley is vice president and service director with Midvale, Utah-based research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.
