A Potential Fix for Cloud Security Woes

DV:="do you believe that virtualization introduces the requirement for architectural changes (at the system-level) that, without being made, will fundamentally make cloud computing perpetually insecure?"

I think security people will note that by going to "Cloud Computing" you have greatly expanded the "attack surface" where the "attack surface" refers to the possibilities available to an attacker

If an attacker gets into the "Cloud" what can he steal ?

Bruce Schenierer teaches us that "complexity is the enemy of security" and I certainly agree with him.  Security has to win by a shut-out and the larger you make that "attack surface" the more opportunities you present to the attackers and the more difficult you make the job of security.

which I why I agree with Jart's comment on the "Balkinization" of the Internet.  It could be access is too public.  If so it could be usefull to consider how best to redefine access procedures.

what manner of credentials would you expect me to present before you would grant me access to the "Cloud" where the "Cloud" is a service for which you are responsible for security?

it's an interesting thread and certainly a line of thinking that many internet advocates will be interested in

it should be noted that a virtual machine can be infected just as a real machine can be.  Of course the virtual machine can be deleted and re-activated.  that will get you a clean VM but what damage could an infected VM do?  In the end it will be necessary to white-list software -- whether on a VM or on a real machine dosn't really matter -- the practice of sending un-authenticated updates over the air or over the net -- was a bad idea to begin with.  If you have a computer that just does not allow itself to be updated and does not allow "ram scraping" does it matter what programs you run? not at all. and in the end that is the only RX for malware.

Try a GOOGLE of security breaches of RACF.  see what you come up with.  I tried it and all I came up with was a report that said they couldn't find much, either.

Annoyed? Not at all Mike-- I truly have great respect for your knowledge and I apologize if I came across as annoyed. My question was of a serious nature. I'm trying to share my thoughts (and get folks' opinions) on the architectural challenges brought forth by virtualization-- from a security perspective.

The crux of my question is do you believe that virtualization introduces the requirement for architectural changes (at the system-level) that, without being made, will fundamentally make cloud computing perpetually insecure?

David: if I have annoyed you; I apologize

First I dont think that even traditional computing architecture security problems have been solved, and are far from being solved.  I dont think that tools will satisfy the issues with the cloud.  The basic issue is that people implemented cloud architectures without addressing that the cloud has issues well above and beyond the traditional security issues.  This will always be the case with cloud computing and it will not be solved.

Show Stopping Problem: Window computers are not secure. there cannot be any meaningful discussion of cloud security until the endpoints are fixed.

Okay Mike...You've demonstrated your considerable expertise time and again on my posts and many (many) others. So I understand and appreciate the depth of your considerable practical knowledge.

My question is if we solve this show stopping problem will security be adequate to host mission critical applications in the cloud?

Ira...I greatly respect your perspective here and appreciate the focus and context you've put on this post. It's been a very good discussion and I also appreciate the contribution of others.Thank you.

I want to stress that my point has never been that cloud securtiy is 'just an architectural issue.'

What I'm saying is that unless the architecture of cloud computing is changed at a system-wide level, we will never truly have security in the cloud. Security experts alone won't be able to solve this problem.

I'm inferring that you are saying that once we have good tools (and presumably processes and procedures too), the cloud security problem will be solved. Is that your assertion?

If so - we disagree. I don't think this is solely a maturity of tools issue. It's necessary but insufficient.

My contention is that even if the well documented cloud performance problems are solved. Even if the speed of light problem is solved. Even if authentication problems are solved,  etc. etc. etc. We still won't be able to host true mission critical applications in the cloud. Not without a fundamental architectural change similar to what we saw with IBM MVS many years ago-- Because of the security conundrum brought on by virtualization which I've been hammering at in here.

I'd really love to hear from system architects on this issue and also try to gain some insight as to what Google's doing -architecturally- to solve this problem.

Cloud computing security is not just an architectural issue.  Every other security issue involved with all security systems are still applicable to cloud computing.  The problem is that there are relatively few good tools to secure cloud environments when compared with traditional environments.  All other security vulnerabilities are still present in a cloud, and are even more important.  Access control is just one example.

Ira,

I am aware and completely agree that authentication is definitely a weak point and obviously is also not just an issue with running servers in the cloud.  It will be difficult if not impossible to get away from problems with authentication, and data leaks, whether its directly with an app running on the clouds public interface or a server in a local office on a dmz because of the carelessness of end users.

It still gets me that plaintext authentication protocols (ie pop, imap, ftp, http auth and other http web based logins) are still widely used, that apps still have different responses or behaviors for failed authentication of an existing user versus failed authentication of a non existent user, sites allow simple passwords including username and password being the same and end users think its ok to use the same password everywhere and write it down on paper.  

As far as data dispersal, that is definitely useless if you can gain shell/console access to the cloud servers.

My last point is if all data is encrypted on a cloud server and you kept the keys completely off of the cloud (not even just in memory on the cloud server) and even went as far as having a shell account on the cloud server open to the public (not that you would do it), it really wouldn't matter if anyone had access to the encrypted data until they build the next billion cpu/gpu cluster to brute force it to plaintext.

Here is an example of one way I would consider securely storing sensitive data on the cloud.  A company with several offices needs to share sensitive data and have it stored in a central highly available location.  You setup an instance on the cloud that runs an app that listens on an RFC1918 ip address aliased to the loopback interface.  The app handles storing and retrieving all encrypted data from allocated cloud storage, but does not know how to decrypt or encrypt it.  Each office has a front end server on their local private subnet that has an encrypted IPSEC or other tunnel to the cloud server.  Each user authenticates only with the local front end server.   The front end server handles encrypting and decrypting data to/from the cloud server app.

In this situation you are reducing the authentication attack against the cloud server to the ipsec application itself which will be very difficult as long as strong keys are used and IPSEC server does not have some kind of remote exploit, but even if it did they would only see encrypted data.  You would just want to make sure to drop anything other than established/related connections from the cloud server over the tunnel and make sure you get alerted if it does happen in case the cloud instance was compromised.

Of course you still have the weak point of the authentication with the front end in each local office, but you will have a slightly higher chance of being secure with auditing and keeping the end users aware of things like social engineering techniques, browsing websites, email/messaging links and attachments and phishing, enforcing strong passwords, etc.

But on to an even more interesting thought...

http://www.itworld.com/security/95398/can-you-trust-chinese-computer-equipment

According to this post, we might already be in trouble...

NCSS (I think) is narrowing his scope to align with the point my piece-- which was really about why cloud security is so hairy. The discussions about endpoint security and authentication are very important - no debate there.

Please for a second just ignore the title - imagine it said something like:

"We need to rethink cloud architectures to be secure."

What I'm saying is that this is an architectural problem brought on by multi-tenancy. Traditional securtiy technologies and practices have been designed to accommodate system architectures that have well-known physical connection points. The approach has been to surround those physical resources and create trusted zones. Virtualization-- as you all are well aware, better than I-- introduces complexities that remove visibility on those connection points.

Look at it this way...if all of a sudden you magically solved the endpoint security issues-- would the cloud problem be solved? No - not in a multi-tenant world.

You've secured the hen-house but the fox is inside having a field day.

NCSS, I dont think you are aware that encrypting the data in the cloud is just as useless as dispersing the data.  The more effective attacks are against authentication, and once a user has been wrongly authenticated, the data encryption is useless.