SYS.2.1 General Client

In order to use a client, users MUST be authenticated by the corresponding IT system. Users MUST use a screen lock when leaving their clients running without supervision. The screen lock SHOULD be activated automatically if no action has been taken by the user for a set period of time. Successful user authentication MUST be the only way to disable a screen lock. Users SHOULD be required to log out of IT systems and applications after completing their tasks.

Automatic update mechanisms 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, there SHOULD be an automatic search for updates at least daily and they SHOULD be installed when found.

Depending on the operating system installed and other protection mechanisms of a given client, it MUST be checked whether malware protection programs should be used. Where available, concrete statements from the operating system modules of the IT-Grundschutz Compendium on whether such virus protection is necessary MUST be considered.

Protection programs on clients MUST be configured so that users cannot disable such programs or make any security-relevant changes to their settings.

Protection programs MUST search for malware when files are exchanged or transmitted. All the data on clients MUST be checked regularly for malware. If a client is infected, it MUST be examined in offline mode to determine whether the detected malware has already collected confidential data, disabled any protective functions, or downloaded any code from the Internet, for example.

The start-up procedure (boot process) of IT systems MUST be protected against manipulation. The media that can be used to boot a given system MUST be defined. A decision SHOULD be taken as to whether and how the boot process is to be protected cryptographically. It MUST be ensured that only administrators can boot clients from anything other than the default drive, or from an external storage medium. The ability to boot IT systems from removable or external storage media MUST be restricted to administrators. The ability to change the configuration settings of boot processes MUST also be restricted to administrators. All unused functions in firmware MUST be disabled.

The use of the cloud and online functions of client operating systems MUST be restricted to those absolutely required. Necessary cloud and online functions SHOULD be documented. The corresponding settings of the operating system at hand MUST be checked for conformity with organisational data protection and security specifications and be configured restrictively; otherwise, such functions MUST be disabled.

On the basis of an organisation's general security policy, requirements for general clients SHOULD be specified. The policy SHOULD be known to all users and all persons involved in the procurement and operation of clients and be integral to their work. The implementation of the policy's requirements SHOULD be checked at regular intervals. The results SHOULD be documented in a transparent manner.

Where and how clients are to be used SHOULD be planned in advance. This planning SHOULD not only address aspects typically associated directly with information security, but also operational aspects that entail requirements in the area of security. All decisions taken in the planning phase SHOULD be documented in such a way that they can be understood at any future point in time.

Before clients are procured, a requirements list SHOULD be drawn up that can be used to evaluate the products available on the market. The manufacturers of IT and operating systems SHOULD be expected to provide patches for vulnerabilities promptly throughout the planned duration of use. The systems to be procured SHOULD have a firmware configuration interface for UEFI SecureBoot and for TPM (if available), which allows for control by the owner (organisation) and thereby facilitates the self-managed operation of SecureBoot and TPM.

Access to runtime environments with unmonitored code execution (storage areas specifically secured by the operating system, firmware areas, etc) SHOULD only be granted to users with administrative rights. The corresponding settings in the BIOS or the UEFI firmware SHOULD be protected against unauthorised changes by a password. If control of the functions in question is delegated to the operating system, the ability to access the functions there SHOULD be restricted to users with administrative authorisations.

Operating systems that are updated via a rolling release model SHOULD be avoided. Only application programs for which support is offered SHOULD be selected and installed. Operating systems, application programs, and firmware for which regular security updates are not offered MUST NOT be used.

Operating system components, specialised applications, and other tools to be installed SHOULD be specified. The installation and configuration of IT systems SHOULD only be performed by authorised persons (administrators or service providers bound by contract) according to a defined installation process in a specific installation environment. After installation and configuration have been completed, the basic settings SHOULD be checked. Provided that the installation and configuration meet the requirements of the security policy at hand, the clients SHOULD then be put into operation in the respective production environment. All installation and configuration steps SHOULD be documented in such a way that they can be understood and repeated by a competent third party.

Firmware and operating system components, applications, and other tools that are installed and activated on clients SHOULD be checked after installation. Unnecessary modules, programs, services, tasks, and firmware functions (like remote maintenance) SHOULD be disabled or removed. Unnecessary runtime environments, interpreter languages, and compilers should also be removed. Unnecessary user IDs SHOULD be disabled or deleted. Unnecessary interfaces and IT system hardware (like webcams) SHOULD be disabled. The reactivation of these components SHOULD be prevented. The decisions taken in this regard SHOULD be documented in a comprehensible manner.

Communication SHOULD be protected by encryption whenever possible.

Clients SHOULD use cryptographic algorithms and key lengths that conform to the current state of the art and meet the security requirements of the organisation in question.

New certificates from certificate issuers SHOULD only be used after their fingerprints are checked.

Adequate security precautions SHOULD be taken based on whether clients are administrated locally or via a network. The procedures used for administration SHOULD conform to the specifications of the applicable security policy.

Access to a client's microphone and camera SHOULD only be available to the users themselves while they are working locally on the corresponding IT system. If a microphone or camera is not used and its misuse is to be prevented, it SHOULD be switched off, covered (camera only), disabled, or physically disconnected from the respective device whenever possible. Rules SHOULD be specified on how cameras and microphones in clients are to be used and how the related rights are to be assigned.

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

Interfaces to external networks SHOULD ONLY be accessible in a restricted manner. Connecting unauthorised devices or removable media to clients SHOULD be prohibited. Clients SHOULD generally be prevented from accessing removable media from untrusted sources. The unauthorised execution of programs on or from external storage media SHOULD be technically prevented. Copying unauthorised data from clients via removable drives or external interfaces SHOULD be prevented.

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

When decommissioning a client, it SHOULD be ensured that no data is lost and no sensitive data remains. There SHOULD be an overview of the data stored on IT systems, along with the respective locations. A checklist which can be completed when decommissioning an IT system SHOULD be created. This checklist SHOULD, at minimum, include aspects of backing up data that is still needed and the subsequent secure deletion of all data.

In order to prevent an attacker from accessing the operating system or other applications and prevent access from the operating system to files that are particularly sensitive, applications and operating system components (such as authentication or certificate verification) SHOULD be specially encapsulated according to their protection needs or isolated from other applications and operating system components. Particular attention SHOULD be paid to security-critical applications that work with data from insecure sources (e.g. web browsers and office communication applications).

All security-relevant settings SHOULD be configured, tested, and regularly checked as needed. To this end, security policies SHOULD be configured that take into account the recommendations of the respective operating system manufacturer and the client's default behaviour, provided that this behaviour does not contradict other requirements of IT-Grundschutz or the organisation in question. The decisions taken in this regard SHOULD be documented and justified. Security policies SHOULD be defined in any case, even if the client's default behaviour is not changed.

All client settings SHOULD be administered using a management system and configured according to the identified protection needs and the internal policies at hand. Configuration changes SHOULD be documented, justified, and coordinated with the relevant security management personnel so that they can be carried out quickly and distributed in a centralised manner. It SHOULD also be possible to trace the status of security configurations at any time.

If confidential information is stored on clients, at least the sensitive files and select areas of the file system—or better yet, all storage media—SHOULD be encrypted. A separate concept SHOULD be developed for this and special care should be taken when documenting the details of the configuration. In this context, authentication (by means of passwords, PINs, tokens, etc), the storage of recovery information, the drives to be encrypted, and the write permissions to unencrypted media SHOULD be regulated. Access to the key material used MUST be adequately protected.

Users SHOULD be informed of the steps they should take if they lose authentication resources.

Clients SHOULD be integrated into a suitable system monitoring concept that continuously monitors their system status and functionality while also reporting error conditions and any threshold violations to the respective operating personnel.

A reference installation SHOULD be set up for clients in which basic configurations and all configuration changes, updates, and patches can be tested before they are installed on clients. Checklists SHOULD be created for various typical and frequently recurring test cases which should be processed as automatically as possible during test runs. 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 reconstructed at a later point in time.

In addition to the central security gateways used, local packet filters SHOULD be used on all clients. A packet filter implementation strategy SHOULD be selected that explicitly only allows network communication that is necessary.

Additional safeguards SHOULD be implemented on clients as explicit protection against exploits of system vulnerabilities. If necessary security safeguards cannot be implemented via operating system functions, additional suitable security safeguards SHOULD be implemented. If it is not possible to implement sustainable safeguards, other suitable (generally organisational) security safeguards SHOULD be implemented.

Execution control SHOULD be used to ensure that only explicitly authorised programs and scripts can be executed. The rules SHOULD be set as restrictively as possible. If explicit specification of paths and hashes is not possible, certificate-based or path rules SHOULD be used as an alternative.

As part of the procurement and installation of clients, the root certificates required for their operation SHOULD be documented. Only the previously documented root certificates required for operation SHOULD be present on clients. Regular checks SHOULD be performed as to whether existing root certificates still comply with the respective organisation’s requirements. All certificate stores available on an IT system (e.g. UEFI certificate stores, certificate stores of web browsers) SHOULD be included in these checks.

On UEFI-compatible systems, the bootloader, kernel, and all required firmware components SHOULD be signed by self-controlling key material, and any key material that is not required SHOULD be removed. If Trusted Platform Module (TPM) is not required, it SHOULD be disabled.

Secure authentication involving multiple different factors (knowledge, possession, property) SHOULD be established for logging into clients locally (e.g. using a password with a chip card or token).

Clients SHOULD be taken into account in business continuity management processes. Clients SHOULD be prioritised for restoration of service in terms of the business processes or specialised tasks for which they are needed. At minimum, suitable business continuity safeguards SHOULD be implemented by drawing up recovery plans, generating boot media for system recovery, and securely storing passwords and cryptographic keys.

Clients SHOULD be connected to an uninterruptible power supply (UPS). The UPS SHOULD have sufficient capacity in terms of its output power and backup time. Clients SHOULD be protected against overvoltage.

The performance of operational tasks on clients or groups of clients SHOULD be documented in a transparent manner with regard to who has done what and when. In particular, the documentation SHOULD make configuration changes transparent. Security-relevant responsibilities (e.g. who is authorised to install new hard disks) SHOULD also be documented. Everything that can be documented automatically SHOULD be documented automatically. The documentation SHOULD be protected from unauthorised access and loss. Security-relevant aspects SHOULD be explained and highlighted in a transparent way.

Consideration SHOULD be given to setting up quotas that limit the space used on local disks. As an alternative, mechanisms of the file or operating system in question should be used that warn users if the hard drive capacity reaches a specific level or only grant write privileges to the system administrator.

Client behaviour that is not directly related to security SHOULD also be logged and immediately evaluated (in an automated way) to detect covert attacker activity.