If DDOS Attacks are Natural Disasters, is it Time to Update your DR Plan?

Published: 2016-11-04
Last Updated: 2016-11-04 16:00:26 UTC
by Rob VandenBrink (Version: 1)
2 comment(s)

5 years ago, I posted a story on the Eastern Seaboard power outage of 2003 (https://isc.sans.edu/forums/diary/8+Years+since+the+Eastern+Seaboard+Blackout+Has+it+Been+that+Long/11374/ ).  In that story I mentioned that we can't seem to help but have a large power outage every 10 years or so - the conclusion being that we shouldn't take a multi-day widespread power outage off the table for DR / BCP (Disaster Recovery / Business Continuity Planning) - we never seem to get the infrastructure 100% right.

I think it's time to take that conclusion and expand it - time to add a new threat to our DR plans.

We've always had DOS and DDOS in our plans - folks tend to multi-home for that, or buy a DDOS service from their ISP.   Newer approaches might include implementing Flowspec to help set PBR parameters upstream on suspected attack traffic (stay tuned on this BTW).

However, what we're seeing now, with the Mirai related DDOS events, is that the target of the attack is the upstream providers - Dyn for instance.  Or in the case of krebsonsecurity attack, that targetted attack affected the provider (akamai).  
What we're seeing now is that DDOS attacks are getting large enough to affect large providers and all of their clients- there are precious few providers who can sink a multi-GB attack without affecting their customers.  In the case of the Dyn outage, folks who had an alternate DNS provider for their server records were able to flip to that provider and recover fairly quickly.  We need to think of DDOS events as natural disasters like hurricanes, floods or ice storms.
I think what we need to start planning for is attacks that don't target us directly - most organizations will be just collateral damage in most DDOS attacks going forward.  Maybe we can call it "blast radius" planning - where if we're in the blast radius of an attack, plan on moving our organization to another provider, hopefuly outside of the spatter range?

Eventually though, as an industry we're going to have to find ways to deal with this at the core.  Flowspec has some potential here, where provider A could tell provider B that "this particular set of indicators identifies an attacking flow".   As implemented today though, flowspec tables fill up muc to quickly to operate between providers, or against Mirai sized attacks.

What we really need is a method of taking the costs out of cooperation.  Right now, if ISPs were to put together formal ways of combatting attacks like this, it's a direct impact on profit.  Nobody is really incented to "fix" attacks like DOS or DDOS - the incentive is to either sell more bandwidth or sell a DDOS mitigation service.  With ISP margins so slim these days, spending money with no direct return doens't get a lot of air play with Sr Management.  I'm not sure that pulling governments into this is helpful (in fact I'm pretty sure it'll hurt more than help), but

Maybe I'm being fatalistic - what do you think?  Please use our comment form if you've got a happier spin on this?

===============
Rob VandenBrink
Compugen

Keywords:
2 comment(s)

Comments

https://datatracker.ietf.org/group/dots/charter/

.pdf presentations:

https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq

https://app.box.com/s/pxdectifypevcvcyu1mm3fncvpv1mum4

There is and always has been a high degree of inter-operator cooperation in mitigating DDoS attacks, FYI. DOTS is intended to make it much easier to do via automation.

I've been using the DR/business continuity analogy with regards to DDoS attacks for many years, and it's a good one.

I don't know why the comment system insists on labeling me as 'Anonymous' - I'm Roland Dobbins of Arbor Networks. ;>
Excellent, thanks for the links !

Diary Archives