Accountability Requirements in the Cloud Provider Chain

Abstract

In order to be responsible stewards of other people’s data, cloud providers must be accountable for their data handling practices. The potential long provider chains in cloud computing introduce additional accountability challenges, with many stakeholders involved. Symmetry is very important in any requirements’ elicitation activity, since input from diverse stakeholders needs to be balanced. This article ventures to answer the question “How can one create an accountable cloud service?” by examining requirements which must be fulfilled to achieve an accountability-based approach, based on interaction with over 300 stakeholders.

1. Introduction

The inception of the computer era was led by corporate giants, and was for a large part reserved for large enterprises that could afford to pay for computer infrastructure. As such, it could hardly be considered symmetric; small actors were generally excluded from reaping the benefits of early computing. The emergence of cloud computing is providing new opportunities for business development, in many ways serving as the great equalizer, finally introducing symmetry between big and small online service providers. Unfortunately, cloud computing is exposing both customers and providers to new challenges (e.g., in terms of data management), which require a shift in the way Information and Communication Technology (ICT) is deployed in business contexts. Cloud customers and providers are exposed to various problems. For instance, from a resource viewpoint, it is necessary to improve data management processes and to a certain extent automate them. The increasing amount of data and resources requires new mechanisms that enable cost-effective management while guaranteeing critical features such as security and privacy. Challenges arise from the redistribution of responsibilities across cloud supply chains, e.g., because customers no longer can relate to a single provider of services, and may not even know the full chain of provides involved, as indicated in Figure 1.

Different stakeholders relate to and contribute to data governance in the cloud. Moving data from centralized and proprietary systems to the cloud involves a shift in responsibilities across organizational boundaries, raising questions such as:

• Who can access personal data?
• How can personal data be used?
• Who is responsible for data governance?

Although security and privacy threats affect any form of ICT (including cloud computing), moving to the cloud changes risk fundamentals (e.g., likelihood of occurrence and severity of impact) as well as risk perceptions of such threats. On the one hand, it is necessary to understand any limitations of technologies (e.g., security mechanisms) within cloud ecosystems. On the other hand, it is necessary to identify new mechanisms to enhance trustworthiness in the cloud. Moving to the cloud involves a change in control, a change in trust and security boundaries, and maybe also a change (or more complexity) in legal requirements [1].

Accountability for a provider can be seen as “doing the right thing”; being a responsible steward of other people’s information. An accountable provider defines how it manages information, monitors how it acts (to verify that it does what it says it does), remedies any discrepancies between the definition of what should occur and what is actually occurring, and explains and justifies any action [2]. Accountability can thus be seen as an important prerequisite for trust in online (cloud) services.

Many of the privacy and security challenges we face in the cloud are just variants of similar challenges in traditional computer networks [1], but one new aspect is the concept of long provider chains. In traditional outsourcing, the customer only has to relate to one provider where data processing and storage is performed in a single data center. In the cloud, a service provider will often re-use (parts of) another provider’s service, who in turn uses services from a third provider, and so on. The most well-known example of this is Dropbox (https://www.dropbox.com/) , which initially had no infrastructure of its own, but used processing and storage services from Amazon Web Services (https://aws.amazon.com/). Cloud and IT service providers should act as responsible stewards for the data of their customers and users. However the current absence of accountability frameworks for distributed IT services makes it difficult for users to understand, influence and determine how their service providers honor their obligations. Motivated by the current absence of accountability frameworks in the cloud and other future internet services, the A4Cloud project has developed tools and technologies that enable accountability for how personal and business confidential information is used in the cloud, taking into account the chain of responsibilities that needs to be built throughout the cloud service supply network.

The goal of this article is to highlight how different actors contribute to accountability in the cloud provider chain, and to document requirements that can help ensure such accountability. This article is based on an elicitation effort [3] that has involved more than 300 stakeholders who contributed to the identification of detailed accountability requirements; about half of these stakeholders participated in requirements elicitation workshops, and the other half in more dissemination-oriented events. This has allowed the project to gather requirements from different stakeholders, ranging from individual cloud customers to organizational cloud customers and cloud providers, additionally including data protection commissioners, auditors, consumer groups, trade bodies and SME organizations. The requirements elicitation workshops highlighted how stakeholders understand accountability and what their priorities and concerns are about data protection in the cloud.

The remainder of this paper is organized as follows: In Section 2 we present relevant background. We present the method employed in eliciting and analyzing requirements in Section 3, and the results in Section 4. We discuss our findings in Section 5, and conclude in Section 6.

2. Background

In the following, we enumerate the various cloud actors that exist in a cloud ecosystem. We then provide our definition of accountability, positioning our work in the existing accountability literature. We close this section by covering essential background on requirements engineering.

2.1. Cloud Actors

The A4Cloud project has analyzed and extended the different cloud roles for the actors in a cloud ecosystem. We have extended the well-known NIST cloud supply chain taxonomy [4] to create the following cloud accountability taxonomy composed of 7 main roles:

• Cloud Subject: An individual whose data are processed by a cloud provider, either directly or indirectly.
• Cloud Customer: An entity that (a) maintains a business relationship with, and (b) uses services from a Cloud Provider. When necessary we may further distinguish:

  (a)

  Individual Cloud Customer, when the entity refers to a person.

  (b)

  Organization Cloud Customer, when the entity refers to an organization.

• Cloud Provider: An entity responsible for making a cloud service available to Cloud Customers
• Cloud Carrier: The intermediary entity that provides connectivity and transport of cloud services between Cloud Providers and Cloud Customers.
• Cloud Broker: An entity that manages the use, performance and delivery of cloud services, and negotiates relationships between Cloud Providers and Cloud Customers.
• Cloud Auditor: An entity that can conduct independent assessment of cloud services, information system operations, performance and security of the cloud implementation, with regards to a set of requirements, which may include security, data protection, information system management, regulations and ethics.
• Cloud Supervisory Authority: An entity that oversees and enforces the application of a set of rules.

In our model, a Cloud Provider that uses the services of another Cloud Provider will then have the role of Cloud Customer with respect to that provider. This is illustrated in Figure 1, where there is a cloud provider chain consisting of three cloud providers; Provider A, Provider B, and Provider C. Provider A offers Service1 to a cloud end user customer. However, as part of Service1, Provider A needs to use Service2 offered by Provider B, and Provider A is thus a Cloud Customer with respect to Provider B. Incidentally, in order to provide its service, Provider B needs to use Service3 offered by Provider C, and Provider B is thus a Cloud Customer with respect to Provider C.

The provider chain in Figure 1 also illustrates the challenge related to security and privacy technologies to protect sensitive data; typically, the various service components in the chain (i.e., Service2 and Service3) will need to process data originating from or belonging to the end user, and even if Provider A has implemented security technologies that can prevent misuse of such data, those technologies will generally not be able to protect data stored and/or processed by Provider B and Provider C.

2.2. Cloud Accountability

Early work on accountability in the cloud was documented by Pearson et al. [5,6,7]. We have built on this in our previous work [2], but we have not been able to identify any systematic accountability requirements elicitation efforts prior to our own.

We define accountability [8] for an organization as follows:

Accountability consists of accepting responsibility for data with which it is entrusted in a cloud environment, for its use of the data from the time it is collected until when the data is destroyed (including onward transfer to and from third parties). It involves the commitment to norms, explaining and demonstrating compliance to stakeholders and remedying any failure to act properly.

This definition is further detailed by a set of accountability attributes [2,8]:

• Transparency: the property of an accountable system that it is capable of “giving account” of, or providing visibility of how it conforms to its governing rules and commitments.
• Responsiveness: the property of a system, organization or individual to take into account input from external stakeholders and respond to queries of these stakeholders.
• Responsibility: the property of an organization or individual in relation to an object, process or system of being assigned to take action to be in compliance with the norms.
• Remediability: the property of a system, organization or individual to take corrective action and/or provide a remedy for any party harmed in case of failure to comply with its governing norms.
• Verifiability: the extent to which it is possible to assess norm compliance.
• Attributability: the possibility to trace a given action back to a specific entity.
• Responsibility: the property of an organization or individual in relation to an object, process or system of being assigned to take action to be in compliance with the norms.
• Observability: the extent to which the behavious of the system is externally viewable.
• Appropriateness: the extent to which the technical and organizational measures used have the capability of contributing to accountability.
• Effectiveness: the extent to which the technical and organizational measures used actually contribute to accountability.

2.3. Requirement Engineering

The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended [9]. Broadly speaking, requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation. There are a number of inherent difficulties in this process [10]. First, stakeholders may be numerous and distributed. Second, the stakeholders’ goals may vary and conflict, depending on their perspectives of the environment in which they work and the tasks they wish to accomplish. Finally, the stakeholders’ goals may not be explicit or may be difficult to articulate, and, inevitably, satisfaction of these goals may be constrained by a variety of factors outside their control. For addressing these challenges we have followed an approach based on requirements by collaboration [10]. The approach focuses on meeting two essential needs: efficiently defining user requirements while building positive, productive working relationships.

3. Requirements Elicitation Method

The overarching goal of this paper is to determine how accountable cloud services may be created. Our approach to answering this question is to gather accountability requirements from stakeholders. We have engaged with a broad base of relevant stakeholders for elicitation purposes using different methodologies to elicit, refine and validate the requirements for the project.

This section starts by giving a high-level description of the four (groups of) elicitation activities in Section 3.1. The next subsection, Section 3.2 then describes the data collection activities performed in each activity, from A1 through A4. Finally, Section 3.3 describes how a requirement repository for collecting all the final requirements was constructed.

3.1. The Elicitation Activities and Events

Stakeholders were engaged through four groups of elicitation activities, as illustrated in Figure 2 and

Table 1. Overview of the four activities and events.

Activity	Goal	Method	Participants	Results
A1	Accountability relationships and requirements	Open Space Technology; World Café	7 participants; authorities, providers, customer, vendor	57 accountability relationships, later refined into 53 requirements
A2	Risk perception; relationship between accountability, risk and trust	Focus groups	20 participants; authorities, providers, customers, vendors, academia	15 requirements
A3	Expectations about accountability; experience with accountability mechanisms	Four workshops (different actors and tools; discussions and questionnaires); interviews	About 90 participants (30 subjects, 20 customers, 40 providers)	62 requirements
A4	Previously uncovered topics: metrics; incident response; opinions of legal experts	Workshops (discussions and questionnaires); email survey and informal conversations	About 60 participants: academia and IT professionals	23 requirements

. Activity A1 was concerned with identifying stakeholders’ notion of accountability and elicited initial accountability requirements. Then activity A2 dealt with risk perception, with the main aim to gather stakeholder views and best practices about the notion of risk and trust in the context of assessment of cloud services, future Internet services and dynamic combinations of such services (mashups). The activity covered how emerging threats in the cloud are perceived by stakeholders and the emerging relationships between accountability, risk and trust. The third activity (A3) addressed different stakeholders’ view and expectation of accountability mechanisms, and studied different stakeholders’ operational experiences and expectations about accountability in the cloud in relation to prototype tools offering such accountability mechanisms. A3 consisted of different sub-workshops that covered different aspects of the tools that were reviewed, and were tailored to specific cloud actors. Finally, the fourth activity (A4) covered aspects not previously touched upon in the other activities. Stakeholders were exposed to metrics for accountability and incident response management in a cloud computing setting. Furthermore, a small number of external legal experts provided input on high-level descriptions of the key accountability mechanisms [11], and gave feedback on how they expected associated tools to be received by cloud customers and providers.

In addition to the conventional elicitation workshops, we have exposed stakeholders to accountability tools and cloud accountability research results in a number of more dissemination-oriented events. Although no new requirements per se have been derived from these events, the discussion has served to confirm many of our previously elicited requirements.

3.2. Data Collection

As the group of cloud stakeholders is large and diverse, a stakeholder map was created to guide the selection of stakeholders for the elicitation events (see Figure 3). The elicitation activities aimed to collectively involve all these stakeholder groups.

3.2.1. Activity A1—Initial Requirements

For the A1 workshop, all partners in the A4Cloud project were asked to nominate potential stakeholders, and based on this process 51 stakeholders were invited, in addition to open invitations in relevant LinkedIn groups (notably, the Cloud Computing Association group (∼500 members) and the Cloud Security Alliance group (∼70,000 members)). Of twelve confirmed attendees, only 7 ended up participating in the workshop, representing data protection authorities (3), cloud providers (2), cloud customers (1) and cloud technology vendors (1).

The A1 workshop relied on Open Space Technology [12,13] and World Café [14]. The workshop technique Open Space Technology is recommended for complex situations involving diverse participants and the need for quick decision making. The technique is highly flexible, because the topics discussed are entirely determined by the participants. The participants are encouraged to suggest topics that are regarded as the most important issues, which make Open Space an inventive, creative, and productive method well suited for eliciting initial stakeholder requirements. First, the workshop facilitator presented the Open Space question: What would make you or the people you represent more comfortable in the cloud? The stakeholders were then invited to suggest topics to discuss during the open space. Six of the suggested topics were discussed (three sessions, two parallels). The stakeholder who suggested a topic was responsible for taking notes from the discussion using a given template and flip-charts. Researchers acted as observers during the discussion.

In the second part of the A1 workshop the discussions were arranged according to the world café methodology, with the goal of getting feedback on the business use cases being developed in the project. First, three use cases were presented; healt care services in the cloud, cloud-based ERP software, and multi tennant cloud. The presentation of the business use cases ended with the question what are the accountability issues in the business case? Then, in the main room, three tables were covered with grey paper. For each table and associated use case, one researcher acted as host. Stakeholders were encouraged to visit the table they found most interesting. The three hosts facilitated three discussions in parallel. Everyone participated in two discussions of 35 min.

The A1 session was reported as fun, interactive and interesting by the participants, and the conversations were lively and generated a lot of new knowledge both for project partners and invited stakeholders.

3.2.2. Activity A2—Risks

To account for the relatively low attendance of stakeholders at the A1 workshop, it was decided to have the A2 workshop in conjunction with the CSA EMEA Congress in Edinburgh, September 2013. The CSA EMEA Congress was the premier conference venue for professional cloud computing users interested in security, and attendees were likely to be interested in the workshop topic of cloud computing risk. The stakeholder list already prepared for A1 was revised, and 46 stakeholders were invited. The 46 stakeholders were based on professional contacts of the consortium members. Some non-responding stakeholders invited to the A1 workshop were removed from the list, and some new names were added. The stakeholders were informed about and invited to the workshop about six months in advance, with subsequent reminders. Furthermore, the organisers of the CSA EMEA congress published information about the workshop on their web site. Stakeholders who attended the A2 workshop include the following: cloud providers; companies that develop and provide services to cloud providers (e.g., service developers, hardware and software vendors, etc.); organizations that use cloud services (e.g., banks, e-commerce companies, food, health, etc.); and governmental and non-governmental regulatory and audit organizations. We also opened the A2 workshop to academia in order to broaden the knowledge base of the discussions. In the end, 20 people participated in this workshop.

Based on participants’ expressed interest in more technical detail, the A2 workshop provided a more structured agenda. Data collection was based on the focus group research technique [15,16], where a main advantage is the explicit use of group interactions to produce data and insight that would be less accessible without these interactions. Group discussions provide direct evidence about similarities and differences in the participants’ opinions and experience. It is possible to collect large and rich amounts of data on a given topic, and focus groups serves as a quick way to obtain information on emerging phenomena.

The A2 workshop consisted of four different sessions covering the following topics: security threats to cloud computing; risks related to each of the use cases from the A1 workshop; risk and trust modelling in cloud computing; and accountability-based approach to risk and trust modelling. Each focus group was moderated by one researcher that was supported by at least one observer. Three of the sessions were complemented by short questionnaires distributed at the end of the session.

3.2.3. Activity A3—Accountability Mechanisms

Within activity A3, separate workshops were held towards different stakeholder groups; cloud subjects, cloud customers and cloud providers. Two workshops involved cloud subjects. In one of these (the Karlstad workshop) invitations were sent to students at Karlstad University (KAU) to participate in a workshop on the use and opinions about Internet services and possible solutions on how to keep track of their personal data. In the other (the Trondheim workshop) invitations were sent to employees at the administration in the SINTEF research institute and students at the biology MSc program at NTNU (Norwegian University of Science and Technology). Participation was voluntary, but participants received breakfast and two cinema tickets. In the Karlstad workshop, 19 people attended the workshop, and in the Trondheim workshop eleven people did the same.

The questionnaire for the cloud subjects contained general questions regarding to what extent the participants use various cloud services, and would trust various cloud actors such as their bank, social media websites, airlines, and search engines. The cloud subjects were then asked about their opinion of the DataTrack tool, its perceived ease of use and effectiveness, and they were asked to rate the importance of various features of the tool.

For the A3 workshop towards cloud customers, invitations were sent to SINTEF’s contact list of software companies in Trondheim. Participation was voluntary, but at the end of the workshop we offered the participants a lunch. Eleven people attended the workshop. The same software companies, as well as some additional contacts, were invited to participate in interviews on transparency [17]. Eight people accepted to participate in the interviews, representing six different organizations. All participants were IT security experts working with cloud related projects.

The main questions [17] of the interview were:

• What is the most important information you think should be provided to the cloud customer when buying services from cloud service providers?
• In which parts would you like to be involved in making the decisions? In which parts would you like just to be informed of the decisions?
• What would increase your trust that the data is secure in this scenario?
• What do you want to know about how the provider corrects data security problems?

Cloud providers were targeted at the first stakeholder meeting of the HP’s Cloud28+, Cloud of Clouds, Made in Europe—Secured Locally initiative. The workshop was attended by 41 participants representing 22 different stakeholders. These were mostly service providers, but other relevant groups were also represented; independent software/system vendors, academia, public administration/government.

The A3 events used accountability tools as a vehicle for stimulating discussions on accountability expectations and what stakeholders would like to experience (operationally) in the cloud. The following tools were used:

• Data Track: a transparency tool that displays an overview of a subject’s data disclosures to different providers and allows subjects to access data collected about them stored at the provider, etc. [18]
• Cloud Offerings Advisory Tool (COAT): a tool to support selection of cloud services based on customer preferences [19]

The use of software tools as a means for gathering feedback gives stakeholders the opportunity to comment and express their accountability expectations in practice, that is, what they would like to experience (operationally) in the cloud.

The A3 workshop with cloud providers included presentations of cloud initiatives and research on accountability, including the COAT tool, and the presentations were followed by round table discussions within focus groups. Small groups of up to 6 people (per table) were moderated by researchers in order to gather stakeholder feedback.

The A3 workshops with cloud subjects and cloud customers had a common structure, where data collection consisted of recorded discussions and questionnaires. Discussions were centered on the tools (Data Track for cloud subjects, COAT for cloud customers), and after a short presentation of the tool, the participants were divided into groups and were asked to discuss the tool for 20 min. The discussion was guided by questions that covered their willingness to use the tool, what they liked/did not like about the tool, feedback on the tool concept and suggestions for improvements. At the end of the workshops, participants handed in a post-questionnaire where they assessed their agreement on usability as well as accomplishment of project goals, and had the opportunity to provide free-text comments about the tool. For cloud subjects there was an additional pre-questionnaire aimed to understand the participants’ behaviour in the cloud, and rate their trust in selected services as well as how sensitive (private) different personal data items are for the participants.

In addition to the workshops, Skype interviews were performed with cloud customers to understand more about the importance of transparency for customers, and verify and refine transparency requirements elicited in previous workshops. Questions [17] covered expectations on what information should be provided by cloud providers (in general and on security problems), factors that can increase customers’ trust in the security of data in the cloud, and the extent to which customers want to be involved in decision making with the provider, in addition to their opinions about the previously elicited requirements. More details regarding the individual questionnaires can be found in the A4Cloud Requirements Report [20].

3.2.4. Activity A4—Feedback, Review and Open Gaps

As with A3, A4 consisted of different elicitation activities. The workshop on metrics for accountability took place in Malaga, and invitations were sent to the members of the research community in computer science at the University of Malaga, as well as members of clerical and technical staff. We also invited SMEs working on cloud computing. Around 30 people participated in the workshop. The incident management workshop took place in Trondheim, and invitations were sent to professionals participating in the Norwegian Computer Society. This is the largest IT professional association in Norway. Sixteen people attended the workshop, and 14 answered the questionnaire. Participants received a movie ticket for returning the questionnaire.

In addition to these workshops, lawyers with experience in the cloud field were approached by researchers from Queen Mary University of London in an email survey and through informal conversation at conferences. This strategy was selected due to previous experiences conducting surveys towards this stakeholder group (low participation rate in formal survey, little appetite for attending workshops). A4 covered important gaps in the elicitation process not resolved by the previous elicitation events. There are many gaps that potentially could have been addressed, but for practical reasons it was decided to focus on accountability metrics, incident management and additional legal input. Two workshops were arranged: the Malaga workshop on metrics for accountability and the Trondheim workshop on incident response. The Malaga workshop consisted of two parts. During the first part we gave the audience an overview of cloud accountability and prompted them with several questions for discussion. Questions covered their concerns when using the cloud, the importance of transparency, and dimensions of accountability. During the second part we explained to the audience the need for measuring accountability and outlined how this can be done based on a metrics catalogue created in the project. We then distributed a questionnaire where the participants’ overall opinion about the metrics catalogue was captured by a Likert scale. In the Trondheim workshop on incident response the data collection comprised a questionnaire distributed after a presentation. The questionnaire comprised three main sections. The first two sections asked the participants to assess their agreements with statements on requirements elicited from the CSA Guide [21] and from Grobauer and Schreck [22] respectively. The last section asked the participants to freely write other comments (extra requirements, improvements, suggestions, recommendations, justification of their answers) about the requirements for incident response. The workshops were supplemented by an email consultation survey from Queen Mary University London, attempting to gauge how legal experts would react to the Guiding Light requirements [2]; this last activity did not result in new requirements, but provided useful input for the ongoing work in the project.

3.3. Requirements Repository

The stakeholder elicitation workshops resulted in a large number of requirements. In order to categorise them, to classify them with respect to what actor(s) they apply to, to preserve consistency, to simplify future management and to make all the requirements accessible to all the project partners, we created a requirements repository. This ensured that requirements could be effectively communicated to work packages that need them, particularly when these requirements were updated or changed during the course of the project. Furthermore, the repository served as the collection point for requirements created by other workpackages in the project.

The requirements repository created for the project has three main objectives:

• Collecting all requirements from all workpackages in a single location;
• Describing all requirements in a uniform manner;
• Providing a global reference for each requirement for tracking purposes.

To meet these objectives we utilised the software versioning and revision control system (SVN) that all project partners had access to, created an Excel spreadsheet template for requirements, and specified a requirement numbering scheme.

It is important to note here that the requirements in each elicitation activity must be internally consistent, but no attempt has been made to enforce coherence between requirements in different activities; this is a consequence of how the requirements have been gathered and analysed. The Excel sheets do not contain raw text, but the result of extracting individual requirements from (e.g.,) workshop minutes. However, the versioning scheme in the requirements repository caters for an evolution of requirements as they are refined by validation activities in the development work packages.

4. Results

In total 289 requirements have been identified [20]. 153 of these requirements stem from the elicitation events, while the rest of the requirements have been identified as part of other research activities in the A4Cloud project. 51 of the requirements are directly targeted towards tools or languages developed as part of the A4Cloud project.

Several researchers were involved in data analysis of the various workshops and requirements elicitation activities. All minutes, observation notes and questionnaires were analysed, with the goal of identifying requirements. In A1 the goal was to identify cloud relationships, but these were later translated into requirements. For the interviews with cloud customers (A3), recommended steps for thematic synthesis [23] were followed. Thematic synthesis is a method for identifying, analyzing, and reporting patterns (themes) within data. It comprises the identification of the main, recurrent or most important (based on the specific question being answered or the theoretical position of the reviewer) issues or themes arising from a body of evidence. The level of sophistication achieved by this method can vary; ranging from simple description of all the themes identified, through to analyses of how the different themes relate to one another in a conceptual map.

In the following, we provide an overview of which requirements target which cloud actors, as well as give an overview of important points from the various discussions of the role of accountability in the cloud.

4.1. Requirements that Target Cloud Providers

The majority of the requirements that target cloud actors (that is, not tools) are directed towards cloud providers. To further illustrate that the main security responsibility is put on cloud providers, 54 of the 57 accountability relationships identified in A1 concerned cloud provider responsibilities towards other actors, with 41 of these towards cloud customers (the rest towards auditors, regulators and data protection authorities). Figure 4 provide an overview of the more than 130 requirements that target cloud providers.

The requirements make it clear that cloud providers are responsible for the way data is handled. All accountability practices [11] are covered in the requirements, so that cloud providers are expected to define what they do, monitor how they act, remedy any discrepancies between what should occur and what is actually occurring, and explain and justify any action. A wide variety of technical and organizational measures are expected for protecting the data, throughout its lifetime. This also implies documenting the security and being able to provide evidence, e.g., that the documented measures are actually carried out. In particular, the cloud provider is expected to inform cloud customers about relevant aspects of the service and the data management practices, in a way that helps customers to understand the implications. Customers should also be empowered, so that they are able to take action regarding the security of their data and access information on vulnerabilities and incidents. Central is the concept of consent, and providers need mechanisms to deal with customer consents in an efficient manner. Monitoring mechanisms should be in place so that the status of different data is known, e.g., where the data is stored, and audits should be supported and regularly performed. The cloud provider should also respond to any incidents in an effective manner, inform customers about incidents affecting their data, and support cloud customers in their incident management activities. For incident management, but also all other matters, cloud providers shall comply with legal requirements.

4.2. Requirements that Target Cloud Subjects or Cloud Customers

As of now, it seems data subjects are not completely aware of what being in the cloud means. For at least some of the cloud subjects participating in A3 events, the cloud was just another web service or another word for “online”, and they were happy to learn more about the cloud. None of the identified requirements are directly targeted towards cloud subjects, but there are a few requirements that more indirectly put some responsibility on cloud subjects. One example is a requirements that states that cloud subjects (and likewise cloud customers) may be consulted by the cloud provider on how they want their personal data to be handled in the cloud. Then cloud subjects can be said to be responsible for giving input to the cloud provider on data handling preferences, if given the opportunity to do so. The same can be said with requirements regarding reporting of data breaches, sending of complaints and providing reviews of cloud providers. These are not direct requirements on cloud subjects, but when implemented, requirements that provide opportunities for the cloud subjects to contribute to improved accountability in the provider chain.

Cloud customers, on the other hand, are given more responsibilities, especially for taking measures to select accountable cloud providers and follow up on contract terms. Still, less than 20 requirements directly target cloud customers. Figure 5 provides an overview of these requirements. Selection of cloud providers is expected to be risk-based, but as was discussed by A2 workshop participants, it is challenging to understand and assess risk in a cloud environment.

The analysis of the different use cases showed that even when it is relatively straightforward to identify the assets, it is far more ambitious to evaluate related risks and the impact of the loss, dissemination or misuse of these assets. Different factors contribute to this difficulty:

• Technical: The variety and the amount of data collected make it difficult to understand the scope of the exposure and the usages after multi-source aggregation and complex data mining
• Lack of transparency: Whereas some data are de facto already sold, it is nearly impossible for a citizen to know who the buyers are and how sound the anonymization techniques are (if any), equally incidents are barely reported and unlikely linked to the data sources
• Legal: The coexistence of a “borderless” cloud and multiple jurisdiction frameworks may impeach users to make use of their rights or may expose the companies involved in the data processing chain

Whereas these concerns were pre-existing the cloud era (e.g., IT outsourcing), the growth of data collection, the capacity of data processing and the broader attack perimeter make them more acute. Despite these challenges of assessing risk for customers, the workshop participants were however clear that customers, and not cloud providers, are the ones that are responsible for performing risk assessments. A stakeholder said: “The amount of money to pay for risk assessment is really dependent on use cases, the amount will be based on business added value and that will also have an impact on the cloud requirements. The cloud provider should not perform the risk assessment, [they should] provide information facilitating risk assessment”.

Risk analysis is one mean to help educate users of cloud computing to better perceive the risks. With improved risk perception they can make more informed decisions when moving (parts of) their data and services to the cloud. Therefore, despite the current obstacles for obtaining meaningful risk analysis results, the participants nevertheless state that risk analysis is essential. Requirements to provide information that support cloud customers to perform risk analysis is put on cloud providers. Additionally, risk assessments can be supported by certifications and accreditation mechanisms.

4.3. Requirements that Target Cloud Brokers

Only eight requirements target cloud brokers. These are related to:

• Interpretation and negotiation of policy: It is expected that cloud brokers should be able to negotiate policy requirements with both cloud providers and cloud customers, and be able to interpret and possibly enhance policy terms, as well as report subsets of policies.
• Evidence of non-data aggregation: It is expected that cloud brokers are able to provide evidence that data are not aggregated, or alternatively, that there is effective data segregation in place
• Relay messages: Brokers are expected to relay messages between cloud providers and cloud customers, i.e., demonstration requests, remediation requests, data breach notifications and compliance and performance indicators.

4.4. Requirements that Target Cloud Auditors or Cloud Supervisory Authorities

Both cloud auditors and cloud supervisory authorities are considered to have responsibilities for clarifying requirements to cloud providers, in particular they should clarify compliance with respect to extraterritorial legislative requirements and provide a list of certifications required. The cloud auditor is then the actor performing audits and certifications. In that work they are expected to monitor accountability levels of cloud providers and make sure that collection of implicitly collected data is made transparent. It is additionally expected that audits are provided in a standard way across the chain of service so that it is possible to visualise differences between SLAs along the cloud supply chain.

Cloud supervisory authorities are not directly involved in making audits, but have the possibility to accept or reject authorisations of providers. They additionally have an important role in handling complaints from cloud subjects, receiving data breach notifications from cloud subjects and customers, and request actions to remedy compliance failures. Both actors are considered to be responsible to societal institutions, e.g., regulators. Figure 6 show an overview of the eleven requirements that target cloud auditors and/or cloud supervisory authorities.

4.5. Requirements not Directly Targeted towards a Particular Cloud Actor

In addition to the 51 requirements that consider specific tools or languages that are developed as part of A4Cloud, a number of the other requirements are not directly targeted towards particular cloud actors, but concern the need for better methods or the need to consider the whole provider chain. Requirements for methods are provided when it comes to settings management, communication between cloud provider and customer, risk monitoring and assessments, remediation, observability and transparency, and assessment of cloud provider accountability. Requirements may concern user-friendliness, on-the-fly settings management, ability to perform impact assessments and test claims made by providers, indicators, and ways to model risk and trust-relationships in cloud provider chains. Additionally, a number of requirements concern the need for language support, in particular for information considered important to cloud subjects, cloud customers and cloud supervisory authorities or cloud auditors (or other regulators). Tools and methods should consider large corporations and organizations, ability to quickly take into account any changes (e.g., in legal requirements and practices), the need to support different user groups (including novice users) and the need for independent tools, so that there are no hidden criteria that favor particular cloud providers.

The need for new methods and tools are grounded in key challenges on dealing with provider chains. This was discussed in several of the workshops, also related to main challenges for trusting the cloud (A2):

• not knowing where the resources were moved in the cloud
• the potential lack of accountability when buying from a provider that purchases services from another provider, not knowing who is responsible for what
• the risk of trusting people with a conflict of interest

This led to the following statement by one workshop participant: “one should carefully think through what data to put in the cloud’.’ Uncertainties additionally stem from the insufficient transparency and the conflicting laws among countries. To meet these challenges, there are requirements that consider the provider chain in more general terms. The need for a legal framework to steer proper handling of information in the cloud is covered by the requirements. This legal framework then needs to be taken into account in the binding and enforceable written data governance policies and procedures in service provision chains. All parties in the provision chain are expected to perform ongoing risk assessments. The need for clearly allocated responsibilities in the provider chain is pointed out, in particular who is liable to the cloud customer, who is responsible for executive oversight and responsibility for data privacy and protection, and who is responsible for responding to inquiries, complaints and data protection breaches.

4.6. The Role of Accountability

In addition to identifying requirements, the workshops included more general discussions. In the following we provide important insights from discussions on the role of accountability, both how accountability relates to risk and trust, and how accountability fits with the cloud business model.

4.6.1. Unclear Relationship between Accountability, Risk and Trust

The workshops uncovered uncertainties on the effects of accountability on risk and trust. In particular the effects on risk was unclear. This topic was covered in most detail in A2, where twelve of the workshop participants responded to a small questionnaire with ten statements describing to this relationship. From the responses one can observe that the participants do not have an agreement among themselves in their answers. In some questions, their answers are dispersed throughout the scale almost equally. The responders think that accountability may not always mitigate risks, and accountability may not always support interactions in the cloud. In the same way, one can see from the data subjects in A3 that they, although they generally were very positive to the Data Track tool, were neutral or disagreed to the the statements that Data Track would “substantially increase users’ trust in cloud services” and that it would “substantially reduce the number of serious security problems”. Cloud customers (A3) however mentioned accountability-related functionality as something that would increase their trust that data is secure, in particular they mentioned upfront transparency, community discussions, costumer awareness, way out, reputation, encryption, data processor agreements and location.

Follow up discussions in A2 on the relationship between accountability, risk and trust, led to a converging understanding that the relationships between accountability and risk and accountability and trust are different (or of a different nature).

• Accountability and risk: Although accountability addresses risk, it is yet unclear how. The relationship between accountability and risk is a generalized one. That is, it is believed that accountability addresses emergent risks in cloud ecosystems. However, stakeholders had difficulties to figure out in which way. Stakeholders questioned whether accountability addresses risk (by modifying risk profiles in terms of likelihood of occurrence or severity of impact) or changes risk perception of emerging threats in cloud ecosystems.
• Accountability and trust: The relationship between accountability and trust seem to be more context-dependent than the one with risk. Accountability helps to make trust decisions, however accountability itself seems to be necessary but not sufficient for (or implying unconditionally) trust. Accountability will help to make trust decisions. A critical aspect of trust decisions seem to be related to the evidence provided to stakeholders. Therefore, accountability (in particular transparency) plays an important role in trust decisions and supports trustworthiness (in particular based on accountability evidence).

Additionally, it was pointed out by cloud providers (A3) that the definition of accountability will be different depending on whom you ask. Enterprises will give different answers about accountability from what the customer will say, and legal people will have different understandings than more technical people.

4.6.2. Accountability and the Cloud Business Model

From the discussions of various accountability tools with lawyers (A4), it is clear that they see the main beneficiaries of the tools to be (a) cloud customers, who furthermore are (b) consumers or SMEs. Little benefit to cloud providers is foreseen. It is also clear that practicing lawyers think that the main obstacles to adoption of the tools will be the potential commercial disadvantages to providers, and the possible increase in their legal risks. Easy visibility of failures would be a commercial disadvantage against providers who are not providing such visibility. Still, as pointed out by providers (A3), the adoption of accountability mechanisms would push towards a standardization of cloud offerings. This would enable comparisons across different cloud providers and ease the adoption from cloud customers. This is the reason why accountability is perceived as a potential market enabler for the cloud. The cloud providers are clear that the business models of accountability mechanisms must be clarified in order to facilitate their deployments in operational environments. Related to this, the following two inputs from the workshops are highly relevant. First, it was stated by providers that the promise of cloud is “something magic” (that is, “not transparent”). Second, not all cloud customers are willing to pay for accountability. Based on the discussions among cloud customers in the A3 event, explicit consent for data operations is seen as an overkill by some customers, and though custom-made security levels are a “nice to have feature”, customers understand that it costs and that not all providers will offer that. Additionally, many customers do not want highest security as default; this may be a reflection on a “you get what you pay for” attitude, and thus preferring the cheapest version as default.

Cloud customers’ demand for cloud accountability can additionally be influenced by a lack of understanding of the risk associated with the cloud. The A2 event discussed the lack of understanding of the cloud among cloud customers, and its implications for cloud services adoption and risk management. A representative from the bank domain said: “Those that make purchasing decisions in banks do not understand cloud. The promise of cloud seems very large to the executives—they understand the benefits, but not the risks. One bank executive recently stated: ‘our core services will be in the cloud in 3–4 years’—but this attracted critical attention from regulatory body”. Another participant said that “the main threat for Cloud Computing is the lack of education and supporting materials for security officers. Security officers need to talk to CEOs why to move to the cloud. However, since they lack knowledge they will not opt for going to the cloud and form an obstacle for cloud adoption”.

5. Discussion

Accountability is clearly not a one-way concept; all actors in the cloud ecosystem have to cooperate to make it work. Organizations that consume cloud services, the end-users of the services, the data subjects whose data is being processed by the services, as well as the organizations that audit, certify and regulate the services, all of these have important roles to play. To illustrate, the customer need to find out if the cloud provider can deliver and can be trusted, but then the cloud provider need to demonstrate somehow that they can take care of the data. Standards bodies or auditors can support this by saying “this is the list of certifications you need to look for”.

Since the majority of the requirements concern the cloud provider, it is relevant to consider whether cloud providers have the necessary motivation to adhere to these requirements. Many requirements can be considered quite strict and, as was pointed out by legal experts (A4), they will probably hamper business if following them in full. Customer demand, audit requirements and legal requirements may motivate more accountable behavior. However, as of now, the positive effect of accountability has not been demonstrated. This does however not mean that the strive for accountable cloud services should stop. There is a need for more research on understanding the positive and negative effects of accountability on the business of cloud providers, as well what aspects of accountability should get priority. The workshops described in this paper, and the resulting requirements, provide a broad view of what accountability can mean in practice for different actors in the cloud ecosystem. Some requirements are likely to be more important than others, both when it comes to being accountable and regarding cost/benefit. Improved knowledge of this can support providers that see the value of accountability in deciding where to focus their effort. For requirements that are essential for accountability, but come at a potentially high cost, it should be investigated how to reduce the potential negative impact of the accountability practice.

Motivating individual cloud providers to demonstrate their accountability is of course essential, but there is additionally a need to consider the whole provider chain. Researchers can have an important role in providing tools and methods that adequately deal with accountability in provider chains. This is covered by the requirements, in addition to requirements on legal frameworks etc. In their current form, these requirements are not however directly targeting a particular cloud actor. Cloud brokers, cloud auditors and cloud supervisory authority may have a potentially important role related to provider chain overview and motivating the adoption of accountability mechanisms. This potential role needs to be better understood.

5.1. The Requirements

Most of the requirements in the repository have been specified at a high level. The main reason is that the requirements should be applicable to a broad spectrum of cloud service models that involve the processing of personal and/or business confidential data. By avoiding specifying detailed requirements on how, for example, the different SaaS, PaaS and IaaS services are implemented and operated, we can make sure that sure that the requirements cover also other types of service models that may appear. This is in line with the scope of the A4Cloud project, whose focus was not only on today’s cloud services but also future IT services. The exception is the requirements for accountability mechanisms, which are detailed enough to be (more or less) directly applied to the technologies and tools that the project is developing. In fact, some of these requirements have already been implemented in the project tools.

Most of the requirements in the repository originate from perceived challenges that the stakeholders associate with existing cloud services, and thus represent features that stakeholders would like to see in a future accountable cloud ecosystem. However, there are exceptions, for example, “R211—The Cloud Subject (Cloud Customer) shall be made aware of the data processing and sharing practices of the Cloud Provider” is something that almost all providers already do (as they provide privacy policies that specify this).

5.2. The Requirements Elicitation Method

Requirements elicitation is concerned with different objectives. On the one hand, elicitation aims to understand the problem space (how can we characterize the problem we are dealing with?) and to identify specific requirements. Addressing this objective tends to give rise to generic requirements charactering the problem we are concerned with. On the other hand, elicitation aims also to fit specific solutions (aligned with such requirements and addressing the characterized problem) to specific user domains. Addressing such objective highlights requirements drawn from stakeholders’ domains. Our aim of involving stakeholders in workshops was to gather a broad spectrum of requirements, good practices and risks related to the cloud eco-system covering the diverse range of geographical (including legal) constraints and challenges, sector/industry-specific requirements and cloud models.

Accountability requirements could also have been derived from the current and future data protection legislation. Many of the requirements in the repository are indeed compliant with the existing Data Protection Directive [24], which specifies a number of rules on the processing of personal data in Europe. Even though the Data Protection Directive has not been used as input to the elicitation of the requirements in our repository, it is clear that the stakeholders that were engaged in the elicitation activities are aware of both the rules in the Directive and the context in which it applies. Similarly, some of the requirements that were elicited form the stakeholders include rules covered by the proposal for a new European Union Data Protection Regulation [25].

A requirements workshop is a structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine and reach closure on deliverables that represent user requirements [10]. Requirements workshops are based on the premise that a small group of knowledgeable, motivated people is more effective than one or two development “heroes”. The benefit of the workshop process is that it nurtures team communication, decision-making, and mutual understanding. Workshops are also an effective way to bring together customers, users and software suppliers to improve the quality of software products. Requirements workshops can bridge communication gaps among project stakeholders. Co-creating models in a requirements workshop expedites mutual learning and understanding. By asking focused questions in the workshop, the workshop facilitator helps participants define requirements at different levels of specificity.

The workshops presented in this paper were clearly described and organized in such a way that the participants were recruited to contribute actively to the elicitation process. Participation was very good from the stakeholders who committed to be part of the events. All workshops proved to be fruitful with respect to generating further insights for the tools and accountability practices (or expectations). When reflecting on the method for generating discussions which led to stakeholder feedback, the methods used through all workshops showed to be effective.

5.3. Stakeholder Participation

The elicitation activities have included a large number of external stakeholders who have been given the opportunity to express their opinions on and experiences with security, privacy, risk and trust issues of public cloud services. In addition, a number of researchers from the A4Cloud project have contributed with additional requirements for the technologies and tools that they are working on. While we overall are happy with the number of stakeholders that have attended the elicitation activities (in particular the A2 and A3 events attracted a large number of stakeholders) and the number of requirements that were generated from these events, we can conclude that not all of the identified stakeholders groups have been well represented. We have had a good representation of cloud customers, cloud providers and cloud subjects in our workshops, focus groups and interviews, but cloud auditors and consumer groups have not been equally well represented. Our stakeholder selection and invitation process was suitable for the project, although recruiting stakeholders to non-local events proved more difficult than first envisaged.

6. Conclusions

To ensure symmetry between cloud actors, requirements need to take all stakeholders into account. The 289 requirements for accountability in the cloud can be accessed freely in the A4Cloud Requirements Report [20], which, along with the other public reports from the project, is available at http://cloudaccountability.eu/.

Cloud providers can use these requirements both when creating new services, and when outsourcing (parts of) their offerings to other providers, to ensure that they serve as responsible stewards of other people’s data, enabling them to leverage accountability as a business advantage. Cloud users may similarly use the requirements as a (partial) checklist when selecting a cloud provider to ensure that the chosen provider offers the required level of accountability.