Denial of Service Attacks: From Bandwidth to APIs

Edward G. Amoroso, SVP & CSO, AT&T

In the months leading up to the Millennium change, the Clinton White House was developing a comprehensive fusion center in Washington, DC to monitor the Y2K transition status of IT systems around the world. The idea was that domestic and international groups would willingly provide real-time information about their computers and software to the Y2K center via e-mail or the Web. This information would then be fused and reported to the President and the American people. Podiums with official logos were set up in front of the center floor so that news channels could cover these status briefings on television.

An interesting security challenge soon emerged, when someone noticed that a so-called zombie net–today, you would refer to this as a botnet–might be used to clog up the communication networks supporting the center’s e-mail and Web servers. Cyber Security experts were brought in to examine this denial-of-service risk, and a number of security risk mitigations were examined (and eventually tossed).

Sadly, the most practical solution to be adopted involved nothing more than having system administrators stand ready to reboot servers if an attack ensued–and luckily none did. Experts felt lucky to have avoided catastrophe, and the security community immediately began to conceptualize solutions using Internet management protocols such as the Border Gateway Protocol (BGP). However three months after Y2K, several major e-Commerce sites including eBay saw the world’s first truly consequential denial- of- service attack, and the rest is cyber security history.

“The reason virtualization, cloud automation, and SDNs are so relevant to cyber security is that APIs have now become the new communications channels for cloud replacing traditional IP networks”

Today, we have a new security challenge–and it is called cloud. For the past few years, experts have been debating on the best ways to manage risk in virtualized data centers and Internet-facing public clouds. Luckily, a broad consensus is emerging through strong authentication, proper end-to-end encryption, and comprehensive activity monitoring; private data can be highly protected virtually in the cloud–perhaps even exceeding the security levels of enterprise perimeters.

Interestingly, the cloud security debate has not focused much on denial-of -service attacks because of the protection progress that has been made since Y2K. Cyber Security and service providers, for example, can now help to detect, divert, and filter botnet attacks aimed at any Internet-connected entity, and this includes public cloud portals. Content Distribution Networks (CDNs) provide additional network security by scattering inbound target points. So when the issue of cloud denial -of -service is raised, most experts shrug.

The problem is that cloud technology involves so much more than a fanciful portal into a public utility cloud offering cheap storage to users. The essence of cloud technology is automation through virtual interfaces called Application Programming Interfaces or APIs. Such virtual interfaces allow dynamic service chaining, which is the magic by which cloud systems become extensible to users and third-parties on-demand. When service providers virtualize capability through APIs in this manner, the result is something called a Software Defined Network (SDN).

The reason virtualization, cloud automation, and SDNs are so relevant to cyber security is that APIs have now become the new communications channels for cloud replacing traditional IP networks. A given cloud workload, for example, will now communicate with another cloud workload across virtualized cloud infrastructure using APIs, rather than across a traditional IP network. This requires a shift in denial-of- service protections to address these changes in interaction between the two workloads.

DDoS defenses must now defend against a new security risk–one that the cyber security experts would be foolish to ignore. It involves some malicious cloud program being programmed to create denial -of -service conditions by clogging up APIs through function call activity with higher volume, capacity, and speed than can be handled by the receiving program. Buffer overflows have worked in this manner for years, so the general concept is not entirely new; but the application to cloud infrastructure increases the attack surface dramatically.

Security solutions to this new denial-of-service problem require contributions from many players in the cloud ecosystem. Developers in particular will have to place much more attention on proper and elegant programming techniques, strong and generalized exception handling in virtual code, and more active run-time monitoring in cloud operating systems. Service providers deploying SDN will also have to address risk, generally through the use of behavioral analytic tools in SDN controllers that can identify rogue, automated attacks.

What this means is that APIs in cloud infrastructure will likely be the new virtualized breeding ground for denial of service attacks. This type of attack will almost certainly replace traditional layer 3 volume attacks over Internet communication channels. This new risk should not diminish our collective enthusiasm for cloud and virtualization, but should rather prompt swift remedial action by all ecosystem participants.

And, by the way, trying to solve the problem by having system administrators hovering over servers waiting to reboot is not recommended.