Evan Schuman's StorefrontBacktalk

Best of all, from the attacker’s point of view: The traffic required to bring down a shopping cart is invisible to monitoring systems designed to spot brute-force attacks.

It’s not just shopping carts, adds Stuart Scholly, president of Prolexic. Anything that causes a database lookup or triggers a script will work as a high-leverage attack: product searches, repeated logins (whether they’re valid or not) and running videos, for example.

From the point of view of legitimate customers, it doesn’t look like the site is under attack—just that it has slowed to a crawl, presumably because the retailer doesn’t know how to run an E-Commerce site. And if attackers can identify how an E-Commerce site is communicating with its payment provider and interfere with transaction confirmations, customers can be left in limbo.

Think of how Target’s new site collapsed in the face of a huge amount of traffic on Missoni Tuesday last year—except instead of being triggered by huge sale crowds, it’s from malicious scripts fired off from a handful of attacking servers.

And the more effort your developers have put in to create a rich E-Commerce experience that leverages lots of CRM data, the more processing power each new item in the shopping cart requires—and the harder a low-and-slow attack is going to hit you.

What can you do? You can’t rip out and rebuild your whole E-Commerce system. Fortunately, you don’t have to. But you will have to get your E-Commerce developers out of the mindset that network security will spot and handle all the DDoS attacks.

What E-Commerce developers have to do is write code that watches for suspicious signs: items added too fast to a cart, a customer who is suddenly starting multiple videos or launching product searches unrealistically fast, or really anything causing an error. “If a user’s requests are causing problems, you can rate-limit that user,” says Akamai’s Ellis. Or do user validation: “When you see ‘interesting’ things, you can throw in CAPTCHAs to make sure it’s not a script.”

That may be something E-Commerce developers do themselves, but they’re probably better off handing the questionable “customers” off to the security team to throttle back the ability to click. (This could have the interesting result that the site’s responsiveness really does slow down—but only for the attacker.)

Besides, it’s really security’s job to deal with attackers, both brute-force and low-and-slow, while developers think about real customers—something like the way in-store associates focus on customers while LP watches out for theft.

And that’s where the LP lesson comes in. The jobs of associates and LP are unquestionably different, and it’s not an associate’s responsibility to handle thieves.

But when they need to, they can still talk to each other. That’s not always the case with developers and network security. From now on, maybe it had better be.