S 2.316 Defining a security policy for a general server

Initiation responsibility: IT Security Officer, Head of IT

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

The security provisions for each server result from the organisation-wide security policy. Based on the general policy, the requirements must be put into concrete terms for the present context and summarised in a security policy for the server or a group of servers. In this context, it must be examined whether there are any other overriding specifications, for example IT guidelines, password rules, and specifications for internet usage, that must be taken into account in addition to the organisation-wide security policy.

All persons and groups participating in the purchasing and operation of the servers must be familiar with the security policy and follow it while working. Like all guidelines, 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 attained and provide basic information on the operation of the server. 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 servers which only store and process data with normal protection requirements, a relatively liberal strategy may 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 servers storing or processing data with high protection requirements, a restrictive strategy is recommended as a matter of principle. For servers with special protection requirements regarding one of the three basic values, a restrictive configuration and administration strategy should be implemented.

The following sections contain some items to be taken into consideration:

• Regulations regarding physical data access control: As a matter of principle, a server should be installed in a lockable computer room or server cabinet. Here, it must be specified who is granted access to the room or data access to the server.
• Rules for the work of the administrators and auditors:
  • According to which scheme are administration rights assigned? Which administrator may execute which rights and how is he/she granted these right
  • Over which access routes are the administrators and auditors allowed to access the systems (for example, only locally on the console, using a separate administration network, or using encrypted connections)?
• Specifications for installation and basic configuration
  • Which installation media are used for installation?
  • Should a central authentication service be used or are users administrated and authorised only locally?
  • Rules for the administration of the users and roles, authorisation structures (procedures and methods of authentication and authorisation, authorisations for installation, updates, configuration changes, etc.). If possible, a role concept should be drawn up for administration.
  • Specifications for the software packages to be installed.
  • If it has been specified while planning the server that parts of the file system are to be encrypted, it is recommendable to define at this point how this must be performed:
    
    • Which parts of the file system are to be encrypted?
    • Which mechanism should be used for integrating the encrypted file system?
    • Which encryption algorithms and key lengths should be used?
    • Which data should be stored to the encrypted file systems?
    • How are the encrypted file systems integrated into the backup.
    For this, it is recommendable to draw up a separate concept when using encrypted file systems and to document the configuration details particularly thoroughly, since the data on the encrypted file systems may be lost completely in the event of problems (loss of the key or the passphrase for the key, incorrect configuration, and such like).
  • Rules for drawing up and maintaining documentation
• Specifications for secure operation
  • Which group of users may log in to the system locally?
  • Which users are granted access via the network? -which protocols may be used?
  • Which resources are the users granted access for?
• Specifications for the use of passwords (password rules, rules and situations for changing passwords, possible escrow of passwords)
  • Who may shut down the system?
• Network communication and services
  • Should a local packet filter be integrated?
  • Should a local packet filter be integrated?
  • Which network services are offered by the server?
  • Which authentication procedures should be selected for the offered services?
  • Which external network services should be accessible from the computer?
  • Should a distributed file system be integrated?
    Distributed file systems where the user data is transmitted without encryption should only be used in the internal network. If a distributed system is to be used across an insecure network, it must be protected with the help of additional safeguards (cryptographically protected VPN, tunnelling).
• Logging
  • Which events are logged?
  • Where are the log files stored? Are the log files stored locally or should a central server be used the individual systems in the network send their logging information to?
  • How and at which intervals are the logs evaluated?
  • Who has access to the log files?
  • Is it ensured that personal information is not disclosed to unauthorised persons?
  • How long should be log files be stored?

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

The security management team is responsible for the security policy; changes to and deviations from which must only be performed upon consultation with the security management team.

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. For every specification rejected or relaxed in the second step, the reasons for the specification not being taken into consideration should be documented.

Review questions:

• Is there a security policy specifying the defined level of security for server operation?
• Does the security policy take into consideration all strategies, specifications, and regulations required for attaining the level of security aimed at?
• Are the contents and the implementation of the security policy updated regularly and checked technically?