Unfortunately, with those so-called "low and slow" attacks—which require a lot less firepower from attackers but can still crash your site—brute-force DDoS defenses won't work. Your E-Commerce and network security teams may need to take a lesson from associates and loss prevention in thinking about online defense.
There are still plenty of brute-force attacks. Security vendor Prolexic said in a quarterly report released on Wednesday (Oct. 17) that the total number of DDoS attacks hitting its customers was up 88 percent from a year ago, although the average attack length dropped to 19 hours, from 33 hours last year. Average attack bandwidth more than tripled, to 4.9 Gbps, but some attacks ran much hotter. And attacks that averaged 20 Gbps are no longer uncommon, Prolexic reported.
In other words, defending against those attacks requires stronger defenses against shorter attacks. That's easy enough for most security teams to grasp. It's just one more iteration of the firewall and security-appliance arms race.
But the new rise in low-and-slow attacks? That's going to require rethinking your strategy.
Case in point: the "basket stuffer" attack, in which the attacker writes a script that puts as many items as possible into a shopping cart. Eventually, that's likely to bring the shopping-cart system to its knees.
"Adversaries don't even have to know why the attack works," said Andy Ellis, chief security officer at Akamai. "They can guess that programmers will assume there will never be more than 20 or 30 items in the basket." Stuffing in hundreds of items? That by itself may overrun the cart's allotted space.
If that doesn't do it, there's also the processing that has to happen for each item—beginning with saving the state of the cart after each item is added. Then there are all the nice elements you've added to make your site more interactive. "Business rules can bite you," Ellis adds. "Every one has to process every time." Recommendation engines are triggered, loyalty information is collected, and all that chews up processing power. The faster items are added, the more CPU time is chewed up—and the more likely it is that processes will stumble over each other. "It's all about causing you to use resources," Ellis says.
One way or another, if an attacker successfully stuffs hundreds of items into a shopping cart fast enough, it will fail.
Best of all, from the attacker's point of view: The attack is invisible.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.