Cloud Computing: An Exercise in Architecting Trust

Cloud computing is a misnomer of arcane origin. Originally the “cloud” was literally just a technology doodle (beyond the then-available lexicon or the plastic templates of systems architects 40 years ago).¹ The billowing shape was used in system schematics to represent something beyond the computationally and conversationally stunted devices of the time (reminiscent of the ancient cartographers’ “terra incognita”). But over time, and especially with the dawning of the gigabyte era, the image/term has been co-opted to visually/linguistically represent what NIST has defined as “a model for enabling ubiquitous access to shared pools of configurable resources (such as computer networks, servers, storage, applications, and services).”²

Rather than the cloud being a thing, it is actually a process.

So how do you cloud compute? You enlist the aid of applications, platforms, and resources owned and controlled by third parties, when and as needed. Whether infrastructure as a service (IaaS), platform as a service (PaaS), and/or software as a service (SaaS), you (the consumer of cloud services) hand over management and control of critical information technology infrastructure to third-party vendors (who legally become your agent[s]). From a legal perspective, that means you delegate responsibility for performance to your agent, by contract (whether negotiated, click-through, or any variation in between). However, despite such delegation of performance you (as principle) still retain primary legal liability for anything that your agent does during such performance. It is important, therefore, that the contract with the agent/vendor adequately and equitably allocates the risks you retain as principle. And that is where most legal issues occur: as a failure to adequately address or allocate such risks.

Part of the risk concerns come from most cloud vendors’ perspective that since they are providing a standardized suite of services to all customers, the contract for such services should also be standardized (i.e., a form contract). These form contracts always seem to disproportionately favor the vendor (and if the cloud vendor has market power, it can force such unfavorable terms across its customer base). What this form-based contracting ignores is that risk is most efficiently allocated in an open marketplace to the party that has control. In the cloud environment, the vendor by definition has control (of the activity), but the form contract avoids and minimizes shifting the risks related to this control, thereby negating the actual monetary consequence of whatever choices the vendor may have made in architecting or operating its cloud. This can be done in the form agreement via:

• limitations of liability and/or caps on liability (that, while proportionate to the value to the vendor of the contract-for-service, have no relationship to the absolute risk of and costs to the cloud customer);
• limited indemnification provisions (leaving the principle exposed to disproportionate third-party risks, even if covered for the customer’s own first-party risks); and/or
• disclaimers of the true equitable and/or monetary damages the customer may experience from a vendor’s activities in favor of service credits (that represent only a fractional or variable cost to the vendor, with little proportionality to the actual customer risks and damages).

However, even when contracts for cloud services are negotiated, attorneys sometimes forget that these negotiations must be mapped against their client’s enterprise vulnerability, which must account for both the probability of disruption or liability and the severity of the consequences.³

Intentional risks grab headlines (and disproportionate mindshare in cloud contracts).

Certainlythe nefarious activities of hackers involved in cybercrimes and security breaches are problematic, require contract allocation of risks, and are prime candidates for risk-sharing with insurance underwriters of cyber insurance.

But cyberterrorism and cyberwarfare are now equally an issue of risk allocation.⁴ Similarly, the intentional acts of the vendor in architecting, implementing, and/or operating its cloud infrastructure based around appropriate standards (and certification and residual auditing around such standards) need to be addressed in negotiations (and run the gamut from the esoteric to the more mundane aspects of cloud operation, such as employee background checks and the physical security of locked doors and drawers).

Negligent risks are more familiar territory for attorneys. Such risks begin with a duty, such that the first issues in cloud contracting are to properly and adequately define the vendor’s duty in the agreement (and make such duty both legally and practically enforceable). Once such duty is articulated in the contract, then the task turns to not only allocating the risks of loss from failure to adhere to that defined duty, but also monitoring for lapses of that duty over the term of the contract. So, for example, shifting uptime responsibility to a vendor and allocating the monetary losses from a breach of such duty is essential in the contract. But however necessary that may be, it is insufficient unless there is appropriate responsibility for monitoring in place of the contract to compensate against a breach of such uptime duty (i.e., the vendor has a much better ability to assess when its infrastructure is working than the customer, so it is legally appropriate to place an affirmative obligation on the vendor to monitor, report, and automatically credit for downtime rather than requiring the customer to either notice and/or report downtime).

Trust is the extent to which one party relinquishes control to another party on the belief that it will fulfill tasks and responsibilities the grantor values. In the cloud, our clients relinquish control. Unfortunately, the cloud was never architected for trust; it is completely agnostic, in that each bit is valued the same as every other bit. So much of what attorneys must do in the cloud environment is architect such trust between the client and a cloud vendor. And this must be done with the sole tool available: appropriate contract language that requires an alignment between the cloud vendor’s values and the client’s values (as set out in the tasks and responsibilities a vendor must assume, by contract, to implement such client values).

----------------------------

¹ See www.retroist.com/2009/01/11/ibm-flowcharting-template/ for example of an early plastic template used for system analysis.

² SP 800-145, The NIST Definition of Cloud Computing, at http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf.

³ See generally, Sheffi, The Resilient Enterprise, MIT Press, 2005.

⁴ See Frey, Cyber-warfare, cyber-terrorism, and cyber-crime, Financier Worldwide, April, 2013; www.financierworldwide.com/cyber-warfare-cyber-terrorism-and-cyber-crime/#.WgnxjMJPqUk.