APP.2.1 General Directory Service

Description

Introduction

A directory service makes information about any objects available in a defined manner within a data network. An object can store associated attributes — for example, for a user ID, the first and last name of the user, the personnel number, and the name of the IT system can be stored. This data can then be used equally by various applications. The directory service and its data are generally managed centrally.

Some typical use cases for directory services are:

• Management of address books, e.g., for phone numbers, email addresses, and certificates for electronic signatures
• User management, e.g., for managing accounts and permissions
• Provision of a backend service for authentication functions, e.g., for logging on to operating systems or applications

Directory services are optimized for read access, as data from the directory service is typically retrieved predominantly. Write accesses, in which entries are created, modified, or deleted, are less frequently necessary.

When a directory service is used, certain administrative tasks within the network, such as account creation, password changes, and role and group assignments, can be carried out centrally.

Objective

The objective of this building block is to operate general directory services securely and to protect the information processed with them appropriately.

Scope and Modeling

The building block APP.2.1 General Directory Service is to be applied to all directory services in use.

This building block addresses general security aspects of directory services regardless of the product used. For product-specific security aspects, there are additional building blocks in the IT-Grundschutz Compendium that are to be applied to the respective directory service in addition. Building blocks on server operating systems on which directory services are typically operated are listed in the SYS.1 Servers layer of the IT-Grundschutz Compendium. Basic requirements for software products are found in APP.6 General Software and must also be observed.

Directory services should generally be taken into account in the context of the building blocks ORP.4 Identity and Authorization Management, OPS.1.1.3 Patch and Change Management, CON.3 Data Backup Concept, OPS.1.2.2 Archiving, OPS.1.1.5 Logging, OPS.1.2.5 Remote Maintenance, and OPS.1.1.2 Proper IT Administration.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used as the basis for describing the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block APP.2.1 General Directory Service.

Missing or Insufficient Planning of Directory Service Deployment

The security of directory services relies heavily on the security of the underlying operating system, and in particular on file system security. Directory services can be installed and operated on many operating systems, which can result in a wide variety of security settings to be made. This variety increases the planning requirements and presupposes corresponding knowledge of the respective operating system. If the resulting overall solution is very heterogeneous or complex, an insufficiently planned deployment of the directory service during live operation can lead to security vulnerabilities.

Faulty or Insufficient Planning of Partitioning and Replication in the Directory Service

Partitioning allows the directory data of a directory service to be divided into individual sub-areas (partitions). To provide better load distribution, partitions of the directory service are often replicated to additional instances. In addition, redundant data storage improves failover capability and thus increases availability. Appropriate planning is therefore also of decisive importance here, since partition and replication settings can be changed retrospectively, but this can cause problems. It can lead, for example, to data loss and inconsistencies in data storage, to inadequate availability of the directory service, and to generally poor system performance or even outages.

Faulty Administration of Access and Authorization Rights

Access rights to an IT system and access rights to stored data and IT applications may only be granted to the extent required for the tasks to be performed. This also applies to the permissions that users and groups managed through a directory service receive, even if these apply to the information in the directory service itself. If these rights are administered incorrectly, operations may be disrupted if required rights have not been assigned. On the other hand, security vulnerabilities can arise if rights are granted beyond what is necessary. If the access rights in the directory service are assigned incorrectly or inconsistently, the security of the entire system is significantly endangered. Administrative rights are also a particularly critical point. If these rights are assigned incorrectly, the entire administration concept can be undermined or, under some circumstances, the administration of the directory system itself may even be prevented or unauthorized use may be enabled.

Faulty Configuration of Access to Directory Services

In many cases, other applications such as internet or intranet applications need to access the directory service. A misconfiguration can result in access rights being granted incorrectly. It can also happen that the directory service can be accessed without authorization or that authentication data is transmitted in clear text. In this case, information can be intercepted during transmission.

Failure of Directory Services

Due to technical failure caused by hardware or software problems, directory services or parts thereof can fail. As a result, the data in the directory is temporarily no longer accessible. In extreme cases, data can also be lost, or logins to IT systems served by the directory service may no longer be possible. This can hinder business processes and internal workflows. If functioning copies of the failed system components are available, access is still possible, but with limited performance depending on the chosen network topology.

Compromise of Directory Services Through Unauthorized Access

If attackers have succeeded in successfully performing or bypassing the necessary authentication against the directory service, they can subsequently access a large number of data without authorization. The entire directory service can thus potentially be compromised. This could damage or even destroy the entire affected system.

The security of a directory service can also be jeopardized if anonymous users are permitted. Because their identity is not verified, anonymous users can initially direct arbitrary queries to the directory service, through which they can obtain at least partial information about its structure and content. If anonymous access is permitted, DoS attacks on the directory service are also easier to carry out, as attackers have more access options that are difficult to control.

Faulty Configuration of Directory Services

Directory services have numerous functions, so that the directory service can be used by users with very different needs. A misconfiguration of these numerous functions can result in unauthorized access to the directory service. For example, if the default configuration is not sufficiently checked and adapted, the authentication information can be transmitted in clear text or insufficiently secured and thus intercepted.

Requirements

The following are the specific requirements of the building block APP.2.1 General Directory Service. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met 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. These SHOULD be filled insofar as this is meaningful and appropriate.

Exactly one role SHOULD be Primarily responsible. There may also 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 requirement heading. The use of singular or plural says nothing about how many people SHOULD fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

APP.2.1.A1 Creation of a Security Policy for Directory Services (B)

A security policy for the directory service MUST be created. This SHOULD be coordinated with the overarching security concept of the entire institution.

APP.2.1.A2 Planning of Directory Service Deployment (B) [Data Protection Officer, Fachverantwortliche]

The deployment of directory services MUST be carefully planned. The specific use of the directory service MUST be determined. It MUST be ensured that the directory service and all applications using it are compatible. In addition, a concept for a structure of object classes and attribute types MUST be developed that meets the requirements of the intended uses. When planning a directory service that contains personal data, the staff representative body and the data protection officer MUST be involved. A needs-based authorization concept for the directory service MUST be designed. In general, the planned directory service structure SHOULD be fully documented and the documentation updated when changes are made. Measures SHOULD be planned and implemented to prevent the unauthorized collection of data from the directory service.

APP.2.1.A3 Setting Up Access Permissions for Directory Services (B) [Fachverantwortliche]

The administration of the directory service itself and the actual management of the data MUST be separated. All administrative task areas and permissions SHOULD be adequately documented.

If multiple directory service trees are merged, the resulting effective rights MUST be checked.

APP.2.1.A4 DISCONTINUED (B)

This requirement has been discontinued.

APP.2.1.A5 Secure Configuration and Configuration Changes of Directory Services (B)

The directory service MUST be configured securely. For the secure configuration of a directory service infrastructure, the clients (IT systems and applications) MUST be included in addition to the server.

If the configuration of the directory service or of the IT systems networked with it is changed, Users SHOULD be informed about maintenance work in a timely manner.

APP.2.1.A6 Secure Operation of Directory Services (B)

The security of the directory service MUST be permanently maintained during operation. All policies, regulations, and processes relating to the operation of a directory service system SHOULD be documented in a comprehensible manner and kept up to date. If the directory service is used to manage login credentials, dedicated clients MUST be used for remote maintenance. Access to all administration tools MUST be blocked for ordinary users.

APP.2.1.A17 Protection of Sensitive Login Credentials (B)

For attributes that contain sensitive login credentials such as passwords, access MUST be heavily restricted.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be met.

APP.2.1.A7 DISCONTINUED (S)

This requirement has been discontinued.

APP.2.1.A8 Planning of Partitioning in the Directory Service (S)

If partitioning is planned, it SHOULD be oriented toward the protection objectives of the directory service and support them appropriately. Partitioning SHOULD be planned in such a way that it limits the damage effects in the event of security incidents, enables the independent administration of various partitions, and follows organizational or security boundaries.

APP.2.1.A9 Appropriate Selection of Components for Directory Services (S) [Fachverantwortliche]

Suitable components SHOULD be identified for the deployment of a directory service. A requirements catalog SHOULD be created, taking APP.6 General Software into account, according to which the components for the directory service are selected and procured. As part of the planning and design of the directory service, security requirements SHOULD be formulated appropriate to the intended use. In particular, consideration SHOULD already be given during product selection to how further security requirements can be implemented using the respective component.

APP.2.1.A10 DISCONTINUED (S)

This requirement has been discontinued.

APP.2.1.A11 Setting Up Access to Directory Services (S)

Access to the directory service SHOULD be configured in accordance with the security policy. If the directory service is used as a server on the internet, it SHOULD be protected accordingly by a security gateway.

APP.2.1.A12 Monitoring of Directory Services (S)

Directory services SHOULD be monitored and logged together with the server on which they are operated. In particular, changes within the directory service and configuration changes to the directory service SHOULD be logged as a priority.

APP.2.1.A13 Securing Communication with Directory Services (S)

If confidential information is transmitted, all communication with the directory service SHOULD be encrypted using a secure protocol in accordance with BSI Technical Guideline TR-02102 (e.g., TLS). Data exchange between the client and the directory service server SHOULD be secured. It SHOULD be defined which data may be accessed.

APP.2.1.A14 Regulated Decommissioning of a Directory Service (S) [Fachverantwortliche]

When decommissioning the directory service, it SHOULD be ensured that rights or information still required are available to a sufficient extent. All other rights and information SHOULD be deleted. Furthermore, Users SHOULD be informed when a directory service is taken out of operation. When individual partitions of a directory service are taken out of operation, care SHOULD be taken to ensure that other partitions are not affected.

APP.2.1.A15 Migration of Directory Services (S)

If migration of directory services is planned, a migration concept SHOULD be created in advance. The migration concept SHOULD consider whether the authorization management of the old and new directory services functions analogously or whether new authorization structures are required. The schema changes made to the directory service SHOULD be analyzed and documented before migration. Extensive permissions used to carry out the migration of the directory service SHOULD be revoked again. During migration, it SHOULD be considered that IT systems accessing the directory service may maintain local caches or for other reasons an update of the migrated directory service content must be initiated there.

APP.2.1.A18 Planning of Replication in the Directory Service (S)

For each replication, it MUST be determined what purpose it serves. A replication topology and strategy SHOULD be chosen that is appropriate for the objective or deployment scenario. For replications that do not serve the high availability of the service, the replicated content of the directory service MUST be limited to the required objects. To be able to carry out the replications in a timely manner, sufficient bandwidth SHOULD be ensured.

APP.2.1.A19 Handling Anonymous Access to Directory Services (S)

If anonymous users are to be granted access to individual sub-areas of the directory tree, a proxy service SHOULD be placed in front of this. This proxy service SHOULD access the actual directory service via a separate account, a so-called proxy user. The access rights for this proxy user SHOULD be assigned sufficiently restrictively. They SHOULD also be completely revoked when the account is no longer needed. To prevent sensitive information from being inadvertently disclosed, the search function of the directory service SHOULD be restricted appropriately for the intended purpose.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. These proposals SHOULD be considered when there is a high protection need. The specific determination takes place in the context of an individual risk analysis.

APP.2.1.A16 Creation of an Emergency Plan for Directory Service Failure (H)

As part of emergency preparedness, there SHOULD be needs-based emergency planning for directory services. Emergency plans SHOULD be in place for the failure of important directory service systems. All emergency procedures for the entire system configuration of the directory service components SHOULD be documented.

APP.2.1.A20 Securing Replication (H)

Replications of confidential content SHOULD be secured additionally through encryption at application or transport layer, e.g., by IPsec, in addition to encryption. The strongest possible authentication methods SHOULD be used for authentication in the context of replication.

APP.2.1.A21 High Availability of the Directory Service (H)

A suitable strategy for high availability SHOULD be chosen. It SHOULD be decided whether master-master replication or master-replica replication (formerly referred to as master-slave replication) is more appropriate. Boundary conditions such as distributed locations or behavior in the event of inconsistencies SHOULD also be considered.

Additional Information

Good to Know

No further information is available for the building block APP.2.1 General Directory Service.