SYS.2.6 Virtual Desktop Infrastructure
A Virtual Desktop Infrastructure (VDI) controls and manages standardized virtual clients. This allows individual applications (e.g., office programs) or entire desktops to be provided centrally...
Description
Introduction
A Virtual Desktop Infrastructure (VDI) controls and manages standardized virtual clients. This allows individual applications (e.g., office programs) or entire desktops to be provided centrally. Virtual clients are virtualized IT systems that can be accessed via terminal server protocols. The virtual clients are run on virtualization servers that are combined with a management system into a virtualization infrastructure (see building blocks SYS.1.5 Virtualization and SYS.2.5 Client Virtualization).
Depending on the product used, a VDI typically consists of access, control, and management components that are distributed across one or more IT systems. These central VDI components manage, among other things, the virtualization infrastructure and establish connections between accessing and virtual clients. Therefore, the virtualization infrastructure, the connected storage systems, and the virtual and accessing clients are also implicit parts of the VDI. In this building block, however, “VDI components” always refers to the following three central components of a VDI:
- The VDI access components authenticate users and decide, based on their permissions, whether accesses are allowed or not allowed and which type of virtual client users are authorized for.
- The VDI control components select the corresponding virtual clients for the permitted accesses and establish the connection between accessing and virtual client.
- The VDI management components manage the rules (e.g., the assignment of users to client types) and settings (e.g., the protocols to be used). They also manage the virtual clients (in accordance with SYS.2.5 Client Virtualization). This also includes the assigned resources and their provisioning as well as the terminal server-specific settings of the virtual clients.
Additionally, it may be necessary to connect further infrastructure services that are not part of the VDI solution itself (e.g., directory services, name resolution, or IP address management).
VDIs are typically used to efficiently provide centrally administrable standardized workstations. This is used, for example, to replace classic physical clients with thin clients.
Objective
The objective of this building block is to protect information stored, processed, and transmitted when using a VDI. For this purpose, specific requirements are placed on the components of a VDI described in the introduction.
Scope and Modeling
The building block SYS.2.6 Virtual Desktop Infrastructure must be applied to every IT system used as part of a VDI solution.
This building block addresses the following content:
The building block SYS.2.6 Virtual Desktop Infrastructure addresses the secure use of a VDI. The focus is on the three central components of a VDI.
This building block contains 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:
- The basic functionality of communication between an accessing and a virtual client in a VDI solution is fulfilled using terminal server technologies. Therefore, the building block SYS.1.9 Terminal Server must also be applied to the VDI solution, whereby the individual virtual clients are the actual terminal servers.
- The building blocks SYS.2.5 Client Virtualization and SYS.1.5 Virtualization must also be applied to the individual virtual clients and the virtualization infrastructure respectively, especially for the isolation of virtual clients through the virtualization server.
- General requirements for the individual server components as well as the accessing and virtual clients are described in the building block SYS.1.1 General Server or SYS.2.1 General Client. Additionally, operating system-specific building blocks may need to be applied.
- The building block NET.1.1 Network Architecture and Design must be applied to secure the networks used for the VDI.
This building block does not address
- the IT systems used in the context of the VDI in addition to the VDI components described above (e.g., storage systems), nor
- the technologies used for virtualization or for communication between accessing and virtual 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.6 Virtual Desktop Infrastructure.
Degraded Quality of Virtual Client Provisioning
A VDI is often used to optimize resources. However, if many virtual clients are placed on individual virtualization servers, the available resources can become overbooked. Resources can also become overbooked if the planned number of users has been incorrectly estimated.
As a result, virtual clients in the VDI can compete heavily for resources and performance can drop unpredictably. This can lead to virtual clients temporarily becoming unavailable.
The performance drops are often opaque to users, so that data is lost or changed unintentionally.
Incorrect Assignment of Virtual Clients to Users
Users are centrally assigned virtual clients and their resources by the VDI based on profiles. If such an assignment is erroneous, this can result in:
- high costs if high-performance virtual clients are assigned to users with little resource demand,
- virtual clients with low performance being assigned to users with high resource demand or special hardware requirements, e.g., for CAD tasks,
- users gaining unauthorized access to IT systems and information, or
- external USB devices being connected and information being transferred to virtual clients not intended for that purpose.
Insufficient Network Separation Due to Misconfiguration in the VDI
Typically, a VDI solution operates different virtual clients that vary greatly in their areas of application and can accordingly be assigned to different networks. The VDI management component manages all of these clients. If the VDI management component is incorrectly configured, a necessary network separation can be lifted. Under certain circumstances, virtual clients may then be able to communicate with each other without authorization.
This situation arises, for example, when virtual clients are assigned to users based on characteristics such as group memberships and are incorrectly mapped. In this case, a network separation that should exist between clients of different groups can be circumvented.
Loss of Virtual Clients Due to Misconfiguration in the VDI
A strength of VDI is that many different virtual clients can be easily managed through a few templates. This allows new desktops to be quickly provisioned and faulty desktops to be repaired or replaced.
However, due to this centralized management, virtual clients can be lost through deleted or corrupted templates. If certain user data is stored exclusively on the storage of the virtual clients, the loss of a virtual client also leads to the loss of that data.
User-modified configurations are also irreversibly deleted when the virtual client is reset.
Failure of VDI Components
A VDI typically consists of multiple components that depend on each other. If even one of these components fails — for example due to hardware or software errors or misconfigurations — this can impair the availability of the entire VDI solution and thus the ability of users to work.
A failure of one or more components can have very different consequences. For example, if the VDI management component fails, normal work operations are in principle possible, but no adjustments can be made. This can lead, among other things, to:
- new virtual clients not being able to be provisioned,
- virtual clients not being able to be reset to a functional baseline state after errors,
- troubleshooting being made more difficult because the collected information from management functions is not available, or
- the resources of a virtual client not being able to be adjusted if they are insufficient for individual users.
The access or control components of some VDI products do not offer their full functionality without the management component.
Unauthorized Access to Virtual Clients
A VDI management component manages all associated clients. If the VDI management component is compromised (for example due to exploited vulnerabilities or misconfiguration), the virtual clients can be accessed from there. In this case, the availability, confidentiality, or integrity of the virtual clients can be impaired.
Some VDI solutions include agent software that is used within the virtual clients and is required for certain VDI functions (e.g., connection establishment, 3D acceleration, storage consumption optimization). If a misconfiguration affects this agent software, the virtual clients can be endangered.
Depending on the size of the environment, the agent software and the management component of the VDI control many clients. In these cases, many different virtual clients can be accessed.
Use of Templates with Software Vulnerabilities
In a VDI, virtual clients can be quickly and centrally created from a defined set of 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 can be exploited and the virtual client compromised.
Requirements
The following are the specific requirements of the building block SYS.2.6 Virtual Desktop Infrastructure. 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.
| Responsibilities | Roles |
|---|---|
| Primarily responsible | IT Operations |
| Additional responsibilities | Planners |
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.6.A1 Planning the Deployment of a VDI (B)
The performance requirements and number of virtual clients needed, as well as the resulting requirements for the dimensioning of the VDI, MUST be identified. The VDI components MUST be planned according to these dimensioning requirements. The VDI components and the virtualization infrastructure used MUST be planned in coordination with each other.
When dimensioning the VDI, it MUST be taken into account whether and how the requirements may change over the planned deployment period of the VDI solution. Support MUST be taken into account during planning for the entire planned deployment period of the VDI solution.
The number of virtual clients and their required performance per virtualization server MUST be defined.
SYS.2.6.A2 Secure Installation and Configuration of VDI Components (B)
When the VDI components are installed and configured, at a minimum the following MUST be taken into account, namely how:
- operations are restricted to operationally and technically necessary functions,
- communication between VDI components is secured, and
- virtual clients are securely assigned to users or groups thereof.
Recommendations from the manufacturer of the VDI solution for secure configuration MUST be taken into account.
The configurations of the VDI components MUST be appropriately documented.
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.6.A3 Secure Installation and Configuration of Virtual Clients Using the VDI (S)
The VDI solution SHOULD be used to install and configure the virtual clients. Virtual clients SHOULD NOT be manually integrated into the VDI solution. Virtual clients SHOULD NOT be created in the virtualization infrastructure used for the VDI independently of the VDI.
SYS.2.6.A4 Network Segmentation of VDI Components (S) [Planners]
The VDI components, including the virtual clients, SHOULD be given special consideration in network segmentation. Networks SHOULD at a minimum be separated with the help of the virtualization infrastructure. Dedicated network segments SHOULD at a minimum be set up for the administration network of the VDI components and for the networks of internal communication between VDI components.
SYS.2.6.A5 Standardized Access to Virtual Clients (S)
The mechanisms and services of the VDI solution SHOULD be used to control and secure access to virtual clients. If additional software is used for these accesses on the accessing clients, this software SHOULD be provided in a standardized and centralized manner.
SYS.2.6.A6 Use of a Dedicated Infrastructure for Virtual VDI Components (S)
If the VDI components are operated in a virtualized manner, they SHOULD be operated on a dedicated virtualization infrastructure.
SYS.2.6.A7 Hardening of Virtualized Clients Through the VDI Solution (S)
The capabilities of the VDI solution SHOULD be used for hardening virtual clients in accordance with the requirements of the building block SYS.2.5 Client Virtualization. The operating systems of the clients SHOULD be configured exclusively through the management component of the VDI solution. Individual configuration of existing virtual clients through the virtualization infrastructure SHOULD be prevented by technical means.
SYS.2.6.A8 Hardening the VDI Solution (S)
Automatic logon to the VDI SHOULD not be possible. Authentication SHOULD only take place after users have interacted with the VDI.
SYS.2.6.A9 Integration of Virtual Clients into Patch and Change Management (S)
Where possible, virtual clients SHOULD be managed centrally through the management components of the VDI solution. Virtual clients SHOULD also be patched while switched off, if this is supported by the VDI solution. The templates from which virtual clients are created SHOULD be regularly updated.
SYS.2.6.A10 Monitoring Availability and Utilization of the VDI (S)
The status of the VDI components SHOULD be monitored centrally. At a minimum, the following parameters SHOULD be monitored for each VDI component:
- Reachability of the required network interfaces
- Availability of the services provided by the VDI component
- CPU and memory utilization
SYS.2.6.A11 Monitoring Security-Relevant Events of the VDI (S)
For the VDI components, at a minimum the following events SHOULD be forwarded to a central monitoring system:
- Successful and failed login attempts
- Configuration changes to VDI components or virtual clients
- Successful and failed updates to VDI components
- Failed updates to virtual clients
The VDI components SHOULD be regularly checked for vulnerabilities.
SYS.2.6.A12 Distribution of Virtual Clients Across Virtualization Servers (S)
Per virtualization server, the maximum performance that it is allowed to provide for virtual clients SHOULD be defined. These threshold values SHOULD be used in the VDI management component to distribute virtual clients across different virtualization servers when utilization is high.
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.6.A13 Use of Separate VDI Solutions for Different User Groups (H)
It SHOULD be examined whether there are user groups whose permissions differ so significantly that the use of a shared VDI solution is not sensible. In this case, a separate VDI solution SHOULD be used for each user group.
SYS.2.6.A14 Use of Non-Persistent Virtual Clients (H)
After they have been used or at a defined point in time, virtual clients SHOULD be reset to their baseline state, i.e., the underlying template, or re-provisioned as needed. These time windows SHOULD be documented and communicated to those affected. Non-reset virtual clients SHOULD NOT be used by multiple different users.
SYS.2.6.A15 Highly Available Provisioning of VDI Components (H)
The VDI components SHOULD be designed redundantly. Each component SHOULD additionally be connected redundantly to the relevant networks. If the VDI components are operated on physical IT systems, these IT systems SHOULD have redundant power supply and data storage. If the VDI components are operated in a virtualized manner, mechanisms of the virtualization infrastructure SHOULD be used for high availability.
SYS.2.6.A16 Integration of the VDI into a SIEM (H)
If a Security Information and Event Management (SIEM) is used, the VDI components SHOULD be integrated into it. In the SIEM, the monitored events SHOULD be automatically analyzed for anomalies, including attack patterns.
Additional Information
Good to Know
No additional information is available for the building block SYS.2.6 Virtual Desktop Infrastructure.