You are on page 1of 13

Google

Apps @ LBL - Considerations and Risk Analysis


Dates and document versions: August 9, 2011: Edits for public release January 18, 2009: Draft released internally

Overview
This paper identifies a number of issues related to the use of Googles Gmail service (and Google Apps more generally) by Berkeley Lab staff, and provides some context and analysis intended to assist in the management decisions about use of these services at Berkeley Lab. It is assumed that line management will make risk-informed choices about whether the service is appropriate for their specific research. A slightly different version of this paper was originally prepared by a small working group of the UC IT Policy and Security Officers Gabriel Lawrence (San Diego), Robert Ono (Davis)*, Janine Roeth (Santa Cruz), Adam Stone (Berkeley Lab) and Kent Wada (Los Angeles) in concert with Senior University Counsel Cynthia Vroom who raised many of these concerns. This is an initial working draft for comment and discussion. It should not be further redistributed. This draft is the short version of this analysis, designed for distribution to the community. A much larger internal version is available to Berkeley Lab staff who wish to further analyze these issues.

A. Conclusion
We believe there are no serious risk factors that preclude Berkeley Lab from moving forward with Google services under the existing agreement; however, renegotiation of the contract to bring in existing standard Google terms is desirable. There are inherent tradeoffs involved in such a move, but these are within the acceptable risk envelope for the Laboratory. No policy or legal issues prevent such a move, and the advantages of the move are substantial.

B. Background
Berkeley Lab has deployed components of the Google Apps Suite at various levels of deployment to its staff under the University of California contract with Google. The contract contains provisions that improve the privacy and security terms of the contract, and appropriate indemnification agreements. Google Apps is a set of services provided by Google, which are linked together through an administrative interface. This interface provides control over users and settings across the applications. This interface is linked via multiple methods to our identity management systems. Provisioning, deprovisioning, and authentication are all managed by our systems.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

1 of 13

Google Apps is not consumer Gmail. It is a set of enterprise services utilized by hundreds of companies and institutions of higher education with similar or greater privacy and security concerns then those of Berkeley Lab. Services and Status as of 10/9/09
Service Gmail (Google Mail for Berkeley Lab) Description Provides institutional email capabilities. Status Completed phase 0 pilot (~20 employees for 1 year). Phase 1 Pilot in progress (~200 employees with full migration of existing content). Based on Phase 1 experience, we could begin transition by CY10 Discussion In current architecture, mail handling (routing, spam/virus, etc) will remain insourced until a separate architectural decision is made. This means that mail routes through LBL servers to Google in both inbound and outbound configurations. All existing virus, spam, and policy protections applied to inbound and outbound email will remain the same. Users already have a choice of email providers at LBL - institutionally provided, locally provided, or a provider of their choosing.

Google Docs

Google Sites

Google Start

Collaborative authoring and publishing of documents, spreadsheets, and presentations to and with anyone with a Google Account. Collaborative multiple- shared resource environment for small workgroup collaboration. Portal start page. No longer included in new Google Apps accounts.

Labwide pilot to all LBL employees and collaborators. Pilot expected to last through 2012. Hundreds of users today.

Labwide pilot to all LBL employees and collaborators. Pilot expected to last through 2012. Hundreds of users today. Labwide pilot to all LBL employees and collaborators. Pilot expected to last through 2012. Promoted as gateway to google apps. Very lightly used. Limited pilot. Accessible to all employees for viewing, but not uploading. Available to employees but not part of our current enterprise calendaring offering. Under consideration as possible replacement for current service.

Google Video

Google Calendar

Provides video sharing only to LBL employees (no external sharing by account or public). Provides enterprise calendar support.

Limitations of included storage mean this service cannot currently be part of our architecture for video sharing. Integration with campus complicates calendar architecture decisions.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

2 of 13

Google Labs Features: Moderator and Short Links Administrator Functionality

Various beta-beta services.

Provides user- provisioning and authentication.

Moderator available but described only by word of mouth. Short links available via inclusion in Docs and to public affairs directly. Populate users from enterprise directory to Google via custom scripts and use of Google API. Users authenticate with their existing enterprise password to LBL servers which pass SAML2.0 assertions back to Google. Secondary password for non-web services is a requirement, and passwords are synced to Google for this purpose.

C. Issues Analyzed
1. Ownership of Information
Concern Google's service (or any outsourced service) would have an impact on LBL/DOE's intellectual property rights. Discussion The UC Agreement with Google clearly specifies that the Lab owns intellectual property rights to all Customer Data, and Google owns all intellectual property rights in relating to the service (See UC Agreement Section 8 and Google Apps Education Edition Agreement (031809), Section 7.1). There is further language in the Agreement that covers indemnification and liability (See UC Agreement Section 13, 14 and Google Apps Education Edition Agreement (031809), Sections 12, and 13). Recommendation We believe that the existing UC Agreement prevents Google from exercising any claims or use of the intellectual property in the system. There is nothing in the language that would change the current ownership of records, or the Department of Energy's ownership interests.

2. Compliance with DOE Policy


Concern Storage of Berkeley Lab data at Google is not consistent with DOE policies. Discussion There is currently no DOE policy that specifies anything about the particular sourcing strategies of Laboratory IT. Fundamental research data already is held through collaborations around the world, and work products are often shared across numerous private and public research networks and systems around the world. DOE policy does require that the Laboratory take an informed, risk-managed view of its IT and cyber security environment. Berkeley Lab has analyzed the set of issues around Google Apps for over two years and has made the informed judgment that its use is consistent with appropriate stewardship of DOE resources and information. Berkeley's position is that Cloud-based services, which are part of our larger service portfolio, should be C&Ad as part of the broader General Support System or Major Application they are a component of. In this case, email is part of our Research and Operations enclave, for which the documentation contains the key requirements to approve an outsourced information system within the context of the existing GSS. Google Apps meets or exceeds all requirements that are part of the ROE enclave envelope for outsourced information systems.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

3 of 13

Recommendation Ensure CSPP and Common Controls document are modified to reflect current sourcing strategies as required.

3. Compliance with Federal Policy and FISMA


Concern Storage of Berkeley Lab data at Google is not consistent with Federal policies. Discussion There is currently no Federal policy that would prohibit such a move. In fact, the direction of OMB at this time is towards the use of cloud-based servies for work that is more inherently federal and more sensitive then that of LBL. See http://apps.gov Recommendation No action required.

4. International Storage and Export Control Laws


Concern Storage of Berkeley Lab data in other countries may result in violations of export control laws. Discussion Background: Google stores information in geographically redundant data centers, including those in other countries. The purpose of this architecture is to provide high resiliency and reliability, as well as speedy response times for users around the world (See Physical Security and Information Accessibility in Comprehensive review of security and vulnerability protections for Google Apps, Google whitepaper February 2007). As a general rule, LBL does not engage in Foreign National restricted research, nor does it filter access to its systems today by nationality. The total amount of truly export-controlled research at LBL is miniscule, because our research typically is intended for publication and thus covered by the fundamental research exemption. Where there is non-fundamental research information, such information is not marked export controlled, but rather is potentially export controlled because it is associated with an NDA. Today, LBL systems are not approved for the storage of export controlled information and instances of export controlled information are typically managed on paper. The normal course of operation of Google systems would not result in export of information to any foreigner since information in email remains the property of the Lab and no Google employee is supposed to be inspecting it. One interpretation is that this means that the service can be assumed to be not in danger of affirmative export of information, regardless of the country in which the server resides. Some observers have suggested that an appropriate analogy may be temporary storage of goods in a foreign country (NACUA:2009). We consider the risk stemming from an export control violation in this area to be quite low, noting no guidance has been provided by either the Department of Commerce or the Department of Defense that would appear to suggest that transient storage of information would present an export control issue. We note that the UC Agreement has language specific to export control laws (See UC Agreement, Section 3.4) while the newer Agreement does not. Recommendation Reaffirm that email is never an acceptable means of transmitting or storing export controlled information at Berkeley Lab. In addition, Google intends to offer a North American-only cloud for government customers, and possibly others in the near future. This would allow us to directly consider the cost-benefit of such a move. The additional costs associated with this service offering are unknown. LBL will continue to track the cost of this offering.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

4 of 13

5. International Storage and Exposure to Foreign Governments


Concern Google might store information in a data center that was covered by international laws in a way that exposes Lab/individual information to foreign governments. Discussion (See Background in previous issue) This concern rests on the theory that the location of a companys information or a service providers operations immediately subjects those operations to access by foreign governments. We consider this risk low considering two scenarios: 1) A foreign government (FOGO) might physically take hardware from an international Google data center in an attempt to get information about an individual Lab employee; or 2) A foreign government might demand data from Google on a US user simply because Google conducts operations in that country. Both of these scenarios require knowledge as to the location of data on a particular user. Based on Googles description of their data storage, we believe that identifying a particular datacenter for storage or transmission of information would be very difficult and require Google proprietary knowledge (See Information Accessibility in Comprehensive review of security and vulnerability protections for Google Apps, Google whitepaper February 2007). We believe that such access or requests would be an international incident. Stories about Yahoo! and Microsoft giving information to foreign governments have been major international news items, and in these situations a citizen/resident of the country was the subject of the request with the locus of operations being the foreign subsidiary of the company. We see no precedent for US customers of US companies being targeted by foreign governments simply because the multinational company has operations in multiple countries. Even if this were to happen, the actual impact would be very low. Berkeley Lab conducts fundamental research intended for publication and does not accept work with foreign national controls. Such work being exposed to a dedicated foreign adversary is not just an acceptable risk already defined in our risk assessments, but truly a very modest issue for Berkeley Lab. Recommendation Track the evolving legal environment. If the legal environment changed in such a way as to create some individual risk or institutional risk, the Lab would also be able to adjust its sourcing strategy or Google would be able to adjust its use of international datacenters as well.

6. Foreign National Access to LBL Data


Concern Storage of Berkeley Lab data at Google would expose LBL data to foreign nationals in a way that is forbidden by DOE or LBL policy. Discussion There is currently no DOE or LBL policy that governs access to IT resources by foreign nationals outside of export control issues described above. Berkeley Lab policy is that there we do not make distinctions between IT access on the basis of nationality. We do not screen access to systems by nationality at all. Laboratories with foreign national access controls will likely not be able to get sufficient assurance from Google regarding citizenship of their employees until the US only datacenter offering becomes available. If we were to take an entirely citizenship-neutral view, we would simply look at what the risk of exposure to an employee of Google is. For this discussion, see Privacy concerns below. Recommendation No action required.

7. Law Enforcement Requests


Concern Berkeley Lab will not have knowledge of subpoenas or other lawful intercepts.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

5 of 13

Discussion Both agreements require Google to notify the Customer of third- party requests, if they are legally able to do so; civil subpoenas and most criminal subpoenas would fall into this category (See UC Agreement, Section 7.3 and Google Apps Educational Edition Agreement (031809), Section 6.4.b). The UC Agreement has additional language that when Google is required to respond directly to a third-party request, they will also notify the End-User. (See UC Agreement, Section 7.2.1.b). There are some potential classes of legal requests, such as gag-order subpoenas and national security letters, where Google would be unable to share the request with LBL. We believe the risk is reduced by the likelihood that the requester may not go directly to Google. The requester may or may not know where the information they are interested in is being stored and unless the requester only wants information from Google's services, they would need to make the request to LBL as well. This would give LBL knowledge of the instrument, and thus the ability to take informed action. Further, many USG requesters would come directly to the Lab or to DOE's IG, assuming that our records would be accessible through the same mechanisms as agencies (which they might or might not be depending on the situation). Recommendation We recommend use of the current agreement. We will leverage possible UC negotiations for language that may require Google to act as our agent in the case of gag-order subpoenas.

8. Implementation of eDiscovery
Concern The process of eDiscovery is complicated by outsourcing email. Discussion Litigation holds may require searches and preservation of existing information and/or preservation of information going forward. This is typically done, by the user directly or assisted, with a copy of the individuals current email inbox and subsequent searches of same. The individual may be asked to place relevant new information into a folder for later searching, or all new incoming email for the individual is copied to a blind account for preservation. The process of retrieving information for preservation from Google is not dissimilar from currently used approaches. Google offers a standard interface (IMAP) for the downloading of email inbox contents. Other services in Google Apps have similar capabilities provided by established interfaces. If required, the administrative interface provides the Lab access to individual's email account and contents. We note that the newer agreement includes language that clarifies Googles participation in responding to third-party requests, e.g., Google would, at our request, participate in production if the ability to produce information requested was not available to us through our interfaces (for example, IP logs) (See Google Apps Education Edition Agreement (031809), 6.4b) Recommendation We believe that the approach to eDiscovery does not change substantially with a transition to Google. We recommend the language in the newer Agreement be reviewed and considered for our UC Agreement.

9. Retention Schedules and eDiscovery


Concern Google never deletes anything; there is no set retention schedule that can inform eDiscovery. Discussion LBL does not enforce (through technical measures) a retention schedule for all email. We permit enormous flexibility in how people manage their mail. This includes decisions about how much to keep, where to keep it, and even which service to utilize. These factors mean that our eDiscovery approach will always be multi-faceted.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

6 of 13

Google currently indicates that deleted information is immediately unrecoverable and that all residual copies of data are deleted within a given time period, currently up to 60 days as described in UC Agreement Section 2.2 and their Google Mail Privacy Notice http://mail.google.com/mail/help/privacy.html. While copies may remain in offline backups, moving the management of backups to Google would take the search backup tapes discussion for many discovery actions out of the hands of the Lab in a positive way, allowing for Google to describe the recover- ability and cost of such a search and knowing that the backups are managed on a defined, audited schedule. Recommendation The shift to Google for email does not introduce substantial differences in our current practices or approach to eDiscovery. We will continue to be responsible and accountable for timely delivery of documents in a lawsuit. We would require assistance from Google if records not under our control were required to be produced.

10. Compliance with Breach Laws


Concern Breach reporting laws (SB1386, etc) complicate LBL's use of outsourced information systems. Discussion Email in its present form (Google or LBL provided) is not an appropriate means of storing or transmitting PII, PHI, or other sensitive information that are covered information in breach notification laws. Breach reporting laws do not prevent the use of outsourced systems or outsourced vendors of any persuasion. Most are interpreted to require that the steward of the information (the Lab) remain responsible for compliance with these laws regardless of where the information resides. The Lab must bind contractors to ensure they comply with and assist the Lab with complying with applicable breach disclosure laws. This includes the actual practice of investigating a breach in a timely manner. Recommendation We recommend that terms are included in the UC Agreement that require timely, legally compliant notification of security breaches within 48 hours. This language is not in the newer Agreement. We recommend that any agreement include requirements of timely, legally compliant notification of security breaches. In particular, cost responsibility for breaches and the responsibility to help the Lab investigate any incident are important negotiating points. The Universitys Data Security Appendix should be utilized as a baseline for the negotiations.

11. Compliance with FERPA


Concern The Lab would not be able to fulfill its responsibilities under FERPA. Discussion As a non-degree granting component of the University, FERPA is not directly applicable to Berkeley Lab. In any case though, FERPA is clear that outsourcing and sharing of information for the purposes of conducting University business is permissible within certain circumstances. The current Educational Editionnewer Agreement includes language making Google a school official for the purposes of FERPA (See Google Apps Education Edition Agreement (031809), Section10.1). The UC Agreement includes references to FERPA though not the school official designation (See UC Agreement, Section 7.2). Recommendation We recommend the language in the newer Agreement be reviewed and considered for the UC Agreement.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

7 of 13

12. Google Modification of Terms


Concern Googles has subsidiary terms and policies that are subject to change outside of the Agreement. Discussion The Google UC Agreement references a number of URL Terms, subsidiary terms and policies (e.g. the SLA, Admin and Privacy policies) and Service definitions and other terms of compliance that are not controlled in the same way as the Agreement itself. Google agreed to notify us of changes to these terms, mitigating stealth changes with material adverse impact. In the UC Agreement, this is limited to the Admin Policy (this is the Acceptable Use Policy), in the newer Agreement it is broadened to all applicable terms (See Google Apps Education Edition Agreement (031809), Section 1.3b). This gives the Lab a chance to review URL terms, and to reject them if they represent a material adverse impact to the Lab. Recommendation We recommend the language in the newer Agreement be reviewed and considered for the UC agreement.

13. Google Acceptable Use Policies


Concern Google has different acceptable uses policies than the Lab and may potentially terminate a user for violations. Discussion The UC Agreement asks that the Lab and individual Google users agree to Googles Admin Policy (which is their Acceptable Use Policy) and Privacy Policy. These are similar to those of the Lab but are not 100% the same. The current version of the educational terms of service require Google to notify the Lab of a breach of terms by its users, and for the Lab to take action to cure the breach. Only if the Lab does not take action may Google unilaterally suspend a user, and then only until the breach is cured (See UC Agreement Section 3.1). The newer Agreement has more expansive language, including suspension of offending use if there is an Emergency Security Issue which is further defined as disruption or unauthorized access by a third party (See Google Apps Education Edition Agreement (031809), Section 5). It is noted that Google has additional language that allows for suspension of offending use if there is an Emergency Security Issue which is further defined as disruption or unauthorized access by a third party. We believe a serious issue arising from violation of these terms is unlikely. Recommendation We recommend the language in the newer Agreement be reviewed and considered for the the UC agreement. We recommend that language be negotiated that applies a more restrictive standard perhaps only material violations, or violations that significantly threaten the security or integrity of the vendors system.

14. Monitoring for Google AUP Acceptable Use Policy (AUP) Violations
Concern It has been asserted that the Agreement requires the Lab to monitor for violations of Googles AUP. Discussion The newer current version of the Agreement requires best efforts to ensure its End Users comply with the AUP (See Google Apps Education Edition Agreement (031809), Section 2.1) The language does not appear to require monitoring per se, though there is the potential for disagreement with Google regarding what best efforts entail. The risk that we would disagree with Google on this issue seems small. The UC Agreement does not contain this language. Recommendation We recommend LBL inform users of the Google AUP and to have procedures in place to manage non-compliance.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

8 of 13

15. End User Privacy Issues


Concern Google will not protect end-user privacy as well as the Lab does. Discussion The agreement includes Googles commitment is to protect the confidentiality of the Universitys data (See UC Agreement Section 7 and Google Apps Education Edition Agreement (031809), Section 6). Google indexes end user content for limited and defined purposes such as spam filtering and virus detection and without human interaction (see http://www.google.com/ support/a/bin/answer.py?answer=107810). Google, by contract, does not mine the content of email to serve automated advertising in the UC Agreement it is by status of the End-User, and in the newer Agreement, it must be unless enabled by the customer. (See UC Agreement Section 2.1 and Google Apps Education Edition Agreement (031809), Section 1.6). Googles employees access end- user email without permission of the University only in contractually defined limited circumstances (see http://www.google.com/ support/a/bin/answer.py?answer=106887). Googles privacy protections, including separations of duty, have been certified by audit (see http://www.google.com/support/a/bin/answer.py?answer=138340). Recommendation Google's end user privacy protections are a sufficient baseline for Berkeley Lab staff.

16. Termination of Service and Data Migration


Concern Once Google has our email and other information, it will be difficult to get it back out, resulting in Google having effectively locked us into their services. Discussion The Agreement with Google references conditions that may result in termination, (See UC Agreement Section 15 and Google Apps Education Edition Agreement (031809), Section 2.1) The Agreement includes language that commits Google to return or destroy all other Confidential Information of the other party. The newer Agreement also includes the provision to provide access to and ability to export data for a commercially reasonable period of time at Googles then-current rates for the applicable Service (See Google Apps Education Edition Agreement (031809), Section 11.2). Google has developed and provided means to migrate data out of Google Apps services (see http://www.google.com/support/a/bin/answer.py?hl=en&answer=100458). LBL has experience with the APIs provided by Google to facilitate migration of email (into Gmail). Migration in and out of any software product, whether cloud or locally provided, is difficult and expensive. While we believe the costs to migrate out of Google would be high and there would be loss of metadata and functionality, we don't believe those costs are any higher then they would be for any similar product migration. Recommendation We recommend the language in the newer Agreement be reviewed and considered for the UC Agreement. We recommend that a subsequent Agreement include language requiring Google to support automated institutional transfer of data, since current terms might be interpreted to provide only user-level migrations. LBL should begin the negotiation process for the next contract at least two years before expiration, to allow time for migration if mutually acceptable terms cannot be agreed to.

17. General Security


Concern Google cannot protect our data adequately or better than we can.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

9 of 13

Discussion As anyone who has worked with security issues knows, there is no such thing as secure. An evolving set of threats, vulnerabilities, and activities combine with operational, technical, and administrative controls to provide an ecology of security which will never be 100% resistant to compromise. Indeed, research and education is somewhat unique because the risks of overprotection derive not only from costs but from the potential to damage the open, collaborative character of the academic enterprise. There is no one set of security protocols in place around email systems within the Laboratory, across UC, or across DOE, nor is there one set of agreed upon acceptable risks. Email, in particular, has a number of characteristics that make it a challenging area for security. These include the use of cached reusable credentials, storage on and access from insecure endpoint devices, and unencrypted, low-assurance transfer of information. Google currently operates tens of millions of email accounts. Their systems are subject to constant attack, as well as constant modification and improvement by their engineers. Their data center operations are SAS 70 certified, an auditor-to-auditor certification, which provides some assurance that their basic security and privacy controls are in place and working effectively. Their systems are also in the process of being granted Authority to Operate by the General Services Administration under a Certification and Accreditation at FIPS 199 Low (the level we believe most Lab operations are conducted at). Googles approach to security is outlined in a public whitepaper and a slightly more detailed whitepaper that is available under NDA. However, in many ways, the specifics of their technical controls may be of less interest then how we think about the risks and assurances we expect from email today. Understanding what constitutes the right level of assurance of security from an outsourced vendor is a key decision the Lab must make going forward. Whatever decision is made, it should be consistent with our own expectations for our internal services, whether run by the central IT organization or not. That means that if we expect Google to have strong authentication, encryption of data at rest, and monthly external audits (not that we do), we likely should have the same expectations for our own internal providers. Indeed, very few central email services are subject to rigorous external review or are held to any particular set of recognized standards. This is not to suggest that they are insecure, only that we need to be cognizant of how we compare an outsourced service to an internal one. Fundamentally, Google has agreed to protect our confidential information under the contract. While we cannot give up our responsibility to secure that information, we need to find ways to reasonably cede that direct protection in ways that further the mission of the Lab. We hope the following will provide a baseline for analysis; however, each campus and unit should make their security risk assessments in light of the specifics of their own systems and expectations.
Concern: Response: Our sensitive information The probability is high; we are a constant target for intrusions. is subject to breach The impact is limited, because the vast majority of information at LBL is not sensitive. Email should not be utilized for collections of this kind of information, no matter whom it is provided by. Google is a target for So are we (see above). hackers Google is a target for hackers and will be a larger target as useful private information moves to their services. However, this risk seems well mitigated by the large security staff and security architecture employed by Google and comparable to the risks we already experience with the use of applications provided by companies like Adobe and Microsoft, which

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

10 of 13

Google's security won't be as good as what can be done locally at the Lab General security

Google's security won't be as good as what can be done locally at the Lab Email specifically

Google's security won't be as good as what can be done locally at the Lab Storage of email specifically Security is a problem with Cloud in General, and Google's Implementation

commonly expose our entire institutions to multiple days of unpatched vulnerability. Google's overall performance in security has been far better than other major software providers; however, even if the days of vulnerability were to increase dramatically, they seem to be within our existing acceptable risk-envelope for software security. Specifically, we should consider how days of vulnerability in Google Apps would compare to days of vulnerability in Adobe Reader and Flash, and Microsoft products - two vendors whose software is widely deployed and which represent vectors of significant risk to the Lab. The architecture of SAAS provides inherent security advantages since there is no variation of configuration or dependence across the software, and security issues can theoretically be fixed instantly across Googles systems. As with all outsourcing arrangements, LBL is putting faith in Google's business practices and security practices to ensure the security of its data. This "faith" is grounded in Google's public statements about its security practices, its track record of security to date, its independent certifications, and its need to protect its image by maintaining security. Googles security staff is robust and its resources to protect and adjust to changing threats are enormous. Googles systems are designed to be resilient with an enormous international footprint. LBL currently accepts substantial security risks around email. We currently accept the risk of unencrypted storage of vast quantities of email on end user workstations and mobile devices, as do the vast majority of our peer institutions. Of course, email itself is an unencrypted form of communication where emails typically travel across multiple servers and over a largely unknown and variable path. When you consider the risk envelope associated with this, existing confidentiality protections for email are quite low. This helps level set the confidentiality risk. While the loss of a device containing unencrypted Lab email is considered an acceptable risk, to the extent that users replace local storage of information with storage on Google's systems, we believe the overall security of that information will increase. This is because end user devices are vulnerable to loss and theft, which prevents forensic investigation. Google's systems are functionally not vulnerable to this issue when the web interface is utilized. The fundamental tradeoff we see is better security performance from Google's realtime (SAAS) approach as weighed against far less forensic information accessible to the Lab for reconstructing an incident. Key advantages are Google's teams of 24x7 engineers and security staff, and realtime scanning of phishing/virus instead of one- time inbound scanning in our current model. Emergent security improvements from previews of thick-client documents in the browser are also possible. Users who do not use a thick-client mail solution should represent a lower risk going forward, though there may be emergent concerns about increased use of the web-browser model from untrusted systems.

The Agreement includes language that commits Google facilities to reasonable security standards for facilities to protect Customer data (See UC Agreement Section 2.2) and systems and procedures that will ensure security of data including confidentiality and integrity and protection against unauthorized access (See Google Apps Education Edition Agreement (031809), Section 1.2). The newer Agreement includes additional language that commits to systems and procedures that will ensure security of data including confidentiality and integrity and protection against unauthorized access.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

11 of 13

Googles security approach benefits from its SAAS model and its control over its own infrastructure. In addition, the scale of their operations allows more attention to application security issues, as well as the use of a defined security lifecycle (see http://www.google.com/support/a/bin/answer.py?answer=107823 and Comprehensive review of security and vulnerability protections for Google Apps, Google whitepaper February 2007 ). This must be weighed against reduced visibility into the specifics of the operations and vulnerabilities of the systems compared to when they are operated locally. Fundamentally, a yes/no on Google security is not possible. However, the real-time nature of Google's protections, combined with its architectural approach, would appear to slightly exceed the lost visibility into intrusions and anomalous behavior that result from sourcing from Google. Recommendation Develop new tools to detect use of credentials in suspicious ways through the IDM system. Continue to monitor Google APIs and data feeds to see areas where improved visibility is possible.

18. Phishing and Credential Protection


Concern Google cannot protect users from phishing and credential theft as well as Berkeley Lab can. Discussion Google and LBL both implement numerous protections against phishing and credential theft. The method of implementing Google Apps greatly impacts LBL's ability to take action in response to a targeted phishing attack. At this time, we continue to route email inbound and outbound through our own servers, providing identical spam/virus/policy protection as we did under our previous email service. We expect to investigate Google's GMS offering to compare it to our existing mail handling services in the CY2010 timeframe. In addition to responding to phishing, utilizing outsourced services has the potential to reduce visibility into credential abuse. If Google Apps is linked to the labs credential provider, visibility when entering through the web interface is preserved. However, access via non-web based protocols is not currently logged to Google Apps administrators in a highly accessible way. A mitigation is that Google provides the end user with detailed information, located at the bottom of the Gmail page, about recent uses of their credential. This actually has the potential to be a better detector of misuse then institutional monitoring. Campuses should weigh the extent to which they conduct broadform monitoring of credential use today against the potential for reduced visibility under Google Apps. In addition, Google conducts multiple kinds of detection to locate compromised accounts; however, the lack of detail about their approach makes it difficult to assess any further reduced risk. Finally, Berkeley Lab has the ability to extract particularly dangerous emails from inboxes after delivery. At this time, we do not appear to have the same functionality within Google; however, we believe it will be possible with labeling APIs in the future. Recommendation Berkeley Lab will evaluate these architectures as it evaluates its mail handling architecture.

19. Availability and Service Levels


Concern The Lab would become dependent on Googles reliability and service level. In addition, remedies for lack of performance are limited because the service is provided for free. Discussion We believe that Google's historical availability and resiliency from a regional disaster are sufficient to justify this move. While email is very important to Berkeley Lab employees, short-term outages are more a source of frustration then actual damage to mission. Google's technical

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

12 of 13

architecture makes it likely that the service will survive a major regional disaster intact (an earthquake for example), something for which we have very low resiliency to today. Recommendation Monitor Google's performance. No other action required.

20. Data Loss


Concern Google doesn't keep backups, we wouldn't have backups. If data were lost, we would have no recourse at all. Discussion This concern represents a fundamental misunderstanding of how Google's services operate. While it is the case that Google doesn't keep backups in the traditional sense, they do stage multiple copies of data for resiliency in geographically diverse regions. Further, they operate so that in most cases, failovers happen seamlessly meaning there is no time delay to provide access to data. Of course, none of this positively ensures that data would always and everywhere be accessible, but neither does our current process of physical backup tape management. Further, it is likely that backups would result in hours or days of data loss in addition to offline time after a major incident, whereas Google's architecture at least has the potential to avoid this situation. Systems exist to provide for backups of all Google services locally. These include Gmail Backup, IMAP shadowing, Docs downloads, Calendar exports, and Sites exports. While there is no significant contractual recourse for lost data in the contract, the embarrassment to Google of losing customer data would be difficult to overestimate. It is highly likely that a major loss of a prominent customer's data would end their efforts in this space. As such, we believe they are well incentivized to keep our data safe. Recommendation Inform users of the options they have for local backup if they want to take an additional precaution; however, we believe Google's existing service level is appropriate.

21. Recent News about China


Concern Doesn't the recent news about Google and China basically prove that all this cloud stuff is totally insecure? Discussion No. First off, we need to apply an appropriate balancing test. Berkeley Lab requires appropriately secure systems, not perfectly secure ones. Our existing systems are not perfectly secure, nor are Google's. We are clearly not immune from a well-resourced attacker attempting to gain access to our systems, and this is an explicitly accepted risk in our Risk Assessments. DOE history suggests that sites that spend far more on security and have far more restrictive postures are not immune either. At the same time, Google is an enormous target, has substantial attack data, and has the ability to provide resources to the lifecycle security of its applications that far exceed ours (see General Security). That said; a major issue in the Google China news has been stolen credentials. We are clearly not immune to those either, and we believe that Google is in a better position to observe suspicious credential usage then we are. Further, we would continue to have transparency into the web- enabled services provided by Google for purposes of detecting compromised accounts (see Phishing and Credential Protection). We would thus build on both Google and LBL's detection capabilities in a Google Apps environment. Recommendation No action required.

Draft released to public. Please send comments or questions to itpolicy@lbl.gov

13 of 13

You might also like