Wow. My head is spinning. Every week there’s a new breach.
This week, Peloton got caught asleep at the wheel and had to bow before the all-powerful Tech Crunch community (in addition to President Biden). This individual breach is not, however, what befuddles me. What’s so striking to me is that in the midst of accelerated scraping attacks, many of the API professionals I work with are so preoccupied with DDoS protection that they haven’t spent any time thinking about scraper mitigations. Many don’t even know what a scraper is, much less how to detect one.
Just last week, a colleague spoke about an equipment rental company that launched an API that was “the target of a DDoS attack” two days after launch. The predictable playbook responses (e.g., getting rate limiting policies and edge protection) were in motion — out of curiosity I asked, “Do you know if it was a true DDoS, a basic DoS or just a scrape?” This is where the story gets interesting for two reasons: 1) DDoS might be the wrong diagnosis and thus they might be working on the wrong solution. 2) None of the parties involved had any clue what I was talking about.
In this two-part blog series, I’ll break down each of the common robotic attack types along with the concepts and tools enterprises need to mount a sustainable defense.
If you don’t know, now you know
In 2019, Gartner predicted the current phenomenon stating: “By 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.”
While MuleSoft and the software community at large has rallied to address this, there lacks a sufficient understanding of:
- The differentiated nature of attacks
- The motivation of the attackers
- The options enterprises have to address the attacks
- The business architecture efforts needed to complement the technology-based mitigation strategies
With this context in mind, I’ve captured a rogues’ gallery of different attack patterns to help enterprises make productive choices in their effort to protect their infrastructure, data assets, and keep their digital reputations safe.
Bad actor # 1: Denial of service attacks (DoS)
Often confused with distributed denial of service (DDoS) attacks, plain DoS attacks are simpler in terms of sophistication and in response techniques. DoS attacks are when a bad-actor points a robot at your API (or any web-based system) and makes a series of repeated requests at an endpoint for a significant duration of time at a very high frequency. The barrage of requests exceeds the target’s capacity to respond, which renders it unable to respond to good actors.
If a DoS attack is what you’re concerned about, edge protection and WAF (web application firewall) products are reasonable choices. The basic features of a WAF (like IP and geo-blocking) are sufficient to detect a high-speed robot and block it from making more requests.
Some organizations use elastic capacity from cloud providers to mitigate the effects of a DoS attack where the infrastructure capacity expands to carry the additional request load coming from the DoS bot. There are a few additional tweaks like blocking certain classes of user agents (e.g. browser types), which can fend off the DoS attacker when taken together, without suffering any significant loss of business.
There is, however, a problem with this strategy — bad actors don’t stay static. Once they see that you’ve blocked them, their attack morphs into different patterns (e.g. DDoS) to circumvent your mitigations.
Bad actor # 2: Distributed denial of service attacks (DDoS)
Distributed denial of service (DDoS) attacks bear the brunt of name recognition. As the most famous “big bad,” any instance of a robotic attack is labeled as a DDoS whether they meet the criteria or not. DDoS attacks are scary because of how hard they are to defend against. One clue to understand how hard this is, is when you see the WAF vendors admit defeat when they refer to their capabilities as “mitigations” rather than solutions. When the WAF vendor says “mitigation,” what you should hear is “this might help to some degree… but, don’t get your hopes up.” This is because current mitigation technologies can’t block the bad actors without blocking good actors as well.
A DDoS differs from a DoS in that it is made up of multiple robots, from separate IP addresses and locations that coordinate their high frequency attacks — circumventing the main DoS mitigation; IP blocking. With your real attacker hiding behind a VPN, they can rotate the IP sources for their hordes of robots and suck up your capacity like a sponge. Geographic blocks can work to some degree here, but still have some shortcomings when it comes to DDoS protection:
- Spreading the geographies: The attacking robots are virtual in nature, which means that they can be launched from anywhere. In the case that your attacker spins up dozens of robots from multiple locations, you’ll need to block multiple geographies, which brings us to shortcoming #2.
- Collateral damage: Geo blocking, unlike IP blocking, covers a wider area than a single IP. When you block a region of the globe from making a request to your system, you don’t just block the bad actors in that area, you block everyone from that area, including your partners, customers, and prospects.
When a true DDoS comes knocking, you have my sympathies because there’s not much you can do beyond paying for elastic capacity and playing whack-a-mole with your WAF and cloud-based regionalization strategy. Before panic sets in, there are two factors here that can help your organization amidst the chaos:
- DDoS attacks are typically not sustained for very long (the average DDoS lasts under four hours).
- Elastic capacity essentially means that you can mitigate the effects as long as you can afford the cloud usage bills.
Robotic disruptions don’t always call for robotic responses
A key point to remember in either the DoS or DDoS scenario is that the primary motive of the attacker is to disrupt your operations. As long as you can absorb the request load, you can prevent them from achieving their goal (but not without expense).
In part two of this series, we’ll shift our focus from the robotic hordes aimed at disrupting your enterprise to the sly scrapers intent on profiting from your data. Strap in and bring your data governance team and business partners, because the disruption is just starting.
To learn more about how to defend your enterprise from attacks with an application network, download our Security by design whitepaper.
