1. Copyright 2010 1 Roger Clarke, Xamax Consultancy, Canberra Visiting Professor in Computer Science, ANU and in Cyberspace Law & Policy, UNSW Computer Science Colloquium Series ANU SOCS – 28 May 2010 http://www.rogerclarke.com/II/CCSA {.html,.ppt} User Requirements for Cloud Computing Architecture

2. Copyright 2010 2 The Gartner Hype-Cycle for Emerging Technologies "... a snapshot of the relative maturity of technologies... "They highlight overhyped areas against those that are high impact, estimate how long they will take to reach maturity, and help organizations decide when to adopt"

3. Copyright 2010 3 http://adverlab.blogspot.com/2008/08/......media-history-through-gartner-hype.html

4. Copyright 2010 4 http://www.lostinthemagicforest.com/blog/wp-content/......uploads/2007/10/gartner2007.jpg

5. Copyright 2010 5 http://adverlab.blogspot.com/2008/08/......media-history-through-gartner-hype.html

6. Copyright 2010 6 The Gartner Hype-Cycle – 2009 http://www.gartner.com/it/page.jsp?id=1124212

7. Copyright 2010 7 Gartner Hype Cycle for Cloud Computing July 2009 – $US 1,995 (53 pp.) On the Rise Cloud Services Governance Cloud-Driven Prof'l IT Services, Solutions Cloud Computing/SaaS Integration Cloudbursting/Overdraft Cloud Service Management Tools Tera-architectures Virtual Private Cloud Computing Application Platform as a Service Cloud Computing for the Enterprise DBMS in the Cloud Private Cloud Computing Business Process Utility Hybrid Cloud Computing Cloud Application Development Tools Cloud-Based E-Mail Services Cloud-Enabled BPM Platforms Cloud Security Concerns Cloud Storage At the Peak Elasticity Enterprise Portals as a Service Cloud/Web Platforms Compute Infrastructure Services 'In the Cloud' Security Services Cloud Computing Public Cloud Computing/the Cloud Sliding Into the Trough Real-Time Infrastructure IT Infrastructure Utility SaaS Climbing the Slope SaaS Sales Force Automation Virtualization Cloud Advertising Grid Computing Integration as a Service http://www.gartner.com/DisplayDocument?id=1078112&ref=g_sitelink

8. Copyright 2010 8 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

9. Copyright 2010 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

10. Copyright 2010 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

11. Copyright 2010 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)

12. Copyright 2010 12 The User Organisation Perspective A Working Definition A service that satisfies all of the following conditions: 1.It is delivered over a telecommunications network 2.Users place reliance on the service for data access and/or data processing 3.The data is under the legal control of the user 4.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

13. Copyright 2010 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

14. Copyright 2010 14 Sample Architectures 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

15. Copyright 2010 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

16. Copyright 2010 16 CC Architecture – The User Organisation Perspective

17. Copyright 2010 17 A Comprehensive CC Architecture

18. Copyright 2010 18 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

19. Copyright 2010 19 Downsides – The User Perspective Operational Disbenefits and Risks Dependability on a day-to-day basis Contingent Risks Low likelihood / Potentially highly significant Security Risks Security in the broad Business Disbenefits and Risks Beyond the merely technical

20. Copyright 2010 20 Operational Disbenefits and Risks 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

21. Copyright 2010 21 Contingent Risks 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 Flexibility Customisation Forward-compatibility (to migrate to new levels) Backward compatibility (to protect legacy systems) Lateral compatibility (to enable escape)

22. Copyright 2010 22 Security Risks Service Security Environmental, second-party and third-party threats to any aspect of reliability or integrity Data Security Environmental, second-party and third-party threats to content, both in remote storage and in transit Authentication and Authorisation How to provide clients with convenient access to data and processes in the cloud, while denying access to imposters? Susceptibility to DDOS Multiple, separate servers; but choke-points will exist

23. Copyright 2010 23 Business Disbenefits and Risks Acquisition Lack of information, non-negotiability of terms of contract and SLA Ongoing Usage Loss of corporate knowledge about apps, IT services, costs to deliver Inherent lock-in effect, because of high switching costs High-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)

24. Copyright 2010 24 Some Risk Management Strategies Risk Assessment Contract Terms Service Level Agreement (SLA) Multi-Sourcing Parallel in-house service Several compatible suppliers...

25. Copyright 2010 25 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 interface 11. 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 history 14. List of annexes http://wiki.en.it-processmaps.com/index.php/Checklist_SLA_OLA_UC

26. Copyright 2010 26 User Requirements Essential 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?

27. Copyright 2010 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

28. Copyright 2010 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 operations Trade off loss of control, uncertain reliability, contingent risks against cost-advantages, convenience, scalability, etc.

29. Copyright 2010 29 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 operations Trade 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

30. Copyright 2010 30 User Requirements for CC Infrastructure 1.Integrity Assurance Service Integrity Data Integrity

31. Copyright 2010 31 User Requirements for CC Infrastructure 1.Integrity Assurance Service Integrity Data Integrity 2.Compliance Assurance Service Security Service Access Controls Data Transmission Security Data Storage Security Data Use (by service-provider) Data Disclosure (by others) Jurisdictional Location(s) of Data Storage

32. Copyright 2010 32 User Requirements for CC Infrastructure 1.Integrity Assurance Service Integrity Data Integrity 2.Compliance Assurance Service Security Service Access Controls Data Transmission Security Data Storage Security Data Use (by service-provider) Data Disclosure (by others) Jurisdictional Location(s) of Data Storage 3.Declaration, Measurement Service Reliability Levels Service Survival Protections Data Survival Protections Service and Data Compatibility Service and Data Flexibility

33. Copyright 2010 33 User Requirements for CC Infrastructure 1.Integrity Assurance Service Integrity Data Integrity 2.Compliance Assurance Service Security Service Access Controls Data Transmission Security Data Storage Security Data Use (by service-provider) Data Disclosure (by others) Jurisdictional Location(s) of Data Storage 3.Declaration, Measurement Service Reliability Levels Service Survival Protections Data Survival Protections Service and Data Compatibility Service and Data Flexibility 4.Privacy Policy Enforcement Measures, to enable: Server Privacy Policy Statement User Privacy Rqmts Statement Comparison of the two Preclusion of Usage where Requirements are not satisfied

34. Copyright 2010 34 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 controlled 6.These all depend on CCAs including specs and implementation of multiple special-purpose components and features 7.Privacy management must go beyond 'privacy through policy' and 'privacy by design' to 'Privacy through Architecture'

35. Copyright 2010 35 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

36. Copyright 2010 36 Roger Clarke, Xamax Consultancy, Canberra Visiting Professor in Computer Science, ANU and in Cyberspace Law & Policy, UNSW Computer Science Colloquium Series ANU SOCS – 28 May 2010 http://www.rogerclarke.com/II/CCSA {.html,.ppt} User Requirements for Cloud Computing Architecture