Cloud Computing Use Cases White Paper V2 published

[drus...@ca.ibm.com]

The Cloud Computing Use Cases White Paper V2 (http://su.pr/1ediq1) has
just been published. The focus of the paper is developers, including
the developer roles and their requirements for Open APIs to work with
Cloud Computing.

Our next step is to start the work on Version 3 on or about November
16th. Between then and now, we want to hear from you on what the focus
of V3 should be. To start the discussion, we will post these three
topics to act as a base for discussion:
- Moving to the Cloud
- Security in Cloud Computing
- Service Level Agreements for Cloud Computing
I am sure there will be additional suggestions to review and discuss,
which is exactly what we are hoping.

If you were a customer, what would be the highest requirements you
feel should be considered for the core topic of V3 of the White
Paper? As you post your comments, please ensure that you provide
enough detail for others to understand what is being posted.

Through an active and open discussion, we will be able to focus V3 on
the topic that is most relevant to our community. Let's brainstorm on
the potential topics and let your comments be your vote.

[michael versace]

I suggest V3 be DEDICATED (with emphasis) to use cases for cloud security and related service agreements.  Service agreements should be tied to cloud security use cases since together they form the basis of trust and accountability.  The timing of this analysis is very important given recent announcements from EMC, VMWare, and Cisco and the VCE (see http://wikibon.org/wiki/v/Eleven_Questions_about_Virtual_Compute_Environment_(VCE))

The most simplistic approach could include one set of use cases focused on common cloud service models

- Software

- Infrastructure

- Platform

One set could be focused on deployment models

- Private

- Public

- Hybrid

A third set could be focused on specific cloud workloads.

- Storage and Archive

- Transaction Peak Workloads

- Software Development

[Nils Puhlmann]

Just as an fyi, the Cloud Security Alliance will very soon publish the 2.0 version of its Guidance document. Instead of reinventing the wheel, why not use the work already done and implement it here for the "security in cloud computing" part?

Thanks,

-Nils Puhlmann

--
Nils Puhlmann, CISM, CISSP-ISSMP
Co-founder, Cloud Security Alliance
npuh...@cloudsecurityalliance.org

http://www.cloudsecurityalliance.org

[Nguyen Quang Hung]

Hi all,

IMHO, there are some approaches to IaaS Cloud Open APIs such as:
a- Sun CloudOpenAPIs: focus on High Performance Computing terms, e.g. JSON/Datacenter/cluster.
b- OGF Cloud OpenAPIs: similar to Sun CloudOpenAPI, but cloud infrastructure as RESTful resources.
c- Other OpenAPI not for High Performance Computing: DAIOS, RedHat DeltaCloud API, etc.

I think we should accept various of Cloud OpenAPI for HPC Grid/Cloud applications and Business applications.

greetings,

NQH

--
Nguyen Quang Hung

[michael versace]

I haven't seen 2.0, but if we apply the 15 CSA domains to a set of use cases, ultimately producing implementations models for end-users, I think we'd be filling a marketplace need.  We do need some level of interoperability/reference across credible industry activities.

- Mike Versace

[Paola Garcia Juarez]

As a customer, the highest requirements could be:

1) Security of data (Applied policies)
2) Service Level Agreements (SLA)
3) Scalability of resources (and related things like costs, support, impact of other users in the same cloud,etc)
4) Testing of the applications
5) Management of upgrades, support, notification of problems, backups, migration, etc.
6) Policies of resilience

I also think that the security part could have a "check list" with all the devices and policies of security.
These are only main ideas, that for sure we could develop more...

Regards,
Paola

2009/11/5 drus...@ca.ibm.com <drus...@ca.ibm.com>

--
Eng. Paola Garcia Juarez
(55-21) 83291885
pgarc...@gmail.com
http://www.linkedin.com/in/pgarciaj
Twitter: pgarciaj13

[Bhaskar Prasad Rimal]

I think,  as a  customer point of view,  user-centric security mechanism is important well as data governance. Similarly "user-based policy management" is another discussion in cloud....

--
Bhaskar Prasad Rimal,Researcher
Graduate School of Business IT
Kookmin University
861-1 Jeongneung-Dong, Seongbuk-Gu, Seoul, 136-702, Korea

[sanjay]

In supply chain example, how are we ensuring that company A which gets
parts from Company B and C then makes a component and supplies to
company D and E. We need that Company D and E don’t see each others
data; similar to company B and C also don’t see each other’s data.
Company A should be able to see complete data for its transactions
from any one of them?

How can we establish such relationships in the cloud?

Number of companies involved may be more than 5, as that depends on
number of suppliers for component, transportation, products used in
transportation etc.

[drus...@ca.ibm.com]

Posted by Mike Kiser from Cloud Security Alliance Google Group
_____________________

The following is intended to open discussions on the topics of
Security and Service Level Agreements. In doing so please address
considerations for the different markets in which Provider Offerings
might be oriented.

Many of the traditional elements of a Service Level Agreement should
still apply. The approach to managing the SLA shouldn’t be radically
different than one of any remote service. For example, Data Center
Outsourcing agreements (if written well) will provide for times,
locations, costs, performance, and responsibilities of the parties
involved. They should also describe how ancillary services (e.g.
applications, engineering change management, refresh, etc) will be
supported.

The challenges with SLAs stem from the models and structure of the
offering. That is, Software as a Service, when structured as a
Commercial-off-the-shelf product/Service, could have widely different
Service Level Objectives. For example, assume that one extreme is a
highly customized cloud—built toward a specific market with unique
requirement; or one built to service as many users as possible—built
as one service to many users.

Thus, in the case of standard offerings the SLOs (if defined at all)
should express specific measurable characteristics of the SLA, such
as: availability, response times, 1st call support, RTO/RPO . In a
standard offering many businesses will have different requirements for
operational support and may drive the need for service catalogue and
rates. Question: How are Cloud Offerings (infrastructure, platform, or
software) being positioned to deal with this?

Next, SLOs should also express quality-of-service measurements that
can be used to address things like incident management, root cause,
and problem resolution. Again, this will vary depending on the
operation or the service, and whether the offering is oriented to a
large and varied market or is customized toward a specific market.

If we put aside the general market (say average homeowner buying open
services) and focus on something like the Federal Government Market
than we find a need for highly complex set of SLOs and details for
Management and Compliancy. Security requirements alone drive a number
of implications in every IT Towers that is directly or indirectly
affected by the Cloud Offering.

I am very interested in seeing how Cloud Providers are positioning
their offerings for compliancy with NIST and FIPs Standards, how
storage architectures /strategies are being considered, Transition and
Migration controls, financial planning (and the list goes on).

Mike KIser

[Steve Primost]

As mentioned in a posting when discussing the draft version, the definition for "federated identity" in Section 3.2.1 is not consistent with the work done by the Liberty Alliance Project in defining "federation" and the definition and use of a "federated identity" More can be obtained from the link to ttp://www.projectliberty.org/liberty/resource_center/specifications/liberty_alliance_id_ff_1_2_specifications

and in particular (for reference and easier reading) the non-normative explanation in "draft-identity-idff-arch-overview-1.2-errata-v1.0.pdf".

To wit:

an enterprise may have one or more identities for an end-user (the example is that of the possibility that an employee of a company may also be a consumer of the product or services of the company). This may be mapped from the "userID/password" to a single digital identity, sub as a customer reference number, with additional authorization and authentication information, as optional). How that "end-user" is represented to the external world, defined in your context as "the infrastructure" may be a different identity. If the "infrastructure" spans multiple cloud structures, such as an "internal" and "external" xaaS, it is possible, and more likely that more "identity" information may be used. For security purposes, customer number is not recommended when dealing with outside (external) companies, since this may reveal too much about the person. The term used in the documentation is that of "opaque handle", as a method by which a reference is made to the end-user but not the actual customer reference number. In some cases, there may not be, for each "federation" a one-to-one match but a "many-to-one" match such as a class of users. It is very clearly discussed in the overview.

If you want, I would like to suggest an alternative definition for "federated identity" and would be happy to work with you on that wording for the next issue of that document.

Steve Primost CISSP, CISM

[Doug Tidwell]

Steve, I would love to see your alternative definition for federated
identity. I'll take a look at your link, looking forward to working
with you on this.

Cheers,
-Doug

[Steve Primost]

Hi Doug --

Thanks for the response. I have been a bit busy the last week or so (job hunting!), meaning to get back to you on this. I will send you a draft in about a week, if it is okay with you.

Regards --

Steve

--

You received this message because you are subscribed to the Google Groups "Cloud Computing Use Cases" group.
To post to this group, send email to cloud-comput...@googlegroups.com.
To unsubscribe from this group, send email to cloud-computing-us...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/cloud-computing-use-cases?hl=.