DDoS happens. It happens quite a bit. It will continue to happen. Information on how to prevent DDoS is readily available, but information on how to survive is missing. DDoS is an outage. Do you have a business continuity plan that covers this sort of outage? Does your business close for the day, or do you keep running in a reduced capacity? Or do you run at full capacity? Do you have multiple approaches to your business? Do you use a variety of services?
Data protection is often about protecting your data, which generally includes backup, replication, and storing your data in multiple places for easy access. However, data protection also includes business continuity. Continuity is needed not just for loss of data, but also for loss of services. One case in point happened while I was at a conference in San Francisco:
The payment processor for Starbucks went down. The result was widespread, as many Starbucks shops closed their doors and stopped serving up coffee and other refreshments. However, not all did: one instead took only cash. Another went back to the old way of handling credit cards.
The stores that didn’t close had a business continuity plan. The one that took only cash was right around the corner from an ATM, so its solution was to send folks there to get cash if they needed it. Both did a booming business, as no other stores in the area were open. What is critical to a coffee shop is not always critical to a normal business, but one thing is critical: access.
The recent DDoS attack took out a critical component of the internet: domain name service (DNS). This controls how to access services by name instead of by address. Most applications use DNS to help route traffic. This is why, when DNS goes down, it looks like the network is no longer around. It still is, but we do not know how to reach it. It is, after all, just one more service we use.
That is the crux of the matter: we use services without really thinking about the impact of their failure. Or more to the point, what to do if we can no longer access those services.
What happens if you lose that access? Do you fall back to a different access path? Do you use a different service? Perhaps, for example, you use Google BigQuery and fall back to AWS Lambda or Microsoft Insights. Or perhaps you use multiple DNS providers, or even DNS caching. Lastly, you may wish to use direct addressing for some of the more critical services as a fallback plan.
The goal is to allow your customers to access your services and your business to continue to function. We need to think outside the box to come up with solutions to potential threats. We know the attackers are thinking outside the box. We need to do so as well. This starts with business leaders, architects, developers, operations, and even knowledge workers. Everyone is involved in keeping the business running. Even the idea that seems the most uninteresting could be a legitimate solution to the next big attack.
Should the issues be fixed at the source? Of course. Many articles out on the net talk about this. However, will such fixes be available in time? I seriously doubt it. The last DDoS attack was targeted very carefully. The real question is how you plan to survive such attacks. Some of those answers are technical; others are about process.
In our example of Starbucks, a process change was implemented to handle the outage. In the case of the latest DDoS attack, there should be a technical answer. That answer is to rely on not just one DNS service, but multiples, and to ensure that failover works as necessary. You may go so far as to use a local cache that pulls from multiple DNS services. This way, if one goes down, the other takes over the load, and if both go down, the cache is there for existing services. New services may need other mechanisms. We may also need to stage or seed our data into multiple clouds. This way the clouds are ready to pick up when there are service outages.
Thinking business continuity? Think what will happen if you lose access to those critical cloud services. If anything, this is what the latest DDoS should be teaching us.
Share this Article:
Latest posts by Edward Haletky (see all)
- Common Product Security Questions - November 23, 2016
- Sorry Support: Not Getting My Data - November 18, 2016
- Moving to the Future: Strategies for Handling Data Scale - November 14, 2016