The Clock Is Ticking For Retailer Web Application Security

In a few months time, what is now considered merely an advisable best practice will become mandatory for any business accepting credit card payments over the Web. Problem is, the mandate is ill conceived.

2 Min Read
Dark Reading logo in a gray background | Dark Reading

In a few months time, what is now considered merely an advisable best practice will become mandatory for any business accepting credit card payments over the Web. Problem is, the mandate is ill conceived.At the end of June, section 6.6 of the Payment Card Industry Data Security Standard (PCI DSS) goes into full effect. In short, this section of PCI DSS requires merchants and card payment providers to make certain their Web applications are secure.

If done right, it could actually help curb the number of Web-related security breaches.

But it's not done right. Not yet.

Here's section 6.6, which goes from a nice-to-do, to a must-do, on June 30:

"Ensure that Web-facing applications are protected against known attacks by applying either of the following methods: -- Having all custom 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"

Now, the overarching point of the PCI DSS is to both help instill a sense of trust among consumers in e-commerce, especially when it comes to online payments. And, hopefully, actually increase the Web security of online merchants, which until a couple of years ago remained ridiculously pathetic. Today, the state of retail security is just pathetic. So there's been some improvement.

In fact, the Privacy Rights Clearing House maintains a chronology of breaches here. It's a long list, and may take awhile for those with slower connections to load, so I don't recommend anyone using a dial-up connection to click the link. To date: 218 million data records have been exposed.

A few years ago, most of the breaches were caused by criminal hacking. Today, many breaches also are caused by the loss of laptops, thumb drives, and other forms of removable media. Yet, there's still a healthy number of criminal hacks, and sloppy Web and application design to go around.

And that's where section 6.6 steps in. And while I agree with the spirit of 6.6, which is better Web code, it's flawed as it's currently written.

It pretty much says that retailers can either perform a custom code assessment, or deploy a Web application firewall.

I'd much rather have PCI DSS mandate a security assessment be performed on all custom (as well as all commercial software before it's allowed to be shipped). Then, secondarily, advise the deployment of a Web application firewall.

As it stands now, retailers can build shoddy code, skimp on Q&A, and toss a Web application firewall in front of their ill-crafted code and claim compliance.

That's just not good enough.

And it's one of a long list of reasons why the list of breaches kept by the Privacy Rights Clearing House will continue to grow ... .

Read more about:

2008

About the Author

George V. Hulme, Contributing Writer

An award winning writer and journalist, for more than 20 years George Hulme has written about business, technology, and IT security topics. He currently freelances for a wide range of publications, and is security blogger at InformationWeek.com.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights