Fig. 1: Fig. 1: (Left) The cloud system model for Whack-a-Mole. (Right) Service recovery progression from start-to-finish is shown in a red-to-green color scale.
With wider adoption of Software-Defined Networking (SDN), network obfuscation and resource adaptation within a cloud environment have emerged as cost-effective solutions against cyber attacks. In spite of their implementation simplicity, shortcomings of such one-dimensional strategies are considerable against sophisticated attacks where the attacker/s have enhanced visibility to the cloud network. In this paper, we propose "Whack-a-Mole", a SDN-driven cloud resource management scheme through network obfuscation that can help Cloud Service Providers (CSPs) to: a) proactively protect critical services from impending DDoS attacks and b) contribute very little sevice interruption footprint while doing so. Whack-a-Mole works at two levels: it employs a novel virtual machine (VM) spawning model (shown in Fig. 1) that not only creates multiple VM-replicas of critical services to new cloud resource instances, but also assigns VM-replica's IP addresses through address space randomization. Whack-a-Mole is implemented through SDN/OpenFlow controllers over Open vSwitches on a GENI testbed where the efficacy and effectiveness of the scheme is evaluated.
Other than attacks, large schale enterprise cloud systems faces issues like misconfigurations, where it is necessary to conduct tests that go across multiple parties. This is because, large-scale cyber and cyberphysical infrastructures are naturally composed of multiple administrative domains, each managed or controlled by a party with potentially unique policies and configurations that are not shared with other parties. Yet user requests pass through the infrastructure of multiple parties. For example in the typical situation of a customer in an organization accessing a remote web service, at least 3 parties are involved: the local organization, the internet service provider (ISP) that provides wide area network access, and the data center that hosts the web service. Each of these parties has its own configuration and test procedures to diagnose problems. However, in order to properly diagnose end to end problem, it is essential to run multiparty tests, and these would require cross party access. We envision them as compositions of test probes provided by individual parties along with suitable cross party access rules. These access rules may not be statically granted, and instead granted specifically for testing purposes.
We are building a comprehensive misconfiguration diagnosis infrastructure involves many significant research, design, and implementation challenges, such as (a) exploring constraints to be exploited by the probes for diagnosis, (b) defining and handling access control across parties, (c) test design and selection, and overall testing infrastructure design, implementation, and evaluation etc. Other than that we are also working on IP address consolidation and reconfiguration in large enterprise networks to minimize the routing table sizes, progressive recovery and restoration planning of interdependent services in enterprise data centers (shown in Fig. 1), failure diagnosis framework in enterprise cloud environments having unknown/uncertain dependencies among the cloud services etc.
Related Publications: