If the likes of Netflix, Spotify & Twitter can go down what does that mean for my organisation?

So Netflix was down....that's a big deal, how does this relate to my organisation? If nothing else, the events over the weekend and the past 12 months should act as a reminder to have a discussion with your executive team about your current security posture to specifically understand:

  • What the impact and cost would be for your organisation if you were a casualty of a DDoS attack?
  • How much down time you would have until your organisation could restore normal service?
  • What actions can / could / should you be taking now to avoid a DDoS attack?

In our second blog of this two part series we're laying out what steps you can take to prevent your organisation being comprised by a potential attack.

Year after year, DDoS attacks increase in size, complexity, and frequency according to research published by Arbor Networks in July 2016. The security appliance firm recorded an average of 124,000 DDoS events per week over the prior 18 months. At 579 Gbps, the largest known attack of 2016 was 73% larger than the 2015 record holder. Mind you in our experience, 1 Gbps is enough to take down most networks today. Unfortunately there’s no real ‘silver bullet’ to the casualties of DDoS attacks. However unlike the 'Millennium Bug', DDoS attacks are very real and on the rise.  So, expect the Worst! If you care enough about your brand to protect it, then there are people out there that will pay to see that brand tarnished;

  • Hackers launch DDoS attacks for sport.
  • Competitors can do it to hurt your business.
  • Hacktivists use them to further a cause and as identified above extortionists even use DDoS attacks to hold web services for ransom.

So how can I protect my organisation from a potential DDoS attack?  In theory, the task is simple: create an architecture/system/infrastructure that can absorb and survive DDoS attacks. In practice as evidenced by this most recent attack, DDoS defence is difficult as one has to distinguish between legitimate and illegitimate sources of traffic -- and we all know that cyber security budgets don’t grow on trees.

Your security action plan should address all types of DDoS attacks, no matter who perpetrates them. Whatever you do though, do not sacrifice your end users to cyber security paranoia. We genuinely believe it's a fine balance and that organisations should take proactive measures -  we suggest working with a security specialist to create a plan so that you're ready to appropriate react if/when you are attacked rather than suffer an attack and throttle the business you sought to defend/protect.

With this in mind, we recommend the following course of action:

Set traffic thresholds. If your marketing and ops team are up to speed you should 100% be tracking how many users visit your website/app per day, per hour, and per minute. This means as an organisation you should have a good handle on your average traffic levels and, hopefully, you’ve recorded how special events such as press releases and/or sales campaigns affect visitor numbers. Based on these numbers, you should set thresholds on your infrastructure that automatically flag abnormal traffic to your CIO / security team / Cloud Managed Service Partner. If you expect 1,000 visitors per 10 minutes, an influx of 5,000 visitors over one minute should definitely trigger your alert.

Build your underlying Cloud infrastructure for Scale. Use auto scaling groups. To complement traffic thresholds businesses need to build the underlying infrastructure with scale in mind. This can be achieved in many ways but your critical Web applications and websites strong have the ability to withstand traffic surges, there are cost effective ways to have sites handle 100k simultaneous visitors, but most sites fail after 1000 concurrent visitors. Ensuring a higher tolerance for simultaneous visitors makes you less likely to be the target of opportunists and amateur extortionists.

Blacklist. A tried and true method, businesses need to control who can access your network and APIs with whitelists and blacklists. However, you do not want to automatically blacklist IP addresses that trigger alerts. You are almost guaranteed to see false positives, and overreacting is a sure way to infuriate good loyal customers. With this approach, we suggest temporarily blocking traffic and see how it responds. Legitimate users usually try again after a few minutes and or contact your support team. Illegitimate traffic tends to switch IP addresses.

Content Delivery Networks. The best defence against DDoS attacks is a security strategy that includes a content delivery network (CDN) such as CloudFlare or Redshield. They can identify illegitimate traffic and divert it direct to their cloud infrastructure. Unfortunately CDNs aren’t cheap and a typical plan will cost up to five figures per month. Or, if you pay per incident, you may be up for a six-figure bill for one attack. Most organisations either can’t afford a CDN or don’t have a platform that warrants such high security. If, for instance, your business has an informational website where no one makes transactions or uses services, you don’t need a CDN. You’re not a prime target. An application or network firewall might be enough to prevent abnormal traffic. If a DDoS attack takes you down, it won’t harm customers or your reputation. The most cost-effective way to defend against a potential DDoS attack is to deploy more servers when you detect suspicious activity. In a public cloud infrastructure this is easily achievable and can be automated. We should point out here that that this is the least reliable method but still better than nothing. Remember, there is no end to the amount of money you can throw at security. Depending on your budget and risk tolerance, choose the right option for your service desk.

Automate Communication with Customers. When a DDoS attack succeeds, you don’t want your service desk buried in emails, phone calls, social media posts, and chat ops (slack etc). Create a prebuilt status page that automatically displays whether your service is up or down.  It’s also a good idea to create DDoS communications templates that you can auto-send to end users who you’re in direct contact with. These templates could cover any interruption to service, not just DDoS attacks. Keep it simple with something like: "Thank you for contacting [your organisation name]. Our platform is currently down. We are working as quickly as possible to restore service. We will post updates on our status page [hyperlinked] as soon as we have more information".

Incident Reporting and Root Cause Analysis. If/when you suffer an attack (DDoS or otherwise), you need to work to re-establish credibility with your clients and the market immediately. Draft an incident report explaining what happened, why, and how you responded. Then, discuss how you will prevent future attacks. If you contracted a CDN, for instance, discuss how it works and how it will deter future attacks. Open the report with simple, non-technical language. You can add a technical section for CIOs, CTOs, and others who would appreciate the details.

Practice for Attacks. Simulate DDoS attacks in pre-arranged change control windows to gauge how your action plan works. You should not provide your DevOps and the service desk warning to make the simulation realistic. If you have a CDN, you can warn the provider, or not. Obviously if you pay per incident, coordinate tests with the CDN provider as they too have a vested interest in proving the security posture.