Q&A: Cloud Security

Emily Holbrook


August 1, 2012

The trend of businesses turning to the cloud for server space has become more popular as companies look for an easy and economical way to store data. Even the U.S. government is getting on board. Just last month it was announced that the Department of Defense plans to use cloud computing for data management.

But how can you ensure that your data is secure in a virtual environment that is beyond your control? For more insight on this critical security issue, we spoke with Carson Sweet, CEO of CloudPassage, a cloud security service provider.

RM: As more companies turn to the cloud, the threats to information security increase. How are companies handling this?

Carson Sweet: The interesting thing that people don't get when they use cloud servers is they don't realize their own responsibilities. There's an education process. When people use cloud servers, there's a shared responsibility. Amazon EC2 [Amazon-owned cloud servers] will take care of part of the security. The owner of the virtual machine has to do the rest.

The analogy I use is renting an apartment. A landlord will say, "I'll take care of the security of the common areas, the front door, the elevators and all that stuff." But once they give you the key to the front door, you're on your own. They can't take [on] the risk for what goes on inside. It's the same thing with cloud servers.

They are rented just like an apartment. So a lot of people think that the cloud provider is going to do everything, but the cloud provider, in fact, doesn't. If the cloud provider is going to do everything, that's more like a hotel.

That is where things are going; there is a shared responsibility model, and security technologies, auditors and the whole risk management world is moving to try to deal with an issue where some of the controls are with the provider and some of the controls are with the actual owner of the system. It's going to be a shift in IT, a shift in thinking, a shift in the way that security is achieved.

RM: Why don't traditional security models translate to the cloud?

Sweet: Part of it is that shared responsibility model. Typically the way you handle security is walls and moats. So you've got all of your servers inside your data center, and you build a nice big firewall environment around it, intrusion detection and so forth to create this perimeter environment. In order to create a perimeter like that, you need to be able to control the IP addressing and the hardware configuration. You can't do that in a cloud. So when you use these cloud-server environments, there's no hardware involved. Basically, everything we've come to rely on from a security perspective in a traditional data center is just gone. You can't use it that way anymore.

RM: Are private clouds a safer option?

Sweet: It's a little bit easier of a situation. The difference between a private cloud and a traditional private data center is that things in the private cloud move faster. So in that environment you've got a cloud within a perimeter. You've got that initial perimeter security, which is great. But where things get a little hairy is that you're creating servers very fast. You used to have a six-week lead time.

For example, if you needed a server, you called up IT and you told them. They would order it, ship it, put it in a rack, turn it on. And that took weeks. During this time there was a lot of opportunity to really get things in order. Now, if a private cloud wants a server, they just click a button and it's there. So that makes for a very dynamic environment--it's wild.

The other thing that's risky from a private cloud perspective is that they do not stay private for very long. People are attracted very quickly when they realize the benefits and they start to see certain articles written by companies like eBay, who say "the way to do this is to take your excess need and put it out into EC2." So you've got your private cloud and then you burst out [with excess storage needs] and use temporary capacity, so you don't have to pay for that high watermark. That, all of a sudden, makes that private cloud into a hybrid cloud. And hybrid clouds are where everything is headed.

RM: What are the benefits of hybrid clouds?

Sweet: Hybrid clouds are like if you have a four-bedroom house and you need more room, you have a deal set up with the hotel down the street for more space. People will actually take servers and plug them into a public cloud for temporary workload. Good examples would be tax season, when the load goes through the roof. Instead of buying more servers, they can just turn on a bunch of web servers on Amazon.

Another good example is retail during the holidays. The capacity needs go way up. Social media is another good example. We see the server count of social media companies go up and down dramatically even within a week because on weekends more people are tweeting and more people are checking in so they need more servers. Usually on Thursdays the server count starts to grow and it will shrink back down on Mondays.

The flexibility with that is really attractive. You can either buy all the capacity you need and only use a third of it most of the time or you can use a temporary capacity in a public cloud like EC2 or Rackspace. But you have to do it safely.

RM: Will there ever be a universal set of compliance regulations or authenticity guidelines for the cloud?

Sweet: Probably not universal, but that's one of the things the Cloud Security Alliance (CSA) is trying to do. The CSA is putting together standards that map together other existing standards. The health-care industry is always going to have their HIPAA stuff, the financial industry is always going to have their FFIEC stuff, the federal government is always going to have their FISMA stuff. They will never unify but there will be kind of a layer to link them together.
Emily Holbrook is the founder of Red Label Writing, LLC, a writing, editing and content strategy firm catering to insurance and risk management businesses and publications, and a former editor of Risk Management.