SYS.2.5 Client Virtualization

Description

Introduction

Client virtualization refers to the virtualized provisioning of clients. Clients can be virtualized both locally on a physical client and through a (central) virtualization infrastructure. Virtualization infrastructures can be used to operate virtual clients from a remote workstation.

This building block addresses the secure use of client virtualization through a virtualization infrastructure. A virtualization infrastructure comprises one or more physical virtualization servers as described in the building block SYS.1.5 Virtualization. The individual virtual clients are executed on the respective virtualization servers and consist of the defined virtual hardware resources such as CPU, memory, and the associated disk image. These images are typically created from templates.

Users interact through physical clients that connect to the virtual clients using terminal server technologies and protocols. The virtual client is therefore also a terminal server in the sense of the building block SYS.1.9 Terminal Server.

Virtual clients running on a virtualization infrastructure are generally easier to administer than physical clients distributed geographically across an institution. Furthermore, virtual clients can be provisioned more easily than physical clients using templates. In addition, virtual clients can be updated more easily via snapshots or cloned virtual machines. Another typical use case involves virtual clients created for testing specific applications and therefore only required for a short period.

Objective

The objective of this building block is to protect information that is processed and transmitted during client virtualization. For this purpose, specific requirements are placed on the virtual clients and the underlying virtualization infrastructure as well as on the networks used.

Scope and Modeling

The building block SYS.2.5 Client Virtualization must be applied to the virtualization infrastructure and all virtual clients provisioned centrally as described above.

To create an IT-Grundschutz model for a specific information domain, the entirety of all building blocks must fundamentally be considered. As a rule, several building blocks must be applied to the subject or target object.

This building block addresses the following content:

• The building block SYS.2.5 Client Virtualization covers those parts of client virtualization that are specific to the provisioning and use of virtual clients.
• This building block includes specific requirements for the networks used to secure communication between the accessing client and the virtualization infrastructure.

The following content is also relevant and is addressed elsewhere:

• Accessing clients and virtual clients communicate via terminal server software running on the virtual clients. Therefore, the building block SYS.1.9 Terminal Server must be applied to both virtual clients and accessing clients.
• To address the general aspects of virtual clients, the building block SYS.2.1 General Client must be applied. Furthermore, the operating system-specific building blocks of the SYS layer may be applicable.
• General aspects of virtualization, such as isolation through the virtualization server, are addressed in the building block SYS.1.5 Virtualization.
• The building block NET.1.1 Network Architecture and Design must be applied to secure the networks used for communication between the accessing client and the virtualization infrastructure.

This building block does not address the following content:

• The local provisioning of virtual clients on physical clients.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block SYS.2.5 Client Virtualization.

Inadequate Dimensioning of the Network Connection for Virtual Clients

If the performance requirements for the network connection of virtual clients are not, or only inadequately, considered during planning, the virtual clients may not function properly. For example, if the network connection to downstream services (e.g., video conferencing solutions or file storage) is not sufficiently capable, virtual clients may under certain circumstances only be able to access information in a limited way, particularly with latency-sensitive applications. A similar situation arises if virtual clients are not connected to accessing clients with sufficient network capacity.

Insufficient Performance of Virtual Clients Due to Resource Scarcity

To be able to work as smoothly as possible on virtual clients, it is important that they are performant. If a virtual client is allocated only insufficient resources (e.g., CPU, memory, or graphics performance), the availability of applications installed on the virtual client can be impaired. For example, certain graphically demanding programs cannot be executed on a virtual client without dedicated graphics processors. An excessively low processor clock speed also leads to slow processing.

If virtual clients behave differently, resources can become scarce as a result. For example, if users run many applications continuously and in parallel, the virtual clients may under some circumstances no longer be able to provide the required performance.

Mutual Interference of Virtual Clients

The dimensioning of the underlying virtualization infrastructure is decisive for the actual retrievable performance of multiple virtual clients running in parallel. If many other virtual IT systems are run simultaneously on a virtualization server in addition to a virtual client, the virtualization server may no longer be able to meet the resource demands. This in turn can result in the actual performance of the virtual client becoming limited and no longer predictable. CPU performance and memory play the greatest role when they are dynamically allocated. If too many different users simultaneously demand performance, they compete for it.

Especially when virtual clients are used improperly and the provided resources are heavily utilized, other virtual clients can be impaired. In extreme cases, the underlying virtualization server may terminate a virtual IT system due to resource exhaustion or even fail completely itself.

Insufficient Separation of Virtual Clients at the Network Level

The virtual clients are clients in the sense of the building block SYS.2.1 General Client, which may have different protection needs. If these clients are operated on a shared virtualization infrastructure, an existing separation at the port level may be lifted by the virtualization server used (at the level of virtual switches).

If virtual clients are not assigned to the intended network segments at the level of virtual switches, VLANs, or physical interfaces — for example due to configuration errors — they could access protected networks and information contained therein for which they are not authorized.

Virtualization servers are typically operated in central IT operation areas (data centers) where other central servers are also located. If virtual clients and central servers are not placed in network segments that are separated from each other, virtual clients may access servers in an unauthorized or unintended manner. If these network segments contain virtual clients that are permitted to access the Internet, this increases the attack surface.

Loss of Virtual Clients and Data Stored on Them

In client virtualization, the images of virtual clients are stored and managed centrally. Erroneous administration or misuse of virtual clients can damage or delete them. The loss of virtual clients during ongoing operations can lead to the deletion of information stored on those virtual clients. Additionally, the loss of virtual clients means that information being processed on them is no longer available.

Unavailability of Virtual Clients and Data Stored on Them

As a rule, virtual clients cannot be switched on by users themselves, but only by IT Operations, which also administers the virtualization infrastructure. During updates or general maintenance work on the virtualization infrastructure, it is customary for virtual clients to be switched off. If they are forgotten to be switched back on afterward, they remain switched off and are thus unreachable.

Similarly, a failure of the underlying virtualization server can result in virtual clients being temporarily unreachable. In this case, users can no longer access the respective virtual client and the data stored on it.

Software Vulnerabilities on Virtual Clients

Virtual clients consist of the defined virtual hardware resources such as CPU and memory and the associated disk image. These images are typically created from templates. When these templates are created, they are generally at a current software level without known vulnerabilities.

Without regular updates to these templates, however, it is possible that a newly created virtual client has vulnerabilities that became known after the template was created. If other IT systems can access this virtual client, the known vulnerability may under certain circumstances be exploited, compromising the virtual client.

It may also be necessary to provision virtual clients with known vulnerabilities, for example for compatibility testing or for required software that only runs on outdated operating systems. These vulnerabilities can occur predictably and can thus be exploited more easily.

Bypassing Isolation Between a Virtual Client and Other Virtualized IT Systems

Virtual IT systems are often deployed on a shared virtualization infrastructure to use resources more efficiently and provide them more flexibly. As a result, the various virtualized IT systems can influence each other. Unlike a virtual server, virtual clients can be compromised more easily because the applications running on virtual clients are more diverse and interactive.

A compromised virtual client can endanger the shared virtualization infrastructure, since not only IT systems reachable over the network but also other virtual IT systems on the virtualization server can be attacked. Because the physical IT system is shared, side-channel attacks such as Spectre or Meltdown can be carried out, or an escape from the virtual machine can be attempted in order to subsequently compromise the underlying hypervisor or operating system. In this case, virtual IT systems can be taken out of operation or the data being processed in them can be read or modified.

Requirements

The following are the specific requirements of the building block SYS.2.5 Client Virtualization. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many people should fill these roles.

Basic Requirements

The following requirements MUST be met with priority for this building block.

SYS.2.5.A1 Planning the Deployment of Virtual Clients (B)

It MUST be determined which applications are to be used on the virtual clients. The tasks to be accomplished with these applications MUST be defined. For these applications, it MUST be verified and documented which requirements are placed on the virtualization infrastructure and any additional hardware it may require (e.g., graphics cards). The virtualization server used MUST provide the necessary resources with regard to CPU, memory, and data storage.

SYS.2.5.A2 Planning the Networks Used for Virtual Clients (B) [Planners]

The networks for the connection between accessing clients and virtual clients as well as the networks for connecting downstream services to the virtual clients (e.g., directory services, e-mail, or Internet access) MUST be designed with sufficient performance capacity.

It MUST be planned which network segments are to be used for the virtual clients. The network segments for virtual clients MUST be separated from network segments for servers. An existing network separation MUST NOT be circumvented using a virtual client or a virtualization server.

For virtual clients, it MUST be determined whether and to what extent communication to untrusted networks should be restricted.

SYS.2.5.A3 Protection Against Malware on Virtual Clients (B)

For the virtual clients, protection against malware MUST be implemented in accordance with the building blocks OPS.1.1.4 Protection Against Malicious Programs and SYS.2.1 General Client, and taking into account the operating system-specific building blocks. If antivirus software is used, it MUST be determined and documented whether this protection is implemented centrally in the virtualization infrastructure, decentrally on the virtual clients, or in hybrid forms. If the virtual clients are to be protected by central components, these central components MUST have sufficient performance capacity.

If antivirus software is run on the virtual clients, it MUST be ensured that the performance of the virtualization infrastructure is sufficient.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be met.

SYS.2.5.A4 Use of a Dedicated Virtualization Infrastructure for Virtual Clients (S)

The virtual clients SHOULD be operated on a dedicated virtualization infrastructure. Virtual servers SHOULD NOT be run on the same virtualization infrastructure.

SYS.2.5.A5 Additional Network Segmentation for Virtual Clients (S)

The following criteria SHOULD be taken into account for additional network separation of virtual clients:

• Usage scenario for the virtual clients and group membership of users
• Permissions of users derived from group membership
• Applications installed on virtual clients and made available to users
• Protection needs of the information processed on the virtual clients
• Trustworthiness of the virtual clients
• Network connections necessary for the functionality of the virtual clients

SYS.2.5.A6 No Local Data Storage on Virtual Clients (S)

Data created or processed by users SHOULD be stored centrally. The data SHOULD NOT be stored permanently on virtual clients.

Users connecting to virtual clients SHOULD NOT be able to transfer data from the virtual clients to their local IT systems. If such a transfer is demonstrably necessary, it SHOULD be limited to the necessary minimum.

SYS.2.5.A7 Automatic Session Locking (S)

After an accessing client has ended its terminal server session, the active session on the virtual client SHOULD be locked. After a defined period of inactivity, connections between the accessing and virtual client SHOULD be terminated. If the intended use of the respective virtual client allows it, the virtual clients SHOULD be placed in an inactive state after the connection is terminated.

SYS.2.5.A8 Hardening of Virtual Clients (S)

The virtual clients SHOULD be hardened. The following aspects SHOULD be taken into account:

• Restriction of data transfer between accessing and virtual clients
• Forwarding of peripheral devices or external storage media from accessing to virtual clients
• Explicit authorization for the execution of applications
• Deactivation of network services not required in the virtualization infrastructure

SYS.2.5.A9 Integration of Virtual Clients into Patch and Change Management (S)

Client applications SHOULD be provisioned centrally. For this purpose, a suitable centrally manageable solution SHOULD be used. Templates for the virtual clients SHOULD be regularly updated and tested.

SYS.2.5.A10 Demand-Oriented Allocation of Resources to Virtual Clients and Groups (S)

Based on roles and activities, the performance requirements of individual user groups on the virtual clients SHOULD be identified. Based on these requirements, a decision SHOULD be made on how many resources (e.g., processor cores or memory) are to be made available to the individual virtual clients.

Additional resources such as GPUs (Graphics Processing Units) SHOULD only be provided to users on demand.

SYS.2.5.A11 Avoiding Nested Virtualization on Virtual Clients (S)

No additional virtual IT systems SHOULD be set up on virtual clients. Where technically possible, functions SHOULD be activated in the underlying virtualization infrastructure that make nested virtualization more difficult or prevent it.

SYS.2.5.A12 Raising Awareness Among Users (S)

All users of virtual clients SHOULD be made aware of the secure use of virtual clients. If resources are dynamically distributed among multiple virtual clients based on usage, users SHOULD be informed that their behavior can potentially affect other users.

If the security requirements of applications running on virtual clients are particular, it SHOULD be communicated how these differ from physical clients. The specific security aspects to be observed SHOULD also be communicated.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered when there is a higher need for protection. The concrete definition is made in the context of an individual risk analysis.

SYS.2.5.A13 Prevention of Communication Between Virtual Clients at a Shared Virtual Switch (H)

Mechanisms SHOULD be activated that prevent uncontrolled Layer 2 communication between virtual clients at a shared virtual switch.

SYS.2.5.A14 Extended Security Features for the Use of Virtual Clients (H)

The virtual clients SHOULD be protected with additional security features. The following technologies SHOULD be taken into account as a minimum:

• Micro-segmentation for the virtual clients
• Intrusion detection or intrusion prevention systems, provided either centrally on the virtualization infrastructure or decentrally on the virtual clients

SYS.2.5.A15 Monitoring of Virtual Clients (H)

The status of virtual clients SHOULD be monitored centrally. At a minimum, the following parameters SHOULD be monitored:

• Reachability of the virtual clients via all designated network interfaces,
• CPU and memory utilization of the virtual clients,
• available disk capacity of the virtual clients, and
• availability of the terminal server services used for access.

For monitoring, the respective threshold values SHOULD be determined in advance (baselining). These threshold values SHOULD be reviewed regularly and adjusted if necessary.

SYS.2.5.A16 Extended Logging for Virtual Clients (H)

For virtual clients, additional events SHOULD be transmitted to a central logging infrastructure (see OPS.1.1.5 Logging). At a minimum, the following events SHOULD be logged:

• Actions performed with administrative rights,
• configuration changes,
• installation of software,
• successful and failed updates, and
• all events generated by malware protection.

SYS.2.5.A17 Extended Monitoring of Virtual Clients (H)

The virtual clients SHOULD be continuously monitored to determine whether the events described in SYS.2.5.A16 Extended Logging for Virtual Clients occur. If a Security Information and Event Management (SIEM) is used, the virtual clients SHOULD be integrated into it. In the SIEM, the monitored events SHOULD be automatically analyzed for anomalies, including attack patterns.

The virtual clients SHOULD be automatically and regularly checked for vulnerabilities.

SYS.2.5.A18 Highly Available Provisioning of the Virtualization Infrastructure (H)

The virtual clients SHOULD be provided with high availability. This SHOULD be ensured by the underlying virtualization infrastructure. The virtualization servers SHOULD be connected redundantly to the relevant networks. In the event of resource scarcity, virtual clients SHOULD be automatically migrated between virtualization servers. If a virtualization server fails, the virtual clients SHOULD be automatically started on another virtualization server.

Additional Information

Good to Know

No additional information is available for the building block SYS.2.5 Client Virtualization.