Blog

Extending the LAN, good security sense or delaying the inevitable?

Been hearing a lot of buzz about securing public space by extending the LAN into the cloud. Projects like OpenFlow as well as similar commercial products are gaining momentum, especially in the LE space. I can see why this has appeal with the legacy security crowd, as it helps to mold public IaaS into a network centric perspective for applying security. While I think this idea has possibilities as a transitional solution, I’m just not sure we’ll be willing to live with the limitation it imposes over the long haul.

If you are unfamiliar with the concept, check out Figure 1.  VMs located in public space are tied back to the corporate network via a VPN. Remote servers will only accept connections via the VPN, which terminates within the corporate network. This permits the corporate perimeter to control traffic flow to and from the server. Network based risk mitigation remains relevant, and we can go back to doing business as usual.

There are a number of issues with this deployment model. To start, this model increases the load on the corporate Internet link, as well as the perimeter infrastructure. So corporate Internet link speed becomes a monkey wrench in how large and quickly we can grow within public space, not just internally. Further, we have introduced a large amount of latency. We’ve effectively doubled the link distance and added encryption/decryption overhead. This could prohibit the use of any time sensitive applications such as voice or video. The other problem with this layout is that it negates all of the networking benefits of outsourcing the workload. We can still leverage the provider’s compute and storage capability, but by running everything through a VPN tube (maybe Senator Stevens was a visionary 🙂 we have negated load balancing, off-site cloning or geolocation services. Of course we’ll still have to pay for this flexibility, as many providers include them in their base service offering, we’ll just be unable to leverage them.

Finally, this solution assumes we can somehow wrap a force field around the VM in public space.  Unfortunately, this is not the case. The VPN ports are still exposed to intrusion attempts and the hypervisor still provides a potential software conduit. So despite attempts to leverage network security solutions on the LAN, prudent risk mitigation will still require that the VM itself be properly secured. We’ve jumped through hoops to make network based security still relevant, but at the end of the day we still must fall back on host based security.

Figure 2 shows how we would prefer connectivity flow.  The model permits us to leverage a provider’s networking assets along with compute and storage. We no longer have a single point of network failure, and the corporate Internet link is no longer a performance gate. Time sensitive applications can be deployed such that latency is no longer an issue.

Of course this type of connectivity raises security issues. We can no longer rely on network based security solutions to protect virtual machines. As mentioned in an earlier post, we need to move risk mitigation closer to the asset we wish to protect. Also mentioned in an earlier post, this is the niche CloudPassage fills with the Halo product line. 🙂

More to come,
Chris

Related Posts