'Nice Internet You've Got There... You Wouldn't Want Something To Happen To It...'

from the this-is-no-longer-theoretical dept

Last month, we wrote about Bruce Schneier's warning that certain unknown parties were carefully testing ways to take down the internet. They were doing carefully configured DDoS attacks, testing core internet infrastructure, focusing on key DNS servers. And, of course, we've also been talking about the rise of truly massive DDoS attacks, thanks to poorly secured Internet of Things (IoT) devices, and ancient, unpatched bugs.

That all came to a head this morning when large chunks of the internet went down for about two hours, thanks to a massive DDoS attack targeting managed DNS provider Dyn. Most of the down sites are back (I'm still having trouble reaching Twitter), but it was pretty widespread, and lots of big name sites all went down. Just check out this screenshot from Downdetector showing the outages on a bunch of sites:
You'll see not all of them have downtime (and the big ISPs, as always, show lots of complaints about downtimes), but a ton of those sites show a giant spike in downtime for a few hours.

So, once again, we'd like to point out that this is as problem that the internet community needs to start solving now. There's been a theoretical threat for a while, but it's no longer so theoretical. Yes, some people point out that this is a difficult thing to deal with. If you're pointing people to websites, even if we were to move to a more distributed system, there are almost always some kinds of chokepoints, and those with malicious intent will always, eventually, target those chokepoints. But there has to be a better way -- because if there isn't, this kind of thing is going to become a lot worse.

Filed Under: attack, ddos, dns, internet, vulnerabilities
Companies: dyn


Reader Comments

Subscribe: RSS

View by: Time | Thread


  1. icon
    sigalrm (profile), 21 Oct 2016 @ 3:10pm

    Re: Re: Re: Re: Nerd Harder!

    here's a more solid start, based on use of MITRE's CVE system.

    Assume Samsung is selling IoT enabled toasters, because why not. Everything's better with a network stack. Anyway, MSRP on this toaster is $100usd and Samsung releases the product Jan 1, 2017, and ships 1000 toasters.

    Now, if there are no open CVE's on any component of the IoT stack on this toaster in the 90 days before Samsung ships, they're effectively insulated from liability. Oh, and in that world, the sky is Fuscia.

    But, If there _is_ an open CVE was announced >= 90 days before Samsung launches the product, _and_ it gets exploited, Samsung is the hook for 5% of the MSRP for each unit sold of said product for every 90 days of age on the CVE.

    Example: Samsung begins selling their IoT enabled toaster (MSRP == $100usd) on Jan. 1, 2017. And they sold 1000 of them on day 1. Said toaster has a vulnerability that was announced on Aug. 15, 2016 (just outside the 90 day grace period). If one of these toasters gets exploited and causes trouble, Samsung is going to write a check for (5% of $100) == $5 for each of the 1000 toasters sold as of the date of the CVE being exploited, plus the same fine going forward for each non-patched unit they sell.

    Now, pretend that vuln wasn't released on Aug. 1, 2016, it was release on Aug. 1, 2016. Same ship date, same quantity. Except now instead of 5% per toaster, it's 10%. Add 5% for every 90 day interval of CVE age. Also, allow the total penalty per unit to exceed 100% of MSRP with no upper bound. So, you release an IoT enabled toaster with a 12 year old ssh vuln, and it gets exploited? assume qty 4-90 day periods / year to make it easy, now your penalty is (48 * $5) = $240 * 1000 = $240k in fines for each $100MSRP toaster you sold.

    And why use MSRP as the basis for the penalty? Well, because it's both easy to validate and publicly verifiable.

    No grace period, no appeal, cut a check to a high school to fund a secure coding class, because CVE's are public and theres no way the organization "couldn't have known".

    Oh, and multiple CVE's? 5% per CVE, and scale it out.

    If you can verifiably patch these toasters 100% then you restart the clock from the time the patch was pushed to the toaster. If you can't patch them, well, eventually you'll get to write a check big enough to make the board pay attention.

    Bonus: Specifically disallow said penalties as a loss for tax purposes.

    As to your other question: It's a Samsung toaster running a google code, Samsung pays. It's their label. If Samsung wants to go back and fight it out with Google based on contract terms, that's fine, Samsung can attempt to recoup their (already paid) losses from Google.

    (yeah, I know. There's no chance this or anything like it will ever happen.)

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Follow Techdirt
Techdirt Gear
Shop Now: I Invented Email
Advertisement
Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Advertisement
Report this ad  |  Hide Techdirt ads
Recent Stories
Advertisement
Report this ad  |  Hide Techdirt ads

Close

Email This

This feature is only available to registered users. Register or sign in to use it.