Let’s Stop Talking About the ‘Largest’ DDoS Attack
There have been a slew of DDoS attacks recently that are serious, but to focus on the size of the latest attack is the wrong thing to do. What we need to focus on are the impacts of these attacks. Would the CFO consider the site being down for less than an hour to be of material impact to the company? Would the head of compliance need to report it?
First, a quick reminder of what we are talking about. As we see articles about DDoS attacks breaking the latest record, here is how the categories tie to attack methodologies:
• RPS (requests per second) = Overwhelming web infrastructure (Layer 7)
• BPS (bits per second) = Overwhelming bandwidth or clogging internet pipes (Layer 3/4)
• PPS (packets per second = Overwhelming hardware/CPU
• QPS (queries per second) = Overwhelming DNS infrastructure (Internet GPS broken)
Each of these has its own records and needs a different solution to protect it. When you are talking about risk, most organizations break out web, infrastructure and DNS as separate areas to gauge DDoS risk.
What the DDoS Attack Did
What we need to focus on is what the DDoS attack did. For example–Google Cloud Platform (GCP) had a customer hit with 46 million RPS. New record–SO WHAT?
• Duration of attack – 69 minutes; the peak only lasted a few minutes.
• Speed to achieve peak – Low level jumped to peak in 10 seconds
• Impact – Low impact
So, we are actually talking about an incremental increase in attack capability (I use ‘incremental’ because the attack had a low impact). While it is important to track threat capabilities to make sure our security controls are able to handle the latest attacks, there is no reason to alert the company’s leadership about the latest record.
Focus on Lessons Learned
That said, there are some lessons we should learn from this attack. First, we need to look at the size of the attack. Then, based on our risk tolerance, we need to determine what factor we want our protections to be able to handle. Someone with a low-risk tolerance should consider a minimum of two currently published attack peaks. Additionally, you need to plan for future growth – something like 10% a quarter. That way, when there are jumps in threat capability, your controls will be best prepared to handle them. Most of this is much easier in a cloud-hosted environment–scale is easier to adapt to quickly keep up with evolutions in attack capabilities.
Next, we need to focus on the time the attack took to achieve maximum impact. If your current solution requires someone to take an action, then you need to look at the risk associated with estimated downtime while decisions are made and for actions to be taken. At Akamai, we have seen attacks reach peaks in minutes, so if you need 30 minutes to get DDoS protections in place, you are accepting 25 minutes of impact in a best-case scenario.
Finally, we need to think about the process. Do we want to keep this in-house, leverage our cloud provider/ISP or get a DDoS protection service? Most leverage a third party, which means we need a playbook to manage it. As with all playbooks, we need to make sure that they are up-to-date. And you should perform periodic reviews to make sure sections like points of contact are correct and that exercises to validate the plan work.
Conclusion
DDoS extortion has been around for a long time. We also have industries that are part of the collateral damage from the Ukraine war. With DDoS-as-a-service making these attacks easier than ever, the threat capability growing through bots made up of IoT-connected devices and poorly secured systems, more remote workers, more revenue tied to online capabilities and auditors asking questions about resiliency, we must think about the impacts of DDoS–but we also need to stop talking about the latest record.
