What We’re Reading, Week of 6/22

Posted: June 25, 2009 in Highlights

Cloud computing security: Choosing a VPN type to connect to the cloud
Friend of NCP, Diana Kelley, analyst at SecurityCurve is writing a series on cloud computing security. In this 1st part series, Diana drills down and discusses the specifics regarding devices that connect to the cloud, and how VPNs affect cloud security. The article takes point-to-point into perspective, as opposed to whether or not SSL or IPSec is best suited – there are varied uses for each within Kelley’s article. Well worth a read and it begs the bigger questions of, “is VPN really a factor for applications living in a cloud, or is securing the applications themselves really the issue”? For example,

“VPN types include network-to-network, multiple service host-server, to single-service host-server. Each of these implementations can be used in a cloud computing environment, and each has security strengths and weaknesses. The oldest VPN technology is the network-to-network VPN. This architecture has the greatest risk associated with it, due in part to the number of hosts involved. While this architecture would not likely be used in the client-to-cloud connection, it could be used within the cloud, especially with server farms or mashups.”

What are your thoughts on cloud computing security?

  1. I think VPN as it is presently conceived would be quite hard with a true cloud. I am assuming that you are not using “Cloud” in the generic marketing sense but in the sense of particular API’s for applications existing in a variable resource environment.

    I’m also not really sure how necessary VPN is in such an environment. The point of VPN is to connect from an insecure location, where messages might be intercepted, to a secure location and to have the remote point participate in the intranet at the host site. The facilities providing the cloud resources would need the VPN endpoint and the knowledge to find the correct resource for a VPN connection. That would surely add cost. Finally, in cloud computing, you don’t know what facility the server might actually be in. Remember, it is a cloud, not a facility … so what is the end point?

    The computers in a cloud are not workstations, they are servers. They also are not quite the same as normal servers either, with special adaptations for cloud participation. For example: they have no file system in the usual sense. There may be no “GUI” at all. So what good purpose in having these machines ad-hoc in an intranet? Also, cloud’s would be communicated with from workstations in an intranet that is already secure and the facilities in which cloud servers exist are certainly secure. So, if you postulate message interception, it would be intercepting high performance OC links. At that point, a major government is intercepting the messages, not simple hackers.

    For updating the applications in a Cloud, for communicating with its databases, secure sockets really should work well.

  2. Yinal Ozkan says:

    There are several questions regarding the necessity of VPNs in the cloud.

    I think the first step is to clear the concept of cloud. Currently the word “cloud” is used interchangeably for TelCo service provider transport clouds (Network Clouds) (e.g.MPLS) and Cloud computing web services that provide re-sizable compute capacity as a cloud (like Amazon EC2).. We can also define private service providers like SaaS providers, managed service providers MSPs) as cloud/utility providers (like force.com from salesforce.com, webroot SaaS). Here are some articles defining cloud and transport options.


    When the necessity of VPNs in the clouds are analyzed, it is obvious that encryption is indeed one of the key pillars of modern information security. And VPNs do provide confidentiality and integrity for data at transit. When cloud networks do transport the data they should provide integrity and confidentiality of data. That being said this does not have to be at layer 3 (IPSEC) or layer 6 (SSL). So focusing on an IPSEC client does not help to address the issue. Confidentiality and integrity services can also be provided via applications themselves. When data is critical you may certainly encrypt data at application layer. (e.g. rights management solutions)

    Here is the high level satus for VPNs in the cloud

    1- TelCo Network Clouds (Service Provider) – This is the most interesting part. TelCos claim that their shared infrastructure and MPLS VPNs are secure. This is questionable (see article below) but the answer depends on the security needed.
    If service provider cloud is not trusted enough you always encrypt at another layer (usually with the application).I personally believe that cloud service provider (TelCos) must be subject to heavier inspection when they are transporting almost all of the intersite traffic. Here are some articles discussing the issue


    I also do not understand why TelCos are exempt from security regulations. (PCI is a good example) TelCos (and their admins, applications, helpdesk people, servers, cable guys…) do have access to almost all interoffice data traffic when MPLS type of TelCo backbone is used. And when the MPLS cloud is compromised, all clear text (yes even the tunneled ones) will be compromised. Real encryption is rarely used. TelCos have been promoting themselves as secure service providers while promoting layered tunnels as segmentation, but I believe they must seal these claims with 3rd party certifications and allowing encryption friendly (where keys are held by the data custodians) clouds.

    2- Cloud Computing providers: These providers addressed encryption at their inception thanks to their security aware generation. Before encryption there are several other questions. Here is my post on generic cloud computing security issues: http://security.24kasim.org/2009/02/cloud-computing-security.html

    3- SaaS providers. SSL looks like the king at these providers. Segregation of customer data, and customer driven/controlled encryption for data at rest and data at transit is required. For data at transit, SSL is secure enough when proper authentication/cert management is provided.

    I am still following the following basic principles when I evaluate a platform. Regardless of the nature of technology, all platforms (clouds and others) should answer properly to following areas of information security:
    1- Authentication
    2- Authorization
    3- Confidentiality
    4- Integrity
    5- Non-Repudiation

    – yinal

  3. I’d’ve liked to read the article, but having to register to do so stopped me from doing this. I’m a bit confused though… my EC2 servers *DO* have VPNs, because I created them – first thing I do when building a new AMI. I have a secure network and less open ports to be hacked, my servers would need to be hacked (over any protocol that’s not web facing!) from here… and you don’t know where I am!

    I would like to make a quick meta comment though:

    @Geoff: The purpose of a VPN is to provide a secure connection between two points, which is slightly different from your (road warrior like) definition, and VPNs then make more sense: for example if you’re delivering new content to your website over ftp using a VPN between your office and your cloud server(s), then you’re safe – do it direct and you’re publishing credentials to anyone who’s listening!

    Just my $0.02, Steve

  4. Javed Ikbal says:

    The authors made a mountain out of a molehill. Yes, clouds don’t have VPNs, AV scanners, and all that. It is like saying if you go mountain climbing, there will be no TV. Again, yes, and so what? Mountain climbing is not for everyone, and neither is the cloud/IaaS.

    On the cloud, things need to be done differently. For people on Unix (and windows as well, if they wish), ssh can tunnel lots of protocols, providing the cloud customer a free/lightweight VPN. For people who want more, there is OpenVPN ALS/Adita or something similar. For cloud infrastructures that can be managed over a web interface, that IS the VPN. (the authors do touch on SSH and SSL, but I failed to understand the point they were trying to make)

    What the authors are really saying is, there is no commercially manufactured appliance with a GUI that can sit in front of your cloud servers. If that “buyer beware” message was the objective of the article, then all is good. But to me the article came across as more FUD (fear/uncertainty/doubt)

    To answer your question–this would be an integral part of the risk analysis of an outsourcing decision (which the cloud really is)–it is not too far down the chain.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s