Translation NIST SP800-125. Complete Virtualization Technology Protection Guide

Against the background of the general tendency of today's IT industry towards virtualized infrastructure and cloud computing, enterprises are facing an acute question of the security of such a transition. The main reasons for some uncertainty in this matter for Russian IT and security specialists are a little experience working with these technologies and, most importantly, the lack of guidance documents and standards of authorized government bodies.

I’ll make a reservation right away: the Russian standard is being developed. It will be called “Information Security. Information security requirements in information systems built using virtualization technology. General Provisions. " A public discussion of the first edition of this national standard is planned to be held from May to June 2013. It is clear that there is clearly no reason to wait for its approval in the coming year. In this regard, foreign recommendations are especially important, where the experience of implementing virtualization solutions is much wider.

The NIST SP 800-125 document contains the most general recommendations on the basis of which organizations can and should develop their security policies.
Due to the cumbersome nature of the document for one post, I will provide here only general definitions from the “introduction” and the section “Overview of Virtualization Security”. For those who wish, a link to the full version in docx format.
There are a lot of letters under the cut.

1. Introduction

Virtualization - simulating software (software) and / or hardware on top of which other software works. This simulated environment is called a virtual machine (VM). There are many forms of virtualization that differ primarily in computational architecture. This work focuses on a form of virtualization known as full virtualization. With full virtualization, one OS or more and the applications that they contain are run on top of virtual hardware. Each OS instance and its applications running in a separate VM is called a guest operating system . Host guest OSs are managed by the hypervisor, which controls the flow of commands between guest OSs and physical hardware such as a CPU, disk storage, memory, and network adapters. The hypervisor can share system resources and isolate guest OSs so that everyone has access only to their own resources, and possibly also access to shared resources, such as files on the host OS. Some hypervisors run on top of another OS called the host operating system or host OS .

There are two forms of implementing full virtualization. The figure compares their generalized architecture.

In virtualization "on hardware"(bare metal), also known as native or native (native) virtualization, the hypervisor runs directly on the equipment used without a host OS. In another form, full virtualization known as placed or is hosted (hosted) virtualization hypervisor runs on top of the host OS;

2 Virtualization Security Overview

The transfer of computing resources to a virtualized environment, in fact, has a negligible effect on the vulnerability of resources (on risks). Virtualization can mitigate the consequences of a successful attack, however, virtualization can also provide additional attack vectors, which will generally increase the likelihood of such a successful attack. Many virtualization features offer both security benefits and weaknesses.
This section describes the security implications of using virtualization. Section 2.1 discusses the isolation of guest OS from each other, the underlying hypervisor, and the host OS. Section 2.2 explains the goals and mechanisms for monitoring guest OSs. Section 2.3 discusses image and snapshot management.

2.1 Isolating Guest OS

The hypervisor is responsible for allocating physical resources (CPU, memory, storage) by the guest OS. He shares these resources, so that each guest OS can only access its resources and cannot encroach on the resources of other OSs or any other resources not involved in virtualization. This prevents unauthorized access to resources, and also helps prevent the spread of malware from one guest OS to another by means of infecting the guest OS files or placing malicious code in the memory area of ​​the guest OS. In addition, resource sharing can also reduce the Denial of Service (DoS) threat caused by the excessive consumption of resources by different guest OSs over the same hypervisor.

Resources can be divided physically or logically. During physical partitioning, the hypervisor assigns separate physical resources to each guest OS, such as hard disk partitions, disk drivers, network cards. Logical separation can represent the resources of one host or several as a pool of resources of one security category, which allows multiple guest OSs to share the same physical resources (for example, processors) through the mediation of a hypervisor. Physical separation imposes strict restrictions on the resources of each guest OS, and the unused resources of one guest OS cannot be used by another. However, the physical separation of resources provides more reliable protection and higher performance than logical.

Resource sharing is an important component of guest OS isolation. Isolation also includes restricting guest OS communications and access that each guest OS has to another, to the hypervisor and host OS (if any). Theoretically, hypervisors can provide a level of logical isolation comparable to physical, taking part in all communications, having full control over each guest OS. If necessary, hypervisors can allow some guest OS interactions, for example, allow two virtual machines to share files. Hypervisors can also dynamically change the degree of isolation for each guest OS, if necessary, for example, allowing / disabling network interaction at a certain time. Isolating each guest OS from others and restricting available resources and privileges is known assandboxing .

Another advantage of isolating guest OS from each other and from the underlying hypervisor is the difficulty of conducting attacks through technical channels. These attacks use the physical properties of equipment to disclose information about CPU usage, memory access, and other resources. Typically, the purpose of such attacks is to break the cryptographic keys, and direct physical access to the host is required.

Attackers may attempt to go beyond a compromised guest OS to gain access to other guest OSs, the hypervisor, or the host OS. If the attacker successfully does this and gains access to the hypervisor, then he gains access to all the guest OSs of the hypervisor. Thus, the hypervisor becomes a single point of failurein terms of security (single point of security failure) for all guest OSs. One failure in the hypervisor puts all guest OSs at great risk.

Guest OSs are usually not completely isolated from each other and from the host OS, which allows some functionality that is not necessary. For example, many host virtualization solutions provide mechanisms that allow guest OSs to access files, directories, the clipboard, and other resources of the host OS or other guest OSs. These communication mechanisms can serve as a vector of attack, spreading malware or allowing an attacker to gain access to private resources. Bare metal virtualization does not provide such opportunities.

2.2 Guest OS Monitoring

The hypervisor at any time has all the information about the current state of each guest OS. And if so, the hypervisor has the ability to monitor each running guest OS, which is called introspection. Introspection provides audit capabilities not available in any other case. Network traffic, memory, processes, and other elements of the guest OS can be audited. In many products, hypervisors can combine their security functions with external monitoring elements and provide them with information obtained through introspection. Examples include firewalling, intrusion prevention, and access control. Many products also enhance security policies with hypervisor-based security,

Monitoring network traffic is especially important when two guest operating systems are connected to the network on the same host, or the guest operating system is combined with the host OS. Unlike the traditional situation, such traffic will not pass through the network security devices, therefore, protection within the host should be used at least to monitor traffic.

2.3 Image and snapshot management

Creating images (images) and snapshots of guest machines is not related to vulnerabilities in guest OSs, services, and applications. Nevertheless, images and images in some ways affect security, sometimes negatively, sometimes positively.

Note that one of the biggest security issues associated with images and snapshots is that they contain important data (such as passwords, personal data, etc.) just like any hard drive. Since images or snapshots are easier to move than physical media, it becomes important to think about the security of the information they contain. Snapshots are subject to more risks than images, because snapshots, among other things, contain the state of RAM-memory at that moment in time when the snapshot was taken, which can give an attacker access even to information that is not stored in read-only memory.

As the use of server virtualization and / or desktop virtualization in an organization grows, image management becomes more complex. Some products offer solutions that can check stored images and update them if necessary, for example, by applying patches or making configuration changes, but other products do not provide the ability to apply updates in a different way than by launching each desired image. For such products, the longer the image does not start and is stored, the more vulnerabilities it will contain when it is launched. Tracking image health can be a significant issue, especially if users and administrators can create their own images. Such images may not be properly protected, which naturally increases the risk of compromise.

Another possible problem associated with an increase in the use of virtualization, and more specifically, with an increase in the number of images, is the so-called sprawl. It’s easy to create a new image — usually a matter of minutes without considering security considerations — which leads to the creation and launch of unnecessary images. Each additional launched image is a new potential point of entry into the system for an attacker. Therefore, organizations should minimize the creation, storage and use of images that are not necessary. Organizations should take into account the use of processes that control the creation, protection, distribution, storage, use, retrieval and destruction of template images, especially for server virtualization. The same attention should be given to image management.

Image files can be monitored to detect unauthorized changes to them. This can be achieved by calculating the cryptographic checksum (or hash) for each stored file and its subsequent periodic verification, as well as determining the initiator of any changes. Image files can also be scanned for rootkits and other malware, which hides its existence from the antivirus software of the guest OS upon startup.

In some virtualization systems, guest operating systems can be moved from one computer to another when necessary. For example, when a host needs to be rebooted or turned off, when a host partially fails, or when an attack is detected on a hypervisor or host OS, or when such attacks are expected. With server virtualization, the hypervisor may be able to move its guest OSs to other host computers automatically; on some systems, this may not even require shutting down or pausing guest OSs. As for workplace virtualization, administrator intervention is usually required here. A SAN (storage network) that provides such a migration or a transport channel (for it) must be fully authenticated and encrypted to preserve the integrity of the VM and prevent information leaks.

In the case of virtualization, covering many physical servers, migration of guest OSs supports load balancing due to the possibility of dynamic control at any time interval over which host which virtualized server is running on. That is, if a particular host is heavily loaded, almost until the physical resources are completely depleted, one or more of its guest OSs should be transferred to less loaded machines. This mechanism prevents the denial of service problem, but most often it is used simply to improve the performance of guest OSs.

A potential drawback of using guest OS migration is that if the guest OS is compromised or contains malicious code, but this malicious activity has not yet been detected, then when migrating this guest system, it may compromise another host. The same problem is present when converting a compromised physical system into a virtual machine.

Conclusion (from the translator)

For those who do not want to read the full 25-page version of the translation, the translator takes the responsibility to formulate a summary to the entire document.

Virtualization is an additional technical level, which, along with useful functions for the owner, provides additional attack vectors for the attacker.

The hypervisor is a single point of failure of the virtual infrastructure, the main problem of its protection. The vast majority of attacks are directed specifically at him.

Protection recommendations are given by the most commonplace:

• Disable unnecessary features anywhere;
• Install the latest updates and patches;
• Sync with a trusted time server;
• Limit access and protect control channels (a separate control network is either encryption, or both);
• Careful monitoring;
• Careful planning during deployment.

In order to get more specific manuals, up to the description of checkboxes in the interface, you need to refer to the recommendations and checklists of virtualization software manufacturers: VMware, Microsoft, Citrix, etc.