Virtual servers are a must in the enterprise data center, but they create their own special security challenges–including consistency of security across virtual machines, vulnerabilities in the hypervisor, and remote access problems. Here are three key issues and how to resolve them.
1. Virtual servers and secure multi-tenancy
Early in cloud evolution, there was a good deal of concern about secure multi-tenancy, with different customers sharing any given server. Stateless servers resolved the issue, once the virtual instance memory was cleared prior to loading a new instance and Central Processing Unit (CPU) features prevented cross-reading of memory by malware instances.
The problem may be back with us, insofar as new instances for analytics and other Input/Output (IO)-intensive use cases are offered with local Solid State Drive (SSD) storage directly attached to the virtualized server. These servers are very much stateful, with potentially terabytes of unencrypted instance storage.
Users need to be comfortable that data is erased from the storage whenever they close the instance. This isn’t as easy as it sounds, because SSD devices use over-provisioning to extend write wear life. Just overwriting the blocks presented as the volume won’t erase data in the over-provisioned portion. In fact, writing blank sectors to the drive results in writes to the over-provisioned space first, so that some data from normal operations will remain in the drive, and accessible, if only a single erase cycle is done.
The need to erase data reduces the life of the drive substantially, but simpler options of just erasing the file system, or deleting the blocks and letting the TRIM operation handle the issue leaves data dangerously exposed. (Editor’s note: TRIM is not an acronym, although it is commonly written in all capital letters. A TRIM command allows an operating system to inform an SSD which blocks of data are no longer considered in use and can be wiped interally.)
With each Cloud Service Provider (CSP) building its own orchestration suite, it’s likely that solutions will differ. It’s critical to find out if, and how, the CSP handles this issue. Note that it also applies to Hard Disk Drive (HDD) instance storage, and potentially to image caching approaches. Downstream, we can expect Non-Volatile Dual In-Line Memory Module (NVDIMM) and Hybrid Memory Cube (HMC) memory to extend the concept of instance storage, so there is an extended exposure.
Agent-less security at the hypervisor level is a must. This protects both active and dormant instances, while establishing a strong security process outside of user control.
2. Virtual servers and mashups
The nature of today’s cloud is much more complex than a typical in-house operation. Services may reside at different CSPs, or be in transition from one to another. The rapid expansion of Software-as-a-Service (SaaS), along with all the other Everything-as-a-Service (XaaS) approaches, creates both an opportunity to be agile, and a risk of security failure. (Editor’s note: Everything-as-a-Service encompasses such offerings as Infrastructure-as-a-Service, Platform-as-a-Service and a variety of other cloud-based methods of delivering IT. Collectively, these are commonly referred to as XaaS.)
Policies on access, encryption retention and erasure have to trickle down through these, and must do so in the face of departmental control on many functions as opposed to central authority. This has to be done under the umbrella of laws such as Sarbanes-Oxley and the Health Insurance Portability and Accountability Act (HIPAA).
Realistically, there will be cases where trickle down is not fully compliant to policies. This becomes a judgment call, since there may be an acceptable alternate approach or it may be possible to limit exposure by selecting the datasets the non-compliant service can access.
3. Virtual servers and data-level security
The cloud approach is forcing us to be more data-centric. Data is no longer protected by physical location. As the cloud grows, it’s quite conceivable that a job-stream could start in New York and end in China, for instance.
Both data in transit and data at rest need protection. It goes without saying that anything useful sent over the Wide-Area Network (WAN) should be encrypted. But what about the 60% of traffic that is experienced inter-server in today’s cloud? A “man-in-the-middle” attack hiding in cloud instances could expose a lot of information. Round-trip encryption is really needed for all networked data, in the sense that server-to-server and server-to-storage communications are always encrypted.
Since data at rest is housed on shared storage appliances, with potentially fallible or hackable software, the stored information has to be encrypted. Moreover, this should not be a CSP-provided “encrypted storage” simply because it’s a strong principle that the owner of the data should be the owner of the encryption keys.
Ideally, the topology should be that the virtualized Network Interface Card (NIC) has encryption assist logic for performance, and that the storage appliance store cypher-text not plaintext data. With this approach, data is exposed only within the server. We are not at this level of sophistication yet, but Intel and others are building platforms to address this issue.
In the end, all of these problems are also real issues in the evolving in-house cloud or datacenter, and have to be addressed fully for those cases, too. The cloud brings such scale and focus to these problems that robust solutions arrive much more quickly than in the past. It may be that the cloud is, and will continue to be, more secure than the non-cloud IT world.