Cloud computing allows an organization to reduce its risks by having to secure fewer resources. The tradeoff is that cloud creates more attack vectors. Don’t let VMs trip you up.
The software-defined nature of VMs makes them easy to manage, provision, set up and tear down. What’s not always so simple is how to address virtual machine security in the cloud.
The role of VMs in the cloud
A cloud service provider owns the physical hardware, software, networks and other supporting components necessary to serve its customers. By clustering hardware, the provider delivers a dynamic, software-defined environment capable of supporting the changing needs of a customer — without the customer needing to purchase and maintain physical equipment.
Key to this just-in-time, as-needed delivery of cloud services is the VM. A physical machine runs a single OS, creating a 1-to-1 relationship, but many VMs can exist on a single physical machine, resulting in a many-to-1 environment. This expansion is made possible by the hypervisor, also known as the virtual machine monitor (VMM).
The VMM is responsible for creating and managing VMs and shared resources, such as memory and disk space, as well as roles and permissions. This naturally makes the VMM a significant security target.
What is virtualized security, how does it work or fail?
Security for VMs relies on software, such as firewalls, intrusion detection systems and identity access management tools. This is much like in the physical environment, but with one key difference: the location of the security products. In the physical environment, dedicated hosts can (but don’t always) run security software. These hosts, historically referred to as bastion hosts, are secured via physical and logical controls.
Virtual security, in contrast, relies strictly on instantiations of logical constructs. Physical security in this environment is whatever the vendor has deployed. Logical security relies on the VM owner, as determined by the service-level agreement (SLA). Thus, owners that routinely update and patch their software tend to do better than those who do not. Should the VMM owner fall behind on updates, the VM owner’s best practices are of limited value.
This lack of separation between physical and logical environments creates the potential for transitive security issues, where a compromised physical environment can result in multiple compromised VMs. The attack paths requiring security in the VM environment are both in the actual VM and VMMs controlled and shared resources. An example of this problem is when lack of physical separation creates an environment where a compromised block of memory in one area becomes a problem for all VMs.
Despite the VMM-VM vulnerabilities, the use of outdated packages remains a common vulnerability to applications running in the VM. This problem highlights the common security problem of failing to maintain and keep the software current. This results in a compromised VM and possibly other VMs in the environment, assuming they all fit the same profile.
Importance of VM security
To understand VM security in the cloud, consider these important concepts:
A reduced hardware footprint lessens the resources spent on the physical environment in general and physical security specifically. The owner of the physical devices implements physical security controls. This might be done at the insistence of the tenant or the owner. In some cases, savvy tenants can improve the physical requirements via the SLA for a lower cost than if they did the maintenance themselves.
The natural separation of the VMs results in logical segmentation. While not as secure as physical segmentation, logical segmentation is a viable and widely used practice. It supports the ability to dynamically segment VMs by users, IP addresses, services or projects. These dynamic segments can exist for as long as needed and then quickly go away.
The cost of hardware and software is obviously greater than the cost of leasing software as needed, but a further consideration is the total cost of ownership (TCO). TCO includes the cost of physical space, energy to maintain the environment, qualified personnel and necessary patches and updates. Depending on the SLA between the client and provider, the client might or might not be responsible for VM maintenance, but the service provider is always responsible for the security of the VMM.
VM security challenges
The security challenges for VMs are in some cases the same ones experienced on physical machines. This is largely due to the nature of data-driven attacks on applications, libraries and OSes. The difference is that defense against lower-level attacks on firmware and VMMs would be the provider’s responsibility. While a vendor has plenty of incentive to maintain security on the VMM and other components, zero-day attacks occur, and the resulting loss can affect any tenant.
There are three significant security challenges with VMs:
Shared-space problem. The VMM is a rich target because, once compromised, all VMs are vulnerable. Because the VMM contains shared libraries, memory and provisioning and management software, attackers can reach multiple environments and cover their activity.
Standardized VM configurations. The use of automated processes enables configuration efficiencies. The software that manages the configurations will typically rely on either a passed parameter or information gained from querying the VM. While this is not a standalone vulnerability, the real problem is the reuse of the script. Once a script is compromised, a problem easily replicates across VMs. Managed extended threat detection and response can be useful in countering this.
Missed patches and updates. This problem is not unlike the user who uses the same password for multiple servers; once the first instance is discovered, the remaining instances are ready to be exploited. Be alert to patch updates as they are released.
Best practices to secure VMs in the cloud
Since security in the cloud cannot be assured, the right approach is to mitigate risk. With VMs, that is accomplished by maintaining up-to-date versions of the software those machines use, particularly the OSes.
In addition to detailing the metrics for expected quality of service, a tightly written SLA should include specific language about the touch points between the service provider and network provider as well as those between the provider and customer. It is generally better for security to overlap in those places than for there to be gaps, but the overlap should be minimized. Also, pay attention to data ownership and storage — especially when your cloud provider has a global presence. Peering agreements between points of presence take on added importance because infrastructure components cross jurisdictional boundaries; the ability to specify in the SLA that data and metadata never cross certain boundaries is important.
Segmentation of the VMs via software-defined networks enables isolation within the virtual environment. Segmentation can be by group, addresses, services or any other method the owner chooses. Additionally, make good use of zero-trust practices.
Content Courtesy – Tech Target