NIST SP800-125 translation. Full Virtualization Technology Security Guide

Against the background of the general trend in today's IT industry, the transition to virtualized infrastructure and cloud computing, enterprises are faced with an urgent need to secure such a transition. The main reasons for some uncertainty in this matter for Russian IT specialists and security specialists are a small experience with these technologies and, most importantly, the lack of governing documents and standards of authorized state bodies.

Immediately make a reservation: the Russian standard is being developed. It will be referred to as “Information Security. Requirements for the protection of information in information systems built using virtualization technology. General provisions. It is planned to hold a public discussion of the first edition of this national standard from May to June 2013. It is clear that it is clearly not necessary to wait for its approval in the coming year. In this regard, foreign recommendations are of particular importance, where the experience of implementing virtualization solutions is much wider.

The NIST SP 800-125 document contains the most general guidelines on the basis of which organizations can and need to develop their security policies.
In view of the bulkiness of the document for one post, here I will give only the general definitions from the “introduction” and the “review of virtualization security” section. For those who wish, a link to the full version in docx format.
There are many letters under the cut.

')

1. Introduction

Virtualization - simulation of software (software) and / or hardware, on top of which other software runs. This simulated environment is called a virtual machine (VM). There are many forms of virtualization that differ primarily in computing architecture. This work focuses on a form of virtualization known as full virtualization. With full virtualization, one OS or more and the applications they contain are running on top of virtual hardware. Each instance of the OS and its applications running in a separate VM is called a guest operating system . The guest OSs on the host are controlled by the hypervisor , which controls the flow of commands between the guest OSs and the physical hardware, such as CPU, disk storage, memory, and network adapters. The hypervisor can share system resources and isolate guest OSs so that each has access only to its own resources, as well as, possibly, access to shared resources, such as files on the host OS. Some hypervisors run on top of another OS, which is called the host operating system or the 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 virtualization, the hypervisor runs directly on the used hardware without a host OS. In another form of full virtualization, known as hosted or hosted virtualization, the hypervisor runs on top of the host OS;

2 Virtualization Security Overview

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

2.1 Isolation of guest OS

The hypervisor is responsible for allocating the physical resources (CPU, memory, storage) of the guest OS. It shares these resources so that each guest OS can only have access to its own 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 malicious software from one guest OS to another by means of infecting guest OS files or placing malicious code in the guest OS memory. In addition, resource sharing can also reduce the threat of denial of service (DoS) caused by over-consuming different guest operating systems over a single hypervisor.

Resources can be shared physically or logically. During physical partitioning, the hypervisor assigns separate physical resources for each guest OS, such as hard disk partitions, disk drivers, network cards. Logical separation can represent resources of one host or several as a set (pool) of resources of one security category, which allows many guest OSs to share (share) one physical resources (for example, processors) through a hypervisor. Physical separation imposes a strict limit 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. Many virtualization systems are equipped with both separation mechanisms.

Resource sharing is an important component of guest OS isolation. Isolation also includes limiting guest OS communications and access, which each guest OS has to another, to the hypervisor and the host OS (if there is one). 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 have common files. Hypervisors can also dynamically change the degree of isolation for each guest OS, if necessary, for example, by enabling / disabling network interaction at a specific time. Isolating each guest OS from others and limiting the available resources and privileges is known as sandboxing .

Another advantage of isolating guest OSs from each other and from the underlying hypervisor is the difficulty of carrying out attacks via technical channels. These attacks use the physical properties of equipment to disclose information about CPU utilization, access to memory, and other resources. Typically, the purpose of such attacks is to open the cryptographic keys, and this requires direct physical access to the host.

Attackers may attempt to go beyond a compromised guest OS in order to gain access to other guest OS, hypervisor, or host OS. If an attacker successfully does this and gets access to the hypervisor, then he gets access to all the guest OS of the hypervisor. Thus, the hypervisor becomes a single point of security failure for all guest OSs. One failure in the hypervisor puts all guest OSes 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 a guest OS to access files, directories, the clipboard, and other resources of the host OS or other guest OSs. These communication mechanisms can serve as an attack vector, 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 that are unavailable in any other case. Audit can be subjected to network traffic, memory, processes and other elements of the guest OS. In many products, hypervisors can combine their security functions with external control elements and provide them with information obtained through introspection. Examples: firewalling, intrusion prevention and access control. Many products also make it possible to strengthen security policies with the help of protection based on the hypervisor, making it possible not to violate the policy when migrating guest OSes from one physical host to another.

Network traffic monitoring is especially important when two guest operating systems on a single host are combined into a network, or a guest operating system is combined with a host operating system. Unlike the traditional situation, such traffic will not pass through network security devices, so protection within the host must be enabled at least to monitor traffic.

2.3 Managing Images and Snapshots

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

Note that one of the greatest security problems 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 images 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 the RAM memory at the time when the snapshot was taken, which can open access to the attacker even to information that is not stored in permanent memory.

As the use of server virtualization and / or virtualization of the workplace 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, applying patches or making configuration changes, but other products do not provide the ability to apply updates in a different way than 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. Monitoring the status of images can be a significant problem, 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 the increasing use of virtualization, and more specifically, with an increase in the number of images, is the so-called sprawl. There is nothing difficult to create a new image - usually, this is a matter of a few minutes, without taking into account security considerations - which leads to the creation and launch of unnecessary images. Each additional image launched is a new potential point of entry into the system for an intruder. Therefore, organizations must minimize the creation, storage and use of images that are not necessary. Organizations must take into account the use of processes that govern the creation, protection, distribution, storage, use, seizure, and destruction of template images, especially for server virtualization. The same attention should receive management of pictures. In some cases, organizations have policies that prevent snapshots from being stored because of the risk of malware being distributed in the system, which can be stored in a snapshot and later downloaded.

Image files can be monitored to detect unauthorized changes to them. This can be provided by calculating a 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 malicious software, which, when launched, hides its existence from guest OS antivirus software.

In some virtualization systems, guest OSs can be moved from one computer to another when necessary. For example, when a host needs to be restarted or shut down, when the host has partially failed, or when an attack is detected on the hypervisor or host OS, or when such attacks are expected. With server virtualization, the hypervisor may be able to move its guest OS to other host computers automatically; on some systems, this may not even require shutting down or suspending the guest OS. As for the virtualization of the workplace, it usually requires the intervention of the administrator. A SAN (storage network) providing 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 that spans multiple physical servers, guest OS migration supports load balancing, thanks to the ability to dynamically control at any time interval on which host which virtualized server is running on. That is, if a particular host is heavily loaded, almost to the complete exhaustion of physical resources, one or several of its guest OS should be transferred to less loaded machines. This mechanism prevents the problem of denial of service, but most often it is used simply to improve the performance of the guest OS.

A potential disadvantage 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 translator)

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

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

Hypervisor - a single point of failure of the virtual infrastructure, the main problem of its protection. The overwhelming majority of attacks directed on him.

Recommendations for the protection given the most banal:

• Disable unnecessary features anywhere;
• Install the latest updates and patches;
• Synchronize with a trusted time server;
• Restrict access and protect control channels (a separate control network or encryption, or both);
• Close monitoring;
• Careful planning when deploying.

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