A Simple Truth about Cloud Security

I keep hearing that security is a fear factor for some organizations that are considering moving to the cloud. They worry that they’ll have to change their whole security approach in a highly virtualized environment. But I think those IT admins should see it as an opportunity, not a threat to their survival. Virtualization—and by extension, its big brother the cloud—doesn’t really change anything about the fundamental nature of security, identity, and access. You just have to go back to the basics. Of course, I do understand that proper security isn’t easy, but neither is anything worthwhile in life.

So let’s think about security in a virtualized environment. As I said, the fundamental nature of security, identity, and access doesn’t change simply because systems are virtualized. In fact, virtualization should make building a secure environment even more achievable, owing to things you get in Windows Server 2012 and Hyper-V, such as workload isolation, platform abstraction, and host independence. From a security perspective, these capabilities mean that, for example, you could put each application in its own VLAN zone, and the bare-metal hypervisor would help buffer guest operating systems from host-level intrusion.  And you can individually update each virtual machine (VM) with the latest patches or versions without disturbing the rest of the system. So, while the way you implement these things in a virtualized datacenter will be different from a more traditional physical layout, that doesn’t mean you should fear the change. Your systems will be just as secure as a physical environment—if not more secure— because the applications can’t endanger each other, the host can’t infect the guests, and all VMs are up to the latest patch level

Still, some in the industry believe that platform-wide security should be abstracted away from the objects it protects. They think you should treat your complex solution stack (virtualized environment, private cloud, or other) as if it were just a home office server: For securing all traffic, they advocate simply using a single VM with a firewall in front of it. This might be fine for a basic remote site with a file and print machine, but most datacenters that are targets for virtualization are a bit more difficult to characterize. Too simplistic an approach introduces problems as the environment gets larger, such as dealing with unique security and policy requirements for application and data compliance.

The truth, however, is that you need processes and core security capabilities for each virtual environment—or workload—you operate, just as you would in a traditional datacenter (i.e., multiple physical servers with dedicated workloads). The closer security is to the data and applications it protects the more effective it will be. This is because the level of insight that a security solution has into the particular needs of a workload or data set, such as rights management or application filtering, greatly influences how well it functions.

To illustrate how placing security closer to the data is more effective, take the example of a medium-sized business (~125 users / desktops) that has chosen to address increasing user demands through virtualization, deploying a smallish private cloud. Let’s also assume that they have a big enough server to handle the load, and they want to maximize hardware utilization. Hyper-V Server 2012 is running on the host, with multiple virtual machines including a domain controller, Exchange, SharePoint, SQL Server, System Center, Web, RDS, some custom and LOB applications, and even a couple of Linux instances; maybe a dozen total VMs. But …

Since this implementation is only one physical box, the company chose to deploy a basic firewall in front of it, plus Exchange-dedicated anti-virus, some domain-level policy, and no web security—just as if it were a simple small office server rather than a complex implementation on a server with multiple cores. If a virtualized implementation looks like a single-server duck and quacks like a duck, then it must be a duck, right?

The problem is … it’s a multiple-VM goose, not a duck, and before it gets cooked you need to look at it through a comprehensive IT lens when it comes to security essentials. Because this virtualized deployment is a self-contained and complete IT environment, it needs the same security, identity, and access infrastructure as any other multi-server solution. 

What does that mean? Just as with a physical datacenter, defense-in-depth dictates that workloads each be placed on their own dedicated server hardware. This approach helps make physical network segmentation, security policies, and so forth fairly straightforward to implement. You can deploy firewalls between sensitive zones, define access policies, and deploy network edge protection. These practices are well documented and understood for physical datacenters. But in virtualized and cloud environments, all the workloads can run together on one machine, with limited physical network infrastructure (unless there are multiple blades involved). Taking away the crunchy edges between standalone servers can make it appear much more difficult to build a secure deployment, so many administrators are tempted to rely on limited physical network security to protect the solution as a whole.

If you want a truly secure virtual deployment, your first step should be to look at your virtualized solution stack as if it were a regular old corporate datacenter. You still need to do things like map out client, application, and network infrastructure according to a secure deployment just like you used to in a physical deployment. Where (on which VMs) will you store sensitive data? How will you implement remote access? Will you have any public Internet facing connections for web publishing? If so, how will it interact securely with the rest of your infrastructure?  

A thorough understanding of your fundamental security needs (preferably before you deploy a highly virtualized environment or cloud) will help you avoid serious issues later on, such as data theft, system corruption, and malware. Then you can start defining policies and architectures to protect your environment. But do this before you worry about it all being virtualized on one physical machine (or cluster), so that you can more easily accommodate the unique needs of a totally shared infrastructure.

It may be that you need to use virtual appliances as firewalls between network segments. Physical routers and ACLs might be replaced by VLANs and IPsec / IPv6. There are other considerations, as well: 

• Now that every workload is on the same machine, you need to be aware of hacks or exploits that can overwhelm a single application, causing it to use up all available resources and choke out the other VMs. You can help avoid this by defining resource usage policies, monitoring / alerting, and other management techniques to throttle usage—System Center is great for that. While it is extremely unlikely that a single errant workload could actually crash the entire server, better safe than sorry.
• Any time you have access of some sort—which you kind of need for your users—you need to think about intrusion prevention and other server-level lock-downs. If, before virtualization, you had anti-malware on your Exchange, SharePoint, Web, and other services, why wouldn’t you have it now? Leaving it on one workload (say, Exchange) and assuming it’s good for all, simply because they share the same host—will lead you to a very dark place, indeed. It is certainly acceptable to have a dedicated IPS on the network edge, but if there were areas of the network—or certain sensitive hosts—that had local IPS, you should arm those virtual workloads the same way.
• It’s fine to have a single VM be the traffic clearinghouse as an added measure of protection, but note that it introduces a single point of failure for your entire IT infrastructure. Combining all security functionality in one place is tempting, but if you wouldn’t do it in your old network, don’t do it now.
• Secure the host itself if it isn’t running a bare-metal hypervisor. Disable all unnecessary services, run local A/V and IPS, etc. Do all the things you would for any public-facing server to prevent exploits that could fubar the one machine (or cluster) that everything in your business relies on.

You may be thinking that following physical infrastructure security guidelines is a lot of extra hassle for your virtualized environment, with too many repeated services that will be an unwanted drain on precious hardware resources. If so, you’re right. But it’s worth it. Consider it a safe-working-environment tax to be calculated alongside application needs when sizing your systems. Security still comes down to risk vs. reward:  Are you willing to forego the security burden in favor of more server capacity? If you are, just be aware of what you’re risking.