cloudsigma

we do use forward secrecy for all our client facing services and of course accept https only. we are also looking at upgrading from 128bit to either 256bit or even 512bit to offer a further 'extended runway' against future direct decryption :)

three points: 1. apathy is the friend of all such measures 2. the NSA aren't the only gig in town both in terms of agency and country and in any case have a nothing close to ubiquitous coverage 3. as hard as you might find it to believe some people do have principles and beliefs. our company was founded and has always operated in line with those of our founders. all this is nothing new. again refer to point 1 about apathy.

The Patriot act has provisions that can potentially be applied to subsidiaries of US companies abroad but not vice versa. If you think about it it would mean shareholders of companies could be pursued globally under US law just for owning shares in a US company. It's all around a bad situation right now with conflicting sets of rules and that's without a doubt.

Please have a look at:

http://www.cloudsigma.com/en/our-cloud/how-we-compare (feature comparison)

https://cloudsleuth.net/web/guest/global-provider-view (select Europe for a comparison of our cloud performance against other providers)

In terms of our platform:

* Customer-managed firewalls

Yes

* Redundant switching/interior routing

Yes

* Private layer 2 networks

Yes we have private VLAN functionality. We'll be expanding this to up to 8 per server shortly.

* Bring your own IP space

Yes, this needs to be manually added to our BGP sessions but isn't a problem and we do this regularly for customers.

* Redundant exterior routing (e.g. I advertise my prefix through a new provider during an extended downtime)

We have multiple redundant carriers and they failover automatically. Actually the failover happens instantaneously, even if you are actively pinging you don't even get one dropped packet :-) If you have your own private infrastructure space elsewhere we also are able to choose the preferred carrier too.

* Out-of-band access

Not sure in what context you are talking about here. If you extrapolate I can give feedback.

You shouldn't confuse a simple affiliate scheme with multi level marketing which is an entirely different beast.

When you say:

"extensive network design customization that your managed service colo host will typically support"

could you give a couple of examples of the sort of thing you are talking about?

Yes, all cloud brokerage attempts have so far stuck to the resources and avoided trying to do any unified billing. Its really tough to accomplish.

Can you think of other areas where competing services have common open billing? Great for sure but difficult commercially. Especially when you start bringing in credit risk and other non-technical factors.

Yes this is definitely possible and a multi-vendor approach in the cloud is achievable at quite a low bar in terms of customer size. You only need to look at outages at Reddit and many others to see the benefit of that approach.

A test along the lines of the one conducted by Google against Bing would reveal the correct situation. Essentially 'seed' the registrar with some crazy domains that no-one would want (google did this with unique searches) and wait. This would be particularly effective against less popular domains which gain less interest to begin with.

If you see any of these zero value domains get registered you have your answer, or at least a very high confidence in your initial assumption.

Welcome to Hacker News, I see this is your first ever contribution.

In terms of what you say, we actually have many unique features and could no way be described as 'off-the-shelf'. We are continuing to innovate and will be launching future first-to-market features in the coming months.

Do any of those providers offer you a free choice of operating systems? i.e. install any operating system you like, any version? Or control of the full server?

There is a very big difference between a VPS where the vendor places restrictions on many things and retains full root access and our cloud servers were you have total control over the software running on your server and full root access.

Put it another way, if I gave you two servers, one dedicated, one a cloud server in our cloud. If you SSHed in, you wouldn't be able to tell me which was the cloud server and which was the dedicated server based on your control of the server. That's totally different to VPS.

Essentially you are combining the control of dedicated servers with the flexibility and transparency of cloud architecture.

Traditional VPS providers slice up large dedicated servers to share them between customers. Typically VPS providers use a container technology such as Virtuozzo to isolate multiple users on a single server from one another whilst running a single shared instance of the operating system. By contrast, our KVM technology enables every user to run their own isolated copy of an operating system of their choice, providing a greater choice of operating systems, higher performance, deeper configurability, and stronger isolation and security guarantees.

Its a cloud server. You can vary its size an re-provision at will. Also, all resources are unbundled so you can tweak the RAM for example leaving other resources unchanged. You can see a video of a cloud server being deployed at http://www.youtube.com/user/CloudSigmaCH . It takes a couple of minutes.

We are offering cloud servers i.e. stand alone servers in a cloud environment. You have complete control over the software and networking layers. So you are basically running Debian (in this case) with the same level of control that you'd have over a system installed on a dedicated server. You have full and sole root access inside your system.

Yes you are right, it is certainly easier to snoop on customers as an IaaS vendor if you keep full root access and file system visibility. I'd say that constitutes 'lazy policing' and not needed and that is certainly our experience :-)

Botnets etc. rely on free hijacked capacity not computing resources bought on an industrial scale on commercial terms. The cloud is no more prone for use as a botnet or other problematic activity than dedicated hardware. Although often touted, I've yet to hear a compelling case for IaaS clouds being any more susceptible to such use than VPS, shared hosting etc. etc.

Likewise, such activity becomes very obvious very quickly and it isn't access inside a customer's cloud server that allows you to spot such activity.

As I say, there are not real reasons not to give customers full control of their cloud servers any more than they have full control of their dedicated servers. In fact, the flexibility of the cloud makes policing it more easy than dedicated hardware without snooping inside customer servers or restricting their ability to control their computing.

In terms of administration, customers can choose to use their own in-house admins or that of a third party and many of our customers do. The point is they done have a choice, with other clouds they have one choice, the cloud vendor as the admin. That's overly restrictive and it isn't surprising why you get such concerns raised over security and control in the cloud.

Thanks for the great feedback by the way.

Best wishes,

Patrick CEO CloudSigma

Yes you can. Resources vary according to a pricing matrix so you can set in your script to send APi calls based on those levels.

Kind regards,

Patrick Baillie CEO

Yes it does and the critical difference is that the customer doesn't have control over when instances are yanked. Likewise servers/drives aren't persistent so you can't have nodes hibernating and then bring them in response to pricing.

Our system is designed to let you control when servers are turned on or off in order to perform orderly computing. Likewise the fact that the servers and drives are persistent allows you to shut them down and back up again over peak times and keep data persistent. This is great if you are doing large jobs like 3d rendering for example.

Best wishes,

Patrick Baillie CEO

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

That's a possibility, the concern is the performance implications, particularly latency involved in operating such a system which needs to interrogate every data access. The question is whether such a system would have more of a performance hit than simply encrypting (with the added advantages that has anyway).

Best wishes,

Patrick

That's great information and you are right. Secure disposal of drives by the vendor is of course also extremely important.

For those deleting virtual drives in the cloud securely the points made in the post might seem obvious but I believe most users in the cloud don't undertake such measures. That's why the encryption option is another way to go and implicit so much more likely to be taken up by cloud users.

Customer side encryption is great and of course usually means access is restricted to the customer, the issue is server restarts, crashes etc. which require manual intervention to get the file system or data directories back up and running again. In a dynamic cloud environment this can be particularly cumbersome.

Best wishes,

Patrick

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...

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

Vukk,

The issue there is more about tracking. You'd have to track every single block and return zero for any that hadn't been used/altered since drive creation. I'm guessing it would prove pretty costly in terms of latency for drive access after initial drive creation but its a good idea potentially. I'll pass it onto our technical guys as well to ask about its feasibility.

Best wishes,

Patrick

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

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

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

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

Secure deletion on physical spindles is extremely resource heavy especially if someone is deleting a very large drive.

Storing encrypted first does affect performance but it is generally much less and more predictable (doing a big secure delete on a drive inflicts an immediate and unexpected hit on that part of a storage array).

We think encryption is also just a lot more robust. If you don't lay down the data in the first place in readable form on the physical drives, its eliminates a lot of data leakage possibilities.

Best wishes,

Patrick

A lot of the compliance issues come from the mixing of infrastructure and the software and networking layers with many IaaS providers. In our cloud only the customer has root access and file system visibility. Essentially the cloud vendor then needs to demonstrate compliance with physical access and data protection/data leakage areas as employees don't have the ability to view data. This isn't a typical situation and for most clouds that are more like IaaS/PaaS hybrids it opens quite a can of worms.

As a Swiss based cloud currently we'd be excluded from many US industry sectors which required domestic hosting. This will change shortly (can't say more) and when it does we'll be working to put in place the necessary coverage/compliance certificates to expand into these sectors.

Best wishes,

Patrick

Yes and no. The main issue we see with 10Gbps is networking topology. We don't want to roll out a star type networking which has a big single point of failure. The whole point of moving to distributed block storage is to eliminate this. Its difficult to build a grid layout with 10Gbps without going into silly money. With Infiniband it supports very well in grid configuration which is ideal for a distributed storage network. As a technology it has at least a few years left simply because it can offer 40Gbps and Ethernet won't be there at a reasonable cost for a while.