The Claroty Blog

Real World Lessons from the Field: HMI Client/Server Architectures and the Security Issues they Create

| Yiftach Keshet

This is the fifth blog in our series focused on real-world problems in Operational Technology (OT)/ Industrial Control Systems (ICS) cybersecurity learned from our experiences with clients across the globe. The intent of this series is to cast light on common problems found across client environments - which pose both security and operational concerns.

In this blog, we focus on the security implications of a seemingly benign standard related to HMI Client/Server architecture.

Across nearly every industry, standard control room operations involve the use of an HMI client/server architecture. A typical workflow for a "Write" command would have the client sending the required command to the server, and the server performing the actual writing to the controller (PLC or DCS) memory.

Figure 1: Single HMI Machine with Both Server and Client

L5 Image 1.jpg


The number of HMI clients is derived from process monitoring requirements. Complex processes that rely on simultaneous monitoring of multiple parameters (temperature, pressure etc.) would require several control room engineers to be involved - each having an HMI client. In such a case, the HMI server processes various clients’ "Write" requests and is still the only endpoint that performs the actual writing to the controller’s memory.

No big deal but here is where the security concern comes into play. While the "Write" operation itself is documented, the common practice across nearly ever industry is that there is no documentation of the identity of the client that initiated the "Write" command in the first place. An exception to this would be the pharmaceutical industry which abides to strict documentation regulations that do require such identification, typically carried out via a purpose-built add-on.

Figure 2: Multiple HMI Machines with Two Clients and One Client/Server


L5 Image 2.jpg

Operationally speaking, this practice makes sense. The data that matters most in a production environemnt is the change that takes place. Therefore, tracking, documenting and analyzing these changes is common practice. However, from a security perspective a lack of knowledge related to the identity of the client requesting the change is of concern.

Let us consider an environment with three clients on three physical machines (the server can be installed on one of them or on a dedicated machine).

An attacker that successfully compromises one of these machines can leverage the HMI client to maliciously modify a critical process by changing values using the "Write" utility. These "Write" commands would not be attributed to the compromised machine but to the server that actually executes them, making real-time trace and detection extremely challenging.

Figure 3: multiple HMI machines attack scenario with Write commands

L5 Image 3.jpg

This is another in a long line of examples of how an operational mindset inadvertently creates an attack surface which is hard to mitigate.

Conclusion

A best practice for confronting the ‘HMI identity obscurity’ we have described is to closely monitor all the traffic vectors that might indicate an unmonitored external connection – DNS, HTTP and other similar protocols - and proactively apply an intensive monitoring routine on all HMIs within the environment to pinpoint any machine that may be compromised. Additionally, controlling remote access to the HMI through granular access policies will assist in both proactive prevention and post-incident detection of compromised HMIs.

.

 

Subscribe to Email Updates