Chapter 7
The Privacy Imperative
Abstract
The discussion about privacy associated within the cloud is one of the most contentious issues within technology. This chapter will consider the overall debate and provide mechanisms for both providers and end customers to address many of these concerns.
Keywords
Data controller; Data processor; Patriot Act; PLAPrivacyWhen we mention the term privacy and the cloud, you would be forgiven as the reader to question: “What exactly does this mean?” To be entirely honest, when we began the process of defining the individual chapters for the book, out of all the chapters, this one felt the least defined in terms of scope. We knew of course that no technology book, let alone cloud book, would be complete without at least one chapter on privacy (as the recent Applied Cyber Security and the Smart Grid, coauthored by Raj Samani would attest). However unlike other publications, when it comes to cloud computing, we can address the subject from a number of angles, for example:
▪ The recent allegations regarding government surveillance, the impact that this has on the privacy of customer data, and ergo the impact this has had on the willingness for end customers to utilize cloud computing services. Otherwise for many known as the Snowden effect!
▪ The use of cloud computing and the impact that this has upon national data protection/privacy regulations.
To summarize the above two points, does cloud computing make my data less private, or make myself less likely to achieve compliance with data protection legislation? The primary focus of this chapter is consider compliance against data protection legislation, however we will consider the first question due to the level of scrutiny the cloud, and in particular, U.S. providers have recently come under.
Does Cloud Computing Make My Data Any Less Private?
The common (mis)perception on this question will of course be yes. After all, how else could we explain the recent survey conducted by the Cloud Security Alliance (CSA) of 500 respondents, which found that 56% of non-U.S. residents were less likely to use U.S.-based cloud providers, in light of recent revelations about government access to customer information.1 This infers that, in particular, non-U.S. customers feel that by using U.S. cloud providers, their data (or indeed their customer data) will be less private through the use of U.S. providers. Such sentiments would appear to be echoed by policy makers, and in particular, the European Parliament Committee on Civil Liberties, Justice and Home Affairs. The initial findings2 from the investigation into the mass surveillance on the EU citizens:
▪ Note that trust in U.S. cloud computing and cloud providers has been negatively affected by the abovementioned practices; emphasize, therefore, the development of European clouds as an essential element for growth and employment and trust in cloud computing services and providers and for ensuring a high level of personal dataa protection
However, while we consider this advice, the question quickly becomes: Is using the cloud (at least certain clouds) by itself make the data any less private? If we ask this particular question, the argument would be: No it does not. Consider that when two organizations are hosting customer data, one is using a traditional outsourcing model (or as many would argue a private cloud!) and the other is using a public cloud provider. Both implementations are being hosted out of U.S. data centers, the question is whether the cloud customers are more likely to have their data subpoenaed under say the Patriot Act solely because they are cloud customers. Addressing this particular point, according to a study undertaken by international law firm, Hogan Lovells, many other countries have “laws in place allowing them to obtain personal data stored on cloud computing services3”; these include (but not limited to) the U.K., Ireland, Germany, France, Japan, and Canada. Of course using this argument, the answer will be no. Simply by using a service marketed as the “cloud” does not increase the likelihood of data being accessed by any agency/department. Further, the ability to lawfully access data using mechanisms such as the Patriot Act is also afforded to many other countries globally. This is reinforced by a white paper4 by A&L Goodbody entitled “No Cloud over the Patriot Act”; “the powers granted to specific US law enforcement authorities under the Patriot Act already existed prior to the enactment of the statute in 2001 and are no broader than equivalent powers granted to law enforcement authorities in Ireland, and in other European jurisdictions.” The paper continues to provide a list of equivalent laws in Ireland as defined in Table 7.1.
Table 7.1
Equivalent Legislation to Patriot Act in Ireland
| Legislation | Application |
| Postal and Telecommunications Services Act 1983 (“the 1983 PTS Act”) and the Interception of Postal Packets and Telecommunications Messages (Regulations) Act 1993 (“the 1993 PPTM Act”) | Permits limited authorization for interception of postal packages and telecommunications messages (to include e-mails) for national security or criminal investigations. This is only applicable to certain licensed providers of telecommunications networks under Irish law. |
| The European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011 (“the 2011 Regulations”) | Provides that listening, tapping, storage, or other kinds of interception or surveillance of communications and the related traffic data by persons other than users, without the consent of the users concerned, is prohibited (unless authorized under the PPTM Act or other laws that would fall under Article 15 of Directive 2002/58 EC). |
| Criminal Justice (Surveillance) Act 2009 (“the 2009 CJ Act”) | Permits ex parte orders for surveillance. |
| Criminal Justice Act 2011 (“the 2011 CJ Act”) | Permits a court to make orders for delivery and/or making available of documents (to include electronic files and other formats) to the Garda in the context of a criminal investigation. |
| Data Protection Acts 1988—2003 (“the Data Protection Acts”) | Provides for strict governance of data processing by controllers and processors of data. Data processing carried out by a Garda or a member of the Defense forces or by an order of a court will be excluded from the general rules under the Data Protection Acts. |
| Communications Retention of Data Act 2011 (“the 2011 Data Retention Act”) | Data (to include call records and traffic data), which are retained by a person engaged in the provision of publicly available electronic communications service or public communications network under this Act may be requested by the Garda where it is required for the prevention, detection, investigation, or prosecution of a serious crime, the safeguarding of the security of the State, or the saving of human life. |
Admittedly, we could have presented equivalent legislation from any number of countries; however, it is worth focusing attention to Ireland partly because of such a concentration among major providers to establish operations in the country. However, as the above table demonstrates the argument that the Patriot Act should act as the motivating factor to establish operations in Ireland, or any other geography is wide of the mark. According to Bryan Cunningham of Cunningham Levy LLP: “Why Ireland? Boosters cite the ‘Patriot Act,’ perhaps somewhat inaccurately, for the notion that “the Patriot Act” enabled the US Government to compel companies based in the United States to hand over any person’s information, regardless of nationality, and that cloud companies with headquarters in Ireland somehow are immune from US Government or, presumably, other nations’ surveillance.5” With this in mind, analysts at IDC advise: “Users need to ignore the Patriot Act scare stories.6”
In the same vain, there are some added complexities to this rather simple and crude argument; first, the lack of transparency means that as an end customer I may not know (1) where my data are physically located and (2) I may not even be told if my data are accessed either if the provider is notified, or indeed uncovers an incident.
Subsequently the simple answer provided earlier is further complicated. However with the appropriate due diligence, in terms of defining the physical location where data are stored, ensuring that incident response policies from the provider meet the organizational requirements, and so forth. The risk of such an issue should be mitigated, and indeed no greater than utilizing a traditional outsourcer, or in fact hosting internally. Moreover, customers storing data with third parties, or in fact even those stored on premise should certainly consider technical controls to mitigate the risk of unauthorized access, or access that may be lawful but not appreciated. This includes using technical controls to encrypt data stored at rest for example.
Of course, these preceding paragraphs will be debated, and you the reader may agree or in fact vehemently disagree with this position. However the intention here is to move away from the arguments that we all hear and question whether they are based in reality, for example, the Patriot Act argument. Do not use a U.S. provider for cloud computing because of the Patriot Act, is one such that appears in most social media discussions, but sadly many making arguments fail to recognize the similar legislation across other countries. Therefore, for an organization using cloud, it is important to understand the legal environment where the data will be physically located, and ensure that the worst-case scenarios align with your risk appetite, or whether it is possible to reduce the risk to a level so that it does not exceed the acceptable level.
If we step away from this rather contentious issue, let us focus on one of the biggest barriers to cloud adoption, the legality of using cloud computing with regards to data protection legislation.
Privacy Level Agreement
Transparency: This has been a recurring message throughout the book as it relates to cloud security. However there are particular implications for this not being achieved, particularly as it relates to the storage, or processingb of personal data with cloud computing. Where the cloud end customer is the data controller, there will exist a number of obligations to ensure that the cloud service provider (CSP) has appropriate controls in place to protect the personal data processed within the cloud (note: the term processing will also include storage). Examples of some of these obligations are detailed by the UK Information Commissioner’s Office (ICO) in its report entitled “Guidance on the use of cloud computing7”:
The obligations of the cloud customer as a data controller will not end once a cloud provider is chosen. A continual cycle of monitoring, review and assessment are required to ensure that the cloud service is running in the manner expected and as the contractual agreement stipulates.
Taking this, and indeed some of the other many obligations, the data controller will have regarding the protection of personal data that a working group within the CSA was established for the development of a Privacy Level Agreement (PLA). The PLA is intended to allow the end customer to review the CSP’s commitment to protect personal data, as well as provide protection should the CSP fall out of compliance or fail to adequately protect the said data.
The PLA produces a series of baselines for the provider to declare regarding the level of protection applied to personal data. Declaring this as an effective way to communicate the level of protection employed by the provider gives a level of transparency to the end customer regarding the baseline level of security deployed by the provider regarding protection of personal data. Consider the ease with which an end customer can ascertain the baseline of protection provided using the PLA, one simple question, and a binary response. Moreover, this assertion is intended to be included as an attachment to the service agreement and aligns with recommendations and guidance provided throughout 2012 by the Article 29 Working Party and several European data protection authorities.
PLA Outline
There are 16 sections within the PLA. There is no intention within the book to simply copy and paste what is included within the PLA, however we will try to summarize some of the key points within the sections, and in particular, their relevance to the end customer, but would recommend referring to the document for additional details.
Identity of the CSP
The provider will be expected to detail high-level information such as name, address, and any local representative. Within this section, however, there will be a question about the role of the provider from a data protection perspective. Typically the CSP is often seen as the data processor, in fact under the Article 29 Working Party Data Protection Working Party opinion on cloud computing it cites, “The cloud client determines the ultimate purpose of the processing and decides on the outsourcing of this processing and the delegation of all or part of the processing activities to an external organization. The cloud client therefore acts as a data controller.8”
This, of course, is not always the case. In addition to the information provided within the PLA, which focuses on guidance from both the ICO and the Commission nationale de l’informatique et des libertés, there is legal precedent whereby this assumption is proven (in certain circumstances to be incorrect). Documented in the book entitled “Cloud Computing: A practical introduction to the Legal Issues,9” a legal position that challenged the view that the service provider was always the data processor. While not a cloud provider per se, the case from 2006 involved a service provider who provided features that were cloudlike. In 2006, the Society for Worldwide Interbank Financial Telecommunication (SWIFT) was subpoenaed under the U.S. antiterror laws to provide agencies with personal data collected for money transfers. In the same year, the Belgian data protection authority provided an opinion that SWIFT were in breach of data protection rules, and later in 2006, the Article 29 Working10 Party found SWIFT to not be a processor that it had originally considered itself to be but indeed a controller.
▪ “While SWIFT presents itself as a data processor, and some elements might suggest that SWIFT has acted in the past as a processor in certain cases on behalf of the financial institutions, the Working Party, having considered the effective margin of maneuver it possesses in the situations described above, is of the opinion that SWIFT is a controller as defined by Article 2 (d) of the Directive, for both the normal processing of personal data under its SWIFTNet service as well as for the further processing by onward transfer of personal data to the UST.”
Part of the reason for this assertion included the fact that SWIFT determined the security standard, and location of its data standards, and itself complied with the U.S. subpoenas without informing the financial institutions. The reason for focusing so heavily on the distinction between the controller and processor is based on the obligations of each stakeholder. In particular, the data controller has “statutory responsibilities to data subjects and is subject to scrutiny of the regulatory regime and ultimately sanction through the courts; the processor has no such responsibility or real scrutiny.11”
It is for this very reason that the distinction by the CSP regarding its perceived role is very relevant, whereby if it is indeed a data processor then its responsibilities regarding data protection are greatly diminished. However, in the case of SWIFT, it is worth noting that despite their assertion, it is possible for this to be challenged should the provider undertake actions that may be deemed as behaving like a data controller.
Processing of Personal Data
In addition to the defining its role, the CSP will also be expected to define the physical location where personal data will be stored. Again, this becomes a critical point for the end customer who may store personal data within the cloud where certain customers may not be allowed to store personal data in particular geographies due to data protection regulation. In the United Kingdom, for example, the eighth principle of Data Protection Act states that:
▪ “Personal data shall not be transferred to a country or territory outside the European Economic Area (EEA) unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data12”
While there are documented examples that do allow personal data to potentially be transferred outside of those listed countries, the level of effort required to maintain compliance can be onerous for the data controller/end customer. Latter sections (4) do request that the provider details whether data are transferred outside of the EEA, and if so on what legal basis this is done (for example, adequacy such as Safe Harbor). Being aware of such potential transfers is imperative for the end customer, and in particular, where they act as data controllers as transfers outside of the EEA could result in being breached of data protection regulation.
Data Security
Section 5 of the PLA demands the provider to specify “the technical, physical, and organizational measures in place to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized use, modification, disclosure or access, and against all other unlawful forms of processing.” This becomes important, particularly where the end customer acts as the data controller; this is because the controller must ensure that the processor has appropriate safeguards in place. Herein lies one the main challenges, we have often discussed the issues regarding the lack of transparency when it comes to cloud computing, and yet when it comes to data security, the controller must take reasonable steps to ensure compliance. With public cloud computing, the likelihood is that the right to audit will not be available; therefore, the controller will be required to seek alternate means to demonstrate “reasonable steps.” One such option will be to leverage security standards and within the PLA the provider will be requested to define the security control frameworks that are used, and which controls apply. In addition, the provider will be requested to “describe which technical, physical, and organizational measures the CSP has in place to support transparency and to allow review by the customers.”
In addition, under section 7, the provider will be required to define whether any third-party audits will be made available to the customer, with their scope and frequency also defined. This again becomes particularly relevant where the data controller will be required to demonstrate “reasonable steps” in terms of security deployed by the data processor. Furthermore, the use of independent third-party audits is seen as a suitable mechanism to assess the security deployed by the processor by the ICO. Also, the frequency of the audit becomes relevant, as the controller is expected to be provided with regular updates of the security controls deployed by the processor.
Of course the above paragraphs are only a small snapshot into the categories within the PLA, the below Table 7.2 is a full list with a short summary. However for further details, and in particular the references with guidance from the various data protection bodies, the reader is encouraged to review the entire document.
Table 7.2
Summary of the Cloud Security Alliance (CSA) Privacy Level Agreement
| 1. Identity of the CSP (and of representative in the EU as applicable), its role, and the contact information of the data protection officer and the information security officer. | This section requires the CSP to provide details about their business and contact details of relevant personnel. This includes the data protection officer, security officer, etc. |
| 2. Categories of personal data that the customer is prohibited from sending to or processing in the cloud. | The CSP will define those categories of personal data that are explicitly prohibited from sending to the provider. |
| 3. Ways in which the data will be processed. | The CSP will define how the end customer can issue instructions to the provider. Also, the providers will define those tasks that they will carry out on behalf of the customer and those that the customer will have to request. |
| 4. Data transfer | We touched on this earlier in the chapter, but this section is where the provider will specify if there will be any transfers of data held by the provider. In particular, the provider will be requested to specify where the data will be transferred to, and under what grounds. |
| 5. Data security measures | This section requires the provider to detail the controls in place to protect the personal data stored by the provider. In particular, this will not just be technical controls, but also physical and organizational measures in place. In addition, the provider can define the security standards/frameworks that are used to protect such information. |
| 6. Monitoring | The provider will specify if the customer can monitor the controls deployed, and the mechanisms to achieve such visibility. |
| 7. Third-party audits | If the provider authorizes independent third-party assessments, then this would be specified within this section. Moreover, the provider will elaborate the scope of the assessment, frequency, and the level of details the report will entail (and ultimately made available to the customer). In addition, the CSP will state the auditor chosen by the customer or chosen by both parties and who will pay for the cost of the audit. |
| 8. Personal data breach notification | “Personal data breach” means a breach of security leading to the accidental or unlawful destruction; loss; alteration; unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed in connection with the provision of a service provided by a CSP. Specify whether and how the customer will be informed of personal data and data security breaches affecting the customer’s data processed by the CSP and/or its subcontractors, within what time frame and how. |
| Table Continued | |
CSP, cloud service provider.
At the time of writing, the launch of a working group for the development of the second version of the PLA has been announced. It is intended for version 2 of the PLA to produce three deliverables:
1. “PLA—Compliance tool for EU market: The first deliverable of the PLA Working Group was a transparency tool for the EU market; based on these initial results, the WG v2 will develop a compliance tool that will satisfy the requirements expressed by the Art 29 WP and in the Code of Conduct currently development by the EC.
2. Feasibility Study on Certification/Seal based on PLA: The group will create a document assessing the feasibility of a Privacy Certification Module in the context of the Open Certification Framework and establish a roadmap and guidance for its creation and implementation.
3. PLA Outline for the Global Market: CSA will extend the scope of the PLA v1 by considering relevant Privacy Legislation outside the EU.13”
The development of the second version of the PLA will be a welcome addition to end customers aiming to ensure compliance against data protection legislation outside of the EU. It is, however, worth noting that the PLA is not the only tool available for end customers to address privacy concerns, or rather will not be the only tool.
Data Protection Certification
The Data Protection Certification is an emerging initiative that aims to address the manner in which the industry addresses data protection legislation particularly within public cloud environments. It intens to deliver a blueprint of controls in Web and PDF formats. It is intended for both the IT and Information Security teams within the end customer or those of the cloud provider to quickly identify and detail the controls that are deployed within a given cloud instance.
Problems the Data Protection Certification Aims to Address
Castles in the Cloud: The classic infrastructure approach of putting key controls on the end points and fortifying the perimeter is antiquated. Even if every cloud provider builds their “castle in the cloud” what protects users’ data traveling between them?
Compliance does not Equal Trustworthiness: The long rote of compliance is taking its toll in the cloud. Providers are facing enormous staffing challenges with addressing assessments to satisfy compliance requirements. As part of the research conducted by the leadership team of the data protection certification team, one organization reported supporting 100 assessments to satisfy just three regulations. Another provider reported supporting 750 assessments, regardless of the level of resources dedicated compliance to standards and regulations will not guarantee the safety or trustworthiness of data in the cloud. It only implies that the provider or the consumer has a well-controlled environment.
How the Data Protection Certification Address the Problem(s)
The Cloud Data Protection Cert presents controls based on the sensitivity of the data, and the cloud model deployed. In addition to the standard list of controls, further customized guidance is provided following the outcomes of a built-in self-assessment. The way that data are classified and treated aligns to business usage and contexts. The focus is on making it easy for the business to protect their own data, and therefore allowing the subjective assessment to determine the value of the data to be undertaken by business owners. Cloud Data Protection Cert prescribes controls according to a tiered data sensitivity model. “Regulated Data” has the most rigorous set of controls, “Commercial Data” has a robust but less rigorous set of controls, and “Collaborative Data” has the most flexible and least number of controls. This data classification is key but missing from typical IT security frameworks and standards. It provides both cloud providers and consumers a standardized approach for ensuring that data protection controls are appropriately applied and thereby greatly diminishing the risk of data theft and exposure.
Simplifying Trust and Protection: Once data are classified, the appropriate level of protection can be applied to govern user access and data, and to protecting transactions and work streams.
At the time of writing, the Cloud Data Protection Cert is undertaking a formal review, and therefore is subject to change. While the individual detail may change the goal of the program is likely to remain, which is to integrate the cortication into data protection standards, and ultimately become the baseline for cloud security requirements.
For more information, please refer to the Cloud Data Protection Cert.
1. Visit http://clouddataprotection.org/cert/
2. Access your blueprint of controls after the following three selections:
a. Your role: Cloud provider or cloud consuming organization
b. Data type—Regulated, commercial, or collaborative
c. Cloud Delivery Model—SaaS, IaaS.
The Cloud Data Protection Cert is an emerging body of work within the CSA, addressing a fundamental area of major global concern as it relates to not only cloud computing but the fabric of daily life. Therefore, like the PLA should act as the cornerstone for cloud customers and providers to provide the transparency so desperately sought to not only remain compliant but protect some of the most valuable data that the organizations have.
At the time of writing, there have been a number of remarkable developments associated with privacy considerations as they relate to cloud (and broader), and there will be many more to come. Most recently, for example, in April 2014, United States Magistrate Judge, James Francis ruled that the U.S. companies must turn over private information when served with a valid search warrant from U.S. law enforcement agencies. Within the ruling, the judge stated, “Even when applied to information that is stored in servers abroad, an SCA warrant does not violate the presumption against extraterritorial application of American law.14” The case involved Microsoft, which challenged the search warrant because the data were stored on a server located in Ireland and subsequently beyond the U.S. law enforcement jurisdiction. While Microsoft has appealed the ruling, the broader impact could be significant according to Caspar Bowden, an independent privacy researcher who preempted Prism in a report to the EU Parliament in October 2012, who stated, “If the US Cloud industry was worried before about lack of confidence of foreign customers, this judgment just upped the ante very considerably (subject of course to any appeals).15”
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.