Standard-based, layered approach to a Cloud Security Framework / Use Cases

[Matt Rutkowski]

In an earlier post, I suggested several security infrastructure areas
that would need to exist in the "cloud" security framework and an
approach to constructing security use cases that sought to "touch"
each of these areas. Hopefully, such an approach would lead to a set
of use cases that would reflect many of the security concerns cited as
barriers to cloud adoption. I would call these "Infrastructural
Security Areas".

In the same post, I alluded to "Security Management Controls" which I
want to elaborate upon now. This would include the processes that
enforce security policy (perhaps against an SLA) and assure governance
of the IT infrastructure and in turn use and connect the
Infrastructure areas together. These controls in turn imply needed
management APIs which also would be born out from use cases.

It is important to view how "the cloud" is managed in terms of an
internal (provider) view to assure that they can maintain an "audit
ready" posture for compliance assessments, as well as an external view
of how a cloud customer wishes to manage the security around their
specific cloud deployed applications/workloads, data and resources.
So the key feature to reflect in uses cases internally would be
operational audit and compliance and externally security information
transparency. I believe there are Service and Federation patterns
that already exist in some areas of enterprise security that lend
themselves to cloud and others that seem to be evolving that could
help us (e.g. DMTF Open Cloud Standards Incubator).

If we assume that we are describing use cases that can be applied to
an open cloud marketplace and that assure customer investments into
cloud are preserved, we of course should suggest open standards as a
means to construct data, interfaces and patterns.

So what I see evolving is a "layering" process where uses cases are
built upon patterns, which are in turn built upon a cloud security
framework that provides security management controls supported by
infrastructural security:

- Cloud Security Use Cases
- Standards-based Security Services and Patterns
- Security Management Controls (based upon standard protocols, APIs
and data formats)
- Infrastructural Security Areas (based upon low level data schemas/
protocol standards)

- Does this layering approach create a view that can meet your use
case requirements?
- Are there any additional layers or additional parts to the suggested
layers that need to be considered?
- Does anyone have any security use cases that would map onto this
layered approach?

Regards,
-Matt

[deepak mane]

Hi Matt,

We can prepare use case based on a As a service model of cloud
computing

-> Infrastructure as a service model
-> Platform as a service model
-> Software as a service model

Risk modelling in Asset in Cloud computing..

In this use case we can identify different set of assets which are
belong to cloud computing .. Then we can prepare matrix with respect
to ownership of assets in SaaS, PaaS and IaaS model.

then We have to prepare framework to identify threat/risks with
respect to IaaS, PaaS and SaaS , by seeing this information we can
prepare Risk assessment and management tool with respect to cloud
computing ..



Thanks
Deepak

[Matt Rutkowski]

Hi Deepak,

Are you saying that use cases should be constructed in such a way to
include as many cloud based services (assets) as possible using a
taxonomy based upon the cloud provider service model of IaaS, PaaS,
etc.?

So far, I have simply been trying to describe a security framework
(infrastructure and controls) whose roles should be highlighted in the
use cases (which in turn show areas of concern for security or risk
that needs to be managed). Risk assessment (which includes Threat and
Vulnerability assessment at all levels of a cloud datacenter...
physical, infrastructure, platform and application layer) is a
security control itself and would touch many areas of the security
infra. and controls I have already listed.

Has the framework I have already described in previous posts
sufficient for the use cases you are envisioning? Are you indeed
suggesting a taxonomy for use cases based upon assets? If so, can you
provide an example of a couple of use cases to demonstrate your point?

If you want to work with me offline feel free to email me.

[clark]

Copied this from a LinkedIn discussion (Cloud Security Alliance Group)
post I just made, in response to Dave Russell's thread there -

It's not a Use Case scenario but it is a consideration - public-facing
versus private B2B scenarios. One of the major differences between
these two categories will be the question of who authenticates the end
user (or process) who initiates the story? I can see public-facing
scenarios boiling down to a relatively small number of large public
Identity Providers (e.g., large financial institutions; government
agencies; etc.) where users authenticate, but in the B2B scenarios
users (or processes) will authenticate at the enterprise and then
initiate activity with one or more Service Providers.

I agree with Eli in the abstract - the principle of Separation of
Concerns dictates that the private key should never leave the secure
domain of the key holder, no matter where the encrypted data lives.
I'm not so sure the authentication service necessarily needs to be co-
located with the encryption service, though.

Where SOA and AOP concepts were "nice to have" in the pre-Cloud era,
they become absolutely indispensable for Cloud Computing Use Case
scenarios. Discrete course-grained global services MUST be defined
and agreed to via some global community consensus building process and
an entire Cloud Infrastructure Layer composed of those services (in
the abstract) MUST be implemented, tested, and deployed rigorously
before enterprises would be able to trust the public Cloud model with
"the crown jewels" (or individual citizens, for that matter).

I applaud Dave's efforts to help drive such a consensus building
process where no "body" has stepped forward yet to formally do so and
I agree that defining a set of Use Case scenarios is an excellent
start (although simply defining terminology is probably necessary even
before you can intelligently describe Use Cases).