Greg Bell, Adam Stone, Denise Sumikawa For Berkeley Site Ofce 01.21.

10
Thursday, January 21, 2010

what is cloud computing? IT initiatives in this space a few non-IT initiatives general approach of the IT Division

Thursday, January 21, 2010

useful denition from Urs Hoelzle (SVP @ Google) cloud implies two kinds of computing systems
tiny: smart phones, net/notebooks, thin clients, tablets

huge: warehouse-scale computers: ~$500M, ~50MW

at either scale, systems are optimized for efciency - battery constraints - operating expenses @ 50MW BERKELEY LAB
Thursday, January 21, 2010

Using Cloud Services to Document Cloud Hype

BERKELEY LAB
Thursday, January 21, 2010

A Tale of Two Clouds

BERKELEY LAB
Thursday, January 21, 2010

The Storm Cloud Will Bring...

privacy concerns security breaches data and service lock-in complete dependence on the network lower quality of service (stubborn c) lay-offs corporate turmoil higher prices, eventually
BERKELEY LAB
Thursday, January 21, 2010

The Fluffy Cloud Will Bring...

much better IT services much faster innovation greater resiliency renewed focus on important problems more productive collaboration reduced travel end to burden of self-managed PC lower prices over time profound but appropriate disruption
BERKELEY LAB
Thursday, January 21, 2010

The Nicholas Carr Thesis

What happened to the generation of [electrical] power a century ago is now happening to the processing of information. Private computer systems... are being supplanted by services provided over a common grid, the Internet... Computing is turning into a utility. - Nicholas Carr, The Big Switch BERKELEY LAB
Thursday, January 21, 2010

another industrial analogy

US Car Manufacturers 200+ 17 3

Year 1920 1940 2010

BERKELEY LAB
Thursday, January 21, 2010

Fords River Rouge Plant

BERKELEY LAB 100k Workers

Thursday, January 21, 2010

ITs River Rouge

220 containers, 550k sq ft, 440k servers 30 employees

Thursday, January 21, 2010

BERKELEY LAB

More Complete Description of Cloud Computing

IT sourcing model (not a technology) exploits virtualization, fast networks, webservice standards and APIs, enormous data centers 5 essential characteristics per NIST self-service provisioning services delivered over network multi-tenancy (resource sharing) scales up/down rapidly (elasticity) granular metering, micro-payments BERKELEY LAB
Thursday, January 21, 2010

Cloud Services Layers, From Bottom Up

Infrastructure as a Service [IaaS] customer rents low-level resources (cycles, storage) sysadmin, integration, scaling tasks remain the most exible but labor-intensive option quick demo (nagios on EC2) Platform as a Service [PaaS] customer rents an application platform customer provides code no sysadmin tasks Software as a Service [SaaS] customer rents an app customer provides conguration + data
Thursday, January 21, 2010

BERKELEY LAB

Are Customers Like Us Using Cloud Services?

cautious adoption in research, education, .gov: - many institutions studying cloud service - Federal CIO/OMB/GSA cmtes - early adopters include Genentech, city of LA, District of Columbia, ASU, UCD, USC, NOAA

strong support from the Feds: - Federal CIO Vivek Kundra promoting cloud very aggressively - take a look at the non-cartoon portion of http://apps.gov - vendors rening services to entice .gov customers - Google federal cloud + FISMA compliance in 2010 - another vendor offering separate .gov hosting facility (cloudish)
Thursday, January 21, 2010

BERKELEY LAB

There is obvious FUD around clouds on both sides. Both sides have economic interests.

BERKELEY LAB
Thursday, January 21, 2010

LBL is well-positioned to be a user b/c we:

dont do sensitive work are good with computers (earnest early adopters) use a lot of diverse IT not already in bed with MS are multi-platform by nature tend not to just do what vendors and consultants
tell us to without thinking it through BERKELEY LAB
Thursday, January 21, 2010

Cloud Projects Within the IT Division

BERKELEY LAB
Thursday, January 21, 2010

A Few Cloud Projects Outside IT

scientic computing

benchmarking commercial services Magellan project

$32M ARRA-funded collaboration (LBNL / ANL / ESnet) to explore feasibility of science cloud, with 100GE network exploring performance, service models, architectures, costs

science pilots underway (all involving CRD)

BLAST on Amazon Hadoop climate analysis on MS Azure Supernova Factory on Amazon EC2

BERKELEY LAB

Thursday, January 21, 2010

A Few Cloud Projects Outside IT

Home Energy Saver empowers home owners to reduce their energy use customer-facing app plus licensed web service hardware currently in Bldg 50A EETD now migrating to Amazon Web Services (EC2 / S3)

LEEP HES for wet labs implemented at nearly the same time on Google AppEngine, Appshosting, and conventionally (terrestrially) in J2EE

BERKELEY LAB
Thursday, January 21, 2010

To Summarize
Beware of generalizations about cloud computing! (the business models and services differ widely) having said that... its likely that many IT functions now performed locally will be cloud-sourced in 3-5 years

this is good for science & good for the planet, but there will be trade-offs general posture of IT Division proceed optimistically but pragmatically, seeking data understand range of services, policy issues gain competence in cloud-sourcing, conduct pilots use cloud services where appropriate

BERKELEY LAB
Thursday, January 21, 2010

If you believe slides 1-20, then... We need to get good at managing privacy and security in the cloud. We need to move judiciously, but quickly to exploit economic/strategic advantage for LBL and DOE.

BERKELEY LAB
Thursday, January 21, 2010

Google Apps: What

Suite of integrated services, connected by common management interface. Google Apps is not consumer gmail. Cloud. No change to policy: Employee and Line Mgt determine where email goes. BERKELEY LAB
Thursday, January 21, 2010

Google Apps: What (2)

Production Service: Docs, Sites, Start Pilot Phase 1: Mail Other Services: Calendar,Talk (chat), Moderator, Code Reviewer, Groups, Short Links,Video.

BERKELEY LAB
Thursday, January 21, 2010

Google Apps: Why

1. Powerful collaboration suite 2. Gain advantages of Google scale and development lifecycle (new features every week) 3. Refocus our resources and people on sciencedriven projects, not commodity apps (specialize where we are trumped by scale).

BERKELEY LAB
Thursday, January 21, 2010

For the purposes of this talk, we will focus mostly on Mail, with occasional forays into other apps.

BERKELEY LAB
Thursday, January 21, 2010

Mail: Architecture
Scope: No change to mail handling architecture at this time. Further study required. berkeley -> lbl -> google -> lbl -> berkeley
A/V A/S Policy and other A/V A/S Policy

Mail Handling is where we do 99% of email security. BERKELEY LAB

Thursday, January 21, 2010

Topline Risk Analysis

Using gmail increases security and privacy risks in some areas and decreases them in others. Its use is, in LBL/UCs assessment, within the acceptable risk-envelope for LBL Research and Operations, probably a marginal net-decrease of risk. To analyze, we need to understand and be honest about current risks, acceptable risks, and google risks - and discuss mitigations. (heuristics work against doing this well) BERKELEY LAB
Thursday, January 21, 2010

Security
The status quo (our approach): We permit LBL users to forward their email anywhere (this is a reection of our risk-tolerance). We prohibit sensitive data and many kinds of elevated sensitivity research. We manage email risks mostly through ltering. BERKELEY LAB
Thursday, January 21, 2010

Contract
The contract b/w the University and Google, as well as the TOS sets the boundaries of the relationship. To some extent, we are required to trust that Google is living up to its end of its commitments. Trust is fed by audits, reviews, and liability. The current UC-contract is being renegotiated to incorporate additional terms. BERKELEY LAB
Thursday, January 21, 2010

UC points of negotiation examples...

Breach reporting. Breach liability. Cooperation with investigations. Agent for covert lawful requests. Subsidiary terms. HIPAA BAA status. Appendix DS BERKELEY LAB
Thursday, January 21, 2010

Easy Things

easy things: Intellectual Property Lock-In Availability

BERKELEY LAB
Thursday, January 21, 2010

Lets cover the easy things rst.

Intellectual Property: The contract clearly states that we own all the information we put into the service. Just as Google owns the IP of the service itself. Issues with IP primarily stem from new capabilities of the tools and their accidental use. These issues are functionally identical to the issues we face today. There are interesting edge issues around ownership of third party content placed into the system. We have these issues today too... Bottom Line: Non Issue.
Thursday, January 21, 2010

BERKELEY LAB

Easy Things: Lock In

Wont google own us? Complex question, detailed weighing required. Contractually, they must provide us with ways to migrate out and they have. We believe cost to migrate out to be similar to cost to migrate out of other systems (though there would be losses of integration, etc). Those costs are serious. (the complex equation: are Googles costs fundamentally lower? will goog raise the prices to within $1 of our decision-curve every year (like MS or Oracle?) BERKELEY LAB

Thursday, January 21, 2010

Lock In: Our Analysis

No worse then current situation - costs to migrate are high no matter where the data sits. No worse then most companies in the world who are locked into Exchange or Oracle. Worth the risk. Increase in functionality and t for our environment is worth the lock in (compare to MS). BERKELEY LAB
Thursday, January 21, 2010

Easy things: Availability

Temporary Outage: Googles numbers are similar to our SLA, but we perform > our SLA. Remedy for downtime is more free days. Real risk for Google is bad press (serious) (plus we mostly outsource reputational risk). Architectural redundancy should permit service after local/regional disaster (unlike current architecture). Power issues alone make this decision easy. BERKELEY LAB
Thursday, January 21, 2010

Easy things: availability continued

Longer Term Outage: What if Google.... went out of business (we should have warning) decided to get out of this business (reputational risk) Compensating Control: Monitor Googles health. BERKELEY LAB
Thursday, January 21, 2010

Harder Things: Security

Understand the envelope. Understand the tradeoffs. Is Google Secure? (this question makes no sense in a vacuum).

BERKELEY LAB
Thursday, January 21, 2010

Security

Status Quo: Risks Two kinds: to user email & to the system User: User accounts use reusable credentials and their pattern of use leads to relatively high likelihood of compromise. Local storage of email = high risk of mass loss of individual users email. This is acceptable in our current risk environment. System: LBL systems are well protected, enforce least functionality and separation, non-reusable auth, and extensive logging. No history of compromise (but were only talking about central systems). BERKELEY LAB

Thursday, January 21, 2010

At the user level...

Improvements: On-access virus-scanning (in addition to ondelivery) ++ Preview for ofce docs and pdf may reduce vulnerabilities (if utilized). +++++ Working without local storage of email becomes possible - if you decide to do it. + User-controllable logout from any workstation and user-accessible logging (+++++) BERKELEY LAB
Thursday, January 21, 2010

Security Issues at the user level.

Lack of logging / Lack of our experience with it. -Requirement of cooperation for forensics. Google = large target New features may be poorly understood (ofine, delegation, etc).

BERKELEY LAB
Thursday, January 21, 2010

Security @ the system layer.

At the high level: Google & LBL share something in common: no trust of endpoints. Googles track-records is very good (compare to Adobe/MS) There is limited patch delay from release. Enormous team of security people. Well regarded lifecycle integration of security (an engineering approach to security). BERKELEY LAB
Thursday, January 21, 2010

Information Storage: Multi-tenant distributed on GFS. Data is chunked, difcult to piece together. Certicates for access, detailed Separation of Roles across apps, privacy protections built in.

BERKELEY LAB
Thursday, January 21, 2010

At the application layer: High visibility into normal performance of applications. Monitoring and Boundary Protection Instant response is possible (though not assured).

BERKELEY LAB
Thursday, January 21, 2010

Two major certications.

FISMA Low (+) SAS 70

BERKELEY LAB
Thursday, January 21, 2010

Security Documents address: Access Control Physical Control Logical Security Boundary Defense, etc...

BERKELEY LAB
Thursday, January 21, 2010

Privacy
Google reads your email (their computers do actually, which really is different) ... but not the same way they do when you are a gmail customer. Google employees dont read your email (by law, by contract, audited), except under dened situations.

BERKELEY LAB
Thursday, January 21, 2010

Privacy: Foreign Countries

Google stores redundant copies of data in geographically disperse regions. Google does not make claims about where (though not China). There are novel aspects of this relationship, but the impacts seem modest. Scenario 1, physical access Scenario 2, logical access BERKELEY LAB
Thursday, January 21, 2010

Privacy: Foreign Employees

LBL does not screen access to systems on the basis of nationality. LBL employees store email in many places today where nationality is not considered. LBL conducts no sensitive research. UC/LBL policy prohibits discrimination on the basis of nationality or citizenship. FVA requirements are in the process of being radically reduced, maybe eliminated. BERKELEY LAB
Thursday, January 21, 2010

Legal Issues: Discovery

Contract requires Google to deliver legal requests to us. We can then ask for help if the information we have isnt enough. However, there are cases where Google might be forced to give up information without our knowledge. eDiscovery is still our responsibility, some changes. BERKELEY LAB
Thursday, January 21, 2010

Other risks?
Emergent properties of whole systems. What if Google becomes MS circa 2004? Does Google become Toyota or Oracle? What happens if there is a .gov incident? What about the Labs/Facilities that are much more strict? BERKELEY LAB
Thursday, January 21, 2010

What does climategate mean to us? What does Chinagate mean to us?

BERKELEY LAB
Thursday, January 21, 2010

Top Five Misconceptions

1. Google owns your data. 2. Google never deletes anything. 3. Google mines your email to serve you ads. 4. Googles international presence means your data is being used by the elbonians. 5. Not being able to touch your data means its at more risk. BERKELEY LAB
Thursday, January 21, 2010

Its not that Google is no risk, its that its within our acceptable risk envelope. Its probably a wash (from what we see now)* * Security should be based on what we see now LBL has had much success with this model. This isnt a decision for now and forever.

BERKELEY LAB
Thursday, January 21, 2010