Professional Documents
Culture Documents
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.
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.
2 of 13
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.
3 of 13
Recommendation Ensure CSPP and Common Controls document are modified to reflect current sourcing strategies as required.
4 of 13
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.
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.
7 of 13
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.
8 of 13
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
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.
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.
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.
13 of 13