Security Manager's Journal: At this point, the cloud remains too leaky

Computerworld - What great timing! I had no sooner returned from the RSA Conference, where my focus was on cloud computing, than I was invited to a meeting to discuss our first venture into "the cloud."

The IT department has decided to contract with an infrastructure-as-a-service provider to host a portion of our development environment. If this trial is successful, some of our production environment could be next. Having read up on the subject in white papers and attended seminars at RSA, I felt informed enough to ask the questions that needed to be answered before I could feel comfortable about an initiative that was going to open new portals to our network and our data.

And there's no question that this could expose us to new dangers.

Our plan is to move our SAP development environment to the cloud. Our developers typically test apps with our actual production data. It's not a problem when they put our financial data on a test server in our own data center. It's another matter entirely when the server is far away and out of our control. In this case, in fact, our hosted servers will actually be located at a hosting provider's data center, so there are two degrees of separation.

The plan is to configure several virtual Linux and Windows servers on a shared VMware ESX Server. The cloud vendor wants us to set up a VPN tunnel. I'm not thrilled that we won't control the VPN termination point, and it doesn't help that the termination point is a Linux server running open-source VPN software.

Compounding my concerns, the vendor wants us to use a shared key for VPN authentication between the devices. I have countered that plan by mandating the use of certificates to handle authentication. I have also established firewall rules that restrict the servers at the server farm from accessing our network.

Making Things Easy

Next in my sights was the Web-based management application that our technicians must use. When you put this application side-by-side with our current data center access controls, the vulnerabilities of the Web app are enough to make a grown security manager cry.

Currently, a bad guy would have to know the physical location of our data center, obtain a badge to enter the building, procure yet another badge and somehow beat the biometric hand scan in order to enter the data center -- and then he'd have know exactly which racks contain the servers he's targeting. In contrast, the Web app asks only for a username and password, it's available via the Internet, and all customers use the same URL. The only thing a bad guy needs is something like a keystroke logger. And here's a clue to how much the vendor values security: It gives clients temporary passwords with no requirement to change them upon initial log-in, and it doesn't enforce the use of complex passwords.

I had other questions as well, and the answers did not inspire confidence. How would we know if an unauthorized, rogue or disgruntled employee manipulated our environment? "Umm, well, uh, we haven't really thought about that, but our offering is strictly for development environments."

OK, then, how about encryption? "Since we cater to development environments, we advise customers not to use sensitive production data in the development environment." And do any customers really create data out of thin air, or do they just take what already exists from production?

The bottom line is that we have a long way to go before we establish a trust relationship between the cloud network and our company's network, and there is still quite a bit of room for improvement in cloud security.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

Read more about security in Computerworld's Security Knowledge Center.