Thoughts from the RSA Conference
As the partners of InfoLawGroup make our way through the sensory overload of the RSA Conference this week, I am reminded (and feel guilty) that it has been a while since I posted here. I have good excuses - have simply been too busy with work - but after spending several days in the thought-provoking environment that is RSA, I had to break down and write something. A few observations, from a lawyer's perspective, based on some pervasive themes:
- We all need to work together, and we can. Legal, Information Security, Privacy, Compliance, IT, and the affected business units. Now more than ever, it is essential that ALL the stakeholders join forces, as early as possible, to address security and privacy risks, assess and vet business deals, and put in place appropriate procedures - RFPs, due diligence, contract negotiation - to address the risks.
- Cloud, cloud, cloud, yada, yada, yada. Hold up - the technology is not new - but usage and the business model have changed dramatically. I have been having this argument with my information security and technology friends for months. OK, I get it. "Cloud" technology in some form or another has been around for 30 or 40 years. What is new is the massive scale, availability and changes in usage and the business model - in part driven by the economics. Guess what? Those business model changes make the legal risks even more pervasive. Going back to (1) above, all of the stakeholders need to be in the room (or on the phone or videoconference) discussing the issues BEFORE the decision is made to enter into a cloud arrangement. ANY cloud arrangement. Not after the RFP is issued. Not after IS does its due diligence. Not after the contract negotiations have begun. And not after the contract is inked. The same due diligence and attention to risks that would apply in a traditional outsourcing/offshoring relationship must be applied here, too. The cost savings are illusory if the short-term and/or long-term risks are significant. Think about the kind of data at issue. What are the risks? Evidence preservation, data security, breach response, enforcement rights, indemnification. And before we even get to those - can the data be transferred across borders in the first place? Think about it early. And then talk about it before decisions are made.
More after the jump.
- Privacy is the next frontier in Information Security. Wait, what? I have to admit that my initial reaction to this was - seriously? Privacy regulations have been here for some time. That's true, and the privacy profession has been growing for the last 10-15 years. But the privacy profession is in its infancy as compared to information security and IT. Why is the privacy profession growing? In part because the regulatory environment has exploded. But Information Security and Privacy care about the same thing -- data management and governance. We can help each other find creative solutions to mitigate risk.
- The regulatory scheme is becoming more complex, at breakneck speed. What regulations do information security professionals and the businesses they serve need to understand and address? Many - international, federal, state, and local. And things are changing constantly. Just this week the Massachusetts data security regulations became effective. And last week the FTC filed its notice of appeal of the District Court's ruling that the FTC cannot apply the Red Flags Rule to attorneys.
Information Security and Privacy, together with Legal, should consider all potentially applicable laws in evaluating security risks. What are those laws? Well, depending on your industry, and where your customers and employees reside, a few, but not all, might include FTCA, GLBA, HIPAA (including the HITECH Act), state data security laws (such as the new Massachusetts data security regulations and Nevada's encryption and PCI law), Sarbanes-Oxley, Red Flags Rule, FACTA Disposal Rule, ECPA, E-Sign, FERPA, the Federal Rules of Civil Procedure and Evidence, the PATRIOT Act, PIPEDA, the EU Data Protection Directive, EU member country laws, other foreign laws across the globe, state breach notification laws, and Social Security number protection statutes. But there are many more. And that's not even getting into contractual standards such as PCI-DSS.
- Lawyers need to embrace technology. I was fortunate enough to attend a CLE last week, pre-RSA, hosted by the Entertainment Law and Intellectual Property Section of the Los Angeles County Bar Association. Roland Trope, who moderated the panel on social networking issues, raised a tremendously important question: Are lawyers "competent" if they do not keep track of, and understand, changes in technology? The ABA is considering changes to the Model Rules of Professional Conduct to address this question. Some take the position that no changes are necessary and that the requirement can be read into the existing Rules. In any event, what better place than RSA to reflect on that question and the future of the legal profession and its relationship with technology.
That's it for now - back to work, and preparing for my next cloud presentation tomorrow. In the meantime, I encourage our readers - the lawyers, the information security professionals, and the privacy professionals - to weigh in.
Quickhits: Security in the Ether; Countrywide Settles Data Breach Case
Happy New Decade (2010)! Unbelievably another decade is gone. Information law developments continue to occur at an increasingly fast pace. The InfoLawGroup is catching up from a very busy December, so we will start out the 2010 blogging with a couple quick hits.
Security in the Ether. A very nice article by David Talbot on the security challenges, myths and misperceptions around Cloud computing. The challenge for security pros and lawyers: what is "reasonable security" in the Cloud, how do you perform your "due diligence," how do you document your due diligence process for use in the event of a breach, litigation or a regulatory action, and how do you draft and negotiate contracts for Cloud-based services?
Judge Preliminarily Approves Countrywide Data Breach Lawsuit Settlement. Faced with 35 lawsuits (many of them class actions) arising out of a security breach exposing the records of millions of customers, Countrywide Financial Corp. has chosen to settle. The settlement includes an offer of one year of credit monitoring for up to 17 million people. In addition, customers that suffered identity theft may recover up to $50,000, but only if they actually lost something of value, were not reimbursed and the theft stemmed from the Countrywide breach. Assuming a 20% redemption rate and a cost of $5-$15 per year for credit monitoring, the credit monitoring alone could cost from $17 million to $51 million (probably on the lower end of the scale -- Countrywide should be able to negotiate favorable credit monitoring rates considering the potential volume). Additional costs that Countrywide had to incur include legal fees and breach notice expenses (assuming breach notice laws were triggered). Does this settlement (and others I am aware of other settlements that have been less publicized) indicate a growing fear that the "damages" wall is weakening?
Compliance as a Service (CaaS): The Enabler Role of Legal, Security and Privacy Professionals
Cloud computing promises incredible benefits for companies looking for inexpensive and scalable computing solutions without the need to do it all themselves (or the costs or personnel). However, as foreshadowed in the InfoLawGroup’s “Legal Implications of Cloud Computing” series (see Part One, Part Two and Part Three) data security, privacy and legal compliance issues are beginning to cause great concern. Stories like this highlight these concerns. High profile information security snafus (fairly or unfairly) have also stoked the fire: Rackspace power outage, Amazon denial of service attack, and the Sidekick Data Loss. Data leakage is maybe problematic as well based on Cloud architecture. In fact, the InfoLawGroup has encountered some companies that are taking a pass on cloud computing (“v. 1.0”) because of regulatory, privacy and security concerns. Do these compliance concerns threaten the Cloud computing model or potentially reduce the cost benefits it promises?
The answer to this question is not clear at this early stage. However, what is becoming clearer is that attorneys, privacy experts and security professionals will increasingly (hopefully) become part of the solution. On one hand, this group of professionals act as organizational gatekeepers when it comes to implementing new IT arrangements such as Cloud. To the dismay of IT managers and business interests, they may have to say “no” to certain Cloud transactions. On the other hand this group will increasingly act as enablers to Cloud vendors by helping them understand their clients’ legal, security and privacy concerns, and providing them with the ability to design their Cloud and services in a manner that addresses those concerns. This activity will take place well before the transaction phase, and its purpose is to create a Cloud that moves the gatekeepers away from “no.” This post explores the enabling role that these professionals will likely play in the coming months and years.
Understanding the End Client/Users Applicable Compliance Issues
The adoption of Cloud computing faces significant potential push-back from legal, privacy and data security stakeholders within an organization. For Cloud to be accepted by certain organizations and industry segments the Cloud solution must address legal, data security and privacy concerns. In essence, by baking compliance into the Cloud, service providers are providing “compliance as a service” (CaaS).
It is important for Cloud service providers to be proactive in this regard. Cloud providers that take the time to understand their clients’ needs ahead of time (as well as the needs of their clients’ clients or users) may gain a competitive advantage against “generic clouds.” If these Cloud providers can implement an architecture that addresses specific client needs and/or provides clients with tools or mechanisms to address these needs, they should rise to the top. Of course, price will also remain a major (the major) factor in a purchase decision. The challenge will be balance: “customizing” Clouds or building in additional features costs money, if these costs materially overwhelm the promised cost savings or functionality of the Cloud then it will not be a viable business opportunity. However, if providers don’t adequately address compliance issues, Cloud services may not be implemented in the first instance. Cloud providers must thread this needle.
A key activity for Cloud providers will be understanding the regulatory, privacy and compliance environments of their clients and end users, and providing Clouds with the infrastructure and tools to meet those needs. Lawyers, security pros and privacy vendors can help Cloud providers (and will be necessary to) achieve this. The legal, privacy and security concerns may vary depending on the industry, the specific activities of the organization, the data being processed and the regulatory environments that impact the company. While there may be commonalities and overlap between different types of organizations, the Cloud services will still have to address the differences that may exist. Ultimately, this may lead to “vertical clouds”: Cloud providers specializing in certain industry verticals that may have different needs or concerns (e.g. banking, healthcare, retail, etc). In fact, this is already beginning to happen (see. e.g. Legal Cloud, FedCloud, athenahealth, bankserv and Rackspace PCI Compliant Cloud).
Creating Transparency
Once the specific legal, security and privacy concerns of clients are understood, Cloud providers will have to go one step further and build transparency into their process to enable potential clients to efficiently perform their due diligence so they can enter into, draft and negotiate Cloud agreements. Again, this is where legal can serve in an enabling role. By understanding the end-client’s compliance issues, cloud providers can make it easier and more transparent for clients to get the information they need to have confidence that their concerns have been addressed by the Cloud provider. Vendor lawyers helping with the design of the Cloud will have to anticipate where transparency is needed, how to most efficiently achieve that transparency, and what information to disclose to clients to smooth through the due diligence and contract negotiation process. Examples of areas where more transparency will likely be needed include:
- Relationships in the Cloud (Who is processing, transmitting and storing the Cloud purchaser’s information?)
- Security policies, procedures and controls (What controls are in place in the Cloud? What security standards [e.g. ISO 27001] have Cloud providers met? Do the controls meet the standard of reasonable security for the purchaser of Cloud services? Are the Cloud provider’s controls consistent with and compatible with the Cloud client's internal security framework? )
- Information handling practices and privacy (What can the Cloud provider do with personal information? What does it plan to do with personal information? Are the Cloud provider’s practices consistent with applicable privacy laws and the Cloud purchaser’s own privacy policy?)
- Geography (Where is the data being stored and processed? What jurisdiction’s laws may be triggered based on the location and cross-border transfer of personal information? Will export restrictions be violated? Will governmental bodies be able to obtain information that flows through their country?)
- Incident response, data preservation and electronic discovery (What procedures are in place to respond to an incident suffered by the Cloud provider? What obligations does the Cloud provider have when it suffers an incident? What information will the Cloud provider provide to the purchaser concerning a security incident? How will a Cloud provider coordinate with a Cloud purchaser in the event of an incident? How will a litigation hold be initiated with respect to data stored or processed by a Cloud provider? How can data be preserved when on the Cloud provider’s systems? What measures are in place to establish the integrity and authenticity of a “document” stored in the Cloud?)
- Service level agreements (Can the Cloud vendor meet SLAs that are appropriate to its clients’ needs? Is the Cloud provider using third party Cloud provider to provide services, and has the former secured contractual rights consistent with the applicable SLA?)
Standards in the Cloud
Going forward, especially where multiple tiers of Cloud providers are involved and/or data is being transferred between multiple Clouds, “universal” standards may develop that could create more transparency. Rather than an ad hoc approach requiring potential Cloud clients to individually investigate compliance aspects of each Cloud provider, it is possible that generally accepted privacy and security standards may develop. Similar to the PCI approach, Cloud providers would certify their compliance with such standards and provide Cloud clients with proof of certification. This could provide more transparency and make the due diligence process more efficient. Moreover, it provides a benefit to Cloud providers: they can certify to the standards once and simply provide proof rather than having each of their clients perform a separate due diligence procedure or assessment for every transaction.
Conclusion
The opportunity for lawyers, security professionals and privacy experts to play a positive role in enabling Cloud offerings is very exciting. Rather than playing their traditional spoiler roles, assuming Cloud providers think proactively, these professions can actually help the Cloud model mature. Moreover, in some cases, early adopters creating customized Clouds that provide “CaaS” may actually achieve a competitive advantage. The end result of CaaS, if done properly, are cost-effective Cloud services that provide all the benefits that have been touted, while reducing legal, privacy and security risk to an acceptable level.
Legal Implications of Cloud Computing -- Part Three (Relationships in the Cloud)
While there is much debate on the IT side as to whether Cloud computing is revolutionary, evolutionary or “more of the same” with a snazzy marketing label, in the legal context, Cloud computing does have a potential significant impact on legal risk. Part three of our ongoing Cloud legal series explores the relationships in the Cloud, and the potential legal implications and impacts suggested by them (if you would like, for context, you can read Part One [the Basics and Framing the Issues] and Part Two [Privacy and the Cloud] of the series.
In the legal world, some take the position that Cloud is no different than “outsourcing”. Unfortunately, making that comparison reveals a misunderstanding of the Cloud and its implications. It is sort of like saying that running is no different than running shoes. Like “running,” outsourcing is a general term describing an activity. In this case the activity involves organizations offloading certain business processes to third parties. Cloud computing (like “running shoes”) is a “new” method for leveraging existing technologies (and technological improvements that have occurred in the past 20 years) that can be used by outsourcers to provide their services more effectively and cheaply (as running shoes represents a technology that can be used to achieve the activity of running more efficiently). In other words, one can outsource utilizing a Cloud architecture provided by a third party, or by using a more traditional dedicated third party hosted technology solution. Both are different technologies or methods for achieving the same activity: outsourcing of business processes.
For lawyers analyzing outsourcing to the Cloud the question is whether the technology, operational aspects and various relationships of a given Cloud transaction create new legal issues or exacerbate known legal problems. To illuminate this question, this post explores the relationships that exist between organizations outsourcing in the Cloud (“Cloud Users”) and those providing services in the Cloud. Coincidentally (or maybe not so much) understanding these relationships is crucial for attorneys that need to address legal compliance risk and draft contracts to protect clients entering into the Cloud.
Dark Opaque Storm Clouds or White Fluffy Transparent Clouds?
When it comes to relationships is the Cloud more like a dark storm cloud that one cannot peer into, or is it more like a fluffy, light and transparent cloud that allows one to see what is happening within? Unfortunately, the current forecast in some areas is for dark Clouds that make it difficult for Cloud Users to understand exactly with whom they are dealing and who is storing and processing their data. Transparency may be elusive and the very nature of the Cloud computing architecture may be the cause of this. In other words, even if an attorney wants to discover who is actually processing their data, the nature of the Cloud may make it very difficult for Cloud providers to provide definitive information on that point. This is in stark contrast to most traditional outsourcing relationships involving a single vendor and dedicated computing resources or software.
Moreover, even if all the Cloud players are known, it may be difficult for Cloud Users to manage and shift responsibility to a party that it has no direct relationship with, and no direct contractual legal rights or remedies.
In a traditional dedicated outsourcing model (e.g. web or data hosting, ASP model, etc.) organizations often deal with a single service provider that provides computing resources. That service provider typically would own or control the computing resources that support the outsourcing transaction. Oftentimes those computing resources would be dedicated solely to a particular client. To clarify and solidify this one-to-one relationship the outsourcing contract might have a clause prohibiting the use of sub-contractors to provide the services. In terms of legal risk, the organization utilizing the service provider would be able to conduct its due diligence (e.g. privacy compliance, “reasonable security,” etc.) on a single entity. Moreover, the organization would be able to negotiate a contract shifting risk between it and the service provider knowing that the service provider in essence directly “controlled” the risk by virtue of its control of the computing environment. Even in cases where a service provider uses a sub-contractor, in the typical case, the organization could fairly easily discover the identity of that party and perform its due diligence. More rare are instances of generic unidentified sub-contractors, or sub-contractors utilizing sub-sub-contractors.
Relationships in the Cloud: Who is processing my data?
It can be very different in the Cloud (click here to view one version of the Cloud landscape). This is not to say that Cloud relationships are not/cannot involve one-to-one relationships like traditional outsourcing. They can. At the base of the Cloud stack, it would not be unusual for IaSS providers to have direct relationships with some of their end-clients. For example, if an organization contracts directly with Amazon Web Services, a Cloud Platform (Infrastructure as a service – IaaS), to allow the organization to build its computing resources in Amazon’s Cloud, it would have a degree of confidence that it was dealing with the party that directly controlled and was responsible for maintaining the Cloud Platform. However, there are service-oriented organizations (integrators) that will actually help to build computing resources on a particular Cloud Platform. In that case a client would not necessarily have a direct relationship with the Cloud Platform, and yet would be subject to the limitations and problems of the Cloud Platform.
The problem is more prevalent as one moves up the Cloud stack. Companies that offer software as a service (SaaS) may have built their application within a particular Cloud Platform (examples can be found here, here, here, here and here). The Cloud User again would typically be dealing solely with the SaaS provider despite the fact that the Cloud User’s data is actually being stored and processed (in part or whole) by the Cloud Platform (at the PaaS or IaaS layer). In fact, it is possible that a particular Saas may actually serve its application on multiple Cloud Platforms. Those Cloud Platforms again are one step removed from the Cloud User and each may pose different legal risks. For example one Cloud Platform may have servers across the globe thereby potentially exposing a Cloud User to multiple privacy laws in various jurisdictions, while another may be purely domestic (thereby limiting the jurisdictions to which it the Cloud User may be exposed). In fact, there may be significant economic incentives for SaaS providers to switch between Cloud Platforms that are more efficient or less expensive (thereby improving the SaaS profit margin).
To make the situation more complex, it is also possible for a particular SaaS to use more than one Cloud Platform for an individual Cloud User client. In these cases, data processing might alternate between multiple Cloud Platforms (either because it provides for better efficiencies or perhaps a particular Cloud Platform provides the SaaS with a better price/profit margin). Again, in the legal context this can be problematic. If a SaaS decides to move processing to a Cloud Platform with weak security for example, it could significantly increase the liability risk of a Cloud User if the platform suffers a security breach. It would be very difficult to perform adequate “due diligence” where data is constantly shifting between multiple Cloud Platforms.
Cloud Service Aggregators
Unfortunately, this may be just the tip of the iceberg. In the foregoing example the Cloud User was at least dealing with a single Cloud SaaS provider on the front end. This would not be the case when dealing with Cloud service aggregators. Aggregators essentially bundle (and possibly integrate) multiple SaaS services into a “single” service (examples of aggregation models are here and here). For example, one could envision an aggregator bundling multiple Cloud SaaS offerings for use by travel agents (you can search for examples of SaaS providers serving industry verticals here). The bundle might include a customer relationship management application, a booking and reservations application, a credit card processing application, a billing platform, an international time zone translator application and an electronic signature/e-commerce application. To the Cloud User this bundle would appear to be a single seamless consolidated application.
The reality is that each of the applications may be operated or created by separate SaaS providers. It is also possible that each of these SaaS providers might serve their application on a different Cloud Platform. There may be variations in each application in terms of reliability and security. Moreover, as discussed above each SaaS provider might be using multiple Cloud Platform’s and that use may not remain static (e.g. it’s a moving target). While aggregation models appear to be just gaining traction they could become more prominent going forward, and legal and security/privacy impacts of these models need to be carefully scrutinized.
The Legal Conundrum
The scenario described above poses significant legal challenges for Cloud Users’ transactional and compliance counsel (as well as security and privacy professionals). Due diligence and contracting are potentially much more difficult when the Cloud is involved.
In some cases the Cloud User may be two or three levels removed from the organizations actually processing and storing the Cloud User’s data. For example, without a direct relationship with the lowest level Cloud Providers, organizations will not be able to directly analyze compliance issues around privacy and security compliance and reasonableness. As such Cloud Users will have to somehow confirm that the direct party they are dealing with engaged in proper due diligence. It almost becomes a meta analysis: due diligence might involve a Cloud User analyzing whether a Cloud Provider’s due diligence process itself was adequate. This would likely include receiving any reports or other types of analysis performed by the higher and lower level Cloud Providers. As discussed below it should also include a review of the contracts the higher layer Cloud Provider has with the level below it.
Of course it more than two levels are involved or there are multiple service providers or Cloud Platforms involved on a particular level, one must have confidence that each of the players also performed adequate due diligence on the providers it utilizes, and so on. So in essence, the Cloud User would be seeking to somehow validate that the Cloud Provider performed adequate due diligence of the due diligence process of the Cloud providers in the level immediately below it. In essence, the Cloud User would want to see a “Chain of Due Diligence.” This requires that the providers on each level of the chain think ahead and anticipate the needs of the Cloud provider or Cloud User in the layer immediately above it.
Another example to illustrate the point involves incident response contract terms. What happens when the Cloud transaction involves multiple layers and the lower layer suffers a data security breach exposing the PII of the Cloud User’s data? What happens when the Cloud User needs to implement a litigation hold to preserve data where the data resides in the lowest layer of the Cloud?
In a typical direct outsourcing relationship, the outsourcer and its client would build processes in to address these issues and the contract would provide for particular rights and remedies. While similar contractual rights and obligations may be built into a Cloud transaction, it is not clear how useful they would be when multiple layers are involved. For example, if a SaaS built on a Cloud Platform has itself failed to obtain certain rights and abilities to forensically analyze and preserve data processed in the Cloud Platform, the Cloud User may not be able to adequately build defenses in a security breach context or implement an effective litigation hold (regardless of what the contract between the SaaS and Cloud User provides).
A final example: data retention and destruction policies. What if the SaaS provider is working on a Cloud Platform that creates residual copies of data that the Cloud User has a legal obligation to delete? What if the SaaS provider works with a Cloud Platform that does not have the technology or capability to properly wipe data? Even if the Cloud Platform has these capabilities, what if the SaaS provider has not negotiated for the right to obtain these services? Again, to make this work it is incumbent on the SaaS provider to anticipate the end Cloud User’s needs and to only work with Cloud Platforms (or other Cloud providers) that have the capability (and willingness) to meet those needs.
Conclusion
We are very much at the start of the Cloud computing phenomenon, and luckily we have an opportunity to proactive identify and attack these issues now. However, it appears that Cloud is gaining significant momentum and time is running short to address these matters. While the ultimate “solutions” will take time to develop, legal counsel (and the legal community as a whole) should begin developing strategies and approaches for handling Cloud transactions.
A key factor (and crucial first step) in addressing Cloud legal risk for a particular transaction is understanding the relationships of the Cloud. Legal counsel (with a huge assist from IT and security) should consider taking steps to achieve this understanding and limit risk, including without limitation:
- Insist on and acheive transparency. Don’t allow the Cloud to be a black-box storm cloud. Identify the Cloud players involved in a transaction, identify where they process the Cloud User’s data, map the data flow between Cloud players and determine whether the Cloud players are static or dynamic (e.g. can/will the Cloud players change in the middle of the contract). Do this early so the organization does not need to play catch-up.
- Develop due diligence strategies and procedures, and follow and document them. Primary Cloud relationships should be directly scrutinized. Moreover, the due diligence processes of Cloud providers relying on lower layer Cloud providers should be analyzed to determine if they are adequate. Any validations (e.g compliance with standards such as ISO 270001 or SAS 70s II) or relevant reports from the various players should be obtained. The capabilities, limitations and processes of lower layer Cloud providers should be explored to ensure that they can satisfy the Cloud User’s legal obligations and do not pose additional, unanticipated legal risk or obligations.
- Confirm that Cloud providers have contractual rights to do what you need them to do. Contractually requiring an Cloud aggregator or SaaS provider to retain data, or obtaining the right to audit the security protecting the Cloud User’s data, is meaningless if the aggregator or SaaS itself does not have such rights with respect to lower layer Cloud providers. Cloud Users do not want to find this out when they have a need to exercise their contract rights (e.g. when a regulatory action, privacy breach of lawsuit happens). As such, it is important to analyze the contracts a higher level Cloud provider has with the Cloud providers it relies on to make sure the necessary rights flow through the contract chain.
- Think Way Ahead – Contractual Requirements Should be Part of the Request for Proposal Phase. Obviously performing a proper due diligence can be very time consuming, especially when multiple layers of Cloud providers are involved. It is much more difficult to achieve due diligence when the Cloud transaction has moved forward significantly (e.g. the competitors have been told they are no longer being considered and negotiations on key terms, like price, have occurred). The time to address these issues is in the RFP process. Organizations should plan ahead and identify the criteria necessary for the company and have Cloud providers confirm that they meet the criteria in their response to a RFP. At this point in time, I recommend that RFPs actually identify legal contract terms (e.g. indemnification, exceptions to limits of liability and consequential damage disclaimers) that Cloud vendors must agree to in order to get the business. Not only does this save time, but it also creates a competitive incentive for Cloud providers to take on more risk (so that they can win the business).
