(Central) User Management

This topic contains the following sections:

General considerations on user management

If communication is allowed through a firewall or possible via local access, access should be protected by a user login.

Users in this context may be human users, software processes, and devices used to build automation infrastructures and systems.

Human users: They must be authenticated when logging on and will be given access to run programs under the account used to log in.
According to the IEC 62443 standard, the authentication of human users is necessary "on all interfaces capable of human user access". This includes local human-machine-interfaces (touchscreens, keyboards and further command devices), and network protocols designed for human user interactions (HTTP, HTTPS, FTP and SFTP) as well as open and proprietary protocols which are, for example, implemented with device configuration tools.
Software processes: Processes must be authenticated when they are automatically started by the operating system and run under the account under which they were started.
Devices: While a device is connected to the system, its identity must be verified. This ensures that devices are authorized to participate in system operation.

Note
Exceptions can be considered for display-only or basic machine operation. All administrative access should be protected.

This topic relates to the identification and authentication of human users.

User management can be done locally, but is then difficult to administer. Central user management systems, as shown in the example below, are more practical.

Note
If a system does not support access control, a dedicated firewall can help by permitting predefined connections only if the user has previously logged on to the firewall.

Roles (e.g., operator, process engineer, maintenance engineer or administrator) are groups of access rights that can be assigned to human users. If identifiers, authenticators, and roles are used, user access controls can be managed more easily. Furthermore, this reduces the potential for errors and omissions in the corresponding processes.
Depending on how the users will use the system, the roles for the ICS will be defined. A user may have one or more roles.

Each user needs "credentials" (password, smart card holding a private key) and the system needs "authenticators" (hashed password, certificate issued for the smart card and/or its user). Furthermore, authorizations must be assigned, i.e. it must be defined which operations the user may perform, which resources he may use and which data he may access.

Required: Password protection of devices in the ICS network

Password protection is necessary when logging on to both devices and applications in your ICS:

Logon to the network-capable devices with a particular user role ensures that the user is known and authorized to access/control/configure the device.
Example: When logging on to a PLCnext Technology controller from PLCnext Engineer to write a project, debug the application or control the PLC, you must enter a user role and password.
When launching a server application from a client, a login page must be called first.
Example: When launching an HMI application running on the internal HMI webserver of a PLCnext Technology controller from any HMI client (e.g. web browser on any computer), a login page should request authentication.

Why using a central user account management?

This question can already be answered by one simple example: In ICS networks, group passwords are often used for user access. The collective password is therefore known to many users. However, when employees leave the company, passwords are not changed or access is not blocked and can be abused. To solve such problems, a central user management should be used in which individual access rights are assigned to each employee.

The IEC 62443 standard (part 4.2) requires that the components involved in an ICS should "provide the capability to support the management of all accounts". This means it should either provide the management of all accounts directly according to part 3-3 or should be able integrate into a higher-level user account management system.

Integration into a higher-level user management means that the evaluation of the user authentication is performed in the higher-level user management system but not in the component itself. Many Phoenix Contact devices support this integration.

For such remote authentication, special network protocols are available which are referred to as "dial-in user services". Examples are RADIUS or LDAP both of which are briefly described below.

General rules for user management systems and user accounts

Every user management server (e.g. RADIUS, LDAP - see below) that evaluates user/login requests and subsequently grants or denies access to the network must be protected by suitable firewall services. A firewall used there should only allow valid dial-in requests to pass.
Strictly separate and distinguish highly privileged (e.g. overall domain administrator), privileged (server/workstation administrator) and non-privileged (normal daily work) accounts.
Reduce the number of privileged accounts to the minimum necessary.
If there are multiple administrators, each should have their own privileged user account, if possible. Otherwise, the responsibility or accountability is not always clearly assignable.
Even for the same person, administrative tasks and "day-to-day" operations should be under separate accounts. Follow the two-user rule to ensure security over convenience.
The IEC 62443 standard explicitly allows role-based and group-based identification and authentication. However, avoid group accounts as much as possible and use individual accounts instead wherever possible. If a group of users use the same account, correct and unique identification is not possible.
Make sure that (access) rights are restricted to the maximum possible extend for each user account. Refer to the topic "Least Privilege Concept".
Only administrators should be authorized to modify the user data bases or access right configurations. Other user must only have read-only permission to this data.
Delete temporary and outdated user accounts (which were, for example, been used during the design or commissioning phase of the plant/ICS).
Delete accounts that are no longer used.
Implement user identification and authentication in a way that does not impede rapid, local emergency response.
If supported, implement multifactor authentication.
According to the IEC 62443 standard, ICS network components should implement multifactor authentication for all human users who will have access. For implementing multifactor authentication, several authentication methods can be combined. Combine the request of the user password with, for example, the evaluation of biometrics (e.g. finger print scanner, face recognition), tokens, physical keys, key cards or the geographic location of the user.

Note
Central user management with username/password implies that the same credentials can be used to access other systems, probably even IT systems. Therefore, both the user/application interface and the communication channel between the device/application and the central user management system should be implemented via secure network connections and/or strong encryption. (See chapter "Secure Communication by Encryption and Authentication" for further information.)

RADIUS

RADIUS is a mechanism which allows network devices to authenticate users. It is less complex as, for example, Active Directory with LDAP as authentication mechanism (see next section). Therefore, it is particularly suitable when using devices that are not members of an Active Directory domain and which implement a simple authentication process.

Note
RADIUS is already an older protocol. In its documentation (RFC 2865, June 2000), the mechanism for hiding the user name and password is not considered state-of-the-art. Consequently, RADIUS cannot be considered strongly encrypted today. It should only be used for central authentication services if the communication can be additionally protected by other network security measures.
RADIUS can be used securely in conjunction with Extensible Authentication Protocol, such as EAP-TLS. EAP-TLS is a commonly deployed authentication protocol which uses X.509 certificates. RADIUS with EAP-TLS is often used in port security applications.

The RADIUS standard is based on a client-server-architecture. The client has to be available on the device which initiates the login and generates a corresponding request. This request is routed via the network to the RADIUS server via a Network Access Server (NAS) which is also referred to as Authenticator. The server is connected to a user database where each user is registered with a unique name, password and the assigned user access rights. The user database can be a RADIUS internal one or the server queries other directory services or databases.

The login request is evaluated (username and password or security token value correct?) and, if the authentication was successful, the server initiates the establishment of the requested connection using all parameters belonging to the user. These user data also include authorization information which define the access rights to resources, services and data in the network. This means, RADIUS supports both authentication and authorization.

Active Directory and Lightweight Directory Access Protocol (LDAP)

Active Directory (AD) is a directory service in Windows-based networks and part of the Windows Server operating system. The term "directory" in this context is not an equivalent to a folder in a file system, but rather corresponds to a register. It stores devices, users, resources and other relevant objects where each contained object is described by specific information (object type, class, attributes).
This way, AD allows the detailed modelling of organization structures or, if suitable, of your plant. The structure may contain several hierarchically structured domains. Each contained object can be uniquely identified. The Active Directory service supports the search for objects, e.g., devices, users etc.

AD allows the management of administrable resources such as network services, access rights to memory space, use rights for applications, access to peripheral devices or network printers and network services. In terms of cyber security, the administrator of the AD must authorize or can restrict each user from using individual services, network devices/resources or objects.

For that purpose, Active Directory implements the LDAP which is described in the following. (LDAP is one of four main components of AD).

Lightweight Directory Access Protocol (LDAP) is an authentication mechanisms implemented in AD (besides other ones like, for example, Kerberos). From a technical point of view, LDAP is a network protocol that enables queries and changes in a decentralized directory service. This means the directory may be distributed over several servers/computers. Each system involved must allow to communicate via a particular port (636 for TLS communication).

Note
LDAP should not be used without TLS protection as otherwise credentials (username, password) will be transmitted in unencrypted text.

Note
LDAP support is not only available in MS Active Directory. Various other software systems also implement an LDAP server, for example, Apache Directory Server, Novell (eDirectory), Sun (Sun Java System Directory Server) and many others. Furthermore, several different LDAP clients are available from various manufacturers.

In AD, the LDAP directory provides the information about users, computers and their group membership and it stores the certificates of the particular computer.

The directory is structured hierarchically below a fixed root directory which corresponds to the directory name. The hierarchy schema below the root must follow strict rules and can reflect your organization as it may contain countries, locations, departments, resources (servers, printers, services etc.) and persons. The LDAP data model defines for each directory service entry (i.e., for each object) a list of attributes such as Common Name (CN), localityName (L), User ID (UID) and more. They form the Distinguished Name which is the unique object identifier.

This way, the LDAP server enables central management of the users in a network. Or, to put it another way, user authentication can be connected to an LDAP server. It allows to manage user accounts, their passwords and group memberships at a central level. With an LDAP server there is no need to setup user accounts and passwords on every single controller.

The benefits are:

If a password change is necessary, it only needs to be changed once inside the LDAP directory and not in every component.
New users can be added without the need of configuring every component.
New user rights and permissions can be granted and distributed in a very simple way.
A blocked user is blocked in the whole system and not only for a single component.

Further Info
Refer to the PLCnext Info Center where the file-based configuration of an LDAP connection is described.