ORP.4 Identity and Access Management

Description

Introduction

Access to an institution’s protected resources must be restricted to authorised users and authorised IT components. Users and IT components must be identified and authenticated without doubt. The management of the information required for this purpose is referred to as identity management.

Access management concerns whether and how users or IT components may access and use information or services — in other words, whether access, entry, or system access is granted or denied to them based on their entitlements. Access management refers to the processes required for the assignment, revocation, and control of entitlements.

The boundaries between the two terms are fluid; this building block therefore uses the term identity and access management (IAM). For clarity, this building block uses the term “user identifier” or “identifier” synonymously for “user account”, “account”, “login”, and “account”. In this building block, the term “password” is used as a general term for “passphrase”, “PIN”, or “credential”.

Objective

The objective of this building block is to ensure that users or IT components can only access the IT resources and information they need for their work and for which they are authorised, and to deny access to unauthorised users or IT components. For this purpose, requirements are formulated with which institutions should build a secure identity and access management system.

Scope and Modeling

The building block ORP.4 Identity and Access Management MUST be applied once to the information network.

This building block describes fundamental requirements for building an identity and access management system.

Requirements relating to components of an identity and access management system, such as operating systems or directory services, can be found in the corresponding building blocks (e.g. SYS.1.3 Server unter Linux und Unix, SYS.1.2.3 Windows Server, APP.2.1 Allgemeiner Verzeichnisdienst, APP.2.2 Active Directory Domain Services).

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information networks, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular relevance to the building block ORP.4 Identity and Access Management.

Missing or Inadequate Processes in Identity and Access Management

If processes in identity and access management are inadequately defined or implemented, it is not ensured that access is restricted to the necessary level, thereby violating the need-to-know and least-privilege principles. IT Operations may not receive information about personnel changes, so that, for example, accounts of employees who have left are not deleted. These employees may thus continue to access protected information.

It is also possible that employees who have been transferred to a new department retain their old entitlements and thereby accumulate extensive overall permissions over time.

Lack of a Central Deactivation Option for Accounts

In institutions, employees often have accounts on various IT systems, such as production, test, quality assurance, or project systems. These are usually located in different areas of responsibility and are often managed by different administrators. This can result in a situation where the same unique identifier is not used across all IT systems and there is no central overview of the accounts on the individual IT systems. In such a scenario, it is not possible to deactivate all accounts of the affected employees in a single step in the event of an attack or password theft. In this scenario, when employees leave the institution, all access cannot be blocked in a single step either.

Inappropriate Management of Physical Access, System Access, and Data Access Rights

If the assignment of physical access, system access, and data access rights is poorly regulated, this quickly leads to serious security gaps, for example due to uncontrolled proliferation of rights. When identity management systems are introduced or audited, it frequently transpires that various persons in a wide range of organisational units are responsible for the assignment of entitlements. This can result in a situation where users receive entitlements informally or, conversely, have to go through unnecessarily complicated routes to obtain them. As a result, missing entitlements can impede day-to-day work on the one hand, and entitlements can be assigned without necessity on the other, thereby posing a security risk.

Requirements

The following are the specific requirements of the building block ORP.4 Identity and Access Management. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and reviewed 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 sensible and appropriate.

Exactly one role SHOULD hold Primary responsibility. There may also be Additional responsibilities. If one of these additional roles holds primary responsibility for fulfilling a requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural does not indicate how many people are intended to fill these roles.

Basic Requirements

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

ORP.4.A1 Regulation for the Creation and Deletion of Users and User Groups (B) [IT Operations]

Regulations MUST be established for how user identifiers and groups are to be created and deleted. Each user identifier MUST be uniquely assignable to a person. User identifiers that have been inactive for an extended period SHOULD be deactivated. All users and user groups MUST ONLY be created and deleted via separate administrative roles. Unnecessary user identifiers, such as default guest accounts or default administrator identifiers, MUST be appropriately deactivated or deleted.

ORP.4.A2 Creation, Modification, and Revocation of Entitlements (B) [IT Operations]

User identifiers and entitlements MUST NOT be assigned except on the basis of actual need and necessity for task fulfilment (principle of least privilege and need-to-know principle). When personnel changes occur, user identifiers and entitlements that are no longer required MUST be removed. If employees request entitlements beyond the standard, these MUST NOT be assigned without additional justification and review. Access entitlements to system directories and files SHOULD be restricted restrictively. All entitlements MUST be created via separate administrative roles.

ORP.4.A3 Documentation of User Identifiers and Rights Profiles (B) [IT Operations]

Documentation MUST be kept of which user identifiers, created user groups, and rights profiles are permitted and have been created. The documentation of permitted user identifiers, created user groups, and rights profiles MUST be regularly reviewed to determine whether it reflects the actual state of entitlement assignments. It MUST also be checked whether the entitlement assignment still meets the security requirements and the current tasks of the users. The documentation MUST be protected against unauthorised access. If it is held in electronic form, it SHOULD be included in the data backup procedure.

ORP.4.A4 Division of Tasks and Separation of Functions (B) [IT Operations]

The incompatible tasks and functions defined by the institution (see building block ORP.1 Organisation) MUST be separated by the identity and access management system.

ORP.4.A5 Assignment of Physical Access Authorisations (B) [IT Operations]

It MUST be determined which physical access authorisations are to be assigned to which persons in the context of their function, or revoked from them. The issue or revocation of physical access means such as chip cards MUST be documented. If access means have been compromised, they MUST be replaced. Those with physical access authorisations SHOULD be trained in the correct handling of access means. For extended absences, authorised persons SHOULD be temporarily blocked.

ORP.4.A6 Assignment of System Access Authorisations (B) [IT Operations]

It MUST be determined which system access authorisations are to be assigned to which persons in the context of their function, or revoked from them. If access means such as chip cards are used, the issue or revocation MUST be documented. If access means have been compromised, they MUST be replaced. Those with system access authorisations SHOULD be trained in the correct handling of access means. For extended absences, authorised persons SHOULD be temporarily blocked.

ORP.4.A7 Assignment of Data Access Rights (B) [IT Operations]

It MUST be determined which data access rights are to be assigned to which persons in the context of their function, or revoked from them. If chip cards or tokens are used in the context of access control, the issue or revocation MUST be documented. Users SHOULD be trained in the correct handling of chip cards or tokens. For extended absences, authorised persons SHOULD be temporarily blocked.

ORP.4.A8 Regulation of Password Use (B) [Users, IT Operations]

The institution MUST bindingly regulate password use (see also ORP.4.A22 Password Quality Policy and ORP.4.A23 Policy for Password-Processing Applications and IT Systems). In doing so, it MUST be examined whether passwords are to be used as the sole authentication method, or whether other authentication credentials or methods can be used in addition to or instead of passwords.

Passwords MUST NOT be reused. A separate password MUST be used for each IT system or application. Passwords that are easy to guess or that appear on common password lists MUST NOT be used. Passwords MUST be kept secret. They MUST ONLY be known personally to the users. Passwords MUST ONLY be entered unobserved. Passwords MUST NOT be stored on programmable function keys of keyboards or mice. A password MAY ONLY be written down for emergency archiving purposes. It MUST then be stored securely. The use of a password manager SHOULD be examined. For password managers with functions or plug-ins that synchronise passwords via third-party online services or otherwise transfer them to third parties, these functions and plug-ins MUST be deactivated. A password MUST be changed if it has become known or is suspected to have become known to unauthorised persons.

ORP.4.A9 Identification and Authentication (B) [IT Operations]

Access to all IT systems and services MUST be secured by appropriate identification and authentication of accessing users, services, or IT systems. Preconfigured authentication credentials MUST be changed before productive use.

ORP.4.A22 Password Quality Policy (B) [IT Operations]

Depending on the intended use and protection needs, secure passwords of appropriate quality MUST be chosen. The password MUST be sufficiently complex that it cannot be easily guessed. The password MUST NOT be too complicated, so that users are able to use the password regularly with reasonable effort.

ORP.4.A23 Policy for Password-Processing Applications and IT Systems (B) [IT Operations]

IT systems or applications SHOULD ONLY prompt for a password change with a valid reason. Purely time-controlled changes SHOULD be avoided. Measures MUST be taken to detect the compromise of passwords. If this is not possible, it SHOULD be examined whether the disadvantages of time-controlled password changes can be accepted and passwords are changed at certain intervals.

Default passwords MUST be replaced by sufficiently strong passwords. Predefined credentials MUST be changed. It SHOULD be ensured that the maximum possible password length is also checked in full by the processing IT systems. After a password change, old passwords MUST NOT be used again. Passwords MUST be stored as securely as possible. For credentials for technical accounts, service accounts, interfaces, or similar, a password change SHOULD be carefully planned and, if necessary, coordinated with the application owners.

When authenticating in networked systems, passwords MUST NOT be transmitted unencrypted over insecure networks. If passwords are transmitted within an intranet, they SHOULD be encrypted. In the event of unsuccessful login attempts, the password-processing applications or IT systems SHOULD NOT give any indication as to whether the password or identifier is incorrect.

Standard Requirements

Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be fulfilled.

ORP.4.A10 Protection of User Identifiers with Extensive Entitlements (S) [IT Operations]

User identifiers with extensive entitlements SHOULD be protected with multi-factor authentication, e.g. with cryptographic certificates, chip cards, or tokens.

ORP.4.A11 Resetting Passwords (S) [IT Operations]

An appropriately secure procedure SHOULD be defined and implemented for resetting passwords. IT Operations staff who are able to reset passwords SHOULD receive appropriate training. In the case of higher protection needs for the password, a strategy SHOULD be defined for situations where IT Operations staff cannot assume responsibility due to the lack of a secure means of transmitting the password.

ORP.4.A12 Development of an Authentication Concept for IT Systems and Applications (S) [IT Operations]

An authentication concept SHOULD be created. For each IT system and each application, it SHOULD define what functional and security requirements are placed on authentication. Authentication information MUST be stored in a cryptographically secure manner. Authentication information MUST NOT be transmitted unencrypted over insecure networks.

ORP.4.A13 Appropriate Selection of Authentication Mechanisms (S) [IT Operations]

Identification and authentication mechanisms appropriate to the protection needs SHOULD be used. Authentication data SHOULD be protected by the IT system or IT applications at all times against interception, modification, and destruction during processing. After each unsuccessful authentication attempt, the IT system or IT application SHOULD increasingly delay further login attempts (time delay). The total duration of a login attempt SHOULD be configurable. After the predefined number of unsuccessful authentication attempts has been exceeded, the IT system or IT application SHOULD lock the user identifier.

ORP.4.A14 Verification of the Effectiveness of User Separation in the IT System or Application (S) [IT Operations]

At appropriate intervals, it SHOULD be verified whether users of IT systems or applications regularly log off after completing their tasks. It SHOULD also be checked that multiple users are not working under the same identifier.

ORP.4.A15 Procedures and Design of Processes in Identity and Access Management (S) [IT Operations]

The following processes SHOULD be defined and implemented for identity and access management:

• Manage policies,
• Manage identity profiles,
• Manage user identifiers,
• Manage entitlement profiles, and
• Manage roles.

ORP.4.A16 Policies for Access and System Access Control (S) [IT Operations]

A policy SHOULD be created for the access and system access control of IT systems, IT components, and data networks. Standard rights profiles SHOULD be used that correspond to the functions and tasks of employees. A written access regulation SHOULD exist for each IT system and each IT application.

ORP.4.A17 Appropriate Selection of Identity and Access Management Systems (S) [IT Operations]

When deploying an identity and access management system, it SHOULD be suitable for the institution and its respective business processes, organisational structures and workflows, as well as its protection needs. The identity and access management system SHOULD be capable of mapping the requirements applicable within the institution for handling identities and entitlements. The selected identity and access management system SHOULD support the principle of separation of functions. The identity and access management system SHOULD be adequately protected against attacks.

ORP.4.A18 Use of a Central Authentication Service (S) [IT Operations]

In order to establish a central identity and access management system, a central network-based authentication service SHOULD be used. The use of a central network-based authentication service SHOULD be carefully planned. For this purpose, the security requirements relevant to the selection of such a service SHOULD be documented.

ORP.4.A19 Briefing All Employees on the Use of Authentication Methods and Mechanisms (S) [Users, IT Operations]

All employees SHOULD be briefed on the correct use of the authentication method. There SHOULD be comprehensible policies for the use of authentication methods. Employees SHOULD be informed about relevant regulations.

Requirements for High Protection Needs

The following are exemplary proposed requirements for this building block that go beyond the level of protection that represents 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.

ORP.4.A20 Emergency Preparedness for the Identity and Access Management System (H) [IT Operations]

It SHOULD be examined to what extent a failed identity and access management system is security-critical for the business processes. Precautions SHOULD be taken to remain operational in the event of a failed identity and access management system. In particular, the authorisation concept provided for in the emergency concept SHOULD remain applicable if the identity and access management system has failed.

ORP.4.A21 Multi-Factor Authentication (H) [IT Operations]

Secure multi-factor authentication SHOULD be used for authentication, e.g. with cryptographic certificates, chip cards, or tokens.

ORP.4.A24 Four-Eyes Principle for Administrative Activities (H) [IT Operations]

Administrative activities SHOULD only be able to be carried out by two persons. To this end, in the case of multi-factor authentication, the factors SHOULD be distributed between the two persons. When using passwords, these SHOULD be divided into two parts, with each of the two persons receiving one part.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides requirements for identity and access management in the standard ISO/IEC 27001:2013 “Information technology — Security techniques — Information security management systems — Requirements” in Annex A.9 Access Control.

The International Organization for Standardization (ISO) provides requirements for identity and access management in the standard ISO/IEC 29146:2016 “Information technology — Security techniques — A framework for access management”.

The Information Security Forum (ISF) provides requirements for identity and access management in its standard “The Standard of Good Practice for Information Security” in chapter TS1.4 Identity and Access Management.

The National Institute of Standards and Technology (NIST) provides guidance on identity and access management in NIST Special Publication 800-53A, particularly in areas AC and IA.