A Collaborative Intrusion Detection
System Framework for Cloud Computing
Nguyen Doan Man and Eui-Nam Huh
Abstract Cloud Computing provides a framework for supporting end users easily
attaching powerful services and applications through Internet. To provide secure and reliable services in cloud computing environment is an important issue. To counter a variety of attacks, especially large-scale coordinated attacks, a frame-work of Collaborative Intrusion Detection System (IDS) is proposed. The pro-posed system could reduce the impact of these kinds of attacks through providing timely notifications about new intrusions to Cloud users’ systems. To provide such ability, IDSs in the cloud computing regions both correlate alerts from multiple elementary detectors and exchange knowledge of interconnected Clouds with each other. In the system, another advantage is isolation between detectors with com-promised hosts to protect these detectors from evasions or infections.
Keywords Cloud computing
Collaborative IDS framework SecurityThreat
VMI8.1 Introduction
Cloud Computing can be defined as a new style of computing in which dynami-cally scalable and often virtualized resources are provided as a services over the Internet. With Cloud Computing, users use a variety of devices, including PCs,
N. D. Man (&)E.-N. Huh
Department of Computer Engineering, Kyunghee University, 1 Seocheon-dong, Giheung-gu, Yongin-si, Gyeonggi-do 446-701, Korea
e-mail: [email protected] E.-N. Huh
e-mail: [email protected]
K. J. Kim and S. J. Ahn (eds.),Proceedings of the International Conference on IT Convergence and Security 2011, Lecture Notes in Electrical Engineering 120, DOI: 10.1007/978-94-007-2911-7_8,Springer Science+Business Media B.V. 2012
laptops, smart phones and PDAs to access programs, storage, and application-development platforms over the Internet, via services offered by cloud computing providers. Advantages of the cloud computing technology include cost savings, high availability and easy scalability [1].
Because Cloud users hold their sensitive data and critical applications in a multi-tenant environment as cloud computing, security becomes their most con-cern. The security requirements for cloud computing providers begin with the same techniques and tools as for traditional data centers, which includes the application of a strong network security perimeter. However, physical segmenta-tion and hardware-based security cannot protect against attacks between virtual machines (VM) on the same server. Cloud Computing servers use the same operating systems (OS), enterprise and Web applications as localized VMs and physical servers. By this feature, an attacker can remotely exploit vulnerabilities in these systems and applications. Furthermore, co-location of multiple VMs increases the attack surface and risks to VM-to-VM compromise. Thus, Intrusion Detection System (IDS) is offered as a necessary security tool to detect malicious activities in the VM level, regardless of the location of VMs within the virtualized cloud environment.
In this paper, we propose a Collaborative IDS framework, which launches an idea of federation defense in the cloud computing. Based on this concept, IDSs are deployed in each Cloud computing region belonging to each cloud provider (CP). These IDSs cooperate with each other by exchanging alerts about recognized intrusions to prevent from further damages. Furthermore, this IDS framework also supports to synthesize information extracted from alerts for detecting large-scale coordinated attacks such as DDoS, stealthy scan, worms, etc. Also, our work allows Cloud users to configure all their own IDSs distributed on different Cloud regions via a unique user interface, which help to simplify management of Cloud users’ IDSs. The rest of this paper is organized as follows. In theSect. 8.2, we will provide backgrounds about Cloud Computing, Intrusion Detection System and Collabo-rative IDS (CIDS). We also consider the previous works to apply IDS into Cloud Computing in the Sect. 8.3. Architecture of our proposed Collaborative IDS framework and its components are the main contents in the Sect. 8.4, before we mention to apply this framework to analyze a DDoS attack scenario inSect. 8.5. In theSect. 8.6, we will conclude our work in this paper.
8.2 Related Works
8.2.1 Cloud Computing
As NIST, ‘‘Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider
interaction.’’ Cloud model consists of five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured ser-vice [2].
8.2.2 Intrusion Detection System
Intrusion Detection System is software that automates the process of monitoring the events occurring in a computer system or network, analyzing them for signs of possible incidents, which are violations or imminent threats of violation of com-puter security policies, acceptable use policies, or standard security practices. Incidents have many causes, such as malware (e.g., worms, spyware), attackers gaining unauthorized access to systems from the Internet, and authorized users of systems who misuse their privileges or attempt to gain additional privileges for which they are not authorized [3].
Based on monitoring targets, IDSs are divided into Network-based Intrusion Detection Systems (NIDS) and Host-base intrusion detection systems (HIDS). Network-based IDS is an independent platform that monitors the network back-bones and looks for suspicious behaviors by monitoring network traffic data. The detection of network intrusions helps generate timely automated or manual responses and notifications such as paging NIDS operators, reconfiguring the routers/firewalls, etc. The limitation of NIDS is the ability to detect no-traffic attacks or attacks from hosts inside the network. Otherwise, Host-based IDS resides in a particular host and tries to detect malicious activities and provide protection for a specific computer system by monitoring OSs and file systems for signs of intrusion. HIDS offers a high degree of visibility as it is integrated into monitored hosts. However, because of being deployed inside the hosts as a normal process, HIDS can be compromised along with host OS because of the lack of isolation between the two [4].
Misuse detection and anomaly detection are main techniques to be applied to recognize intrusions to a system. Misuse Detection is the most popular approach for the current IDSs, refers to known attacks that exploit the known vulnerabilities of the system to discriminate between anomaly or attack patterns (signatures) and known ID signatures. However, misuse detection is largely ineffective at detecting novel attacks, threats disguised by the use of evasion techniques, and many variants of known threats. Otherwise, anomaly-based detection is the process of comparing definitions of what activity is considered normal against observed events to identify significant deviations. The major benefit of anomaly-based detection is that they can detect unknown threats effectively. However, anomaly-based IDS often produces many false positives because of benign activity that deviates significantly from profiles, especially in more diverse or dynamic envi-ronments. Another noteworthy problem is that it is often difficult for analysts to determine why a particular alert was generated and to validate that an alert is
accurate and not a false positive, because of the complexity of events and number of events that may have caused the alert to be generated [3].
8.2.3 Coordinated Attacks
Large-scale coordinated attacks, such as stealthy scans, worms and DDoS are powerful tools to assist attackers to achieve monetary gain. These attacks can occur in multiple network domains simultaneously, which makes prompt detection an extremely difficult task [5].
8.2.3.1 Large-Scale Stealthy Scans
The main goal of an attacker who performs a large-scale stealthy scan is to gather information about the status of particular ports and IP addresses of interest.
The topology of these attacks is from one attack host to many target hosts. By randomizing a scan across multiple networks simultaneously, there is less likeli-hood that any single local IDS can observe a sufficient number of scan accesses within its detection window.
8.2.3.2 Worm Outbreaks
A worm is a self-replicating computer program that can send copies of itself to other computers in the network without user intervention. An attack that aims to spread a worm on the Internet has two main purposes: (1) to cause a traffic overload in local area networks and congestion on Internet links, which disrupts affected hosts and leads to financial losses; and (2) to recruit compromised hosts for future use. As new worms are discovered from time to time, they remain a threat to the security of the Internet. Three well-known examples of worms are SQL-Slammer, Code Red 2 and W32/Sasser.
8.2.3.3 Distributed Denial-of-Service Attacks
Distributed Denial-of-Service Attacks (DDoS) attack is to disrupt the on-line service of a victim’s web service, which is motivated mainly by monetary gain either by extorting the victim or by a payment from an opponent of the victim. In comparison to traditional DoS attacks that use a single attack source, DDoS attacks use multiple attack sources, which amplifies the attack power and makes defense more complicated. They can be split into two stages: recruiting and attacking. In the first stage, an attacker hunts for vulnerable hosts on the Internet to install attack tools on them. The attack topology in this stage is often one attack source to many
target systems, which is similar to the infection phase of worm spread. In the second stage, attacker sends attack commands to compromised systems to launch an attack against a third party. The attack topology in this stage is often many attack sources to one target system. Two well-known DDoS attacks are distributed SYN floods and distributed reflector attacks (Fig.8.1).
8.2.4 Collaborative Intrusion Detection System in Cloud
Computing
During the large-scale stealthy scans, there is one source (attacking host) that is responsible for numerous scans. Similarly, there is one source (infected host) that begins to connect to numerous hosts in order to spread itself during the worm outbreak. In contrast, the attack topology of a DDoS attack is many to one, namely, all the attack traffic is forwarded to one destination (the target system), although in a distributed reflector DDoS attack, part of the attack topology may appear as one to many (i.e., one spoofed source to many reflectors) [5].
Therefore, in order to detect the source address of a stealthy scan or worm outbreak, we need to correlate suspicious source addresses from incoming traffic across multiple network domains. Similarly, to detect and filter DDoS traffic we either need to correlate traffic at its source based on a common destination address,
Correlation unit Detection unit Detection unit Detection unit Detection unit Detection unit Detection unit Detection unit Detection unit
or correlate traffic at the reflectors based on a common (spoofed) source address. Moreover, given that the attack rate is high (except for stealthy scans), this cor-relation of attack evidence must be done in a timely manner. The combination of complementary IDSs to build a Collaborative IDS (CIDS) is a promising technique that can be used to obtain a precise and comprehensive view of suspicious events. Cloud Computing is defined as a multi-tenant environment where a CP’s infrastructure is shared by numerous users. The existence of numerous VMs owned by different Cloud users significantly increases attack surface for cross-VM (or VM-to-VM) attacks, which a VM can take advantage of vulnerabilities; for example, in hypervisor to compromise other co-resident VMs. This is considered as one of VM-level threats in Cloud Computing. Some other VM-level attacks are Hypervisor escape, VM escape, etc. To limit damages from these kinds of attacks, IDS is offered as a highly-confident security tool to detect malicious behaviors and alert to Cloud’s users about VM-level intrusions, which most of other security tools; such as firewalls, cannot support. The key benefit of IDS is the ability to deeply and automatically collect and analyze hardware states or network traffic, not only in physical machines but also in VMs, to find suspicious behaviors occurring in Cloud systems.
The present of Collaborative Cloud Computing model, which is constituted by multiple CPs’ infrastructure and owns a huge amount of resources, opens new chances for Cloud users to choose the best services from different CPs. However, the complexity of this model also generates a large amount of traffic of data which are transferred either locally between VMs located on the same Cloud infra-structure or between Cloud regions. These sensitive data are attractive and easy targets for attackers to deploy eavesdropping, MITM or probing attacks. This information leakage can be followed by large-scale attacks such as DDoS, worm spreading, etc. by exploiting detected vulnerabilities, which can occur not only on a single Cloud region but also in multiple interconnect Cloud regions. Further-more, attackers can hire services in multiple Cloud regions to take advantage of the computing and storage power of Cloud Computing for attacking their victims efficiently. Due to these threats which spread not only in a Cloud region but also whole of a Cloud federation, Cloud Computing is required providing counter-measures to protect Cloud users from severe damages. These security tools also need to gather knowledge about intrusions and threats from multiple Cloud regions to enrich their knowledge about compromised activities and enhance the efficiency of intrusion detection. A Collaborative IDS framework is a mechanism to solve these issues as by correlating suspicious evidence and attack signatures from different sources of IDS, CIDSs provide:
• The efficiency of detecting intrusions over a large-scale environment is improved.
• CIDSs have the potential to reduce computational costs by sharing ID resources between networks.
• The number of false alarms and irrelevant alerts that would be generated by individual IDSs is reduced.
• The fusion of alarms raised by different IDSs produces more comprehensive information about intrusion attempts than that attained using a single IDS technique.
• The knowledge synthesis from distributed IDSs in all interconnect Cloud regions about intrusions, suspicious behaviors, list of attackers or compromised VMs to enhance the efficiency and rate of intrusion detection.
8.3 Previous Works
In Sebastian Roschke’s paper [6], each virtual component is secured by a separated IDS sensor, which is responsible for one VM and can be configured by the Cloud user. For each layer (Application, Platform or System), NIDS and HIDS sensors should be deployed accordingly. A central IDS management system is responsible to gather and pre-process alerts of all sensors. As the outputs of the sensors are not standardized into the same format or technology, the Intrusion Detection Message Exchange Format (IDMEF) has been proposed as a standard to enable commu-nication between IDS sensors.
Distributed IDSs and mobile agent are suggested by Amir Vahid Dastjerdi [7] for applying IDSs into Cloud Computing. When Static Agents installed in each VM detect a suspicious event, Mobile Agents (MA) are created to visit and investigate all those VMs, collect information, correlate it and finally send or carry back the result to IDS Control Center. Alerting Console in IDS Control Center will analyze the coming information, compare and match with intrusion patterns in database. IDS Control Center saves the information received from investigative MA into its database. Names and identifications of possibly discovered compro-mised VMs will be black-listed and sent to all VMs except the black-listed VMs. The advantages of this approach include higher scalability, overcoming network latency, reducing network load and lower operational cost, executing asynchro-nously and autonomously, adopting dynamically, operating in heterogeneous environments, and having robust and fault-tolerant behavior.
VMFence [8], a VMM-based intrusion prevention system in cloud computing environments, is used to monitor network traffic and file integrity in real time, and provide a network defense and file integrity protection as well. VMFence exploits the fact that the privileged VM is able to capture all network packets to or from other service VMs, thus this VM has the ability to detect all packets without installing an instance of IDS in each service VM. In the virtualization-based computing environment, the communication between service VMs must pass through the virtual bridge in the privileged VM, so the virtual bridge can be monitored by VMFence. The security can be assured by the isolation provided by VMM.
A cooperative IDS framework for Cloud Computing is proposed by Chi-Chun Lo to protect Clouds from DOS and DDOS attacks [9]. Within this framework,
IDS is deployed in each cloud computing region. Each IDS sends out the alert to other IDSs while they are suffering from a severe attack defined in its block table. IDSs exchange their alerts and have a judgment criterion to evaluate the trust-worthiness of these alerts. After evaluation, a new blocking rule is added into the block table if alerts are regarded as a new kind of attack. By early detection and prevention from a victim IDS, IDSs in the Cloud computing regions could resist this type of attack.
8.4 Architecture of Collaborative IDS Framework
For convenience, each CP’s infrastructure in a Collaborative Cloud Computing model is considered as a Cloud region while each physical machine residing at a Cloud region is called a node.
Our proposed IDS framework consists of three main components; namely, IDS Manager, which resides at the management region of a Collaborative Cloud, IDS Dispatcher, which is built inside each Cloud region, and Elementary Detector, which is distributed to monitor each VM and generates alarms for an detected anomaly. For communication among components, messages containing data and necessary information are created and encrypted at each component before being exchanged. Messages use TCP as the data transport. Also, two kinds of Database servers, Global and Local, reside at Management region and each element region, respectively, to store alerts and users’ profiles, which are vital for operating the whole CIDS framework.
8.4.1 Elementary Detector
Elementary Detector (ED) is a specialized IDS distributed to monitor each VM in the system. Based on the service models that Cloud users chose from the initial-ization phase, the default functions are assigned to each EDs to collect and analyze data about network traffic, memory, file systems, logs, etc. to find potential intrusions in the monitored hosts. For example, EDs only need to monitor network and hardware infrastructure of a host, which are controlled by the CP in IaaS model. Moreover, users can offer complementary configurations (such as thresh-olds, functions of EDs) to customize the functions of their individual EDs or resources used for intrusion detection components. Alerts generated by EDs are called raw alerts and sent to IDS Dispatcher to alert aggregation and correlation from other EDs for reducing the number of false raw alerts and generating higher-level alerts about large-scale coordinated or multi-step attacks.
To build EDs for monitoring Cloud users’ virtual hosts, Virtual Machine Introspection (VMI) technique [4,10] is used to gather necessary data including memory states, I/O activities, network traffic, etc. from monitored hosts.
In virtualization, to isolate many VMs that might run on a single system, the VMM provides an abstraction layer between each VM OS’s memory management and the underlying physical hardware. VMM translates the VM-requested page frame number into a page frame number for the physical hardware, and thereby gives the VM access to that page. Because of the VMM’s active involvement in this process and its elevated privileges, it can also access memory pages assigned to each VM directly–without the VM actually requesting the page. VMM can also make those pages accessible to other VMs on the system. With this mechanism, VMI process helps IDSs installed in a privileged domain can monitor the memory state of all VMs residing on the same physical machine. Furthermore, requests of virtual hosts for I/O devices are also processed by VMM. Thus, through information provided by VMM, VMI IDSs can still rebuild I/O activities of the monitored hosts, which are important data to understand systems and user behaviors, without installing IDSs inside monitored hosts. Because of location of VMI IDSs, these IDSs cannot be evaded or compromised in case the monitored VMs are failed by attacks. Moreover, operations of VMI IDSs do not affect the performance of VMs as computing and storage resources allocated to EDs are isolated with which belong to hosts (Fig.8.2).
In general, VMI EDs are generated and operated in a trusted and privileged domain, which can communicate with VMM and other VMs at the same node to access important information. Each ED is responsible for collecting, analyzing data from each VM and generating alerts to owner of this VM or system admin-istrators in case an intrusion is detected. The complexity of Cloud Computing environments can increase the attack surface and the probability for existence of novel attacks. Therefore, unsupervised anomaly detection [11] should be applied
Physical Machine IDS Domain Virtual Machine
Hypervisor (Virtual Machine Monitor) Hardware Virtual NIC Data Collector VM Isolator Elementary Detector Virtual Switch Elementary Detector Log Collection Local Database Cloud Provider 2 Global Database IDS Manager Alert Processor User Configuration Alert Collector Notification IDS Dispatcher Alert Correlation IDS Generator Translation Engine Guest OS Virtual Machine Virtual NIC Log Collection Guest OS Management Domain Alerts Network traffic Log files Memory states, I/O activities
to EDs as the key detection mechanism to detect effectively novel attacks and decrease amount of training data and time to build an anomaly-base IDS. All behaviors which are labeled as intrusions or anomaly behaviors will be transferred to IDS Dispatcher as raw alerts for aggregation and correlation to further analyze and detect large-scale coordinated attacks.
8.4.2 IDS Dispatcher
IDS Dispatcher is built in a secured independent node at each Cloud region and responsible for either generating distributed EDs or processing raw alerts which are sent from all EDs. It’s considered as the parent node in the hierarchical CIDS model for aggregating and correlating all raw alerts from EDs into hyper alerts and analyzing them to detect large-scale coordinated attacks. IDS Dispatcher consists of three modules: IDS Generator, Translation Engine and Alert Correlation.
8.4.2.1 IDS Generator
IDS Generator (IDSGen) is responsible for generating and configuring EDs to monitor each virtual host. First, IDSGen receives user’s information (such as user profiles, IDS configurations, service model) that is specified by Cloud users from IDS Manager. In addition, a blacklist from IDS Manager, which consists of information about suspicious attackers, intrusions detected by IDSs of other Cloud regions, is also used to update IDS configurations. To prevent these sensitive data from man-in-the-middle (MITM) attacks, all data are encrypted and capsulated into TCP packets at IDS Manager before being sent to this module.
In case there is a new legitimate user, IDSGen queries Service Management component in each Cloud region for information about nodes and VMs which are allocated to this user. After knowing locations of monitored VMs, IDSGen sends requests to the management component in each node to generate EDs in a trusted VM of the same node according to user’s service models and ED configurations and allocate computing resources to them.
Otherwise, if EDs had been allocated to this user before, IDSGen would update new IDS configurations to the deployed EDs through management component, if needed. In addition, if any change about the status of VMs occurs, i.e. VM migration or VM removal, IDSGen is also notified by the management component of each node and then informs IDS Manager about new status of VMs and cor-responding EDs to update to the list of Cloud regions belonging to the Collabo-rative Clouds and location of VMs allocated to each user.
8.4.2.2 Translation Engine
After receiving raw alerts which are generated by all EDs located in all nodes of a cloud region or hyper alerts from Alert Correlation module, Translation Engine (TransEng) takes charge of storing them in Local Database. Due to the diversifi-cation of alerts which are built in different formats, TransEng translates received alerts into a common format, IDMEF [12], before extracting necessary data and storing them into Local Database.
8.4.2.3 Alert Correlation
In theory, attackers are likely to launch a series of attacks against the targets. Otherwise, EDs can only generate raw alerts based on each step it detects. Intel-ligent hackers are more likely to disguise their real purpose by launching many other minor attacks. Alert Correlation is used to correlate alerts based on logical relationships among the alerts. This function will provide the system security operator with great insight into where the initial attacks come from and where they actually end up. It can also be used to find patterns among series of attacks. After the alert correlation, high-level alerts providing an overall view of the attacks will be presented to the system security operators and Cloud users.
In addition, correlating raw alerts from different function of IDSs also helps to verify whether a certain attack is successful or failed to have appropriate responses. For instance, from information about network traffic, an ED detects a suspicious remote buffer-overflow attack to get shell access to a server machine. But due to its limitation, it does not know what is really occurring inside that host after that. Meanwhile, system states and behaviors which are collected inside the same VM help to detect a suspicious shell process and generate an alert. Therefore by correlating these raw alerts, system administrators can further confirm that some remote shell access attack is in progress. Moreover, since each IDS product has its own blind spots, correlation can help to remove some of the false negatives. Three key steps to correlate raw alerts into hyper alerts are alert aggregation, alert verification and alert correlation. Alert aggregating is the grouping of alerts that both are close in time and have similar features. It fuses together different ‘‘views’’ of the same event. Alert verification is to take a single alert and determine the success of the attack that corresponds to this alert. The idea is that alerts that correspond to failed attacks should be appropriately tagged and their influence on the correlation process should be decreased. Finally, alert correlation discovers the relationships between individual alerts raised by security incident detection sys-tems and other security syssys-tems. This step has to do with the recognition of logically linked alerts, and dedicate to disclose the logical association between network attack activities by analyzing their corresponding alerts.
In particular, when a new raw alert is stored into the Local Database by TransEng, Alert Correlation is simultaneously notified. After receiving this alert from database, Alert Correlation puts it in Alert Queue and then correlates it with
others which are also located in this Queue. An alert would expire from the Alert Queue when it is determined by the fresh alerts are corresponding to a different attack. This can be determined by using metrics such as the source of the attack, the time interval, the target process [13]. In case a multi-step or coordinated attack is recognized from correlating progresses, this module creates a new alert, which is the result of merging two or more related alerts as a part of the alert correlation process, and then removes related raw alerts out of Alert Queue. This alert is also included ID numbers of raw alerts used to refer. Finally, it is sent back to Tran-sEng for reformatting and then updating to Local Database.
Correlation Algorithm
A: list of raw alerts
r: Correlation threshold
s: Correlation sensitivity
initializehyper alert listH
forall each alertaiinA
forall hyper alerts in H
find an hyper alert hjcontaining an alert ajsuch that the correlation probability ofaiandajis maximum m/this maximum correlation probability
ifm[r
thenfor each alert akin hj
ifm- (probability betweenakandai)\s
thenconnectaiwithak
else
create a new hyper-alert putaiin new hyper-alert
8.4.3 IDS Manager
IDS Manager is considered as the central management component of the CIDS framework and an intermediate to exchange information between Cloud’s users and EDs. It also takes charge of gathering all events related to intrusions and sending notifications to users via one single interface for all cloud regions. With IDS Manager, the management of IDSs which are distributed into Cloud regions can also be manipulated with centralized characteristic and via only a user interface for all regions.
There are four modules in IDS Manager; namely, User Configuration, Notifi-cation, Alert Collector and Alert Processor. Also, IDS Manager keeps a list of
cloud regions which are members of this Collaborative Cloud model, and location information of VMs which had been allocated to Cloud users (Fig.8.3).
8.4.3.1 User Configuration
User Configuration (UserCfg) is built to collect users’ IDS configurations and transfer them to other related components in our proposed CIDS framework. Through a single web-based user interface, Cloud users can specify monitoring functions (e.g., network traffic, file integrity, hardware state, legitimate access, etc.), alert settings (e.g., notification through email, pop-up, dialog, etc.) and thresholds which are considered as parameters for building and configuring their EDs. This interface is only sent to Cloud users after they are verified as legitimate users of Cloud.
Client Multi-factors Users
Authentication
End-User Service Portal Security Control VPN Manager VPN Service 1 Service N . . . Service Enabler Service Configuration Asset Manager IDS Manager Auditing
Service Broker Service Gateway
Security Control Access Control Identification Authentification Authorization Security Policy Key Management Security
Cloud Service Provider 1
Service Management IDS Dispatcher IaaS Open API ... Cloud Service provider 2 Inter Cloud IDS Manager User Configuration Alert Collector Alert Processor Service Monitoring PaaS Open API ... SaaS Open API ... Notification
Based on the list of Cloud regions and VM locations, UserCfg relays messages containing users’ IDS configurations to IDS Generator module of corresponding IDS Dispatchers. Otherwise, changes of VM states (such as generation, removal or migration) are also updated to the mentioned list that IDS Manager is keeping by UserCfg after it receives updates from Cloud regions.
8.4.3.2 Notification
Notification directly interacts with Cloud users to notify detected intrusions which affect their own resources allocated from CPs. It does queries to Global Database to get new alerts which are stored into Database by Alert Collector and alarms to Cloud users. In this context, Global Database stores information about intrusions to resources of all users of all Cloud regions belonging to the Collaborative Cloud environment.
Furthermore, in case a user wants to review the historical events of intrusions in his/her system, Notification collects all the entries which is related to this user from Global Database, parses and audits all alerts stored before creating the sta-tistical reports and detailed reports as user’s demand.
8.4.3.3 Alert Collector
In the proposed collaborative IDS framework, information about intrusions gen-erated by IDSs of a cloud region are also worthy to other Cloud regions in the same Collaborative environment because they help to detect the same intrusions more precisely and rapidly and prevent from further damages. Therefore, gathering all hyper alerts from all regions and extracting important information from these alerts are necessary steps to complete function of a Collaborative IDS framework. Alert Collector takes charge of receiving hyper alerts from Cloud regions and updating them to Global Database for being processed by Alert Processor later.
Because of the Internet-based nature of Cloud Computing, handling services and allocated resources of Cloud users is processed through a request–response model like an ordinary web client–server. Therefore, Cloud users’ requests to Access Control component also needs to be monitored by the Cloud IDS frame-work as a source for anomaly detection. As usual, Access Control will assess the validation of all requests from Cloud users before determining to reject these requests or forward them to appropriate processing components in Cloud systems. In this case, all requests are sent to Access Control component are analyzed to figure out internal anomalies, such as denied access, ill-formed access requests, login failures exceeding thresholds, etc. All these alerts are collected by Alert Collector and correlated with historical alerts or related alerts from cloud regions to detect intrusions, if existed.
8.4.3.4 Alert Processor
Alert Processor is the module which processes hyper alerts at the highest level in the hierarchical Collaborative IDS framework. The main goal of Alert Processor is to analyze lower-level alerts stored in the Global Database, extract information and generate a blacklist of compromised VMs, identification of suspicious attackers (i.e., IP addresses of suspicious systems which may be owned by an external attacker or even a Cloud user), and details of recognized attacks. This blacklist is sent to all Cloud regions as complementary data for local IDSs to prevent from being damaged by the same attackers. Moreover, this information is also used to notify CPs about intrusions which help them determine to apply more security policies or countermeasures to against compromised hosts or attackers which are considered as Cloud users.
8.4.4 Collaborative IDS Framework Workload
Figure8.4illustrates generally the steps in the above CIDS framework. Users could access the client side (i.e. web browser) via diverse devices like PDA, laptop, or mobile phone. The client side is the portal where users touch their services on Cloud Computing. Before a user can be provided any service in the cloud, users have to get validation from Security Control as legitimate users. After being authenticated and choosing appropriate services, users send IDS configurations (functions, thresholds, etc.) to proposed IDS framework(Step 1.1)for generating new IDSs for their allo-cated systems. These users’ IDS configurations are stored in Global Database before having been transferred to IDS Dispatcher in each Cloud region(Step 1.2). At each Cloud region, all configurations are used to generate and configure new IDSs which are used to monitor user’s virtual hosts(Step 1.3). These steps also occur with other Cloud regions based on users’ IDS configurations.
As an intrusion is detected by EDs, a raw alert is generated and sent to IDS Dispatcher node on the same Cloud region(Step 2.1). This alert is converted into the common format (IDMEF) and stored in the Local Database(Step 2.2). This alert is aggregated with other alerts(Step 2.3)to create hyper alerts and forward to IDS Manager on the Management region of this federated Cloud(Step 2.4).After receiving new alerts, through a user interface, IDS framework notifies users about a threat(Step 2.5)to their system and requires a response.
8.5 Security Analysis
8.5.1 Scenario of a DDoS Attack
Figure8.5illustrates a DDoS attack scenario which may occur in a Cloud Com-puting infrastructure. We assume that the attacker is inherently a Cloud user and owns at least a virtual host which will be used as a Control & Command (C&C) server for a DDoS attack [15]. The first step of a DDoS attack is network probing, which is deployed to recognize the potentially co-resident vulnerable hosts, which are located on the same physical machine with attacker’s hosts, or the ones on other Cloud regions. For instance, we can utilize nmap to determine the infor-mation about the virtual hosts residing on the network, the operating system version running on each host and the services hosted on each host. Next, attackers try to convert a set of vulnerable hosts into a botnet. A botnet is defined to be a set of infected hosts that run autonomously and automatically, controlled by a bot-master who can coordinate his/her malicious intention using the infected bots (or zombies) [16]. Based on exploitation of vulnerabilities which are recognized after probing, botnet infection can be deployed to gain root privileges on the target hosts (for instance, buffer overflow) and then install bot malware.
After generating a botnet, the botmaster can command all its bots to attack a particular target at a particular date, time and for a duration. As usual, physical network is the main environment for DDoS attacks when bots simultaneously request the victim for services, which will make the victim’s resources exhausted, and therefore, the target server cannot keep providing other legitimate clients with services. However, in Cloud Computing, cross-VM attack, which takes advantage of sharing of physical resources to compromise a VM from another VM at the same physical machine, creates a novel attack surface for DDoS attacks. As [17], the same resources can be used to mount cross-VM performance degradation and DoS attacks, analogously to those demonstrated for non-virtualized multipro-cessing. Some resources multiplexed between the attacker and target can form a potentially useful channel for cross-VM are network, CPU branch predictors and instruction cache, DRAM memory bus, data cache, etc. In Fig.8.5, the target host will be suffered by a large amount of cross-VM attacks which are deployed by bots at the same time. In this context, cross-VM attack helps bots to degrade the
performance of target VM via concurrently deploying DoS attacks to the victim to make its resources exhausted.
8.5.2 Defense Strategy with CIDS Framework
Botnets are considered as the key component to deploy a DDoS attack; thus, botnet detection is urgent requirement for protection Cloud Computing from DDoS attack. Botnet detection can be based on observation that bots within the same botnet will likely demonstrate very strong synchronization in their responses and activities. Hence, we employ several alerts correlation analysis algorithms to detect spatial–temporal correlation in network traffic and process behaviors with a very low false positive rate. In particular, bots communicate with botmaster constantly for new executables to detect and disable antivirus software, or update bot malware with its full command list to make it more functional [16]. Therefore, network packets which are generated or received by hidden processes which are not found in the process lists that OSs provided via system commands (e.g.,psin Linux systems) and to or from a suspicious host can be considered as a suspicious behavior.
In this case, EDs can rapidly generate raw alerts corresponding with suspicious events which may be related to the abnormal increase of network traffic from multiple VMs to a single host. Then these raw alerts are forwarded to IDS Dis-patcher for correlating alerts into hyper alerts which help to detect large-scale coordinated attacks. Also, these alerts can be correlated with previous alerts about either suspicious behaviors of network probing or the present of applications which are suspected as bot malware. This process provides more proofs to decide if the present of a botnet in Cloud Computing environment is.
Fig. 8.5 Scenario of a DDoS attack in cloud computing
Because EDs are located on a trusted VM in each physical machine and use VMI technology to gather data, they prevent from being evaded by bot malware installed in the compromised VMs. In contrast, as IDSs or security tools reside on the host to investigate hardware states or network traffic of the virtual hosts, botnet malware can disable or evade these tools. Therefore, network traffic from bots may not be detected because of failure of countermeasures.
8.6 Conclusions
In this paper, we have presented a Collaborative IDS framework for a Collabo-rative Cloud Computing model, which builds multiple anomaly-based elementary detectors and a hierarchical architecture for combination of their alerts to make more accurate determination of intrusions. In this architecture, elementary detectors are located outside the monitored hosts to prevent from being evaded and compromised by intrusions and gather vital information with the support of VMI technology. We also proposed a synthesis component which resides on the Management region of a Collaborative Cloud environment and gathers knowledge about intrusions, suspicious attackers or compromised hosts from multiple inter-connect Clouds into a blacklist. This blacklist is considered as either notification to each interconnected Cloud or additional knowledge to increase efficiency of intrusion detection progress. Currently, we are developing the adaptive and effective algorithms to simulate, evaluate and enhance the ability of this CIDS framework to recognize intrusions, especially large-scale coordinated attacks which are applied to against security of enterprise.
Acknowledgements This work was partly supported by the IT R&D program of MKE (The Ministry of Knowledge Economy)/KEIT (Korea Evaluation Institute of Industrial Technology) [10035321, Terminal Independent Personal Cloud System].
References
1. Furht B, Chapter 1, Handbook of cloud computing
2. The NIST Definition of Cloud Computing, Recommendations of the National Institute of Standards and Technology, Special Publication 800-145 (Draft)
3. Guide to Intrusion Detection and Prevention Systems (IDPS), Recommendations of the National Institute of Standards and Technology, Special Publication 800-94
4. Garfinkel T, Rosenblum M (2003) A virtual machine introspection-based architecture for intrusion detection. In:Proceedings 10th symposium, Network and Distributed System Security (NDSS 03), Internet Society, pp 191–206
5. Zhou CV, Leckie C, Karunaseker S (2010) A survey of coordinated attacks and collaborative intrusion detection. Comput Secur 29(1):124–140
6. Roschke S, Cheng F, Meinel C (2009) Intrusion detection in the cloud. In: 8th IEEE international conference on dependable, autonomic and secure computing
7. Dastjerdi AV, Bakar KA, Tabatabaei SGH (2009) Distributed intrusion detection in clouds using mobile agents. In: 3rd international conference on advanced engineering computing and applications in sciences
8. Jin H, Xiang G, Zou D, Wu S, Zhao F, Li M, Zheng W, A VMM-based intrusion prevention system in cloud computing environment
9. Lo C-C, Huang C-C, Ku J (2010) A cooperative intrusion detection system framework for cloud computing Networks. In: 39th international conference on parallel processing workshops
10. Nance K, Hay B, Bishop M, Virtual machine introspection: observation or interference? 11. Portnoy L, Eskin E, Stolfo S (2011) Intrusion detection with unlabeled data using clustering.
In Proceedings of ACM CSS workshop on data mining applied to security 12. Intrusion detection message exchange format.http://www.ietf.org/rfc/rfc4765.txt
13. Wu Y-S, Foo B, Mei Y, Bagchi S (2003) Collaborative Intrusion detection system (CIDS): a framework for accurate and efficient IDS. In: Proceedings of the 19th annual computer security applications conference
14. Zhu B, Ghorbani AA (2006) Alert correlation for extracting attack strategies. Int J Netw Secur 3(3):244–258
15. European Network and Information Security Agency (ENISA) (2011) Botnets: detection, measurement, disinfection and defence
16. Vuong ST, Alam MS, Advanced methods for Botnet intrusion detection systems
17. Ristenpart T, Tromer E, Shacham H, Savage S (2009) Hey, you, get off my cloud: exploring information leakage in third-party compute clouds. In: CSS’09 proceedings of the 16th ACM conference on computer and communications security
18. Feily M, Shahrestani A, Ramadass S (2009) A survey of botnet and botnet detection. In: 3rd international conference on emerging security information, systems and technologies
