80 IEEE TRANSACTIONS ON CLOUD COMPUTING, …vertexsoft.co.in/.../2016/01/Stealthy-Denial-of-Service-Strategy.pdf · Stealthy Denial of Service Strategy in Cloud Computing Massimo

Stealthy Denial of Service Strategyin Cloud Computing

Massimo Ficco and Massimiliano Rak

Abstract—The success of the cloud computing paradigm is due to its on-demand, self-service, and pay-by-use nature. According to

this paradigm, the effects of Denial of Service (DoS) attacks involve not only the quality of the delivered service, but also the service

maintenance costs in terms of resource consumption. Specifically, the longer the detection delay is, the higher the costs to be incurred.

Therefore, a particular attention has to be paid for stealthy DoS attacks. They aim at minimizing their visibility, and at the same time,

they can be as harmful as the brute-force attacks. They are sophisticated attacks tailored to leverage the worst-case performance of

the target system through specific periodic, pulsing, and low-rate traffic patterns. In this paper, we propose a strategy to orchestrate

stealthy attack patterns, which exhibit a slowly-increasing-intensity trend designed to inflict the maximum financial cost to the cloud

customer, while respecting the job size and the service arrival rate imposed by the detection mechanisms. We describe both how to

apply the proposed strategy, and its effects on the target system deployed in the cloud.

Index Terms—Cloud computing, sophisticated attacks strategy, low-rate attacks, intrusion detection

Ç

1 INTRODUCTION

CLOUD Computing is an emerging paradigm that allowscustomers to obtain cloud resources and services

according to an on-demand, self-service, and pay-by-usebusiness model. Service level agreements (SLA) regulate thecosts that the cloud customers have to pay for the providedquality of service (QoS) [1]. A side effect of such a model isthat, it is prone to Denial of Service (DoS) and DistributedDoS (DDoS), which aim at reducing the service availabilityand performance by exhausting the resources of the serv-ice’s host system (including memory, processing resources,and network bandwidth) [2]. Such attacks have specialeffects in the cloud due to the adopted pay-by-use businessmodel. Specifically, in cloud computing also a partial ser-vice degradation due to an attack has direct effect on theservice costs, and not only on the performance and avail-ability perceived by the customer. The delay of the cloudservice provider to diagnose the causes of the service degra-dation (i.e., if it is due to either an attack or an overload) canbe considered as a security vulnerability. It can be exploitedby attackers that aim at exhausting the cloud resources(allocated to satisfy the negotiated QoS), and seriouslydegrading the QoS, as happened to the BitBucket Cloud,which went down for 19h [3]. Therefore, the cloud manage-ment system has to implement specific countermeasures inorder to avoid paying credits in case of accidental or delib-erate intrusion that cause violations of QoS guarantees.

Over the past decade, many efforts have been devoted tothe detection of DDoS attacks in distributed systems. Secu-rity prevention mechanisms usually use approaches based

on rate-controlling, time-window, worst-case threshold,and pattern-matching methods to discriminate between thenominal system operation and malicious behaviors [4]. Onthe other hand, the attackers are aware of the presence ofsuch protection mechanisms. They attempt to perform theiractivities in a “stealthy” fashion in order to elude the secu-rity mechanisms, by orchestrating and timing attack pat-terns that leverage specific weaknesses of target systems [5].They are carried out by directing flows of legitimate servicerequests against a specific system at such a low-rate thatwould evade the DDoS detection mechanisms, and prolongthe attack latency, i.e., the amount of time that the ongoingattack to the system has been undetected.

This paper presents a sophisticated strategy to orches-trate stealthy attack patterns against applications running inthe cloud. Instead of aiming at making the service unavail-able, the proposed strategy aims at exploiting the cloud flex-ibility, forcing the application to consume more resourcesthan needed, affecting the cloud customer more on financialaspects than on the service availability. The attack pattern isorchestrated in order to evade, or however, greatly delaythe techniques proposed in the literature to detect low-rateattacks. It does not exhibit a periodic waveform typical oflow-rate exhausting attacks [5], [6], [7], [8]. In contrast withthem, it is an iterative and incremental process. In particu-lar, the attack potency (in terms of service requests rate andconcurrent attack sources) is slowly enhanced by a patientattacker, in order to inflict significant financial losses, evenif the attack pattern is performed in accordance to the maxi-mum job size and arrival rate of the service requestsallowed in the system. Using a simplified model empiricallydesigned, we derive an expression for gradually increasingthe potency of the attack, as a function of the reached servicedegradation (without knowing in advance the target systemcapability). We show that the features offered by the cloudprovider, to ensure the SLA negotiated with the customer(including the load balancing and auto-scaling mecha-nisms), can be maliciously exploited by the proposed

� The authors are with the Department of Industrial and InformationEngineering, Second University of Naples (SUN), Via Roma 29, 81031,Aversa, Italy. E-mail: {massimo.ficco, massimiliano.rak}@unina2.it.

Manuscript received 17 July 2013; revised 1 May 2014; accepted 6 May 2014.Date of publication 30 June 2014; date of current version 11 Mar. 2015.Recommended for acceptance by A. Martin.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference the Digital Object Identifier below.Digital Object Identifier no. 10.1109/TCC.2014.2325045

80 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 3, NO. 1, JANUARY-MARCH 2015

2168-7161� 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

stealthy attack, which slowly exhausts the resources pro-vided by the cloud provider, and increases the costsincurred by the customer.

The proposed attack strategy, namely Slowly-Increasing-Polymorphic DDoS Attack Strategy (SIPDAS) can be appliedto several kind of attacks, that leverage known applicationvulnerabilities, in order to degrade the service provided bythe target application server running in the cloud. The termpolymorphic is inspired to polymorphic attacks whichchange message sequence at every successive infection inorder to evade signature detection mechanisms [9]. Even ifthe victim detects the SIPDAS attack, the attack strategy canbe re-initiate by using a different application vulnerability(polymorphism in the form), or a different timing (polymor-phism over time).

In order to validate the stealthy characteristics of theproposed SIPDAS attack, we explore potential solutionsproposed in the literature to detect sophisticated low-rateDDoS attacks. We show that the proposed slowly-increas-ing polymorphic behavior induces enough overload onthe target system (to cause a significant financial losses),and evades, or however, delays greatly the detectionmethods. Moreover, in order to explore the attack impactagainst an application deployed in a cloud environment,this paper focuses on one of the most serious threats tocloud computing, which comes from XML-based DoS (X-DoS) attacks to the web-based systems [10]. The experi-mental testbed is based on the mOSAIC framework,which offers both a ‘Software Platform’, that enables theexecution of applications developed using the mOSAICAPI, and a ‘Cloud Agency’, that acts as a provisioningsystem, brokering resources from a federation of cloudproviders [11].

The rest of this paper is organized as follows. Back-ground and related work are presented in Section 2. Sec-tion 3 illustrates several examples of attacks, which canbe leveraged to implement the proposed attack pattern.Section 4 describes the proposed strategy to build thestealthy attacks, and presents the attack pattern, whosedetailed implementation is reported in Section 5. Section6 introduces the X-DoS attack used as case study. Section7 shows the experimental results obtained running theattack pattern. Validation of stealthy characteristics isprovided in Section 8. Some considerations about coun-termeasures against the proposed strategy are illustratedin Section 9. Conclusions and future work are describedin Section 10.

2 BACKGROUND AND RELATED WORK

2.1 Related Work

Sophisticated DDoS attacks are defined as that category ofattacks, which are tailored to hurt a specific weak point inthe target system design, in order to conduct denial of ser-vice or just to significantly degrade the performance [7],[12]. The term stealthy has been used in [13] to identifysophisticated attacks that are specifically designed to keepthe malicious behaviors virtually invisible to the detectionmechanisms. These attacks can be significantly harder todetect compared with more traditional brute-force andflooding style attacks [5].

The methods of launching sophisticated attacks can becategorized into two classes: job-content-based and jobsarrival pattern-based. The former have been designed inorder to achieve the worst-case complexity of OðnÞ ele-mentary operations per submitted job, instead of the aver-age case complexity of Oð1Þ [14], [15], [16]. The jobsarrival pattern-based attacks exploit the worst case trafficarrival pattern of requests that can be applied to the tar-get system [7], [17]. In general, such sophisticated attacksare performed by sending a low-rate traffic in order to beunnoticed by the DDoS detection mechanisms. In recentyears, variants of DoS attacks that use low-rate traffichave been proposed, including Shrew attacks (LDoS),Reduction of Quality attacks (RoQ), and Low-Rate DoSattacks against application servers (LoRDAS).

The terminology ‘stealthy DDoS’ mainly refers to Shrewattacks first introduced in [6], which was followed by aseries of related research [18], [19]. It refers to a periodic,pulsing, and low-rate attack traffic against the TCP protocol.Specifically, it has been used to exploit TCP’s retransmissiontime-out (RTO) mechanism, provoking a TCP flow torepeatedly enter in a RTO state. This is obtained by sendinghigh rate but short-duration bursts (having round trip timescale burst length), and repeating periodically at slowerRTO time-scales [5], [16].

RoQ attacks target the dynamic operation of the adapta-tion mechanisms widely adopted to ensure that the work-load would be distributed across the system resources tooptimize the overall performance [7], [12], [20]. By using aspecific attack pattern, RoQ induces constant oscillationsbetween the overload and underload states, without sus-taining the attack traffic. This is achieved by timing theattack traffic and its magnitude in order to exploit thedynamics of the system.

As for LoRDAS, the applications are usually more vul-nerable to DDoS attacks due to their complexity. Specifi-cally, LoRDAS attacks have no necessary deviations interms of network traffic volumes or traffic distribution withrespect to normal traffic. Due to its high similarity to legiti-mate network traffic and much lower launching overheadthan classic DDoS attack, this new assault type cannot beefficiently detected or prevented by existing network-basedsolutions [21], [22]. Therefore, in recent years, the target ofDDoS attacks has shifted from network to application serverresources and procedures. Several LoRDAS attack modelsagainst application server have been proposed [8], [23], [24].In particular, they aim at keeping the service queue of thetarget application servers completely full of requests com-ing from the attacker, so that any new incoming requestsent by legitimate users is discarded. Macia-Fernandez et al.[24] present an evolution of the low-rate DDoS attackagainst iterative application servers, and extends its capabil-ities to concurrent systems. They assume the target serverhas a finite service queue, where the incoming servicerequests are temporarily stored to be served by the corre-sponding application process or thread. The attack takesadvantage of the capacity to forecast the time at which theresponses to incoming requests for a given service occur.This capability is used to schedule an intelligent pattern insuch a way that the attacked server becomes busy the mosttime in processing of the malicious requests instead of those

FICCO AND RAK: STEALTHY DENIAL OF SERVICE STRATEGY IN CLOUD COMPUTING 81

from legitimate users. The actual availability of the service isthus reduced, while the data rate is low to elude potentialdefense mechanisms deployed against high-rate DDoSattacks at the server side. However, the major attention waspaid to the mechanism for forecasting of the applicationserver response times. Regarding this, Xiaodong et al. [8]propose a modified strategy, according to which the attackdiffers in behavior at different stage of the process. Specifi-cally, the attack process has two different stages, before andafter the service queue is filled up. The attacker monitorsthe number of attack requests that have been declined bythe server within a recent period. If the requests are widelyrejected, the attacker can assume that the service queue hasbeen filled, and the attack is suspended. However, both thedescribed attacks exhibit the typical periodic waveform ofthe low-rate DDoS attack, which consists of ON-OFFsequences of attack messages. Several works have proposedapproaches to detect attacks that exhibit such a periodicand pulsing behavior [25], [26], [27].

Ben-Porat et al. [12] propose a vulnerability metric. Itaccounts for the maximal performance degradation (dam-age) that sophisticated attackers can inflict on the systemusing a specific amount of resources, normalized by theperformance degradation attributed to regular users(using the same resources). In particular, they evaluatethe vulnerability of both Open Hash and Closed Hashsystems combined with some queuing mechanism, com-monly used in computer networks. They show that underattack, the regular user still suffers from performancedegradation, even after the attack has ended (such degra-dation is not due to the extra load of the attack, but dueto its sophistication). However, the proposed metric hasbeen defined to support the system designer to evaluatethe relationship between the maximal job size allowed inthe system and the vulnerability of the system to mali-cious attacks, and to choose the desired balance betweenthe two. In contrast, our contribution aims at presentingan approach to build up sophisticated attack patterns,which cause significant damages (service performancedegradation), even if the attack pattern is performed inaccordance with the maximal job size and arrival rateallowed in the system (stealthy behavior). In particular,SIPDAS is a low-rate attach pattern that leverages thestrengths of both LoRDAS and RoQ. On the one hand, itis designed to exploit a common vulnerability in applica-tion design or implementation [28]; on the other hand, itis able to target the dynamic operation of the adaptationmechanisms used to ensure the system performance.

To the best of our knowledge, none of the works pro-posed in the literature focus on stealthy attacks againstapplication that run in the cloud environment.

2.2 Cloud Resources Provisioning

Cloud providers offer services to rent computation and stor-age capacity, in a way as transparent as possible, giving theimpression of ‘unlimited resource availability’. However, suchresources are not free. Therefore, cloud providers allow cus-tomers to obtain and configure suitably the system capacity,as well as to quickly renegotiate such capacity as theirrequirements change, in order that the customers can pay

only for resources that they actually use. Several cloud pro-viders offer the ‘load balancing’ service for automatically dis-tributing the incoming application service requests acrossmultiple instances, as well as the ‘auto scaling’ service forenabling consumers to closely follow the demand curve fortheir applications (reducing the need to acquire cloudresources in advance). In order to minimize the customercosts, the auto scaling ensures that the number of the appli-cation instances increases seamlessly during the demandspikes (to maintain the contracted performance), anddecreases automatically during the demand lulls. For exam-ple, by using Amazon EC2 cloud services, the consumerscan set a condition to add new computational instanceswhen the average CPU utilization exceeds a fixed threshold.Moreover, they can configure a cool-down period in orderto allow the application workload to stabilize before theauto scaling adds or removes the instances [29].

In the following, we will show how this feature can bemaliciously exploited by a stealthy attack, which mayslowly exhaust the resources provided by the cloud pro-vider for ensuring the SLA, and enhance the costs incurredby the cloud customer.

2.3 The mOSAIC Framework

The mOSAIC project aimed at offering a simple way todevelop and manage applications in a multi-cloud environ-ment [11]. It provides a framework composed of two maincomponents: the cloud agency and the software platform. Thecloud agency acts as a provisioning system, brokeringresources from a federation of cloud providers. ThemOSAIC user develops the application on its local machine,then it uses a local instance of the cloud agency in order tostart-up the process of remote resource acquisition and todeploy the Software Platform and the developed applica-tion. The Platform enables the execution of the developedapplications on the acquired cloud resources.

A Java-based API is provided to develop software com-ponents in the form of Cloudlets. A mOSAIC application is acollection of Cloudlets, which are interconnected throughcommunication resources, such as queues or shared key-value stores. The Cloudlets run on a dedicated operatingsystem, named mOSAIC Operating System (mOS), which isa small Linux distribution. At runtime, the Software Plat-form transparently scales the Cloudlets instances on theacquired virtual machines (VM) on the base of the resourceconsumption (auto scaling). As an example, when the Plat-form detects that a Cloudlet is overloaded (e.g., it has toomessages on the intercommunicating queues), it maychoose to start a new Cloudlet instance. The Platformassumes such a decision on the base of policies defined bythe application developer (through specific mOSAIC fea-tures). Finally, a load balancing mechanism automaticallybalances the application service requests among theinstances.

3 DOS ATTACKS AGAINST CLOUD APPLICATIONS

In this section are presented several attack examples, whichcan be leveraged to implement the proposed SIPDAS attackpattern against a cloud application. In particular, we con-sider DDoS attacks that exploit application vulnerabilities


[10], [12], [30], including: the Oversize Payload attack thatexploits the high memory consumption of XML processing;the Oversized Cryptography that exploits the flexibleusability of the security elements defined by the WS-Secu-rity specification (e.g., an oversized security header of aSOAP message can cause the same effects of an OversizePayload, as well as a chained encrypted key can lend tohigh memory and CPU consumptions); the ResourceExhaustion attacks use flows of messages that are correctregarding their message structure, but that are not properlycorrelated to any existing process instance on the targetserver (i.e., messages that can be discarded by the system,but at the expense of a huge amount of redundant work,such as the Business Process Execution Language (BPEL)based document, which must be read and processedcompletely, before they may safely be discarded); andattacks that exploit the worst-case performance of the sys-tem, for example by achieving the worst case complexity ofHash table data structure, or by using complex queries thatforce to spend much CPU time or disk access time.

In this paper, we use a Coercive Parsing attack as a casestudy, which represents one of the most serious threat forthe cloud applications [10]. It exploits the XML verbosityand the complex parsing process (by using a large numberof namespace declarations, oversized prefix names or name-space URIs). In particular, the Deeply-Nested XML is aresource exhaustion attack, which exploits the XML mes-sage format by inserting a large number of nested XML tagsin the message body. The goal is to force the XML parserwithin the application server, to exhaust the computationalresources by processing a large number of deeply-nestedXML tags [30].

4 STEALTHY DOS CHARACTERIZATION AND

MODELING

This section defines the characteristics that a DDoS attackagainst an application server running in the cloud shouldhave to be stealth.

Regarding the quality of service provided to the user,we assume that the system performance under a DDoSattack is more degraded, as higher the average time to pro-cess the user service requests compared to the normaloperation. Moreover, the attack is more expensive for thecloud customer and/or cloud provider, as higher thecloud resource consumption to process the maliciousrequests on the target system. From the point of view ofthe attacker, the main objective is to maximize the ratiobetween the amount of ‘damage’ caused by the attack (interms of service degradation and cloud resources con-sumed), and the the cost of mounting such an attack(called ‘budget’) [7].

Therefore, the first requirement to design an efficientDDoS attack pattern is the ability of the attacker to assessthe damage that the attack is inflicting to the system, byspending a specific budget to produce the maliciousadditional load. The attack damage is a function of the‘attack potency’, which depends on the number of concur-rent attack sources, the request-rate of the attack flows,and the job-content associated to the service requests tobe processed. Moreover, in order to make the attack

stealthy, the attacker has to be able to estimate the maxi-mum attack potency to be performed, without that theattack pattern exhibits a behavior that may be consideredanomalous by the mechanisms used as a protection forthe target system.

In the following sections, starting from a synthetic repre-sentation of the target system, we describe the conditionsthe attack pattern has to satisfy to minimize its visibility aslong as possible, and effectively affect the target system per-formance in the cloud environment.

4.1 Server under Attack Model

In order to assess the service degradation attributed to theattack, we define a synthetic representation of the systemunder attack. We suppose that the system consists of apool of distributed VMs provided by the cloud provider,on which the application instances run. Moreover, weassume that a load balancing mechanism dispatches theuser service requests among the instances. The instancescan be automatically scaled up or down, by monitoringsome parameter suitable to assess the provided QoS (e.g.,the computational load, the used memory, and the numberof active users). Specifically, we model the system underattack with a comprehensive capability zM , which repre-sents a global amount of work the system is able to per-form in order to process the service requests. Suchcapability is affected by several parameters, such as thenumber of VMs assigned to the application, the CPU per-formance, the memory capability, etc. Each service requestconsumes a certain amount wi of the capability zM on thebase of the payload of the service request. Thus, the loadCN of the system at time t can be modeled by a queuingsystem M=M=n=n with Poisson arrivals, exponentially dis-tributed service times, multiple servers, and n incomingrequests in process (system capability). Moreover, the autoscaling feature of the cloud is modeled in a simple way:when new resources (e.g., VMs) are added to the system,the effect is an increase of the system capability zM .

Therefore, given h legitimate type of service requestsu ¼ (#1; . . . ; #h), and denoted w as the cost in terms ofcloud resources necessary to process the service request’ 2 u, an attack against a cloud system can be representedas in Fig. 1. Specifically, Fig. 1 shows a simple illustrativeattack scenario, where the system is modeled as: ðiÞ aqueue (that conceptually represents the load balancingmechanism), in which are queued both the legitimateuser request flows fNj

and the DDoS flows fAj(attack

sources), and ðiiÞ a job for each service request that is cur-rently processed on the system.

Fig. 1. Attack scenario.


4.2 Stealthy Attack Objectives

In this section, we aim at defining the objectives that asophisticated attacker would like to achieve, and therequirements the attack pattern has to satisfy to be stealth.Recall that, the purpose of the attack against cloud applica-tions is not to necessarily deny the service, but rather toinflict significant degradation in some aspect of the service(e.g., service response time), namely attack profit PA, in orderto maximize the cloud resource consumption CA to processmalicious requests. In order to elude the attack detection,different attacks that use low-rate traffic (but well orches-trated and timed) have been presented in the literature.Therefore, several works have proposed techniques todetect low-rate DDoS attacks, which monitor anomalies inthe fluctuation of the incoming traffic through either a time-or frequency-domain analysis [18], [25], [26]. They assumethat, the main anomaly can be incurred during a low-rateattack is that, the incoming service requests fluctuate in amore extreme manner during an attack. The abnormal fluc-tuation is a combined result of two different kinds of behav-iors: ðiÞ a periodic and impulse trend in the attack pattern,and ðiiÞ the fast decline in the incoming traffic volume (thelegitimate requests are continually discarded). Therefore, inorder to perform the attack in stealthy fashion with respectto the proposed detection techniques, an attacker has toinject low-rate message flows fAj

¼ ½’j;1; . . . ; ’j;m], that sat-isfy the following optimization problem:

Stealthy DDoS attack pattern in the cloud -Denote p the num-ber of attack flows, and consider a time window T , the DDoSattack is successful in the cloud, if it maximizes the followingfunctions of profit and resource consumption:

maximize PA ¼Xpj¼1

Xi

gð’j;iÞ;

maximize CA ¼Xpj¼1

Xi

wð#j;iÞ;

8>>>><>>>>:

(1)

and it is performed in stealthy fashion, if each flow fAjsatisfies the

following conditions:

ðc1Þ minimize dj; 8j 2 ½1::p�;ðc2Þ s:t:to ’j;i 2 u;ðc3Þ s:t:to exhibits a pattern neither periodic

nor impulsive;ðc4Þ s:t:to exhibits a slowly increasing intensity;

8>>>><>>>>:

(2)

where:

� g is the profit of the malicious request ’j;i, whichexpresses the service degradation (e.g., in terms ofincrement of average service time tS to process theuser requests with respect to the normal operation);

� dj is the average message rate of the flow fAj,

� w is the cost in terms of cloud resources necessary toprocess ’j;i 2 u.

Cond. (2.c1) implies that the flow fAjhas to be injected

with a low-rate dj. Cond. (2.c2) assumes that all attack mes-sages have to be legitimate service requests.

4.3 Creating Service Degradation

Considering a cloud system with a comprehensive capabil-ity zM to process service requests ’i, and a queue with sizeB that represents the bottleneck shared by the customer’sflows fNj

and the DoS flows fAj(Fig. 1). Denote C0 as the

load at time the onset of an attack period T (assumed tooccur at time t0), and CN as the load to process the userrequests on the target system during the time window T . Toexhaust the target resources, a number n of flows fAj

haveto be orchestrated, such that:

C0ðt0Þ þ CNðT Þ þ CAðT Þ � zM � T; (3)

where CAðT Þ represents the load to process the maliciousrequests ’i during the period T . If we assume that ð1Þ theattack flows are not limited to a peak rate due to a networkbottleneck or an attacker’s access link rate, and ð2Þ the termCN can be neglected during the attack (CA � CN ), the mali-cious resource consumption CA can be maximized if the fol-lowing condition is verified:

CAðT Þ � zM � T � C0ðt0Þ with CA � CN: (4)

Moreover, assume that during the period T , the requests’i 2 fA burst at an average rate dA, whereas the flow fN

bursts at an average rate dN . Denote B0 as the queue sizeat time t0, and d as the time that the queue becomes full,such that:

d ¼ B�B0

dA þ dN � dp; (5)

where dp is the average rate of requests processed on the tar-get system (i.e., the system throughput during the periodT ). After d seconds, the queue remains full if dA þ dN � dp.In particular, under attack, if d < T and CAðVÞ � zM �V �C0ðt0 þ dÞ, the attacker can archive the best profit PA duringthe time window V ¼ ½t0 þ d; T � (i.e., there will be a highlikelihood for the user requests to be neglected, forcing theclient to perform a service request retransmission).

4.4 Minimize Attack Visibility

According to the previous stealthy attack definition, inorder to reduce the attack visibility, Conditions (2) have tobe satisfied. Therefore, through the analysis of both the tar-get system and the legitimate service requests (e.g., theXML document structure included within the HTTP mes-sages), a patient and intelligent attacker should be able todiscover an application vulnerability (e.g., a Deeply-NestedXML vulnerability), and identify the set of legitimate servicerequest types #k � u (Cond. (2.c2)), which can be used toleverage such vulnerability. For example, for an X-DoSattack, the attacker could implement a set of XML messageswith different number of nested tags nTi ¼ 1; . . . ; NT . ThethresholdNT can be either fixed arbitrarily, or possibly, esti-mated during a training phase, in which the attacker injectsa sequence of messages with nested XML tags growing, inorder to identify a possible limitation imposed by a thresh-old-based XML validation schema. A similar approach canbe used to estimate the maximum message rate dT withwhich injecting the service requests ’i. Then, the attacker


has to define the minimal number p of flows fA character-ized by malicious requests injected with:

� an average message rate lower than dT , in order toevade rate-controlling- and time-window-baseddetection mechanisms (Cond. (2.c1)), and

� a polymorphic pattern (described in the next sec-tion), in order to evade low-rate detection mecha-nisms (Conditions (2.c3 and 2.c4)),

such that maximize the functions PA and CA (Eq. (1)).

5 SLOWLY-INCREASING-POLYMORPHIC DDOSATTACK PATTERN AGAINST CLOUD

APPLICATION

In this section, on the basis of the attack objectives and char-acterization described in Section 4, we present a strategy toimplement attack patterns that optimize the problemdescribed by Conditions (1) and (2).

5.1 Slowly-Increasing Polymorphic Attack Strategy

Denote w as the payload in terms of cloud resources zi (e.g.,average CPU load), necessary to process the service request’i 2 u during a time period Di (i.e., wð’iÞ ¼ zi � Di), Eq. (4)can be formulated as CAðT Þ ¼

Pzi � Di � zM � T � C0ðt0Þ.

Moreover, assuming that n is the average number of mali-cious requests Fn ¼ ½’1; . . . ;’n� (with ’i 2 u) sent by theattacker during a time window T , and m is the averagenumber of malicious requests Fm actually processed by thetarget system during T ; in order to maximize the functionsPA and CA, the DDoS attack has to satisfy the following con-ditions:

nPn

i¼1tIi

� mPm

i¼1tSi

with m n;

Xmi¼1

zi � Di � zM � T � C0ðt0Þ with CA � CN;

8><>: (6)

where, tIi is the inter-arrival time between two consecutiverequests ’i 2 Fn, and tSi is the average service time to pro-cess ’i 2 Fm. Eq. (6) expresses that, in order to identify asuboptimal solution of the problem described by Functions(1), the attacker should know in advance the comprehen-sive system capacity zM and the payload w for each type ofrequest ’i 2 u. The knowledge of such information wouldallow to orchestrate an attack that, on the one hand,achieves the desired service degradation, on the otherhand, minimizes the attack potency in order to hide themalicious behavior and to reduce the budget needed tomount the attack.

To implement an attack pattern that maximizes PA andCA, as well as satisfies Conditions (2), without knowingin advance the target system characteristics, we propose aSlowly-Increasing Polymorphic attack strategy, which isan iterative and incremental process. At the first iterationonly a limited number p of flows fA are injected. Thevalue p is increased by one unit at each iteration p, untilthe desired service degradation is achieved. During eachiteration, the flows fA exhibit the attack intensity shown inFig. 2. Specifically, each flow fAj

consists of burst of mes-sages, in which the parameter I0ðpÞ means the initial

attack intensity at the iteration p (which can be orches-trated by varying the number and type of injectedrequests), T is the length of the burst period, and DI isthe increment of the attack intensity each time a specificcondition V is false. V is tested at the end of each periodT . The satisfaction of the condition V identifies theachievement of the desired service degradation.

The purpose of using an iterative and incrementalapproach is related to the inability of knowing in advancethe target system capability zM and the payload wð’iÞ.The parameter DI sets the hypothetical overload that theattacker would like to add on the target system. The valueDI has to be manipulated by the attacker, and controlledwithin a very small range to hide the attack behavior, andprolong the attack detection latency. The intensity IðtÞ isperiodically increased until it exceeds a threshold IM ,beyond which the attack may be detected. In such case, anew attack iteration pþ 1 is performed, in which anotherflow fAj

is added, and a new attack intensity I0ðpþ 1Þ iscomputed for each flow fAj

(as will be described inSection 5.1.1). Therefore, in order to inject a number ofrequests (Cond. (2.c1)) strictly necessary for achieving a cer-tain level of service degradation (Eq. (6)), the intensity IðtÞand the number of involved flows fA are slowly enhanced.Moreover, each burst is a sequence of legitimate messages’i, randomly chosen within the set u (polymorphism in theform), injected with an inter-arrival time tI that is propor-tional to the alleged load associated to the injected message.

In the following is described as the SIPDAS-based attackscan be implemented, and how to estimate their effects onthe target system.

5.1.1 Attack Approach

In order to implement SIPDAS-based attacks, the followingcomponents are involved:

� aMaster that coordinates the attack;� p Agents that perform the attack (each Agent injects a

single flow of messages fAj); and

� aMeter that evaluates the attack effects.

Algorithm 1 describes the approach implemented byeach Agent to perform a stealthy service degradation in thecloud computing. It has been specialized for an X-DoSattack. Specifically, the attack is performed by injectingpolymorphic bursts of length T with an increasing intensityuntil the attack is either successful or detected. Each burst isformatted in such a way as to inflict a certain average levelof load CR. In particular, we assume that CR is proportionalto the attack intensity of the flow fAj

during the period T .

Fig. 2. SIPDAS lowly-increasing intensity behavior.


Therefore, denote I0 as the initial intensity of the attack, andassuming DCR ¼ DI as the increment of the attack intensity.For each attack period, fixed the maximum number ofnested tags (tagThreshold), the routine pickRandomTags(. . .)randomly returns the number of nested tags nT for eachmessage (row 4). Based on nT , the routine computeInterarri-valTime uses a specific algorithm (Eq. (12) described inSection 6.3) to compute the inter-arrival time for injectingthe next message (row 5). At the end of the period T , if thecondition ‘attackSuccessful’ is false (evaluated by the Meterand described in the next Section 5.1.2), the attack intensityis increased (row 10). If the condition ‘attackSuccessful’ istrue, the attack intensity is maintained constant until eitherthe attack is detected (e.g., the target system is no longerreachable due to a reaction performed by the securityadministrator or by an Intrusion Prevention System), or theauto-scaling mechanism enabled in the cloud adds newcloud resources (row 12). The attack is performed until it iseither detected, or the average message rate of the next burstto be injected is greater than dT (row 21). In this last case, theAgent notifies to the Master that the maximum averagemessage rate is reached (row 26), and continues to injectmessages formatted according to the last level of load CR

reached (row 30).If all the current Agents reach the threshold dT , the Mas-

ter replaces them with new Agents. Specifically, assumingthat at the generic iteration p were active p Agents, the Mas-ter replaces them with pþ 1 Agents, with initial attackintensity I0ðpþ 1Þ ¼ CRM

ðpÞ=ðpþ 1Þ, where CRMðpÞ is the

maximum level of intensity achieved by the previous pAgents. In general, the attack starts with a limited numberof Agents (e.g., a single Agent) and increased by one unit ateach iteration.

5.1.2 Attack Effect Estimation

During the attack, in order to determine if the current flowsfA are generating a service degradation, the Meter injects aflow fM of requests ’i overlapped to the attack flows fA,and estimates the service time tS to process each message ’i

on the target system. In particular, if we assume that theflow fM is not limited by a network bottleneck, and the net-work latency is negligible, then, we can approximate tSwith the response time of the target application. Therefore,during a training phase, the attacker can estimate anapproximation of the actual distribution of the responsetime tR, for each message of type #k � u, and then, uses it toevaluate the service degradation achieved.

Since the actual response time distribution may have alarge variance during the attack, the estimation model has tobe in charge of identifying significant deviations. Therefore,supposing thatmRð#kÞ and sRð#kÞ are themean and standarddeviation of the response time tR for the messages type #k,empirically estimated during the training phase, the Metercan adopt the following Chebyshev’s inequality to computedeviation of the service time tSð’iÞ during the attack:

pðjtSð’iÞ � mRð#kÞj � � � sRð#kÞÞ 1

�2with ’i 2 #k: (7)

The Chebyshev’s inequality establishes an upper bound forthe percentage of samples that are more than � standard

deviations away from the population mean. For example,by Eq. (7) can be shown that with � ¼ 2, at least 25 percentof the samples would fall outside two standard deviationsfrom the mean. The Chebyshev’s inequality can be used tocompute an upper limit (an outlier detection value)&ð#kÞ ¼ mRð#kÞ þ � � sRð#kÞ beyond which the sample tScan be considered to be an outlier. Specifically, we assumethat the attack is successful, if starting from a certain timet0, Eq. (8) is verified for each ’i:

tSð’iÞ > &ð#kÞ with ’iðtÞ 2 #k and t > t0: (8)

On the other hand, the service degradation may be due to atemporary user’s peak load. Moreover, since even if theattack is successful, a short subset of requests may benot affected by the attack (as will be shown in Fig. 5 ofSection 6.2), we can assume that the provided service isdegraded whether, given a sequence of messages ’i 2 fM ,i ¼ 1; . . . ; n, Eq. (8) has to be verified at least for a largenumber of service requests ’i. This assumption can be veri-fied by an approach based on a count� and� thresholdmechanism. It relies on a simple g filtering function definedas follows:

gð0Þ ¼ 0;gðiÞ ¼ gði� 1Þ þ 1 if tSð’iÞ > &ð#kÞ;gðiÞ ¼ gði� 1Þ �D if tSð’iÞ &ð#kÞ;with D 2�0; 1 ½ and ’i 2 #k;

8>><>>: (9)

where g is a score that tracks the number of requests thatexhibit a tS degraded according to the condition (8). Specifi-cally, the attack is successful if gðiÞ exceeds a certain thresh-old H, which represents the minimum number ofconsecutive requests that present a tS sufficiently large toconsider the service degraded. D represents the ratio withwhich gðiÞ is decreased for each tS that is comparable withthe tR under normal condition. The values to assign to Hand D depend on the required accuracy. In particular, ahigher value of H may improve the probability of correctlyrecognizing the service degradation due to the attack ratherthan a short workload peak of the user. A higher value of Denhances the weight of requests that are processed with aservice time comparable with that estimated during normaloperation. Moreover, the values of H and D have to be cho-sen on the base of the number of requests injected duringthe attack period T . Assuming that the peak loads due tothe user workload are short and impulsive, the attackershould choose a sufficiently large period T , for example,ranging between 10 minutes and one hour. Moreover, weempirically observed that, if the attack is successful, thenumber of messages unaffected by the attack is low (lessthan 10 percent of the injected messages). Therefore, we canchoose a value D close to 1 (e.g., D ¼ 0:98), and a thresholdH greter than the 50 percent of the requests injected in theperiod T ).

In summary, according to the proposed approach, theMeter is the component enabled to inject the flow fM , aswell as to compute the filtering function g used to set thecondition attackSuccessful in Algorithm 1. Specifically, atthe end of each attack period T , the Meter sets the conditionattackSuccessful, and the Agent increases the attack inten-sity whether such a condition is false.


Algorithm 1: Core Algorithm of SIPDAS Agent

Require: Integer timeWindow ( T {Burst period.}

Require: Integer nT ( 0 {Nested tags within eachmessage.}

Require: Integer tagThresold ( NT {Nested tagsthreshold.}

Require: Integer rateThreshold ( dT {Attack ratethreshold.}

Require: Integer attackIncrement ( DI {Attack intensityincrement.}

Require: Integer CR ( I0 {Initial attack intensity.}

1: repeat2: t ( 0;

3: while t T do

4: nT ( pickRandomTagsðtagThresoldÞ;5: tI ( computeInterarrivalTimeðCR; nT Þ;6: sendMessageðnT ; tIÞ;7: t ( tþ tI ;

8: end while

9: if !ðattackSuccessfulÞ then10: CR ( ðCR þ attackIncrementÞ;

{Attack intensification}11: else

12: while !ðattack detectedÞ and attackSuccessful do

13: {Service degradation achieved; attack intensityis fixed}

14: nT ( pickRandomTagsðtagThresoldÞ;15: tI ( computeInterarrivalTimeðCR; nT Þ;16: sendMessageðnT ; tIÞ;17: end while

18: end if

19: tIM ðCRÞ ¼ computeInterarrivalTimeðCR;NT Þ;20: tImðCRÞ ¼ computeInterarrivalTimeðCR; 1Þ;21: until ð2=ðtIM � tImÞ < rateThresholdÞ

and !ðattack detectedÞ22: if attack detected then

23: {Notify to the Master that the attack hasbeen detected}

24: print 0Attack detected0;25: else26: {Notify to the Master the attack has reached the

threshold dT and archived the intensity CR ¼ CRM}

27: print 0Threshold reached0;28: {Continue the attack by using the previous CR value}

29: CR ¼ CR � attackIncrement;

30: loop

31: nT ( pickRandomTagsðtagThresoldÞ;32: tI ( computeInterarrivalTimeðCR; nT Þ;33: sendMessageðnT ; tIÞ;34: end loop

35: end if

However, in order to make stealth the whole attack, eventhe flow fM must satisfy Conditions (2). Therefore, thesequence of the messages fM has to exhibit a polymorphicbehavior in terms of message form and over time. In orderto generate a polymorphic form, the Meter builds asequence of legitimate messages fMðtÞ ¼ ½’1ðtÞ; . . . ;’mðtÞ�,

randomly chosen within the set u. As for the inter-arrivaltime tI , the average message rate has to be lower than themessage rate of flows fA, but enough large to make a properperformance assessment of the system under attack (e.g., arequest per second). Specially, the requests are injected withan inter-arrival time tI such that, fixed m random numberxi sorted in ascending order in the range [0; T ]:

8xi 2 ½0; T ½) ’iðtk þ xiÞ with i ¼ ½1; . . . ;m�;xi 2 <;(10)

where m is the number of requests sent in the periodTk ¼ ½tk; tk þ T ½, and xi < xj with i < j.

6 THE CASE STUDY

In order to explain how to leverage a DDoS attack describedin Section 3 to implement a SIPDAS pattern, the Deeply-Nested XML attack is adopted as case study. We first ana-lyze the CPU consumption in presence of the classic brute-force X-DoS attack against a simple application server(Section 6.1). Then, the requirements to perform an X-DoSattack in the cloud environment are derived (Section 6.2).Finally, Section 6.3 describes how this simple X-DoS attackcan be orchestrated in order to exhibit a polymorphicbehavior.

6.1 XML-Based DoS Attack Example

In a previous work [32], we presented the effects of aDeeply-Nested XML attack against a simple web applica-tion built on Apache Axis2. The attacked system is a singleVM with 2.8 GHz processor, 4 GB of RAM, and Ubuntu 9.10Linux. During the experimental campaign, we analyzed theCPU consumption depending on the number of nestedXML tags and the frequency with which the malicious mes-sages are injected. In particular, in Fig. 3 is shown the CPUconsumption on the target system to parse messages con-taining XML tags with different nested depth. [t] The resultsshowed that a message of 500 nested tags is sufficient toproduce a peak of CPU load of about 97 percent, whereaswith 1,000 tags the CPU is fully committed to process themessage for about 3 seconds. Moreover, we performed sev-eral attacks. For each attack, we injected a homogeneous X-DoS flow fAj

, i.e., a sequence of messages with a fixed num-ber of nested tags nTj and a fixed message rate dAj

. Assum-ing that 20 seconds are the maximum time observedexperimentally to reach a steady state value of CPU underattack (namely CR), and denoting ‘base_line’ as the averageCPU load in absence of user load (about 9 percent). Wehave empirically estimated a function Y , which representsan approximation of the values CR reached (after 30 s)by each attack, varying nT (different inter-arrival time

Fig. 3. CPU consumption with different nested XML tags.


tI ¼ 1=dA are also considered). We can observe that, fixedthe inter-arrival time, CR enhances with a trend that can beapproximated as an exponential function Y ðnT ; tIÞ ¼AðtIÞ � e½nT �BðtI Þ�. In particular, in order to simplify theachieved results, assuming that BðtIÞ is a steady value equalto �, the computational load on the target system during theattack increases according to the following expressions:

CPU ¼ Base lineþ CRðnT ; tIÞCRðnT ; tIÞ ¼ AðtIÞ � e�nTAðtIÞ ¼ at�b

I :

8<: (11)

Finally, we empirically observed that the same level ofCPU overload can be achieved with several flows fAj

,orchestrated with different combination of nT and tI . Forexample, in order to obtain an increment of CPU load ofabout 30 percent with respect to the base_line, we canequally use flows fA orchestrated according to the pair(nTj , tIj ) reported in Table 1. As will be described inSection 6.3, such consideration can be exploited to buildthe polymorphic behavior of the SIPDAS attack pattern.

In the second set of experiments, in order to evaluate theeffect of a distributed X-DoS attack, we injected concurrentflows fAj

with the same number of nested tags nT and inter-arrival time tI . Empirical results showed that CR increaseslinearly with respect to the number kF of concurrent flows,such thatCPU ¼ Base lineþ ðm � kF Þwith the slopem < 1.

6.2 Creating X-DoS Based Degradation in CloudComputing

In this section, we analyze the effects of an X-DoS attack onthe cloud system in terms of provided quality of service.The mOSAIC-based testbed designed to test the attack effec-tiveness consists of two independent cloud applications,which represent the ‘Attacker’ and the target applicationserver, namely SUA. Both applications are designed accord-ing to the mOSAIC paradigm and run on independent setof VMs. The SUA application emulates a typical XML-basedweb application: it receives the XML messages via HTTP,and performs the XML parsing (using a DOM approach),and other simple elaborations (e.g., it computes the totalnumber of nested tags). The mOSAIC implementation ofsuch a scenario is represented in Fig. 4: a HTTPgw Cloudletmanages the HTTP messages and forwards them to theXML Analyzer, which parses the XML document, and storesthe results (in a Key-Value store). The advantage of usingmOSAIC is that, we are able to automatically scale theapplication when the virtual node is overloaded (startingnew VMs). Moreover, thanks to the mOSAIC monitoringtools [11], we are able to evaluate the resource consumptionof each involved VM and the number of retrieved messages(XML documents) to be processed.

In [31], we adopted the TPC Benchmark W (TPC-W) isadopted in order to assess the effectiveness of the X-DoS

attack with respect to the provided quality of service [33].It is a transactional web benchmark used to simulate theactivities of a business oriented transactional web server(i.e., the execution of multiple transaction types that spana breadth of complexity). Each web interaction involvesa different computational cost, and it is subjected to aresponse time constraint. The performance metric reportedby TPC-W is the number of web interactions processed persecond, namely WIPS. In this paper, the target applicationis an ad-hoc web service, therefore, we cannot use theTPC-W workload. In order to perform similar evaluations,we have built a TPC-W emulator, which generates a simi-lar workload for the SUA application. Moreover, it meas-ures the number of operations processed per second(WIPS), and retransmits the same request to the applica-tion when it is not processed before a fixed timeout. Itshould be clear that this testbed does not aim at correctlyemulating the TPC-W benchmark. It is only used as a basisto build up a generic workload, under which we are ableto analyze the attack effect.

We perform a dedicated testing campaign, by injectingflows fAj

with a fixed number of nested tags nTj and a fixedmessage rate dAj

. In Fig. 5 is shown the effect of a flow ofmessages with 350 nested tags every 100 ms. Specifically, itrepresents a qualitative analysis of the WIPS variation withrespect to the time, during several time windows. The firstwindow shows the WIPS variation in absence of the attack(i.e., in normal operation the considered testbed processesabout 190 transaction per second). In the second timewindow, the X-DoS attack is activated (at time t0). After afew seconds from t0, the system is completely overloaded(100 percent CPU), and the number of interactions proc-essed become very low (about 17 per second). At time t1,the attack is intensified, in particular, the message rate isincreased from 100 to 10 ms, which further reducing thenumber of transactions processed (about 9 per second).Finally, at time t2, we forced the mOSAIC auto-scaling

TABLE 1Attack Parameters to Achieve an Overload

CR of About 30 Percent

nTj 5 63 159 182 211 273tIj 10 ms 50 ms 100 ms 250 ms 500 ms 1000 ms

Fig. 4. Architecture of the mOSAIC-based testbed.

Fig. 5. WIPS evaluation during an X-DoS (with 350 nested XML tags)against a cloud application.


mechanism to add three new VMs, on which the XML Ana-lyzer instances are enabled; thus, the number of processedrequests progressively increases from 9 to 71. However,since the attack is already in progress, the provided servicestill results degraded compared with the normal operation.

Such results show that, ðiÞ if the X-DoS attack is over-lapped on the user traffic, although the attack achieves asubstantial service degradation, a subset of user’srequests is either unaffected, or at most processed in alonger time; and ðiiÞ once the system has reached a cer-tain level of service degradation, the attacker has togreatly increase the attack potency (i.e., the request-rateand/or number of concurrent sources), in order to pro-duce a slight additional damage. Therefore, on the basisof the considerations described in Section 5.1, it is neces-sary to identify the maximum attack intensity IM that theattacker can inflict to the target system, while respectingCond. (2).

6.3 SIPDAS-Based Attack Burst

In Fig. 6 is shown an example of a SIPDAS-based X-DoSattack burst, in which the number of nested tags nT and theinter-arrival time for each injected requests ’i 2 u have beenchosen according to a uniform distribution. Specifically,supposing that NT and dT are the maximum number of tagsthat can be nested and the maximum request rate respec-tively (empirically estimated as described in Section 4.4),and assuming that the level of CPU load increases accordingto the trend described by Eq. (11):

CRðnT ; tIÞ ¼ at�bI � eð�nT Þ ) tI ¼

ffiffiffiffiffiffiffiffiffiffiffiffiffiffiaeð�nT Þ

CR

b

s; (12)

fixing the value CR (the increment of CPU load inflicted bythe attack), the burst is implemented by orchestrating asequence of messages, in which each message includes arandom number of nested tags nT NT , injected with aninter-arrival time tI computed by Eq. (12) and includedwithin the range [tImðCRÞ; tIM ðCRÞ]:

tImðCRÞ ¼ tIð1; CRÞ tIðnT ; CRÞ tIðNT ;CRÞ ¼ tIM ðCRÞ;(13)

withtIð1; CRÞ ¼

ffiffiffiffiffiae�bpCR

;

tIðNT ;CRÞ ¼ffiffiffiffiffiffiffiffiffiffiae�NT

bp

CR:

8<: (14)

Clearly, we cannot expect that the real CPU load on thetarget system will exactly follow the function described by

Eq. (11). Nevertheless, such a model may be used to identifythe sequence of pairs ½nT ; tIðnT Þ�, which can be used to buildthe polymorphic behavior of the burst (that produces a loadCR on the target system).

Moreover, each burst is a sequence of requests ’iðnT Þ(with nT equally distributed in the range [1; NT ]), whichexhibits an average message rate equal to:

dAðCRÞ ¼ 1

½tIM ðCRÞ � tImðCRÞ�=2 : (15)

Therefore, the maximum attack intensity IM (beyond whichthe flow fA may not be more stealth) is bounded by the con-dition dAðCRÞ < dT .

7 ATTACK EVALUATION

In this section, first we present an example of attack imple-mented by using the paradigm offered by the mOSAICframework. Then, we study the impact of the SIPDAS-basedattack pattern on the quality of service provided by the tar-get application, by varying the number of the involvedAgents and the resources of the application server.

7.1 Attack Implementation

The implementation of a SIPDAS-based attack can be donein several ways. In this work, we use the same cloud frame-work adopted for building up the target server applicationSUA (described in Section 6.2). As a result, the implementedattack can be offered as a services through a simple webinterface. Fig. 7 shows the architecture of the attacker appli-cation in terms of the mOSAIC Cloudlets. A web interface isused to setup the attack parameters and observe the statusof the attack. When the attack is activated by the web inter-face, a set of parameters is sent to the Master, including thetarget system URL, the attack intensity I0, the attack incre-ment DI, the thresholdsNT and dT (e.g., the maximum num-ber of nested tags and service request rate), and the attackperiod T . The Master coordinates the attack, by enablingthe Agent instances, and interacting with the Meter that per-forms legitimate requests to the server under attack, anddifferently from the Agents, evaluates the response time tS .The KV store shared among the Cloudlets, maintains all theinformation related to the attack state, including the param-eters used by the Agents and the attack results (in terms ofreached service degradation) evaluated by the Meter. TheMaster periodically acquires information from the ‘KVstore’, and sends messages to Agents in order to updatetheir actions, according to the attack strategy described inSection 5.1.1.

Fig. 6. SIPDAS burst.Fig. 7. Attacker implementation by the mOSAIC paradigm.


7.2 Experimental Evaluation

In the following experiments, we assume that during thenormal operation the target application SUA runs on a cer-tain number of VMs (with 2 CPU x86, 32 bit, 2.0 Ghz with 1GB of memory) in a mOSAIC-based private cloud. Theauto-scaling mechanism is enabled by the mOSAIC Plat-form when the average CPU load on the involved VMsexceeds the 90 percent for a time period greater than 10minutes. Moreover, we adopt the developed TPC-W emula-tor (described in Section 6.2) both to simulate the customerworkload and to evaluate the attack effect. The TCP-W emu-lator and the attacker application are deployed on differentVMs and connected to the target cloud through a privatenetwork (100 Mb/s Ethernet LAN). The settings for theattack evaluation are selected as following: I0 ¼ 10 (initialattack intensity), DI ¼ 10 (attack intensity increment), andthe maximum number of nested tags NT ¼ 40 (we assumethat it is imposed by a prevention mechanism based on avalidation schema). Moreover, in order to achieve a smallevaluation time, the attack period is chosen to be T ¼ 120 s.Finally, during the first two experiments the mOSAIC autoscaling mechanism is disabled.

During the first experiment, we evaluate the maximummessage rate dT necessary to inflict a substantial service deg-radation. According to the filtering function g described byEq. (9) (with D ¼ 0:98 and � ¼ 3), we assume that the attackis successful if tsð’iÞ > mR þ 3sR for a number of consecu-tive service requests greater that H ¼ 60. In order to showthe attack effects, Fig. 8 shows the WIPS variation withrespect to the time, achieved with a single Agent againstSUA deployed on a single VM on the server side. In orderto make more clear the achieved results, the WIPS valuesare aggregated at a fixed time interval TS ¼ 30 s andthe average value is shown. Experimental results show thatare sufficient about nine attack periods (i.e., about t ¼ 9�T ¼ 18minutes) to satisfy Eq. (7), as well as to achieve a ser-vice degradation greater than 90 percent. The smallestreached inter-arrival time between two consecutive message(in the attack sequence) is tI ¼ 26ms, whereas the averagevalue is tI ¼ 73ms.

In the second experiment, we set the threshold dT tothe average value tI reached during the previous experi-ment (dT ¼ 1=73ms). Fig. 9 shows the WIPS variationachieved when the SUA is deployed on two VMs. Resultsshow that a single Agent is not able to inflict a significant

service degradation. Specifically, at sample #73 the Agentreaches the maximum achievable attack intensity CRM

with the fixed dT (after a period P1 ¼ 50 � TS from theattack activation). At this point, the Master enablesanother Agent and sets a new initial attack intensity ofthe two Agents to I0 ¼ CRM

=2. As Fig. 9 shows, with twoAgents the maximum service degradation is achievedafter a time period P2 ¼ 96 � TS ¼ 48 minutes.

In the third experiment, the mOSAIC auto-scaling mech-anism is enabled. We assume that in normal conditions thetarget application runs on two VMs, whereas in case ofoverloading due to a workload peak, the auto-scaling mech-anism can incrementally add other five VMs. Experimentalresults show that after about 3 hours the attack inflicts themaximum service degradation with five Agents.

8 VALIDATION

In order to validate the proposed stealthy strategy, we ana-lyze the traffic distribution exhibited by the presented attackpattern.

Recall that, the detection methods proposed in the lit-erature assume the main anomaly incurred during a low-rate attack is that, the incoming service requests fluctuatein a more extreme manner during an attack (it is due to ahuge number of messages periodically injected to the nor-mal traffic in a very slow pace), as well as the incomingtraffic volume suffers a fast decline. On the other hand,according to the proposed SIPDAS strategy, the overallincoming traffic volume may or may not decline duringthe attack, because the attack flows are legitimate mes-sage sequences ’i 2 u injected with a rate dA < dT , compa-rable with the normal customer’s flows, as well as it doesnot exhibit an impulsive pattern.

In order to prove that such kind of methods cannot beapplied to detect SIPDAS attack pattern, we exploit arecent work that proposes real-time detection approachfor low-rate DDoS attacks. Specifically, Lui [27] proposeto compute the distribution of the flow connectionentropy (FCE) series to obtain a coarse-grained estimationof the message traffic, and then use the time-seriesdecomposition method to divide the FCE series into a‘trend’ component and a ‘steady random’ component.Authors propose to analyze such components to detectthe anomalies of the long-term and short-term trends inthe message traffic, caused by the low-rate DDoS attacks.

Fig. 8. SIPDAS effect (with a single Agent) on the mOSAIC-basedapplication running on a single VM (auto-scaling disabled).

Fig. 9. SIPDAS effect (with two Agents) on the mOSAIC-based applica-tion running on two VMs (auto-scaling disabled).


The FCE of a set of incoming flows is defined as:

FCE ¼ �Xnj¼1

pðfiÞlog2pðfiÞ; (16)

where pðfiÞ is the probability of receiving a message belong-ing to the flow fi. According to a study conducted by Guanget al. [34], a DDoS attack produces an abnormal increase inthe FCE of the message traffic. Generally, a long time-scaletraffic exhibits the characteristics of trend, period, mutation,and randomness. The first two components belong to thelong-term changes, which represent the smooth process ofmessage traffic behavior, whereas the other two componentsbelong to the short-term changes, reflecting uncertainty inthe message traffic. As for the short period of time, we mayassume that the mutation component and the period compo-nent are negligible with the proposed attack pattern, i.e., themessages traffic within a short window can be considered asthe consequence of the interaction between the trend compo-nent and the random component only. This assumption sim-plifies the real-time detection approach. Under thisassumption, the FCE series is modeled as:

FCEi ¼ FCEi þRi;Ri ¼ hi þ �i;

�(17)

where FCEi denotes the trend component, Ri is the randomcomponent, hi represents the steady random component,and �i represents the measurement error (white noise).

To estimate the trend component, an exponentiallyweighted moving average can be adopted. The estimationof FCE is obtained by combining the current FCE with theFCE from the previous period corrected for trend as follows:

FCEi ¼ kiFCEi þ ð1� kiÞFCEi;ki ¼ kmaxð1� e�QmiÞ;mi ¼ jFCEi�FCEi�1j

FCEi�1;

8><>: (18)

where mi reflects the extent of the fluctuation. Generally, ifFCE series are subject to large changes, then the proportionof the history should be small so as to quickly attenuate theeffect of the old observations. If FCE series smoothlychange, the proportion of the history should be large to min-imize random variations. The value of the parameter Q canbe determined empirically through experiments. Finally,subtracting the long-term trend component from the origi-nal series, the remainder of the series can be considered asthe random part of the traffic Ri ¼ FCEi � FCEi. Therefore,given a series of FCE data, we first compute the trend andrandom components (the trend component will reflect themajority of slowly-increasing signal, whereas the steadyrandom signal is contained in the random component),then, specific anomaly detection methods are applied toeach component separately. In particular, we apply the non-parametric CUSUM method to the random component [34].It can be used to determine whether the observed timeseries are statistically homogeneous, and to identify thetime when the changes occur. The basic idea of CUSUM isto accumulate those small fluctuations during the detectionprocess to amplify the varying statistical feature, and thus,improve the detection sensitivity. It can detect a small devi-ation of the mean effectively. As for the trend component,

we calculate the double auto-correlation (DA) coefficientseries and examine the first Nmax elements in such series[35]. If the behavior in the trend component has an evidentincreasing or declining tendency, then those Nmax valueswill all exceed a certain threshold:

r0kðiÞ > TH; with 2 k Nmax; (19)

where r0kðiÞ is the DA coefficient series at phase i. Generally,since the window size used in the detection algorithm issmall (for attack latency reduction), the normal trend seriesshould exhibit a little fluctuation.

During the experimental campaign, we evaluated theaccuracy and latency of the detection approach based onFCS series. In order to generate the normal traffic, we useactual HTTP traffic collected by a web server of our univer-sity. The traffic we tested is synthetically generated bymerging the attack traffic and the normal traffic. The defaultsetting for the adopted parameters are the same used in[35]: Dt ¼ 5 s for sampling FCE series, ki ¼ 0:4, Q ¼ 10 fortime series decomposition, Nmax ¼ 6, and TH ¼ 0:4. Gener-ally, the size of the detection sliding window W should bekept small (e.g., W ¼ 10 minutes) to adapt to real-timedetection requirements. Moreover, with larger windowsize, more memory resources will be consumed [34].

During the first experiment, we consider the secondattack scenario of Section 7.2 (T ¼ 20 s, auto scaling dis-abled, two VMs client-side). We analyze separately the twocomponents to detect long-term and short-term anomalouschanges of the incoming message traffic. We used alarmseries to represent the detecting results, in which the valueis 1 when an anomaly is detected and 0 otherwise. AsFig. 10 shows, several anomalous behaviors are observedfrom the FCE series, including short increasing tendenciesand random components. However, all the alarms are falsepositives due to short outbursts or increasing-intensity ofthe normal traffic. The attack traffic is injected with a veryslow-increasing trend, which is not amplified from the back-ground traffic. It does not exhibit sudden fluctuations.Moreover, the incoming traffic volume declines very slowly.By finding a better combination of FCE parameter values,this last phenomena could be detected, but at the expense ofthe detection accuracy (with an increase of false positives ofabout 270 percent in the considered example). Moreover,recall that, the increasing trend of the attack potencydepends from the number of involved flows and the attackperiod; even if the victim detects the attack, the malicious

Fig. 10. Detection results achieved with FCE series (auto scalingdisabled).


process can be re-initiate (polymorphic over time). In partic-ular, enlarging suitably the attack period (T greater than thedetection sliding window W ), the incoming traffic volumeexhibits a slow-decreasing trend, such that the FCE seriesdo not exhibit fluctuation as time goes.

In the second experiment, we consider the third attackscenario of Section 7.2 (T ¼ 20 s, auto scaling enabled, sevenVMs client-side). Fig. 11 shows that anomalous trends areobserved before and after the system scales up. Specifically,when an VM is added, the incoming traffic volumeincreases quickly, which is an obvious consequence of theimprovement in overall system performance. Then, sincethe attack is already in progress, the performance decreasesquickly again. However, even in this case, experimentalresults have shown that, by using a larger attack period T(greater than 10 minutes), this second phenomenon cannotbe detected by the FCE series. Finally, the attacker couldslowly increase the attack potency in order to induce thesystem to scale up, but without deny the service, or how-ever, excessively degrading the response time. Specifically,by using the Meter, the attacker can check the reached ser-vice degradation (estimated by the function described inSection 5.1.2). As Fig. 11 shows, when the system scales up,the system performance tends to improve. Therefore, oncethe system is scaled up, the attacker can fix the attackpotency to the value achieved, without further overloadingthe system. In this way, the attacker can inflict a significantfinancial cost, limiting the response time degradation.

9 HOST-BASED COUNTERMEASURES

This section presents some considerations about host-basedcountermeasures against the presented attack strategy. Inparticular, several recent works have proposed host-basedsolutions for virtual environment application monitoring ofcloud resources utilization [36], [37]. However, they claimthat, the proposed detection techniques, which adopt pre-defined target performance measures and empiricallyderived thresholds, require a good understanding of the tar-get application. In a dynamic environment such as the cloud,it is difficult to identify which resources (such as memory,computing and communication units, server thread pools,database connections, locks, queues, hash tables, etc.) andmeasures (e.g., response time, CPU utilization, etc.) need tobe monitored and how to set accurate threshold values forthem [38]. The particular resources and measures to monitordepend on the nature of the applications, their workload,and the their potential vulnerability. The model-based tech-niques also face a big challenge in modeling the highly

dynamic of the cloud application behavior. Another draw-back of host-based techniques is that monitoring agents haveto be deployed on the target VMs, along with a need for ascalable monitoring infrastructure, which represent an addi-tional real cost for the victims (in the cloud). Moreover, col-lecting several measures frequently in real time, from all theinvolved virtual nodes, can be costly.

Regarding the X-DoS attack used as case study, it is anexhaustion attack that inflicts a sustained consumption ofcomputational resources. A possible detection method couldconsist in monitoring the overall CPU consumption of thetarget application deployed over the distributed VMs. Weadopt a window-based state monitoring that triggers statealerts only when the normal state is continuously violatedfor a time windowW [39].W is essentially the tolerable timeof abnormal state, which must be established by the serviceprovider. Given the threshold TR, the sizeW of the monitor-ing window, and nmonitored VMswith CPU values CiðtÞ attime t, an alert is triggered only when

Pni¼1 Ciðt� jÞ > TR,

8j 2 ½0;W ½ at any t. In order to validate the adopted tech-nique, we assume that the alarmmust be triggered when theoverall CPU load on the involved VMs exceeds 80 percentfor a time windowW ¼ 10minutes. Thus, if we consider theattack scenario of the second experiment of Section 7.2 (inwhich two VMs are involved and the auto scaling mecha-nism is disabled), the attack is detected after 41 minutes(detection latency). In the second experiment, we considerthe third attack scenario of Section 7.2 (in which two VMsrun in normal condition, and five VMs are added incremen-tally by the auto scaling mechanism). In order to set the autoscaling mechanism, we were inspired by the policy for theauto scaling activation suggested for Amazon Cloud [40].We assume that the system scales up by one VM, if CPUutili-zation is greater than 60 percent for 5 minutes (we call thistime ‘scaling time’). Based on this setting, the attack isdetected only after all the additional VMs have been enabled,which is about 137minutes from the start of the attack.

The experimental results have shown that the adopteddetection technique may be more accurate than the traffic-based technique presented in Section 7.2, although with alonger detection latency. On the other hand, the fixedthresholds can be identified and exploited by sophisticatedattackers in order to implement a SIPDAS-based attackpattern. The proposed strategy allows to define a sequenceof bursts which, while respecting the fixed thresholds,inflicts a system load that is considered normal by thedetection technique, and at the same time consuming moreresources possible. In particular, the attacker can graduallyincrease the attack potency, forcing the cloud service toscaling up, until reaching the maximum computationalcapacity (all available VMs have been enabled). At thispoint, the attacker can slightly reduce the attack intensityuntil the system scales down (e.g., by a single VM). If thisprocess is repeated in an iterative manner, with a periodsmaller than the detection time window W and an attackperiod T greater than the scaling time, the overall CPUconsumption can be kept below the detection thresholdfixed to 80 percent (none alarm is triggered).

Based on the performed analysis, a possible approach todetect SIPDAS should correlate both host- and traffic-basedinformation, such as an excessive sustained consumption of

Fig. 11. Detection results achieved with FCE series (auto scalingenabled).


computational resources, with no corresponding increase inincoming traffic [41]. However, the proposed attack strategyis generic enough to be applied to several kind of attacksthat leverage known application vulnerabilities. Therefore,even if the victim detects the attack, the attack process canbe re-initiate by exploiting a different application vulnera-bility (polymorphism in the form), or a different timing(polymorphism over time), in order to inflict a prolongedconsumption of resources.

10 CONCLUSIONS

In this paper, we propose a strategy to implement stealthyattack patterns, which exhibit a slowly-increasing polymor-phic behavior that can evade, or however, greatly delay thetechniques proposed in the literature to detect low-rateattacks. Exploiting a vulnerability of the target application,a patient and intelligent attacker can orchestrate sophisti-cated flows of messages, indistinguishable from legitimateservice requests. In particular, the proposed attack pattern,instead of aiming at making the service unavailable, it aimsat exploiting the cloud flexibility, forcing the services toscale up and consume more resources than needed, affect-ing the cloud customer more on financial aspects than onthe service availability.

In the future work, we aim at extending the approach to alarger set of application level vulnerabilities, as well asdefining a sophisticated method able to detect SIPDAS-based attacks in the cloud computing environment.

APPENDIEX A

TABLE OF NOTIONS

ACKNOWLEDGEMENTS

This research was partially supported by the EuropeanCommunity’s Seventh Framework Programme (FP7/2007-2013) under Grant Agreements no. 610795 (SPECS), and theMIUR under Project PON02 00485 3487784 “DISPLAY” ofthe public private laboratory “COSMIC” (PON02 00669).

REFERENCES

[1] M. C. Mont, K. McCorry, N. Papanikolaou, and S. Pearson,“Security and privacy governance in cloud computing via SLASand a policy orchestration service,” in Proc. 2nd Int. Conf. CloudComput. Serv. Sci., 2012, pp. 670–674.

[2] F. Cheng and C. Meinel, “Intrusion Detection in the Cloud,” inProc. IEEE Int. Conf. Dependable, Autonom. Secure Comput., Dec.2009, pp. 729–734.

[3] C. Metz. (2009, Oct.). DDoS attack rains down on Amazon Cloud[Online]. Available: http://www.theregister.co.uk/2009/10/05/amazon_bitbucket_outage/S

[4] K. Lu, D. Wu, J. Fan, S. Todorovic, and A. Nucci, “Robust and effi-cient detection of DDoS attacks for large-scale internet,” Comput.Netw., vol. 51, no. 18, pp. 5036–5056, 2007.

[5] H. Sun, J. C. S. Lui, and D. K. Yau, “Defending against low-rateTCP attacks: Dynamic detection and protection,” in Proc. 12thIEEE Int. Conf. Netw. Protocol., 2004, pp. 196-205.

[6] A. Kuzmanovic and E. W. Knightly, “Low-rate TCP-Targeteddenial of service attacks: The shrew vs. the mice and elephants,”in Proc. Int. Conf. Appl., Technol., Archit., Protocols Comput. Com-mun., 2003, pp. 75–86.

[7] M. Guirguis, A. Bestavros, I. Matta, and Y. Zhang, “Reduction ofquality (RoQ) attacks on internet end-systems,” in Proc. IEEE Int.Conf. Comput. Commun., Mar. 2005, pp. 1362–1372.

[8] X. Xu, X. Guo, and S. Zhu, “A queuing analysis for low-rate DoSattacks against application servers,” in Proc. IEEE Int. Conf. Wire-less Commun., Netw. Inf. Security, 2010, pp. 500–504.

[9] L. Wang, Z. Li, Y. Chen, Z. Fu, and X. Li, “Thwarting zero-daypolymorphic worms with network-level length-based signa-ture generation,” IEEE/ACM Trans. Netw., vol. 18, no. 1, pp.53–66, Feb. 2010.

[10] A. Chonka, Y. Xiang, W. Zhou, and A. Bonti, “Cloud securitydefense to protect cloud computing against HTTP-DOS and XML-DoS attacks,” J. Netw. Comput. Appl., vol. 34, no. 4, pp. 1097–1107,Jul. 2011.

[11] D. Petcu, C. Craciun, M. Neagul, S. Panica, B. Di Martino, S.Venticinque, M. Rak, and R. Aversa, “Architecturing a skycomputing platform,” in Proc. Int. Conf. Towards Serv.-BasedInt., 2011, vol. 6569, pp. 1-13.

[12] U. Ben-Porat, A. Bremler-Barr, and H. Levy, “Evaluating the vul-nerability of network mechanisms to sophisticated DDoS attacks,”in Proc. IEEE Int. Conf. Comput. Commun., 2008, pp. 2297–2305.

[13] S. Antonatos, M. Locasto, S. Sidiroglou, A. D. Keromytis, and E.Markatos, “Defending against next generation through network/endpoint collaboration and interaction,” in Proc. IEEE 3rd Eur. Int.Conf. Comput. Netw. Defense, 2008, vol. 30, pp. 131–141.

[14] R. Smith, C. Estan, and S. Jha, “Backtracking algorithmic complex-ity attacks against a NIDS,” in Proc. Annu. Comput. Security Appl.Conf., Dec. 2006, pp. 89–98.

[15] C. Castelluccia, E. Mykletun, and G. Tsudik, “Improving secureserver performance by re-balancing SSL/TLS handshakes,” inProc. ACM Symp. Inf., Apr. 2005, pp. 26–34.

[16] Y. Zhang, Z. M. Mao, and J. Wang, “Low-rate TCP-targeted DoSattack disrupts internet routing,” in Proc. 14th Netw. Distrib. Syst.Security Symp., Feb. 2007, pp. 1–15.

[17] U. Ben-Porat, A. Bremler-Barr, and H. Levy, “On the exploitationof CDF based wireless scheduling,” in Proc. IEEE Int. Conf. Com-put. Commun., Apr. 2009, pp. 2821–2825.

[18] A. Kuzmanovic and E. W. Knightly, “Low-rate TCP-targeteddenial of service attacks and counter strategies,” IEEE/ACM Trans.Netw., vol. 14, no. 4, pp. 683–696, Aug. 2006.

[19] S. Ebrahimi-Taghizadeh, A. Helmy, and S. Gupta, “TCP vs. TCP:A systematic study of adverse impact of short-lived TCP flows onlong lived TCP flows,” in Proc. IEEE Int. Conf. Comput. Commun.,Mar. 2005, pp. 926–937.

[20] M. Guirguis, A. Bestavros, I. Matta, and Y. Zhang, “Reduction ofquality (RoQ) attacks on dynamic load balancers: Vulnerabilityassessment and design tradeoffs,” in Proc. IEEE Int. Conf. Comput.Commun., 2007, pp. 857–865.

[21] Y. Xuan, I. Shin, M. T. Thai, and T. Znati, “Detecting applica-tion denial-of-service attacks: A group-testing-based approach,”IEEE Tran. Parallel Distrib. Syst., vol. 21, no. 8, pp. 1203–1216,Aug. 2010.

[22] V. Durcekova, L. Schwartz, and N. Shahmehri, “Sophisticateddenial of service attacks aimed at application layer,” in Proc. 9thInt. Conf. ELEKTRO, 2012, pp. 55–60.

Notions Meaning

zM comprehensive system capacityvi computational load of a service requestCN normal system loadu legitimate service request set#i service request typePA attack profitCA attack resource consumptionCR desired level of loadfAðNÞ attack (normal) flowp number of concurrent flows’i service requestnT number of nested tags per messageg profit of a malicious service requestd average rate of flow ftI ; tS inter-arrival time and service timeB queue sizeT; I attack period and intensitydT ;NT attack thresholds (rate and nested tags)p attack iterationW detection time window


[23] G. Macia-Fernandez, E. Diaz-Verdejo, and P. Garcia-Teodoro,“LoRDAS: A low-rate DoS attack against application servers,” inProc. 2nd Int. Conf. Critical Inf. Infrastruct. Security, 2008, vol. 5141,pp. 197–209.

[24] G. Macia-Fernandez, J. E. Diaz-Verdejo, and P. Garcia-Teodoro,“Mathematical model for low-rate DoS attacks against applicationserver,” IEEE Trans. Inf. Forensics Security, vol. 4, no. 3, pp. 519–529, Sep. 2009.

[25] X. Luo and R. K. Chang, “On a new class of pulsing denial-of-ser-vice attacks and the defense,” in Proc. Netw. Distrib. Syst. SecuritySymp., Feb. 2005, pp. 61–79.

[26] Y. Chen and K. Hwang, “Collaborative detection and filtering ofshrew DDoS attacks using spectral analysis,” J. Parallel Distrib.Comput., vol. 66, no. 9, pp. 1137–1151, Sep. 2006.

[27] H. Liu. “Real-time detection of stealthy ddos attacks using time-series decomposition,” in Proc. Int. Conf. Commun., 2010, pp. 1–6.

[28] A. Jumratjaroenvanit and Y. Teng-amnuay, “Probability of attackbased on system vulnerability life cycle,” in Proc. IEEE Int. Conf.Electron. Commerce Security, Aug. 2008, pp. 531–535.

[29] Amazon EC2—Auto Scaling Feature. Giu. (2012) [Online]. Avail-able: http://aws.amazon.com/autoscaling/

[30] M. Jensen, N. Gruschka, and R. Herkenh, “A survey of attacks onweb services,” Comput. Sci., vol. 24, no. 4, pp. 185–197, 2009.

[31] M. Ficco and M. Rak, “Intrusion tolerance of stealth DoS attacks toweb services,” in Proc. Int. Conf. Inf. Security Privacy, 2012,vol. 376, pp. 579–584.

[32] M. Ficco and M. Rak, “Intrusion tolerant approach for denial ofservice attacks to web services,” in Proc. IEEE Int. Conf. Data Com-pression, Commun. Process., Jun. 2011, pp. 285–292.

[33] TPC Benchmark W (TPC-W). A transactional web benchmark.(2013) [Online]. Available: at http://www.tpc.org/tpcw/

[34] C. Guang, G. Jian, and D. Wei, “A time-series decomposed modelof network traffic,” in Proc. 1st Int. Conf. Adv. Natural Comput.,2005, pp. 338–345.

[35] B. Brodsky and B. Darkhovsky, Nonparametric Methods in Change-point Problems. Norwell, MA, USA: Kluwer, 1993.

[36] Y. Mei, L. Liu, and X. Pu, “Performance analysis of network I/Oworkloads in virtualized data centers,” IEEE Trans. Services Com-put., vol. 6, no. 1, pp. 48–63, Jan. 2013.

[37] C. C Thimmarayappa and A. Jayadharmarajan, “VMON-virtualenvironment application monitoring,” in Proc. Int. Conf. Adv. Com-put., Commun. Inf., 2013, pp. 1936–1941.

[38] H. Wu, A. N. Tantawi, and T. Yu, “A self-optimizing workloadmanagement solution for cloud applications,” in Proc. IEEE 20thInt. Conf. Web Serv., 2013, pp. 483–490.

[39] S. Meng, T. Wang, and L. Liu, “Monitoring continuous state viola-tion in datacenters: Exploring the time dimension,” in Proc. IEEE26th Int. Conf. Data Eng., 2010, pp. 968–979.

[40] Auto Scaling in the Amazon Cloud. (2012, Jan.) [Online].Available: http://techblog.netflix.com/2012/01/auto-scaling-in-amazoncloud. html

[41] M. Ficco, “Security event correlation approach for cloudcomputing,” Int. J. High Perform. Comput. Netw., vol. 7, no. 3,pp. 173–185, 2013.

Massimo Ficco received the degree in computerengineering from the University ‘Federico II’ in2000, and the PhD degree in information engi-neering from the University of Parthenope. He isan assistant professor at the Department of Indus-trial and Information Engineering of the SecondUniversity of Naples (SUN). From 2000 to 2010,he was a senior researcher at the Italian UniversityConsortium for Computer Science. His currentresearch interests include software engineeringarchitecture, security aspects, and mobile comput-

ing. He has been involved in several EU funded research projects in thearea of security and reliability of critical infrastructures.

Massimiliano Rak received the degree in com-puter science engineering at the University ofNaples Federico II in 1999. In November 2002, hereceived the PhD degree in electronical engineer-ing at Second University of Naples. He is an assis-tant professor at Second University of Naples. Hisscientific activity is mainly focused on the analysisand design of high performance system architec-tures and on methodologies and techniques fordistributed software development. He has beeninvolved in several EU funded research projects in

the area of cloud computing.

" For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


Documents

80 IEEE TRANSACTIONS ON CLOUD COMPUTING, …vertexsoft.co.in/.../2016/01/Stealthy-Denial-of-Service-Strategy.pdf · Stealthy Denial of Service Strategy in Cloud Computing Massimo