Understanding Cloud Security Part One

Sunday, March 11, 2012

Neira Jones


It seems that my previous post on compliance and third parties struck a chord with a few of you... So I guess it’s about time I dedicated some time to “The Cloud” specifically!

Over the past couple of years, we have seen a lot of hype and confusion as to what The Cloud really means and what it can do for you. I think we have now reached the stage where there is perhaps a bit of disappointment that The Cloud, due to inflated expectations, is perhaps not a miracle...

Undeniably, the key opportunity for service providers is to differentiate themselves by becoming cloud service providers and major efforts are still being invested to attain a recognised position in the new clouds. The key issues for businesses when determining cloud adoption still revolve around security and control, capacity or scale flexibility and availability of skilled workforce.

Evidently, there are a lot of exciting opportunities in the Cloud, where organisations can see the potential to reduce capital costs and become more agile by divesting themselves of infrastructure and application management to concentrate on their core competencies.

As with any technology, it creates risks as well as opportunities. In some cases, moving to the cloud provides an opportunity to re-architect older applications and infrastructure to meet or exceed modern security requirements. At other times, the risk of moving sensitive data and applications to an emerging infrastructure might exceed tolerance levels.

The fact remains:Cloud Computing isn’t necessarily more or less secure than your current environment. Unfortunately, misconceptions still abound, not only about what The Cloud really is but also about security in The Cloud. I guess the limitations on cloud computing growth will include issues of data custody, control, security, privacy, and jurisdiction and portability standards as highlighted on my previous post on EU Data Protection Laws.

Adopting cloud computing is a complex decision that will involve many factors, including not only desktop applications, e-mail, collaboration and enterprise resource planning but potentially any application and the infrastructure they require. It is therefore not surprising that enterprises are grappling with the dichotomy of how to lose control gracefully whilst maintaining accountability when operational responsibilities for handling and securing their assets rests with one or more third parties.

At this point, I have to thank the Cloud Security Alliance for their tireless efforts in promoting best practice for not only securing the cloud but also all other forms of computing. Today’s post attempts to provide some definitions and takes its inspiration from their Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing v3.0 (November 2011)

One of the fundamental considerations when trying to assess cloud computing security risks is understanding the relationship between Cloud Service Models, commonly referred to as SPI (Software as a Service, Platform as a Service, Infrastructure as a Service) as defined by NIST:

IaaS is the foundation of all cloud services, and is the lowest level infrastructure resource stack. It gives the capability, if required, to abstract resources and provides physical and logical connectivity to those resources as well as a set of APIs which allows “consumers” to interact with the infrastructure.

PaaS builds on IaaS and provides an additional integration layer with application development frameworks, middleware, programming languages and tools supported by the stack as well as functions allowing developers to build applications on the platform.

SaaS in turn builds on PaaS and is a self-contained operating environment to deliver the entire user experience.

(click images to enlarge)

The key consideration for security is that the lower down the stack the cloud service provider stops, the more organisations will be responsible themselves for managing and implementing security for their assets, as summarised by the figure below:

This means that organisations should adopt a risk-based approach when considering moving assets to the cloud. This will involve risk assessments and some elements of threat scenario modelling:

  • What enterprise asset (data or applications/ functions/ processes) is being considered for a potential move to the Cloud and how sensitive is that asset?
  • What would be the impact of the asset being made public?
  • What would be the impact of the asset being changed unexpectedly?
  • What would be the impact of the asset being unavailable?
  • What would be the impact of cloud service provider employee accessing the asset?
  • What would be the impact of a process or function being manipulated by an outsider?
  • What would be the impact of a process or function failing to provide the expected results?

In other words, the first step in determining a Cloud migration “posture” is to categorise and evaluate the asset for confidentiality, integrity and availability and how these will be affected if the asset is handled in the cloud.

And finally, it would be remiss of me not to mention that when it comes to cardholder information related assets (either cardholder data or payment applications) or other personally identifiable information (PII), the process is the same, and the PCI DSS controls fit neatly with the security control model to be applied to a cloud model.

My next post will look at how cloud deployment models and location will affect security considerations and hopefully give you some tips on contractual matters. In the meantime, you can also read this very interesting article from The Metropolitan Corporate Counsel.

Until next time...

Cross-posted from neirajones

Possibly Related Articles:
Cloud Security
Service Provider
Cloud Security Enterprise Security Risk Management SaaS Managed Services IAAS applications Legacy Systems Cloud Security Alliance PaaS
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.