Good web application security requires multiple approaches

Share this article:
Good web application security requires multiple approaches
Good web application security requires multiple approaches

The big changes to the Payment Card Industry Data Security Standard — specifically for web application security — have arrived. From now on, sections of PCI DSS that pertained to web applications that were formerly considered best practices now are mandated; this includes web application security reviews and/or the deployment of a web application firewall (WAF).

Earlier this year, there was considerable confusion surrounding PCI DSS section 6.6 (which requires internet-facing applications to be secure). There were questions whether the use of a WAF negated the need to develop secure web applications at all, or if web application vulnerability assessment tools could be used to meet the security intent. This led some in the security industry to boast that deploying a web application firewall was the best way to attain compliance. That isn't necessarily so. The confusion may have seemed surprising, because requirement 6.5 did require web applications to be developed with security in mind.

The PCI Security Standards Council published a clarification, stating that proper web application code reviews, including automated web application vulnerability scanners, when used by someone who has been properly trained in their use, all are ways to meet requirement 6.6. These include:

1.  Manual review of application source code.

2.  Proper use of automated application source code analyzer (scanning) tools.

3.  Manual web application security vulnerability assessment.

4.  Proper use of automated web application security vulnerability assessment (scanning) tools.

This isn't to say that a WAF deployment shouldn't be considered. It certainly should. WAFs can do an excellent job at protecting code errors missed by manual and automated assessments, and they add an additional layer of defense against unknown vulnerabilities and zero-day attacks. But it's certainly not a wise move to rely on WAFs alone. First, WAFs do not detect all of the different types of attacks that could be targeted at your web applications. Second, WAFs aren't without their management and configuration issues. And, like most technology, they don't come trouble-free. For instance, it's not uncommon for organizations to notice that certain pages don't function well behind their WAF — and that means WAF functionality usually is turned off for that page. That's a quick and slippery slope to big security trouble.

As with any regulation, it's important to keep in mind the intent of its requirements. The intent of requirement 6.6 is to ensure that web applications are built and maintained in a secure way. And a crucial part of those efforts is making sure your web applications, whether you buy them or build them in-house, are tested for potential vulnerabilities.

If you do develop your own web applications, it's important to train developers regularly on web application security basics, such as the types of errors that can create poor security conditions like buffer overflows and cross-site scripting vulnerabilities.

Also, just as one must scan networks for vulnerabilities on a regular, if not continuous, basis, it's also important to use automated tools that will evaluate web applications before they're deployed. And, once they are, regular scans should be conducted not only as part of your normal security and compliance program, but every time your applications or servers are changed or updated.

But unlike the case with network vulnerability scanners, the PCI Security Standards Council hasn't set out guidelines for the capabilities of any web application vulnerability scanner. Considering today's common programming techniques, it's important that the scanner be able to evaluate Javascript and AJAX applications, spot cross-site scripting vulnerabilities, and conduct authenticated and unauthenticated scanning to capture the perspective of both authorized and unauthorized users. Of course, these results need to be submitted for “expert review” to validate and interpret the remediation steps behind the identified issues.  And the web application scanner should be easy to use, provide reports you understand for straightforward remediation, and provide automated functionality whenever possible.

One change many organizations aren't aware of is that the Payment Application Best Practices (PABP) now is being adopted as a new security standard, which will be known as the Payment Application Data Security Standard (PA DSS). Though the PA DSS is aligned closely with PCI DSS, it will be maintained as an entirely independent standard. PA DSS applies to all applications that are used to process, transmit, and store cardholder data as part of payment and authentication processes, including shopping carts and back-end payment applications.

To help merchants make certain they're using applications that are PA DSS compliant, the PCI Security Standards Council will be creating a list of PA DSS qualified security assessors, and later this year validation of all applications covered by PA DSS will begin. The important thing is to make sure that the providers of your payment applications and shopping carts are certified or are on the path toward PA DSS certification.

This may sound complicated, but it's really not. What the PCI Security Standards Council is asking is that all web applications be developed based on well-founded secure coding practices, and that they be maintained securely once they are facing the public Internet. That's how we all should be managing our web applications already.

 

 

 

 

 

 

 

 

 

Share this article:

Sign up to our newsletters

More in Opinions

An IT lens on data breach response

An IT lens on data breach response

This heightened awareness regarding data breach response time has created an interesting dynamic for security professionals.

Ensuring your developers love - or at least don't hate - security

Ensuring your developers love - or at least ...

The relationship between development and security doesn't need to be hostile, and there are ways to engage developers more with security.

Backing diversity lowers the bar?

Backing diversity lowers the bar?

Many groups have striven to cultivate a more welcoming workplace, says Alison Gianotto.