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

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).