andrewmitchell

I think you're right that losing access to Github is a serious problem. I'm worried that an attack like this could be used in conjunction with some zero-day. Imagine a bunch of distributed teams trying to deploy a fix to the next rails zero-day yaml parsing RCE with GitHub and slack down.

There's a very strong argument to be made that regulation is the only way to improve this situation. A negative externality like this is unlikely to correct itself. Cheap manufacturers will continue to save money by cutting security features, and unaware or price-driven consumers will reinforce that behavior. What else can we do?

Note: this isn't something the US can solve. A lot of this traffic came from overseas. It's needs a coordinated response.

I found a really really stale name server that didn't respect TTLs.

I can understand the instinct to move, but I think the answer is to split your eggs among many baskets, not just pick a sturdier basket. I don't think the Dyn team is necessarily bad, it was an enormous assault.

I'm sure a lot of people were unscathed by this event, but it appears to be more of a warm-up than the main event. I think it demonstrates the likelihood of further attacks and the possibility that those could have far-reaching consequences. You're right that the title is sensational, but I do believe the threat is daunting.

Good point! We are working through the details of those sorts of use cases, and are thinking of ways to mitigate the risks posed. A lot depends on the characteristics of your particular background tasks, but here are a few ideas we’re considering:

- Grant background tasks limited access to data based on some applicable filter. Imagine your medical software sends a nightly summary of tomorrow’s appointments. Instead of giving the background task access to the entire database (including patient names and medical histories), grant it access to summary data about appointments which occur in the next 24 hours. In this example, there is still sensitive data at risk, but the scope is limited.

- Have temporally limited access for scheduled tasks. Can we scope them to only running for 30 minutes once a day?

- As a matter of practice, only run these types of jobs on machines that are isolated in a tightly controlled private network with an absolutely minimal attack surface.

We’re still working out how to express some of these scoping restrictions in practice, but the core idea here is that we should be able to mitigate overall risk by being more judicious about how we grant access.