• Save
Handling of Incident, Challenges, Risks, Vulnerability and Implementing Detection approaches inside the Cloud
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Handling of Incident, Challenges, Risks, Vulnerability and Implementing Detection approaches inside the Cloud

on

  • 706 views

Handling of Incident, Challenges, Risks, Vulnerability and Implementing Detection approaches inside the Cloud

Handling of Incident, Challenges, Risks, Vulnerability and Implementing Detection approaches inside the Cloud

Statistics

Views

Total Views
706
Views on SlideShare
706
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Handling of Incident, Challenges, Risks, Vulnerability and Implementing Detection approaches inside the Cloud Document Transcript

  • 1. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 136 Handling of Incident, Challenges, Risks, Vulnerability and Implementing Detection approaches inside the Cloud Deepak Kumar, Amit Kumar Tyagi , Sadique Nayeem Abstract: In a malicious cloud system, handling of incident, challenges and risks, is an integral part of security management. In this paper we discuss various detection and analysis of security incidents as well as the subsequent response (i.e., containment, eradication, and recovery.) On side of existing processes and methods for incident and risk handling is geared towards infrastructures and operational models that will be increasingly outdated by cloud computing. So to update these systems on time to time, we need to discuss some risks and incident inside the cloud. Cloud computing is a computing paradigm which provides services and data from a shared resources from scalable data centers, and the services and data are accessible by any authenticated device over the Internet. Hence this paper discusses how to handle the changes in a cloud computing environment which is influenced via various incident, risks and challenges. It identifies problems that cloud customers encounter in each of the incident and risks handling steps and provides possible approaches and corresponding challenges to get the reliable service from cloud provider. The identified approaches provide guidance for cloud customers and cloud service providers towards handling of incidents and risks in the cloud; the identified challenges may serve as basis for a research agenda in cloud incident handling in future. Keywords: Cloud computing, Incident Handling, Risk, CSA, SLA I. INTRODUCTION A. Handling of Incident Security handling (SH) is one of the most important issues ever more important during the past years. In this, risks and incident which is arise in a cloud to affect it with various malicious attacks like botnet. So among this, relevant standards regarding IT (security) management such as ISO 27002 [39], PCI [32], and CobiT [26] list handling of incident as an important separate top-level control domain. Figure 1: Incident handling process diagram. Generally a detailed description of the incident handling process is given in several standard publications [7, 8, and 30] with containing the following steps shown in figure -1: • Detection: In this discover of possible security intrusion. • Analysis: In this it is ascertain weather a security intrusion is at hand or not and also understand the current situation. • Containment: It contains the intrusion much before it spreads and overpowers resources or increases damage. • Eradication & Recovery: It removes system changes caused by the intrusion and regain normal operations. • Preparation/Continuous improvement: It adopts intrusion handling activities according to changing requirements. Generally in this paper, incident handing (IH) or handing of incident term is used interchangeably.
  • 2. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 137 B. Cloud Computing Cloud computing is the computing paradigm where services and data are allowed to gain access from shared resources in long distance data centers, and the services and data are accessible only by the authenticated device over the Internet. It has emerged as a legitimate alternative model for the sourcing and it provides provision of digitized platforms for business organizations with following benefits:  Virtualization: Virtualization is decoupling and separation of the business service from the infrastructure needed to run it.  Flexibility to choose vendor.  Agility  Adaptability  Elasticity: Elastic nature of the infrastructure allows rapidly allocating and de-allocating massively scalable resources to business services on a demand basis.  Cost Reduction: Reduced costs due to operational efficiencies, and more rapid deployment of new business services. And today, we have identified three main categories of services that fall within our broad cloud computing definition. The main difference among these service models lie in how responsibilities are divided among cloud service provider (CSP) and cloud customer. For example: • Software as a service (SaaS): Software deployed as a hosted service and gained access over the Internet. • Platform as a service (PaaS): Platforms that deploy applications provided by customers or partners of the PaaS provider. • Infrastructure as a service (IaaS): Computing infrastructure, such as servers, storage, and network, delivered as a cloud service, typically through virtualization. Figure 2: Cloud service architecture displaying the service layers IaaS, PaaS, and SaaS. Today Mostly, security incidents will be due to high responsibility and gaining access of cloud computing. This aspect must be taken into account while establishing handling incidents for cloud infrastructure. It's not important for cloud computing alone but also for customers for a good relationship among cloud service provider and customers. Now from the definition of cloud computing, NIST [35] identifies the following essential cloud characteristics: 1. On-demand self-service: It provides the facility to the users to order and manage services without human interaction with the service provider, i.e., by using a web portal and management interface. Provisioning and de-provisioning of services and associated resources occur automatically at the provider. 2. Ubiquitous network access: Cloud services are gained access via the network, usually the Internet, using standard mechanisms and protocols.
  • 3. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 138 3. Resource pooling: Computing resources used to provide the cloud services are realized using a homogeneous infrastructure which is shared among all users of the service. 4. Rapid elasticity: Resources can be scaled up and down rapidly and elastically; to the customer, there often is an illusion of unlimited resources. 5. Measured Service: Resource/service usage is constantly metered, supporting optimization of resource usage, usage reporting to the customer and pay-as-you-go business models. C. Contribution This paper shows that adaption and handling of various types of arises incident and risks to cloud computing environments, cloud customers must establish clarity about their requirements on CSPs for successful handling of incidents and contract CSPs accordingly. Secondly, CSPs must strive to support these requirements and mirror them in their SLAs. Thirdly, for research in a cloud, handling of unknown incidents and risks with others challenges is the most pressing issues and most promising approaches. So in this paper comprehensive treatment of incident handling, risks analysis and carrying out detection analysis techniques in a cloud as contained provides a basis introduction for these activities. So for knowledge, we will describe in this paper �how the incident is handled and what are the challenges and risks inside a cloud. Hence at last this paper is organized as follow: Section 2 identify problems for cloud customers encounter in each of the incident handling step and provide possible approaches and corresponding challenges towards solving these problems. Section 3 examines cloud computing risks, threats & vulnerabilities. And Section 4 examines the implications these problems, possible approaches and related challenges have on cloud sourcing and research in cloud security. And in last Section 5 conclude this paper. II. INCIDENT HANDLING IN THE CLOUD In this task, we will examine problems, possible approaches and corresponding challenges regarding handling of incident in the cloud for each incident-handling process step. A. Detection Timely detection of security incidents depends on systematic event monitoring [7] are (a) all relevant existing event sources (e.g., OS and application log files) are monitored, (b) security- specific event sources (e.g., intrusion detection systems) are added where necessary, and (c) adequate methods for identifying events that may indicate a security incident are utilized. Of course, also user reports, chance findings of system administrators, or notification from third parties often lead to the detection of security incidents, but statistics [11] show that these seldom lead to timely detection. Finally, findings about vulnerabilities are indicators that should trigger investigations as to whether an incident may have occurred: the vulnerability may have been exploited by an attacker [7]. 1. Customer Issues with incident detection in the cloud. These are the some issues relate with customer in a cloud: • No access to CSP-controlled event sources and vulnerability information Generally for PaaS and SaaS, this issue is most pronounced. i.e. with PaaS, the customer typically only has access to events generated by his own application (e.g., via application logging) while with SaaS, the customer is completely dependent upon the CSP to provide event information such as activity logging, etc. Now problem is somewhat less acute for the main use case of IaaS, namely the provisioning of virtual servers which is in control of the customer. But the underlying virtualization infrastructure (through which an attacker might be able to attack the virtual server of a customer) connects to virtual servers in control of CSP. • Insufficient interfaces for access to relevant data Especially for PaaS and SaaS, access to event data and other information relevant for incident handling must necessarily occur via interfaces under the control of the CSP. These interfaces often are insufficient for integration of the available data into event monitoring systems. With IaaS, customers usually will be able to access event information from virtual servers in a way suitable for automated processing, but for all CSP-controlled data, the same problem is arise as for SaaS and PaaS occurs. • Inability to add security-specific event sources With infrastructure under one‟s own control (or the control of a service provider with a customer-tailored offering rather than a standardized cloud offering), security- specific event sources can be added when required e.g. a web application can be given additional protection using a web-application firewall. • Misdirection of abuses/incident reports In this the cloud business model leads to a situation where it is often unclear for a third party, to whom abuse/incident reports should be directed. Reports that actually concern a customer may be reported to the CSP instead e.g. in IaaS scenarios, incident reports regarding abusive traffic from a certain IP address will be directed to the CSP rather than the customer whose virtual server has been causing the abusive traffic[1,7]. Because of resource pooling, it may be difficult for the CSP to find out, to which of his customers the report refers. Conversely, incident reports to a customer may actually be relevant to the CSP and its customers.
  • 4. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 139 2. Possible approaches. In this, to enable their customers to reliably detect cloud incidents, CSPs should adapt their service levels and - offerings as follows: • Authentication In the cloud environment, the primary basis for access control over internet is user authentication. Trusted Platform Module (TPM) is a widely available and stronger authentication scheme using for improving the security in cloud computing than available username and passwords scheme in recent. Trusted Computing Groups (TCG‟s) is IF-MAP standard about authorized users and other security issue in real-time communication between the cloud provider and the customer. When a user is reassigned or fired, the customer‟s uniqueness management system can report the cloud provider in real-time so that the user‟s cloud access can be revoked or modified within seconds. In cloud any fired user is logged, they can be immediately disconnected. The secure mechanisms are used to the authentication process for frequent target of attackers by different ways to authenticate users based on different information know by the user. • Indirect Denial of Service It manage the computational power of the attacker, in cloud service the direct flooding attack gives some side effect and the same hardware provides some other services may suffer the workload caused by the flooding. So, the Denial of Service is targeted other services with target service instances on the same server hardware. In Cloud computing environment, denial of service can cause and notice the lack of availability and switch to other service instances to other servers. It is extra burden to all other servers and it spreads all the servers of Cloud. • Access to relevant data sources In this we consider which data sources are relevant for incident detection activities at the customer side. • Incident detection and reporting obligations/Service Incidents that originate with CSP-controlled infrastructure and might have an impact on a customer‟s resources must be reported to the customer. So SLA must provide a well-defined incident classification scheme and inform about reporting obligations and service levels (what is reported, how fast is reported, etc.). • Open interfaces for event/incident data exchange The CSP must enable systematic event-monitoring by offering open/standardized interfaces for accessing event / incident data exchange. • Direct Denial of Service It is a service attack involves saturating the objective with bogus requests to prevent it from responding to reasonable requests in a timely manner. An attacker to launch physical attack typically uses multiple computers or a botnet. The cloud dynamic provisioning in some ways minimizes the task of an attacker to cause harm [7, 32]. At the same time, the resources of a cloud are significant with enough attacking computers they can become saturated. • Intrusion-detection/prevention service portfolio Since customers usually cannot add intrusion detection/ prevention capabilities to their cloud resources, the CSP may have to offer such capabilities and these offering feasible service evolve as “security-as-a service” cloud offerings. • Acceptance and forwarding of external incident reports The CSP must accept external incident reports, ideally following established best practices and standards e.g., standard information regarding scope of responsibility, and monitoring of relevant mailboxes. 3. Challenges In this we define several challenges. So apart from the obvious challenges for the cloud-provider of building and maintaining the required infrastructure for supporting the service enhancements discuss above, the following problems must be define: • Identification of relevant data sources It is not easy to determine, which data sources are relevant for incident detection especially for SaaS and PaaS. • Standardization of event information Till now, no leading standard for expressing event information has emerged out of the field of existing initiatives [22, 24, and 25] for standardizing event information. • Customer-specific logging For providing customers access to event sources, the CSP must implement concepts and mechanisms that ensure two goals: all relevant event information should be accessible, but one customer should not be able to view event information regarding other customers. These two goals may be conflicting for events concerning several customers at the same time [7]. • Detection in spite of missing information about customer infrastructure/resources This problem is most pronounced with IaaS e.g. when providing intrusion detection for virtual machine images without knowledge regarding the installed OS [16] but also occurs with PaaS e.g., the problem of intrusion detection for web applications without knowledge about the application.
  • 5. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 140 B. Analysis After indicators and detection for a security incident we report, analysis of (a) whether indeed a security incident is at hand and (b) what exactly has happened or is happening. Moreover today a cloud is not secure because when a professional attacker using advanced techniques to hide his activity on the system. So to understand the security incident, the scope of affected networks, systems, and applications must be determined, the intrusion vector must be found and the attacker activities must be reconstructed. And the analysis of an incident needs to be performed quickly because an attacker may be able to hide his activity [2, 5, and 7]. The required level of documentation, and measures to assure traceability and integrity protection of collected data depend on requirements regarding later use of the collected data, e.g., as courtroom evidence [12]. 1. Customer Issues with analysis in the cloud. Similarly to incident detection, the customer‟s ability to perform incident analysis is also limited: • Limited knowledge about architecture Generally analysis of an incident, information about the architecture of the system e.g. network infrastructure, system configuration, and application-specific implementations is required. But parts of cloud infrastructure that are under control of the CSP, such information is usually not available – not least, because the exact set-up of the cloud infrastructure must be regarded as the CSP‟s core intellectual property [7]. • Missing knowledge of relevant data sources In cloud infrastructure data sources is more relevant for analyzing a security incident for a cloud e.g. regarding the redirection of access between applications on the PaaS platform: if the customer does not know about the PaaS- internal DNS-service i.e. used to resolve requests, he does not know about the log files of the DNS service that might serve as key for understanding the security incident. • Unclear incident handling responsibilities Previous discussed two issues show that, there is a clear need for co-operation between the CSIRT of the customer and some incident handling capability of the CSP. But for most current cloud offerings, however, there is no clear sense of the CSP‟s responsibilities in case of a security incident. • Problems of gathering evidence In the traditional IT infrastructure it is relatively easy to gather evidence by creating a 1:1 copy of the system‟s hard disc [7]. With cloud computing, the situation is different means systems are out of the customer‟s reach and virtualized rather than physical. For IaaS, the virtual machine image at least can be attributed to exactly one customer, so handing over a 1:1 copy of that image to the customer is a possibility. And for PaaS and SaaS, services are shared on one machine for several customers and it is not possible to give a 1:1 copy of the system to one customer. Also, the system and application logs often include information for several customers and cannot be easily accessed by customer [3, 8]. 2. Possible approaches • Provision of technical information about infrastructure When entering in a cloud-sourcing relationship, cloud customers should have at least some basic understanding of the CSP‟s infrastructure such that in case of a security incident. • Access to relevant data sources Considerations of relevant data for incident analysis activities at the customer side, the CSP can analyze data according to the questions of the customer‟s CSIRT and provide the customer with analysis results. • Interface to forensic use of virtualization technology For IaaS, virtualization allows novel methods of carrying out forensic analysis which should be made available to IaaS customers. Firstly, virtualization allows an investigator to introspect the compromised host. Secondly, virtual machines can create so-called system snapshots. Now advantage of forensic analysis is that an attacker cannot easily remove his traces on the system e.g. some malware does when a system is shut down [5, 7]. • Access to CSP incident handling capability The CSP‟s incident handling capability must have clear responsibilities regarding the co-operation in the analysis of security incidents that should be also described in the SLA. 3. Challenges • Separation of customer’s data sources during evidence collection With collection of information and data about many customers‟ for incident detection via resource pooling in a cloud environment is a major task to provide confidienality. Thus, when one customer is provided access to a data source, the CSP has to assure that this customer does not see information regarding other customers. • Adapting forensic analysis methods to the cloud Today‟s digital forensic methods are geared towards traditional IT infrastructures. Currently, it is unclear, how to effectively perform incident analysis in a highly dynamic cloud computing environment with redundancies (redundant storage, caching, etc.), data mobility, etc. And another issue is attacks that are changing for the cloud. e.g., Botnets use cloud computing to hide their activities [15, 33] beyond it e.g. the misuse of cloud computing infrastructures as botnet to start Denial of- Service attacks against large scale infrastructures.
  • 6. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 141 So New methods need to be developed to detect and analyze such kind of attacks. So to improve incident analysis for cloud customers is: • Improving live analysis techniques Live analysis examines an active rather than a shutdown system e.g. .memory forensics [36, 37] in which the memory structures of a live system is examined. Memory forensics is one prime example of how a snapshot of a virtual machine image could be analyzed. So with the current state of cloud technology, forensics must often be performed on the running system (e.g., because a snapshot is not available). • Improving log generation & analysis techniques With cloud computing, log file analysis used especially for PaaS and SaaS, the majority of all available information about an incident will be contained in log files. It is therefore essential to improve on the generation of logging information (how to make sure that an application log contains enough information to allow for successful analysis of a broad range of incidents) as well analysis techniques for logging information (e.g., how to interpret and correlate logging information from varying – often proprietary – sources). C. Containment, Eradication, and Recovery After determine of incident analysis some assets are affected, measures must be taken to contain the incident, i.e., prevent the spreading of the incident to hit her to unaffected assets. Then, the next important step is to eradicate the incident: the attack vector has to be closed and possible manipulations carried out by the attacker to keep and extend control have to be reverted [7]. And finally, recovery brings operations back to a normal, secured state. Hence now each step can be discuss in terms of each service layer of cloud system as: 1. IaaS Scenarios: In an IaaS setting, an incident scenario is that „a virtual machine image‟ has been compromised by an attacker. So as first step “containment” is carried out in the corresponding non-cloud setting – the compromise of a server – is to limit or cut network connectivity, where “limiting “must be understood as a wide range of possibilities, ranging from blocking communication with certain network parts to routing traffic via an active device such as a honeywall [38] in order to observe and selectively block traffic. For a different course of action, the cloud setting actually is very beneficial for eradication and recovery may be aided by the cloud setting e.g. virtualization i.e. if the point of time at which the compromise occurred can be established, the snapshot feature offered by virtualization could be used to revert the compromised virtual machine image to a non-compromised state. Such an approach, however, depends on well-established change management processes such that legitimate changes to the virtual machine image after a snapshot has been taken are tracked. For the arising incidents scenario, CSPs can help by offering the following services: • Ability to configure networking The more flexible the possibilities to configure networking are, the more options for containing an incident exist. • Access to halting and snapshot features of virtualization By providing a “snapshot and restore facility” to the customer, eradication and recovery activities can be supported. 2. PaaS and SaaS Scenarios: In a PaaS or SaaS setting, frequent incident scenario is that „application vulnerabilities‟ allow an attacker to compromise confidentiality and/or integrity of data processed in the application. So as first step, Containment reducing or completely removing functionality that allows the attacker to carry out unauthorized activities; if the critical functionality cannot be restricted, an alternative may be to closely monitor the functionality and then timely react to abuse. A frequently used work around when dealing with vulnerable web applications is to use web application firewalls to close known attack vectors until the root cause can be treated. So the ability for containment for the examined scenario in a PaaS and SaaS setting depend (a) on the granularity with which functionality and access rights can be configured and (b) the ability to implement work around, e.g., using a web application firewall. For Vulnerability has to be closed. For SaaS, this is clearly the obligation of the CSP, while for PaaS it depends whether the vulnerability lies in the customer‟s code or the implementation of API functionality that is provided by the CSP and used in the customer‟s code. An eradication & recovery step that definitely must be carried out by the customer is to purge the customer data in the application from the attacker‟s activity. The attacker may (i) precise logging information of all data changes and (ii) direct administrative data access rather than through the application‟s user interface is beneficial for the customer. So CSPs can help their customers in containment, eradication and recovery by offering the following: • Granular configuration of functionality and access rights The more gradual the configuration of functionality and access rights is, the higher the chance that vulnerable features in a SaaS application can be disabled in a limited scope that contains the incident but allows continued use of the application [7]. • Possibility to configure web application firewall If the CSP offers the customer the possibility to configure a web application firewall for his PaaS applications, it may be possible to carry out containment using detection and prevention possibilities of the web application firewall.
  • 7. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 142 • Direct read/write access to customer data By providing direct read/write access to customer data rather than only via the application GUI, eradication and recovery at the data level may be facilitated for the customer. D. Preparation and Continuous Improvement The preparation of the handling of incident and emerging risks and challenges is commonly done once an incident handling process is completed. In this phase the incident handling process is introduced within the corporate environment, SLAs are agreed with responsible parties, tools for analysis are evaluated, and interfaces between various entities are defined. After each and every incident, a “post mortem” should be conducted to identify, whether some aspect of security management in general or incident handling in particular must be changed. Also, if some aspect of the IT environment changes or is about to change, incident handling preparation has to be carried out to reflect these changes. The gradual shift towards cloud computing that many organizations are starting to carry out will bring about substantial changes of the IT environment that require renewed handling of incidents, risks preparation and emerged challenges. III. CLOUD COMPUTING RISKS, THREATS & VULNERABILITIES The words “Vulnerability,” “Threat,” “Risk,” and “Exposure” often are used to represent the same thing with even different meanings and relationships to each other. Hence each one can be describe as: “Vulnerability” refers to a software, hardware, or procedural weakness that may provide an attacker the open door to enter a computer or network and have unauthorized access to resources within the environment. It characterizes the absence or weakness of a safeguard that could be exploited. This vulnerability may be a service running on a server, unmatched applications or operating system software, or an unsecured physical entrance. A “Threat” is any potential danger to information or systems. The threat is that someone, or something, will identify a specific vulnerability and use it against the company or individual. Threats exploit existing vulnerabilities in an attempt to cause damage or destruct a resource. A “Threat Agent” is the entity that takes advantage of vulnerability. A threat agent could be an intruder, a process, or an employee making an unintentional mistake that could expose confidential information or destroy a file‟s integrity. A “Risk” is the likelihood of a threat agent taking advantage of vulnerability and the corresponding business impact. For example, if users are not educated on processes and procedures, there is a higher likelihood that an employee will make an intentional or unintentional mistake that may destroy data. Risk ties the vulnerability, threat, and likelihood of exploitation to the resulting business impact. An “Exposure” is an instance of being exposed to losses from a threat agent. Vulnerability exposes an organization to possible damages. If a bank does not properly patch its servers then it may be exposed to possible breaches in relation to the open holes resulting from the missing patches [34]. Now about Information security risks in Cloud Computing (CC) were subject for detailed analysis and assessment due to some efforts in this direction was realized by the European Network & Information Systems Agency (ENISA) [34]. ENISA classifies Cloud Computing which described as: 1. The organizational risks include all risks that may affect the structure of the organization or the business as an entity e.g. loss of business reputation due to co-tenant activities (or the tenants sharing the same resource), and any organizational change that can happen to the cloud provider (as a business organization) including provider failure, termination or acquisition. 2. The technical risks include problems or failures associated with the provided services or technologies contacted from the cloud service provider e.g. resource-sharing isolation problems, malicious (insiders or outsiders) attacks on the cloud provider, and any possibility of data leakage on download/upload through communication channels. 3. The legal risks refer to issues that surround data being exchanged across multiple countries that have different laws and regulations concerning data traversal, protection requirements and privacy laws e.g. risks resulting from possible changes of jurisdiction and the liability or obligation of the vendor in case of loss of data or business interruption. Generally Cloud Computing is based on a new utilization of technology and many risks like social engineering, physical security, lost or robbed backups, and loss or compromise of security logs are just a few examples of such general security risks also for a cloud. And Cloud Security Alliance (CSA) lists also following threats as the top risks associated with CC based on their recent research: malicious insiders, data loss/leakage, abuse and nefarious use of CC and shared technology vulnerabilities [16, 34]. Cloud Specific Vulnerabilities: According to such research, a particular vulnerability can be considered specific to cloud computing if it meets any of the following criteria: 1. It is intrinsic to or prevalent in a core technology of cloud computing, such as virtualization, service oriented architecture, and cryptography
  • 8. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 143 2. It has its root cause in one of essential cloud characteristics, such as elasticity, resource pooling, and pay-as-you-go model 3. It is caused by cloud innovations making exiting (tried and tested) security controls hard or impossible to implement; for example, management procedures that were created initially for a fixed hardware structure does not port correctly to virtual machines [15]. 4. It is prevalent in established state-of-the-art cloud services. Hence a relation among these words can be defined as- Risk = Vulnerability x Threat x Impact x Likelihood Generally the challenge in this paper sought to address was that of accurately differentiating aggregate data usage of legitimate clients from that of attack clients. Such a problem is difficult because requests only differ in the intentions of the attacker not in the structure or semantics of the request Figure 3: Relation between Cloud Computing Risks, Threats & Vulnerabilities Real World Examples: 1. Using IaaS to Host Crimeware 2. The Blue Pill Rootkit 3. Cloud Computing Outage and Data Loss IV. IMPLICATIONS In this paper, there are two main implications of the changes as identified. First, a cloud customer‟s incident handling requirements must influence cloud sourcing projects much more than currently is the case: incident handling must be reflected in the SLAs and the customer‟s incident handling capabilities must be adjusted such that incident occurring in cloud resources can be handled. And Secondly, research into improving and adopting incident handling for cloud computing must be carried out. A. Handling of Incident and Cloud Sourcing When contracting a cloud service, the capabilities and requirements of the customer on incident handling must be aligned with the incident handling capabilities of the CSP. • Identify relevant event sources For detection and analyze to security incidents, the most important basis for analysis and detection is event information – therefore, relevant event sources of the cloud service under consideration and the possibilities to add security-specific event sources must be identified. • Evaluate CSP’s level of support for detection and analysis Discussed above in section 2.1, CSP support for detection and analysis and provide the solution for following questions. Does the CSP provide access to the relevant event sources? Are the CSP‟s own incidents handling capabilities adequate? Are incidents that have been detected by or reported to the CSP communicated in a timely fashion? Does the CSP provide adequate access to information required during analysis? • Establish communication channels and exchange formats Efficient communication used to access event information and incident reports with the CSP‟s IH capability for analysis and response. Formats used for communicating event and incident information: the IH tools used at the customer‟s side such as incident tracking system and tools for event analysis must be able to work with the formats used by the CSP. • Evaluate interface to contain, eradicate, and recover an incident Probable incident scenarios suggest that certain standard mechanisms such as customer access to virtualization snapshot functionality, customer-configurable web application firewalls, direct data access, etc.
  • 9. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 144 B. A future work for IH in cloud computing Actually the majority of research in incident handling and detection on new techniques to handle risks and challenges focuses on the improvement of intrusion detection in the network and on the host. As on Current research in incident handling does not reflect the fact that cloud computing has a significant impact on incident handling processes, methods, and technologies. The approaches and challenges describe above provide the basis for a research agenda towards adapting handling of incident to the cloud. 1. Cloud SLAs for incident handling. This work provides many indications about issues regarding incident handling that should be treated in cloud SLAs. i.e. CSPs regarding incident handling support must be defined and included following work as future (1) the standardization of cloud security requirements such as the Common Assurance Maturity Model (the successor project of ENISA‟s Cloud Computing Assurance Framework [34]) or the Cloud Security Alliance‟s trusted cloud initiative [23] and (2) monitoring/controlling of SLA compliance in a cloud setting. 2. Generating and processing event information. Generation and processing of event information is at the heart of incident handling particular for the cloud. • Every cloud computing environment is built with differently techniques of cloud service providers and therefore a systematic approach towards identifying relevant events which support the detection and analysis of attacks must be developed. • Efficient handling of event information in a cloud requires accepted standards to generate for further event information. • Resource pooling leads to event sources with collection of information about many customers. It cannot make accessible to a single customer for incident detection and analysis: methods for generating customer specific event logs that contain as much information as possible yet do not violate the confidentiality/privacy requirements of other customers are required. C. Detection & analysis methods for the cloud The importance of ongoing work in the fields of detection and analysis of security incidents is increased by the using of cloud computing in future: • Virtual-machine introspection is uniquely sufficient for incident analysis in a cloud context and further research about virtual-machine introspection in general and its use for incident handling in the cloud should be conducted [7]. • To make the most of virtual-machine introspection and the snapshot feature of virtualization, more research in memory forensics must be intensified. • The collection of information via live forensics on running systems must be subjected to a systematic approach [7]. • Methods for incident detection and analysis based on event information such as log file correlation and visualization must be improved and adapted to the specific requirements on incident handling in the cloud. It is so important for handling to incident and risks in PaaS and SaaS service layers, where most relevant information will be available as event logs. • Detection methods that allow for detection with little or no information about the infrastructure that is monitored (e.g., web applications under customer control as treated by machine learning / anomaly-detection approaches to web- application firewalling) must be improved. V. CONCLUSION This paper describes the impact of cloud computing in real world for customers and cloud providers. By handling of various types of incidents, risks and challenges inside a cloud environment is a major work did in this paper. For the stages of handling of incident and risks that allow a general treatment, namely incident detection and incident analysis, problems are identified, risks are identified possible approaches are developed and (research) challenges are elicited. Hence for incident containment, eradication and recovery, problems and possible approaches are examined based on frequent incident scenarios. The paper shows that cloud computing will have a significant impact on handling and carrying out detection approaches and manage the security level inside a cloud environment. So to exchanging information inside a cloud, cloud customers must establish clarity about their requirements on CSPs for successful handling of incidents and contract CSPs accordingly; CSPs must strive to support these requirements and mirror them in their SLAs. As research into cloud, handling of incident and risks must focus more on current issues and challenges. So the comprehensive treatment of handling of incident and risks in the cloud as contained in this paper provides a basis for these activities. REFERENCES [1] Rajkumar Buyya, Chee Shin Yeo, and Srikumar Venugopal. "Market- Oriented Cloud Computing:Vision, Hype, and Reality for Delivering IT Services as Computing Utilities", HPCC, 2008 [2] Liang-Jie Zhang and Qun Zhou. "CCOA: Cloud Computing Open Architecture", IEEE International Conference on Web Services, 2009. [3] Kamal Dahbur et al. “A Survey of Risks, Threats and Vulnerabilities in Cloud Computing”, ACM , 2011 [4] George Resse, "Cloud Application Architecture", OReilly, 2009 [5] Balachandra Reddy Kandukuri, Ramakrishna Paturi V, Atanu Rakshit "Cloud Security Issues", IEEE International Conference on Services Computing,2009.
  • 10. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 145 [6] V.Krishna Reddy, Dr L.S.S.Reddy , “Security Architecture of Cloud Computing”, International Journal of Engineering Science and Technology (IJEST), September 2011 [7] Bernd Grobauer et al. “Towards Incident Handling in the Cloud: Challenges and Approaches” ACM, 2010. [8] Zachman, J.A. "A Framework for Information Systems Architecture." IBM Systems Journal, Volume 26, Number 3, 1987. [9] www.opengroup.org [10] Rajkumar Buyya, Rajiv Ranjan, and Rodrigo N. Calheiros "Inter Cloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services." Springer LNCS, 2010 [11] W. H. Baker et al. Verizon 2009 “Data Breach Investigations” Report, 2009. [12] D. Brezinski and T. Killalea. “Guidelines for Evidence Collection and Archiving”, RFC 3227, Feb. 2002. [13] D. Crocker. “Mailbox Names for Common Services, Roles and Functions”, RFC 2142, May 1997. [14] R. Danyliw, J. Meijer, and Y. Demchenko. “The Incident Object Description Exchange Format”, RFC 5070, Dec. 2007. [15] Y. Chen, V. Paxson, and R. H. Katz, “What‟s new about cloud computing security?” Technical Report UCB/EECS-2010-5, EECS Department, University of California, Berkeley, Jan 2010. [16] M. Christodorescu, R. Sailer, D. L. Schales, D. Sgandurra, and D. Zamboni. “Cloud security is not (just) virtualization security”, In Proceedings of CCSW 2009: The ACM Cloud Computing Security Workshop, Nov. 2009. [17] B. D. Payne, M. D. P. de Carbone, and W. Lee, “Secure and flexible monitoring of virtual machines”. In Computer Security Applications Conference, 2007. ACSAC 2007. Twenty-Third Annual, pages 385– 397, 2007. [18] PCI Security Standards Council. “Payment Card Industry (PCI) Data Security Standard v1.2.1”, July 2009. [19] N. Brownlee and E. Guttman, “Expectations for Computer Security Incident Response”, RFC 2350, June 1998. [20] R. M. Bryan Casper, “Incident response in virtual environments: Challenges in the cloud”, In 22nd Annual FIRST Conference, Miami, USA, June 2010. [21] W. Dawoud, I. Takouna, and C. Meinel, “Infrastructure as a service security: Challenges and solutions”, in The 7th International Conference on Informatics and Systems (INFOS). IEEE Computer Society, 2010. [22] H. Debar, D. Curry, and B. Feinstein., “The Intrusion Detection Message Exchange Format (IDMEF)”, RFC 4765 Mar. 2007. [23] Cloud Security Alliance,” Trusted Cloud Initiative”. http://www.cloudsecurityalliance.org/ trustedcloud.html. [24] The Open Group, “Distributed audit service (XDAS) – preliminary specification”, Jan. 1997. http://www. opengroup.org/bookstore/catalog/p441.htm. [25] M. West Brown, D. Stikvoort, et al. “Handbook for Computer Security Incident Response Teams (CSIRTs)”, Technical Report CMU/SEI-2003- HB-002, Carnegie Mellon SEI, 2003. [26] IT Governance Institute, Rolling Meadows, Illinois, USA. CobiT 4.1, 2007. [27] A. Khajeh-Hosseini, I. Sommerville, and I. Sriram, “Research challenges for enterprise cloud computing”. CoRR, abs/1001.3257, 2010. [28] R. Rounsavall, “Forensics considerations in the next generation cloud environments” In 22nd Annual FIRST Conference, Miami, USA, June 2010. [29] N. Ruff, “Windows memory forensics. Journal in Computer Virology”, 4(2):83–100, 2008. [30] T. Grance, K. Kent, and B. Kim. “computer security incident handling guide”, NIST SP800-61 [31] B. Grobauer, T. Walloschek, and E. St¨ocker, “Understanding cloud- computing vulnerabilities”, IEEE Security & Privacy, 2010. [32] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage, “Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds”, In CCS ‟09: Proceedings of the 16th ACM conference on Computer and communications security, pages 199–212, New York, NY, USA, November 2009. ACM. [33] S. Roschke, F. Cheng, and C. Meinel, “Intrusion detection in the cloud. In Dependable, Autonomic and Secure computing”, IEEE International Symposium on, volume 0, pages 729–734, Los Alamitos, CA, USA, 2009. IEEE Computer Society. [34] ENISA. “Cloud computing information assurance framework – ENISA”. http://www.enisa.europa.eu/ act/rm/files/deliverables/ cloud-computing- information-assurance-framework. [35] P. Mell and T. Grance, “Draft NIST working definition of cloud computing”, Aug. 2009. [36] A. Schuster, “Searching for processes and threads in Microsoft windows memory dumps”. Digital Investigation, 3(Supplement 1):10–16, 2006. The Proceedings of the 6th Annual Digital Forensic Research Workshop (DFRWS ‟06). [37] The CEE Board. Common event expression, 2008. http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_Jun e_2008.pdf. [38] “Honeynet Project & Research Alliance”, Honeywall CDROM Roo, Aug. 2005. http://www.honeynet.org. [39] “International Organization for Standardization”, Geneva, Switzerland. ISO/IEC 27002:2005 Information technology – Security techniques – Code of practice for information security management, 2005. [40] Microsoft. Computer Online Forensic Evidence Extractor (COFEE).http://www.microsoft.com/ industry/government/solutions/cofee/default. aspx. Deepak Kumar is currently working as Assistant Professor in Shivalik Institute of Engineering And Technology, Ambala, India. He completed his Bachelor of Technology degree in Information Technology from Uttar Pradesh Technical University, Lucknow, India, in 2009 and Master Degree from PEC Chandigarh in 2011. His research interests include Network Security, Robotics, VoIP, Mobile Computing, Natural Language Processing, and Artificial Intelligence. (Email id is: deepakum_n1987@yahoo.com). Amit Kumar Tyagi received his Bachelor of Technology degree in Computer Science and Engineering from Uttar Pradesh Technical University, Lucknow, India, in 2009. He is currently pursuing his Master‟s degree in Computer Science and Engineering in Department of Computer Science from the School of Engineering and Technology, Pondicherry University, India. His research interests include Network Security, Cyber Security, Denial-of Service resilient protocol design, VoIP, Mobile Computing, Cloud Computing, Smart and Secure Computing and Data Mining (Email id is :amitkrtyagi025@gmail.com).
  • 11. ISSN 2249-6343 International Journal of Computer Technology and Electronics Engineering (IJCTEE) Volume 2, Issue 2 146 Sadique Nayeem has received the B.Tech. Degree in Computer Sc. & Engineering from Biju Patnaik University of Technology (BPUT), Rourkela, India in 2009. He is pursuing M.Tech. degree in Computer Sc. & Engineering from Department of Computer Science and Technology, Pondicherry University, Pondicherry, India. . His research interests include Network Security, Mobile Computing, and Data Mining etc (Email id: sadiquenayeem@gmail.com).