WEB SECURITY ADVISOR
PCI DSS Section 6: A plan for tackling application security
Joel Dubin
12.13.2007
Rating: -2.45- (out of 5)
|
Among the Payment Card Industry (PCI) Data Security Standard's 12 requirements is a mandate for Web and application security. Requirement six specifically calls for merchants and credit card issuers to "develop and maintain secure systems and applications."
While many parts of the standard have caused headaches for companies using credit cards in their business, Section 6 is especially painful. Like other PCI DSS requirements, some of it is common sense and easy to implement, and the rest is ambiguous and confusing to understand, not to mention difficult and costly to implement.
What makes it more painful is that unlike the rest of the standard, the last part, Section 6.6, is only recommended as a "best practice." It becomes a requirement June 30, 2008, and if companies want to be compliant by that date, they have to begin their work now.
Code reviews or firewalls?
To achieve compliance with Section 6.6, companies have two draconian alternatives: either conduct code reviews for all their Web applications, or install an application-level firewall.
But before delving into the specifics of Section 6.6 and some acceptable workarounds, let's briefly review Section 6. Again, as with the rest of the PCI DSS, some of these guidelines may already be part of your IT security program.
Sections 6.1 and 6.2 basically require companies to check for published vulnerabilities and install patches within a month of release. They also call for setting up a process to do all of this and to update standards based on new vulnerabilities. Most corporations already have a patch management program in place, and an employee watching the Web and downloading, testing and installing patches.
Section 6.3 descends deeper into the snake pit of compliance, but we haven't hit rock bottom yet. There are seven practices for application development that revolve around integrating security into the application development life cycle. This isn't
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
a new idea and it has been championed, for example, by Microsoft with its Security Development Lifecycle (SDL) process.
Though Section 6.3 is harder to implement than the previous two sections, it's pretty standard fare for secure software development. It calls for, among other things, testing of patches and software changes before deployment, separate development, test and production environments, not using production data for testing, and removal of both test data and custom accounts with user IDs and passwords before production deployments.
These are best practices for any company with an in-house software shop. Besides Microsoft's SDL, the Open Web Application Security Project (OWASP) has methodologies for integrating secure coding into the development lifecycle. In fact, OWASP best practices are part of Section 6.5.
Section 6.4 covers change control, which includes documentation, management sign-off and testing and rollback procedures. Most companies already have change control processes in place for their software deployments. Otherwise, their systems would be in a state of chaos.
Section 6.5 calls for all Web application development to be based on guidelines like OWASP. OWASP has its own version of the Ten Most Wanted list of Web application vulnerabilities, but the problem is that the current version of PCI (1.1) was released in September 2006, and the OWASP vulnerability list is updated annually. That means what's in the standard and what's currently in OWASP aren't an exact match.
OWASP's top ten for 2007 include cross-site scripting (XSS), injection attacks, improper error handling, and broken authentication and session management. But new culprits include cross-site request forgery (CSRF), insecure cryptographic storage and communications and failure to restrict URL access.
Does that mean you're going to take a beating from your PCI auditors if you follow the current OWASP list and not the letter of the law in the PCI standard? This is one of the PCI gray areas that have caused so many headaches for businesses trying to become compliant. The best answer is that it depends on your auditors.
Since this section is slated for an update next year, it's likely auditors will call this a "compensating control," one of PCI's few loopholes. It would also be hard to penalize a company for using an updated version of OWASP. It's still OWASP, and the standard recommends using it.
Section 6.6 is the most difficult and controversial part of the PCI DSS. It calls for either a review of all Web application code developed in-house, or the installation of an application layer firewall to protect all Web applications from known attacks.
This puts most companies in a difficult position. They either have to spend money for an additional firewall, which could be a drag on their network and might not even fit into their architecture, or they have to pay for an outside consultant to review all of their application code. Even for a small company with only a few Web applications, this can mean reviewing thousands of lines of code.
Companies seeking PCI compliance already have to budget for third-party consultants to scan their networks. Section 6.6 just adds to that burden, since these scanning consultants don't always perform application code reviews.
But there is an alternative. Companies will be compliant if they use a Web scanning tool such as SPI Dynamics WebInspect, Watchfire's AppScan (these companies were recently acquired by Hewlett-Packard and IBM, respectively), or Cenzic's Hailstorm. An enterprise must also show it has the expertise to fix uncovered vulnerabilities. Combining this with developer training wrapped around OWASP is a plus.
Though WebInspect and AppScan don't do line-by-line code reviews, the PCI Security Standards Council has hinted they fit the bill. This is another area that may be more clearly spelled out in next year's redraft.
Many companies offer PCI compliance tools that check for data protection and leakage, but few address the application security requirements of Section 6. If you're looking for a tool to assist with Section 6 compliance, stick with traditional scanning tools like WebInspect and AppScan and code review products from Ounce Labs and Fortify Software. WhiteHat Security and Veracode are among the vendors that provide code review as a service.
Section 6 has unique challenges that are different from the rest of the PCI standard, and those challenges require a different approach for compliance.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and is the author of The Little Black Book of Computer Security available from Amazon. He has a regular radio show on computer security on WIIT and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
|
|
Rate this Tip
|
To rate tips, you must be a member of SearchSecurity.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
|
|
|
|
