SYS.2.1 General Client

Description

Introduction

A “General Client” refers to an IT system with any operating system that allows the separation of users and is not intended to provide server services. On a client, at minimum separate environments for administration and for use should be able to be set up. The IT system generally has drives and connection options for external or removable media, additional interfaces for data exchange, and other peripheral devices. Typically, such an IT system is integrated into a client-server network. The IT system can be, for example, a PC with or without a hard drive, a mobile or stationary device, but also a Linux workstation or an Apple Mac.

Objective

The objective of this building block is to protect information that is created, read, edited, stored, or sent on any type of client, regardless of the operating system used.

Scope and Modeling

The building block SYS.2.1 General Client is to be applied to all clients regardless of the specific operating system.

Clients are generally run under an operating system that requires its own specific security measures. Specific building blocks for common client operating systems are available in the SYS.2 Desktop Systems layer, which build upon the present building block and must be applied additionally. If no specific building block exists for the clients in use, the requirements of the present building block must be appropriately specified for the target object and a supplementary risk assessment must be conducted.

Security recommendations for mobile end devices with a fixed operating system, such as smartphones or tablets, can be found in the SYS.3 Mobile Devices layer. If a client has additional interfaces for data exchange, such as USB, Bluetooth, LAN, or WLAN, these must be secured in accordance with the institution’s security requirements as described in the corresponding building blocks. Requirements for this can be found, for example, in SYS.4.5 Removable Media or NET.2.2 WLAN Usage.

The requirements of building blocks OPS.1.1.3 Patch and Change Management and CON.3 Data Backup Concept must also regularly be taken into account for clients. Clients are often threatened by malicious software; therefore the requirements of building block OPS.1.1.4 Protection Against Malicious Programs are particularly relevant for clients.

Threat Landscape

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

Malicious Programs

Malicious programs are developed with the aim of executing undesirable and harmful functions on IT systems. They typically become active “covertly,” i.e., without users being aware of this or consenting to it. Depending on their design, they offer extensive communication and control capabilities with many different functions during attacks. Among other things, they could specifically read out passwords, remotely control IT systems, deactivate protective software, spy on data, or encrypt it.

Clients are particularly vulnerable to malicious software. They are operated directly by users and are therefore often the entry point for harmful content of all kinds. If users visit malicious websites, open emails with harmful content from private accounts, or copy malicious software onto the client via local storage media, the malicious software can spread through the clients into the institution’s network. Central protective mechanisms, such as antivirus protection on the file or email server, can often be circumvented in this way.

Data Loss Through Local Data Storage

Despite regular contrary recommendations, important data is often stored exclusively locally. For example, data is frequently stored in local directories rather than on a central file server. Emails are also often archived only locally. As a result, data can easily be lost in the event of hardware defects. If data important to the institution is destroyed or corrupted, this can delay or even completely prevent business processes and professional tasks. Overall, the loss of stored data can lead, in addition to work interruptions and the costs of re-procurement, to long-term consequences such as a loss of trust in business relationships and a negative impression in the public. In extreme cases, the direct and indirect damage caused by data losses can threaten the very existence of institutions.

If important data is kept exclusively locally, other persons also cannot access it — for example, when covering for someone during vacation or illness.

Even when general requirements for central storage are observed, local copies of centrally stored data are often additionally created. This not only frequently leads to inconsistent version states, but also results in data being deleted either prematurely or not when necessary.

Hardware Defects in Client Systems

Unlike central IT systems such as servers, users work directly on or with clients as end devices. As a result, they could potentially damage the client intentionally or unintentionally. For example, they could kick IT systems standing on the floor, trip over cables and damage interfaces, or spill liquids on devices. If no quick replacement is available, the IT system cannot be used as intended until the repair is completed. If a mobile device such as a laptop fails while on the road, work can often only be resumed upon return to the institution.

Unauthorized Use of Clients

The identification and authentication of persons is intended to prevent unauthorized use of a client. However, even IT systems on which users must identify and authenticate themselves using IDs and passwords can be used unauthorized if attackers succeed in spying on or guessing the access data. If a screen lock is not activated, the client can also be used without authorization during brief absences.

Installation of Unnecessary Operating System Components and Applications

When installing an operating system, there is generally the option to install optional software. Software is also regularly installed and tested during ongoing operation. With each additional application, not only does the computing and storage load of a client increase, but so does the probability of hidden vulnerabilities. Unnecessary software is also often not subject to regular patch management, so known security vulnerabilities are not closed in a timely manner. Such vulnerabilities can therefore be exploited for attacks.

Eavesdropping on Rooms via Microphone and Camera

Many clients have a microphone and a camera. These can in principle be activated and used by anyone with the appropriate access rights — in the case of networked systems, also by external parties. If these rights are not carefully assigned, unauthorized persons can misuse the microphone or camera to eavesdrop on rooms or record meetings unnoticed via the internet. This also includes Intelligent Personal Assistants (IPAs) or voice assistants that permanently listen to the environment and execute certain functions when a device-specific activation word is spoken, such as playing music, calling contacts, controlling lighting, or adjusting room climate. If conversations are transmitted to third parties by IPAs, these could potentially be intercepted by unauthorized persons. The recorded conversations could also be stored for longer periods at the manufacturing companies of IPAs and further processed.

Erroneous Administration or Use of Devices and Systems

Modern client operating systems are very complex. Therefore, in particular, misconfigurations of components can impair security, causing the IT system to malfunction or to be compromised. In general, every interface on an IT system not only provides the possibility of using certain services of the IT system with authorization, but also the risk that unauthorized persons can access the IT system. If, for example, account identifiers and associated passwords can be spied on due to misconfiguration of authentication mechanisms, unauthorized use of the applications or IT systems protected by those credentials is conceivable.

Erroneous or improper use of devices, systems, and applications can also impair security, especially if existing security measures are disregarded or circumvented. For example, overly generous access rights, easily guessable passwords, insufficiently protected storage media with backup copies, or unattended workstations that are not locked during temporary absence can lead to security incidents. Another consequence of erroneous operation of IT systems or applications can be the accidental deletion or modification of data. It is also possible for confidential information to fall into the hands of third parties — for example, if access rights are set incorrectly.

Requirements

The following are the specific requirements of building block SYS.2.1 General Client. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled 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. They should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. In addition, 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 persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

SYS.2.1.A1 Secure Authentication of Users (B)

To use the client, users MUST authenticate themselves to the IT system. Users MUST use a screen lock when operating the client unattended. The screen lock SHOULD be activated automatically when no action has been performed by users for a defined period. The screen lock MUST only be able to be deactivated by successful authentication. Users SHOULD be required to log off from the IT system or IT application after completing their tasks.

SYS.2.1.A2 DISCONTINUED (B)

This requirement has been discontinued.

SYS.2.1.A3 Activation of Auto-Update Mechanisms (B)

Automatic update mechanisms (auto-update) MUST be activated, unless other mechanisms such as regular manual maintenance or a central software distribution system are used for updates. If a time interval can be specified for auto-update mechanisms, updates SHOULD be searched for and installed automatically at least daily.

SYS.2.1.A4 DISCONTINUED (B)

This requirement has been discontinued.

SYS.2.1.A5 DISCONTINUED (B)

This requirement has been discontinued.

SYS.2.1.A6 Use of Protective Programs Against Malicious Software (B)

Depending on the installed operating system and other existing protective mechanisms of the client, it MUST be checked whether protective programs against malicious software should be used. Insofar as they exist, concrete statements as to whether such protection is necessary from the specific operating system building blocks of the IT-Grundschutz Compendium MUST be taken into account.

Protective programs on the clients MUST be configured such that users can neither make security-relevant changes to the settings nor deactivate the protective programs.

The protective program MUST scan for malicious software when files are exchanged or transferred. The entire data inventory of a client MUST be regularly checked for malicious software. If a client is infected, it MUST be examined in offline mode whether a found malicious program has already collected confidential data, deactivated protective functions, or downloaded code from the internet.

SYS.2.1.A7 DISCONTINUED (B)

This requirement has been discontinued.

SYS.2.1.A8 Protection of the Boot Process (B)

The startup process of the IT system (“booting”) MUST be protected against manipulation. It MUST be specified from which media booting is permitted. A decision SHOULD be made as to whether and how the boot process should be cryptographically protected. It MUST be ensured that only administrators can boot the clients from media other than the preset drives or external storage media. ONLY administrators MUST be able to boot from removable or external storage media. The configuration settings of the boot process MUST NOT be able to be changed by anyone other than administrators. All unnecessary functions in the firmware of the client system MUST be deactivated.

SYS.2.1.A42 Use of Cloud and Online Functions (B) [Users]

ONLY absolutely necessary cloud and online functions of the operating system MAY be used. The necessary cloud and online functions SHOULD be documented. The corresponding operating system settings MUST be checked for compliance with the organizational data protection and security requirements and configured restrictively or the functions deactivated.

Standard Requirements

Together with the basic requirements, the following requirements reflect the state of the art for this building block. They SHOULD generally be fulfilled.

SYS.2.1.A9 Definition of a Security Policy for Clients (S)

Based on the institution’s general security policy, the requirements for general clients SHOULD be specified in concrete terms. The policy SHOULD be known to all users and all persons involved in the procurement and operation of the clients, and SHOULD form the basis of their work. Compliance with the content required in the policy SHOULD be regularly reviewed. The results SHOULD be documented in a traceable manner.

SYS.2.1.A10 Planning the Deployment of Clients (S)

The deployment of clients SHOULD be planned in advance with regard to where and how they are to be used. Planning SHOULD address not only aspects typically directly associated with IT or information security, but also operational aspects that give rise to security requirements. All decisions made during the planning phase SHOULD be documented in such a way that they can be traced at a later point in time.

SYS.2.1.A11 Procurement of Clients (S)

Before clients are procured, a requirements list SHOULD be created against which available products on the market are evaluated. The respective manufacturers of the IT system and operating system SHOULD provide patches for vulnerabilities in a timely manner throughout the planned period of use. Operating systems that are updated via a rolling release model SHOULD be avoided. The systems to be procured SHOULD have a firmware configuration interface for UEFI SecureBoot and, if present, for the TPM that ensures control by the institution, thus enabling self-managed operation of SecureBoot and the TPM.

SYS.2.1.A12 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.1.A13 Access to Execution Environments with Unobservable Code Execution (S)

Access to execution environments with unobservable code execution (e.g., memory areas specially secured by the operating system, firmware areas, etc.) SHOULD only be possible with administrative privileges. The corresponding settings in the BIOS or UEFI firmware SHOULD be protected against unauthorized modifications by a password. If control over these functions is delegated to the operating system, access to the functions SHOULD also only be permitted there with administrative privileges.

SYS.2.1.A14 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.1.A15 Secure Installation and Configuration of Clients (S)

It SHOULD be specified which components of the operating system, which specialist applications, and which other tools are to be installed. The installation and configuration of IT systems SHOULD only be carried out by authorized persons (administrators or contractually bound service providers) following a defined process in an installation environment. After installation and configuration are complete, the default settings SHOULD be reviewed. If the installation and configuration comply with the requirements of the security policy, the clients SHOULD then be put into operation in the production environment. All installation and configuration steps SHOULD be documented in such a way that they can be traced and repeated by competent third parties.

SYS.2.1.A16 Deactivation and Uninstallation of Unnecessary Components and Identifiers (S)

After installation, it SHOULD be checked which firmware and operating system components, applications, and other tools are installed and activated on the clients. Unnecessary modules, programs, services, tasks, and firmware functions (such as remote maintenance) SHOULD be deactivated or completely uninstalled. Unnecessary runtime environments, interpreter languages, and compilers SHOULD be uninstalled. Unnecessary identifiers SHOULD be deactivated or deleted. Unnecessary interfaces and hardware of the IT system (such as webcams) SHOULD be deactivated. It SHOULD be prevented that these components can be reactivated. The decisions made SHOULD be documented in a traceable manner.

SYS.2.1.A17 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.1.A18 Use of Encrypted Communication Connections (S)

Communication connections SHOULD be protected by encryption wherever possible.

Clients SHOULD use cryptographic algorithms and key lengths that correspond to the state of the art and the security requirements of the institution.

New certificates from certificate authorities SHOULD only be activated after verifying the fingerprint.

SYS.2.1.A19 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.1.A20 Protection of Administration Procedures for Clients (S)

Depending on whether clients are administered locally or via the network, appropriate security precautions SHOULD be taken. The procedures used for administration SHOULD comply with the specifications defined in the security policy.

SYS.2.1.A21 Prevention of Unauthorized Use of Computer Microphones and Cameras (S)

Access to the microphone and camera of a client SHOULD only be possible for users themselves while they are working locally on the IT system. If existing microphones or cameras are not being used and their misuse is to be prevented, they SHOULD, where possible, be switched off, covered (cameras only), deactivated, or physically disconnected from the device. Rules SHOULD be established regarding how cameras and microphones in clients are used and how access rights are assigned.

SYS.2.1.A22 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.1.A23 Preference for Client-Server Services (S)

Where possible, dedicated server services SHOULD be used for information exchange and direct connections between clients SHOULD be avoided. If this is not possible, it SHOULD be specified which client-to-client services (often also referred to as “peer-to-peer”) may be used and what information may be exchanged via them. If required, users SHOULD be trained in the use of such services. Direct connections between clients SHOULD be limited to the LAN. Auto-discovery protocols SHOULD be restricted to the necessary minimum.

SYS.2.1.A24 Handling External Media and Removable Storage (S)

Access to external interfaces SHOULD only be possible in a restrictive manner. It SHOULD be prohibited for unauthorized devices or removable media to be connected to the clients. It SHOULD be prevented that clients can access removable media from untrustworthy sources. The unauthorized execution of programs on or from external data storage SHOULD be technically prevented. It SHOULD be prevented that data can be copied from clients without authorization via removable drives or external interfaces.

SYS.2.1.A25 DISCONTINUED (S)

This requirement has been discontinued.

SYS.2.1.A26 Protection Against Exploitation of Vulnerabilities in Applications (S)

To make it more difficult to exploit vulnerabilities in applications, ASLR and DEP/NX SHOULD be activated in the operating system and used by applications. Security functions of the kernel and standard libraries such as heap and stack protection SHOULD be activated.

SYS.2.1.A27 Regulated Decommissioning of a Client (S)

When decommissioning a client, it SHOULD be ensured that no data is lost and that no sensitive data remains. There SHOULD be an overview of which data is stored where on the IT systems. A checklist SHOULD be created that can be worked through when decommissioning an IT system. This checklist SHOULD cover at minimum aspects relating to the backing up of data that is still needed and the subsequent secure deletion of all data.

SYS.2.1.A34 Encapsulation of Security-Critical Applications and Operating System Components (S)

To prevent both access to the operating system or other applications during attacks and access from the operating system to particularly sensitive files, applications and operating system components (such as authentication or certificate verification) SHOULD be encapsulated according to their protection needs or isolated from other applications and operating system components. In doing so, security-critical applications that work with data from insecure sources (e.g., web browsers and office communication applications) SHOULD be given particular consideration.

SYS.2.1.A43 Local Security Policies for Clients (S)

All security-relevant settings SHOULD be configured, tested, and regularly reviewed as needed. For this purpose, security policies SHOULD be configured, taking into account the recommendations of the manufacturer and the default behavior, provided the default behavior does not conflict with other requirements from IT-Grundschutz or the organization. The decisions SHOULD be documented and justified. Security policies SHOULD be set in any case, even when the default behavior is not thereby changed.

SYS.2.1.A44 Management of Security Policies for Clients (S)

All client settings SHOULD be managed using a management system and configured in accordance with the identified protection needs and based on internal policies. Configuration changes SHOULD be documented, justified, and coordinated with security management so that the state of the security configuration is traceable at all times and configuration changes can be implemented quickly and distributed centrally.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the protection level corresponding to the state of the art. The proposals SHOULD be considered in the case of high protection needs. The specific determination is made within the framework of an individual risk analysis.

SYS.2.1.A28 Encryption of Clients (H)

If confidential information is stored on clients, at minimum the sensitive files and selected file system areas, or better yet the entire data storage media, SHOULD be encrypted. A dedicated concept SHOULD be created for this purpose and the configuration details SHOULD be documented with particular care. In this context, authentication (e.g., password, PIN, token), the storage of recovery information, the drives to be encrypted, and write permissions to unencrypted storage media SHOULD be regulated. Access to the key material used MUST be adequately protected.

Users SHOULD be informed about how to proceed in the event of losing an authentication means.

SYS.2.1.A29 System Monitoring and Monitoring of Clients (H)

Clients SHOULD be integrated into an appropriate system monitoring or monitoring concept that continuously monitors the system status and functionality of the clients and reports error states as well as the exceeding or falling below of defined threshold values to operating personnel.

SYS.2.1.A30 Setting Up a Reference Environment for Clients (H)

A reference installation SHOULD be created for clients in which the basic configuration and all configuration changes, updates, and patches can be tested before being applied to the client. For various, typical, and frequently recurring test cases, checklists SHOULD be created that should be worked through as automatically as possible during the test run. The test cases SHOULD take into account both the user and the operational perspective. In addition, all tests SHOULD be documented in such a way that they can be traced at a later point in time.

SYS.2.1.A31 Setting Up Local Packet Filters (H)

On each client, local packet filters SHOULD be used in addition to the central security gateways in use. An implementation strategy SHOULD be chosen that explicitly permits only required network communication.

SYS.2.1.A32 Use of Additional Measures for Protection Against Exploits (H)

Additional measures for explicit protection against exploits (attacks to exploit system vulnerabilities) SHOULD be taken on clients. If necessary protective measures cannot be implemented via operating system functions, additional appropriate security measures SHOULD be implemented. If it is not possible to implement sustainable measures, other appropriate (generally organizational) security measures SHOULD be taken.

SYS.2.1.A33 Use of Execution Control (H)

Execution control SHOULD be used to ensure that only explicitly permitted programs and scripts can be executed. The rules SHOULD be defined as narrowly as possible. If paths and hashes cannot be explicitly specified, certificate-based or path-based rules MAY alternatively be used.

SYS.2.1.A35 Active Management of Root Certificates (H)

During the procurement and installation of the client, it SHOULD be documented which root certificates are necessary for the operation of the client. The client SHOULD contain only the root certificates that are necessary for operation and have been previously documented. It SHOULD be regularly checked whether the existing root certificates still comply with the institution’s requirements. All certificate stores present on the IT system SHOULD be included in the review (e.g., UEFI certificate store, certificate stores of web browsers, etc.).

SYS.2.1.A36 Self-Managed Use of SecureBoot and TPM (H)

On UEFI-compatible systems, bootloaders, kernels, and all required firmware components SHOULD be signed using self-controlled key material. Key material that is not required SHOULD be removed. If the Trusted Platform Module (TPM) is not required, it SHOULD be deactivated.

SYS.2.1.A37 Use of Multi-Factor Authentication (H)

Secure multi-factor authentication involving different factors (knowledge, possession, inherence) SHOULD be set up for local logon to the client, e.g., password with chip card or token.

SYS.2.1.A38 Integration into Emergency Planning (H)

Clients SHOULD be taken into account in the emergency management process. Clients SHOULD be prioritized for restart with regard to the business processes or professional tasks for which they are required. Appropriate emergency measures SHOULD be provided by at minimum creating restart plans, generating boot media for system recovery, and securely storing passwords and cryptographic keys.

SYS.2.1.A39 Uninterruptible and Stable Power Supply (H) [Facility Management]

Clients SHOULD be connected to an uninterruptible power supply (UPS). The UPS SHOULD be dimensioned adequately in terms of output and buffer time. Clients SHOULD be protected against overvoltage.

SYS.2.1.A40 Operational Documentation (H)

The execution of operational tasks on clients or groups of clients SHOULD be documented traceably based on the questions “Who?”, “When?”, and “What?”. Configuration changes in particular SHOULD be traceable from the documentation. Security-relevant tasks (e.g., who is authorized to install new hard drives) SHOULD also be documented. Everything that can be automatically documented SHOULD also be automatically documented. The documentation SHOULD be protected against unauthorized access and loss. Security-relevant aspects SHOULD be explained and highlighted in a traceable manner.

SYS.2.1.A41 Use of Quotas for Local Storage Media (H)

Consideration SHOULD be given to setting up quotas that limit the storage space used on the local hard drive. Alternatively, mechanisms of the file or operating system used SHOULD be used that warn users when the hard drive reaches a certain fill level or grant write permissions only to administrators.

SYS.2.1.A45 Extended Logging (H)

Client behavior that is not directly related to security SHOULD also be logged and evaluated promptly (automatically) in order to be able to detect covert activities related to attacks.

Additional Information

Good to Know

There is no additional information for building block SYS.2.1 General Client.