Google  Apps  @  LBL  -­‐  Considerations  and   Risk  Analysis  

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

This  paper  identifies  a  number  of  issues  related  to  the  use  of  Google’s  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  

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  

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  

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   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  

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  company’s  information  or  a  service  provider’s  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  Google’s  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  

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  individual’s  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  Google’s  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  

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  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   University’s  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  

7  of  13  

12.  Google  Modification  of  Terms  
Concern  Google’s  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  Google’s   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  vendor’s  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   Google’s  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  

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  Google’s  commitment  is  to  protect  the  confidentiality  of  the   University’s  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   support/a/bin/  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).  Google’s  employees  access  end-­‐ user  email  without  permission  of  the  University  only  in  contractually  defined  limited  circumstances   (see  support/a/bin/  Google’s  privacy   protections,  including  separations  of  duty,  have  been  certified  by  audit  (see   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  Google’s  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  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  

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).   Google’s  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  

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  Google’s  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.   • Google’s  security  staff  is  robust  and  its  resources  to  protect  and  adjust  to  changing   threats  are  enormous.   • Google’s  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  

11  of  13  

Google’s  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  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  Google’s  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  

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  

13  of  13  

Sign up to vote on this title
UsefulNot useful