Virtualization and Cloud Security: Back to Basics

Every time I talk virtualization and cloud security, I am surprised by the number of people who do not follow the basics. The basics have been around since 2004. The funny thing is, I also see the basics misquoted all the time. People try to interject their language into something already simple, yet by doing so, they limit the overall idea behind the basics. What are these basics I am talking about? The recent Virtualization and Cloud Security Podcast went back to basics to cover the basics in detail. You can find the podcast on iTunes and Talkshoe. Here is a rundown of getting back to basics.

Virtualization and cloud security basics started when a little-known engineer at Digital Equipment Corporation was talking to his customers about the need to place a firewall in front of the management constructs within each hypervisor. Yes, that engineer was myself, aka Texiwill. Things have since expanded to many different aspects of security. Let us get back to basics together:

  • Improve monitoring so that you know who did what, when, where, and how. In essence, you need a security operations center that looks at activity within your virtual environment. This operations center will help with security as well as operational issues. The operations center should track users as well as actions to users. Lastly, the operations center should alert when disallowed things are done, such as actions taking place as the administrator and root users, or when new virtual switches come into being, or promiscuous mode is allowed within those virtual switch constructs. Improving monitoring and alerting is the most basic thing anyone can do to improve the overall security of a virtual or cloud environment. Get a handle on what is happening in as much detail as possible.
  • Never use the administrator or root users by your management tools. When you join a new management tool to your management constructs, give it a unique username. This way, you will be able to distinguish users from tools and to tell who did what. Administrator and root users should only be used in break-glass situations by humans, not machines.
  • Protect the management network of any hypervisor cluster, usually by placing the management network behind a firewall and enabling multifactor authentication. The management network contains anything that directly speaks with the hypervisor management construct or the management tool itself. In the world of VMware, this is anything that talks directly to ESXi’s management construct and directly to vCenter. This includes the VMware management tools found within vRealize Suite and NSX. For the world of KVM, protect anything that talks to Dom0 and oVirt. In the world of Hyper-V, it would be anything talking to the Hyper-V server and System Center Virtual Machine Manager, and for Xen it would be Dom0 and XenConsole. In the world of cloud, this is the cloud management portal. This basic rule is just to protect the management constructs; it is not to protect the workloads.
  • Protect your storage (VSAN, VSA, iSCSI, NFS, and Fibre Channel), live migration (or vMotion), fault tolerance, and backup networks. Many of these networks transfer data in clear text and now travel over entire data-center networks instead of private networks.
  • If you use VLANs as a segmentation tool, please be aware that VLANs’ fundamental purpose is to improve performance of switches, not to improve security. Switches are still under attack, so you need compensating controls to ensure that the configuration of your switch is not changed and to ensure that nothing plugs into a switch that shouldn’t be there. For physical switches, that is usually the case, but for virtual switches, that is not the case. Improve your monitoring for network security into the virtual switch realm.
  • Change your mindset. Stop thinking about virtualization as a single node; think of it as a cluster of nodes with interconnects between the nodes. Even the smallest of the small have minimally a two- to three-node cluster, while the largest can have hundreds, if not thousands, of nodes. Virtualization security transcends the single node, single system concept.
  • Take the time to get educated and to educate your security and compliance folks. We have said in the past that the virtualization and cloud administrator needs to lead the charge, to help educate folks. This is far easier today than it has ever been with vBrownBag, The Great vSwitch Debate, YouTube, my own books, and other web-based training resources.

None of these actions cost any money to implement; they do, however, take time. Some even take some planning. Those plans may show you need more hardware or software to implement these items adequately. This is not a debate about using VLANs or not; it is about considering things first without technologies, then adding the technologies you need to secure your environment. The simplest way to go back to basics is with monitoring. Use monitoring to guide you down the other steps, to improve your architecture, and ultimately to secure your environment.

Have a listen to the podcast and let us know your thoughts!

Posted in SecurityTagged , , ,