After our post last week ( http://isc.sans.org/diary.html?storyid=8251 ) defining the various "as a Service" terms that are commonly meant when people say "Cloud Computing", there was a spirited discussion around the security aspects of each.  I felt it was important to summarize this discussion for our readers, please feel free to add to this topic (or disagree with me) using the comments feature.

So Why are Public Clouds Good?
Public IaaS services are great in several situations:

• All of the "aaS" service models make great sense for any business that needs to reduce IT costs - just be sure to factor in all the cost and risk factors in when making your business decision
• you have a temporary need for computing power, and can farm out some servers as VM's temporarily
• you are not under strict regulatory control that requires audit of the hypervisor in virtual environments
• you are hosting public data
• research, or any other requirement really that needs computing horsepower, but does not house sensitive data

So What Issues Should be Considered Before moving a service to a Public "aaS" Service?

IaaS (Infrastructure as a Service)
The issue that comes up over and over is that if your organization outsources computing resources to an IaaS platform, your data and business applications go with it.  Quite often, the protections you might have in place for these valuable resources "at home" - for instance, an IPS (Intrusion Prevention System) or DLP (Data Loss Prevention) solution - do not go with them when they are moved into the cloud.

From an Audit perspective, the disposition of any guests in an outsourced virtual infrastructure is generally not known - it would be common to have virtual machines from several customers running on one physical server for instance.  The whole concept of data classification, host classification and network trust zones is very hard to enforce and audit, aside from trusting the management interface of the IaaS provider and logical separation within the Hypervisor.

Also from an Audit perspective, the entire Hypervisor layer is not available to be audited at all.  Customers of an IaaS provider have to trust their contract language and the technical security skills of the IaaS provider, and specific security settings generally cannot be known.

On the legal side, your data may be in a different legal jurisdiction than the one your company operates in.  This has implications on liability, search and seizure and privacy issues.  Not only that, but the advanced virtualization functions used by IaaS providers may mean that your VMs might migrate to another datacenter entirely in the event of a failure in the IaaS infrastructure.  For instance, a disk or communications failure in an Atlanta datacenter might prompt an automated migration of your VM to a datacenter in the EU (with associated changes in the legislation around privacy, search and seizure)

PaaS (Platform as a Service)
The PaaS model targets the core applications within a company - ERP, shop floor control, warehouse management, sales and inventory applications, things like that.  Because the underlying infrastructure for PaaS is very similar to IaaS, all of the same issues apply.  A new issue that PaaS brings to the table is "getting your keys back".  Once you've outsourced your business application to a third party, getting it back out again might not be as easy as you think.  Since in a PaaS model, the customer writes the actual application, so the data formats should not be an issue in a migrate back out.  But you will need to mount a project that migrates the data and application back to your hardware, and chances are good that hardware will no longer exist.  In fact, I've seen clients outsource their entire datacenters, then have to start over from scratch.

SaaS (Software as a Service)
In most SaaS applications, "getting the keys back" is an even larger issue.  The Google Apps SaaS platform does a really great job of "saving as" to common formats, other business-application type SaaS services don't always permit easy export of stored data to a common format in an accessible location.

Privacy settings within SaaS infrastructures have been under the microscope in the last year.  For instance, many of the original Google Voice adopters found that they had inadvertantly set their voicemail to "publically searchable" - a setting that I would suspect almost no-one would want.  Gmail has only recently (Jan 2010) moved to make HTTPS access their default.

Loss of control is another issue that has a good illustration in this space.  In the fall of 2009. a bank employee sent a file containing personal and financial information for over 1300 customers to the wrong gmail account.  Sending this kind of information unencrypted over email is probably a clear regulatory violation, but let's not get hung up on that.  After realizing their mistake, they emailed the mistaken account, asking that person to delete the first email without reading it.  After not receiving an answer, they contacted Google, who (quite rightly) asked for a court order.  The bank sued, and got the account in question deactivated.  What this illustrates is that if you are using any of the "as a Service" models, your data isn't as much yours as it used to be, and you might be subject to legal rules .

In all models, remember that bandwidth in a local datacenter is often at 1Gbps or 10Gbps.  Once moved into a service cloud, access to data might be more convenient, but will certainly be slower. 

Transport to our computing and data resources is now over the internet rather than over a private network.  While the BGP based routing architecture of the internet lends itself to routing around trouble spots, it's not unusual to have intermittent communications issues, localized outages due to fiber cuts or even widespread outages.  Remember - even 99.9% uptime is still almost 9 hrs of down time per year.

After all effort on nac and 2 factor most "as a Service" infrastructures bring us back to simple Userids and Passwords for access to our computing and data resources.  Just keep in mind that in this model, a combination like "jsmith / m0nday" could be all that stands between your data and your competitor.
 

So, to sum things up, IaaS, PaaS and SaaS services all offer great solutions for business, but none of them come without risk.  It's important to actually *read* your contract with these issues in mind before signing up, both from business risk and legal perspectives.

=============== Rob VandenBrink, Metafore ===============