Copyright2010

1

Roger Clarke, Xamax Consultancy, Canberra Visiting Professor in Computer Science, ANU

and in Cyberspace Law & Policy, UNSW

23rd Bled eConferenceSlovenia – 22 June 2010

http://www.rogerclarke.com/II/CCBR {.html,.ppt}

Computing Clouds on the Horizon?Benefits and Risks from the User's

Perspective

Copyright2010

2

Cloud Computing• son of Eric Schmidt, b. 2006• retro-fitted to SalesForce, 2006• adopted for IBM and Amazon, 2007• published in the academic

literature:• rarely in 2008• occasionally in 2009• frequently in 2010

• ...• d. ?

Copyright2010

3

InternetAccessProvider

PersonalWork-and-Play

Stations

RouterCorporateWorkstationsFirewallHost and

Servers

Copyright2010

4

InternetAccessProvider

PersonalWork-and-Play

Stations

RouterCorporateWorkstationsFirewallHost and

Servers

Copyright2010

5

http://www.lostinthemagicforest.com/blog/wp-content/...

...uploads/2007/10/gartner2007.jpg

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Copyright2010

6

http://adverlab.blogspot.com/2008/08/...

...media-history-through-gartner-hype.html

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Copyright2010

7The Gartner Hype-Cycle – 2009

http://www.gartner.com/it/page.jsp?id=1124212

Copyright2010

8

Research Method• An exegetic paper, ‘armchair analysis’• Literature reviews

• Academic• To November 2009:

• Google Scholar disclosed a few dozen articles with citations, all of which were evaluated

• the AIS eLibrary disclosed 0 articles• During December 2009:

• 4 further conference papers appeared• Very little attention to the user orgn perspective

• Commercial and Popular• Application of prior bodies of theory and practice

Copyright2010

9

Predecessor Terms

• Computing as a utility / 'computer service bureaux' / 'data centres'– 1960s, 1970s

• Application Service Providers (ASPs)– 1980s

• working from home / tele-work – 1980s

• working on the move / 'road warrior'– 1990s

• docking portables to corporate networks

• portable-to-desktop synchronisation• Internet Service Providers (ISPs)

– late 1980s• Web Services – 2000• Service-Oriented Architecture (SOA)

– early-to-mid-2000s

Copyright2010

10

Predecessor Terms

• Computing as a utility / 'computer service bureaux' / 'data centres'– 1960s, 1970s

• Application Service Providers (ASPs)– 1980s

• working from home / tele-work – 1980s

• working on the move / 'road warrior'– 1990s

• docking portables to corporate networks

• portable-to-desktop synchronisation• Internet Service Providers (ISPs)

– late 1980s• Web Services – 2000• Service-Oriented Architecture (SOA)

– early-to-mid-2000s

• Software as a Service (SAAS) – late 1990s, e.g. Salesforce

• Cluster Computing – inter-connected stand-alone computers are managed as a single integrated computing resource

• Grid Computing – computational resources are assigned dynamically

• Peer-to-Peer (P2P) architectures • Server-Virtualisation• Infrastructure as a Service (IaaS)

– 2006• Platform as a Service (PaaS)

– 2006• Anything as a Service *aaS / AaaS

Related Concepts

Copyright2010

11

Cloud Computing Definitions• "a large-scale distributed computing paradigm that is driven by

economies of scale, in which a pool of abstracted, virtualized, dynamically-scalable, managed computing power, storage, platforms, and services are delivered on demand to external customers over the Internet" (Foster et al. 2008, at the Grid Computing Environments Workshop)

• five 'essential characteristics' (NIST, October 2009):• on-demand self-service (i.e. automated response by servers

to direct requests by clients)• broad network access (i.e. from anywhere, using any device)• resource pooling (i.e. the provider allocates resources

according to demand, rather than assigning resources to particular clients)

• rapid elasticity (i.e. resources are scalable according to demand)

• measured service (i.e. resource usage is metered)

Copyright2010

12

The User Organisation PerspectiveA Working Definition

A service that satisfies all of the following conditions:1. It is delivered over a telecommunications network2. Users place reliance on the service for data access

and/or data processing3. The data is under the legal control of the user4. Some of the resources on which the service

depends are virtualised, i.e. the user has no technical need to be aware which server running on which host is delivering the service, nor where the hosting device is located

5. The service is acquired under a relatively flexible contractual arrangement, at least re the quantum used

Copyright2010

13

Cloud Computing is a Form of Outsourcing

How is it different from earlier forms?

• Scalability ('there when it's needed)• Flexible Contractual Arrangements ('pay per

use')• Opaqueness ('let someone else worry about

details')• which means less user control:

• of the application, through commoditisation• of service levels, through SLA dependence

(assuming there's an SLA, and it's negotiable)• of host location, through resource-virtualisation

Copyright2010

14

Sample Architectures

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

CSA (2009) 'Security Guidance for Critical Areas of Focus in Cloud Computing' Cloud Security Alliance, April 2009

Youseff L., Butrico M. & Da Silva D. (2008) 'Toward a Unified Ontology of Cloud Computing' Proc. Grid Computing Environments Workshop, 2008

Copyright2010

15

Buyya R., Yeo C.S., Venugopal S., Broberg J. & Brandic I. (2009) 'Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility' Future Generation Computer Systems 25 (January 2009) 599-616

Fig. 3 High-level market-oriented Cloud architecture

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Copyright2010

16

CC Architecture – The User Organisation Perspective

Organisation

Client App

UtilitySoftware

esp.Web-

Browsers

Platform– System

S’ware

UserDevice

Broker

CloudManager

Client-SideInfrastructure

CloudInfrastructure

IntermediatingInfrastructure

Copyright2010

17

CC's Potential Benefits• Enhanced Service Accessibility

• Access to Services that are otherwise unavailable

• Access to Services from multiple desktop devices

• Access to Services from scaled-down devices• Access to Services from multiple device-types

• Other Technical Benefits• Professionalised backup and recovery• Scalability• Collaboration convenience• Copyright convenience

• Financial Benefits• Lower Investment / up-front cost• Lower Operational Costs• Lower IT Staff Costs

Copyright2010

18

Downsides – The User Perspective

• Operational Disbenefits and RisksDependability on a day-to-day basis

• Contingent RisksLow likelihood / Potentially highly significant

• Security RisksSecurity in the broad

• Business Disbenefits and RisksBeyond the merely technical

Copyright2010

19

Operational Disbenefits and RisksAS ISO/IEC 2000-2007, ITIL, Avizienis et al. (2004)

• Fit – to users' needs, and customisability

• Reliability – continuity of operation• Availability – hosts/server/database

readiness/reachability

• Accessibility – network readiness

• Robustness – frequency of un/planned unavailability (97% uptime = 5 hrs/wk offline)

• Resilience – speed of resumption after outages

• Recoverability – service readiness after resumption

• Integrity – sustained correctness of the service, and the data

• Maintainability – fit, reliability, integrity after bug-fixes, mods

Copyright2010

20

Contingent RisksISO/IEC 24762:2008 (Disaster Recovery Services)

BS 25999:2006/07 and and BS 25777:2008 (Business continuity)

• Major Service Interruptions• Service Survival – supplier collapse or withdrawal

Safeguards include software escrow; escrow inspection; proven recovery procedures; rights that are proof against actions by receivers

• Data Survival – data backup/mirroring and accessibility

• Compatibility – software, versions, protocols, data formats

• FlexibilityCustomisationForward-compatibility (to migrate to new levels)Backward compatibility (to protect legacy systems)Lateral compatibility (to enable escape)

Copyright2010

21

Security RisksISO/IEC 27002:2005, Hogben (2009)

• Service Security Environmental, second-party and third-party threats to any aspect of reliability or integrity

• Data SecurityEnvironmental, second-party and third-party threats to content, both in remote storage and in transit

• Authentication and AuthorisationHow to provide clients with convenient access to data and processes in the cloud, while denying access to imposters?

• Susceptibility to DDOSMultiple, separate servers; but choke-points will exist

Copyright2010

22

Business Disbenefits and Risks• Acquisition

Lack of information, non-negotiability of terms of contract and SLA

• Ongoing UsageLoss of corporate knowledge about apps, IT services, costs to deliverInherent lock-in effect, because of high switching costsHigh-volume data transfers (large datasets, replication/synch'n)

• Service Levels to the Organisation's Customers

• Legal Compliance – **Data protection law, law of confidence, financial services regulations, evidence discovery law. Company Directors' obligations re asset protection, due diligence, business continuity, risk management

• Privacy Breach – ** Content Access, Use, Retention,Second-Party (service-provider abuse), Third-Party ('data breach','unauthorised disclosure'), Storage in Data Havens (India, Arkansas)

Copyright2010

23

Some Risk Management Strategies

• Risk Assessmentwhich depends on transparent information

• Contract Terms• Service Level Agreement (SLA)• Multi-Sourcing

• Parallel in-house service• Several compatible

suppliers

Copyright2010

24

ITILv3 SLA Checklist – Edited Down!1. Service name

2. Clearance information (with location and date)

1. Service Level Manager

2. Customer

3. Contract duration

1. Start and end dates

2. Rules regarding termination of the agreement

4. Description/ desired customer outcome

1. Business justification

2. Business processes/ activities oncust side supported by the service

3. Desired outcome in terms of utility

4. Desired outcome in terms of warranty

5. Service and asset criticality

1. Identification of business-critical assets connected with the service

1. Vital Business Functions (VBFs) supported by the service

2. Other critical assets used within the service

2. Estimation of the business impact caused by a loss of service or assets

6. Reference to further contracts which also apply (e.g. SLA)

7. Service times

1. Hours when the service is available

2. Exceptions (e.g. weekends, public holidays)

3. Maintenance slots

8. Required types and levels of support

1. On-site support

1. Area/ locations

2. Types of users

3. Types of infrastructure to be supported

4. Reaction and resolution times

2. Remote support

1. Area/ locations

2. Types of users (user groups granted access to the service)

3. Types of infrastructure to be supported

4. Reaction and resolution times

9. Service level requirements/ targets 1. Availability targets and commitments 1. Conditions under which the service is considered to be unavailable 2. Availability targets 3. Reliability targets (usually defined as MTBF or MTBSI ) 4. Maintainability targets (usually defined as MTRS) 5. Downtimes for maintenance 6. Restrictions on maintenance 7. Procedures for announcing interruptions to the service 8. Requirements regarding availability reporting 2. Capacity/ performance targets and commitments 1. Required capacity (lower/upper limit) for the service, e.g. 1. Numbers and types of transactions 2. Numbers and types of users 3. Business cycles (daily, weekly) and seasonal variations 2. Response times from applications 3. Requirements for scalability 4. Requirements regarding capacity and performance reporting 3. Service Continuity commitments 1. Time within which a defined level of service must be re-established 2. Time within which normal service levels must be restored 10. Mandated technical standards and spec of the technical service interface11. Responsibilities 1. Duties of the service provider 2. Duties of the customer (contract partner for the service) 3. Responsibilities of service users (e.g. with respect to IT security) 4. IT Security aspects to be observed when using the service 12. Costs and pricing 1. Cost for the service provision 2. Rules for penalties/ charge backs 13. Change history14. List of annexes

http://wiki.en.it-processmaps.com/index.php/Checklist_SLA_OLA_UC

Copyright2010

25

User RequirementsEssential Features

• Assured Data Integrity• Assured Service Integrity• Assured Compliance

with legal requirements within jurisdictions to which the user organisation is subject

• Warranties and indemnities in the contract, terms of service and SLA (if any)

• But who audits and certifies?

Copyright2010

26

Categories of Use-Profile• UP1: CC is completely inappropriate – business-

critical apps• 'mission-critical systems'• systems embodying the organisation's 'core

competencies'• applications whose failure or extended

malperformance would threaten the organisation's health or survival

Copyright2010

27

Categories of Use-Profile• UP1: CC is completely inappropriate

• 'mission-critical systems'• systems embodying the organisation's 'core

competencies'• applications whose failure or extended malperformance

would threaten the organisation's health or survival• UP2: CC is very well-suited

Uses of computing that are highly price-sensitive, and adjuncts to analysis and decision-making, not essential operationsTrade off loss of control, uncertain reliability, contingent risks against cost-advantages, convenience, scalability, etc.

Copyright2010

28

Categories of Use-Profile• UP1: CC is completely inappropriate

• 'mission-critical systems'• systems embodying the organisation's 'core competencies'• applications whose failure or extended malperformance

would threaten the organisation's health or survival• UP2: CC is very well-suited

Uses of computing that are highly price-sensitive, and adjuncts to analysis and decision-making, not essential operationsTrade off loss of control, uncertain reliability, contingent risks against cost-advantages, convenience, scalability, etc.

• UP3: CC is applicable depending ...• can the risks be adequately understood and managed?• trade-offs between potential benefits vs. uncontrollable risks

Copyright2010

29

Implications for Cloud Computing Architectures

1. CCAs must be comprehensive, encompassing not only the server side, but also the client side and intermediating functions

2. Security Risk Assessments and Solutions must be end-to-end rather than limited to the server side

3. CCA designers must address the risks arising from vulnerable user devices and vulnerable clients

4. Client authentication must be achieved through components, APIs, and externally-managed identities (Shibboleth, OpenID)

5. Jurisdictional Locations of Hosts must be controlled6. These all depend on CCAs including specs and implementation

of multiple special-purpose components and features7. Privacy management must go beyond 'privacy through policy'

and 'privacy by design' to 'Privacy through Architecture'

Copyright2010

30

User Requirements for Cloud Computing Architecture

AGENDA• Precursors / Related

Concepts• A Working Definition• An Architectural Framework• User Benefits• Disbenefits and Risks

• Operational• Contingent• Security• Business

• Implications

Copyright2010

31

Conclusion

• "Past efforts at utility computing failed, and we note that in each case one or two ... critical characteristics were missing" (Armbrust et al. 2008, p. 5 – UC Berekeley)

• CC may be just another marketing buzz-phrase that leaves corporate wreckage in its wake

• CC service-providers need to invest a great deal in many aspects of architecture, infrastructure, applications, and terms of contract and SLA

Copyright2010

32

Roger Clarke, Xamax Consultancy, Canberra Visiting Professor in Computer Science, ANU

and in Cyberspace Law & Policy, UNSW

23rd Bled eConferenceSlovenia – 22 June 2010

http://www.rogerclarke.com/II/CCBR {.html,.ppt}

Computing Clouds on the Horizon?Benefits and Risks from the User's

Perspective