S 2.322 Defining a security policy for a client/server network

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: IT Security Officer, Administrator, Head of IT

The security specifications for all clients result from the organisation-wide security policy. Based on this general policy, the requirements must be specified for the given context and summarised in a security policy for the respective group of clients. In this context, it must be checked whether further, generic stipulations such as IT policies, password policies or Internet usage policies must be taken into consideration, in addition to the organisation-wide security policy.

The security policy must be known to all users and other persons involved in the procurement and operation of the clients, and must form the foundation of their work. Like all policies, its contents and its implementation should be examined regularly within the framework of a general audit.

The security policy should specify the overall security level to be achieved and establish fundamental definitions. In order to improve the clarity, it may make sense to draw up separate security policies for different fields of application.

First of all, the general configuration and administration strategy ("liberal" or "restrictive") should be specified, as the other decisions will mainly depend on this specification.

For clients with normal protection requirements, a relatively liberal strategy can be selected making the configuration and administration much easier in many cases. However, it is generally also recommendable in these cases to design the strategy only "as liberal as required".

For clients with high protection requirements, a restrictive strategy is generally recommended. For clients with special protection requirements regarding one of the three basic values, a restrictive configuration and administration strategy should be implemented.

Some points which should be taken into account are listed below:

• Rules for the work of the client users:
  • Is the client only to be used by a single user or are changing users going to operate the system?
  • May users modify certain configuration settings themselves (e.g. screen background, screen saver, or similar things) or are all settings made centrally?
  • Should users by denied access to certain parts of the system?
  • These specifications usually have an impact on the assignment of rights in the system itself and on the specifications for installation and basic configuration.
  • Which information may be stored locally on the clients by the users? In general, all business-related information should be stored centrally on a server where it is backed up regularly. Otherwise it must be ensured that all information of the users which is stored locally on the clients is considered in the data backup concept of the client.
  • Are users asked to shut down and switch off their computer in the evenings, or must it be in operation around the clock?
    Fire protection and energy saving speak for switching off the client computers after work. Moreover, the hard drives in client computers are usually not suitable for continuous operation. However, continuous operation of the computer can be desirable, e.g. for the purpose of running automatic data backups overnight or using the computer for other applications.

• Rules for the work of the administrators and auditors:
  • According to which scheme are administrator rights assigned?
  • Which administrator may make use of which rights and how does he or she attain these rights?
  • Via which access channels may administrators and auditors access the systems?
  • Which procedures and events must be documented? In which form is the documentation drawn up and maintained?
  • Are certain changes subject to the four-eye principle?
• Specifications for installation and basic configuration:
  • Which installation media are used for installation?
  • Should a central authentication service be used or should user administration and authentication only be performed locally?
  • Rules regarding user and role management, authorisation structures (sequence and methods of authentication and authorisation, permissions to perform installations, updates, configuration changes etc.). If possible, a role concept for administration should be drawn up. The use of collective accounts used by different users with the same ID is not allowed.
  • Specifications for the software packages to be installed
  • If it was determined during client planning that parts of the file system are to be encrypted, how this is to be performed should be specified at this point.
  • When using encrypted file systems, a separate concept should be drawn up and the configuration details should be carefully documented, because in case of problems (loss of the key or the passphrase to the key, incorrect configuration, etc.) the data on the encrypted file systems could be completely lost.
  • Rules on drawing up and maintaining documentation
• Specifications for secure operation:
  • Which group of users may log on to the system?
  • How can the users authenticate themselves to the IT system? In general, automatic log-in where users are logged in when starting up the client without active authentication should not be used.
  • Are users granted access to one or more LANs, or to the Internet?
  • Which protocols may be used? With clients that are used as workstations in an organisation, it is usually not necessary and often not even desirable that normal users access other workstations via the network.
  • Which resources are the users permitted to access?
  • Specifications for password use must be drawn up (password rules, rules and situations for password changes, and, if applicable, storage of passwords).
  • Who is permitted to shut down the system?
  • Should the system be provided with a boot lock that prevents booting from external media such as diskettes, CD-ROMs or USB memory sticks?
  • It is advisable to provide such a lock for normal operation, which can only be released by the administrator within the scope of searching for and eliminating malfunctions by booting the system from the emergency boot medium (see S 6.24 Creating an emergency boot medium).
• Network communication and services:
  • Should a local packet filter be used?
  • Which external network services should be accessible from the computer?
  • Should a distributed file system be integrated?
  • Distributed file systems in which usage data are transmitted unencrypted should only be used in the internal network. In case a distributed file system is to be used across an insecure network, it must be secured by additional measures (cryptographically protected VPN, tunnelling).
• Logging:
  • Which data are logged? How and at which intervals are log data evaluated? Who performs the evaluation?

Based on the items mentioned above, a checklist that may be helpful during audits can be drawn up.

Security management is responsible for the security policy. Changes and deviations to this policy may only be made in agreement with security management.

When drawing up a security policy, it is recommended to proceed in such a way that the maximum requirements and specifications for the security of the systems are stated initially. These may then be adapted to the actual circumstances. Ideally, it will be possible to take into account all aspects necessary. Reasons should be documented for each specification that was rejected or weakened in the second step.

With regard to rules applying to the users, it should be noted that they are only appropriate if they can be applied to normal everyday work and can be monitored and enforced. For example, it doesn't make sense to forbid users access to certain directories according to the security policy, but to then not actually protect these directories from being accessed by assigning the corresponding access rights. Therefore, access restrictions defined by the security policy should always be implemented, as far as possible, by means of corresponding specifications made in regard to the installation and configuration of the computers.

When formulating the security policy for the clients, it is important that a balance is kept between security (through restrictions of functionality and the restrictive assignment of user rights) and user-friendliness. If users feel they are too restricted by regulations which are not transparent for them and which they may even deem as harassment, they could be tempted, in turn, to creatively bypass these restrictions.

This distinguishes the security policy for clients from the corresponding policies for servers and active network components, which usually only address technologically experienced users and administrators who tend to show understanding for many restrictions.

Review questions:

• Does a client security policy exist that describes the security level to be achieved?
• Is the client security policy regularly adapted to the current requirements?