The Trustwave Spiderlabs team frequently responds to E-commerce data breaches. The number of website breaches that we are working continues to rise. There are a handful of reasons for this rise.
- We are approaching saturation in the "brick and mortar" Point of Sale breaches. Attackers have been after these systems very aggressively for the past few years. They're not going to stop stealing, they are just going to find new targets.
- It's getting easier. There are some very sophisticated scanning tools on the market that are either free, cheap or already pirated by attackers. These tools are incredibly efficient at pinpointing and exploiting website vulnerabilities. We see Havij and SQLmap on a weekly basis.
- The payoff! E-commerce sites are still storing large databases full of personal information and cardholder data. The black market for this information is well established and an attacker can easily monetize what they steal. It's not unusual to see 50,000 - 100,000 records in an E-Commerce database. The sale price of a data record can vary from a few dollars up to about $25 per record. That's a lot of money!
There are several steps that website admins/programmers can take to help avoid these breaches. Here's my list of the top 5:
- STOP STORING SENSITIVE DATA! There is no good reason to store thousands of records on your customers, especially not their full credit card numbers, expiration dates and CVV2 codes. Modify your code, stop storing this data and purge the old records from your database. A minimal amount of data is necessary for charge-backs and refunds, the risk of a breach outweighs the convenience for your customers at checkout and the storage of this data is strictly forbidden by the PCI standards. This is one of the PCI areas where there is no guessing or discussion. Section 3.2:"Do not store sensitive authentication data after authorization (even if encrypted)." It's also a terrible idea. If you have nothing to steal, you won't be robbed.
- Don't host multiple sites with your main E-Commerce application. Running an auction site, blog or user forum is a great way to increase traffic and sales. I don't discourage this activity at all. Just segregate it from your main site. I'm working a string of cases right now where the initial point of breach is Wordpress and its associated plugins that are running on the primary E-Commerce server. Additional hosting fees or the cost of launching a VM to run these secondary sites is trivial compared to the costs associated with a breach. (Investigation, fees and fines, legal counsel, etc..) Move that stuff off to a seperate server and decrease your attack surface.
- Patch your systems. This is good system administration 101: I constantly run into breached sites running a 3 year old version of PHP or ColdFusion from 2007. The same thing goes for your web apps, Xcart, OSCommerce, ZenCart and any of the others all need to be patched regularly.
- PenTest. There is a cost involved with this, but the return on investment is very high. A penetration tester will run the tools that a hacker will run, they will identify the vulnerabilities in your site and a good one (see Spiderlabs) will guide you in correcting the problems. You could purchase roughly 2 years of penetration tests for the cost of having us on-site for a week to work a breach.
- Install a Web Application Firewall. This is a technology that has really matured in the last few years. There is no "magic bullet" to prevent a breach, but a WAF is a really good start to a comprehensive approach. The best part? Modsecurity is free and supports all of the major web servers (IIS, Apache, Nginx). It's not as effective as Trustwave's WebDefend product but it's pretty darned good. WAF's watch inbound HTTP requests to your site for SQL Injection strings, RFI attempts and known exploits. If it is installed properly it will stop this traffic before it even makes it to your server.
There you have it! Five common sense ways to help prevent a breach. 4 of the 5 are even free.
Make the investment in time and capitol, you don't want me or any other member of the IR team working for you if you can avoid it. Breaches are a terrible thing.