Security Incident Information Exchange for Cloud Services

Christian Frøystad, Erlend Andreas Gjære, Inger Anne Tøndel and Martin Gilje Jaatun

Software Engineering, Safety and Security, SINTEF ICT, P.O. Box 4760, NO-7465, Trondheim, Norway

Keywords:

Incident Response, Cloud Computing, Accountability.

Abstract:

The complex provider landscape in cloud computing makes incident handling difﬁcult, as Cloud Service

Providers (CSPs) with end-user customers do not necessarily get sufﬁcient information about incidents that

occur at upstream CSPs. In this paper, we argue the need for commonly agreed-upon incident information

exchanges between providers as a means to improve accountability of CSPs. The discussion considers sev-

eral technical challenges and non-technical aspects related to improving the situation for incident response in

cloud computing scenarios. In addition, we propose a technical implementation which can embed standard

representation formats for incidents in notiﬁcation messages, built over a publish-subscribe architecture, and

a web-based dashboard for handling the incident workﬂow.

1 INTRODUCTION

Cloud computing offers its users a signiﬁcant amount

of beneﬁts such as increased agility, reliability,

easier and better scalability and elasticity, mainte-

nance, device and location independence, and re-

duced cost (Kalloniatis et al., 2014). Due to this, the

popularity of cloud infrastructure is understandably

on the rise among both smaller companies and multi-

national enterprises alike, further enabling start-up

companies to innovate with rapidly growing customer

bases without costly IT investments up-front.

While the beneﬁts of cloud computing are well

known, there are still drawbacks or challenges which

need to be taken into account by stakeholders look-

ing into adoption of such infrastructure. This paper

focusses on incident response, which is the process of

handling the occurrence of an incident from detection,

through analysis, containment, eradication & recov-

ery and preparation (Grobauer and Schreck, 2010).

These activities have increased in complexity since

the time when servers were physical machines run-

ning a single system for one organisation, possibly

at their own physical premises, too. A set of secu-

rity issues related to incident handling in the cloud

were examined by Grobauer & Schreck (Grobauer

and Schreck, 2010) back in 2010, who then called for

more research in several areas. In the years which

have passed since this paper, there has only been pub-

lished a little amount of research addressing those

challenges. Most of this, however, is mainly con-

cerned with digital forensics in the cloud, or more tra-

ditional incident response scenarios, and nothing on

the perspective of dealing with complex cloud pro-

visioning chains. In general, we ﬁnd a lack of aca-

demic attention paid to incident management between

independent companies and organizations involved in

cloud computing, and to giving the involved parties

sufﬁcient access to related data and event sources in a

timely manner.

Sharing of incident information has typically been

based on one-to-one trust relationships between Com-

puter Security Incident Response Team (CSIRT)

members in the relevant organisations. The actual ex-

change of incident information normally happen by

means of email, phone, incident trackers, help desk

systems, conference calls and face to face. With the

advent of cloud computing, however, the human el-

ement is much less prominent. A cloud service can

be made up of a chain of providers where none of

the CSIRT members have ever communicated directly

with a representative from any of the other providers.

In addition, an incident in the cloud may need to in-

volve different parts of the provider chain, potentially

even in an automated, real-time fashion, to minimise

business disruption (Gjære et al., 2014). This sets new

requirements to the way incident response needs to

be managed and supported by tools which are able to

communicate effectively across rapidly changing con-

stellations of organisations.

An essential challenge is that there is no single

part of the supply chain which has access to all events

and all areas to monitor, thus nobody can immedi-

ately see the full picture. In a survey conducted

Frøystad, C., Gjære, E., Tøndel, I. and Jaatun, M.

Security Incident Information Exchange for Cloud Services.

DOI: 10.5220/0005953803910398

In Proceedings of the International Conference on Internet of Things and Big Data (IoTBD 2016), pages 391-398

ISBN: 978-989-758-183-0

391

by Torres (Torres, 2014), little visibility into sys-

tem/endpoint conﬁgurations/vulnerabilities as such

was considered one of the top hindrances to effec-

tive incident response in their organisation. The cloud

actors therefore need to be able to communicate efﬁ-

ciently in order to provide each other with informa-

tion to ease detection or assist responding to an inci-

dent. It has also been claimed that attackers are better

at handling information sharing than those protecting

services and systems (Horne, 2014). This adds to the

importance of providing good tools and solutions to

incident handlers.

Laws are powerful incentives for changing be-

haviors in entire industries within a country. When

large unions, like the United States or the European

Union, introduces quite similar laws, this affects the

entire western world and also, to some degree, the

rest of the world (Greenleaf, 2012). The introduc-

tion of new regulations in Europe, like the General

Data Protection Regulation (GDPR) and Network In-

formation Security (NIS), increases the need for an ef-

fective way of exchanging incident information. Due

to the substantial ﬁnes mandated by the GDPR, ser-

vice providers are given an incentive to ensure accu-

rate and timely notiﬁcation about breaches relating to

personal information. Laws are not only an incentive,

but sometimes also a hindrance or at least an obsta-

cle. The difference between laws covering personal

information, could complicate information exchange.

2 BUSINESS ASPECTS

In order for an incident exchange solution to be use-

ful, it needs to be adopted by businesses and CSPs.

Given how most businesses strive to improve their ﬁ-

nancial results, it is likely that for the system to be

adopted, one of the following criteria must be ful-

ﬁlled:

• Use of the solution results in reduced costs or in-

creased revenue – directly or indirectly

• Actors are required by law to use a system that

has functionalities such as those described in this

paper

More efﬁcient incident response, e.g. by increased

automation of response to common and simple inci-

dents (Metzger et al., 2011), can result in a ﬁnancial

beneﬁt. Additionally, professional incident notiﬁca-

tion schemes can strengthen the provider’s reputation

as an accountable and trustworthy provider. However,

the sharing of incident information can also be con-

sidered risky for a provider. Traditionally, incident

information has mostly been shared directly between

people with a direct trust relationship, i.e., who know

each other personally. In vendor and outsourcing re-

lationships, organizations thus take many measures to

build trust in order to facilitate incident information

exchange (Jaatun and Tøndel, ). It may not be pos-

sible to achieve the same level of trust between or-

ganizations as between individuals. Cloud providers,

however, cannot rely on individual trust relationships,

but need to establish trust on an organizational level

and exchange incident information based on that trust.

Bandyophyay et al. (Bandyopadhyay et al., 2009)

divides costs of cyber-incidents into two broad cate-

gories: primary and secondary losses, where primary

losses refer to direct loss and operating loss and sec-

ondary losses refer to any second-degree effects that

is indirectly triggered by information concerning the

security of the company (e.g. reputation damage or

credit rating). Several factors may impact the cost.

As an example, Bandyophyay et al. (Bandyopadhyay

et al., 2009) explains how a decision to report the in-

cident to an insurance company can increase the cost

associated with the incident: the reporting may result

in the breach becoming known to external parties, and

thus secondary losses is experienced. Cloud providers

may be reluctant towards sharing incident information

for similar reasons. In addition, there may be a need to

share information on the incident before the incident

is fully understood, including the cause of the inci-

dent. Revealing incident information may thus, in the

worst case, give information to any attackers on the

impact of their attack. Technological solutions that

provide secure means to distribute incident informa-

tion can to some extent reduce the risk of sharing inci-

dent information, as providers can have an improved

overview of who has received what information re-

garding the incident. Terms regarding sharing and re-

ceiving incident information can also be covered in

contracts.

3 FUNCTIONAL

CONSIDERATIONS

We have investigated functional aspects of how inci-

dent information should be represented and shared.

The following provides an overview of how these as-

pects relate to cloud computing scenarios in particu-

lar.

3.1 One Format to Rule them All?

In order to ensure that every part of the cloud supply

chain is able to understand the information sent, we

believe it is necessary to agree on a deﬁnition of an

IoTBD 2016 - International Conference on Internet of Things and Big Data

392

incident and its data elements. This would allow for

easier development and deployment of new systems

as well as increase interoperability, as one would not

have to conform to multiple different deﬁnitions and

data sets, but can rely on one base format. At the same

time, if an organization needs a different representa-

tion internally, this should still be possible as long as

it is feasible to translate this representation into the

common representation.

Schneier (Schneier, 2014) claims that “Incidents

aren’t standardized; they’re all different.” NIST (Ci-

chonski et al., 2012) further state that each CSIRT

team must choose their own list of required data el-

ements, based on factors like team model, team struc-

ture and how the team deﬁnes an incident. This raises

the question of whether it is actually possible to rep-

resent every incident in one format, or if it is a bet-

ter approach to allow multiple formats and thus allow

for specialization. By using only one format that is

able to represent everything, one could, theoretically,

know that all conforming implementations would be

able to understand any incident received and be able

to handle it automatically, if desired. On the other

hand, the format would be very complex, as it needs

to include mechanisms to represent all possible rele-

vant information for any incident imaginable.

We have found the Incident Object Descrip-

tion Exchange Format (IODEF) (Danyliw et al.,

2007) and Structured Threat Information eXpression

(STIX) (Barnum, 2012) to be comprehensive for-

mats for expressing incidents. They can support most

properties included in other relevant formats, like

eCrime (Cain and Jevans, 2010) and Cyber Observ-

able eXpression (CybOX) (The MITRE Corporation,

2015), but also brings along noteworthy challenges.

The formats are complex, making them difﬁcult to un-

derstand for humans.

On the other hand, an option can be to only trans-

fer unstructured text messages between parties in the

cloud supply chain. This would reduce the solution

to be a secure “email” system, and thus in accordance

with how incident information is mostly exchanged

today (Frøystad, 2014). The ability to provide free

text would allow the parties to exchange any informa-

tion required, but they would have to agree on a spe-

cial formatting for the text if planning to support auto-

matic handling of incidents. This would make it eas-

ier to implement the solution, and thus reduce initial

adoption costs. Notable drawbacks of this approach

include fragmentation in message formatting, leading

to potential difﬁculties for humans in interpreting or

encoding incident information.

A middle ground would be to have a small base

format, with the ability to represent the most common

information in a simple way and providing a struc-

tured way of attaching other incident formats such

as those mentioned above. This allows for reuse of

existing incident formats, specialization, incremental

implementation, and ﬂexibility to support newer for-

mats.

3.2 Notiﬁcation

At some point, the CSP experiencing an incident

needs to notify its cloud customers – that is other

providers in the cloud supply chain buying services

from the CSP. This could be because required by law,

legal agreements with the cloud customer or because

the CSP strives to be accountable. One approach is to

decide which notiﬁcations to send a-priori by the mu-

tual agreement between provider and customer, which

each make sure that they exchange the necessary in-

formation to fulﬁl the relevant laws and provide sufﬁ-

cient data for information exchange to be useful.

Another approach could be that the provider de-

cides which notiﬁcations to send, without the cloud

customer’s inﬂuence. This could include notiﬁcations

with a core message like: “We have been breached,

but your data was not compromised.”

A hybrid, combining the two, would allow the

mutual agreement to be created by the provider list-

ing which types of incidents the cloud customer is al-

lowed to access, and the cloud customer subscribing

to the incident types he needs. In order to allow the

cloud provider to fulﬁl any legal obligations to notify

the cloud customer, he could, when obligated by law,

send such notiﬁcations whether the cloud customer

subscribes to them or not.

Figure 1 shows an example of the relationship be-

tween service providers and services used, and thus

provides an example of the amount of unneeded or

unwanted incident information a subscriber could re-

ceive if the deﬁned triggers are not taken into account.

E.g. in the case of cloud B, it only uses a fraction of

the services offered by cloud C and D. If cloud B was

notiﬁed about all incidents at C and D, this would in-

clude a large amount of unneeded information relat-

ing to services not in use by cloud B. Additionally

if cloud D has thousands of customers, the overhead

of negotiating and deﬁning which incident informa-

tion to share would become noticeable. Therefore, it

is expected to be better to use the hybrid approach,

where the subscriber deﬁnes what he wants to be no-

tiﬁed about and the provider additionally pushes all

information required by law to the subscriber by us-

ing mandatory notiﬁcations that could be deﬁned for

each subscriber.

Security Incident Information Exchange for Cloud Services

393

Figure 1: Data ﬂow in supply chain. Each cloud represents

a service provider. Each coloured square represents the ser-

vices used by the subscriber. The coloured square inside

each stippled square, represents the data or parts of the ser-

vices actually used by the subscriber.

3.3 Propagation of Incidents

Incidents which affect one CSP could in turn af-

fect other CSPs, and hence be propagated. Two ap-

proaches to representing propagated incidents have

been considered. The ﬁrst approach embeds the par-

ent incident in an unchanged manner, allowing all re-

cipients of a derived incident – an incident created

based on information from another incident – to ac-

cess all of the information received by an earlier link

in the supply chain. At ﬁrst glance, this seems like

a valid approach and one that could result in bet-

ter cooperation, faster response time and better inci-

dent handling as a result of access to more and bet-

ter information. However, if all information from one

provider is passed on to entities further down in the

chain by a receiver, this would limit trust as the en-

tity sending the incident information would not know

who receives it. Given the potentially sensitive nature

of information related to security incidents, there is a

real possibility this would result in the system not be-

ing used or only superﬁcial information being shared.

To allow the incident sender to be more in con-

trol of his incident information, a better approach is

to only reference the parent incident when propagat-

ing down to a subscriber of a subscriber. In this way,

only relevant information would propagate directly,

through the actions of an entity, while there would

still be a hard link to follow in order to establish ex-

actly what happen during the incident handling. This

could, e.g., be useful when auditing a provider or dur-

ing criminal investigations.

4 SPECIFICATION

In order to allow cloud providers and cloud customers

to exchange security incident information, we ex-

amine an incident exchange format and subscription

based Application Programming Interface (API). A

standardised format would allow for increased au-

tomation of incident response tasks, yet it does not re-

quire automation to be implemented anywhere. Only

the interface provisioned by notiﬁcation publishers

need to be deﬁned, while the implementation of the

underlying functions can be up to the implementers,

and can vary between different actors.

The examination only deals with notiﬁcations be-

tween cloud providers and cloud customers, not noti-

ﬁcations to end-users. If e.g. Dropbox uses Amazon

S3 for storage of ﬁles, Dropbox is in the best posi-

tion to know which end users to notify in the event

of an incident happening at Amazon. Thus, this work

contributes to notiﬁcation of end users by allowing in-

cidents to propagate the cloud supply chain, while not

directly handling the end user notiﬁcation itself.

4.1 Notiﬁcation Message Format

For the content of the incident notiﬁcation messages,

we propose a core format which supports manual in-

cident handling as well, i.e. the case where the in-

cident notiﬁcation is read and acted upon by a hu-

man. Essential here is the capability to keep track of

e.g. where an incident has occurred and how it may

be correlated with other incidents, to make the noti-

ﬁcation system well suited for complex networks of

services. In order to support automation, i.e. when

a service could adapt itself during runtime to miti-

gate a threat (Gjære et al., 2014), we also make it

possible to attach more structured and standardised

formats to the message. A goal with our work is to

keep the complexity to a minimum so that even small

organisations/start-ups should be able to implement

and utilise cloud incident notiﬁcation tools. While

some organisations only need manual handling, we

retain the possibility to support more extensive for-

mats needed for automation, at the same time facili-

tating specialisation and forward compatibility.

The ﬁelds included in the core format are based

on a review of the RFC 5070 standard for an

IODEF (Danyliw et al., 2007), the Federal Inci-

dent Notiﬁcation Guidelines (US-CERT, 2014), the

EU Commission Regulation No 611/2013 (Europea-

nUnion, 2013), STIX (Barnum, 2012), and a shared

mental model for incident response teams described

by Flodeen et al. (Floodeen et al., 2013).

The incident is associated with an incident

type, and in addition its status is described (re-

solved/unresolved). The provider can give an esti-

mate of the consequence of the incident (as a ﬂoat

number), and the meaning of this estimate is deter-

mined by the SLA. A short written summary of the

incident, as well as possibly a more detailed descrip-

tion can be provided. In addition the (guessed) oc-

IoTBD 2016 - International Conference on Internet of Things and Big Data

394

currence time of the incident as well as the time the

incident was ﬁrst detected are provided. The parent

ﬁeld provides traceability for propagated incidents,

and the liaison ﬁeld contains relevant contact infor-

mation for this incident. By using the optional tlp

ﬁeld, a provider can instruct the receiving cloud cus-

tomer on how to handle the received incident infor-

mation. Given the difference between ENISA’s Traf-

ﬁc Light Protocol (TLP) (ENISA, 2015) and the TLP

described by US-CERT (US-CERT, 2015), it is pos-

sible to state which schema is used. The format also

allows the sender to specify a different TLP value for

speciﬁc ﬁelds. For any ﬁeld not added speciﬁcally to

the ﬁelds array, the main TLP value applies.

4.2 Custom Fields and Attachments

Our preliminary approach uses a small base format,

with the ability to represent the most common in-

formation in a simple way, while providing a struc-

tured way of attaching other incident formats such as

IODEF and STIX. In addition, the format supports

custom ﬁelds, which allow the provider and the sub-

scriber to agree upon extra information to be included

in the base format without altering its base structure.

This allows for two levels of implementation, as well

as support incremental development of the highest

level. Level 1 would only implement the base format,

and thus only be suitable for incident handling where

there are humans acting on the incident reports. Level

2 would implement different attachment formats, and

thus be able to support more automation of incident

handling. This allows for reuse of existing incident

formats, specialization , incremental implementation

, ﬂexibility to support new formats, and the possibility

to exchange evidence in the case of a forensic investi-

gation.

Having a deﬁned set of incident formats, agreed

upon between the provider and subscriber through

Service Level Agreements (SLAs), simpliﬁes the im-

plementation as a cloud customer would only have

to support the attachment formats agreed upon with

the cloud provider and the cloud provider only the

formats agreed upon with its customers. Thus not

all cloud providers and customers have to support

all incident formats, but still gives ﬂexibility to the

provider and the subscriber in identifying the for-

mats most suitable for their use case and apply

those.Custom ﬁelds allow providers and subscribers

to agree on extra information to include in the base

format without changing its structure. This is an easy

way of exchanging a few extra values that the sub-

scriber wants, but without the overhead of a large in-

cident representation format. There are multiple ways

custom ﬁelds could be implemented, including allow-

ing any values to be included in any format, allowing

only a predeﬁned set of basic data values, and provid-

ing data building blocks that allow representation of

anything in a structured way.

By allowing only basic data types, such as String,

Integer, and Boolean, use of custom ﬁelds where at-

tachments should have been used would become less

likely, but still possible through abusing the String

value ﬁeld. Explicitly stating the type of the value

in the ﬁeld would make it easier for the subscriber to

interpret the value. A potential problem with this ap-

proach is the reduced ﬂexibility, though it might be

argued that attachments should be used for anything

more complex than including simple values. Thus

only basic data types are allowed.

Table 1: REST interface for our solution.

Resource URI METHOD

Incident types /incidents/types

GET

POST

DELETE

Incident type /incidents/

types/{id}

GET

POST

DELETE

Trigger types /incidents/

types/{id}/

triggers/types

GET

POST

DELETE

Trigger type /triggers/types/

{id}

GET

POST

DELETE

Subscriptions /subscriptions

GET

POST

Subscription /subscription/

{id}

GET

POST

DELETE

Subscription

incidents

/subscriptions/

{id}/incidents

GET

POST

Subscription

incident

/incidents/{id}

GET

POST

DELETE

Notiﬁcation

triggers

/incidents/{id}/

triggers

GET

POST

Notiﬁcation

trigger

/triggers/{id}

GET

POST

DELETE

Notiﬁcation

validation

/notifications/

validate

POST

4.3 Prototype

The customers of a cloud provider may have vary-

ing preferences when it comes to which systems, ser-

Security Incident Information Exchange for Cloud Services

395

vices and incident types they are interested in notiﬁ-

cations for, as well as which thresholds for severity

these should operate in relation to. Supporting such

individual preferences can be accommodated by pub-

lishers e.g. through offering customers a subscription

mechanism. The individual provider will obviously

need to have the ﬁnal say as to what information their

customers are allowed to receive, regardless of pref-

erences.

The API is implemented through Representational

State Transfer (REST), which acts as an adapter pat-

tern (Gamma et al., 1994) so the system is allowed

to function on every platform as long as they imple-

ment the API and provide the mechanisms needed to

support REST. Reducing coupling to a minimum in-

creases ﬂexibility, modiﬁability and portability, and

makes it easier to adopt the solution also for estab-

lished systems and solutions. A list of all endpoints

along with their HTTPS method can be found in Ta-

ble 1. The prototype can be found at (SINTEF-

Infosec, 2016).

5 INTERVIEWS

Catalyzed by the dashboard prototype, we have con-

ducted two focused interviews with experienced inci-

dent handlers from two organisations to evaluate our

approach. The participants both found the incident

format to be mostly complete, but mentioned some

special ﬁelds which could be useful in the base for-

mat. An indication on the time of next update was

brought up in both interviews. An estimate on the

expected time of correction, and the channel from

which the incident report originally was received,

was further mentioned as frequently useful informa-

tion. In addition, adopting the Trafﬁc Light Protocol

(TLP) (US-CERT, 2015)(ENISA, 2015) was consid-

ered relevant for classifying conﬁdentiality between

parties, in terms of redistributing message contents.

This was addressed in this iteration of the prototype.

A way to relay recommended actions to the subscriber

was also mentioned as important. These suggestions

should be examined further, and be included if there

is a common need for them among incident handlers.

Given that other participants in the cloud delivery

chain supported the REST interface and the incident

format, the participants would ﬁnd it useful for noti-

fying customers. One participant also mentioned the

possibility for such a solution to improve the amount

and quality of reports to national Computer Emer-

gency Response Teams (CERTs). What was missed

from the interface was a way of requesting further in-

formation and reply to a report within the system. One

participant suggested using a comment section avail-

able to all recipients of an incident, thus avoiding the

sender having to respond to the same questions mul-

tiple times and allow collaboration between receiving

incident handlers.

6 DISCUSSION

Here, we will discuss adoption, beneﬁts for small and

larger organizations, how our solution facilitates early

decision making on sharing, comparing our solution

to previous research and industry efforts and ﬁnally

the need for further research.

Our main contribution is a simpliﬁed method of

incident sharing, making it available for organizations

of all sizes, while still allowing for implementing a

large ecosystem with automation if so desired. While

the proposed approach does not facilitate all cloud

providers and customers in understanding all mes-

sages at any link in the chain, it ensures that all par-

ticipants in the chain understand the information they

are eligible to receive by requiring each link to be in-

teroperable with its adjacent links.

In Section 2 it was pointed out that adoption of

such an incident notiﬁcation tool will likely depend

on businesses expecting a positive economic impact

from using it. The proposed solution is unlikely to

contribute directly to a higher revenue stream, but

might contribute indirectly. If a CSP, or any other

organization adopting this solution, is diligent in shar-

ing information about incidents, this could contribute

to building an image of trustworthiness and profes-

sionalism. Such an image could in turn result in

more customers, and thus increased revenue. A Level

1 implementation, that is exchange of security inci-

dent information without any automation in incident

handling, is unlikely to result in signiﬁcantly reduced

costs. However, the solution has been designed with

implementation cost in mind, so the cost of adopt-

ing the solution should be quite low. The incremental

nature of the solution allows implementers to gradu-

ally introduce more formats and also automation. As

the implementation progresses into a Level 2 imple-

mentation, with an increasing amount of automation,

the reduced costs are expected to become noticeable.

Metzger et al. (Metzger et al., 2011) claim that more

than 85 % of abuse cases can be partly or fully auto-

mated, which in turn would free up resources allow-

ing for reduced costs.

“Even the smallest organizations need to be able

to share incident information with peers and partners

in order to deal with many incidents effectively” (Ci-

chonski et al., 2012). An important consideration

IoTBD 2016 - International Conference on Internet of Things and Big Data

396

taken when creating the proposed solution, was that it

should be feasible for even small organizations to im-

plement, utilize and receive value. The two level im-

plementation allows for smaller organizations to reap

a subset of the potential beneﬁts, while larger orga-

nizations implementing full automation reaps the full

set of potential beneﬁts.

NIST (Cichonski et al., 2012) state that “The inci-

dent response team should discuss information shar-

ing with the organizations public affairs ofﬁce, legal

department, and management before an incident oc-

curs to establish policies and procedures regarding

information sharing.” Our proposed solution facili-

tates such decisions to be taken before incidents oc-

cur, as subscribers are able to subscribe to incident

types made available to them by the CSP. Thus, the

CSP needs to have decided beforehand which inci-

dent types each subscriber is allowed to subscribe to.

In addition, each organization is free to decide how to

implement the backend and can thus require a man in

the loop, allowing for a second screening of incidents

before they are sent to subscribers.

Comparing the approach presented in this paper

with previous research efforts on sharing incident in-

formation, Cusick and Ma (Cusick and Ma, 2010) de-

scribe a solution conceptually similar to the one pro-

posed here, but for internal use in the organization.

Users might subscribe to be notiﬁed when events are

created or changed, which has lead to improved com-

munication around the incidents. The authors state

that this feature alone made it worth their while to

create a new process and implement new tooling. Our

proposal takes this one step further, and allows other

entities to be notiﬁed just as easily as the human sub-

scribers.

As mentioned, both STIX and IODEF are excel-

lent formats in their own respect. Still our main prob-

lem with both of them comes down to the general-

ized complexity and overwhelming scope. When a

collection of large formats are supposed to represent

everything, even the simple cases, this is likely to cre-

ate some overhead in situations where what is rep-

resented does not ﬁt the format. It seems like both

have tried to counter this effect by making some ﬁelds

optional, but Floodeen et al. (Floodeen et al., 2013)

has found incident handlers in practice enters all in-

formation required by a system or a standard, rather

than only the necessary information based on situa-

tion. Thus making ﬁelds optional will have a limited

effect on which ﬁelds are used unless the tool strictly

regulates which ﬁelds are presented to the incident

handler.

Cusick and Ma had a different experience from

that described by Flooden et al. (Floodeen et al.,

2013). Cusick and Ma found that engineers entered

the minimum amount of information required and of-

ten just closed the ticket when it was handled without

any information about steps taken to solve the inci-

dent. This problem will not be solved by the solution

proposed here; if anything it will become more appar-

ent and pressing. Compared to e.g. STIX the format

presented in this paper is in danger of going too far in

the opposite direction, which might result in overhead

for the incident handler in deciding which information

to enter – since the format does not necessarily ask for

all the necessary information. Depending on the rela-

tionship between two parties exchanging incident in-

formation, it might be alarming for one party to never

receive any information other than “we have an inci-

dent – it was solved”. This might lead the consum-

ing organization to wonder if the incident has really

been handled at all, and thus affect the trust between

the two organizations. To solve this problem, organi-

zations will probably need to consider the organiza-

tional culture as well as the use of pre-deﬁned custom

ﬁelds on the incident types which might serve as a

way to mitigate this effect. The backend implement-

ing this speciﬁcation will also need to assist the in-

cident handler in generating the relevant attachments

when needed.

Still, there are many equally important challenges

to tackle in order for sharing of security incident in-

formation to become common. Some of these are:

trust, company culture, security in information shar-

ing (like utilising broadcast encryption and signing of

incident notiﬁcations), new mechanisms of collabora-

tion, laws and SLAs. The interface we present here

is simple enough to be used to facilitate further re-

search into several of these areas. Our initial ﬁnd-

ings, from our limited number of interviews, indicate

the need for a larger survey to be conducted on the

ﬁelds included in the base format in order to learn

more about its completeness and eventually which ad-

ditional ﬁelds to include.

7 CONCLUSION

Incident information exchange is, at present, largely

a manual exercise between two individuals who trust

each other, via e.g. email, phone, or help desk sys-

tems. The same methods are prominent in both in-

house and cloud chains – if ever incident informa-

tion is exchanged at all. There are however legal re-

quirements and contractual obligations which in some

cases cements the need to exchange incident informa-

tion in an effective manner.

The examination conducted in this paper is a ﬁrst

Security Incident Information Exchange for Cloud Services

397

step in the direction of more effortless incident infor-

mation exchange by means of formalistic and deter-

ministic channels. Here we facilitate a direct connec-

tion between two parties in the supply chain, allowing

for automated and/or manual handling of exchanged

incident information. The proposal also allows for

easy integration with existing systems and solutions,

as well as use of internationally standardised message

formats for possibly handling adaptation of services

automatically during runtime.

ACKNOWLEDGEMENT

This research is funded by the European Commis-

sion’s Seventh Framework Programme (FP7/2007-

2013) under grant agreement no: 317550 A4Cloud

– Accountability For Cloud and Other Future Internet

Services.

REFERENCES

Bandyopadhyay, T., Mookerjee, V. S., and Rao, R. C.

(2009). Why it managers don’t go for cyber-insurance

products. Commun. ACM, 52(11):68–73.

Barnum, S. (2012). Standardizing cyber threat intelligence

information with the Structured Threat Information

eXpression (STIX). Technical report, The MITRE

Corporation.

Cain, P. and Jevans, D. (2010). Extensions to the IODEF-

Document Class for Reporting Phishing. Technical

report, IETF.

Cichonski, P., Millar, T., Grance, T., and Scarfone, K.

(2012). Computer Security Incident Handling Guide:

Recommendations of the National Institute of Stan-

dards and Technology, 800-61. Revision 2. Technical

report, National Institute of Standards and Technol-

ogy.

Cusick, J. J. and Ma, G. (2010). Creating an ITIL inspired

Incident Management approach: Roots, response, and

results. In Network Operations and Management Sym-

posium Workshops (NOMS Wksps), 2010 IEEE/IFIP,

pages 142–148. Ieee.

Danyliw, R., Meijer, J., and Demchenko, Y. (2007). The

Incident Object Description Exchange Format.

ENISA (2015). Information disclosure.

EuropeanUnion (2013). Commission regulation (eu) no

611/2013 of 24 june 2013 on the measures applica-

ble to the notiﬁcation of personal data breaches under

directive 2002/58/ec of the european parliament and

of the council on privacy and electronic communica-

tions. Technical report.

Floodeen, R., Haller, J., and Tjaden, B. (2013). Identify-

ing a shared mental model among incident responders.

Proceedings - 7th International Conference on IT Se-

curity Incident Management and IT Forensics, IMF

2013, pages 15–25.

Frøystad, C. (2014). Exchange of security incident infor-

mation in the context of cloud services. NTNU Minor

Thesis Report.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994).

Design patterns: elements of reusable object-oriented

software. Pearson Education.

Gjære, E. A., Per, H., and Vilarinho, T. (2014). Notiﬁ-

cation Support Infrastructure for Self-Adapting Com-

posite Services. In DEPEND 2014, The Seventh In-

ternational Conference on Dependability, number c,

pages 17–24, Lisbon, Portugal.

Greenleaf, G. (2012). The inﬂuence of European data pri-

vacy standards outside Europe: implications for glob-

alization of Convention 108. International Data Pri-

vacy Law, 2(2):68–92.

Grobauer, B. and Schreck, T. (2010). Towards Incident

Handling in the Cloud :. In Proceedings of the 2010

ACM Workshop on Cloud Computing Security Work-

shop, pages 77–85, Chicago, Illinois, USA. ACM.

Horne, B. (2014). On Computer Security Incident Re-

sponse Teams. Security & Privacy, IEEE, 12(October

2014):13–15.

Jaatun, M. G. and Tøndel, I. A. How much cloud can you

handle? In ARES 2015.

Kalloniatis, C., Mouratidis, H., Vassilis, M., Islam, S.,

Gritzalis, S., and Kavakli, E. (2014). Towards the de-

sign of secure and privacy-oriented information sys-

tems in the cloud: Identifying the major concepts.

Computer Standards & Interfaces, 36(4):759–775.

Metzger, S., Hommel, W., and Reiser, H. (2011). Integrated

Security Incident Management – Concepts and Real-

World Experiences. In 2011 Sixth International Con-

ference on IT Security Incident Management and IT

Forensics, pages 107–121. Ieee.

Schneier, B. (2014). The Future of Incident Response. Se-

curity & Privacy, IEEE, 12(October):95–96.

SINTEF-Infosec (2016). SINTEF-Infosec/Incident-

Information-Sharing-Tool. [Online; accessed

2015-12-14.

The MITRE Corporation (2015). CybOX - Cyber Observ-

able eXpression.

Torres, A. (2014). Incident Response : How to Fight Back

A SANS Survey.

US-CERT (2014). Federal incident notiﬁcation guidelines.

Technical report.

US-CERT (2015). Trafﬁc Light Protocol (TLP) Matrix and

Frequently Asked Questions.

IoTBD 2016 - International Conference on Internet of Things and Big Data

398