Roger Clarke's Web-Site

© Xamax Consultancy Pty Ltd,  1995-2024
Photo of Roger Clarke

Roger Clarke's 'Backing up Your Cloud'

SaaS Backup Fails the Fitness for Purpose Test

Published in IEEE Cloud Computing (Nov-Dec 2015) 58-63

Version of 13 September 2015

Roger Clarke **

© Xamax Consultancy Pty Ltd, 2015

Available under an AEShareNet Free
for Education licence or a Creative Commons 'Some
Rights Reserved' licence.

This document is at http://www.rogerclarke.com/EC/FPTB.html


Abstract

SaaS providers have achieved dramatic take-up rates for their services. However, they are placing their businesses at risk through their inadequate attention to security issues. Nowhere is this more evident than in the area of backup and recovery. When assessed against users' needs for assured accessibility of the data that they entrust to the cloud, SaaS services are found to be untrustworthy, and very hard to work with.


1. Introduction

There are many requirements that a cloud service needs to satisfy. This short paper necessarily has a tight focus. It confines itself to Software as a Service (SaaS), and within that to application software as a service. It's primarily concerned with individual users, micro-organisations of 0-2 people, and the sub-set of small organisations that have similar levels of IT expertise and resources. Finally, within the broad area of 'non-functional' requirements, it concerns itself with the security cluster, and the primary focus is narrowed still further to backup and recovery.

As a criterion for evaluating the extent to which SaaS services meet the needs of individuals and small organisations, the analysis that follows adopts the notion of 'merchantability', operationally defined as 'fitness for purpose'. This is a form of consumer protection that has long been imposed on the suppliers of goods, as an implied condition of contract law.

Whether a SaaS service is actually, at law, subject to a fitness for purpose test is unanswerable in the abstract, because every jurisdiction requires a separate analysis. Unfortunately, even within a single jurisdiction, the question is still in most cases unanswerable, because the relevant laws are unclear, and little relevant litigation has been conducted. An indication of the difficulties involved can be gained from an outline of the situation within the author's own jurisdiction.

Australia has moderately strong consumer protection law in relation to 'goods', currently expressed in the Australian Consumer Law (ACL 2010), in Schedule 2 of the Competition and Consumer Act 2010 (Cth). Since passage of that statute, 'goods' have been defined to include `computer software'. It is not clear, however, that there has been any material improvement in consumer protection for purchasers of software. Enforcement by consumers and small business is completely impractical, and regulators move so ponderously that they represent little or no threat even to relatively small Australian software-producers, let alone supra-nationals.

Under the ACL, services are also subject to an imposed condition that they be "reasonably fit for the purpose". However, the provision is subject to significant qualifications that are untested in the courts. Among the loopholes is that "the consumer, expressly or by implication, [must have made] known to the supplier [each] particular purpose for which the services are being acquired by the consumer" (s.61). It will require decades of litigation to work out whether there are any circumstances under which there are even any theoretical obligations on SaaS providers arising from that section. There is little evidence of any enforcement of s.61, virtually no prospect of consumers or small business instigating complex, expensive and long-winded court actions, and no sign of the regulator awakening from its slumber.

As Hunt (2015) points out, "consumers are conditioned to expect product defects in computing and especially in terms of the cloud" and "unfair terms regimes have now been in place in Europe and Australia for a number of years, yet many international cloud providers are clearly not responding as the law requires". Meanwhile, the few industry codes that have emerged, such as NZCC (2013), have been subjected to derision from a consumer protection perspective, for their failure to, among other things, assure data survival (ACCAN 2012, Clarke 2013a, Hunt 2015).

Despite the low probability that SaaS providers are legally obliged to ensure that their services are fit for purpose, it's nonetheless an appropriate test to apply. After all, a service that fails the test will need to be all the more compelling if it is to keep customers after they've discovered that the functionality or the service-quality are inadequate.


2. Security Issues in SaaS Contexts

The inadequacies of SaaS were recently encapsulated by Bruce Schneier, as follows: "Why don't I embrace the cloud ... ? There are three reasons ... The first is control. I want to be in control of my data, and I don't want to give it up. ... The second is security. ... [In summary, ] I am extremely paranoid about cloud security ... The third is the big one: trust. I simply don't trust large corporations with my data ... Right now, it is largely a free-for-all out there, and it can be impossible to see how security in the cloud works" (Schneier 2015).

Drawing on the risk assessment literature, and on prior research reported in Clarke (2010a, 2011), Table 1 presents a generic set of requirements for SaaS services. They're expressed in terms that consumers can relate to, but with keywords added in order to connect with the language used by large organisations' IT staff and with the relevant literature.

Table 1: Requirements of SaaS

Extract from Clarke (2011)
Requirements relevant to backup are in bold-face type

The Basic Needs

The Basic Protections

More Advanced Needs

More Advanced Protections

Further analysis was reported on in Clarke (2013b), which identifed the following key data risks in the cloud:


3. Backup and Recovery in SaaS Contexts

Depending on how well backup is designed and implemented, it can address various aspects of data risk. In Clarke (2015a), relevant literature is applied to the development of a risk assessment, leading to what are referred to as 'practicable backup plans' for individuals and micro- and small organisations. The first of these plans addresses the longstanding but now almost quaint pattern whereby the user is self-sufficient, in terms of equipment, software, and backup and recovery arrangements. The second plan is appropriate where a remote online service is used to store backups, and the third is for circumstances in which the primary copy of data is stored on a remote file-hosting service, but with processing and backups managed locally, by the user themselves.

But those arrangements are all a bit passé. What does backup look like in the vibrant, post-modern world of the cloud?

A first rough test is to consider how well the specific needs of a narrow segment of users are served. Academics are a case in point, because they're both individuals and micro-organisations. Many academics are now reliant on:

How does backup work in such contexts?

An earlier evaluation of LinkedIn's Terms of Service and Privacy Policy was severely critical (Clarke 2010b). There's been little improvement. In the current document, cl. 3.2 makes abundantly clear that "LinkedIn is not a storage service. You agree that we have no obligation to store ... any content ... that you ... provide ...". No evidence could be found that the company has noticed that users might like to have long-term access to some of what they contribute to the site.

The bepress site's Terms of Service state emphatically that "YOUR USE OF THE SERVICE IS AT YOUR SOLE RISK. THE SERVICE IS PROVIDED ON AN 'AS IS' AND 'AS AVAILABLE' BASIS" (shouting in original). Yet the site appears to not even mention the need for users to consider making backups, let alone provide guidance on how to do it. In other words, you can't rely on your index-page being there next week, nor your carefully manicured text, nor even your painstakingly-assembled collection of papers. Experiments with the bepress site suggest that it is open, and that a user-side backup routine could be fashioned. However, the papers themselves are contained in a separate directory from the index-pages, and hence simple tools such as SiteCrawler may not be flexible enough to enable a complete backup to be quickly and reliably implemented.

Google Scholar remains an experimental service without a business model. It appears not to enable any form of backup beyond an occasional print-to-PDF of the main page and of such publication-specific pages as an author perceives to be important. (However, even when logged in, the display of citing articles appears to be limited to 20 per page and 25 pages).

This is not a denigration of the valuable functionality that these services offer. But it's a sobering thought that none of the data or the services are for ever, and the organisations that run the sites effectively owe their 'customers' no obligations at all. Moreover, empirical study of the reliability of cloudsourcing confirms that the data risks aren't imaginary (Clarke 2012). Multiple of the incidents reviewed involved loss of data, and in most of those cases users would have had no way of recovering the lost data, because they were entirely dependent on the service provider.

In short, if you want to assure your ongoing access to the data that you contribute to these sites, you must manage your own copies as well, or get someone else to manage them for you.


4. A Deeper Study of SaaS Fitness for Purpose

The previous section's superficial scan of a few services depended on by academics needs to be complemented by more disciplined studies of backup in the no-longer-new context of SaaS. The author has recently conducted a project of this kind. It extended the risk assessment reported in Clarke (2015a), developed specifications for three different approaches to achieving backup and recovery of data held by SaaS providers, and then used those specifications to assess a small sample of SaaS services. The results are reported in Clarke (2015b).

The first of the three approaches is the common circumstance in which the user places implicit trust in the SaaS provider to take due care with the data. In effect, the user is assuming that the SaaS provider warrants fitness for purpose. Table 2 declares the requirements.

Table 2: SaaS Backup Requirements Statement

Reproduction of Table 4 of Clarke (2015b)

ESSENTIAL

    Infrastructure Features

  1. a. The SaaS provider is to store the Primary copies of all files
    b. The SaaS provider is to provide facilities for creating, amending and accessing the data from the user's working-devices
    c. The SaaS provider is to provide 99.9% service-availability (10 minutes' downtime per week)
    This ensures that the user has access to their data and to the ability to create, amend, access and delete their data
  2. File-Precautions

  3. The SaaS provider is to perform continual saves when data is being changed
    This guards against the loss of recently-completed amendments due to infrastructure failure
  4. The SaaS provider is to create a new file-version when making significant amendments
    This ensures recoverability from mistaken amendments and deletions
  5. The SaaS provider is to run malware detection and eradication software
    a. on all incoming files
    b. on all stored files

    These two safeguards greatly reduce the frequency with which malware will affect the individual's data. This is particularly important on devices using a Microsoft OS
  6. Backup Runs

  7. The SaaS provider is to maintain a full Backup to a separate storage-medium no less frequently than daily
    This provides an accessible and reasonably up-to-date First-Level Backup
  8. The SaaS provider is to
    a. maintain a full Second-Level Backup on a weekly, fortnightly or monthly basis

    b. store the Second-Level Backup in such a manner that it is not subject to the location-based risks that apply to the First-Level Backup
    These together address the risk of the Primary and the First-Level Backup both being inaccessible for any reason
    c. store the Second-Level Backup offline
    This addresses the risk of simultaneous corruption of all versions of the data, e.g. by ransomware
  9. The SaaS provider is to ensure that, periodically, a Full Backup is provided to a Data Escrow service, under conditions that ensure its availability to the user
    This addresses the risk that the Primary copy and the Backups, which are all in the possession of the service-provider, may become inaccessible by the individual, for such reasons as undetected loss of data, bankruptcy, withdrawal of service, a commercial dispute, or seizure by another party
  10. Business Processes

  11. The SaaS provider is to document and periodically rehearse backup procedures to implement all of the Backup Runs
  12. The SaaS provider is to document and periodically rehearse recovery procedures for individual files, and for the complete set of files, from First-Level Backup and from Second-Level Backup

RECOMMENDED

    Infrastructure Features – Additional Measures

  1. The SaaS provider is to facilitate mutual authentication and channel encryption between all of the individual's devices and the service-provider
    This greatly reduces the risks of data interception and data corruption, particularly when connecting from insecure external locations
  2. Backup Runs – Additional Measures

  3. a. The SaaS provider is to, half-yearly, retire a Full Backup to Archive
    b. The SaaS provider is to store successive Archive copies locally and remotely
    This ensures that an occasional set of old file-copies exists and hence earlier versions of files can be recovered
  4. The SaaS provider is to, annually, spool 3-year-old Archives to new media
    This addresses the risk of storage-media decay
  5. The SaaS provider is to, 5-yearly, spool all Archives to a new media-type
    This addresses the risk of having storage-media that no storage-device can read

UNADDRESSED RISKS

  1. It is not feasible to require the SaaS provider to ensure that the format is readable by software readily available to the individual
    This means that the user is at risk that the data may be in principle accessible, but in practice unusable
  2. It is not feasible to require the SaaS provider to ensure that the user's data is inaccessible to the SaaS provider
    This is feasible (although not simple) in relation to backup copies, which can be encrypted to a key that only the user has access to. But the Primary copy is processed in clear and hence, even if it is stored encrypted, the SaaS provider must be able to decrypt it

The requirements in Table 2 were used as a basis for evaluating a sample of five SaaS relevant to the target-segment - Instagram, ancestry.com, Xero, Salesforce and Google Docs. The assessment concluded that individuals and organisations that are reliant on being able to access data should not place implicit trust in any of these mainstream SaaS services. There are good grounds for suspicion that, at the current immature stage of development, trust should not be placed in any SaaS service.

A statement by one of the five is indicative of the services' inadequacies: "Although Salesforce does maintain back up data and can recover it, it's important to regularly back up your data locally so that you have the ability [to] restore it to avoid relying on Salesforce backups to recover your data. ... Data Recovery is a last resort process ... The price is a flat rate of $US 10,000".

But really, how serious are these shortfalls? The modern generations, of organisations as well as people, are high on hedonism, convenience and ephemera, and low on history, planning and discipline. Surely SaaS providers are tuned into the zeitgeist and fulfilling their users' needs.

Well, it's true that many uses of SaaS are casual. Instagram was include in the sample for precisely that reason. Instagram may well be able to succeed as a sharer, and deny any notion of being a repository. But many small organisations and individuals do value some of their images, and may be assuming that they'll remain accessible on Instagram's site, for as long as they might be needed. A family-tree, meanwhile, has been something developed and maintained by an individuals, perhaps in conjunction with a kinship group. Are people really ready to cede their family-tree data to a for-profit corporation associated with a church in Utah?

Of greater significance for organisations, accounting data is vital as a means of managing operations, of fulfilling reporting obligations each year, and of satisfying demands for evidence from tax agencies for the previous 5-10 years. Similarly, data about customers and prospects is the lifeblood of any business. If marketing intelligence has really migrated from the proprietor's head into the Saleforce cloud, can Salesforce really justify its cavalier attitude to enabling reliable user access to copies of the data that it holds? And can the individuals whose correspondence has migrated from manilla folders via their own disks into Google-managed virtualised storage who-knows-where, really get by without access to the trail of correspondence with their customers, suppliers, banks, insurance companies, pension funds, lawyers, and multiple government agencies?

A second Backup Plan was specified for the alternative approach whereby the user takes personal responsibility for extracting backups from their SaaS providers to their own site. When the five sample SaaS were evaluated, it was found that only ancestry.com makes it reasonably straightforward for an individual or small organisation to acquire a backup - and this can be processed using an inexpensive product sold by the company. In the other four cases, there are conceptual and technical challenges that are sufficiently substantial as to be insurmountable for most users.

Of the four services that scored an abject fail on the test, Salesforce again needs to be highlighted, given how valuable the data is that they maintain for their customers. The site provides the valuable exhortation to "regularly back up your data locally", but the notion is completely hollow. Data stored by Salesforce can only be extracted as a sizeable collection of flat files, and in CSV format. But the database is highly structured, and no data model was located, and hence the data-collection cannot be reliably reconstituted, and therefore the backups are unlikely to support their nominal purpose - which is the recovery of the data and its associated value. Added to that, data extraction can only be instigated manually by a user and cannot be automated, it can only be performed weekly or monthly, the time when it is performed is determined by Salesforce not by the customer, and the website declares that it can be subject to delays longer than a week, in order to suit the needs of the service-provider.

Finally, a two-layer-SaaS approach was considered, with a Backup-as-a-Service (BaaS) provider extracting backups to somewhere else in the cloud. Surely this would be the end-point in the search for security and fitness for purpose. But the BaaS approach to backups appears to be feasible in one only case (Instagram). In two cases, it's fraught with difficulty because of the absence of services oriented towards small organisations and individuals (Salesforce and Google Docs), in one case it's impractical (Xero), and in the last case it's infeasible (ancestry.com).

Despite the cacophony surrounding cloud interoperability standards, useful contributions in relation to data backup are in short supply. For example, all that was offered by NIST's Cloud Computing Standards Roadmap (NIST 2011a) was: "Popular methods for interchange of data in clouds generally leverage representations in either JSON or XML formats" (p.37), yet a later version omits even that limited contribution, saying only that "data format for backup [needs] further standardization to support portability" (NIST 2013). Its Guidelines on Security and Privacy in Public Cloud Computing are just as vacuous on the topic (NIST 2011b). There is little evidence that either providers or standards organisations are paving the way towards a world in which individuals and organisations can reliably protect their interests in cloud-borne data.

Alarm-bells were rung years ago, e.g. Menn (2011) referred to "the need for multiple cloud providers and for local, non-cloud back-ups of essential data". Yet, even before that, it has been noted that "In a cloud setting, rebuilding an application years later so as to make data intelligible may be impossible. ... As one commentator put it [Schofield 2010], one of the issues with cloud computing is that it can work a bit like Hotel California - you can check your data in OK, but will you ever get it out?" (Vincent & Hart 2011). For most of the sample examined in this particular research, the answer, five years later, is still a resounding 'no'.


5. Conclusions

The legal tests of merchantability and fitness for purpose quite probably don't apply to SaaS providers. That may be lucky for SaaS providers, but it's very unlucky indeed for the individuals, micro-organisations and small organisations that are relying on them. This short paper has considered just one very narrow aspect of the fitness for purpose of just one category of cloud computing. But it paints a picture less of happy, fluffy cumulus, and much more of nimbus, rumbling darkly, and rapidly approaching.


References

ACCAN (2012) 'What consumers need from cloud computing' Position Statement, Australian Communications Consumers Action Network, 11 December 2012, at https://accan.org.au/index.php/broadband/broadband-policy-positions/514-position-statement-what-consumers-need-from-cloud-computing

ACL (2010) 'Australian Consumer Law' Schedule 2 of the Competition and Consumer Act 2010 (Cth), at http://www.austlii.edu.au/au/legis/cth/consol_act/caca2010265/sch2.html

Clarke R. (2010a) 'User Requirements for Cloud Computing Architecture' Proc. 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing, Melbourne, Australia, 17-20 May 2010, pp. 625-630, PrePrint at http://www.rogerclarke.com/II/CCSA.html

Clarke R. (2010b) 'An Evaluation of the Terms of Service and Privacy Policy of the LinkedIn Professional Networking Service' Xamax Consultancy Pty Ltd, December 2010, at at http://www.rogerclarke.com/EC/LinkedIn-1012.html

Clarke R. (2011) 'The Cloudy Future of Consumer Computing' Proc. 24th Bled eConference, June 2011, PrePrint at http://www.rogerclarke.com/EC/CCC.html

Clarke R. (2012) 'How Reliable is Cloudsourcing? A Review of Articles in the Technical Media 2005-11' Computer Law & Security Review 28, 1 (February 2012) 90-95, PrePrint at http://www.rogerclarke.com/EC/CCEF-CO.html

Clarke R. (2013a) 'Cloud Computing Consumer Protocol' Submission to the Australian Computer Society, Xamax Consultancy Pty Ltd, August 2013, at http://www.xamax.com.au/EC/ACS-CloudCompProt-130812.pdf

Clarke R. (2013b) 'Data Risks in the Cloud' Journal of Theoretical and Applied Electronic Commerce Research (JTAER) 8, 3 (December 2013) 59-73, Preprint at http://www.rogerclarke.com/II/DRC.html

Clarke R. (2015a) 'Practicable Backup Arrangements for Micro-Organisations and Individuals' Xamax Consultancy Pty Ltd, September 2015, at http://www.rogerclarke.com/EC/PBAR.html

Clarke R. (2015b) 'Managing the Risk of Cloudburst: Backup Strategies for Users Dependent on Service-Providers' Xamax Consultancy Pty Ltd, September 2015, at http://www.rogerclarke.com/EC/PBAR-SP.html

Hunt K.M. (2015) 'CloudConsumer: contracts, codes & the law' Computer Law & Security Review 31, 4 (August 2015) 450-477

Menn J. (2011) 'Cloud creates tension between accessibility and security' Financial Times, 14 November 2011, at, http://www.ft.com/intl/cms/s/0/6513a4d6-0a06-11e1-85ca-00144feabdc0.html;2011. com/EC/CCEF-ITMediaReports-1109.rtf

NIST (2011a) 'Cloud Computing Standards Roadmap' NIST CCSRWG-092, National Institute of Standards and Technology, July 2011

NIST (2011b) 'Guidelines on Security and Privacy in Public Cloud Computing' Special Publication 800-144, National Institute of Standards and Technology, December 2011, at http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf

NIST (2013) 'Cloud Computing Standards Roadmap' NIST Special Publication 500-291 v2, National Institute of Standards and Technology, July 2013, at http://www.nist.gov/itl/cloud/upload/NIST_SP-500-291_Version-2_2013_June18_FINAL.pdf

NZCC (2013) 'The CloudCode' Institute of IT Professionals NZ, v.2.0, July 2013, at https://cloudcode.nz/Cloudcode

Schneier B. (2015) 'Debate: Cloud computing: Should companies do most of their computing in the cloud? Rebuttal Statements' The Economist, 29 May 2015, at http://debates.economist.com/debate/cloud-computing?state=rebuttal

Vincent M. & Hart N. (2011) 'Legal issues in the cloud' Computers & Law 79, 1 (2011), at http://www.austlii.edu.au/au/journals/ANZCompuLawJl/2011/1.pdf

Schofield J. (2010) 'We have the internet: now we need the intercloud, says Vint Cerf' The Guardian, 6 February 2010, at http://www.theguardian.com/technology/blog/2010/feb/05/google-cloud-computing-intercloud-cerf


Author Affiliations

Roger Clarke is Principal of Xamax Consultancy Pty Ltd, Canberra. He is also a Visiting Professor in Cyberspace Law & Policy at the University of N.S.W., a Visiting Professor in the Computer Science at the Australian National University, and a Director and Company Secretary of Internet Australia.



xamaxsmall.gif missing
The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021.

Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer
Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 4 September 2015 - Last Amended: 13 September 2015 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/FPTB.html
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2022   -    Privacy Policy