

How your data gets compromised in an IaaS cloud: Vendor tells all - cloudsigma
http://cloudsigma.com/en/blog/2010/12/04/15-security-in-the-cloud-data-storage

======
patio11
This is a big issue in certain verticals. In my early research for AR I looked
into the interaction of HIPAA (an American privacy law for medical
information) and cloud hosting. My brief educated layperson's conclusion:
sensible default settings at your cloud service of choice almist certainly
lead you to be OMGWTF noncompliant. I immediately moved medical providers out
of scope, because it looked like there were, minimally, several months of
engineer time needed to merit a finding of compliance, plus whatever
costs/effort it would take to deal with the lawyers.

~~~
samd
My layman's conclusion of HIPAA and cloud hosting was that the language of the
law was vague and technologically out of date, and that depending on how you
interpreted its requirements you'd be either OK or OMGWTF noncompliant.

It's too bad because the medical space is in dire need of innovation and
there's a lot of money to be made.

~~~
cloudsigma
There's definitely huge opportunities in the medical sphere. We do have
customers from this sector in our cloud although how they handle client data
is always very strictly controlled and I think its fair to say that only a
subset of the potential is being realised properly in terms of the broader
market.

Kind regards,

Patrick

------
trotsky
I don't understand why a zero wipe isn't sufficient when provisioning the
storage. At least for this purpose it would seem to achieve the same result as
encryption with much less complexity and no ongoing overhead. AWS takes a long
time to provision new EBS storage, does anyone know what's going on there?

~~~
cloudsigma
Simply overwriting with zeros isn't a 100% fix by any means and actually it
does involve writing perhaps 1TB of data in sequence. For any storage array
that's a lot of data to write. It doesn't matter if its 0s or something else.
Better is to use random data but even so you still have forensic techniques to
revert this.

You say encryption is complicated but actually as a vendor its implicit in our
system. As a customer you just mark the drive upon creation and then its
invisible to both you as a customer and the cloud servers that are using the
drive. That's really the whole idea, to make security measures that are
convenient so people actually use them. Our customers see usually about a
10%-15% performance difference and we've got pretty high storage performance
to begin with so it rarely means taking a performance hit compared with other
platforms. We also allow multiple drives so users can categorise data by
drives for encryption or not. Of course I'm biased regarding performance but
the principles stand.

The other point of the blog post is to ask; what do other vendors do and do
their customers have the ability to find out? Security through obscurity isn't
an acceptable approach in the cloud. Everyone needs to be transparent and work
to build confidence through solid information and education on how to use the
cloud securely and effectively.

Kind regards,

Patrick

~~~
moe
_Better is to use random data but even so you still have forensic techniques
to revert this._

How does one revert this without physical access to the drive?

We overwrite our EBS volumes with zeros before deleting them and I was under
the impression that should protect us against leakage to other customers.

Naturally it can't protect us against a malicious amazon employee pulling the
drive physically (or taking snapshots without our knowledge), but frankly I
don't see how your "vendor encryption" helps with that either.

If all I do is set a checkbox to "mark the drive for encryption" then that
means

    
    
       a) You have the encryption key, I don't.
       b) The checkbox could just as well be a placebo and not have any effect.
    

Thus we're back to square 1 and the same old question: "Do I trust you?"

No need to take a 10%-15% performance hit for that.

~~~
cloudsigma
You raise a number of interesting points.

Firstly we can't comment on the arrangements of other companies for whom we
don't have visibility. As a customer you can of course ask them and one would
hope they are able to provide you with a full answer. On the blog we raise and
answer (in our case) the various aspects for data storage, not just of
security but also legal issues and data migration aspects. How many customers
currently using an IaaS cloud can answer those questions or get their vendor
to provide answers? Building confidence in cloud computing is all about
transparency, education and creating secure ways of working. Different users
will choose different solutions and regimes that they feel are 'secure' for
them and we are all for that. We'd also like people to be able to make
informed choices which means having the right information.

Secondly, there is a big difference between a vendor that has sole root access
and full visibility of all your data and one that doesn't (as in our case); in
our cloud the customer retains sole root access to cloud servers. This means
our employees don't have visibility into cloud servers in the way you suggest.
Further, as clearly stated in the blog, the issue raised is about data leakage
i.e. data being accessible between cloud users. There are other issues
regarding vendor security but this doesn't negate the points being made about
data leakage.

Finally, your point regarding the encryption being a placebo is specious.
There is a big difference between making systems secure against casual data
theft/leakage or the actions of rogue employees and a company that is
institutionally set up to lie and steal their customers' data. If you think
your vendor is actually of that nature then no security measure can help and
that's the case for any company you have dealings with. It really isn't a
valid criticism of any security measure that may be put in place.

The measures we outline and have implemented on the vendor side do address the
real issue of data leakage that occurs with block storage devices in IaaS
clouds; they are effective and they are convenient. Our storage performance is
generally higher than many other vendors to begin with and we have much
feedback from customers regarding this even after using encryption. These
customers are getting good performance in a secured cloud. For them it makes
sense.

Best wishes,

Patrick

~~~
moe
I can't help it, it just doesn't make sense to me.

The only people it would theoretically protect me against are _your_ people
(those with physical access). And if I don't trust _your_ people then why
should I trust _your_ encryption?

The issue of data leakage between customers (who don't have physical access)
seems so trivial to prevent to me that I'm honestly wondering if I'm missing
something fundamental here.

What's wrong with just making a loopback file and mounting _that_ to the
customer node? I had in fact assumed that this is how most clouds do it (for
sanity reasons alone, security being the bonus). Hence I'm rather baffled by
the whole claim of "data leakage through reading the raw volume".

Has that ever happened on any cloud provider?

~~~
cloudsigma
The blog post looks at three main aspects to data storage: \- keeping data
private (to you as a user) \- thinking about legal issues of location and
control \- thinking about migration issues

Of the first point we outline how data leakage is possible in IaaS clouds.
Some may already have measures in place to prevent this. We have our own
measures too, some private others public. We offer encryption also as a free
and convenient way to secure your data. This has nothing to do with securing
physical access which is a totally separate issue. It relates to how customers
secure access to their data. As outlined previously we don't have root access
or file system level visibility into cloud servers in the way that other
vendors generally do (although there are exceptions). As such it does pretty
much come down to securing physical access. That isn't the case on other
platforms for sure.

Here's another article that you might like (short but sweet) which actually
talks directly about EBS and others and the problem of 'data remanance' in a
way we can't as a competing vendor:

[http://elastic-security.com/2010/01/07/data-remanence-in-
the...](http://elastic-security.com/2010/01/07/data-remanence-in-the-cloud/)

Here's an interesting quote:

"The technique of overwriting file sectors does not work without the
collaboration of the cloud provider. You are not given access to the physical
device, but only to higher level abstractions like file-systems (e.g. Amazon
EBS) or key-value based APIs (e.g. Amazon S3). "

I'll get back to you on the loopback technique once I've spoken with the
relevant storage guys in our company for feedback.

Kind regards,

Patrick

------
notmyname
FWIW, non-block storage services (like Rackspace Cloud Files and S3) should
not be vulnerable to these info leaks. I cannot speak to the S3 backend, but
this sort of attack would not be possible with Cloud Files. Of course, the use
case is a little different when you don't have access to a block-level device.

~~~
cloudsigma
Yes we believe that's the case too however like you say, object orientated
storage services are a different use case to block-level storage devices.
Customers running their own databases for example can have these data leakage
issues if they aren't careful.

Best wishes,

Patrick

------
rworthington
Do you guys know what the situation is with GoGrid? I've been using them for
about 6 months now but I've not been using encryption. Am I exposed to data
leakage in the way you outline in your blog post?

~~~
cloud-geek
Any service that reuses the same physical drive space should be vulnerable
unless they either store encrypted or do secure deletion. Having used secure
deletion before on dedicated hardware it is really hitting the drive
performance. That is why I am guessing vendors don't use secure deletion.
Using encryption overall looks more efficient overall.

~~~
moe
Sorry, but this is really bordering on FUD here.

Have you ever looked at a freshly mounted EBS volume on EC2? It shows all
zero's for me. And I'm almost sure that was not just a coincidence for the
volumes I looked at.

Moreover there are more efficient ways than encryption or "full sweep
overwrite" to address this at the storage-level.

~~~
cloudsigma
Our post is regarding IaaS clouds in general and has nothing specifically to
do with EC2 or any other particular vendor. It may be the case that EC2 does
have secure measures in place; I wonder how many of their customers can
articulate them (or customers of other IaaS clouds for that matter)? We are
merely raising an important issue. You can look at the many other posts we
have on the other various aspects of security in the cloud of which this post
forms the latest instalment regarding data storage.

"there are more efficient ways than encryption or "full sweep overwrite" to
address this at the storage-level."

Your suggestion would be?

Kind regards,

Patrick

~~~
moe
_Your suggestion would be?_

See my reply above about using a loopback-file.

It's a one-liner:

    
    
      dd if=/dev/zero of=/vols/customer123/vol234 seek=$SIZE bs=1 count=1
    

There's surely quite a few other ways to skin this cat (eventually arriving at
the multi-tenancy features in proprietary SAN appliances), but this seems the
most obvious one.

