SYS.1.1 General Server

Description

Introduction

A “General Server” refers to IT systems with any operating system that provide services to users and other IT systems. These services may be basic services for the local or external network, or they may enable email exchange or offer database and printer services. Server IT systems are of central importance to information technology and thus to the functioning workflows of an institution. Servers often perform tasks in the background without users directly interacting with them. On the other hand, there are server services that interact directly with users and are not immediately perceived as a server service. A well-known example is X-servers under Unix.

Objective

The objective of this building block is to protect information that is processed, offered, or transmitted on servers, as well as to protect the associated services.

Scope and Modeling

The building block SYS.1.1 General Server is to be applied to all server IT systems with any operating system.

As a rule, servers are operated under operating systems for which specific security requirements must be observed. For common server operating systems, dedicated building blocks exist in the IT-Grundschutz Compendium that build on the present building block. SYS.1.1 General Server forms the foundation for the building blocks covering specific server operating systems. If a specific building block exists for the IT system under consideration, it must be applied in addition to SYS.1.1 General Server. If no specific building block exists for the server operating systems in use, the requirements of the present building block must be appropriately tailored to the target object and a supplementary risk assessment must be carried out.

The specific services offered by the server are not part of this building block. For these server services, additional building blocks must be implemented in addition to this one, in accordance with the results of the IT-Grundschutz modeling.

The provision of user sessions by terminal servers is also to be regarded as a service. For terminal servers, the building block SYS.1.9 Terminal Server must be modeled accordingly.

In general, the requirements regarding the role and authorization concept from building block ORP.4 Identity and Authorization Management must be taken into account. The requirements of building block DER.4 Emergency Management must also be considered.

Servers should generally be included in the concept for protection against malware. Requirements for this can be found in building block OPS.1.1.4 Protection Against Malware.

Servers have special requirements for administration and the handling of patches and changes. Therefore, the requirements of building blocks OPS.1.1.2 Proper IT Administration and OPS.1.1.3 Patch and Change Management must be observed.

Servers frequently offer services to a large number of clients, often also via the internet. For this reason, they must be particularly separated from the rest of the institution’s network. Requirements for this can be found in building block NET.1.1 Network Architecture and Design.

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.1.1 General Server.

Inadequate Planning

Servers are complex IT systems with a large number of functions and configuration options. Although modern server operating systems come with good default settings in many areas, the basic configuration is not always the most secure. Inadequate planning can lead to a large number of vulnerabilities and weaknesses due to misconfiguration, which unauthorized third parties can easily exploit. Furthermore, if key decisions are not made before installation, servers are often operated in an insecure and undefined state that is almost impossible to correct after the fact.

Incorrect Administration of Servers

New versions of server operating systems regularly introduce new functions compared to their predecessors. Even in existing features, sub-functions, parameters, or default configurations may change in new versions. If IT Operations at the institution is not sufficiently trained in the specifics of the operating systems, configuration errors and human mistakes are likely, which can affect not only the functionality but also the security of the IT system.

A particular risk is posed by inconsistent server security settings (e.g., for SMB, RPC, or LDAP). If the configuration is not systematically and centrally planned, documented, reviewed, and maintained, a so-called configuration drift may occur. The more the actual configurations of functionally similar systems diverge without justification and documentation, the harder it becomes to maintain an overview of the current state and to uphold security holistically and consistently.

Unauthorized Acquisition or Misuse of Administrative Rights

The regular use of administrative rights — such as completing tasks that could in principle be performed with standard permissions on a client system — represents a security risk on a server. If dedicated administrative accounts are not restricted to the minimum rights necessary for performing administrative tasks (Least Privilege principle), taking over such accounts can grant far-reaching rights on the server or other IT systems and cause considerable damage. Misuse of rights by legitimate administrators is also a relevant damage scenario. Since these roles are often very powerful, the impact is typically considerable — especially for so-called domain administrators. Even without guessing or breaking passwords, suitable credentials can be read and misused, for example through so-called pass-the-hash techniques, to move laterally within the network.

Data Loss

The loss of data can have significant consequences for business processes and professional tasks — and thus for the institution as a whole — particularly on servers. A great many IT systems such as clients or other servers typically depend on having the centrally stored data available at all times.

If institution-relevant information of any kind is destroyed or corrupted, business processes and professional tasks may be delayed or even prevented from being carried out at all. Overall, the loss of stored data — in addition to the outage and the costs of recovering the data — can above all lead to long-term consequences such as loss of trust in business relationships, legal implications, and a negative public perception. Many institutions have regulations stipulating that no data may be stored on local clients, and that central storage locations on servers must be used instead. In such a case, the loss of this centrally stored data has severe consequences. The direct and indirect damages caused can even threaten the existence of institutions.

Denial-of-Service Attacks

An attack on the availability of data stocks — called a “Denial of Service” — aims to prevent the use of required and normally available functions or devices. This type of attack is frequently associated with distributed resources. By making very heavy demands on these resources during attacks, normal access to them is no longer possible. As a rule, IT systems are also highly interdependent. Consequently, resource shortages on one server quickly affect other servers as well. For example, CPU time, storage capacity, or bandwidth can be artificially depleted. This can result in services or resources becoming completely unavailable.

Provision of Unnecessary Applications and Services

Even during the installation of the server operating system, it is possible to install bundled applications and services, some of which may not be used at all. During subsequent operation, software is also frequently installed for brief testing and then no longer needed. Often, it is not even known that these unused applications and services are present. In this way, numerous applications and services end up on servers where they serve no purpose and create unnecessary overhead.

Furthermore, these unused applications and services may contain vulnerabilities, for example if they are no longer updated. If the installed applications and services are unknown, the institution is not even aware that they also need to be updated. In this way, they can easily become entry points for attacks.

Server Overload

If servers are not adequately sized, there comes a point at which they can no longer meet the institution’s requirements. Depending on the type of affected IT systems, this can have a wide range of negative consequences. For example, servers or services may be temporarily unavailable, or data losses may occur. The overload of a single server can, in complex IT landscapes, also cause problems or failures on other servers.

Triggers for IT system overload can include:

• installed services or applications are misconfigured and therefore consume unnecessarily large amounts of memory,
• available storage capacity is exceeded,
• numerous requests at the same time overburden an IT system,
• services consume too much processing power, or
• an excessively large number of messages are sent at the same time.

Requirements

The following are the specific requirements of building block SYS.1.1 General Server. 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.1.1.A1 Access Protection and Use (B)

Physical servers MUST be operated in locations to which only authorized persons have access. Physical servers MUST therefore be installed or housed in data centers, server rooms, or lockable server cabinets (see the relevant building blocks of the INF Infrastructure layer). For virtualized servers, access to the instance’s resources and its configuration MUST also be restricted to authorized persons.

Servers MUST NOT be used as workstations. Servers MUST NOT be used to perform tasks that can in principle be carried out on a client system. In particular, available applications such as web browsers MUST NOT be used on the server to retrieve information from the internet or to download software, drivers, and updates.

IT systems used as workstations MUST NOT be used as servers.

SYS.1.1.A2 Authentication on Servers (B)

For the login of users and services on the server, authentication procedures MUST be used that are appropriate to the protection needs of the servers. This SHOULD be taken into account particularly for administrative access. Where possible, centralized, network-based authentication services SHOULD be used.

SYS.1.1.A3 DISCONTINUED (B)

This requirement has been discontinued.

SYS.1.1.A4 DISCONTINUED (B)

This requirement has been discontinued.

SYS.1.1.A5 Protection of Interfaces (B)

It MUST be ensured that only designated removable storage and other devices can be connected to the servers. All interfaces that are not in use MUST be deactivated.

SYS.1.1.A6 Deactivation of Unneeded Services (B)

All unneeded server roles, features and functions, other software, and services MUST be deactivated or uninstalled, especially network services. All unneeded functions in the firmware MUST also be deactivated. The recommendations of the operating system vendor SHOULD be taken into account as a reference.

On servers, the storage space for individual users, as well as for applications, SHOULD be appropriately restricted.

The decisions made SHOULD be documented in such a way that it is traceable which configuration and software configuration was chosen for the servers.

SYS.1.1.A7 DISCONTINUED (B)

This requirement has been discontinued.

SYS.1.1.A8 DISCONTINUED (B)

This requirement has been discontinued.

SYS.1.1.A9 Use of Antivirus Programs on Servers (B)

Depending on the installed operating system, the services provided, and other existing protection mechanisms of the server, it MUST be assessed whether antivirus programs should and can be used. Where available, specific statements as to whether antivirus protection is necessary from the relevant operating system building blocks of the IT-Grundschutz Compendium MUST be taken into account.

SYS.1.1.A10 Logging (B)

In general, all security-relevant system events MUST be logged; at a minimum, these include:

• system starts and reboots,
• successful and unsuccessful logins on the IT system (operating system and application software),
• failed authorization checks,
• blocked data streams (violations of ACLs or firewall rules),
• creation or modification of users, groups, and permissions,
• security-relevant error messages (e.g., hardware defects, exceeding capacity limits), and
• warning messages from security systems (e.g., antivirus).

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.1.1.A11 Establishment of a Security Policy for Servers (S)

Based on the institution’s general security policy, the requirements for servers SHOULD be elaborated in a separate security policy. This policy SHOULD be known to all administrators and other persons involved in the procurement and operation of servers, and should form the basis for their work. The implementation of the content required by the policy SHOULD be regularly reviewed. The results SHOULD be meaningfully documented.

SYS.1.1.A12 Planning of Server Deployment (S)

Each server system SHOULD be appropriately planned. At a minimum, the following points SHOULD be taken into account:

• selection of the platform (hardware or virtualized resources), operating system, and application software,
• sizing of the hardware (performance, memory, bandwidth, etc.),
• type and number of communication interfaces,
• power consumption, heat dissipation, space requirements, and form factor,
• administrative access (see SYS.1.1.A5 Protection of Interfaces),
• user access,
• logging (see SYS.1.1.A10 Logging),
• updating of operating system and applications, and
• integration into system and network management, data backup, and protection systems (antivirus, IDS, etc.).

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.1.1.A13 Procurement of Servers (S)

Before one or more servers are procured, a requirements list SHOULD be created against which the products available on the market can be evaluated.

SYS.1.1.A14 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.1.A15 Uninterruptible and Stable Power Supply (S) [Facility Management]

Each server SHOULD be connected to an uninterruptible power supply (UPS).

SYS.1.1.A16 Secure Installation and Basic Configuration of Servers (S)

The complete installation and configuration process SHOULD be carried out, as far as possible, in a dedicated installation environment separated from production systems. The configuration of the operating system SHOULD already be completed before the server is put into productive operation.

Multiple key functions and roles SHOULD NOT be fulfilled by a single server but SHOULD be distributed appropriately.

All security-relevant settings of the activated services and functions (cf. SYS.1.1.A6 Deactivation of Unneeded Services) SHOULD be configured, tested, and regularly reviewed for content in accordance with the requirements of the security policy for servers (see SYS.1.1.A11 Establishment of a Security Policy for Servers). In doing so, the server SHOULD be configured taking into account the recommendations of the operating system vendor and the preset default behavior, unless this conflicts with other requirements from IT-Grundschutz or the organization. The decisions SHOULD be documented and justified. Configuration options SHOULD be set in any case, even if the preset default behavior is not changed as a result.

If the server requires a connection to the internet or must be reachable from the internet, it SHOULD only be connected to the internet after installation and configuration have been completed.

SYS.1.1.A17 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.1.A18 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.1.A19 Configuration of Local Packet Filters (S)

Existing local packet filters SHOULD be configured through a rule set such that incoming and outgoing communication is restricted to the required communication partners, communication protocols, and ports and interfaces. The identity of remote systems and the integrity of connections to them SHOULD be cryptographically secured.

SYS.1.1.A20 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.1.A21 Operations Documentation for Servers (S)

Operational tasks performed on a server SHOULD be documented traceably (who?, when?, what?). In particular, configuration changes SHOULD be traceable from the documentation. Security-relevant tasks — e.g., who is authorized to install new hard drives — SHOULD be documented. Everything that can be documented automatically SHOULD also be documented automatically. The documentation SHOULD be protected against unauthorized access and loss.

SYS.1.1.A22 Integration into Emergency Planning (S)

The server SHOULD be taken into account in the emergency management process. To this end, the emergency requirements for the server SHOULD be determined and appropriate emergency measures implemented, e.g., by creating restart plans or securely storing passwords and cryptographic keys.

SYS.1.1.A23 System Monitoring and Monitoring of Servers (S)

The server system SHOULD be integrated into an appropriate system monitoring or monitoring concept. The system status and the operability of the server and the services running on it SHOULD be continuously monitored. Error states and the exceeding of defined threshold values SHOULD be reported to operations personnel.

SYS.1.1.A24 Security Testing for Servers (S)

Servers SHOULD be subjected to regular security tests that verify whether all security requirements are met and, if applicable, identify existing vulnerabilities. These security tests SHOULD be conducted in particular on servers with external interfaces. However, in order to prevent indirect attacks via infected IT systems in the institution’s own network, internal servers SHOULD also be tested at defined intervals. It SHOULD be examined whether security tests can be automated, e.g., using suitable scripts.

SYS.1.1.A25 Controlled Decommissioning of a Server (S)

When decommissioning a server, it SHOULD be ensured that no important data that may be stored on the installed storage media is lost, and that no data requiring protection is left behind. There SHOULD be an overview of which data is stored where on the server. It SHOULD be ensured in good time that services provided by the server are taken over by another server, if required.

A checklist SHOULD be created that can be worked through when decommissioning a server. This checklist SHOULD cover at a minimum aspects relating to data backup, migration of services, and the subsequent secure erasure of all data.

SYS.1.1.A35 Creation and Maintenance of an Operations Manual (S)

An operations manual SHOULD be created. All necessary regulations, requirements, and settings required to operate servers SHOULD be documented in it. There SHOULD be a specific operations manual for each type of server. The operations manual SHOULD be regularly updated. The operations manual SHOULD be protected against unauthorized access. The operations manual SHOULD be available in emergencies.

SYS.1.1.A37 Encapsulation of Security-Critical Applications and Operating System Components (S)

In order to prevent both unauthorized 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 specially encapsulated according to their protection needs or isolated from other applications and operating system components. In particular, security-critical applications that process data from insecure sources (e.g., web browsers and office communication applications) SHOULD be taken into account.

SYS.1.1.A39 Central Management of Security Policies for Servers (S)

All settings of the server SHOULD be managed using a central management system (see also OPS.1.1.7 System Management) and configured according to the identified protection needs and based on internal policies. Configuration parameters that cannot be technically implemented SHOULD be documented, justified, and coordinated with security management.

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.1.1.A26 DISCONTINUED (H)

This requirement has been discontinued.

SYS.1.1.A27 Host-Based Intrusion Detection (H)

Host-based intrusion detection systems (IDS) and intrusion prevention systems (IPS) SHOULD be deployed to monitor system behavior for anomalies and misuse. The IDS/IPS mechanisms used SHOULD be appropriately selected, configured, and thoroughly tested. In the event of an intrusion detection, operations personnel SHOULD be alerted in an appropriate manner.

Using operating system mechanisms or suitable additional products, changes to system files and configuration settings SHOULD be checked, restricted, and reported.

SYS.1.1.A28 Increasing Availability Through Redundancy (H)

Servers with high availability requirements SHOULD be adequately protected against failures. For this purpose, at a minimum, appropriate redundancies SHOULD be available and maintenance contracts concluded with suppliers. It SHOULD be examined whether, in cases of very high requirements, high-availability architectures with automatic failover — if applicable across different sites — are required.

SYS.1.1.A29 DISCONTINUED (H)

This requirement has been discontinued.

SYS.1.1.A30 One Service per Server (H)

Depending on the threat situation and the protection needs of the services, only one service SHOULD be operated on each server.

SYS.1.1.A31 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 specified explicitly, certificate-based or path rules SHOULD alternatively be used.

SYS.1.1.A32 DISCONTINUED (H)

This requirement has been discontinued.

SYS.1.1.A33 Active Management of Root Certificates (H)

During server procurement and installation, it SHOULD be documented which root certificates are necessary for the operation of the server. The server SHOULD only contain those root certificates that are necessary for operation and documented in advance. It SHOULD be regularly reviewed 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.

SYS.1.1.A34 Disk Encryption (H)

In the case of high protection needs, the data media of the server SHOULD be encrypted using a product or procedure considered secure. This SHOULD also apply to virtual machines with production data. A TPM alone SHOULD NOT serve as the sole key protection. The recovery password SHOULD be stored in an appropriately secure location. For very high requirements, e.g., regarding confidentiality, full volume or full disk encryption SHOULD be performed.

SYS.1.1.A36 Hardening the Boot Process (H)

The bootloader and operating system kernel SHOULD be signed using self-controlled key material and verified at system startup in a trusted chain (Secure Boot). Key material that is not needed SHOULD be removed.

SYS.1.1.A38 Hardening the Host System Using a Read-Only File System (H)

The integrity of the host system SHOULD be ensured by a read-only file system (Immutable OS).

Additional Information

Good to Know

The National Institute of Standards and Technology (NIST) provides the document “Guide to General Server Security: NIST Special Publication 800-123”, July 2008.