I’m discussing the IEC 62443 certification with an organization: that build and sell ICS plants which are risky from a safety perspective. They currently comply with the Machinery Directive (Directive 2006/42/EC of the European Parliament), but they are not considering the Cyber risk. If today is not mandatory, more and more customers are requesting some “security” compliance.

Without reinventing the wheel I chose the IEC 62443 framework as a guideline to evaluate the AS-IS and define the next steps.

IEC 62443 is very complete, but in this post, I want to focus on AAA: Authentication, Authorization, and Accounting.

User authentication in OT (and medical devices)

AAA functions are described in many parts of IEC 62443 (on both system and component levels). Let’s see some requirements from IEC 62443-3-3 (I’m quoting a few of them just as examples):

Security measures shall not adversely affect essential functions of a high availability IACS unless supported by a risk assessment. (Support of essential functions) The control system shall provide the capability to identify and authenticate all human users. This capability shall enforce such identification and authentication on all interfaces which provide human user access to the control system to support segregation of duties and least privilege in accordance with applicable security policies and procedures. (SR 1.1 – Human user identification and authentication) The control system shall provide the capability to employ multifactor authentication for human user access to the control system via an untrusted network (SR 1.1 RE 2 – Multifactor authentication for untrusted networks) Automatic denial of access for control system operator workstations or nodes should not be used when immediate operator responses are required in emergency situations. (SR 1.11 – Unsuccessful login attempts) The control system shall provide the capability to limit the number of concurrent sessions per interface for any given user (human, software process or device) to a configurable number of sessions. (SR 2.7 – Concurrent session control) The control system shall provide the capability to centrally manage audit events and to compile audit records from multiple components throughout the control system into a system-wide (logical or physical), time-correlated audit trail […] (SR 2.8 RE 1 – Centrally managed, system-wide audit trail, IEC 62443)

We have similar requirements for medical devices.

In short:

• AAA must be implemented in the proper way (user and non-user access must be authenticated, authorized, and logged).
• In some cases additional security measures may be required (MFA).
• Emergency access (firecall) must be provided.
• Security measures cannot impact essential functions.

The above sentences may sound contradictory, but we are missing an important piece: the context.

The context

In the real world plants and medical devices are installed in specific contexts. Most of them are installed in a restricted area where only authorized personell can enter and operate. Under emergency operations, they must operate as fast as possible. Moreover, we should differentiate security measures for reading, writing, and administrative operations.

I often see remote access to plants and medical devices for service assistance.

Finally, we need to evaluate the risk of information available on HMI (for both local and remote access). Medical devices are more critical, but ICS HMIs can store confidential information (recipes, production details…).

An hypothetical approach

I don’t have the magic recipe that can fit any organization, but we could make some assumptions:

1. Setting the same PIN/password for any HMI/user is useless and doesn’t comply with IEC 62443 (users must be identified).
2. In a restricted area a read-only view may not require authentication.
3. There are also some remote connections that may not require a username/password authentication. For example, remote control rooms could be authenticated via IP/VPN and require stronger authentication only for write or administrative operations.
4. Fast emergency access must be guaranteed.
5. Any remote user must be identified with a strong authentication method (user, password, MFA).
6. Security measures cannot affect essential functions, thus we can offload AAA to external devices (firewalls, captive portals, NACs…)

Post-incident analysis involving casualties

The most critical situation a plant can face is the ones that involve casualties or physical damage. In those cases, we need to find out the root cause analysis and collect evidence that can help the investigation.

Here comes the logging and its security features: integrity and availability. Any event should be logged and made it permanent. The events I would log include:

• Access (unauthenticated)
• Authentication, Authorization
• Event logging and Accounting
• Chat (especially during service assistance)
• Software and configuration changes
• Output of integrity tests (systems and components)
• State of each component (especially during service assistance)

The manufacturer should consider WORM media for accounting:

The control system shall provide the capability to determine whether a given human user took a particular action. (SR 2.12 – Non-repudiation)

In a specific event, a good logging platform with WORM media helped to prove that casualties were caused by the customer and not by the manufacturer.

Conclusions

I often see OT and medical devices protected by simple PINs. Every time I’m asking why they are using the same 5 digits PIN shared between any authorized users and may be known by much much more. Blind compliance is useless, if we don’t evaluate the context we are not protecting a device, we are just scrolling a checklist.

References