Often, the hybrid device decides which network to use transparently, based on network availability and connection speed. In most cases, the user doesn't care if he or she is connecting to email using the latest Outlook client in Vista or the Outlook Web Client in a browser running on Linux: What matters is that the mail is accessible.
While all of these options make working anywhere, anytime a reality, they also provide more opportunities for attacks through each of these new attack vectors. They also make management and security increasingly complex for corporate administrators. When devices are untethered from the corporate network, administrators must assume the underlying network is insecure, or at least untrustworthy. The devices themselves are also a cause for concern. Is the device owned by the corporation? If not, how can the enterprise guarantee configurations and patching, or even enforce appropriate usage policies? If the company has standardized specific remote access VPN clients (for example: Cisco Systems Inc.'s VPN client or Barracuda Networks Inc.'s SSL VPN agent), what happens if those specific vendor clients (or agents) are not available for all devices and platforms? Will those devices and platforms be allowed access only to restricted parts of the cloud, or will they be completely denied access to connect to the cloud at all?
One solution is to limit access to corporate resources, such as email, to specific services based on the security control level of the device. But as any administrator who's attempted to tell an executive he or she isn't allowed to access email from his or her new iPhone knows, this is often easier said than done. This is especially true if the policy to deny access is seen as standing in the way of corporate progress and innovation.
VPN client support (SSL or IPSec)
VPN in the cloud
Virtual private networks (VPNs) provide the ability to create a secure network connection across a public network through the use of encryption; thus, VPNs provide privacy and a level of trust. Before discussing the various trust issues associated with VPNs, it's necessary to note that the term itself has multiple implementations. 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.
The very nature of the network-to-network VPN presents several well-known security challenges. The ability to hack via the encrypted tunnel without fear of detection is a strong incentive for any would-be hacker. This model gives an attacker the ability to use many services on many hosts in order to gain access and control of cloud computing data. The network-to-network VPN provides network transparency and management that enables inspection of the traffic after the point of decryption, but it does not protect the data payload end-to-end.
Once any portion of the cloud is compromised, all other portions connected to that cloud via network-to-network VPN technology must be considered compromised. This is worse than the old "reverse Darwinism" problem that occurs when a network with strong security controls is connected to a network with weaker controls, such as through a VPN tunnel, and the more a secured network is exposed to vulnerabilities via the weaker one. Due to the nature of cloud computing architectures, customers of the cloud provider may not always be aware when portion(s) of the cloud network have been attached or opened to another, possibly less secure portion. This is the invisible reverse Darwinism problem.
The second type of VPN is the single-host-to-server VPN, or point-to-point VPN. This VPN provides the encrypted tunnel from client to host for multiple services. Because this connection, much like the network-to-network connection, takes place at layer 3 (or lower), many of the same security issues found in the network-to-network VPN exist here. Fortunately, most cloud computing service providers elect to use the service-to-host model through SSH, SSL or another dedicated service.
The single service-to-host model is not without flaws. However, by limiting the size of the access area, the overall security footprint decreases, thereby making monitoring and securing it more manageable. The service-to-host model offers the opportunity to monitor the entire session. The cloud service provider has the ability to insert logging software, as well as security controls, into the processing.
Naturally, the security controls and logging are dependent on the cloud computing service provider's security model. Since logging and event monitoring are required components of most organizations' compliance programs, it's recommended that customers clarify up-front with the provider which processes and events will be monitored, logged and reported. If the provider cannot provide the appropriate information for compliance reporting needs, the customer should look elsewhere.
Summary
The cloud computing infrastructure is comprised of hosts, servers and network transports. The multiplicity of devices and transports and the abstraction of management and trust require enterprises to layer security throughout to ensure data and connections are properly protected.
The use of single-service VPN access to the cloud is considered the most secure and can decrease vulnerability exposure to both the client and the server. However, the client must still remain aware of the cloud server(s) architecture and must extend as much of his security model into the cloud as possible.
[IMAGE]
[IMAGE]CLOUD COMPUTING SECURITY MODEL OVERVIEW
[IMAGE] What is cloud computing?
[IMAGE] Introduction to cloud computing security
[IMAGE] Secure devices that connect to the cloud
[IMAGE] Cloud computing security threats
About the authors:
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.
Char Sample is a research scientist at BBN Technologies specializing in network security and integration issues.
