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.
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_Envi...)
)
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
On Thu, Nov 5, 2009 at 3:18 PM, druss...@ca.ibm.com <druss...@ca.ibm.com>wrote:
> 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.
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
On Thu, Nov 5, 2009 at 12:18 PM, druss...@ca.ibm.com <druss...@ca.ibm.com>wrote:
> 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.
-- Nils Puhlmann, CISM, CISSP-ISSMP
Co-founder, Cloud Security Alliance
npuhlm...@cloudsecurityalliance.org
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
On Fri, Nov 6, 2009 at 3:18 AM, druss...@ca.ibm.com <druss...@ca.ibm.com>wrote:
> 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.
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
npuhlm...@cloudsecurityalliance.org> wrote:
> 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
> On Thu, Nov 5, 2009 at 12:18 PM, druss...@ca.ibm.com <druss...@ca.ibm.com>wrote:
>> 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.
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...
> 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.
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....
On Fri, Nov 6, 2009 at 6:20 AM, Paola Garcia Juarez <pgarcia...@gmail.com>wrote:
> 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...
>> 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.
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.
On Nov 5, 12:18 pm, "druss...@ca.ibm.com" <druss...@ca.ibm.com> wrote:
> 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.
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).
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...
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
On Mon, Nov 9, 2009 at 7:01 AM, druss...@ca.ibm.com <druss...@ca.ibm.com>wrote:
> 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).
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.
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.
On Fri, Nov 13, 2009 at 11:35 AM, Doug Tidwell <dtidw...@us.ibm.com> wrote:
> 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
> --
> 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-computing-use-cases@googlegroups.com.
> To unsubscribe from this group, send email to
> cloud-computing-use-cases+unsubscribe@googlegroups.com<cloud-computing-use- cases%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/cloud-computing-use-cases?hl=.
