As most security professionals are probably fully aware by now, the process of securely deploying virtualization technologies into a production environment requires serious effort. This is true from inception throughout the rollout process.
Specifically, the planning phase of a virtualization initiative requires the security team to be involved in a number of critical engineering tasks: locking down hypervisors, hardening guest platforms and evaluating current security controls for applicability in the new virtual ecosystem. Once planning is complete and actual rollout begins, a new set of operation issues emerges: virtual machine (VM) sprawl, long-term latent (i.e., "mothballed") images and logistical challenges associated with keeping a reliable and thorough inventory of images, to name a few.
Because of the amount of effort to get these kinks ironed out, the temptation can sometimes be to scale back efforts from the security team once these early phases are complete. However, this attitude can be dangerous because there are some issues that emerge only as the environment matures. It's important that security teams be aware of these complications and keep an eye open for them because they can impact the security of the environment and turn into virtualization security issues.
Virtualization security issues: Expansion of virtual images
The post-virtualization phase comes about once the initial bootstrapping of a virtual initiative is complete and the environment is operationalized into a "steady state." But the term steady state is deceptive because it is really anything but; there's natural expansion of the footprint through growth and other factors.
Some routine growth is to be expected as new physical platforms are virtualized and brought under management, and through the routine generation of clones and snapshots. But growth can also occur when disparate environments are consolidated. For example, consider two different business units (each with its own virtual footprint) coming together into one larger environment or similarly, two different virtual data centers merging into one larger environment. These situations are more likely to occur than you might expect -- and they greatly compound the complexity of the environment.
But expansion of virtual images is not the only source of added complexity. The proliferation of virtualization products can also play a role. Keep in mind that there are quite a few different types of virtualization: server virtualization, application virtualization, VDI, storage, and so on -- with multiple vendors and community-supported initiatives supporting each category. It's not unusual for the same organization to use dozens of different virtualization products from a wide swath of different vendors. Even within the same vendor's product portfolio, there are different "flavors" of products with different legacy versions that might be supported. Each particular instance of the same product can have different security profiles; for example, you might have a "locked down" hypervisor environment for high-security applications and a lower assurance platform for development and quality assurance (QA).
All this complexity makes the virtualization environment harder to keep secured. It also makes inventorying more challenging due to proliferation of images (for example, the same image might be cloned out of one product, re-imported into another, with both clones being snapshotted multiple times in parallel.)
It also can have an impact on the security of those images themselves. For guest OS instances, shops usually maintain a "golden image" that is the basis for virtualized hosts. This image includes both required integration software specific to the hypervisor (e.g., VMWare Tools), but it also usually includes security parameters and a hardened configuration. Proliferation of virtualization products means multiple different images need to be maintained while at the same time proliferation of virtual appliances, each with their own particular configuration, makes the situation worse.
Virtualization security issues: Monitor for sprawl, administrative access
As the virtual environment moves into a more operational focus and expands, the security organization's strategies need to shift. Even from the get-go of a virtual initiative, sprawl is a huge concern. But monitoring for and weeding out sprawl shouldn't stop just because the environment has been running along smoothly for a year or two. It goes without saying that getting the environment to the operational steady state requires disciplined provisioning to control sprawl. But it is important to keep scanning and discovery controls running, too, as the environment is expanded, and to stay alert for these issues, because they are almost certain to resurface as time goes by.
In addition, take stock of administrative access and build out tools to monitor for proliferation of administrative credentials. Just as in a traditional IT environment, controlling administrative credentials is imperative for a virtual environment. As time goes by, administrative credentials tend to collect; you should be keeping tabs on this to make sure that administrative rights are reasonable and appropriate. Last, keep an eye open for situations where relocation of images breaks your security model. This can happen when virtual images are "teleported" to locations that are undesirable from a security standpoint -- for example, when someone vMotions the billing server to a QA lab (yes, this happens). This extends to user-oriented scenarios as well. For instance, give employees a virtual image to run as their corporate managed endpoint (i.e., to support BYOD) and it's only a matter of time before someone gets the great idea to import that image into a user-accessible service like Amazon EC2. That could lead to a compliance violation for organizations with requirements for retaining data within predefined boundaries.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.