It's been more than a year since section 6.6 of the Payment Card Industry Data Security Standard (PCI DSS) became a requirement. PCI 6.6 requires organizations that process credit card transactions to address Web application security; it mandates that companies conduct either manual or automated source code reviews, or install a Web application firewall between a Web application and client endpoints.
Web applications are a popular attack vector. SQL injection attacks are becoming rampant, and are most dangerous because the vulnerabilities they exploit often provide a direct route to an organization's sensitive data.
The PCI Security Standards Council imposed a June 30, 2008 deadline for compliance with PCI 6.6; for the 18 months prior, it was a recommendation. It was a wake-up call for organizations to address Web application security, and a stress point for smaller Level 3 and Level 4 merchants who may not have the resources or expertise to either conduct a source code review or properly configure a Web app firewall.
Manual source code reviews are extremely expensive and time consuming. Automated vulnerability scans are less so, but still tax the bottom line. Web app firewalls, meanwhile, are likely the quickest way to a compliance checkmark, and some experts say this is a fitting starting point until an organization matures sufficiently to tackle its proprietary software.
"Many organizations start with a Web application firewall to get a checkmark. That is not necessarily raising the bar in terms of security, but they would be meeting the compliance factor," says Danny Allan, director of security research with IBM Rational.
Allan points out that organizations should want to do both, but the most likely scenario is one where an organization is grappling with how to compare the two options afforded by 6.6 and deciding which is the best immediate fit.
"There's no right answer," Allan says. "Some recommend beginning with a Web application firewall, but a WAF needs to be configured properly to work. If you're in a fluid environment [applications change and grow in complexity], that can require a fair amount of time to configure. And ultimately, you're putting a Band-Aid on the issue. The application still has the problem."
Web application firewalls, also known as deep-packet inspection firewalls, look at application layer messages for violations of an established security policy. Some offer signature-based protection, while others are fed a baseline of appropriate application behaviors and monitor for deviations. They're offered either as software or in an appliance. WAFs struggle detecting certain types of attacks because they don't always understand the context under which input is entered into an application, and legitimate traffic could be dropped if a WAF believes the traffic violates policy. Also, some tools fail to detect some serious Web app threats such as cross-site scripting attacks.
"In my mind, you want to do both [6.6 options], but this is an apples to oranges comparison," Allan says. "Which gives you more of a bang in the short term? That is the question that needs to be answered."
"Smaller merchants are going to gravitate toward a WAF if it will get them a checkmark," says David Taylor, founder of the PCI Knowledge Base and research director of PCI Security Vendor Alliance. "That is where things are going. It's not wrong; it's the most cost-effective way to go. I would never tell a Level 3 or 4 merchant to spend more money than they have to."
Source code reviews, meanwhile, are the ideal solution. For some time, experts have urged organizations to include security in the software development lifecycle. Automated scanners can test applications for vulnerabilities, in particular the Open Web Application Security Project (OWASP) top 10 list of flaws. In fact, PCI DSS 6.5 says Web applications should be developed based on guidelines such as OWASP and applications should be secured against the vulnerabilities listed in the top 10, which is updated annually.
But developers generally shun security because it hampers productivity and functionality. Manual reviews are difficult, though sometimes they're essential in order to catch problems in the context of an application's semantics. Expense aside, manual reviews require inspection, often of hundreds of thousands of lines of code, and it's virtually impossible to follow all the logic paths an application can take, says Barmak Meftah, senior VP of products and services at Fortify, a vendor of static and dynamic source code analysis tools.
"The main type of vulnerability a hacker is getting hold of is an input field--putting in malformed input and getting the app to do unintended things," he explains. "That packet is now using different paths than intended, and connecting those dots optically is impossible."
The big picture is that organizations need to look at 6.6 compliance requirements in the context of an overall vulnerability management program, says IBM Rational's Allan.
"Security threats are changing daily. PCI 6.6 is a strategic approach: How do I address this fluid changing paradigm of security attacks that is going to be different tomorrow than today?" Allan says. "This is about building good, quality code. If we keep focusing on the security aspect and not building quality apps, we're forever going to be chasing security vulnerabilities."
Michael S. Mimoso is editor of SearchMidmarketSecurity.com.
Send comments on this technical tip firstname.lastname@example.org.
Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.