S 4.241 Secure operation of clients

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

The secure operation of clients depends on a number of factors. With clients it is also especially important that administration be performed with great care and via a secure access.

In the following, several general points are described that should be observed to securely operate clients regardless of the operating system. More specific information for individual operating systems is given in the corresponding safeguards of the applicable modules.

Administration accesses

There are different ways to access clients for administration purposes. Depending on the type of access used, a number of security precautions must be taken. With larger networks, it is recommended, and often absolutely necessary, to also integrate the clients in a central network management system, because otherwise secure and efficient administration cannot be ensured. The methods applied for administration should be specified in the security policy, and administration may only be performed in accordance with the security policy.

It is advisable to draw up an overview for the different types of administrative tasks and which ones can be performed in which way. It is especially important to specify whether certain tasks may normally not be performed in a certain manner.

• Local administration
  
  The direct administration of clients by accessing them via the console is only viable for a small number of computers and will usually be the exception in environments with a larger number of clients. If, as an exception, an administrator must work locally on a client computer, it is important that he/she cannot be spied upon when entering the password. In some cases, you should consider using one-off passwords or similar precautions.
• Administration with the help of a boot medium
  
  For certain administration tasks that are to be performed locally on a client computer, it can be advantageous to use an external boot medium to boot the computer (see also S 6.24 Creating an emergency boot medium). This has the advantage that the administrator can be sure of a "clean" system environment. However, this method also entails a number of drawbacks, for example, increased effort. In addition, it is not possible in this manner to reconstruct certain error messages that occur during operation.
• Remote administration clients are frequently administrated from an administrator computer via the network. To prevent authentication information of the administrators from being intercepted or even manipulated by an attacker, administration should only be performed via secure protocols (e.g. not via Telnet, but via SSH; not via HTTP, but via HTTPS).

Unprotected remote administration via external (unprotected) networks must never be performed. This must be taken into consideration when defining the security policy. No insecure protocols should be used in the internal network either.

• Administration via a central management system
  
  If a central management system is to be used for administration, analogous considerations as with remote administration have to be made in regard to this access channel. It is furthermore important that the central management system itself is securely configured and administrated.

Routine administrative activities

It is advisable to draw up notes on the administrators' usual routine activities in accordance with the security policy. This includes activities such as:

• creating and deleting users,
• installing and uninstalling programs,
• installing security updates and patches (see also S 2.273 Prompt installation of security-relevant patches and updates),
• installing other updates and patches, or
• regular integrity checks using appropriate tools (see also S 4.93 Regular integrity checking and S 5.8 Regular security checks of the network).

Testing configuration changes

If possible, configuration changes to clients should be tested on a reference system before being distributed to the individual computers (see also S 4.242 Setting up a reference installation for clients). If (e.g. in the framework of error search) changes are made locally to individual clients, whether the changes have an impact on the client's other functions must be checked.

Documentation of work performed on the systems

Changes to the system configuration of the clients or to the configuration of applications must be documented. With clients, the documentation should also be drawn up in such a way that, if problems occur, the reconstruction of the last change and of when and by whom it was made is possible. With clients not subject to high

security requirements, the documentation of individual functioning configuration states (e.g. at certain points in time) can suffice, without the necessity of having to be able to reconstruct each individual step. But it is still advisable to draw up the documentation in such a way that all changes can be reconstructed.

Logs

Security-relevant events occurring with clients should be logged for many reasons. On the one hand, when logging is activated it can be used for early detection and elimination of potential weaknesses. On the other hand, logging can be used to promptly detect violations against security specifications or to obtain more information about a security incident. Logging of clients should be integrated into the logging concept (see S 2.500 Logging IT systems).

Review questions:

• Are the methods applied for administration of clients described in the security policy?
• Are only secure protocols used for remote administration or use of a management system?
• Are there specifications regarding the documentation of changes and are these implemented?